Re: [gentoo-user] Genlop wonky again

[Wols Lists]

On 06/01/2024 00:54, John Blinka wrote:
I’ve often found that it gives one estimate when multiple packages are 
being built, then a much longer estimate for still-in-progress builds 
once some of the builds have finished.


That result defies common sense. Less remaining work has to take less, 
not more (much more), time.


Common sense isn't common and, well, often doesn't make sense.

If there's a bunch of small builds skewing the "time per build" estimate 
down, as they drop off the list the estimated time per build will go up, 
and if the skew is serious enough it can even make the total estimated 
time go up ...


Cheers,
Wol

Re: Python warnings still

[Genes Lists]

On Fri, 2024-01-05 at 23:05 +, pete wrote:
> On Fri, 05 Jan 2024 17:13:40 -0500
> Genes Lists  wrote:
> ...
> 
> " pacman -Q --check python-pyrate-limiter
> python-pyrate-limiter: 59 total files, 0 missing files "
> 

Then may be worth trying:

   pacman -Qk 2>&1 | tee /tmp/pac.log
   
or if needed then:

   pacman -Qkk 

gene

Re: Python warnings still

[Genes Lists]

On Fri, 2024-01-05 at 21:45 +, pete wrote:
> Hi folks .
> 
> 
> I am still getting plagued by  these Python  warnings
> 
> warning: could not get file information for
> usr/lib/python3.11/site-packages/pyr
> ate_limiter-3.1.0.dist-info/...

Anything interesting from :

   pacman -Q --check python-pyrate-limiter

Re: Cotty's Channel

[lists]

Thanks Cotty!

> On 2 Jan 2024, at 20:06, Steve Cottrell  wrote:
> 
> Hello Pentaxians
> 
> Apologies if I mentioned this here on the list previously…I don’t think I 
> have, so in for a penny…
> 
> I’ve started a Youtube channel - Pentax content will be, ahem, very thin on 
> the ground - but not impossible as I still have some Pentax lenses that I use 
> for video occasionally, and I will feature them in an upcoming episode.
> 
> Anyway - new YouTube channel started yesterday. If you’re venturing into the 
> realms of video, this could be for you. A mixture of 'director's commentary' 
> versions of sailing features I've made with British sailor and broadcaster 
> Tom Cunliffe, and 'how-to' videos to improve your filmmaking skills. 5 new 
> videos dropped January 1st, and there is a short intro video.
> 
> New videos twice a month - have  <>a look and if it's something you might be 
> interested in, by all means do subscribe.

Just did, I do make the occasional video, and always try to edit them properly 
(using the simple MOVAVI program), and get good sound with it.
Not at your level of expertise, but above average for what you see on Youtube 
or Facebook. (which is quite easy really :-)

Your hints and tips, and equipment rants are highly appeciated!

Regards, JvW


=
Jan van Wijk; author of DFsee;  https://www.dfsee.com

--
%(real_name)s Pentax-Discuss Mail List
To unsubscribe send an email to pdml-le...@pdml.net
to UNSUBSCRIBE from the PDML, please visit the link directly above and follow 
the directions.

Re: [AFMUG] Ken Hohof

[Jeff Broadwick - Lists]

Hey Ken!

Regards,

Jeff 

Jeff Broadwick
CTIconnect
312-205-2519 Office
574-220-7826 Cell
jbroadw...@cticonnect.com

> On Dec 31, 2023, at 1:08 AM, Chuck McCown via AF  wrote:
> 
> Everbuddy say welcome back Ken!!!
> 
> Sent from my iPhone
> 
> 
> --
> AF mailing list
> AF@af.afmug.com
> http://af.afmug.com/mailman/listinfo/af_af.afmug.com


-- 
AF mailing list
AF@af.afmug.com
http://af.afmug.com/mailman/listinfo/af_af.afmug.com

[oe] [meta-oe][PATCH v3] bonnie++: New recipe for version 2.0

[Jörg Sommer via lists . openembedded . org]

From: Jörg Sommer 

Newer versions of bonnie get published on
. Unfortunately, the new version
doesn't compile with g++ 11 which requires *fix-csv2html-data.patch* and
configure fails due to cross compilation which gets fixed
with *fix-configure-lfs.patch*

Signed-off-by: Jörg Sommer 
---
 .../bonnie/bonnie++/fix-configure-lfs.patch   |  39 
 .../bonnie/bonnie++/fix-csv2html-data.patch   | 183 ++
 .../makefile-use-link-for-helper.patch|  24 +++
 .../bonnie/bonnie++_2.00a.bb  |  33 
 4 files changed, 279 insertions(+)
 create mode 100644 
meta-oe/recipes-benchmark/bonnie/bonnie++/fix-configure-lfs.patch
 create mode 100644 
meta-oe/recipes-benchmark/bonnie/bonnie++/fix-csv2html-data.patch
 create mode 100644 
meta-oe/recipes-benchmark/bonnie/bonnie++/makefile-use-link-for-helper.patch
 create mode 100644 meta-oe/recipes-benchmark/bonnie/bonnie++_2.00a.bb

diff --git a/meta-oe/recipes-benchmark/bonnie/bonnie++/fix-configure-lfs.patch 
b/meta-oe/recipes-benchmark/bonnie/bonnie++/fix-configure-lfs.patch
new file mode 100644
index 0..af20acdcd
--- /dev/null
+++ b/meta-oe/recipes-benchmark/bonnie/bonnie++/fix-configure-lfs.patch
@@ -0,0 +1,39 @@
+Upstream-Status: Submitted 
[https://salsa.debian.org/etbe/bonnie/-/merge_requests/3/diffs?commit_id=4ffece51791ba75ddca2e664cdce726cc40c92d3]
+
+diff --git i/configure.in w/configure.in
+index 080e40c..f2a2bbe 100644
+--- i/configure.in
 w/configure.in
+@@ -82,8 +82,15 @@ void * thread_func(void * param) { return NULL; }
+   , thread_ldflags="-lpthread"
+   , thread_ldflags="-pthread")
+ 
+-AC_SUBST(large_file)
+-AC_TRY_RUN([#ifndef _LARGEFILE64_SOURCE
++AC_ARG_ENABLE(lfs,
++  [  --disable-lfs  disable large file support],
++  LFS_CHOICE=$enableval, LFS_CHOICE=check)
++
++if test "$LFS_CHOICE" = yes; then
++   bonniepp_cv_large_file=yes
++elif test "$LFS_CHOICE" = check; then
++   AC_CACHE_CHECK([whether to enable -D_LARGEFILE64_SOURCE], 
bonniepp_cv_large_file,
++  AC_TRY_RUN([#ifndef _LARGEFILE64_SOURCE
+ #define _LARGEFILE64_SOURCE
+ #endif
+ #include 
+@@ -118,8 +125,12 @@ int main () {
+   }
+   close(fd);
+   return 0;
+-}], large_file="yes")
+-if [[ -n "$large_file" ]]; then
++}], bonniepp_cv_large_file="yes"))
++fi
++
++AC_SUBST(large_file)
++
++if [[ -n "$bonniepp_cv_large_file" ]]; then
+large_file="#define _LARGEFILE64_SOURCE"
+ fi
+ 
diff --git a/meta-oe/recipes-benchmark/bonnie/bonnie++/fix-csv2html-data.patch 
b/meta-oe/recipes-benchmark/bonnie/bonnie++/fix-csv2html-data.patch
new file mode 100644
index 0..4b37b8d65
--- /dev/null
+++ b/meta-oe/recipes-benchmark/bonnie/bonnie++/fix-csv2html-data.patch
@@ -0,0 +1,183 @@
+commit 7e9433a56f22426b11cbc9bd80e0debca67c893b
+Author: Jörg Sommer 
+Date:   Mon Jun 26 12:38:30 2023 +0200
+
+csv2html: Explicitly reference data in top level
+
+With g++ 11 *data* became ambiguous with [std::data][1]. Therefore it's
+needed to explicitly address the variable from the top level scope.
+
+[1] https://en.cppreference.com/w/cpp/iterator/data
+
+Upstream-Status: Submitted 
[https://salsa.debian.org/etbe/bonnie/-/merge_requests/3/diffs?commit_id=fb13a71d56dab8aaa39233fcaaedfb0ba4ad647d]
+
+diff --git a/bon_csv2html.cpp b/bon_csv2html.cpp
+index e9d9c50..652e330 100644
+--- a/bon_csv2html.cpp
 b/bon_csv2html.cpp
+@@ -87,8 +87,8 @@ int main(int argc, char **argv)
+ read_in(buf);
+   }
+ 
+-  props = new PPCCHAR[data.size()];
+-  for(i = 0; i < data.size(); i++)
++  props = new PPCCHAR[::data.size()];
++  for(i = 0; i < ::data.size(); i++)
+   {
+ props[i] = new PCCHAR[MAX_ITEMS];
+ props[i][0] = NULL;
+@@ -109,7 +109,7 @@ int main(int argc, char **argv)
+   }
+   calc_vals();
+   int mid_width = header();
+-  for(i = 0; i < data.size(); i++)
++  for(i = 0; i < ::data.size(); i++)
+   {
+ // First print the average speed line
+ printf("");
+@@ -171,23 +171,23 @@ int compar(const void *a, const void *b)
+ 
+ void calc_vals()
+ {
+-  ITEM *arr = new ITEM[data.size()];
++  ITEM *arr = new ITEM[::data.size()];
+   for(unsigned int column_ind = 0; column_ind < MAX_ITEMS; column_ind++)
+   {
+ switch(vals[column_ind])
+ {
+ case eNoCols:
+ {
+-  for(unsigned int row_ind = 0; row_ind < data.size(); row_ind++)
++  for(unsigned int row_ind = 0; row_ind < ::data.size(); row_ind++)
+   {
+ if(column_ind == COL_CONCURRENCY)
+ {
+-  if(data[row_ind][column_ind] && strcmp("1", 
data[row_ind][column_ind]))
++  if(::data[row_ind][column_ind] && strcmp("1", 
::data[row_ind][column_ind]))
+ col_used[column_ind] = true;
+ }
+ else
+ {
+-  if(data[row_ind][column_ind] && strlen(data[row_ind][column_ind]))
++  if(::data[row_ind][column_ind] && 
strlen(::data[row_ind][column_ind]))
+ col_used[column_ind] = true;
+ }
+   }
+@@ -195,22 +195,22 @@ 

Re: [oe] [meta-oe][PATCH v2] bonnie++: New recipe for version 2.0

[Jörg Sommer via lists . openembedded . org]

Are the build logs available anywhere? I would like to see do_configure and 
do_compile. I suspect that configure picks the wrong compiler.

Kind regards


Jörg Sommer

Software Developer / Programmierer

--


Navimatix GmbH

Tatzendpromenade 2

07745 Jena

T: 03641 - 327 99 0

F: 03641 - 526 306

M: joerg.som...@navimatix.de

www.navimatix.de



Geschäftsführer: Steffen Späthe, Jan Rommeley

Registergericht: Amtsgericht Jena, HRB 501480


From: Khem Raj 
Sent: Friday, 29 December 2023 17:58
To: Jörg Sommer 
Cc: openembedded-devel@lists.openembedded.org 

Subject: Re: [oe] [meta-oe][PATCH v2] bonnie++: New recipe for version 2.0

Here are some build issues seen while building for x86

https://errors.yoctoproject.org/Errors/Details/748405/

On Fri, Dec 29, 2023 at 2:19 AM Jörg Sommer via lists.openembedded.org
 wrote:
>
> From: Jörg Sommer 
>
> Newer versions of bonnie get published on
> . Unfortunately, the new version
> doesn't compile with g++ 11 which requires *fix-csv2html-data.patch* and
> configure fails due to cross compilation which gets fixed
> with *fix-configure-lfs.patch*
>
> Signed-off-by: Jörg Sommer 
> ---
>  .../bonnie/bonnie++/fix-configure-lfs.patch   |  39 
>  .../bonnie/bonnie++/fix-csv2html-data.patch   | 183 ++
>  .../bonnie/bonnie++_2.00a.bb  |  26 +++
>  3 files changed, 248 insertions(+)
>  create mode 100644 
> meta-oe/recipes-benchmark/bonnie/bonnie++/fix-configure-lfs.patch
>  create mode 100644 
> meta-oe/recipes-benchmark/bonnie/bonnie++/fix-csv2html-data.patch
>  create mode 100644 meta-oe/recipes-benchmark/bonnie/bonnie++_2.00a.bb
>
> diff --git 
> a/meta-oe/recipes-benchmark/bonnie/bonnie++/fix-configure-lfs.patch 
> b/meta-oe/recipes-benchmark/bonnie/bonnie++/fix-configure-lfs.patch
> new file mode 100644
> index 0..af20acdcd
> --- /dev/null
> +++ b/meta-oe/recipes-benchmark/bonnie/bonnie++/fix-configure-lfs.patch
> @@ -0,0 +1,39 @@
> +Upstream-Status: Submitted 
> [https://salsa.debian.org/etbe/bonnie/-/merge_requests/3/diffs?commit_id=4ffece51791ba75ddca2e664cdce726cc40c92d3]
> +
> +diff --git i/configure.in w/configure.in
> +index 080e40c..f2a2bbe 100644
> +--- i/configure.in
>  w/configure.in
> +@@ -82,8 +82,15 @@ void * thread_func(void * param) { return NULL; }
> +   , thread_ldflags="-lpthread"
> +   , thread_ldflags="-pthread")
> +
> +-AC_SUBST(large_file)
> +-AC_TRY_RUN([#ifndef _LARGEFILE64_SOURCE
> ++AC_ARG_ENABLE(lfs,
> ++  [  --disable-lfs  disable large file support],
> ++  LFS_CHOICE=$enableval, LFS_CHOICE=check)
> ++
> ++if test "$LFS_CHOICE" = yes; then
> ++   bonniepp_cv_large_file=yes
> ++elif test "$LFS_CHOICE" = check; then
> ++   AC_CACHE_CHECK([whether to enable -D_LARGEFILE64_SOURCE], 
> bonniepp_cv_large_file,
> ++  AC_TRY_RUN([#ifndef _LARGEFILE64_SOURCE
> + #define _LARGEFILE64_SOURCE
> + #endif
> + #include 
> +@@ -118,8 +125,12 @@ int main () {
> +   }
> +   close(fd);
> +   return 0;
> +-}], large_file="yes")
> +-if [[ -n "$large_file" ]]; then
> ++}], bonniepp_cv_large_file="yes"))
> ++fi
> ++
> ++AC_SUBST(large_file)
> ++
> ++if [[ -n "$bonniepp_cv_large_file" ]]; then
> +large_file="#define _LARGEFILE64_SOURCE"
> + fi
> +
> diff --git 
> a/meta-oe/recipes-benchmark/bonnie/bonnie++/fix-csv2html-data.patch 
> b/meta-oe/recipes-benchmark/bonnie/bonnie++/fix-csv2html-data.patch
> new file mode 100644
> index 0..4b37b8d65
> --- /dev/null
> +++ b/meta-oe/recipes-benchmark/bonnie/bonnie++/fix-csv2html-data.patch
> @@ -0,0 +1,183 @@
> +commit 7e9433a56f22426b11cbc9bd80e0debca67c893b
> +Author: Jörg Sommer 
> +Date:   Mon Jun 26 12:38:30 2023 +0200
> +
> +csv2html: Explicitly reference data in top level
> +
> +With g++ 11 *data* became ambiguous with [std::data][1]. Therefore it's
> +needed to explicitly address the variable from the top level scope.
> +
> +[1] https://en.cppreference.com/w/cpp/iterator/data
> +
> +Upstream-Status: Submitted 
> [https://salsa.debian.org/etbe/bonnie/-/merge_requests/3/diffs?commit_id=fb13a71d56dab8aaa39233fcaaedfb0ba4ad647d]
> +
> +diff --git a/bon_csv2html.cpp b/bon_csv2html.cpp
> +index e9d9c50..652e330 100644
> +--- a/bon_csv2html.cpp
>  b/bon_csv2html.cpp
> +@@ -87,8 +87,8 @@ int main(int argc, char **argv)
> + read_in(buf);
> +   }
> +
> +-  props = new PPCCHAR[data.size()];
> +-  for(i = 0; i < data.size(); i++)
> ++  props = new PPCCHAR[::data.size()];
> ++  for(i = 0; i < ::data.size(); i++)
> +   {
> + props[i] = new PCCHAR[MAX_ITEMS];
> + props[i][0] = NULL;
> +@@ -109,7 +109,7 @@ int main(int argc, char **argv)
> +   }
> +   calc_vals();
> +   int mid_width = header();
> +-  for(i = 0; i < data.size(); i++)
> ++  for(i = 0; i < ::data.size(); i++)
> +   {
> + // First print the average speed line
> + printf("");
> +@@ -171,23 +171,23 @@ int compar(const void *a, const void *b)
> +
> + void 

Re: postfix stable35->3.5.22, stable->3.7.8

[Why 42? The lists account.]

On Fri, Dec 22, 2023 at 10:24:03PM +, Stuart Henderson wrote:
> On 2023/12/22 22:20, Stuart Henderson wrote:
> > On 2023/12/19 16:52, Stuart Henderson wrote:
> > > Here are updates to postfix stable and stable35 versions, the latter
> > > from tb@. I've tested both.
> > 
> > New ones with smtpd_forbid_bare_newline :
> 
> oops, updated on a machine that didn't have the 3.5 openssl
> patch, here are the right ones:
> ...

Hi Stuart,

That's very cool - I'd love to be able to build a new Postfix with that
fix.

Currently I'm running 7.3 (+ postfix-3.7.5p8-sasl2). Should this diff
apply to 7.3?

FYI, I've not used ports much before, well, not in the last 10 years or
so. I was able to download the port tar archive:
> ftp https://cdn.openbsd.org/pub/OpenBSD/$(uname -r)/{ports.tar.gz,SHA256.sig}

And, after some faffing around, I was able to do "make fetch" and "make
extract". However, when I use patch to try to apply the diffs from your
email, I noticed two errors. The first one is a "patch reversed" error:
> dna-ng:postfix 29.12 17:26:00 % patch -i 
> ~robb/obsd_ports_postfix_build_mods_smtp_smuggling_20231222.patch ; echo $?
> Hmm...  Looks like a unified diff to me...
> The text leading up to this was:
> --
> |Index: stable/Makefile
> |===
> |RCS file: /cvs/ports/mail/postfix/stable/Makefile,v
> |retrieving revision 1.251
> |diff -u -p -r1.251 Makefile
> |--- stable/Makefile  26 Oct 2023 20:17:58 -  1.251
> |+++ stable/Makefile  22 Dec 2023 22:22:09 -
> --
> Patching file stable/Makefile using Plan A...
> Reversed (or previously applied) patch detected!  Assume -R? [y] 
> Hunk #1 succeeded at 2 with fuzz 1 (offset 1 line).
> Can't backup stable/Makefile, output is in /home/robb/tmp/patchoS8gjDYOvpd: 
> Permission denied
> Hmm...  The next patch looks like a unified diff to me...
> The text leading up to this was:
> ...
(Not sure how best to answer that question) ...

Then, after several apparently successful patch operations, the patch
command ends with:
> ...
> |Index: stable35/patches/patch-src_tls_tls_misc_c
> |===
> |RCS file: stable35/patches/patch-src_tls_tls_misc_c
> |diff -N stable35/patches/patch-src_tls_tls_misc_c
> |--- /dev/null1 Jan 1970 00:00:00 -
> |+++ stable35/patches/patch-src_tls_tls_misc_c22 Dec 2023 22:22:09 
> -
> --
> (Creating file stable35/patches/patch-src_tls_tls_misc_c...)
> patch:  can't find stable35/patches/patch-src_tls_tls_misc_c
> 2

At this point the stable35/patches sub-directory contains:
> dna-ng:postfix 29.12 17:47:40 % l stable35/patches/
> -rw-r--r--  1 root  wheel   566 Nov  1  2022 patch-src_util_sys_defs_h
> -rw-r--r--  1 root  wheel   424 Nov  1  2022 patch-src_tls_tls_server_c
> -rw-r--r--  1 root  wheel   415 Nov  1  2022 patch-src_tls_tls_certkey_c
> -rw-r--r--  1 root  wheel   674 Nov  1  2022 patch-makedefs
> -rw-r--r--  1 root  wheel  6248 Nov  1  2022 patch-conf_master_cf
> -rw-r--r--  1 root  wheel   611 Nov  1  2022 patch-conf_main_cf
> drwxr-xr-x  2 root  wheel   512 Mar 25  2023 CVS

It seems more likely I'm doing something wrong than there is an issue
with your patch ... but just FYI.

Ironically, I'm only interested in building 3.7.9 + sasl2. If I carry on
regardless :-) ... then I run into some issue(s) around ports and
permissions e.g. "make prepare" starts, runs and then fails with:
> ...
> ===>  Building package for metaauto-1.0p4
> Create /home/robb/ports/PACKAGE_REPOSITORY/amd64/no-arch/metaauto-1.0p4.tgz
> Creating package metaauto-1.0p4
> pkg_create: mkdir /usr/ports/plist: Permission denied

After a further (long) period of experimentation, I tried switching from
using sudo to doas in mk.conf ... but now even the fetch command fails
:-/

Cheers,
Robb.

[oe] [meta-oe][PATCH v2] bonnie++: New recipe for version 2.0

[Jörg Sommer via lists . openembedded . org]

From: Jörg Sommer 

Newer versions of bonnie get published on
. Unfortunately, the new version
doesn't compile with g++ 11 which requires *fix-csv2html-data.patch* and
configure fails due to cross compilation which gets fixed
with *fix-configure-lfs.patch*

Signed-off-by: Jörg Sommer 
---
 .../bonnie/bonnie++/fix-configure-lfs.patch   |  39 
 .../bonnie/bonnie++/fix-csv2html-data.patch   | 183 ++
 .../bonnie/bonnie++_2.00a.bb  |  26 +++
 3 files changed, 248 insertions(+)
 create mode 100644 
meta-oe/recipes-benchmark/bonnie/bonnie++/fix-configure-lfs.patch
 create mode 100644 
meta-oe/recipes-benchmark/bonnie/bonnie++/fix-csv2html-data.patch
 create mode 100644 meta-oe/recipes-benchmark/bonnie/bonnie++_2.00a.bb

diff --git a/meta-oe/recipes-benchmark/bonnie/bonnie++/fix-configure-lfs.patch 
b/meta-oe/recipes-benchmark/bonnie/bonnie++/fix-configure-lfs.patch
new file mode 100644
index 0..af20acdcd
--- /dev/null
+++ b/meta-oe/recipes-benchmark/bonnie/bonnie++/fix-configure-lfs.patch
@@ -0,0 +1,39 @@
+Upstream-Status: Submitted 
[https://salsa.debian.org/etbe/bonnie/-/merge_requests/3/diffs?commit_id=4ffece51791ba75ddca2e664cdce726cc40c92d3]
+
+diff --git i/configure.in w/configure.in
+index 080e40c..f2a2bbe 100644
+--- i/configure.in
 w/configure.in
+@@ -82,8 +82,15 @@ void * thread_func(void * param) { return NULL; }
+   , thread_ldflags="-lpthread"
+   , thread_ldflags="-pthread")
+ 
+-AC_SUBST(large_file)
+-AC_TRY_RUN([#ifndef _LARGEFILE64_SOURCE
++AC_ARG_ENABLE(lfs,
++  [  --disable-lfs  disable large file support],
++  LFS_CHOICE=$enableval, LFS_CHOICE=check)
++
++if test "$LFS_CHOICE" = yes; then
++   bonniepp_cv_large_file=yes
++elif test "$LFS_CHOICE" = check; then
++   AC_CACHE_CHECK([whether to enable -D_LARGEFILE64_SOURCE], 
bonniepp_cv_large_file,
++  AC_TRY_RUN([#ifndef _LARGEFILE64_SOURCE
+ #define _LARGEFILE64_SOURCE
+ #endif
+ #include 
+@@ -118,8 +125,12 @@ int main () {
+   }
+   close(fd);
+   return 0;
+-}], large_file="yes")
+-if [[ -n "$large_file" ]]; then
++}], bonniepp_cv_large_file="yes"))
++fi
++
++AC_SUBST(large_file)
++
++if [[ -n "$bonniepp_cv_large_file" ]]; then
+large_file="#define _LARGEFILE64_SOURCE"
+ fi
+ 
diff --git a/meta-oe/recipes-benchmark/bonnie/bonnie++/fix-csv2html-data.patch 
b/meta-oe/recipes-benchmark/bonnie/bonnie++/fix-csv2html-data.patch
new file mode 100644
index 0..4b37b8d65
--- /dev/null
+++ b/meta-oe/recipes-benchmark/bonnie/bonnie++/fix-csv2html-data.patch
@@ -0,0 +1,183 @@
+commit 7e9433a56f22426b11cbc9bd80e0debca67c893b
+Author: Jörg Sommer 
+Date:   Mon Jun 26 12:38:30 2023 +0200
+
+csv2html: Explicitly reference data in top level
+
+With g++ 11 *data* became ambiguous with [std::data][1]. Therefore it's
+needed to explicitly address the variable from the top level scope.
+
+[1] https://en.cppreference.com/w/cpp/iterator/data
+
+Upstream-Status: Submitted 
[https://salsa.debian.org/etbe/bonnie/-/merge_requests/3/diffs?commit_id=fb13a71d56dab8aaa39233fcaaedfb0ba4ad647d]
+
+diff --git a/bon_csv2html.cpp b/bon_csv2html.cpp
+index e9d9c50..652e330 100644
+--- a/bon_csv2html.cpp
 b/bon_csv2html.cpp
+@@ -87,8 +87,8 @@ int main(int argc, char **argv)
+ read_in(buf);
+   }
+ 
+-  props = new PPCCHAR[data.size()];
+-  for(i = 0; i < data.size(); i++)
++  props = new PPCCHAR[::data.size()];
++  for(i = 0; i < ::data.size(); i++)
+   {
+ props[i] = new PCCHAR[MAX_ITEMS];
+ props[i][0] = NULL;
+@@ -109,7 +109,7 @@ int main(int argc, char **argv)
+   }
+   calc_vals();
+   int mid_width = header();
+-  for(i = 0; i < data.size(); i++)
++  for(i = 0; i < ::data.size(); i++)
+   {
+ // First print the average speed line
+ printf("");
+@@ -171,23 +171,23 @@ int compar(const void *a, const void *b)
+ 
+ void calc_vals()
+ {
+-  ITEM *arr = new ITEM[data.size()];
++  ITEM *arr = new ITEM[::data.size()];
+   for(unsigned int column_ind = 0; column_ind < MAX_ITEMS; column_ind++)
+   {
+ switch(vals[column_ind])
+ {
+ case eNoCols:
+ {
+-  for(unsigned int row_ind = 0; row_ind < data.size(); row_ind++)
++  for(unsigned int row_ind = 0; row_ind < ::data.size(); row_ind++)
+   {
+ if(column_ind == COL_CONCURRENCY)
+ {
+-  if(data[row_ind][column_ind] && strcmp("1", 
data[row_ind][column_ind]))
++  if(::data[row_ind][column_ind] && strcmp("1", 
::data[row_ind][column_ind]))
+ col_used[column_ind] = true;
+ }
+ else
+ {
+-  if(data[row_ind][column_ind] && strlen(data[row_ind][column_ind]))
++  if(::data[row_ind][column_ind] && 
strlen(::data[row_ind][column_ind]))
+ col_used[column_ind] = true;
+ }
+   }
+@@ -195,22 +195,22 @@ void calc_vals()
+ break;
+ case eCPU:
+ {
+-  for(unsigned int row_ind = 0; row_ind < data.size(); row_ind++)
++  for(unsigned int row_ind 

Re: ***UNCHECKED*** Re: Post (snap) update emails: fsck errors and (in)security output

[Why 42? The lists account.]

On Thu, Dec 21, 2023 at 08:20:37AM -0300, Crystal Kolipe wrote:
> > login.conf used to allow unlimited datasize for the 'daemon' class. That was
> > changed to cap at 4G
> 
> Actually the value is an architecture dependent setting.
> 
> On amd64 it is indeed 4G, but typically 1024 Mb on the smaller archs which
> until recently, (post 7.4), included i386, which has now been increased to
> 1500 Mb.
Shouldn't it vary according to the amount of RAM available on the system?
Or is the backing store (swap) more relevant? Anyway ...

> BTW, we already had this exact same discussion with Robb on the list back in
> February:
> 
> https://marc.info/?l=openbsd-misc=167561903118994
> 
> So when I asked why he didn't just bump the value, it was indeed a question
> and not a suggestion to just do it.
Oh right :-) Seems like I was fat and happy in February with "-s=4194304"
in fstab and "df -h /tmp" returning 1.8G available.

I don't know why or when it stopped working in the meantime. Maybe daily
should report failed mounts? I mean, normally, something like that is
hard to miss, but with /tmp it's not so obvious. Just a thought.

I guess I tend to avoid modifying login.conf to avoid having to fix
issues reported by sysmerge after an upgrade. But in reality those don't
occur that often and I'm just being overly sensitive.

Right now login.conf contains:
> daemon:\
>:ignorenologin:\
>:datasize=4096M:\
>:maxproc=infinity:\
>:openfiles-max=1024:\
>:openfiles-cur=128:\
>:stacksize-cur=8M:\
>:tc=default:
> ...

I was just able to mfs_mount 2GB on the command line:
> mjoelnir:robb 28.12 17:13:17 # mkdir /tmptmp   
> mjoelnir:robb 28.12 17:13:25 # df -h /tmptmp   
> Filesystem SizeUsed   Avail Capacity  Mounted on
> /dev/sd1a 1005M250M704M27%/
> mjoelnir:robb 28.12 17:13:29 # mount_mfs -s 4194304 swap /tmptmp
> mjoelnir:robb 28.12 17:13:43 # df -h /tmptmp
> Filesystem SizeUsed   Avail Capacity  Mounted on
> mfs:23190  1.9G1.0K1.8G 1%/tmptmp

That was as root though, so maybe that's not such a great test. Is it
possible to do something like "doas daemon ..."?

I'll switch fstab back to use this size for /tmp and check after the next
reboot if it gets mounted as expected ...

Cheers,
Robb.

[oe] [meta-oe][PATCH] bonnie++: New recipe for version 2.0

[Jörg Sommer via lists . openembedded . org]

From: Jörg Sommer 

Newer versions of bonnie get published on
. Unfortunately, the new version
doesn't compile with g++ 11 which requires *fix-csv2html-data.patch* and
configure fails due to cross compilation which gets fixed
with *fix-configure-lfs.patch*

Signed-off-by: Jörg Sommer 
---
 .../bonnie/bonnie++/fix-configure-lfs.patch   |  39 
 .../bonnie/bonnie++/fix-csv2html-data.patch   | 183 ++
 .../bonnie/bonnie++_2.00a.bb  |  33 
 3 files changed, 255 insertions(+)
 create mode 100644 
meta-oe/recipes-benchmark/bonnie/bonnie++/fix-configure-lfs.patch
 create mode 100644 
meta-oe/recipes-benchmark/bonnie/bonnie++/fix-csv2html-data.patch
 create mode 100644 meta-oe/recipes-benchmark/bonnie/bonnie++_2.00a.bb

diff --git a/meta-oe/recipes-benchmark/bonnie/bonnie++/fix-configure-lfs.patch 
b/meta-oe/recipes-benchmark/bonnie/bonnie++/fix-configure-lfs.patch
new file mode 100644
index 0..af20acdcd
--- /dev/null
+++ b/meta-oe/recipes-benchmark/bonnie/bonnie++/fix-configure-lfs.patch
@@ -0,0 +1,39 @@
+Upstream-Status: Submitted 
[https://salsa.debian.org/etbe/bonnie/-/merge_requests/3/diffs?commit_id=4ffece51791ba75ddca2e664cdce726cc40c92d3]
+
+diff --git i/configure.in w/configure.in
+index 080e40c..f2a2bbe 100644
+--- i/configure.in
 w/configure.in
+@@ -82,8 +82,15 @@ void * thread_func(void * param) { return NULL; }
+   , thread_ldflags="-lpthread"
+   , thread_ldflags="-pthread")
+ 
+-AC_SUBST(large_file)
+-AC_TRY_RUN([#ifndef _LARGEFILE64_SOURCE
++AC_ARG_ENABLE(lfs,
++  [  --disable-lfs  disable large file support],
++  LFS_CHOICE=$enableval, LFS_CHOICE=check)
++
++if test "$LFS_CHOICE" = yes; then
++   bonniepp_cv_large_file=yes
++elif test "$LFS_CHOICE" = check; then
++   AC_CACHE_CHECK([whether to enable -D_LARGEFILE64_SOURCE], 
bonniepp_cv_large_file,
++  AC_TRY_RUN([#ifndef _LARGEFILE64_SOURCE
+ #define _LARGEFILE64_SOURCE
+ #endif
+ #include 
+@@ -118,8 +125,12 @@ int main () {
+   }
+   close(fd);
+   return 0;
+-}], large_file="yes")
+-if [[ -n "$large_file" ]]; then
++}], bonniepp_cv_large_file="yes"))
++fi
++
++AC_SUBST(large_file)
++
++if [[ -n "$bonniepp_cv_large_file" ]]; then
+large_file="#define _LARGEFILE64_SOURCE"
+ fi
+ 
diff --git a/meta-oe/recipes-benchmark/bonnie/bonnie++/fix-csv2html-data.patch 
b/meta-oe/recipes-benchmark/bonnie/bonnie++/fix-csv2html-data.patch
new file mode 100644
index 0..4b37b8d65
--- /dev/null
+++ b/meta-oe/recipes-benchmark/bonnie/bonnie++/fix-csv2html-data.patch
@@ -0,0 +1,183 @@
+commit 7e9433a56f22426b11cbc9bd80e0debca67c893b
+Author: Jörg Sommer 
+Date:   Mon Jun 26 12:38:30 2023 +0200
+
+csv2html: Explicitly reference data in top level
+
+With g++ 11 *data* became ambiguous with [std::data][1]. Therefore it's
+needed to explicitly address the variable from the top level scope.
+
+[1] https://en.cppreference.com/w/cpp/iterator/data
+
+Upstream-Status: Submitted 
[https://salsa.debian.org/etbe/bonnie/-/merge_requests/3/diffs?commit_id=fb13a71d56dab8aaa39233fcaaedfb0ba4ad647d]
+
+diff --git a/bon_csv2html.cpp b/bon_csv2html.cpp
+index e9d9c50..652e330 100644
+--- a/bon_csv2html.cpp
 b/bon_csv2html.cpp
+@@ -87,8 +87,8 @@ int main(int argc, char **argv)
+ read_in(buf);
+   }
+ 
+-  props = new PPCCHAR[data.size()];
+-  for(i = 0; i < data.size(); i++)
++  props = new PPCCHAR[::data.size()];
++  for(i = 0; i < ::data.size(); i++)
+   {
+ props[i] = new PCCHAR[MAX_ITEMS];
+ props[i][0] = NULL;
+@@ -109,7 +109,7 @@ int main(int argc, char **argv)
+   }
+   calc_vals();
+   int mid_width = header();
+-  for(i = 0; i < data.size(); i++)
++  for(i = 0; i < ::data.size(); i++)
+   {
+ // First print the average speed line
+ printf("");
+@@ -171,23 +171,23 @@ int compar(const void *a, const void *b)
+ 
+ void calc_vals()
+ {
+-  ITEM *arr = new ITEM[data.size()];
++  ITEM *arr = new ITEM[::data.size()];
+   for(unsigned int column_ind = 0; column_ind < MAX_ITEMS; column_ind++)
+   {
+ switch(vals[column_ind])
+ {
+ case eNoCols:
+ {
+-  for(unsigned int row_ind = 0; row_ind < data.size(); row_ind++)
++  for(unsigned int row_ind = 0; row_ind < ::data.size(); row_ind++)
+   {
+ if(column_ind == COL_CONCURRENCY)
+ {
+-  if(data[row_ind][column_ind] && strcmp("1", 
data[row_ind][column_ind]))
++  if(::data[row_ind][column_ind] && strcmp("1", 
::data[row_ind][column_ind]))
+ col_used[column_ind] = true;
+ }
+ else
+ {
+-  if(data[row_ind][column_ind] && strlen(data[row_ind][column_ind]))
++  if(::data[row_ind][column_ind] && 
strlen(::data[row_ind][column_ind]))
+ col_used[column_ind] = true;
+ }
+   }
+@@ -195,22 +195,22 @@ void calc_vals()
+ break;
+ case eCPU:
+ {
+-  for(unsigned int row_ind = 0; row_ind < data.size(); row_ind++)
++  for(unsigned int 

XFCE thunar dumps core when toggling "show hidden"

[Why 42? The lists account.]

Hi All,

(This discussion/issue moved from misc).

Thunar crashes when I try to toggle "show hidden" e.g. via "Ctrl+h":
zsh: segmentation fault (core dumped)  thunar

I'm running a recent snapshot:
mjoelnir:empty_directory 28.12 10:30:37 % uname -a
OpenBSD mjoelnir.fritz.box 7.4 GENERIC.MP#1535 amd64

With XFCE 4.18 e.g.
thunar-4.18.8   Xfce4 file manager
thunar-archive-0.5.2 Thunar archive plugin
thunar-media-tags-0.4.0 Thunar media tags plugin
xfce-4.18.1 Xfce desktop meta-package (base installation)

Below is a gdb stacktrace with various debug packages installed:
debug-glib2-2.78.3  debug info for glib2
debug-gtk+3-3.24.39 debug info for gtk+3
debug-thunar-4.18.8 debug info for thunar

Cheers,
Robb.


(gdb) bt
#0  g_node_traverse_pre_order (node=, flags=G_TRAVERSE_ALL, 
func=0xb39a046db40 , 
data=0xb3c1e775d20) at ../glib-2.78.3/glib/gnode.c:543
#1  0x0b3bff3c2577 in g_node_traverse_pre_order (node=, 
flags=G_TRAVERSE_ALL, func=0xb39a046db40 
, data=0xb3c1e775d20) at 
../glib-2.78.3/glib/gnode.c:544
#2  0x0b3bff3c2577 in g_node_traverse_pre_order (node=, 
flags=G_TRAVERSE_ALL, func=0xb39a046db40 
, data=0xb3c1e775d20) at 
../glib-2.78.3/glib/gnode.c:544
#3  0x0b39a0471046 in thunar_tree_view_set_show_hidden (view=0xb3c2ec9edc0, 
show_hidden=) at thunar-tree-view.c:1990
#4  thunar_tree_view_set_property (object=0xb3c2ec9edc0, prop_id=, value=, pspec=) at thunar-tree-view.c:509
#5  0x0b3c5df7982a in object_set_property (object=0xb3c2ec9edc0, 
pspec=0xb3c2ec70560, value=0x7c245b20a620, nqueue=0xb3c2aaeb250, 
user_specified=) at ../glib-2.78.3/gobject/gobject.c:1811
#6  0x0b3c5df795a8 in g_object_setv (object=0xb3c2ec9edc0, n_properties=1, 
names=0x7c245b20a5e0, values=0x7c245b20a620) at 
../glib-2.78.3/gobject/gobject.c:2722
#7  0x0b3c5df7a94b in g_object_set_property (object=0xdfdfdfdfdfdfdfdf, 
property_name=0xb39a03dea3b "show-hidden", value=0x0) at 
../glib-2.78.3/gobject/gobject.c:3022
#8  0x0b3c5df69f19 in on_source_notify (source=, 
pspec=, context=) at 
../glib-2.78.3/gobject/gbinding.c:556
#9  0x0b3c5df7142b in g_closure_invoke (closure=0xb3c1e76f570, 
return_value=, n_param_values=, 
param_values=0x7c245b20a7e0, invocation_hint=) at 
../glib-2.78.3/gobject/gclosure.c:832
#10 0x0b3c5df8df4c in signal_emit_unlocked_R (node=0x7c245b20a830, 
detail=2100, instance=0xb3c47855690, emission_return=0x0, 
instance_and_params=0x7c245b20a7e0) at ../glib-2.78.3/gobject/gsignal.c:3980
#11 0x0b3c5df8bbab in signal_emit_valist_unlocked (instance=0xb3c47855690, 
signal_id=, detail=2100, var_args=) at 
../glib-2.78.3/gobject/gsignal.c:3612
#12 0x0b3c5df8c39f in g_signal_emit_valist (instance=0xb3c47855690, 
signal_id=1, detail=2100, var_args=) at 
../glib-2.78.3/gobject/gsignal.c:3355
#13 g_signal_emit (instance=0xb3c47855690, signal_id=1, detail=2100) at 
../glib-2.78.3/gobject/gsignal.c:3675
#14 0x0b3c5df7da53 in g_object_dispatch_properties_changed 
(object=0xb3c47855690, n_pspecs=1, pspecs=0x7c245b20aaf8) at 
../glib-2.78.3/gobject/gobject.c:1427
#15 0x0b3c5df77e1c in g_object_notify_by_spec_internal 
(object=0xb3c47855690, pspec=0xb3c2ec77790) at 
../glib-2.78.3/gobject/gobject.c:1551
#16 0x0b39a047fc07 in thunar_window_action_show_hidden 
(window=0xb3c0f47e260) at thunar-window.c:4727
#17 0x0b3c5df7142b in g_closure_invoke (closure=0xb3c99ee9d40, 
return_value=, n_param_values=, 
param_values=0x7c245b20acc0, invocation_hint=) at 
../glib-2.78.3/gobject/gclosure.c:832
#18 0x0b3c5df8df4c in signal_emit_unlocked_R (node=0x7c245b20ad00, 
detail=0, instance=0xb3c99ef7180, emission_return=0x0, 
instance_and_params=0x7c245b20acc0) at ../glib-2.78.3/gobject/gsignal.c:3980
#19 0x0b3c5df8bbab in signal_emit_valist_unlocked (instance=0xb3c99ef7180, 
signal_id=, detail=0, var_args=) at 
../glib-2.78.3/gobject/gsignal.c:3612
#20 0x0b3c5df8c39f in g_signal_emit_valist (instance=0xb3c99ef7180, 
signal_id=487, detail=0, var_args=) at 
../glib-2.78.3/gobject/gsignal.c:3355
#21 g_signal_emit (instance=0xb3c99ef7180, signal_id=487, detail=0) at 
../glib-2.78.3/gobject/gsignal.c:3675
#22 0x0b3c42762fc6 in gtk_check_menu_item_toggled 
(check_menu_item=0xb3c99ef7180) at ../gtk+-3.24.39/gtk/gtkcheckmenuitem.c:473
#23 gtk_check_menu_item_activate (menu_item=0xdfdfdfdfdfdfdfdf) at 
../gtk+-3.24.39/gtk/gtkcheckmenuitem.c:640
#24 0x0b3c5df716fc in _g_closure_invoke_va (closure=0xb3bab6b6420, 
return_value=, instance=, args=0x7c245b20b250, 
n_params=, param_types=) at 
../glib-2.78.3/gobject/gclosure.c:895
#25 0x0b3c5df8bedf in signal_emit_valist_unlocked (instance=0xb3c99ef7180, 
signal_id=175, detail=, var_args=0x7c245b20b250) at 
../glib-2.78.3/gobject/gsignal.c:3516
#26 0x0b3c5df8c39f in g_signal_emit_valist (instance=0xb3c99ef7180, 
signal_id=175, detail=0, var_args=) at 
../glib-2.78.3/gobject/gsignal.c:3355
#27 g_signal_emit (instance=0xb3c99ef7180, signal_id=175, detail=0) at 
../glib-2.78.3/gobject/gsignal.c:3675
#28 

[oe] [meta-oe][PATCH] i2cdev: New recipe with i2c tools

[Jörg Sommer via lists . openembedded . org]

From: Jörg Sommer 

The main part is the tool lsi2c to scan the i2c bus, like lspci and lsusb
do.

This recipe also ships a static library *libi2cdev.a*. Because this library
contains the file *smbus.c* which is *GPL v2+,* and a static library can't
be linked dynamically to satisfy the LGPL, the whole recipe is marked
as *GPL-2.0-or-later.*

Signed-off-by: Jörg Sommer 
---
 .../i2cdev/i2cdev/fix-lsi2c-makefile.patch| 28 +++
 meta-oe/recipes-bsp/i2cdev/i2cdev_git.bb  | 26 +
 2 files changed, 54 insertions(+)
 create mode 100644 meta-oe/recipes-bsp/i2cdev/i2cdev/fix-lsi2c-makefile.patch
 create mode 100644 meta-oe/recipes-bsp/i2cdev/i2cdev_git.bb

diff --git a/meta-oe/recipes-bsp/i2cdev/i2cdev/fix-lsi2c-makefile.patch 
b/meta-oe/recipes-bsp/i2cdev/i2cdev/fix-lsi2c-makefile.patch
new file mode 100644
index 0..820d4bb44
--- /dev/null
+++ b/meta-oe/recipes-bsp/i2cdev/i2cdev/fix-lsi2c-makefile.patch
@@ -0,0 +1,28 @@
+From 57c09727220e00ab961325a2c85f5611bd1770d6 Mon Sep 17 00:00:00 2001
+Message-Id: 
<57c09727220e00ab961325a2c85f5611bd1770d6.1701984646.git.joerg.som...@navimatix.de>
+From: =?UTF-8?q?J=C3=B6rg=20Sommer?= 
+Date: Thu, 7 Dec 2023 22:29:40 +0100
+Subject: [PATCH] lsi2c/Makefile: Use builddir to refer to libi2cdev.a
+
+Signed-off-by: Jörg Sommer 
+Upstream-Status: Submitted 
[https://github.com/costad2/i2cdev/pull/2/commits/43f15e97d869797dbfeaacafa13216aaaf353426]
+---
+ lsi2c/Makefile.am | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/lsi2c/Makefile.am b/lsi2c/Makefile.am
+index 6defc1f..0d81d01 100644
+--- a/lsi2c/Makefile.am
 b/lsi2c/Makefile.am
+@@ -14,7 +14,7 @@ bin_PROGRAMS=lsi2c
+ lsi2c_SOURCES = lsi2c.c
+ 
+ # Linker options for lsi2c
+-lsi2c_LDADD = $(top_srcdir)/libi2cdev/libi2cdev.a
++lsi2c_LDADD = $(top_builddir)/libi2cdev/libi2cdev.a
+ 
+ # Compiler options for lsi2c
+ lsi2c_CFLAGS = -I$(top_srcdir)/include -std=c99 -fPIC
+-- 
+2.34.1
+
diff --git a/meta-oe/recipes-bsp/i2cdev/i2cdev_git.bb 
b/meta-oe/recipes-bsp/i2cdev/i2cdev_git.bb
new file mode 100644
index 0..b1f8a7f80
--- /dev/null
+++ b/meta-oe/recipes-bsp/i2cdev/i2cdev_git.bb
@@ -0,0 +1,26 @@
+SUMMARY = "i2c dev tools for Linux"
+DESCRIPTION = "\
+This package contains an I2C dev library and the i2c bus scanning \
+utility lsi2c. \
+"
+AUTHOR = "Danielle Costantino"
+HOMEPAGE = "https://github.com/costad2/i2cdev;
+LICENSE = "GPL-2.0-or-later"
+LIC_FILES_CHKSUM = "\
+file://COPYING;md5=768997ba510a952bef1775c50bc22b00 \
+
file://include/libi2cdev.h;beginline=12;endline=25;md5=72486a5e192d6ac5c7e55a4a95e380a6
 \
+
file://libi2cdev/smbus.c;beginline=9;endline=22;md5=d9a0de5a611b960fa75912ded6c60096
 \
+
file://lsi2c/lsi2c.c;beginline=11;endline=24;md5=72486a5e192d6ac5c7e55a4a95e380a6
 \
+"
+
+PR = "git${SRCPV}"
+
+SRC_URI = "\
+git://github.com/costad2/i2cdev.git;protocol=https;branch=master \
+file://fix-lsi2c-makefile.patch \
+"
+SRCREV = "ed9ad777d842880e7ac6ca5e0de4bd2d3b4d02dc"
+
+S = "${WORKDIR}/git"
+
+inherit autotools
-- 
2.34.1


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

[OE-core] [PATCH] i2cdev: New recipe with i2c tools

[Jörg Sommer via lists . openembedded . org]

From: Jörg Sommer 

The main part is the tool lsi2c to scan the i2c bus, like lspci and lsusb
do.

This recipe also ships a static library *libi2cdev.a*. Because this library
contains the file *smbus.c* which is *GPL v2+,* and a static library can't
be linked dynamically to satisfy the LGPL, the whole recipe is marked
as *GPL-2.0-or-later.*

Signed-off-by: Jörg Sommer 
---
 .../i2cdev/i2cdev/fix-lsi2c-makefile.patch| 28 +++
 meta/recipes-bsp/i2cdev/i2cdev_git.bb | 26 +
 2 files changed, 54 insertions(+)
 create mode 100644 meta/recipes-bsp/i2cdev/i2cdev/fix-lsi2c-makefile.patch
 create mode 100644 meta/recipes-bsp/i2cdev/i2cdev_git.bb

diff --git a/meta/recipes-bsp/i2cdev/i2cdev/fix-lsi2c-makefile.patch 
b/meta/recipes-bsp/i2cdev/i2cdev/fix-lsi2c-makefile.patch
new file mode 100644
index 00..4df7527205
--- /dev/null
+++ b/meta/recipes-bsp/i2cdev/i2cdev/fix-lsi2c-makefile.patch
@@ -0,0 +1,28 @@
+From 57c09727220e00ab961325a2c85f5611bd1770d6 Mon Sep 17 00:00:00 2001
+Message-Id: 
<57c09727220e00ab961325a2c85f5611bd1770d6.1701984646.git.joerg.som...@navimatix.de>
+From: =?UTF-8?q?J=C3=B6rg=20Sommer?= 
+Date: Thu, 7 Dec 2023 22:29:40 +0100
+Subject: [PATCH] lsi2c/Makefile: Use builddir to refer to libi2cdev.a
+
+Signed-off-by: Jörg Sommer 
+Upstream-Status: Submitted 
https://github.com/costad2/i2cdev/pull/2/commits/43f15e97d869797dbfeaacafa13216aaaf353426
+---
+ lsi2c/Makefile.am | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/lsi2c/Makefile.am b/lsi2c/Makefile.am
+index 6defc1f..0d81d01 100644
+--- a/lsi2c/Makefile.am
 b/lsi2c/Makefile.am
+@@ -14,7 +14,7 @@ bin_PROGRAMS=lsi2c
+ lsi2c_SOURCES = lsi2c.c
+ 
+ # Linker options for lsi2c
+-lsi2c_LDADD = $(top_srcdir)/libi2cdev/libi2cdev.a
++lsi2c_LDADD = $(top_builddir)/libi2cdev/libi2cdev.a
+ 
+ # Compiler options for lsi2c
+ lsi2c_CFLAGS = -I$(top_srcdir)/include -std=c99 -fPIC
+-- 
+2.34.1
+
diff --git a/meta/recipes-bsp/i2cdev/i2cdev_git.bb 
b/meta/recipes-bsp/i2cdev/i2cdev_git.bb
new file mode 100644
index 00..b1f8a7f805
--- /dev/null
+++ b/meta/recipes-bsp/i2cdev/i2cdev_git.bb
@@ -0,0 +1,26 @@
+SUMMARY = "i2c dev tools for Linux"
+DESCRIPTION = "\
+This package contains an I2C dev library and the i2c bus scanning \
+utility lsi2c. \
+"
+AUTHOR = "Danielle Costantino"
+HOMEPAGE = "https://github.com/costad2/i2cdev;
+LICENSE = "GPL-2.0-or-later"
+LIC_FILES_CHKSUM = "\
+file://COPYING;md5=768997ba510a952bef1775c50bc22b00 \
+
file://include/libi2cdev.h;beginline=12;endline=25;md5=72486a5e192d6ac5c7e55a4a95e380a6
 \
+
file://libi2cdev/smbus.c;beginline=9;endline=22;md5=d9a0de5a611b960fa75912ded6c60096
 \
+
file://lsi2c/lsi2c.c;beginline=11;endline=24;md5=72486a5e192d6ac5c7e55a4a95e380a6
 \
+"
+
+PR = "git${SRCPV}"
+
+SRC_URI = "\
+git://github.com/costad2/i2cdev.git;protocol=https;branch=master \
+file://fix-lsi2c-makefile.patch \
+"
+SRCREV = "ed9ad777d842880e7ac6ca5e0de4bd2d3b4d02dc"
+
+S = "${WORKDIR}/git"
+
+inherit autotools
-- 
2.34.1


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

Re: [arch-general] pcmanfm-gtk3 no longer working on wayland?

[Genes Lists]

On Tue, 2023-12-26 at 22:02 -0600, Javier wrote:
> Hi !
> 
> pcmanfm-gtk3 is segfaulting on wayland when trying to access any
> directory.  I don't know if others are experiencing the same.  The
> alternative I've been using is thunar, though I really liked pcmanfm-
> gtk3.
> 

I don't use this but I see that the last source code update was 5 years
ago [1] - maybe its time to move to something else that is being more
actively maintained?

gene

[1]  https://github.com/lxde/pcmanfm/tree/master/src

Re: [gentoo-user] Virtualbox 7

[Wols Lists]

On 21/12/2023 05:48, the...@sys-concept.com wrote:
I run Windows 7 in VirualBox-6 and it runs relatively fast but after 
upgrade to VirtualBox-7 (7.0.10) I noticed
users weren't able to access Windows-7 server; the network got almost 
non responsive.  I've notice same with earlier VirtualBox-7.0.8 (something)

I've found many post complaining about similar problems with VirtualBox-7

What changes did they introduced in VirtualBox-7 that make it unusable?


If it ran reasonably fast, well, think yourself unusual.

I run XP, and although I've got a Win7 box, I never run it, it always 
felt dreadfully slow - and that's going back years. I doubt they've 
changed anything, it wouldn't surprise me if it's a default config. I 
don't tend to dig in to that, so I wouldn't know what to change.


Plus, of course, changing things tends to break Windows' authentication :-(

Cheers,
Wol44

Re: Post (snap) update emails: fsck errors and (in)security output

[Why 42? The lists account.]

On Wed, Dec 20, 2023 at 10:57:41AM -0500, Nick Holland wrote:
> the ROOTBACKUP process is making an image of a live file system; fsck
> grumblings ARE expected.  It's just one of those things you aren't supposed
> to do (but I do it regularly, because normally, you can get away with it).
> 
> Why the files it is grumbling about are owned by you ... that is a puzzle.
> Is your /tmp on a separate partition?  If so, it shouldn't be being backed
> up by the ROOTBACKUP process.  Same for "home" or any other file system you
> have access write to.

Interesting ... unexpectedly /tmp _is_ part of the root filesystem.

I have an entry in fstab to mount it as a seperate mfs filesystem but
that has failed for some reason. Probably then this is the reason that
the fsck errors are now occurring, being reported, and that I noticed
them.

Previously, when /tmp was transient, the root filesystem and the altroot
fsck process were not affected by content in /tmp.

Just tried the mount of /tmp manually from the command line at got:
mount_mfs: mmap: Cannot allocate memory

When I halved the size (memory) allocated (-s=2097152) it mounts
successfully:
mjoelnir:robb 20.12 19:50:02 # df -h /tmp
Filesystem SizeUsed   Avail Capacity  Mounted on
mfs:75507  1.9G1.0K1.8G 1%/tmp

Strange that it used to work. One day (!) I'll re-partition and allocate
a partition/slice of "real" storage to /tmp instead of using mfs.


> I also see this:
> > Backing up root=/dev/rsd1a to /dev/rsd0a:
> is sd1a actually your root, and sd0a actually your altroot?
 
> > Second question: Also after an upgrade, the "daily insecurity output"
> > contains a huge amount of setuid changes e.g.
> > ...
> > What actually changed then?
> 
> The files.

Aha! - I see. I had in my head somehow understood "Setuid changes:" to
mean "changes to the setuid flags/bits of these files ...", not "these
files are suid and their content has changed". Maybe that is a better
description.

> (and yes, I have seen events where a major upgrade caused a lot of noise in
> a "something changed" file...which unfortunately hid something we needed to
> know about ALSO happened, and was dismissed as "part of the upgrade noise".
> This wasn't OpenBSD nor was it a "security event", but it did delay the
> detection and repair of a redundancy failure issue because one line was
> missed in a sea of thousands of lines of "yeah, that's expected" noise.)

It is a fair bit of noise in this case ... even more so with the
following "Block device changes" and the even longer "rpki" related
section.

Thanks!

Cheers,
Robb.

Re: XFCE Thunar filemanager core dumps ...

[Why 42? The lists account.]

On Wed, Dec 20, 2023 at 03:23:52PM -, Stuart Henderson wrote:
> > ...
> > When I started gdb (no expert) I noticed this "Dwarf error":
> > mjoelnir:/tmp 20.12 12:04:38 % gdb -e /usr/local/bin/Thunar -c thunar.core
> > GNU gdb 6.3
> 
> https://www.openbsd.org/faq/ports/ports.html#Backtrace

Thanks. What I understood from there then was to install the debug
package and run egdb + "bt". Hopefully that's what you had in mind.
Here's the resulting stack trace, the "optimized out" sounds a bit
worrying :-):

(gdb) bt
#0  0x084822eb0565 in g_node_traverse_pre_order () from 
/usr/local/lib/libglib-2.0.so.4201.11
#1  0x084822eb0577 in g_node_traverse_pre_order () from 
/usr/local/lib/libglib-2.0.so.4201.11
#2  0x084822eb0577 in g_node_traverse_pre_order () from 
/usr/local/lib/libglib-2.0.so.4201.11
#3  0x084570b35046 in thunar_tree_view_set_show_hidden (view=0x848252483c0, 
show_hidden=) at thunar-tree-view.c:1990
#4  thunar_tree_view_set_property (object=0x848252483c0, prop_id=, value=, pspec=) at thunar-tree-view.c:509
#5  0x084827e3c82a in object_set_property () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#6  0x084827e3c5a8 in g_object_setv () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#7  0x084827e3d94b in g_object_set_property () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#8  0x084827e2cf19 in on_source_notify () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#9  0x084827e3442b in g_closure_invoke () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#10 0x084827e50f4c in signal_emit_unlocked_R.123 () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#11 0x084827e4ebab in signal_emit_valist_unlocked () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#12 0x084827e4f39f in g_signal_emit () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#13 0x084827e40a53 in g_object_dispatch_properties_changed () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#14 0x084827e3ae1c in g_object_notify_by_spec_internal () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#15 0x084570b43c07 in thunar_window_action_show_hidden 
(window=0x848393b6760) at thunar-window.c:4727
#16 0x0847e652dc4e in _gtk_marshal_BOOLEAN__OBJECT_UINT_FLAGS () from 
/usr/local/lib/libgtk-3.so.2201.0
#17 0x084827e3442b in g_closure_invoke () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#18 0x084827e4ff6d in signal_emit_unlocked_R () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#19 0x084827e4ec0f in signal_emit_valist_unlocked () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#20 0x084827e4f39f in g_signal_emit () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#21 0x0847e65498d2 in gtk_accel_group_activate () from 
/usr/local/lib/libgtk-3.so.2201.0
#22 0x0847e6549a24 in gtk_accel_groups_activate () from 
/usr/local/lib/libgtk-3.so.2201.0
#23 0x0847e686e048 in gtk_window_activate_key () from 
/usr/local/lib/libgtk-3.so.2201.0
#24 0x0847e6874325 in gtk_window_key_press_event () from 
/usr/local/lib/libgtk-3.so.2201.0
#25 0x0847e652ceb0 in _gtk_marshal_BOOLEAN__BOXED () from 
/usr/local/lib/libgtk-3.so.2201.0
#26 0x084827e3442b in g_closure_invoke () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#27 0x084827e50100 in signal_emit_unlocked_R () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#28 0x084827e4ec0f in signal_emit_valist_unlocked () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#29 0x084827e4f39f in g_signal_emit () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#30 0x0847e684e22a in gtk_widget_event_internal () from 
/usr/local/lib/libgtk-3.so.2201.0
#31 0x0847e66ce1cf in gtk_propagate_event () from 
/usr/local/lib/libgtk-3.so.2201.0
#32 0x0847e66cdbe1 in gtk_main_do_event () from 
/usr/local/lib/libgtk-3.so.2201.0
#33 0x08477220a65b in _gdk_event_emit () from 
/usr/local/lib/libgdk-3.so.2201.1
#34 0x084772263c88 in gdk_event_source_dispatch () from 
/usr/local/lib/libgdk-3.so.2201.1
#35 0x084822ea320d in g_main_context_dispatch_unlocked () from 
/usr/local/lib/libglib-2.0.so.4201.11
#36 0x084822ea35ec in g_main_context_iterate_unlocked () from 
/usr/local/lib/libglib-2.0.so.4201.11
#37 0x084822ea369b in g_main_context_iteration () from 
/usr/local/lib/libglib-2.0.so.4201.11
#38 0x0847e42d987d in g_application_run () from 
/usr/local/lib/libgio-2.0.so.4200.18
#39 0x084570acf399 in main (argc=1, argv=0x7ee77838c528) at main.c:86


mjoelnir:robb 20.12 18:42:54 # pkg_info | grep thunar
debug-thunar-4.18.8 debug info for thunar
thunar-4.18.8   Xfce4 file manager
thunar-archive-0.5.2 Thunar archive plugin
thunar-media-tags-0.4.0 Thunar media tags plugin

Re: [PATCH 2/2] arm: Add support for MVE Tail-Predicated Low Overhead Loops

[Andre Vieira (lists)]

Squashed the definition and changes to predicated_doloop_end_internal 
and dlstp*_insn into this patch to make sure the first patch builds 
independently


On 18/12/2023 11:53, Andre Vieira wrote:


Reworked Stam's patch after comments in:
https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640362.html

The original gcc ChangeLog remains unchanged, but I did split up some tests so
here is the testsuite ChangeLog.


gcc/testsuite/ChangeLog:

* gcc.target/arm/lob.h: Update framework.
* gcc.target/arm/lob1.c: Likewise.
* gcc.target/arm/lob6.c: Likewise.
* gcc.target/arm/mve/dlstp-compile-asm.c: New test.
* gcc.target/arm/mve/dlstp-int16x8.c: New test.
* gcc.target/arm/mve/dlstp-int16x8-run.c: New test.
* gcc.target/arm/mve/dlstp-int32x4.c: New test.
* gcc.target/arm/mve/dlstp-int32x4-run.c: New test.
* gcc.target/arm/mve/dlstp-int64x2.c: New test.
* gcc.target/arm/mve/dlstp-int64x2-run.c: New test.
* gcc.target/arm/mve/dlstp-int8x16.c: New test.
* gcc.target/arm/mve/dlstp-int8x16-run.c: New test.
* gcc.target/arm/mve/dlstp-invalid-asm.c: New test.
diff --git a/gcc/config/arm/arm-protos.h b/gcc/config/arm/arm-protos.h
index 
2f5ca79ed8ddd647b212782a0454ee4fefc07257..4f164c547406c43219900c111401540c7ef9d7d1
 100644
--- a/gcc/config/arm/arm-protos.h
+++ b/gcc/config/arm/arm-protos.h
@@ -65,8 +65,8 @@ extern void arm_emit_speculation_barrier_function (void);
 extern void arm_decompose_di_binop (rtx, rtx, rtx *, rtx *, rtx *, rtx *);
 extern bool arm_q_bit_access (void);
 extern bool arm_ge_bits_access (void);
-extern bool arm_target_insn_ok_for_lob (rtx);
-
+extern bool arm_target_bb_ok_for_lob (basic_block);
+extern rtx arm_attempt_dlstp_transform (rtx);
 #ifdef RTX_CODE
 enum reg_class
 arm_mode_base_reg_class (machine_mode);
diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc
index 
0c0cb14a8a4f043357b8acd7042a9f9386af1eb1..1ee72bcb7ec4bea5feea8453ceef7702b0088a73
 100644
--- a/gcc/config/arm/arm.cc
+++ b/gcc/config/arm/arm.cc
@@ -668,6 +668,12 @@ static const scoped_attribute_specs *const 
arm_attribute_table[] =
 #undef TARGET_HAVE_CONDITIONAL_EXECUTION
 #define TARGET_HAVE_CONDITIONAL_EXECUTION arm_have_conditional_execution
 
+#undef TARGET_LOOP_UNROLL_ADJUST
+#define TARGET_LOOP_UNROLL_ADJUST arm_loop_unroll_adjust
+
+#undef TARGET_PREDICT_DOLOOP_P
+#define TARGET_PREDICT_DOLOOP_P arm_predict_doloop_p
+
 #undef TARGET_LEGITIMATE_CONSTANT_P
 #define TARGET_LEGITIMATE_CONSTANT_P arm_legitimate_constant_p
 
@@ -34483,19 +34489,1147 @@ arm_invalid_within_doloop (const rtx_insn *insn)
 }
 
 bool
-arm_target_insn_ok_for_lob (rtx insn)
+arm_target_bb_ok_for_lob (basic_block bb)
 {
-  basic_block bb = BLOCK_FOR_INSN (insn);
   /* Make sure the basic block of the target insn is a simple latch
  having as single predecessor and successor the body of the loop
  itself.  Only simple loops with a single basic block as body are
  supported for 'low over head loop' making sure that LE target is
  above LE itself in the generated code.  */
-
   return single_succ_p (bb)
-&& single_pred_p (bb)
-&& single_succ_edge (bb)->dest == single_pred_edge (bb)->src
-&& contains_no_active_insn_p (bb);
+&& single_pred_p (bb)
+&& single_succ_edge (bb)->dest == single_pred_edge (bb)->src;
+}
+
+/* Utility fuction: Given a VCTP or a VCTP_M insn, return the number of MVE
+   lanes based on the machine mode being used.  */
+
+static int
+arm_mve_get_vctp_lanes (rtx_insn *insn)
+{
+  rtx insn_set = single_set (insn);
+  if (insn_set
+  && GET_CODE (SET_SRC (insn_set)) == UNSPEC
+  && (XINT (SET_SRC (insn_set), 1) == VCTP
+ || XINT (SET_SRC (insn_set), 1) == VCTP_M))
+{
+  machine_mode mode = GET_MODE (SET_SRC (insn_set));
+  return (VECTOR_MODE_P (mode) && VALID_MVE_PRED_MODE (mode))
+? GET_MODE_NUNITS (mode) : 0;
+}
+  return 0;
+}
+
+/* Check if INSN requires the use of the VPR reg, if it does, return the
+   sub-rtx of the VPR reg.  The TYPE argument controls whether
+   this function should:
+   * For TYPE == 0, check all operands, including the OUT operands,
+ and return the first occurrence of the VPR reg.
+   * For TYPE == 1, only check the input operands.
+   * For TYPE == 2, only check the output operands.
+   (INOUT operands are considered both as input and output operands)
+*/
+static rtx
+arm_get_required_vpr_reg (rtx_insn *insn, unsigned int type = 0)
+{
+  gcc_assert (type < 3);
+  if (!NONJUMP_INSN_P (insn))
+return NULL_RTX;
+
+  bool requires_vpr;
+  extract_constrain_insn (insn);
+  int n_operands = recog_data.n_operands;
+  if (recog_data.n_alternatives == 0)
+return NULL_RTX;
+
+  /* Fill in recog_op_alt with information about the constraints of
+ this insn.  */
+  preprocess_constraints (insn);
+
+  for (int op = 0; op < n_operands; op++)
+{
+  requires_vpr = true;
+  if (type == 1 && 

Re: [PATCH 1/2] arm: Add define_attr to to create a mapping between MVE predicated and unpredicated insns

[Andre Vieira (lists)]

Reworked patch after Richard's comments and moved 
predicated_doloop_end_internal and dlstp*_insn to the next patch in the 
series to make sure this one builds on its own.


On 18/12/2023 11:53, Andre Vieira wrote:


Re-sending Stam's first patch, same as:
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635301.html

Hopefully patchworks can pick this up :)
diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
index 
a9c2752c0ea5ecd4597ded254e9426753ac0a098..f0b01b7461f883994a0be137cb6cbf079d54618b
 100644
--- a/gcc/config/arm/arm.h
+++ b/gcc/config/arm/arm.h
@@ -2375,6 +2375,21 @@ extern int making_const_table;
   else if (TARGET_THUMB1)  \
 thumb1_final_prescan_insn (INSN)
 
+/* These defines are useful to refer to the value of the mve_unpredicated_insn
+   insn attribute.  Note that, because these use the get_attr_* function, these
+   will change recog_data if (INSN) isn't current_insn.  */
+#define MVE_VPT_PREDICABLE_INSN_P(INSN)
\
+  (recog_memoized (INSN) >= 0  \
+   && get_attr_mve_unpredicated_insn (INSN) != CODE_FOR_nothing)
+
+#define MVE_VPT_PREDICATED_INSN_P(INSN)
\
+  (MVE_VPT_PREDICABLE_INSN_P (INSN)\
+   && recog_memoized (INSN) != get_attr_mve_unpredicated_insn (INSN))
+
+#define MVE_VPT_UNPREDICATED_INSN_P(INSN)  \
+  (MVE_VPT_PREDICABLE_INSN_P (INSN)\
+   && recog_memoized (INSN) == get_attr_mve_unpredicated_insn (INSN))
+
 #define ARM_SIGN_EXTEND(x)  ((HOST_WIDE_INT)   \
   (HOST_BITS_PER_WIDE_INT <= 32 ? (unsigned HOST_WIDE_INT) (x) \
: unsigned HOST_WIDE_INT)(x)) & (unsigned HOST_WIDE_INT) 0x) |\
diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
index 
07eaf06cdeace750fe1c7d399deb833ef5fc2b66..296212be33ffe6397b05491d8854d2a59f7c54df
 100644
--- a/gcc/config/arm/arm.md
+++ b/gcc/config/arm/arm.md
@@ -124,6 +124,12 @@ (define_attr "fpu" "none,vfp"
 ; and not all ARM insns do.
 (define_attr "predicated" "yes,no" (const_string "no"))
 
+; An attribute that encodes the CODE_FOR_ of the MVE VPT unpredicated
+; version of a VPT-predicated instruction.  For unpredicated instructions
+; that are predicable, encode the same pattern's CODE_FOR_ as a way to
+; encode that it is a predicable instruction.
+(define_attr "mve_unpredicated_insn" "" (symbol_ref "CODE_FOR_nothing"))
+
 ; LENGTH of an instruction (in bytes)
 (define_attr "length" ""
   (const_int 4))
diff --git a/gcc/config/arm/iterators.md b/gcc/config/arm/iterators.md
index 
a980353810166312d5bdfc8ad58b2825c910d0a0..5ea2d9e866891bdb3dc73fcf6cbd6cdd2f989951
 100644
--- a/gcc/config/arm/iterators.md
+++ b/gcc/config/arm/iterators.md
@@ -2305,6 +2305,7 @@ (define_int_attr simd32_op [(UNSPEC_QADD8 "qadd8") 
(UNSPEC_QSUB8 "qsub8")
 
 (define_int_attr mmla_sfx [(UNSPEC_MATMUL_S "s8") (UNSPEC_MATMUL_U "u8")
   (UNSPEC_MATMUL_US "s8")])
+
 ;;MVE int attribute.
 (define_int_attr supf [(VCVTQ_TO_F_S "s") (VCVTQ_TO_F_U "u") (VREV16Q_S "s")
   (VREV16Q_U "u") (VMVNQ_N_S "s") (VMVNQ_N_U "u")
diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md
index 
b0d3443da9cee991193d390200738290806a1e69..b1862d7977e91605cd971e634105bed3fa6e75cb
 100644
--- a/gcc/config/arm/mve.md
+++ b/gcc/config/arm/mve.md
@@ -17,7 +17,7 @@
 ;; along with GCC; see the file COPYING3.  If not see
 ;; .
 
-(define_insn "*mve_mov"
+(define_insn "mve_mov"
   [(set (match_operand:MVE_types 0 "nonimmediate_operand" "=w,w,r,w   , w,   
r,Ux,w")
(match_operand:MVE_types 1 "general_operand"  " 
w,r,w,DnDm,UxUi,r,w, Ul"))]
   "TARGET_HAVE_MVE || TARGET_HAVE_MVE_FLOAT"
@@ -81,18 +81,27 @@ (define_insn "*mve_mov"
   return "";
 }
 }
-  [(set_attr "type" 
"mve_move,mve_move,mve_move,mve_move,mve_load,multiple,mve_store,mve_load")
+   [(set_attr_alternative "mve_unpredicated_insn" [(symbol_ref 
"CODE_FOR_mve_mov")
+  (symbol_ref 
"CODE_FOR_nothing")
+  (symbol_ref 
"CODE_FOR_nothing")
+  (symbol_ref 
"CODE_FOR_mve_mov")
+  (symbol_ref 
"CODE_FOR_mve_mov")
+  (symbol_ref 
"CODE_FOR_nothing")
+  (symbol_ref 
"CODE_FOR_mve_mov")
+  (symbol_ref 
"CODE_FOR_nothing")])
+   (set_attr "type" 
"mve_move,mve_move,mve_move,mve_move,mve_load,multiple,mve_store,mve_load")
(set_attr "length" "4,8,8,4,4,8,4,8")
(set_attr "thumb2_pool_range" "*,*,*,*,1018,*,*,*")
(set_attr "neg_pool_range" "*,*,*,*,996,*,*,*")])
 
-(define_insn "*mve_vdup"
+(define_insn "mve_vdup"
   

omp: Fix simdclone arguments with veclen lower than simdlen [PR113040]

[Andre Vieira (lists)]

This patch fixes an issue introduced by:
commit ea4a3d08f11a59319df7b750a955ac613a3f438a
Author: Andre Vieira 
Date:   Wed Nov 1 17:02:41 2023 +

omp: Reorder call for TARGET_SIMD_CLONE_ADJUST

The problem was that after this patch we no longer added multiple 
arguments for vector arguments where the veclen was lower than the simdlen.


gcc/ChangeLog:

* omp-simd-clone.cc (simd_clone_adjust_argument_types): Add multiple
vector arguments where simdlen is larger than veclen.

Bootstrapped and regression tested on x86_64-pc-linux-gnu and 
aarch64-unknown-linux-gnu.


OK for trunk?

PS: struggling to add a testcase for this, the dumps don't show the 
simdclone prototype and I can't easily create a run-test for this as it 
requires glibc.  Only option is a very flaky assembly scan test to see 
if it's writing to ymm4 (i.e. it is passing enough parameters), but I 
haven't because I don't think that's a good idea.
PPS: maybe we ought to print the simdclone prototype when passing 
-fdump-ipa-simdclone ?diff --git a/gcc/omp-simd-clone.cc b/gcc/omp-simd-clone.cc
index 
3fbe428125243bc02bd58f6e50ac773e8df8..5151fef3bcdaa76802184df43ba13b8709645fd4
 100644
--- a/gcc/omp-simd-clone.cc
+++ b/gcc/omp-simd-clone.cc
@@ -781,6 +781,7 @@ simd_clone_adjust_argument_types (struct cgraph_node *node)
   struct cgraph_simd_clone *sc = node->simdclone;
   unsigned i, k;
   poly_uint64 veclen;
+  auto_vec new_params;
 
   for (i = 0; i < sc->nargs; ++i)
 {
@@ -798,9 +799,11 @@ simd_clone_adjust_argument_types (struct cgraph_node *node)
   switch (sc->args[i].arg_type)
{
default:
+ new_params.safe_push (parm_type);
  break;
case SIMD_CLONE_ARG_TYPE_LINEAR_UVAL_CONSTANT_STEP:
case SIMD_CLONE_ARG_TYPE_LINEAR_UVAL_VARIABLE_STEP:
+ new_params.safe_push (parm_type);
  if (node->definition)
sc->args[i].simd_array
  = create_tmp_simd_array (IDENTIFIER_POINTER (DECL_NAME (parm)),
@@ -828,6 +831,9 @@ simd_clone_adjust_argument_types (struct cgraph_node *node)
  else
vtype = build_vector_type (parm_type, veclen);
  sc->args[i].vector_type = vtype;
+ k = vector_unroll_factor (sc->simdlen, veclen);
+ for (unsigned j = 0; j < k; j++)
+   new_params.safe_push (vtype);
 
  if (node->definition)
sc->args[i].simd_array
@@ -893,22 +899,8 @@ simd_clone_adjust_argument_types (struct cgraph_node *node)
last_parm_void = true;
 
   gcc_assert (TYPE_ARG_TYPES (TREE_TYPE (node->decl)));
-  for (i = 0; i < sc->nargs; i++)
-   {
- tree ptype;
- switch (sc->args[i].arg_type)
-   {
-   default:
- ptype = sc->args[i].orig_type;
- break;
-   case SIMD_CLONE_ARG_TYPE_LINEAR_VAL_CONSTANT_STEP:
-   case SIMD_CLONE_ARG_TYPE_LINEAR_VAL_VARIABLE_STEP:
-   case SIMD_CLONE_ARG_TYPE_VECTOR:
- ptype = sc->args[i].vector_type;
- break;
-   }
- new_arg_types = tree_cons (NULL_TREE, ptype, new_arg_types);
-   }
+  for (i = 0; i < new_params.length (); i++)
+   new_arg_types = tree_cons (NULL_TREE, new_params[i], new_arg_types);
   new_reversed = nreverse (new_arg_types);
   if (last_parm_void)
{

Re: veclower: improve selection of vector mode when lowering [PR 112787]

[Andre Vieira (lists)]

Thanks, fully agree with all comments.

gcc/ChangeLog:

PR target/112787
* tree-vect-generic (type_for_widest_vector_mode): Change function
to use original vector type and check widest vector mode has at 
most

the same number of elements.
(get_compute_type): Pass original vector type rather than the element
type to type_for_widest_vector_mode and remove now obsolete check
for the number of elements.

On 07/12/2023 07:45, Richard Biener wrote:

On Wed, 6 Dec 2023, Andre Vieira (lists) wrote:


Hi,

This patch addresses the issue reported in PR target/112787 by improving the
compute type selection.  We do this by not considering types with more
elements
than the type we are lowering since we'd reject such types anyway.

gcc/ChangeLog:

PR target/112787
* tree-vect-generic (type_for_widest_vector_mode): Add a parameter to
control maximum amount of elements in resulting vector mode.
(get_compute_type): Restrict vector_compute_type to a mode no wider
than the original compute type.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/pr112787.c: New test.

Bootstrapped and regression tested on aarch64-unknown-linux-gnu and
x86_64-pc-linux-gnu.

Is this OK for trunk?


@@ -1347,7 +1347,7 @@ optimize_vector_constructor (gimple_stmt_iterator
*gsi)
 TYPE, or NULL_TREE if none is found.  */

Can you improve the function comment?  It also doesn't mention OP ...

  static tree
-type_for_widest_vector_mode (tree type, optab op)
+type_for_widest_vector_mode (tree type, optab op, poly_int64 max_nunits =
0)
  {
machine_mode inner_mode = TYPE_MODE (type);
machine_mode best_mode = VOIDmode, mode;
@@ -1371,7 +1371,9 @@ type_for_widest_vector_mode (tree type, optab op)
FOR_EACH_MODE_FROM (mode, mode)
  if (GET_MODE_INNER (mode) == inner_mode
 && maybe_gt (GET_MODE_NUNITS (mode), best_nunits)
-   && optab_handler (op, mode) != CODE_FOR_nothing)
+   && optab_handler (op, mode) != CODE_FOR_nothing
+   && (known_eq (max_nunits, 0)
+   || known_lt (GET_MODE_NUNITS (mode), max_nunits)))

max_nunits suggests that known_le would be appropriate instead.

I see the only other caller with similar "problems":

 }
   /* Can't use get_compute_type here, as supportable_convert_operation
  doesn't necessarily use an optab and needs two arguments.  */
   tree vec_compute_type
 = type_for_widest_vector_mode (TREE_TYPE (arg_type), mov_optab);
   if (vec_compute_type
   && VECTOR_MODE_P (TYPE_MODE (vec_compute_type))
   && subparts_gt (arg_type, vec_compute_type))

so please do not default to 0 but adjust this one as well.  It also
seems you then can remove the subparts_gt guards on both
vec_compute_type uses.

I think the API would be cleaner if we'd pass the original vector type
we can then extract TYPE_VECTOR_SUBPARTS from, avoiding the extra arg.

No?

Thanks,
Richard.diff --git a/gcc/testsuite/gcc.target/aarch64/pr112787.c 
b/gcc/testsuite/gcc.target/aarch64/pr112787.c
new file mode 100644
index 
..caca1bf7ef447e4489b2c134d7200a4afd16763f
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/pr112787.c
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-O2 -march=armv8-a+sve -mcpu=neoverse-n2" } */
+
+typedef int __attribute__((__vector_size__ (64))) vec;
+
+vec fn (vec a, vec b)
+{
+  return a + b;
+}
+
+/* { dg-final { scan-assembler-times {add\tv[0-9]+} 4 } } */
diff --git a/gcc/tree-vect-generic.cc b/gcc/tree-vect-generic.cc
index 
a7e6cb87a5e31e3dd2a893ea5652eeebf8d5d214..c906eb3521ea01fd2bdfc89c3476d02c555cf8cc
 100644
--- a/gcc/tree-vect-generic.cc
+++ b/gcc/tree-vect-generic.cc
@@ -1343,12 +1343,16 @@ optimize_vector_constructor (gimple_stmt_iterator *gsi)
   gsi_replace (gsi, g, false);
 }
 
-/* Return a type for the widest vector mode whose components are of type
-   TYPE, or NULL_TREE if none is found.  */
+/* Return a type for the widest vector mode with the same element type as
+   type ORIGINAL_VECTOR_TYPE, with at most the same number of elements as type
+   ORIGINAL_VECTOR_TYPE and that is supported by the target for an operation
+   with optab OP, or return NULL_TREE if none is found.  */
 
 static tree
-type_for_widest_vector_mode (tree type, optab op)
+type_for_widest_vector_mode (tree original_vector_type, optab op)
 {
+  gcc_assert (VECTOR_TYPE_P (original_vector_type));
+  tree type = TREE_TYPE (original_vector_type);
   machine_mode inner_mode = TYPE_MODE (type);
   machine_mode best_mode = VOIDmode, mode;
   poly_int64 best_nunits = 0;
@@ -1371,7 +1375,9 @@ type_for_widest_vector_mode (tree type, optab op)
   FOR_EACH_MODE_FROM (mode, mode)
 if (GET_MODE_INNER (mode) == inner_mode
&& maybe_gt (GET_MODE_NUNITS (mode), best_nunits)
-   && optab_handler (op

Re: What is the plan for dhcpd/kea?

[Genes Lists]

On Tue, 2023-12-19 at 16:17 -0600, David C. Rankin wrote:
> > 
> 
> Yes, hopefully ISC made is fairly compatible and straight-forward to 
> transition, but holy cow, 2G for kea-docs?
> 


The doc package includes both administrator and developer docs.
The docs are quite extensive.

You can see the admin docs online too (skip to chapter 4)

     https://kea.readthedocs.io/en/kea-2.4.1/

gene

XFCE Thunar filemanager core dumps ...

[Why 42? The lists account.]

Hi All,

I'm running XFCE on OpenBSD 7.4 GENERIC.MP#1535 amd64

I pressed Control+h in thunar thinking that it would toggle the display
of hidden files ( .dot files), but instead thunar core dumps:
-rw---   1 robb  robb   20656304 Dec 19 21:02 thunar.core

Would this be an OpenBSD (porting) issue, or something upstream?

I don't see this behaviour on an adjacent Linux system (different
versions of XFCE though). I have these versions:
xfce-4.18.1 Xfce desktop meta-package (base installation)
thunar-4.18.8   Xfce4 file manager

When I started gdb (no expert) I noticed this "Dwarf error":
mjoelnir:/tmp 20.12 12:04:38 % gdb -e /usr/local/bin/Thunar -c thunar.core
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-unknown-openbsd7.4".
Core was generated by `thunar'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libpthread.so.27.1...done.
Loaded symbols for /usr/lib/libpthread.so.27.1
Loaded symbols for /usr/local/bin/Thunar
Reading symbols from /usr/local/lib/libthunarx-3.so.0.1...done.
Loaded symbols for /usr/local/lib/libthunarx-3.so.0.1
...
Reading symbols from /usr/libexec/ld.so...Error while reading shared library 
symbols:
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in 
module /usr/libexec/ld.so]


Here is some other output, perhaps relevant ...

Where:
(gdb) where
#0  0x0570de714565 in g_node_traverse_pre_order () from 
/usr/local/lib/libglib-2.0.so.4201.11
#1  0x0570de714577 in g_node_traverse_pre_order () from 
/usr/local/lib/libglib-2.0.so.4201.11
#2  0x0570de714577 in g_node_traverse_pre_order () from 
/usr/local/lib/libglib-2.0.so.4201.11
#3  0x056ec2b50046 in thunar_tree_view_set_property () from 
/usr/local/bin/Thunar
#4  0x05711845582a in object_set_property () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#5  0x0571184555a8 in g_object_setv () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#6  0x05711845694b in g_object_set_property () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#7  0x057118445f19 in on_source_notify () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#8  0x05711844d42b in g_closure_invoke () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#9  0x057118469f4c in signal_emit_unlocked_R.123 () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#10 0x057118467bab in signal_emit_valist_unlocked () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#11 0x05711846839f in g_signal_emit () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#12 0x057118459a53 in g_object_dispatch_properties_changed () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#13 0x057118453e1c in g_object_notify_by_spec_internal () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#14 0x056ec2b5ec07 in thunar_window_action_show_hidden () from 
/usr/local/bin/Thunar
#15 0x0571c0afdc4e in _gtk_marshal_BOOLEAN__OBJECT_UINT_FLAGS () from 
/usr/local/lib/libgtk-3.so.2201.0
#16 0x05711844d42b in g_closure_invoke () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#17 0x057118468f6d in signal_emit_unlocked_R () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#18 0x057118467c0f in signal_emit_valist_unlocked () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#19 0x05711846839f in g_signal_emit () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#20 0x0571c0b198d2 in gtk_accel_group_activate () from 
/usr/local/lib/libgtk-3.so.2201.0
#21 0x0571c0b19a24 in gtk_accel_groups_activate () from 
/usr/local/lib/libgtk-3.so.2201.0
#22 0x0571c0e3e048 in gtk_window_activate_key () from 
/usr/local/lib/libgtk-3.so.2201.0
#23 0x0571c0e44325 in gtk_window_key_press_event () from 
/usr/local/lib/libgtk-3.so.2201.0
#24 0x0571c0afceb0 in _gtk_marshal_BOOLEAN__BOXED () from 
/usr/local/lib/libgtk-3.so.2201.0
#25 0x05711844d42b in g_closure_invoke () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#26 0x057118469100 in signal_emit_unlocked_R () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#27 0x057118467c0f in signal_emit_valist_unlocked () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#28 0x05711846839f in g_signal_emit () from 
/usr/local/lib/libgobject-2.0.so.4200.18
#29 0x0571c0e1e22a in gtk_widget_event_internal () from 
/usr/local/lib/libgtk-3.so.2201.0
#30 0x0571c0c9e1cf in gtk_propagate_event () from 
/usr/local/lib/libgtk-3.so.2201.0
#31 0x0571c0c9dbe1 in gtk_main_do_event () from 
/usr/local/lib/libgtk-3.so.2201.0
#32 0x0571359bd65b in _gdk_event_emit () from 
/usr/local/lib/libgdk-3.so.2201.1
#33 0x057135a16c88 in gdk_event_source_dispatch () from 
/usr/local/lib/libgdk-3.so.2201.1
#34 0x0570de70720d in 

Post (snap) update emails: fsck errors and (in)security output

[Why 42? The lists account.]

...
Reply-To: 

Hi All,

A couple of questions ...

I have "ROOTBACKUP=1" in /etc/daily.local to replicate my root partition
as described in the FAQ (https://www.openbsd.org/faq/faq14.html#altroot)

I noticed after an update to a new snapshot via sysupgrade that the next
daily output email contains many many fsck "UNREF FILE" errors (See the
output included below). Is this expected, or is there some problem? Most
or all of the files seem to be owned by me (robb) so I'm thinking that
these errors may be related to files in /tmp ... Not sure why this occurs
though?

Second question: Also after an upgrade, the "daily insecurity output"
contains a huge amount of setuid changes e.g.
...
-r-xr-sr-x 1 root auth   21144   Nov 30 15:36:52 2023 /usr/bin/skeyinit
-r-xr-sr-x 1 root auth   21144   Dec 19 08:35:26 2023 /usr/bin/skeyinit
-r-xr-sr-x 1 root _sshagnt   440496  Nov 30 15:36:53 2023 /usr/bin/ssh-agent
-r-xr-sr-x 1 root _sshagnt   443856  Dec 19 08:35:26 2023 /usr/bin/ssh-agent
-r-sr-xr-x 1 root bin19608   Nov 30 15:36:53 2023 /usr/bin/su
-r-sr-xr-x 1 root bin19608   Dec 19 08:35:27 2023 /usr/bin/su
-r-xr-sr-x 1 root tty17936   Nov 30 15:36:54 2023 /usr/bin/wall
-r-xr-sr-x 1 root tty17936   Dec 19 08:35:28 2023 /usr/bin/wall
-r-xr-sr-x 1 root tty14184   Nov 30 15:36:55 2023 /usr/bin/write
-r-xr-sr-x 1 root tty14184   Dec 19 08:35:28 2023 /usr/bin/write
-r-xr-sr-x 4 root _token 21248   Nov 30 15:36:44 2023 
/usr/libexec/auth/login_activ
-r-xr-sr-x 4 root _token 21248   Dec 19 08:35:18 2023 
/usr/libexec/auth/login_activ
...

What actually changed then?
Surely many or all of these files had the same permission bits before the
upgrade?
Maybe these files now have diffent inode numbers, after the upgrade?
Why is each filename reported twice? Are these "old" and "new" values?

Thanks in advance for any feedback!

Cheers,
Robb.


Subject: mjoelnir daily output
...
OpenBSD 7.4-current (GENERIC.MP) #1535: Tue Dec 19 00:55:53 MST 2023
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

 1:30AM  up  7:20, 7 users, load averages: 0.62, 0.44, 0.40

Backing up root=/dev/rsd1a to /dev/rsd0a:
131071+0 records in
131071+0 records out
1073733632 bytes transferred in 10.509 secs (102169077 bytes/sec)
** /dev/rsd0a
** Last Mounted on /
** Phase 1 - Check Blocks and Sizes
INCORRECT BLOCK COUNT I=26656 (64 should be 32)
CORRECT? yes

INCORRECT BLOCK COUNT I=26688 (4128 should be 0)
CORRECT? yes

** Phase 2 - Check Pathnames
** Phase 3 - Check Connectivity
** Phase 4 - Check Reference Counts
UNREF FILE I=26064  OWNER=robb MODE=100600
SIZE=4 MTIME=Dec 20 01:30 2023
CLEAR? yes

UNREF FILE I=26069  OWNER=robb MODE=10640
SIZE=0 MTIME=Dec 19 19:02 2023
CLEAR? yes

UNREF FILE I=26070  OWNER=robb MODE=10640
SIZE=0 MTIME=Dec 20 01:02 2023
CLEAR? yes

UNREF FILE I=26073  OWNER=robb MODE=100600
SIZE=28672 MTIME=Dec 20 01:30 2023
CLEAR? yes
...
** Phase 5 - Check Cyl groups
FREE BLK COUNT(S) WRONG IN SUPERBLK
SALVAGE? yes

SUMMARY INFORMATION BAD
SALVAGE? yes

BLK(S) MISSING IN BIT MAPS
SALVAGE? yes

6103 files, 101471 used, 412968 free (656 frags, 51539 blocks, 0.1% 
fragmentation)

MARK FILE SYSTEM CLEAN? yes


* FILE SYSTEM WAS MODIFIED *

Re: What is the plan for dhcpd/kea?

[Genes Lists]

On Tue, 2023-12-19 at 14:19 -0600, David C. Rankin wrote
> 
>    The wiki notes the successor in the first paragraph 
> https://wiki.archlinux.org/title/Dhcpd but there is no Kea page and
> no 
> indication if Arch will start packaging Kea.

Arch has been packaging kea for quite a long time actually 

  https://archlinux.org/packages/extra/x86_64/kea/

Its also mentioned here:
 https://wiki.archlinux.org/title/Router#DNS_and_DHCP

> 
>    For those of us with long standing ISC bind/dhcpd setups what does
> the 
> future look like on Arch? Will there be a Kea at some point?
> 
I switched to kea some time back - it is a significant improvement
including having support for primary, secondary (hot spare) and backup
servers. They call it 'high availability' or HA. 

Not having a hot backup dhcp server can be pretty nasty if the one and
only server becomes unavailable for some reason. It has been working
well for me for quite some time now.

Only thing a bit ugly was the complicated / duplicative configs - in
which similar/same info needs to be provided for all 3 servers configs.
I created a little tool to generate the 3 sets of configs from a single
source file for my kea-dhcp4 servers (It's in aur) which cleaned things
up nicely.

gene

Re: [tor-relays] Dutch Relays

[lists]

On Dienstag, 19. Dezember 2023 16:23:27 CET Jordan Savoca via tor-relays 
wrote:
> On 12/18/23 6:59 AM, ab...@relayon.org 2023 wrote:
> > These are complete and utter shit.
> > 
> > avoid like the plague!
> > 
> > nifty
;-) You've landed in the sun again, I envy you.

> Oh? I'm curious to hear more about your reasons/experience, if you're
> open to sharing. They're pretty well-regarded in networking spaces.

ColoClue is nice if you have _low_ traffic and want to learn about routing 
BGP, OSPF... Artikel10 has server running there.

Christopher Sheats could ask for traffic prices at
https://serverius.net/colocation/server-colocation/

-- 
╰_╯ Ciao Marco!

Debian GNU/Linux

It's free software and it gives you freedom!

signature.asc
Description: This is a digitally signed message part.
___
tor-relays mailing list
tor-relays@lists.torproject.org
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-relays

[yocto] [meta-secutrity] tpm2-tools RDEPENDS behaviour in meta-tpm

[João Paulo Silva Gonçalves via lists . yoctoproject . org]

Hello,

For kirkstone branch when adding tpm2-tools recipe to install on a image it
will not work as it is missing tcti-device dependencies.

Is this behaviour intended or can I send a patch to master to correct
tpm2-tools recipes RDEPENDS?

Regards,
João Paulo


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

[yocto] [yocto-autobuilder-helper][PATCH v2 1/1] scripts: send_qa_email: add dry-run mode

[Alexis Lothoré via lists . yoctoproject . org]

From: Alexis Lothoré 

Add a dry-run mode to be able to run send_qa_email locally but disabling
any output (no commit or tag pushed upstream, no mail sent). This eases
all release-related debugging. This dry-run mode is enabled by the
following changes:
- add a -d/--dry-run parameter to send_qa_email
- update test_results url to allow cloning test_results repository without
  having its public key registered upstream
- skip test results storage
- do not erase test results temp dir
- skip email sending (but still generate it)

Signed-off-by: Alexis Lothoré 
---
Changes in v2:
- add missing signed-off-by

This feature is basically a translation of a "stub" commit I have been
maintaining locally for a few months. Being able to execute send_qa_email
locally is a big enabler to allow debugging autobuilder issues. The
corresponding workflow then looks like the following, when replaying
locally a failed build:
- retrieve, from autobuilder logs, the failed job layer.json (see "Write
  main layerinfo.json" step logs) and create a local copy
- retrieve release number, if it was a release job
- in the directory containing your layer.json, create tree "build/repos".
  In there, clone all components mentioned in layer.json as poky, oe-core,
  vendor metas, etc (this is how autobuilder organizes sources)
- run send_qa_email in dry run mode:
  ./scripts/send_qa_email.py -d True layer.json fakesharedrepodir \
  --url 'https://foo.bar' -p fakepublishdir -r  -R \
  faketestresultsdir

There is likely even more automation to add to this new dry-run mode, but
that's a start

Signed-off-by: Alexis Lothoré 
---
 scripts/send_qa_email.py | 55 +++-
 1 file changed, 37 insertions(+), 18 deletions(-)

diff --git a/scripts/send_qa_email.py b/scripts/send_qa_email.py
index cfbbf62a9910..f0d8aa2339b9 100755
--- a/scripts/send_qa_email.py
+++ b/scripts/send_qa_email.py
@@ -16,6 +16,7 @@ import logging
 import utils
 
 TEST_RESULTS_REPOSITORY_URL="g...@push.yoctoproject.org:yocto-testresults"
+TEST_RESULTS_DRY_RUN_REPOSITORY_URL="git://git.yoctoproject.org/yocto-testresults"
 
 def is_release_version(version):
 p = re.compile('\d{8}-\d+')
@@ -57,17 +58,17 @@ def get_previous_tag(targetrepodir, version):
 defaultbaseversion, _, _ = 
utils.get_version_from_string(subprocess.check_output(["git", "describe", 
"--abbrev=0"], cwd=targetrepodir).decode('utf-8').strip())
 return utils.get_tag_from_version(defaultbaseversion, None)
 
-def get_last_tested_rev_on_branch(branch, log):
+def get_last_tested_rev_on_branch(branch, test_results_url, log):
 # Fetch latest test results revision on corresponding branch in test
 # results repository
-tags_list = subprocess.check_output(["git", "ls-remote", "--refs", "-t", 
TEST_RESULTS_REPOSITORY_URL, "refs/tags/" + branch + 
"/*"]).decode('utf-8').strip()
+tags_list = subprocess.check_output(["git", "ls-remote", "--refs", "-t", 
test_results_url, "refs/tags/" + branch + "/*"]).decode('utf-8').strip()
 latest_test_tag=tags_list.splitlines()[-1].split()[1]
 # From test results tag, extract Poky revision
 tested_revision = re.match('refs\/tags\/.*\/\d+-g([a-f0-9]+)\/\d', 
latest_test_tag).group(1)
 log.info(f"Last tested revision on branch {branch} is {tested_revision}")
 return tested_revision
 
-def get_regression_base_and_target(targetbranch, basebranch, release, 
targetrepodir, log):
+def get_regression_base_and_target(targetbranch, basebranch, release, 
targetrepodir, test_results_url, log):
 if not targetbranch:
 # Targetbranch/basebranch is an arbitrary configuration (not defined 
in config.json): do not run regression reporting
 return None, None
@@ -80,7 +81,7 @@ def get_regression_base_and_target(targetbranch, basebranch, 
release, targetrepo
 # Basebranch/targetbranch are defined in config.json: regression
 # reporting must be done between latest test result available on base 
branch
 # and latest result on targetbranch
-latest_tested_rev_on_basebranch = 
get_last_tested_rev_on_branch(basebranch, log)
+latest_tested_rev_on_basebranch = 
get_last_tested_rev_on_branch(basebranch, test_results_url, log)
 return latest_tested_rev_on_basebranch, targetbranch
 
 #Default case: return previous tag as base
@@ -119,6 +120,9 @@ def send_qa_email():
 parser.add_argument('--url',
 action='store',
 help="The url for the build")
+parser.add_argument('-d', '--dry-run',
+action='store_true',
+help="Do not generate any commit, tag or mail: just 
simulate the release process")
 
 args = parser.parse_args()
 
@@ -136,6 +140,12 @@ def send_qa_email():
 
 repodir = os.path.dirname(args.repojson) + "/build/repos"
 
+if args.dry_run:
+log.info("Running in dry-run mode")
+test_results_url = TEST_RESULTS_DRY_RUN_REPOSITORY_URL
+else:
+ 

Re: [yocto] [yocto-autobuilder-helper][PATCH 1/1] scripts: send_qa_email: add dry-run mode

[Alexis Lothoré via lists . yoctoproject . org]

On 12/18/23 10:33, Alexis Lothoré via lists.yoctoproject.org wrote:
> From: Alexis Lothoré 
> 
> Add a dry-run mode to be able to run send_qa_email locally but disabling
> any output (no commit or tag pushed upstream, no mail sent). This eases
> all release-related debugging. This dry-run mode is enabled by the
> following changes:
> - add a -d/--dry-run parameter to send_qa_email
> - update test_results url to allow cloning test_results repository without
>   having its public key registered upstream
> - skip test results storage
> - do not erase test results temp dir
> - skip email sending (but still generate it)

I somehow messed-up my patch formatting and signed-off-by got lost. Please
discard this version, I will send a v2.

Kind regards,

Alexis

-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


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

[yocto] [yocto-autobuilder-helper][PATCH 1/1] scripts: send_qa_email: add dry-run mode

[Alexis Lothoré via lists . yoctoproject . org]

From: Alexis Lothoré 

Add a dry-run mode to be able to run send_qa_email locally but disabling
any output (no commit or tag pushed upstream, no mail sent). This eases
all release-related debugging. This dry-run mode is enabled by the
following changes:
- add a -d/--dry-run parameter to send_qa_email
- update test_results url to allow cloning test_results repository without
  having its public key registered upstream
- skip test results storage
- do not erase test results temp dir
- skip email sending (but still generate it)
---
This feature is basically a translation of a "stub" commit I have been
maintaining locally for a few months. Being able to execute send_qa_email
locally is a big enabler to allow debugging autobuilder issues. The
corresponding workflow then looks like the following, when replaying
locally a failed build:
- retrieve, from autobuilder logs, the failed job layer.json (see "Write
  main layerinfo.json" step logs) and create a local copy
- retrieve release number, if it was a release job
- in the directory containing your layer.json, create tree "build/repos".
  In there, clone all components mentioned in layer.json as poky, oe-core,
  vendor metas, etc (this is how autobuilder organizes sources)
- run send_qa_email in dry run mode:
  ./scripts/send_qa_email.py -d True layer.json fakesharedrepodir \
  --url 'https://foo.bar' -p fakepublishdir -r  -R \
  faketestresultsdir

There is likely even more automation to add to this new dry-run mode, but
that's a start
---
 scripts/send_qa_email.py | 55 +++-
 1 file changed, 37 insertions(+), 18 deletions(-)

diff --git a/scripts/send_qa_email.py b/scripts/send_qa_email.py
index cfbbf62a9910..f0d8aa2339b9 100755
--- a/scripts/send_qa_email.py
+++ b/scripts/send_qa_email.py
@@ -16,6 +16,7 @@ import logging
 import utils
 
 TEST_RESULTS_REPOSITORY_URL="g...@push.yoctoproject.org:yocto-testresults"
+TEST_RESULTS_DRY_RUN_REPOSITORY_URL="git://git.yoctoproject.org/yocto-testresults"
 
 def is_release_version(version):
 p = re.compile('\d{8}-\d+')
@@ -57,17 +58,17 @@ def get_previous_tag(targetrepodir, version):
 defaultbaseversion, _, _ = 
utils.get_version_from_string(subprocess.check_output(["git", "describe", 
"--abbrev=0"], cwd=targetrepodir).decode('utf-8').strip())
 return utils.get_tag_from_version(defaultbaseversion, None)
 
-def get_last_tested_rev_on_branch(branch, log):
+def get_last_tested_rev_on_branch(branch, test_results_url, log):
 # Fetch latest test results revision on corresponding branch in test
 # results repository
-tags_list = subprocess.check_output(["git", "ls-remote", "--refs", "-t", 
TEST_RESULTS_REPOSITORY_URL, "refs/tags/" + branch + 
"/*"]).decode('utf-8').strip()
+tags_list = subprocess.check_output(["git", "ls-remote", "--refs", "-t", 
test_results_url, "refs/tags/" + branch + "/*"]).decode('utf-8').strip()
 latest_test_tag=tags_list.splitlines()[-1].split()[1]
 # From test results tag, extract Poky revision
 tested_revision = re.match('refs\/tags\/.*\/\d+-g([a-f0-9]+)\/\d', 
latest_test_tag).group(1)
 log.info(f"Last tested revision on branch {branch} is {tested_revision}")
 return tested_revision
 
-def get_regression_base_and_target(targetbranch, basebranch, release, 
targetrepodir, log):
+def get_regression_base_and_target(targetbranch, basebranch, release, 
targetrepodir, test_results_url, log):
 if not targetbranch:
 # Targetbranch/basebranch is an arbitrary configuration (not defined 
in config.json): do not run regression reporting
 return None, None
@@ -80,7 +81,7 @@ def get_regression_base_and_target(targetbranch, basebranch, 
release, targetrepo
 # Basebranch/targetbranch are defined in config.json: regression
 # reporting must be done between latest test result available on base 
branch
 # and latest result on targetbranch
-latest_tested_rev_on_basebranch = 
get_last_tested_rev_on_branch(basebranch, log)
+latest_tested_rev_on_basebranch = 
get_last_tested_rev_on_branch(basebranch, test_results_url, log)
 return latest_tested_rev_on_basebranch, targetbranch
 
 #Default case: return previous tag as base
@@ -119,6 +120,9 @@ def send_qa_email():
 parser.add_argument('--url',
 action='store',
 help="The url for the build")
+parser.add_argument('-d', '--dry-run',
+action='store_true',
+help="Do not generate any commit, tag or mail: just 
simulate the release process")
 
 args = parser.parse_args()
 
@@ -136,6 +140,12 @@ def send_qa_email():
 
 repodir = os.path.dirname(args.repojson) + "/build/repos"
 
+if args.dry_run:
+log.info("Running in dry-run mode")
+test_results_url = TEST_RESULTS_DRY_RUN_REPOSITORY_URL
+else:
+test_results_url = TEST_RESULTS_REPOSITORY_URL
+
 if 'poky' in repos and 

[yocto] [yocto-autobuilder-helper][PATCH 4/4] scripts: send_qa_email: protect get_regression_base_and_target from exceptions

[Alexis Lothoré via lists . yoctoproject . org]

From: Alexis Lothoré 

generate_regression_reports is currently protect in a try/catch block to
prevent it from canceling QA email generation when encountering an issue,
but get_regression_base_and_target is not.

Make sure that get_regression_base_and_target can not prevent QA email from
being generated by adding it to the try/catch block protecting
send_qa_email. While doing so, make sure to preserve the exitcode variable
to make sure that the step is still marked as fail in autobuilder to make
sure the error does not go silent. However the variable is not needed as
global anymore since it is now used in a single function.

Signed-off-by: Alexis Lothoré 
---
 scripts/send_qa_email.py | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/scripts/send_qa_email.py b/scripts/send_qa_email.py
index 8422e4937102..fe612c7e114a 100755
--- a/scripts/send_qa_email.py
+++ b/scripts/send_qa_email.py
@@ -16,7 +16,6 @@ import logging
 import utils
 
 TEST_RESULTS_REPOSITORY_URL="git://git.yoctoproject.org/yocto-testresults"
-exitcode = 0
 
 def is_release_version(version):
 p = re.compile('\d{8}-\d+')
@@ -89,21 +88,16 @@ def get_regression_base_and_target(targetbranch, 
basebranch, release, targetrepo
 
 def generate_regression_report(querytool, targetrepodir, base, target, 
resultdir, outputdir, log):
 log.info(f"Comparing {target} to {base}")
-global exitcode
 
-try:
-regreport = subprocess.check_output([querytool, "regression-report", 
base, target, '-t', resultdir])
-with open(outputdir + "/testresult-regressions-report.txt", "wb") as f:
-   f.write(regreport)
-except subprocess.CalledProcessError as e:
-error = str(e)
-exitcode = 1
-log.error(f"Error while generating report between {target} and {base} 
: {error}")
+regreport = subprocess.check_output([querytool, "regression-report", base, 
target, '-t', resultdir])
+with open(outputdir + "/testresult-regressions-report.txt", "wb") as f:
+   f.write(regreport)
 
 def send_qa_email():
 # Setup logging
 logging.basicConfig(level=logging.INFO, format="%(levelname)s: 
%(message)s")
 log = logging.getLogger('send-qa-email')
+exitcode = 0
 
 parser = utils.ArgParser(description='Process test results and optionally 
send an email about the build to prompt QA to begin testing.')
 
@@ -195,9 +189,15 @@ def send_qa_email():
 # log.warning("Test results not published on release version. 
Faulty AB configuration ?")
 
 utils.printheader("Processing regression report")
-regression_base, regression_target = 
get_regression_base_and_target(targetbranch, basebranch, args.release, 
targetrepodir, log)
-if regression_base and regression_target:
+try:
+regression_base, regression_target = 
get_regression_base_and_target(targetbranch, basebranch, args.release, 
targetrepodir, log)
+log.info(f"Generating regression report between 
{regression_base} and {regression_target}")
 generate_regression_report(querytool, targetrepodir, 
regression_base, regression_target, tempdir, args.results_dir, log)
+except subprocess.CalledProcessError as e:
+error = str(e)
+exitcode = 1
+log.error(f"Error while generating regression report: {error}")
+
 
 finally:
 log.info(f"[SKIP] delete {tempdir}")
-- 
2.42.1


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

[yocto] [yocto-autobuilder-helper][PATCH 2/4] scripts: send_qa_email: allow testing against non fixed tags

[Alexis Lothoré via lists . yoctoproject . org]

From: Alexis Lothoré 

send_qa_email currently deals with tags in a "reproducible" way: despite
new versions being released on different branches, the computation of the
"reference" version for a specific input version always remain the same.

This behavior does not match perfectly real expectations: if at the some
point we get version 4.3.1 as a comparison reference for a regression
report, and 4.3.2 is released some time later, we want the next comparision
to be done against 4.3.2.

Start introducing this new behavior by allowing the tests to check returned
version against regex patterns instead of static strings, so we can for
example use wildcards on the "micro" version

Signed-off-by: Alexis Lothoré 
---
 scripts/test_send_qa_email.py | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/scripts/test_send_qa_email.py b/scripts/test_send_qa_email.py
index 8ab91538748a..2dd946f32bf1 100755
--- a/scripts/test_send_qa_email.py
+++ b/scripts/test_send_qa_email.py
@@ -12,6 +12,7 @@ import sys
 import unittest
 import send_qa_email
 import logging
+import re
 
 logging.basicConfig(level=logging.INFO, format="%(levelname)s: %(message)s")
 log = logging.getLogger('send-qa-email')
@@ -60,7 +61,8 @@ class TestVersion(unittest.TestCase):
 input_version = data["input"]["version"]
 expected = data["expected"]
 with self.subTest(f"Test {input_version} previous tag (expecting 
{expected})"):
-
self.assertEqual(send_qa_email.get_previous_tag(os.environ.get("POKY_PATH"), 
input_version), expected)
+   result = 
send_qa_email.get_previous_tag(os.environ.get("POKY_PATH"), input_version)
+   self.assertIsNotNone(re.match(data["expected"], result), 
msg=f"get_previous_tag returned {result}")
 
 def test_is_release_version(self):
 for data in self.test_data_is_release_version:
-- 
2.42.1


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

[yocto] [yocto-autobuilder-helper][PATCH 3/4] scripts: send_qa_email: properly compute previous tag for new major release tag

[Alexis Lothoré via lists . yoctoproject . org]

From: Alexis Lothoré 

send_qa_email currently fails when dealing with release version starting a
new major, for example 5.0. This has been observed for example when trying
to generate 5.0_M1.rc1

This specific versioning makes previous tag computation method fall through
last branch which currently expects that the current release tag indeed
exists (5.0_M1), which is true when checking regression reports a
posteriori, but not in an autobuilder run (tag is added only when the
release has been "validated")

Fix tag computation for this case by getting previous release tag with git
ls-remote, instead of relying on git describe with a possibly non-existing
tag. While doing so, add a few tests about this specific case.

Signed-off-by: Alexis Lothoré 
---
 scripts/send_qa_email.py  | 9 +++--
 scripts/test_send_qa_email.py | 5 -
 2 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/scripts/send_qa_email.py b/scripts/send_qa_email.py
index 232f360621fe..8422e4937102 100755
--- a/scripts/send_qa_email.py
+++ b/scripts/send_qa_email.py
@@ -42,10 +42,15 @@ def get_previous_tag(targetrepodir, version):
 # Process first milestone or release if not first in major release
 elif compareversionminor > 0:
 previousversion = compareversion[:-1] + [compareversion[-1] - 1]
-# Otherwise : format it as tag (which must exist) and search previous 
tag
+# Otherwise : compare against last release on previous major. This can
+# not be computed: we need to retrieve the exact tag from remote
 else:
 comparetagstring = utils.get_tag_from_version(compareversion, 
comparemilestone)
-return subprocess.check_output(["git", "describe", "--abbrev=0", 
comparetagstring + "^"], cwd=targetrepodir).decode('utf-8').strip()
+previous_major = compareversion[0] - 1
+tags_list = subprocess.check_output(["git", "ls-remote", "--refs", 
"-t", "origin", f"refs/tags/yocto-{previous_major}*"], 
cwd=targetrepodir).decode('utf-8').strip()
+# Get last tag from list, pick only the tag part, and remove the
+# "refs/tags/" part
+return tags_list.splitlines()[-1].split()[1].split('/')[-1]
 
 return utils.get_tag_from_version(previousversion, previousmilestone)
 
diff --git a/scripts/test_send_qa_email.py b/scripts/test_send_qa_email.py
index 2dd946f32bf1..415d8cbbbccd 100755
--- a/scripts/test_send_qa_email.py
+++ b/scripts/test_send_qa_email.py
@@ -30,7 +30,10 @@ class TestVersion(unittest.TestCase):
 {"input": {"version": "4.1_M3.rc4"}, "expected": "4.1_M2"},
 {"input": {"version": "4.1_M1.rc1"}, "expected": "yocto-4.0"},
 {"input": {"version": "4.1_M1.rc4"}, "expected": "yocto-4.0"},
-{"input": {"version": "4.1.rc4"}, "expected": "yocto-4.0"}
+{"input": {"version": "4.1.rc4"}, "expected": "yocto-4.0"},
+{"input": {"version": "yocto-5.0_M1.rc1"}, "expected": 
"yocto-4.3(\.\d)?"},
+{"input": {"version": "yocto-5.0_M1.rc2"}, "expected": 
"yocto-4.3(\.\d)?"},
+{"input": {"version": "yocto-5.0_M2.rc1"}, "expected": "5.0_M1"},
 ]
 
 test_data_is_release_version = [
-- 
2.42.1


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

[yocto] [yocto-autobuilder-helper][PATCH 0/4] Fix send_qa_email for releases with new major number

[Alexis Lothoré via lists . yoctoproject . org]

Hello,
the autobuilder encountered a failure while trying to generate 5.0_M1.rc1
(see [1]) on send_qa_email part, which resulted in missing QA email.

This issue is mostly due to the fact that this is the first release on new
major 5.0. While this case is in theory handled in send_qa_email, practice
came in and made things blew up: this version makes the tag computation
method fall through the last branch, which currently expects the tag to
exist. This assumption is a mistake: it may be valid when trying to
generate regression reports a posteriori, but not for autobuilder run (tag
is then applied only when corresponding release has been validated)

The two first commits slightly rework tests to prepare for the fix, which
comes in the third commit.
Last commit makes sure that get_regression_base_and_target will not prevent
QA email generation in case of an exception, as it is currently done with
generate_regression_report

[1] 
https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/6338/steps/29/logs/stdio

Alexis Lothoré (4):
  scripts: send_qa_email: slightly rework previous tag test
  scripts: send_qa_email: allow testing against non fixed tags
  scripts: send_qa_email: properly compute previous tag for new major
release tag
  scripts: send_qa_email: protect get_regression_base_and_target  from
exceptions

 scripts/send_qa_email.py  | 33 +++--
 scripts/test_send_qa_email.py | 15 ++-
 2 files changed, 29 insertions(+), 19 deletions(-)

-- 
2.42.1


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

[yocto] [yocto-autobuilder-helper][PATCH 1/4] scripts: send_qa_email: slightly rework previous tag test

[Alexis Lothoré via lists . yoctoproject . org]

From: Alexis Lothoré 

Use intermediate variables for test input/output, and print expected
output in subtest to get more info when a test fails

Signed-off-by: Alexis Lothoré 
---
 scripts/test_send_qa_email.py | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/scripts/test_send_qa_email.py b/scripts/test_send_qa_email.py
index 5509b3c2510e..8ab91538748a 100755
--- a/scripts/test_send_qa_email.py
+++ b/scripts/test_send_qa_email.py
@@ -57,10 +57,10 @@ class TestVersion(unittest.TestCase):
 
 def test_versions(self):
 for data in self.test_data_get_version:
-test_name = data["input"]["version"]
-with self.subTest(f"Test {test_name} previous tag"):
-self.assertEqual(send_qa_email.get_previous_tag(os.environ.get(
-"POKY_PATH"), data["input"]["version"]), data["expected"])
+input_version = data["input"]["version"]
+expected = data["expected"]
+with self.subTest(f"Test {input_version} previous tag (expecting 
{expected})"):
+
self.assertEqual(send_qa_email.get_previous_tag(os.environ.get("POKY_PATH"), 
input_version), expected)
 
 def test_is_release_version(self):
 for data in self.test_data_is_release_version:
-- 
2.42.1


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

[pfx] Re: 25 years today

[Rob Sterenborg (Lists) via Postfix-users]

On 14-12-2023 14:20, Wietse Venema via Postfix-users wrote:

As a few on this list may recall, it is 25 years ago today that the
"IBM secure mailer" had its public beta release. This was accompanied
by a nice article in the New York Times business section.


...


That was a long time ago. Postfix has evolved as the Internet has
changed. I am continuing the overhaul of this software, motivated
by people like you on this mailing list.

Wietse


Back in 2001 or so, I needed an MTA at the place I worked, and I wasn't 
too experienced. So I tried Sendmail because it was the default, didn't 
understand it, so that didn't work out. Next I somehow found Qmail (it's 
too long ago to remember how that happened), and found it even worse to 
handle. Then I found Postfix, and immediately got it to work for what I 
needed it to do. Since then, I've been using Postfix for all mail 
servers I've ever built, never looked back.


A big thank you for this excellent piece of software and all the support 
we're still getting!



--
Rob

___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

Re: Blog post

[Christopher Dimech via Emacs news and miscellaneous discussions outside the scope of other Emacs mailing lists]

> Sent: Friday, December 15, 2023 at 5:01 AM
> From: "Eli Zaretskii" 
> To: "Christopher Dimech" 
> Cc: arne_...@web.de, m...@eshelyaron.com, Emacs-tangents@gnu.org
> Subject: Re: Blog post
>
> > Cc: Eshel Yaron , Emacs-tangents@gnu.org
> > Date: Thu, 14 Dec 2023 17:20:56 +0100
> > From:  Christopher Dimech via Emacs news and miscellaneous discussions 
> > outside the scope of other
> >  Emacs mailing lists 
> >
> > I put the emphasis on the maintainers themselves to eliminate chaos within
> > their project.  The latter could be the specific area where our opinions 
> > differ.
> > Users typically focus upon specific details, whereas software designers 
> > focus on
> > making everything work well together.  From my experience, being a 
> > maintainer requires
> > a higher level of concentration and control of the external.
>
> It is quite clear to me from what you wrote above that your mental
> model and vision of maintainership of a project like Emacs are very
> different from the reality, starting from what does it mean to be a
> maintainer of such a project and what is its job description.
>
> Given that, your criticism is mostly off-mark.

Yes,  my vision of maintainership of any project is much different.

---
via emacs-tangents mailing list 
(https://lists.gnu.org/mailman/listinfo/emacs-tangents)

Re: Discussion about arm/aarch64 testcase failures seen with patch for PR111673

[Richard Earnshaw (lists) via Gcc]

On 14/12/2023 07:17, Surya Kumari Jangala via Gcc wrote:
> Hi Richard,
> Thanks a lot for your response!
> 
> Another failure reported by the Linaro CI is as follows:
> 
> Running gcc:gcc.dg/dg.exp ...
> FAIL: gcc.dg/ira-shrinkwrap-prep-1.c scan-rtl-dump pro_and_epilogue 
> "Performing shrink-wrapping"
> FAIL: gcc.dg/pr10474.c scan-rtl-dump pro_and_epilogue "Performing 
> shrink-wrapping"
> 
> I analyzed the failures and the root cause is the same for both the failures.
> 
> The test pr10474.c is as follows:
> 
> void f(int *i)
> {
> if (!i)
> return;
> else
> {
> __builtin_printf("Hi");
> *i=0;
> }
> }
> 
> 
> With the patch (for PR111673), x1 (volatile) is being assigned to hold value 
> of
> x0 (first parameter). Since it is a volatile, x1 is saved to the stack as 
> there
> is a call later on. The save to the stack is generated in the LRA pass. The 
> save
> is generated in the entry basic block. Due to the usage of the stack pointer 
> in
> the entry bb, the testcase fails to be shrink wrapped.

I'm not entirely sure I understand what you mean from a quick glance.  Do you 
mean that X1 has the /v flag marked on it (ie it's printed in dumps as 
"reg/v")?  If so, that's not volatile, it just means that the register is 
associated with a user variable (as opposed to a compiler-generated temporary 
variable):

>From the manual:

@item REG_USERVAR_P (@var{x})
In a @code{reg}, nonzero if it corresponds to a variable present in
the user's source code.  Zero for temporaries generated internally by
the compiler.  Stored in the @code{volatil} field and printed as
@samp{/v}.

There are several other cases where we re-use this bit on different RTL 
constructs to mean things other than 'volatile': it pretty much only has the 
conventional meaning on MEM objects.

> 
> The reason why LRA generates the store insn in the entry bb is as follows:
> LRA emits insns to save volatile registers in the inheritance/splitting pass.
> In this pass, LRA builds EBBs (Extended Basic Block) and traverses the insns 
> in
> the EBBs in reverse order from the last insn to the first insn. When LRA sees 
> a
> write to a pseudo (that has been assigned a volatile register), and there is a
> read following the write, with an intervening call insn between the write and 
> read,
> then LRA generates a spill immediately after the write and a restore 
> immediately
> before the read. In the above test, there is an EBB containing the entry bb 
> and
> the bb with the printf call. In the entry bb, there is a write to x1 
> (basically
> a copy from x0 to x1) and in the printf bb, there is a read of x1 after the 
> call
> insn. So LRA generates a spill in the entry bb.
> 
> Without patch, x19 is chosen to hold the value of x0. Since x19 is a 
> non-volatile,
> the input RTL to the shrink wrap pass does not have any code to save x19 to 
> the
> stack. Only the insn that copies x0 to x19 is present in the entry bb. In the
> shrink wrap pass, this insn is moved down the cfg to the bb containing the 
> call
> to printf, thereby allowing prolog to be allocated only where needed. Thus 
> shrink
> wrap succeeds.
> 
> 
> Shrink wrap can be made to succeed if the save of x1 occurs just before the 
> call
> insn, instead of generating it after the write to x1. This will ensure that 
> the
> spill does not occur in the entry bb. In fact, it is more efficient if the 
> save
> occurs only in the path containing the printf call instead of occurring in the
> entry bb.
> 
> I have a patch (bootstrapped and regtested on powerpc) that makes changes in
> LRA to save volatile registers before a call instead of after the write to the
> volatile. With this patch, both the above tests pass.
> 
> Since the patch for PR111673 has been approved by Vladimir, I plan to
> commit the patch to trunk. And I will fix the test failures after doing the
> commit.
> 

I think I'd probably understand this better if you could give some example RTL 
(before and after).  Do you have that?

R.

> Regards,
> Surya
> 
> 
> 
> On 28/11/23 7:18 pm, Richard Earnshaw wrote:
>>
>>
>> On 28/11/2023 12:52, Surya Kumari Jangala wrote:
>>> Hi Richard,
>>> Thanks a lot for your response!
>>>
>>> Another failure reported by the Linaro CI is as follows :
>>> (Note: I am planning to send a separate mail for each failure, as this will 
>>> make
>>> the discussion easy to track)
>>>
>>> FAIL: gcc.target/aarch64/sve/acle/general/cpy_1.c -march=armv8.2-a+sve 
>>> -moverride=tune=none  check-function-bodies dup_x0_m
>>>
>>> Expected code:
>>>
>>>    ...
>>>    add (x[0-9]+), x0, #?1
>>>    mov (p[0-7])\.b, p15\.b
>>>    mov z0\.d, \2/m, \1
>>>    ...
>>>    ret
>>>
>>>
>>> Code obtained w/o patch:
>>>  addvl   sp, sp, #-1
>>>  str p15, [sp]
>>>  add x0, x0, 1
>>>  mov p3.b, p15.b
>>>  mov z0.d, p3/m, x0
>>>  ldr p15, [sp]

Re: [PATCH v7] libgfortran: Replace mutex with rwlock

[Richard Earnshaw (lists)]

On 09/12/2023 15:39, Lipeng Zhu wrote:
> This patch try to introduce the rwlock and split the read/write to
> unit_root tree and unit_cache with rwlock instead of the mutex to
> increase CPU efficiency. In the get_gfc_unit function, the percentage
> to step into the insert_unit function is around 30%, in most instances,
> we can get the unit in the phase of reading the unit_cache or unit_root
> tree. So split the read/write phase by rwlock would be an approach to
> make it more parallel.
> 
> BTW, the IPC metrics can gain around 9x in our test
> server with 220 cores. The benchmark we used is
> https://github.com/rwesson/NEAT
> 
> libgcc/ChangeLog:
> 
>   * gthr-posix.h (__GTHREAD_RWLOCK_INIT): New macro.
>   (__gthrw): New function.
>   (__gthread_rwlock_rdlock): New function.
>   (__gthread_rwlock_tryrdlock): New function.
>   (__gthread_rwlock_wrlock): New function.
>   (__gthread_rwlock_trywrlock): New function.
>   (__gthread_rwlock_unlock): New function.
> 
> libgfortran/ChangeLog:
> 
>   * io/async.c (DEBUG_LINE): New macro.
>   * io/async.h (RWLOCK_DEBUG_ADD): New macro.
>   (CHECK_RDLOCK): New macro.
>   (CHECK_WRLOCK): New macro.
>   (TAIL_RWLOCK_DEBUG_QUEUE): New macro.
>   (IN_RWLOCK_DEBUG_QUEUE): New macro.
>   (RDLOCK): New macro.
>   (WRLOCK): New macro.
>   (RWUNLOCK): New macro.
>   (RD_TO_WRLOCK): New macro.
>   (INTERN_RDLOCK): New macro.
>   (INTERN_WRLOCK): New macro.
>   (INTERN_RWUNLOCK): New macro.
>   * io/io.h (struct gfc_unit): Change UNIT_LOCK to UNIT_RWLOCK in
>   a comment.
>   (unit_lock): Remove including associated internal_proto.
>   (unit_rwlock): New declarations including associated internal_proto.
>   (dec_waiting_unlocked): Use WRLOCK and RWUNLOCK on unit_rwlock
>   instead of __gthread_mutex_lock and __gthread_mutex_unlock on
>   unit_lock.
>   * io/transfer.c (st_read_done_worker): Use WRLOCK and RWUNLOCK on
>   unit_rwlock instead of LOCK and UNLOCK on unit_lock.
>   (st_write_done_worker): Likewise.
>   * io/unit.c: Change UNIT_LOCK to UNIT_RWLOCK in 'IO locking rules'
>   comment. Use unit_rwlock variable instead of unit_lock variable.
>   (get_gfc_unit_from_unit_root): New function.
>   (get_gfc_unit): Use RDLOCK, WRLOCK and RWUNLOCK on unit_rwlock
>   instead of LOCK and UNLOCK on unit_lock.
>   (close_unit_1): Use WRLOCK and RWUNLOCK on unit_rwlock instead of
>   LOCK and UNLOCK on unit_lock.
>   (close_units): Likewise.
>   (newunit_alloc): Use RWUNLOCK on unit_rwlock instead of UNLOCK on
>   unit_lock.
>   * io/unix.c (find_file): Use RDLOCK and RWUNLOCK on unit_rwlock
>   instead of LOCK and UNLOCK on unit_lock.
>   (flush_all_units): Use WRLOCK and RWUNLOCK on unit_rwlock instead
>   of LOCK and UNLOCK on unit_lock.
> 

It looks like this has broken builds on arm-none-eabi when using newlib:

In file included from /work/rearnsha/gnusrc/nightly/gcc-cross/master/libgfortran
/runtime/error.c:27:
/work/rearnsha/gnusrc/nightly/gcc-cross/master/libgfortran/io/io.h: In function 
‘dec_waiting_unlocked’:
/work/rearnsha/gnusrc/nightly/gcc-cross/master/libgfortran/io/io.h:1023:3: error
: implicit declaration of function ‘WRLOCK’ [-Wimplicit-function-declaration]
 1023 |   WRLOCK (_rwlock);
  |   ^~
/work/rearnsha/gnusrc/nightly/gcc-cross/master/libgfortran/io/io.h:1025:3: error
: implicit declaration of function ‘RWUNLOCK’ [-Wimplicit-function-declaration]
 1025 |   RWUNLOCK (_rwlock);
  |   ^~~~


R.

> ---
> v1 -> v2:
> Limit the pthread_rwlock usage in libgcc only when __cplusplus isn't defined.
> 
> v2 -> v3:
> Rebase the patch with trunk branch.
> 
> v3 -> v4:
> Update the comments.
> 
> v4 -> v5:
> Fix typos and code formatter.
> 
> v5 -> v6:
> Add unit tests.
> 
> v6 -> v7:
> Update ChangeLog and code formatter.
> 
> Reviewed-by: Hongjiu Lu 
> Reviewed-by: Bernhard Reutner-Fischer 
> Reviewed-by: Thomas Koenig 
> Reviewed-by: Jakub Jelinek 
> Signed-off-by: Lipeng Zhu 
> ---
>  libgcc/gthr-posix.h   |  60 +++
>  libgfortran/io/async.c|   4 +
>  libgfortran/io/async.h| 151 ++
>  libgfortran/io/io.h   |  15 +-
>  libgfortran/io/transfer.c |   8 +-
>  libgfortran/io/unit.c | 117 +-
>  libgfortran/io/unix.c |  16 +-
>  .../testsuite/libgomp.fortran/rwlock_1.f90|  33 
>  .../testsuite/libgomp.fortran/rwlock_2.f90|  22 +++
>  .../testsuite/libgomp.fortran/rwlock_3.f90|  18 +++
>  10 files changed, 386 insertions(+), 58 deletions(-)
>  create mode 100644 libgomp/testsuite/libgomp.fortran/rwlock_1.f90
>  create mode 100644 libgomp/testsuite/libgomp.fortran/rwlock_2.f90
>  create mode 100644 libgomp/testsuite/libgomp.fortran/rwlock_3.f90
> 
> diff --git 

Re: [PATCH v7] libgfortran: Replace mutex with rwlock

[Richard Earnshaw (lists)]

On 09/12/2023 15:39, Lipeng Zhu wrote:
> This patch try to introduce the rwlock and split the read/write to
> unit_root tree and unit_cache with rwlock instead of the mutex to
> increase CPU efficiency. In the get_gfc_unit function, the percentage
> to step into the insert_unit function is around 30%, in most instances,
> we can get the unit in the phase of reading the unit_cache or unit_root
> tree. So split the read/write phase by rwlock would be an approach to
> make it more parallel.
> 
> BTW, the IPC metrics can gain around 9x in our test
> server with 220 cores. The benchmark we used is
> https://github.com/rwesson/NEAT
> 
> libgcc/ChangeLog:
> 
>   * gthr-posix.h (__GTHREAD_RWLOCK_INIT): New macro.
>   (__gthrw): New function.
>   (__gthread_rwlock_rdlock): New function.
>   (__gthread_rwlock_tryrdlock): New function.
>   (__gthread_rwlock_wrlock): New function.
>   (__gthread_rwlock_trywrlock): New function.
>   (__gthread_rwlock_unlock): New function.
> 
> libgfortran/ChangeLog:
> 
>   * io/async.c (DEBUG_LINE): New macro.
>   * io/async.h (RWLOCK_DEBUG_ADD): New macro.
>   (CHECK_RDLOCK): New macro.
>   (CHECK_WRLOCK): New macro.
>   (TAIL_RWLOCK_DEBUG_QUEUE): New macro.
>   (IN_RWLOCK_DEBUG_QUEUE): New macro.
>   (RDLOCK): New macro.
>   (WRLOCK): New macro.
>   (RWUNLOCK): New macro.
>   (RD_TO_WRLOCK): New macro.
>   (INTERN_RDLOCK): New macro.
>   (INTERN_WRLOCK): New macro.
>   (INTERN_RWUNLOCK): New macro.
>   * io/io.h (struct gfc_unit): Change UNIT_LOCK to UNIT_RWLOCK in
>   a comment.
>   (unit_lock): Remove including associated internal_proto.
>   (unit_rwlock): New declarations including associated internal_proto.
>   (dec_waiting_unlocked): Use WRLOCK and RWUNLOCK on unit_rwlock
>   instead of __gthread_mutex_lock and __gthread_mutex_unlock on
>   unit_lock.
>   * io/transfer.c (st_read_done_worker): Use WRLOCK and RWUNLOCK on
>   unit_rwlock instead of LOCK and UNLOCK on unit_lock.
>   (st_write_done_worker): Likewise.
>   * io/unit.c: Change UNIT_LOCK to UNIT_RWLOCK in 'IO locking rules'
>   comment. Use unit_rwlock variable instead of unit_lock variable.
>   (get_gfc_unit_from_unit_root): New function.
>   (get_gfc_unit): Use RDLOCK, WRLOCK and RWUNLOCK on unit_rwlock
>   instead of LOCK and UNLOCK on unit_lock.
>   (close_unit_1): Use WRLOCK and RWUNLOCK on unit_rwlock instead of
>   LOCK and UNLOCK on unit_lock.
>   (close_units): Likewise.
>   (newunit_alloc): Use RWUNLOCK on unit_rwlock instead of UNLOCK on
>   unit_lock.
>   * io/unix.c (find_file): Use RDLOCK and RWUNLOCK on unit_rwlock
>   instead of LOCK and UNLOCK on unit_lock.
>   (flush_all_units): Use WRLOCK and RWUNLOCK on unit_rwlock instead
>   of LOCK and UNLOCK on unit_lock.
> 

It looks like this has broken builds on arm-none-eabi when using newlib:

In file included from /work/rearnsha/gnusrc/nightly/gcc-cross/master/libgfortran
/runtime/error.c:27:
/work/rearnsha/gnusrc/nightly/gcc-cross/master/libgfortran/io/io.h: In function 
‘dec_waiting_unlocked’:
/work/rearnsha/gnusrc/nightly/gcc-cross/master/libgfortran/io/io.h:1023:3: error
: implicit declaration of function ‘WRLOCK’ [-Wimplicit-function-declaration]
 1023 |   WRLOCK (_rwlock);
  |   ^~
/work/rearnsha/gnusrc/nightly/gcc-cross/master/libgfortran/io/io.h:1025:3: error
: implicit declaration of function ‘RWUNLOCK’ [-Wimplicit-function-declaration]
 1025 |   RWUNLOCK (_rwlock);
  |   ^~~~


R.

> ---
> v1 -> v2:
> Limit the pthread_rwlock usage in libgcc only when __cplusplus isn't defined.
> 
> v2 -> v3:
> Rebase the patch with trunk branch.
> 
> v3 -> v4:
> Update the comments.
> 
> v4 -> v5:
> Fix typos and code formatter.
> 
> v5 -> v6:
> Add unit tests.
> 
> v6 -> v7:
> Update ChangeLog and code formatter.
> 
> Reviewed-by: Hongjiu Lu 
> Reviewed-by: Bernhard Reutner-Fischer 
> Reviewed-by: Thomas Koenig 
> Reviewed-by: Jakub Jelinek 
> Signed-off-by: Lipeng Zhu 
> ---
>  libgcc/gthr-posix.h   |  60 +++
>  libgfortran/io/async.c|   4 +
>  libgfortran/io/async.h| 151 ++
>  libgfortran/io/io.h   |  15 +-
>  libgfortran/io/transfer.c |   8 +-
>  libgfortran/io/unit.c | 117 +-
>  libgfortran/io/unix.c |  16 +-
>  .../testsuite/libgomp.fortran/rwlock_1.f90|  33 
>  .../testsuite/libgomp.fortran/rwlock_2.f90|  22 +++
>  .../testsuite/libgomp.fortran/rwlock_3.f90|  18 +++
>  10 files changed, 386 insertions(+), 58 deletions(-)
>  create mode 100644 libgomp/testsuite/libgomp.fortran/rwlock_1.f90
>  create mode 100644 libgomp/testsuite/libgomp.fortran/rwlock_2.f90
>  create mode 100644 libgomp/testsuite/libgomp.fortran/rwlock_3.f90
> 
> diff --git 

Re: Blog post

[Christopher Dimech via Emacs news and miscellaneous discussions outside the scope of other Emacs mailing lists]

> Sent: Thursday, December 14, 2023 at 9:29 PM
> From: "Dr. Arne Babenhauserheide" 
> To: "Christopher Dimech" 
> Cc: "Eshel Yaron" , emacs-de...@gnu.org
> Subject: Re: Blog post
>
> 
> Christopher Dimech  writes:
> 
> > From your experience, have your rants been justified ? Introspection
> > of other people's rants should be considered part of the work.  After 
> > all, expletives towards demigods have occurred since time immemorial,
> > and will surely continue.
> 
> Yes, they were totally justified — but usually not helpful. Most times
> they needlessly hurt people who then often stopped contributing. A
> friendly text may have helped to stay together and actually fix the
> problem to move forward as community. - Arne

Nobody gets hurt.   It is commonly a type of vengeance (a form of 
retaliation) intended to dissuade contrarian views directed towards 
the developers.

The Gnu Project is built on the fundamental premise that software is for
the benefit of its users, not solely its developers.  This perspective 
emphasizes the importance of creating an inclusive and collaborative 
community where users can contribute, share ideas, and provide feedback
without reprisals from developers - unlike what generally happens with 
Proprietary Software Developers.

The "Information for Gnu Maintainers" states that when a developer receives
a report, the maintainers have to keep in mind that such reports are crucial
for our work - so always thank each person who sends a report. 

This is not to say that a considerate peaceful problem solving should not
be the common way of approaching the developer team.  Ultimately the job
of the maintainers is to exercise their authority so they can focus upon
improving the next version of the program.  Stopping one's contribution 
rather than exercising one's authority is Conflict Avoidance that shows
a Lack of Responsibility - a sign of failure.   



- Christopher Dimech
Administrator General - Chilkat Design Build - Naiad Informatics - Gnu Project

Society has become too quick to pass judgement and declare someone
Persona Non-Grata, the most extreme form of censure a country can
bestow.

In a new era of destructive authoritarianism, I support Richard
Stallman.  Times of great crisis are also times of great
opportunity.  I call upon you to make this struggle yours as well !

https://www.gnu.org https://www.fsf.org/


---
via emacs-tangents mailing list 
(https://lists.gnu.org/mailman/listinfo/emacs-tangents)

Re: [PATCH] Fix tests for gomp

[Andre Vieira (lists)]

On 13/12/2023 10:55, Jakub Jelinek wrote:

On Wed, Dec 13, 2023 at 10:43:16AM +, Andre Vieira (lists) wrote:

Hi,

Apologies for the delay and this mixup. I need to do something different

This is to fix testisms initially introduced by:
commit f5fc001a84a7dbb942a6252b3162dd38b4aae311
Author: Andre Vieira 
Date:   Mon Dec 11 14:24:41 2023 +

 aarch64: enable mixed-types for aarch64 simdclones

gcc/testsuite/ChangeLog:

* gcc.dg/gomp/pr87887-1.c: Fixed test.
* gcc.dg/gomp/pr89246-1.c: Likewise.
* gcc.dg/gomp/simd-clones-2.c: Likewise.

libgomp/ChangeLog:

* testsuite/libgomp.c/declare-variant-1.c: Fixed test.
* testsuite/libgomp.fortran/declare-simd-1.f90: Likewise.

OK for trunk? I was intending to commit as obvious, but jakub had made a
comment about declare-simd-1.f90 so I thought it might be worth just sending
it up to the mailing list first.



--- a/libgomp/testsuite/libgomp.c/declare-variant-1.c
+++ b/libgomp/testsuite/libgomp.c/declare-variant-1.c
@@ -40,16 +40,17 @@ f04 (int a)
  int
  test1 (int x)
  {
-  /* At gimplification time, we can't decide yet which function to call.  */
-  /* { dg-final { scan-tree-dump-times "f04 \\\(x" 2 "gimple" } } */
+  /* At gimplification time, we can't decide yet which function to call for
+ x86_64 targets, given the f01 variant.  */
+  /* { dg-final { scan-tree-dump-times "f04 \\\(x" 2 "gimple" { target 
x86_64-*-* } } } */
/* After simd clones are created, the original non-clone test1 shall
   call f03 (score 6), the sse2/avx/avx2 clones too, but avx512f clones
   shall call f01 with score 8.  */
/* { dg-final { scan-ltrans-tree-dump-not "f04 \\\(x" "optimized" } } */
-  /* { dg-final { scan-ltrans-tree-dump-times "f03 \\\(x" 14 "optimized" { 
target { !aarch64*-*-* } } } } } */
-  /* { dg-final { scan-ltrans-tree-dump-times "f01 \\\(x" 4 "optimized" { 
target { !aarch64*-*-* } } } } } */
-  /* { dg-final { scan-ltrans-tree-dump-times "f03 \\\(x" 10 "optimized" { 
target { aarch64*-*-* } } } } } */
-  /* { dg-final { scan-ltrans-tree-dump-not "f01 \\\(x" "optimized" { target { 
aarch64*-*-* } } } } } */
+  /* { dg-final { scan-ltrans-tree-dump-times "f03 \\\(x" 14 "optimized" { 
target { !aarch64*-*-* } } } } */
+  /* { dg-final { scan-ltrans-tree-dump-times "f01 \\\(x" 4 "optimized" { 
target { !aarch64*-*-* } } } } */
+  /* { dg-final { scan-ltrans-tree-dump-times "f03 \\\(x" 10 "optimized" { 
target { aarch64*-*-* } } } } */
+  /* { dg-final { scan-ltrans-tree-dump-not "f01 \\\(x" "optimized" { target { 
aarch64*-*-* } } } } */


The changes in this test look all wrong.  The differences are
i?86-*-* x86_64-*-* (which can support avx512f isa) vs. other targets (which
can't).
So, there is nothing aarch64 specific in there and { target x86_64-*-* }
is also incorrect.  It should be simply
{ target i?86-*-* x86_64-*-* }
vs.
{ target { ! { i?86-*-* x86_64-*-* } } }
(never sure about the ! syntaxes).



Hmm I think I understand what you are saying, but I'm not sure I 
agree. So before I enabled simdclone testing for aarch64, this test had 
no target selectors. So it checked the same for 'all simdclone test 
targets'. Which seem to be x86 and amdgcn:


@@ -4321,7 +4321,8 @@ proc check_effective_target_vect_simd_clones { } {
 return [check_cached_effective_target_indexed vect_simd_clones {
   expr { (([istarget i?86-*-*] || [istarget x86_64-*-*])
  && [check_effective_target_avx512f])
|| [istarget amdgcn-*-*]
|| [istarget aarch64*-*-*] }}]
 }

I haven't checked what amdgcn does with this test, but I'd have to 
assume they were passing before? Though I'm not sure how amdgcn would 
pass the original:
 -  /* At gimplification time, we can't decide yet which function to 
call.  */

 -  /* { dg-final { scan-tree-dump-times "f04 \\\(x" 2 "gimple" } } */

I've added Andrew to the mail to see if he can comment on that. Either 
way I'd suggest we either add scan's per target with the expected value 
or stick with my original change of aarch64 vs non-aarch64 as I think 
that would better reflect the changes of enabling this for aarch64 where 
it wasn't ran before.

[PATCH] Fix tests for gomp

[Andre Vieira (lists)]

Hi,

Apologies for the delay and this mixup. I need to do something different

This is to fix testisms initially introduced by:
commit f5fc001a84a7dbb942a6252b3162dd38b4aae311
Author: Andre Vieira 
Date:   Mon Dec 11 14:24:41 2023 +

aarch64: enable mixed-types for aarch64 simdclones

gcc/testsuite/ChangeLog:

* gcc.dg/gomp/pr87887-1.c: Fixed test.
* gcc.dg/gomp/pr89246-1.c: Likewise.
* gcc.dg/gomp/simd-clones-2.c: Likewise.

libgomp/ChangeLog:

* testsuite/libgomp.c/declare-variant-1.c: Fixed test.
* testsuite/libgomp.fortran/declare-simd-1.f90: Likewise.

OK for trunk? I was intending to commit as obvious, but jakub had made a 
comment about declare-simd-1.f90 so I thought it might be worth just 
sending it up to the mailing list first.


Kind regards,
Andrediff --git a/gcc/testsuite/gcc.dg/gomp/pr87887-1.c 
b/gcc/testsuite/gcc.dg/gomp/pr87887-1.c
index 
281898300c7794d862e62c70a83a33d5aaa8f89e..8b04ffd0809be4e6f5ab97c2e32e800edffbee4f
 100644
--- a/gcc/testsuite/gcc.dg/gomp/pr87887-1.c
+++ b/gcc/testsuite/gcc.dg/gomp/pr87887-1.c
@@ -10,7 +10,6 @@ foo (int x)
 {
   return (struct S) { x };
 }
-/* { dg-warning "unsupported return type ‘struct S’ for ‘simd’ functions" "" { 
target aarch64*-*-* } .-4 } */
 
 #pragma omp declare simd
 int
@@ -18,7 +17,6 @@ bar (struct S x)
 {
   return x.n;
 }
-/* { dg-warning "unsupported argument type ‘struct S’ for ‘simd’ functions" "" 
{ target aarch64*-*-* } .-4 } */
 
 #pragma omp declare simd uniform (x)
 int
diff --git a/gcc/testsuite/gcc.dg/gomp/pr89246-1.c 
b/gcc/testsuite/gcc.dg/gomp/pr89246-1.c
index 
4a0fd74f0639b2832dcb9101e006d127568fbcbd..dfe629c1c6a51624cd94878c638606220cfe94eb
 100644
--- a/gcc/testsuite/gcc.dg/gomp/pr89246-1.c
+++ b/gcc/testsuite/gcc.dg/gomp/pr89246-1.c
@@ -8,7 +8,6 @@ int foo (__int128 x)
 {
   return x;
 }
-/* { dg-warning "unsupported argument type ‘__int128’ for ‘simd’ functions" "" 
{ target aarch64*-*-* } .-4 } */
 
 #pragma omp declare simd
 extern int bar (int x);
diff --git a/gcc/testsuite/gcc.dg/gomp/simd-clones-2.c 
b/gcc/testsuite/gcc.dg/gomp/simd-clones-2.c
index 
f12244054bd46fa10e51cc3a688c4cf683689994..354078acd9f3073b8400621a0e7149aee571594b
 100644
--- a/gcc/testsuite/gcc.dg/gomp/simd-clones-2.c
+++ b/gcc/testsuite/gcc.dg/gomp/simd-clones-2.c
@@ -19,7 +19,6 @@ float setArray(float *a, float x, int k)
 /* { dg-final { scan-tree-dump "_ZGVnN2ua32vl_setArray" "optimized" { target 
aarch64*-*-* } } } */
 /* { dg-final { scan-tree-dump "_ZGVnN4ua32vl_setArray" "optimized" { target 
aarch64*-*-* } } } */
 /* { dg-final { scan-tree-dump "_ZGVnN2vvva32_addit" "optimized" { target 
aarch64*-*-* } } } */
-/* { dg-final { scan-tree-dump "_ZGVnN4vvva32_addit" "optimized" { target 
aarch64*-*-* } } } */
 /* { dg-final { scan-tree-dump "_ZGVnM2vl66u_addit" "optimized" { target 
aarch64*-*-* } } } */
 /* { dg-final { scan-tree-dump "_ZGVnM4vl66u_addit" "optimized" { target 
aarch64*-*-* } } } */
 
diff --git a/libgomp/testsuite/libgomp.c/declare-variant-1.c 
b/libgomp/testsuite/libgomp.c/declare-variant-1.c
index 
6129f23a0f80585246957022d63608dc3a68f1ff..790e9374054fe3e0ae609796640ff295b61e8389
 100644
--- a/libgomp/testsuite/libgomp.c/declare-variant-1.c
+++ b/libgomp/testsuite/libgomp.c/declare-variant-1.c
@@ -40,16 +40,17 @@ f04 (int a)
 int
 test1 (int x)
 {
-  /* At gimplification time, we can't decide yet which function to call.  */
-  /* { dg-final { scan-tree-dump-times "f04 \\\(x" 2 "gimple" } } */
+  /* At gimplification time, we can't decide yet which function to call for
+ x86_64 targets, given the f01 variant.  */
+  /* { dg-final { scan-tree-dump-times "f04 \\\(x" 2 "gimple" { target 
x86_64-*-* } } } */
   /* After simd clones are created, the original non-clone test1 shall
  call f03 (score 6), the sse2/avx/avx2 clones too, but avx512f clones
  shall call f01 with score 8.  */
   /* { dg-final { scan-ltrans-tree-dump-not "f04 \\\(x" "optimized" } } */
-  /* { dg-final { scan-ltrans-tree-dump-times "f03 \\\(x" 14 "optimized" { 
target { !aarch64*-*-* } } } } } */
-  /* { dg-final { scan-ltrans-tree-dump-times "f01 \\\(x" 4 "optimized" { 
target { !aarch64*-*-* } } } } } */
-  /* { dg-final { scan-ltrans-tree-dump-times "f03 \\\(x" 10 "optimized" { 
target { aarch64*-*-* } } } } } */
-  /* { dg-final { scan-ltrans-tree-dump-not "f01 \\\(x" "optimized" { target { 
aarch64*-*-* } } } } } */
+  /* { dg-final { scan-ltrans-tree-dump-times "f03 \\\(x" 14 "optimized" { 
target { !aarch64*-*-* } } } } */
+  /* { dg-final { scan-ltrans-tree-dump-times "f01 \\\(x" 4 "optimized" { 
target { !aarch64*-*-* } } } } */
+  /* { dg-final { scan-ltrans-tree-dump-times "f03 \\\(x" 10 "optimized" { 
target { aarch64*-*-* } } } } */
+  /* { dg-final { scan-ltrans-tree-dump-not "f01 \\\(x" "optimized" { target { 
aarch64*-*-* } } } } */
   int a = f04 (x);
   int b = f04 (x);
   return a + b;
diff --git a/libgomp/testsuite/libgomp.fortran/declare-simd-1.f90 

[pfx] printer ip SMTP AUTH / mynetworks question

[lists--- via Postfix-users]

I have a user with an 'old' printer/scanner who wants to scan/email scans
from the home located device

printer offers:
machine email address:
SMTP server:
SMTP server port:

send authentication: PoPb4SMTP/SMTP AUTH: Plain/Login/CRAM-MD5/Auto

login name:
passwd:

tried 587 with each of the 4 AUTH options, keeps failing
added printer IP to mynetworks, changed to port 25, working

any suggestion what it might need to use port 587 / AUTH ?

any undesired side effects of allowing printer IP in main.cf mynetworks ?

Dec 13 17:52:13 geko postfix/submission/smtpd[22180]: connect from
111-222-333-444.tpgi.com.au[111.222.333.444]
Dec 13 17:52:13 geko postfix/submission/smtpd[22180]: lost connection
after EHLO from 111-222-333-444.tpgi.com.au[111.222.333.444]
Dec 13 17:52:13 geko postfix/submission/smtpd[22180]: disconnect from
111-222-333-444.tpgi.com.au[111.222.333.444] ehlo=1 commands=1

Dec 13 17:47:20 geko postfix/submission/smtpd[15098]: disconnect from
111-222-333-444.tpgi.com.au[111.222.333.444] ehlo=1 commands=1
Dec 13 17:48:12 geko postfix/anvil[15001]: statistics: max connection rate
6/3600s for (submission:111.222.333.444) at Dec 13 17:47:20
Dec 13 17:48:26 geko postfix/postscreen[14984]: CONNECT from
[111.222.333.444]:50694 to [103.106.168.106]:25
Dec 13 17:48:26 geko postfix/postscreen[14984]: WHITELISTED
[111.222.333.444]:50694
Dec 13 17:48:26 geko postfix/smtpd[15061]: connect from
111-222-333-444.tpgi.com.au[111.222.333.444]
Dec 13 17:48:26 geko postfix/smtpd[15061]: CB67D20BBA9:
client=111-222-333-444.tpgi.com.au[111.222.333.444], sasl_method=LOGIN,
sasl_username=u...@tld.com.au
Dec 13 17:48:30 geko amavis[15129]: (15129-15) Checking: P4rpqg2X2xgz
[111.222.333.444]  -> 
Dec 13 17:48:31 geko postfix/smtpd[15061]: disconnect from
111-222-333-444.tpgi.com.au[111.222.333.444] ehlo=1 auth=1 mail=1 rcpt=1
data=1 quit=1 commands=6
Dec 13 17:48:31 geko amavis[15129]: (15129-15) Passed CLEAN
{RelayedInbound}, [111.222.333.444]:50694 [111.222.333.444] ESMTP/ESMTP
 -> ,
(ESMTPA://[111.222.333.444]:50694), Queue-ID: CB67D20BBA9, mail_id:
P4rpqg2X2xgz, b: cNaGQKTr-, Hits: 0.436, size: 525554, queued_as:
C064E20A5CB, Subject: "ScanFrom Printer (raw:
=?utf-8?B?U2NhbkZy2NhbkZyb20gW50ZXI=?=)", From: ,
helo=iptarget, Tests:
[ALL_TRUSTED=-1,BAYES_00=-1.9,DATE_IN_PAST_06_12=1.543,DKIM_INVALID=0.1,DKIM_SIGNED=0.1,INVALID_DATE=1.096,MISSING_MID=0.497],
autolearn=no autolearn_force=no, autolearnscore=1.875, 1715 ms




___
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org

Re: [PATCH] aarch64: enable mixed-types for aarch64 simdclones

[Andre Vieira (lists)]

On 11/12/2023 21:42, Thomas Schwinge wrote:

Hi Andre!

On 2023-10-16T16:03:26+0100, "Andre Vieira (lists)" 
 wrote:

Just a minor update to the patch, I had missed the libgomp testsuite, so
had to make some adjustments there too.


Unfortunately, there appear to be a number of DejaGnu directive errors in
your test case changes -- do you not see those in your testing?


I hadn't seen those... I wonder whether they don't show up if you do 
dg-cmp-results with just one -v, I have binned the build, but I'll rerun 
it and double check, may need to use '-v -v' instead.


Thanks for letting me know.
..., and the following change also doesn't look quite right:



--- a/libgomp/testsuite/libgomp.fortran/declare-simd-1.f90
+++ b/libgomp/testsuite/libgomp.fortran/declare-simd-1.f90
@@ -1,5 +1,5 @@
  ! { dg-do run { target vect_simd_clones } }
-! { dg-options "-fno-inline" }
+! { dg-options "-fno-inline -cpp -D__aarch64__" }




Yeah, that needs a target selector. Thanks!

Re: [OT] Not clobbering bash history

[Arsen Arsenović via Emacs news and miscellaneous discussions outside the scope of other Emacs mailing lists]

Hi Jean,

Jean Louis  writes:

>>   > Say that the history has eight entries, and a ninth was added by a
>>   > parallel process, the current process would be at the point after the
>>   > eighth element and should continue reading from there next time it wants
>>   > a history entry.
>
> Arsen, explore options of the command `history' to do what you want,
> you can save history:
>
> $ history -a
>
> and you can re-read history file:
>
> $ history -r
>
> and by using those options you can mix history from different Bash
> sessions, and also re-use the history from other Bash session.

Thanks for the tip.  I already have something using these flags
implemented:

  PROMPT_COMMAND="$PROMPT_COMMAND;history -a; history -c; history -r")

which is a functional hack, for the most part.  It still has some of the
problems mentioned in my original message (history is only added to
after a command concludes, sporadic truncation still happens, etc), plus
this approach is rather ugly.

Thanks again, have a lovely day.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature
---
via emacs-tangents mailing list 
(https://lists.gnu.org/mailman/listinfo/emacs-tangents)

[sphinx-users] Thank you moderators

[Wols Lists]

I know the current spate of spam is a pain, but this is the second group 
I'm on that's been hit, and you're doing a very good job of keeping on 
top of it.


I'm on the mailing list, so I get hit with everything that doesn't get 
caught as it's posted.


I'm sure you're doing the same as the other group did, they've always 
put new joiners on moderation temporarily, which prevents the drive-by 
spammers.


This lot seem to have cracked a bunch of google addresses, and are using 
them as burner posters. When they run out, it'll stop. Here's hoping 
they haven't got that many.


Cheers,
Wol

--
You received this message because you are subscribed to the Google Groups 
"sphinx-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sphinx-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sphinx-users/17784801-b4dc-41e5-8fc8-a23cfae3c673%40youngman.org.uk.

Re: [yocto] [yocto-autobuilder-helper][mickledore][PATCH 0/3] fix mickledore tests reports

[Alexis Lothoré via lists . yoctoproject . org]

Hello Steve,

On 12/8/23 23:39, Steve Sakoman wrote:
> Mickledore is already end-of-life, so no further builds are scheduled.

Ah, yes, I checked that before sending because I had a doubt about whether this
series would still be useful on top of mickledore, but since the 4.2.4.rc3 is
still in progress, I was not sure.
So ok, feel free to drop this series.

> There is a dunfell release that I plan to build this weekend, so a
> patchset for dunfell would be much appreciated if you would like me to
> test it with the 3.1.30 build.
> 
> And a kirkstone release is due shortly thereafter, so we also need it there 
> too!

I am not sure that a backport is really needed on dunfell and kirkstone, because
- "dunfell" is properly described in BUILD_HISTORY_DIRECTPUSH in config.json, on
dunfell branch
- "kirkstone" is properly described in BUILD_HISTORY_DIRECTPUSH in config.json,
on kirkstone branch
(so yes, the issue was really affecting mickledore specifically)

Anyway, the wider issue is that those branches are lacking almost all
developments I did since ~January on send-qa-email, so some things may work
(test results storage), some other may not (regression reports based on those
results). It is also true for poky. A whole backport is of course possible, but
that would definitely need some thorough testing before using it for releases.

Kind regards,

Alexis
-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


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

[yocto] [yocto-autobuilder-helper][mickledore][PATCH 2/3] config.json: remove BUILD_HISTORY_DIRECTPUSH

[Alexis Lothoré via lists . yoctoproject . org]

From: Alexis Lothoré 

Now that BUILD_HISTORY_DIRECTPUSH has been replaced by a hardcoded
condition, remove it from config.json

Signed-off-by: Alexis Lothoré 
Signed-off-by: Richard Purdie 
---
 config.json | 1 -
 1 file changed, 1 deletion(-)

diff --git a/config.json b/config.json
index 1eeabc4c9015..f93ec45927ac 100644
--- a/config.json
+++ b/config.json
@@ -5,7 +5,6 @@
 
 "BUILD_HISTORY_DIR" : "buildhistory",
 "BUILD_HISTORY_REPO" : 
"ssh://g...@push.yoctoproject.org/poky-buildhistory",
-"BUILD_HISTORY_DIRECTPUSH" : ["poky:morty", "poky:pyro", "poky:rocko", 
"poky:sumo", "poky:thud", "poky:warrior", "poky:zeus", "poky:dunfell", 
"poky:gatesgarth", "poky:hardknott", "poky:honister", "poky:kirkstone", 
"poky:langdale", "poky:master"],
 "BUILD_HISTORY_FORKPUSH" : {"poky-contrib:ross/mut" : "poky:master", 
"poky-contrib:abelloni/master-next": "poky:master", "poky:master-next" : 
"poky:master"},
 
 "BUILDTOOLS_URL_TEMPLOCAL" : 
"/srv/autobuilder/autobuilder.yocto.io/pub/non-release/20210214-8/buildtools/x86_64-buildtools-extended-nativesdk-standalone-3.2+snapshot-7d38cc8e749aedb8435ee71847e04b353cca541d.sh",
-- 
2.42.1


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

[yocto] [yocto-autobuilder-helper][mickledore][PATCH 3/3] scripts/test_utils.py: update test after BUILD_HISTORY_DIRECTPUSH removal

[Alexis Lothoré via lists . yoctoproject . org]

From: Alexis Lothoré 

Update getcomparisonbranch unit tests by removing BUILD_HISTORY_DIRECTPUSH
entry in fake configuration

Signed-off-by: Alexis Lothoré 
Signed-off-by: Richard Purdie 
---
 scripts/test_utils.py | 29 +++--
 1 file changed, 7 insertions(+), 22 deletions(-)

diff --git a/scripts/test_utils.py b/scripts/test_utils.py
index d02e9b2a5bb3..d149dc946ccd 100755
--- a/scripts/test_utils.py
+++ b/scripts/test_utils.py
@@ -7,22 +7,7 @@ import utils
 
 class TestGetComparisonBranch(unittest.TestCase):
 TEST_CONFIG = {
-"BUILD_HISTORY_DIRECTPUSH": [
-"poky:morty",
-"poky:pyro",
-"poky:rocko",
-"poky:sumo",
-"poky:thud",
-"poky:warrior",
-"poky:zeus",
-"poky:dunfell",
-"poky:gatesgarth",
-"poky:hardknott",
-"poky:honister",
-"poky:kirkstone",
-"poky:langdale",
-"poky:master"
-], "BUILD_HISTORY_FORKPUSH": {
+   "BUILD_HISTORY_FORKPUSH": {
 "poky-contrib:ross/mut": "poky:master",
 "poky:master-next": "poky:master",
 "poky-contrib:abelloni/master-next": "poky:master"
@@ -35,9 +20,9 @@ class TestGetComparisonBranch(unittest.TestCase):
 basebranch, comparebranch = utils.getcomparisonbranch(
 self.TEST_CONFIG, repo, branch)
 self.assertEqual(
-basebranch, "master", msg="Repo/branch pair present in 
BUILD_HISTORY_DIRECTPUSH must return corresponding base branch")
+basebranch, "master", msg="Release branch in poky must return 
corresponding base branch")
 self.assertEqual(
-comparebranch, None, msg="Repo/branch pair present in 
BUILD_HISTORY_DIRECTPUSH must return corresponding compare branch")
+comparebranch, None, msg="Release branch in poky must return 
corresponding compare branch")
 
 def test_release_kirkstone(self):
 repo = "ssh://g...@push.yoctoproject.org/poky"
@@ -45,9 +30,9 @@ class TestGetComparisonBranch(unittest.TestCase):
 basebranch, comparebranch = utils.getcomparisonbranch(
 self.TEST_CONFIG, repo, branch)
 self.assertEqual(basebranch, "kirkstone",
- msg="Repo/branch pair present in 
BUILD_HISTORY_DIRECTPUSH must return corresponding base branch")
+ msg="Release branch in poky must return corresponding 
base branch")
 self.assertEqual(
-comparebranch, None, msg="Repo/branch pair present in 
BUILD_HISTORY_DIRECTPUSH must return corresponding compare branch")
+comparebranch, None, msg="Release branch in poky must return 
corresponding compare branch")
 
 def test_release_langdale(self):
 repo = "ssh://g...@push.yoctoproject.org/poky"
@@ -55,9 +40,9 @@ class TestGetComparisonBranch(unittest.TestCase):
 basebranch, comparebranch = utils.getcomparisonbranch(
 self.TEST_CONFIG, repo, branch)
 self.assertEqual(basebranch, "langdale",
- msg="Repo/branch pair present in 
BUILD_HISTORY_DIRECTPUSH must return corresponding base branch")
+ msg="Release branch in poky must return corresponding 
base branch")
 self.assertEqual(
-comparebranch, None, msg="Repo/branch pair present in 
BUILD_HISTORY_DIRECTPUSH must return corresponding compare branch")
+comparebranch, None, msg="Release branch in poky must return 
corresponding compare branch")
 
 def test_master_next(self):
 repo = "ssh://g...@push.yoctoproject.org/poky"
-- 
2.42.1


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

[yocto] [yocto-autobuilder-helper][mickledore][PATCH 1/3] scripts/utils.py: replace BUILD_HISTORY_DIRECTPUSH with hardcoded condition

[Alexis Lothoré via lists . yoctoproject . org]

From: Alexis Lothoré 

It has been observed that when a new release branch is created, it is quite
easy to forget to update the BUILD_HISTORY_DIRECTPUSH variable, which leads
to failures in autobuilder like test results not being pushed.
Replace the BUILD_HISTORY_DIRECTPUSH usage with a hardcoded condition which
validates any branch in poky representing a "main" branch, i.e all branches
not ending in "-next"

Signed-off-by: Alexis Lothoré 
Signed-off-by: Richard Purdie 
---
 scripts/utils.py | 13 +++--
 1 file changed, 11 insertions(+), 2 deletions(-)

diff --git a/scripts/utils.py b/scripts/utils.py
index 444b3ab55092..36b3e81bfc94 100644
--- a/scripts/utils.py
+++ b/scripts/utils.py
@@ -19,6 +19,15 @@ import fnmatch
 import glob
 import fcntl
 
+
+def is_a_main_branch(reponame, branchname):
+"""
+Checks if target repo/branch combo represent a main branch. This
+includes master and release branches in poky, while excluding "next"
+branches
+"""
+return reponame == "poky" and not branchname.endswith("-next")
+
 #
 # Check if config contains all the listed params
 #
@@ -212,7 +221,7 @@ def getbuildhistoryconfig(ourconfig, builddir, target, 
reponame, branchname, ste
 reponame = reponame.rsplit("/", 1)[1]
 if reponame.endswith(".git"):
 reponame = reponame[:-4]
-if (reponame + ":" + branchname) in 
getconfig("BUILD_HISTORY_DIRECTPUSH", ourconfig):
+if is_a_main_branch(reponame, branchname):
 base = reponame + ":" + branchname
 if (reponame + ":" + branchname) in 
getconfig("BUILD_HISTORY_FORKPUSH", ourconfig):
 base = getconfig("BUILD_HISTORY_FORKPUSH", ourconfig)[reponame 
+ ":" + branchname]
@@ -392,7 +401,7 @@ def getcomparisonbranch(ourconfig, reponame, branchname):
 comparerepo, comparebranch = base.split(":")
 print("Comparing to %s\n" % (comparebranch))
 return branchname, comparebranch
-if (reponame + ":" + branchname) in getconfig("BUILD_HISTORY_DIRECTPUSH", 
ourconfig):
+if is_a_main_branch(reponame, branchname):
 return branchname, None
 return None, None
 
-- 
2.42.1


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

[yocto] [yocto-autobuilder-helper][mickledore][PATCH 0/3] fix mickledore tests reports

[Alexis Lothoré via lists . yoctoproject . org]

Hello,
mickledore release 4.2.4-rc3 suffered some tests reporting issue (tests
result not pushed, regression report not generated, etc). This is due to
the fact that the mickledore branch is not properly described in
BUILD_HISTORY_DIRECTPUSH in config.json. This issue has already received
the following fixes:
- add the missing mickledore entry
- then replaced the quickfix with a rework on BUILD_HISTORY_DIRECTPUSH to
  prevent the issue from occuring on any new future release branch

While those fixes made it to any release since Nanbield, we forgot to
backport it on yocto-autobuilder-helper, so the fixed issue still occurs on
this branch

This series brings the minimal set of patches to be backported **on top of
mickledore branch** on yocto-autobuilder-helper. This is from a bare
cherry-pick session with minimal conflict fixes, and commit tags untouched

Alexis Lothoré (3):
  scripts/utils.py: replace BUILD_HISTORY_DIRECTPUSH with hardcoded
condition
  config.json: remove BUILD_HISTORY_DIRECTPUSH
  scripts/test_utils.py: update test after BUILD_HISTORY_DIRECTPUSH
removal

 config.json   |  1 -
 scripts/test_utils.py | 29 +++--
 scripts/utils.py  | 13 +++--
 3 files changed, 18 insertions(+), 25 deletions(-)

-- 
2.42.1


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

Re: [OT] Not clobbering bash history

[Arsen Arsenović via Emacs news and miscellaneous discussions outside the scope of other Emacs mailing lists]

Richard Stallman  writes:

> [[[ To any NSA and FBI agents reading my email: please consider]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > > If two different shells will try to write history into one single file,
>   > > are they doomed to give bad results, one way or another...
>
>   > Not necessarily.  If both shells use a single write() syscall on an
>   > O_APPEND file, they should work as expected to my awareness.
>
> We are miscommunicating.  The way you expect it to work is, in my
> opinion, a bad result -- various histories interspersed.
>
> It seems to me that the crucial thing is for each Bash process
> to have its own separate history.
>
> Do you think that behavior would be bad?

Bad?  No.  It's not what I'd prefer, though.

Note that, with either separate or interspersed histories, history
should never be lost, so, if a file is being shared by multiple shells
(even if it is not continuously re-read), care should be taken not to
lose data.

>   > If a bash process decides to rotate the history file as a result of
>   > HISTSIZE, and another bash process decides to do the same, one of their
>   > new history entries would be lost due to the other one overriding it.
>   > This would be a bug.
>
> Only if they share one single history file.  If each has its own
> history file, each can handle it as if it were your only Bash process.

Indeed.  How would these histories be recalled, though?  Which file does
a new shell read?
-- 
Arsen Arsenović


signature.asc
Description: PGP signature
---
via emacs-tangents mailing list 
(https://lists.gnu.org/mailman/listinfo/emacs-tangents)

Re: [PING][PATCH 2/2] arm: Add support for MVE Tail-Predicated Low Overhead Loops

[Andre Vieira (lists)]

Thanks for addressing my comments. I have reviewed this and the other 
patch before and they LGTM. I however do not have approval rights so you 
will need the OK from a maintainer.


Thanks for doing this :)

Andre

On 30/11/2023 12:55, Stamatis Markianos-Wright wrote:

Hi Andre,

Thanks for the comments, see latest revision attached.

On 27/11/2023 12:47, Andre Vieira (lists) wrote:

Hi Stam,

Just some comments.

+/* Recursively scan through the DF chain backwards within the basic 
block and
+   determine if any of the USEs of the original insn (or the USEs of 
the insns
s/Recursively scan/Scan/ as you no longer recurse, thanks for that by 
the way :) +   where thy were DEF-ed, etc., recursively) were affected 
by implicit VPT

remove recursively for the same reasons.

+  if (!CONST_INT_P (cond_counter_iv.step) || !CONST_INT_P 
(cond_temp_iv.step))

+    return NULL;
+  /* Look at the steps and swap around the rtx's if needed. Error 
out if

+ one of them cannot be identified as constant.  */
+  if (INTVAL (cond_counter_iv.step) != 0 && INTVAL 
(cond_temp_iv.step) != 0)

+    return NULL;

Move the comment above the if before, as the erroring out it talks 
about is there.

Done


+  emit_note_after ((enum insn_note)NOTE_KIND (insn), BB_END (body));
 space after 'insn_note)'

@@ -173,14 +176,14 @@ doloop_condition_get (rtx_insn *doloop_pat)
   if (! REG_P (reg))
 return 0;
 -  /* Check if something = (plus (reg) (const_int -1)).
+  /* Check if something = (plus (reg) (const_int -n)).
  On IA-64, this decrement is wrapped in an if_then_else.  */
   inc_src = SET_SRC (inc);
   if (GET_CODE (inc_src) == IF_THEN_ELSE)
 inc_src = XEXP (inc_src, 1);
   if (GET_CODE (inc_src) != PLUS
   || XEXP (inc_src, 0) != reg
-  || XEXP (inc_src, 1) != constm1_rtx)
+  || !CONST_INT_P (XEXP (inc_src, 1)))

Do we ever check that inc_src is negative? We used to check if it was 
-1, now we only check it's a constnat, but not a negative one, so I 
suspect this needs a:

|| INTVAL (XEXP (inc_src, 1)) >= 0

Good point. Done


@@ -492,7 +519,8 @@ doloop_modify (class loop *loop, class niter_desc 
*desc,

 case GE:
   /* Currently only GE tests against zero are supported.  */
   gcc_assert (XEXP (condition, 1) == const0_rtx);
-
+  /* FALLTHRU */
+    case GTU:
   noloop = constm1_rtx;

I spent a very long time staring at this trying to understand why 
noloop = constm1_rtx for GTU, where I thought it should've been (count 
& (n-1)). For the current use of doloop it doesn't matter because ARM 
is the only target using it and you set desc->noloop_assumptions to 
null_rtx in 'arm_attempt_dlstp_transform' so noloop is never used. 
However, if a different target accepts this GTU pattern then this 
target agnostic code will do the wrong thing.  I suggest we either:
 - set noloop to what we think might be the correct value, which if 
you ask me should be 'count & (XEXP (condition, 1))',
 - or add a gcc_assert (GET_CODE (condition) != GTU); under the if 
(desc->noloop_assumption); part and document why.  I have a slight 
preference for the assert given otherwise we are adding code that we 
can't test.


Yea, that's true tbh. I've done the latter, but also separated out the 
"case GTU:" and added a comment, so that it's more clear that the noloop 
things aren't used in the only implemented GTU case (Arm)


Thank you :)



LGTM otherwise (but I don't have the power to approve this ;)).

Kind regards,
Andre

From: Stamatis Markianos-Wright 
Sent: Thursday, November 16, 2023 11:36 AM
To: Stamatis Markianos-Wright via Gcc-patches; Richard Earnshaw; 
Richard Sandiford; Kyrylo Tkachov
Subject: [PING][PATCH 2/2] arm: Add support for MVE Tail-Predicated 
Low Overhead Loops


Pinging back to the top of reviewers' inboxes due to worry about Stage 1
End in a few days :)


See the last email for the latest version of the 2/2 patch. The 1/2
patch is A-Ok from Kyrill's earlier target-backend review.


On 10/11/2023 12:41, Stamatis Markianos-Wright wrote:


On 06/11/2023 17:29, Stamatis Markianos-Wright wrote:


On 06/11/2023 11:24, Richard Sandiford wrote:

Stamatis Markianos-Wright  writes:
One of the main reasons for reading the arm bits was to try to 
answer

the question: if we switch to a downcounting loop with a GE
condition,
how do we make sure that the start value is not a large unsigned
number that is interpreted as negative by GE?  E.g. if the loop
originally counted up in steps of N and used an LTU condition,
it could stop at a value in the range [INT_MAX + 1, UINT_MAX].
But the loop might never iterate if we start counting down from
most values in that range.

Does the patch handle that?

So AFAICT this is actually handled in the generic code in
`doloop_valid_p`:

This kind of loops fail because of they are "desc->infinite", then no
loop-doloop conversion is attempted at all (even for standa

Re: [OT] Not clobbering bash history

[Arsen Arsenović via Emacs news and miscellaneous discussions outside the scope of other Emacs mailing lists]

Richard Stallman  writes:

> [[[ To any NSA and FBI agents reading my email: please consider]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> I moved this to emacs-tangents because thus isn't really about Emacs,
> but I don't know of a Bash list to use.  Is there one?

IIRC there's bug-bash and it accepts patches, so it is perhaps also
appropriate for topics like this one.

>   > Say that the history has eight entries, and a ninth was added by a
>   > parallel process, the current process would be at the point after the
>   > eighth element and should continue reading from there next time it wants
>   > a history entry.
>
> Are you saying that multiple Bash processes in parallel should share
> one single history, which would contain all the commands the user
> entered in any of these processes?

Yes.  Opinions vary on this, but I have a workflow which relies on this
(via a hack I put in my bashrc and found ages ago).

> So the commands of Basb process A and those of Basb process B would be
> interspersed in the history?  And as you go forward and back in the
> history in Bash process B, you would see A's commands and B's commands
> in chronological order?

Yes.  ZSH does implement this well IME (but I haven't used ZSH
extensively.. so I'm not sure if I'd run into trouble with it).

> That makes a kind of sense, but what I would envision is that each
> Bash process has its own history with only the commands of that process.

Some do prefer that.  It'd be reasonable to do that by default, as it's
currently the default.

> Why do you prefer the shared history file approach
> to the one-history-per-process approach?

Because I rely on working in many, many interactive shells in parallel.

Though, on that note, it is perhaps reasonable to flip 'histappend' to
on by default, even if nothing else changes (because otherwise history
is lost since only the last shells history is kept).

Thanks, have a lovely day.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature
---
via emacs-tangents mailing list 
(https://lists.gnu.org/mailman/listinfo/emacs-tangents)

veclower: improve selection of vector mode when lowering [PR 112787]

[Andre Vieira (lists)]

Hi,

This patch addresses the issue reported in PR target/112787 by improving the
compute type selection.  We do this by not considering types with more 
elements

than the type we are lowering since we'd reject such types anyway.

gcc/ChangeLog:

PR target/112787
* tree-vect-generic (type_for_widest_vector_mode): Add a parameter to
control maximum amount of elements in resulting vector mode.
(get_compute_type): Restrict vector_compute_type to a mode no wider
than the original compute type.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/pr112787.c: New test.

Bootstrapped and regression tested on aarch64-unknown-linux-gnu and 
x86_64-pc-linux-gnu.


Is this OK for trunk?

Kind regards,
Andre Vieiradiff --git a/gcc/testsuite/gcc.target/aarch64/pr112787.c 
b/gcc/testsuite/gcc.target/aarch64/pr112787.c
new file mode 100644
index 
..caca1bf7ef447e4489b2c134d7200a4afd16763f
--- /dev/null
+++ b/gcc/testsuite/gcc.target/aarch64/pr112787.c
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-additional-options "-O2 -march=armv8-a+sve -mcpu=neoverse-n2" } */
+
+typedef int __attribute__((__vector_size__ (64))) vec;
+
+vec fn (vec a, vec b)
+{
+  return a + b;
+}
+
+/* { dg-final { scan-assembler-times {add\tv[0-9]+} 4 } } */
diff --git a/gcc/tree-vect-generic.cc b/gcc/tree-vect-generic.cc
index 
a7e6cb87a5e31e3dd2a893ea5652eeebf8d5d214..2dbf3c8f5f64f2623944110dbc371fe0944198f0
 100644
--- a/gcc/tree-vect-generic.cc
+++ b/gcc/tree-vect-generic.cc
@@ -1347,7 +1347,7 @@ optimize_vector_constructor (gimple_stmt_iterator *gsi)
TYPE, or NULL_TREE if none is found.  */
 
 static tree
-type_for_widest_vector_mode (tree type, optab op)
+type_for_widest_vector_mode (tree type, optab op, poly_int64 max_nunits = 0)
 {
   machine_mode inner_mode = TYPE_MODE (type);
   machine_mode best_mode = VOIDmode, mode;
@@ -1371,7 +1371,9 @@ type_for_widest_vector_mode (tree type, optab op)
   FOR_EACH_MODE_FROM (mode, mode)
 if (GET_MODE_INNER (mode) == inner_mode
&& maybe_gt (GET_MODE_NUNITS (mode), best_nunits)
-   && optab_handler (op, mode) != CODE_FOR_nothing)
+   && optab_handler (op, mode) != CODE_FOR_nothing
+   && (known_eq (max_nunits, 0)
+   || known_lt (GET_MODE_NUNITS (mode), max_nunits)))
   best_mode = mode, best_nunits = GET_MODE_NUNITS (mode);
 
   if (best_mode == VOIDmode)
@@ -1702,7 +1704,8 @@ get_compute_type (enum tree_code code, optab op, tree 
type)
  || optab_handler (op, TYPE_MODE (type)) == CODE_FOR_nothing))
 {
   tree vector_compute_type
-   = type_for_widest_vector_mode (TREE_TYPE (type), op);
+   = type_for_widest_vector_mode (TREE_TYPE (type), op,
+  TYPE_VECTOR_SUBPARTS (compute_type));
   if (vector_compute_type != NULL_TREE
  && subparts_gt (compute_type, vector_compute_type)
  && maybe_ne (TYPE_VECTOR_SUBPARTS (vector_compute_type), 1U)

Re: [gentoo-user] New installation - not booting

[Wols Lists]

On 06/12/2023 14:56, Peter Humphreey wrote:

The idea is that you may want to install another system later, which may want
to install its own code in /efi. By all means shrink it if you think that's
unlikely and you need the space. Gparted on SysRescCD is ideal for this.


I had the opposite problem - Windows created a tiny EFI partition and I 
couldn't install linux ...


Cheers,
Wol

Re: [gentoo-user] Boot and EFI partitions

[Wols Lists]

On 06/12/2023 16:36, Jack Ostroff wrote:
The way I think of it is that the UEFI firmware needs to find the 
.efi loader, and it can only read FAT32 formatted partitions 
labelled as type esp. That .efi loader then needs to find your 
kernel and related files, but as it is specific for that type of kernel 
(linux) it can know about more partition formatting options. I suspect 
that many (most?/all?) existing linux utilities still expect the boot 
dir to be at /boot, but perhaps the docs are late to change describing 
that it no longer needs to be a separate partition, or perhaps one or 
more of those utilities still requires a partition.


It's not that far off base ... note that Macs use UEFI, but don't have 
FAT32 partitions ...


On the raid wiki I say that you need *some* sort of boot partition, and 
say that if you're using legacy (bios) boot you should really put /boot 
on its own partition so if you decide to go UEFI, you re-purpose that 
partition. It certainly seems weird that systemd-boot would want its own 
partition on top of the efi partition :-)


The UEFI spec basically requires - as a minimum - that the UEFI software 
in rom must be able to read fat32. There is no requirement that that is 
the only format it can read, hence Macs reading the Mac format. If you 
want your own boot rom that can read ext*, that's fine (so long as ext32 
is also available).


Cheers,
Wol

[OE-core] [PATCH] wic/DirectPlugin: don't update fstab if --no-fstab-update

[Jörg Sommer via lists . openembedded . org]

From: Jörg Sommer 

The function `update_fstab` should not touch the fstab for partitions with
`--no-fstab-update`.

Signed-off-by: Jörg Sommer 
---
 scripts/lib/wic/plugins/imager/direct.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/scripts/lib/wic/plugins/imager/direct.py 
b/scripts/lib/wic/plugins/imager/direct.py
index 9b619e41c1..013aa4255f 100644
--- a/scripts/lib/wic/plugins/imager/direct.py
+++ b/scripts/lib/wic/plugins/imager/direct.py
@@ -116,7 +116,7 @@ class DirectPlugin(ImagerPlugin):
 
 updated = False
 for part in self.parts:
-if not part.realnum or not part.mountpoint \
+if not part.realnum or not part.mountpoint or part.no_fstab_update 
\
or part.mountpoint == "/" or not 
(part.mountpoint.startswith('/') or part.mountpoint == "swap"):
 continue
 
-- 
2.34.1


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

Re: Fastly Peering Contact

[Justin Wilson (Lists)]

We have sent them some inquiries in markets we are with no reply.  Just figured 
they weren’t interested.




Justin Wilson
j...@mtin.net
jus...@fd-ix.com
Https://www.fdi-ix.com

> On Dec 5, 2023, at 4:14 PM, Peter Potvin via NANOG  wrote:
> 
> Looking for someone on the Fastly peering team to reach out regarding peering 
> on a couple mutual IXPs - sent an email to the peering contact as listed on 
> PeeringDB and never heard back, and also have a few colleagues who have 
> experienced the same issue.
> 
> Regards,
> Peter Potvin | Executive Director
> --
> Accuris Technologies Ltd.
> 

[meta-xilinx] git.yoctoproject.org/meta-xilinx-tools mickledore branch out of date

[Przemysław Recha via lists . yoctoproject . org]

Hi,
git.yoctoproject.org/meta-xilinx-tools mickledore branch is behind 
https://github.com/Xilinx/meta-xilinx-tools/
Could we get an update to git.yoctoproject.org/meta-xilinx-tools?

Best regards,
Przemek






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

Scanning (documents) no longer works: scanner not found?

[Why 42? The lists account.]

Hi All,

I just noticed that "simple-scan" no longer works, it cannot find my
scanner. This used to work just fine.

I'm running the latest (installed today) snapshot, but I don't know when
this stopped working - I try not to do much scanning :-)

The scanner is a Canon Pixma "Multi Function" device, connected via
Ethernet. (I never ever got it to print.)

Running simple-scan in debug mode doesn't show me much, I see:
> simple-scan -d
> [+0.00s] DEBUG: simple-scan.vala:2015: Starting simple-scan 44.0, PID=91216
> [+0.01s] DEBUG: unsetenv() is not thread-safe and should not be used after 
> threads are created
> [+0.04s] DEBUG: _g_io_module_get_default: Found default implementation gvfs 
> (GDaemonVfs) for ‘gio-vfs’
> [+0.18s] DEBUG: Portal not found: 
> GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
> org.freedesktop.portal.Desktop was not provided by any .service files
> [+0.18s] DEBUG: Portal not found: 
> GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
> org.freedesktop.portal.Desktop was not provided by any .service files
> [+0.18s] DEBUG: Portal not found: 
> GDBus.Error:org.freedesktop.DBus.Error.ServiceUnknown: The name 
> org.freedesktop.portal.Desktop was not provided by any .service files
> [+0.18s] DEBUG: _g_io_module_get_default: Found default implementation dconf 
> (DConfSettingsBackend) for ‘gsettings-backend’
> [+0.18s] WARNING: Using GtkSettings:gtk-application-prefer-dark-theme 
> together with HdyStyleManager is unsupported. Please use 
> HdyStyleManager:color-scheme instead.
> [+0.66s] DEBUG: app-window.vala:2002: Loading state from 
> /home/robb/.config/simple-scan/state
> [+0.66s] DEBUG: app-window.vala:1981: Restoring window to 1002x1235 pixels
> [+0.72s] DEBUG: scanner.vala:1619: sane_init () -> SANE_STATUS_GOOD
> [+0.72s] DEBUG: scanner.vala:1625: SANE version 1.2.1
> [+0.72s] DEBUG: scanner.vala:1686: Requesting redetection of scan devices
> [+0.72s] DEBUG: scanner.vala:863: Processing request
> [+0.86s] DEBUG: app-window.vala:2078: Saving state to 
> /home/robb/.config/simple-scan/state
> [+2.67s] DEBUG: scanner.vala:348: sane_get_devices () -> SANE_STATUS_GOOD
> [+2.67s] DEBUG: platform does not do hotplug, using polling
> ...

I have the saned daemon running, it seems to run OK. No matter what I
tried I have been unable to trick it into logging any debug output e.g.
even with "-d 32" I just see this logged:
> mjoelnir:log 4.12 17:10:14 # grep sane *   
> messages:Dec  4 10:02:07 mjoelnir pkg_add: Added 
> sane-backends-1.2.1p0->1.2.1p0
> messages:Dec  4 16:58:31 mjoelnir pkg_add: Added xsane-0.999p7

(The second message is me adding xsane, but it also fails to find the
scanner.)

The README "sane-backends" ends with this cryptic (to me) advice, but
I don't know what a "scanner device node" is for a thing with an IP
address:
> ...
> NETWORK
> ===
> By default, the saned(8) daemon runs as _saned, so you need to allow the
> _saned user access to the scanner device node.

What am I missing? Any tips for me?

(Oh, I also tried "pfctl -d" to disable the local firewall, didn't seem
to make any difference.)

Cheers,
Robb.

mjoelnir:/etc 4.12 17:14:41 # uname -a
OpenBSD mjoelnir.fritz.box 7.4 GENERIC.MP#1471 amd64

mjoelnir:/etc 4.12 17:14:46 # pkg_info | egrep '(scan|sane)'
arp-scan-1.10.0p1   ARP scanning and fingerprinting tool
nmap-7.91p5 scan ports and fingerprint stack of network hosts
py3-ruamel.yaml.clib-0.2.8 C based reader/scanner and emitter for ruamel.yaml
sane-backends-1.2.1p0 API for accessing scanners, backends
simple-scan-44.0p0  simple scanning utility
unpaper-7.0.0   post-processing tool for scanned paper sheets
xsane-0.999p7   scanner frontend for SANE

mjoelnir:/etc 4.12 17:15:55 # ps aux | grep sane
root 55249  0.0  0.0   880  1236 ??  S   4:36PM0:00.07 
/usr/local/libexec/saned -a -d 32
root  5814  0.0  0.0  3956  2016 p1  R+/25:15PM0:00.00 grep sane 
(zsh)
robb 24135  0.0  0.0  1628  2656 p3  I+p11:52AM0:00.01 less 
sane-backends

Re: [gentoo-user] ffmpeg: WARNING: One or more updates/rebuilds have been skipped due to a dependency conflict

[Wols Lists]

On 04/12/2023 08:28, Dale wrote:

Oh, I see the little  pointing up there but in Konsole, they never
point up to the right place.  If it has a clue, I wouldn't be able to
get help from it.  Also, I have some options in make.conf for emerge so
I'm taking this from emerge.log to show the complete command that is
used.  Keep in mind, I increased backtrack and added changed-deps.


2>&1 tee emerge.log

That should give you the output in a file (emerge.log), and in an editor 
it should all line up (provided the editor is set not to wrap).


Cheers,
Wol

Re: [PATCH 8/8] aarch64: Add SVE support for simd clones [PR 96342]

[Andre Vieira (lists)]

On 29/11/2023 17:01, Richard Sandiford wrote:

"Andre Vieira (lists)"  writes:

Rebased, no major changes, still needs review.

On 30/08/2023 10:19, Andre Vieira (lists) via Gcc-patches wrote:

This patch finalizes adding support for the generation of SVE simd
clones when no simdlen is provided, following the ABI rules where the
widest data type determines the minimum amount of elements in a length
agnostic vector.

gcc/ChangeLog:

      * config/aarch64/aarch64-protos.h (add_sve_type_attribute):
Declare.
  * config/aarch64/aarch64-sve-builtins.cc (add_sve_type_attribute):
Make
  visibility global.
  * config/aarch64/aarch64.cc (aarch64_fntype_abi): Ensure SVE ABI is
  chosen over SIMD ABI if a SVE type is used in return or arguments.
  (aarch64_simd_clone_compute_vecsize_and_simdlen): Create VLA simd
clone
  when no simdlen is provided, according to ABI rules.
  (aarch64_simd_clone_adjust): Add '+sve' attribute to SVE simd clones.
  (aarch64_simd_clone_adjust_ret_or_param): New.
  (TARGET_SIMD_CLONE_ADJUST_RET_OR_PARAM): Define.
  * omp-simd-clone.cc (simd_clone_mangle): Print 'x' for VLA simdlen.
  (simd_clone_adjust): Adapt safelen check to be compatible with VLA
  simdlen.

gcc/testsuite/ChangeLog:

  * c-c++-common/gomp/declare-variant-14.c: Adapt aarch64 scan.
  * gfortran.dg/gomp/declare-variant-14.f90: Likewise.
  * gcc.target/aarch64/declare-simd-1.c: Remove warning checks where no
  longer necessary.
  * gcc.target/aarch64/declare-simd-2.c: Add SVE clone scan.


diff --git a/gcc/config/aarch64/aarch64-protos.h 
b/gcc/config/aarch64/aarch64-protos.h
index 
60a55f4bc1956786ea687fc7cad7ec9e4a84e1f0..769d637f63724a7f0044f48f3dd683e0fb46049c
 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -1005,6 +1005,8 @@ namespace aarch64_sve {
  #ifdef GCC_TARGET_H
bool verify_type_context (location_t, type_context_kind, const_tree, bool);
  #endif
+ void add_sve_type_attribute (tree, unsigned int, unsigned int,
+ const char *, const char *);
  }
  
  extern void aarch64_split_combinev16qi (rtx operands[3]);

diff --git a/gcc/config/aarch64/aarch64-sve-builtins.cc 
b/gcc/config/aarch64/aarch64-sve-builtins.cc
index 
161a14edde7c9fb1b13b146cf50463e2d78db264..6f99c438d10daa91b7e3b623c995489f1a8a0f4c
 100644
--- a/gcc/config/aarch64/aarch64-sve-builtins.cc
+++ b/gcc/config/aarch64/aarch64-sve-builtins.cc
@@ -569,14 +569,16 @@ static bool reported_missing_registers_p;
  /* Record that TYPE is an ABI-defined SVE type that contains NUM_ZR SVE 
vectors
 and NUM_PR SVE predicates.  MANGLED_NAME, if nonnull, is the ABI-defined
 mangling of the type.  ACLE_NAME is the  name of the type.  */
-static void
+void
  add_sve_type_attribute (tree type, unsigned int num_zr, unsigned int num_pr,
const char *mangled_name, const char *acle_name)
  {
tree mangled_name_tree
  = (mangled_name ? get_identifier (mangled_name) : NULL_TREE);
+  tree acle_name_tree
+= (acle_name ? get_identifier (acle_name) : NULL_TREE);
  
-  tree value = tree_cons (NULL_TREE, get_identifier (acle_name), NULL_TREE);

+  tree value = tree_cons (NULL_TREE, acle_name_tree, NULL_TREE);
value = tree_cons (NULL_TREE, mangled_name_tree, value);
value = tree_cons (NULL_TREE, size_int (num_pr), value);
value = tree_cons (NULL_TREE, size_int (num_zr), value);
diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index 
37507f091c2a6154fa944c3a9fad6a655ab5d5a1..cb0947b18c6a611d55579b5b08d93f6a4a9c3b2c
 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -4080,13 +4080,13 @@ aarch64_takes_arguments_in_sve_regs_p (const_tree 
fntype)
  static const predefined_function_abi &
  aarch64_fntype_abi (const_tree fntype)
  {
-  if (lookup_attribute ("aarch64_vector_pcs", TYPE_ATTRIBUTES (fntype)))
-return aarch64_simd_abi ();
-
if (aarch64_returns_value_in_sve_regs_p (fntype)
|| aarch64_takes_arguments_in_sve_regs_p (fntype))
  return aarch64_sve_abi ();
  
+  if (lookup_attribute ("aarch64_vector_pcs", TYPE_ATTRIBUTES (fntype)))

+return aarch64_simd_abi ();
+
return default_function_abi;
  }
  


I think we discussed this off-list later, but the change above shouldn't
be necessary.  aarch64_vector_pcs must not be attached to SVE PCS functions,
so the two cases should be mutually exclusive.


Yeah I had made the changes locally, but not updated the patch yet.



@@ -27467,7 +27467,7 @@ aarch64_simd_clone_compute_vecsize_and_simdlen (struct 
cgraph_node *node,
int num, bool explicit_p)
  {
tree t, ret_type;
-  unsigned int nds_elt_bits;
+  unsigned int nds_elt_bits, wds_elt_bits;
int count;
unsigned HOST_WIDE_INT const_simdlen;
  
@@ -27513,10 +27513,14 @@ aarch64_simd_clone_compute_vecsize_and

Re: [PATCH] testsuite, arm: Fix up pr112337.c test

[Richard Earnshaw (lists)]

On 01/12/2023 13:45, Christophe Lyon wrote:
> On Fri, 1 Dec 2023 at 13:44, Richard Earnshaw (lists)
>  wrote:
>>
>> On 01/12/2023 11:28, Saurabh Jha wrote:
>>> Hey,
>>>
>>> I introduced this test "gcc/testsuite/gcc.target/arm/mve/pr112337.c" in 
>>> this commit 2365aae84de030bbb006edac18c9314812fc657b before. This had an 
>>> error which I unfortunately missed. This patch fixes that test.
>>>
>>> Did regression testing on arm-none-eabi and found no regressions. Output of 
>>> running gcc/contrib/compare_tests is this:
>>>
>>> """
>>> Tests that now work, but didn't before (2 tests):
>>>
>>> arm-eabi-aem/-marm/-march=armv7-a/-mfpu=vfpv3-d16/-mfloat-abi=softfp: 
>>> gcc.target/arm/mve/pr112337.c (test for excess errors)
>>> arm-eabi-aem/-mthumb/-march=armv8-a/-mfpu=crypto-neon-fp-armv8/-mfloat-abi=hard:
>>>  gcc.target/arm/mve/pr112337.c (test for excess errors)
>>> """
>>>
>>> Ok for trunk? I don't have commit access so could someone please commit on 
>>> my behalf?
>>>
>>> Regards,
>>> Saurabh
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> * gcc.target/arm/mve/pr112337.c: Fix the testcase
>>
>>
>> Hmm, could this be related to the changes Christophe made recently to change 
>> the way MVE vector types were set up internally?  If so, this might indicate 
>> an issue that's going to affect real users with existing code.
>>
> 
> My change was only about vector types, here the problem is with a
> pointer to a scalar.
> Anyway, I ran the test with my commit reverted and it still fails in
> the same way, so I think this patch is needed.
> 
> Thanks,
> 
> Christophe
> 
>> Christophe?
>>
>> R.

Ok, thanks for checking.  In that case, Saurabh, your patch is OK, but please 
change 'Fix testcase' to 'Use int32_t instead of int.'

Note that ChangeLog entries end with a full stop.

R.

Re: [PATCH] testsuite, arm: Fix up pr112337.c test

[Richard Earnshaw (lists)]

On 01/12/2023 11:28, Saurabh Jha wrote:
> Hey,
> 
> I introduced this test "gcc/testsuite/gcc.target/arm/mve/pr112337.c" in this 
> commit 2365aae84de030bbb006edac18c9314812fc657b before. This had an error 
> which I unfortunately missed. This patch fixes that test.
> 
> Did regression testing on arm-none-eabi and found no regressions. Output of 
> running gcc/contrib/compare_tests is this:
> 
> """
> Tests that now work, but didn't before (2 tests):
> 
> arm-eabi-aem/-marm/-march=armv7-a/-mfpu=vfpv3-d16/-mfloat-abi=softfp: 
> gcc.target/arm/mve/pr112337.c (test for excess errors)
> arm-eabi-aem/-mthumb/-march=armv8-a/-mfpu=crypto-neon-fp-armv8/-mfloat-abi=hard:
>  gcc.target/arm/mve/pr112337.c (test for excess errors)
> """
> 
> Ok for trunk? I don't have commit access so could someone please commit on my 
> behalf?
> 
> Regards,
> Saurabh
> 
> gcc/testsuite/ChangeLog:
> 
>     * gcc.target/arm/mve/pr112337.c: Fix the testcase


Hmm, could this be related to the changes Christophe made recently to change 
the way MVE vector types were set up internally?  If so, this might indicate an 
issue that's going to affect real users with existing code.

Christophe?

R.

Re: [gentoo-user] [OT] Very slow POST process

[Wols Lists]

On 29/11/2023 00:16, Michael wrote:

Thanks Dan, will do.  I was planning to take it apart soon to replace the HDD
with an SSD, so this would be the first thing to check.  I expect finding a
replacement unit will be difficult.  Every Lenovo RTC battery seems to have a
different part number.


I know laptops are different from desktops, but I think every desktop 
mobo I've come across uses a 3032 battery.


See if you can find out what the standard definition of the lenovo 
battery is, hopefully they just use internal part numbers for a totally 
standard item.


Cheers,
Wol

Re: [RFC] vect: disable multiple calls of poly simdclones

[Andre Vieira (lists)]

On 06/11/2023 07:52, Richard Biener wrote:

On Fri, 3 Nov 2023, Andre Vieira (lists) wrote:


Hi,

The current codegen code to support VF's that are multiples of a simdclone
simdlen rely on BIT_FIELD_REF to create multiple input vectors.  This does not
work for non-constant simdclones, so we should disable using such clones when
the VF is a multiple of the non-constant simdlen until we change the codegen
to support those.

Enabling SVE simdclone support will cause ICEs if the vectorizer decides to
use a SVE simdclone with a VF that is larger than the simdlen. I'll be away
for the next two weeks, so cant' really discuss this further.
I initially tried to solve the problem, but the way
vectorizable_simd_clone_call is structured doesn't make it easy to replace
BIT_FIELD_REF with the poly-suitable solution right now of using
unpack_{hi,lo}.


I think it should be straight-forward to use unpack_{even,odd} (it's
even/odd for VLA, right?  If lo/hi would be possible then doing
BIT_FIELD_REF would be, too?  Also you need to have multiple stages
of unpack/pack when the factor is more than 2).

There's plenty of time even during stage3 to address this.

At least your patch should have come with a testcase (or two).


Yeah I didn't add one as it didn't trigger on AArch64 without my two 
outstanding aarch64 simdclone patches.


Is there a bugreport tracking this issue?  It should affect GCN as well
I guess.


No, since I can't trigger them yet on trunk until the reviews on my 
target specific patches are done and they are committed.


I don't have a GCN backend lying around but I suspect GCN doesn't use 
poly simdlen simdclones yet either... I haven't checked. The issue 
triggers for aarch64 when trying to generate SVE simdclones for 
functions with mixed types.  I'll give the unpack thing a go locally.

Re: [PING][PATCH 2/2] arm: Add support for MVE Tail-Predicated Low Overhead Loops

[Andre Vieira (lists)]

Hi Stam,

Just some comments.

+/* Recursively scan through the DF chain backwards within the basic 
block and
+   determine if any of the USEs of the original insn (or the USEs of 
the insns
s/Recursively scan/Scan/ as you no longer recurse, thanks for that by 
the way :) +   where thy were DEF-ed, etc., recursively) were affected 
by implicit VPT

remove recursively for the same reasons.

+  if (!CONST_INT_P (cond_counter_iv.step) || !CONST_INT_P 
(cond_temp_iv.step))

+   return NULL;
+  /* Look at the steps and swap around the rtx's if needed.  Error 
out if

+one of them cannot be identified as constant.  */
+  if (INTVAL (cond_counter_iv.step) != 0 && INTVAL 
(cond_temp_iv.step) != 0)

+   return NULL;

Move the comment above the if before, as the erroring out it talks about 
is there.


+  emit_note_after ((enum insn_note)NOTE_KIND (insn), BB_END (body));
 space after 'insn_note)'

@@ -173,14 +176,14 @@ doloop_condition_get (rtx_insn *doloop_pat)
   if (! REG_P (reg))
 return 0;
 -  /* Check if something = (plus (reg) (const_int -1)).
+  /* Check if something = (plus (reg) (const_int -n)).
  On IA-64, this decrement is wrapped in an if_then_else.  */
   inc_src = SET_SRC (inc);
   if (GET_CODE (inc_src) == IF_THEN_ELSE)
 inc_src = XEXP (inc_src, 1);
   if (GET_CODE (inc_src) != PLUS
   || XEXP (inc_src, 0) != reg
-  || XEXP (inc_src, 1) != constm1_rtx)
+  || !CONST_INT_P (XEXP (inc_src, 1)))

Do we ever check that inc_src is negative? We used to check if it was 
-1, now we only check it's a constnat, but not a negative one, so I 
suspect this needs a:

|| INTVAL (XEXP (inc_src, 1)) >= 0

@@ -492,7 +519,8 @@ doloop_modify (class loop *loop, class niter_desc *desc,
 case GE:
   /* Currently only GE tests against zero are supported.  */
   gcc_assert (XEXP (condition, 1) == const0_rtx);
-
+  /* FALLTHRU */
+case GTU:
   noloop = constm1_rtx;

I spent a very long time staring at this trying to understand why noloop 
= constm1_rtx for GTU, where I thought it should've been (count & 
(n-1)). For the current use of doloop it doesn't matter because ARM is 
the only target using it and you set desc->noloop_assumptions to 
null_rtx in 'arm_attempt_dlstp_transform' so noloop is never used. 
However, if a different target accepts this GTU pattern then this target 
agnostic code will do the wrong thing.  I suggest we either:
 - set noloop to what we think might be the correct value, which if you 
ask me should be 'count & (XEXP (condition, 1))',
 - or add a gcc_assert (GET_CODE (condition) != GTU); under the if 
(desc->noloop_assumption); part and document why.  I have a slight 
preference for the assert given otherwise we are adding code that we 
can't test.


LGTM otherwise (but I don't have the power to approve this ;)).

Kind regards,
Andre

From: Stamatis Markianos-Wright 
Sent: Thursday, November 16, 2023 11:36 AM
To: Stamatis Markianos-Wright via Gcc-patches; Richard Earnshaw; Richard 
Sandiford; Kyrylo Tkachov
Subject: [PING][PATCH 2/2] arm: Add support for MVE Tail-Predicated Low 
Overhead Loops


Pinging back to the top of reviewers' inboxes due to worry about Stage 1
End in a few days :)


See the last email for the latest version of the 2/2 patch. The 1/2
patch is A-Ok from Kyrill's earlier target-backend review.


On 10/11/2023 12:41, Stamatis Markianos-Wright wrote:


On 06/11/2023 17:29, Stamatis Markianos-Wright wrote:


On 06/11/2023 11:24, Richard Sandiford wrote:

Stamatis Markianos-Wright  writes:

One of the main reasons for reading the arm bits was to try to answer
the question: if we switch to a downcounting loop with a GE
condition,
how do we make sure that the start value is not a large unsigned
number that is interpreted as negative by GE?  E.g. if the loop
originally counted up in steps of N and used an LTU condition,
it could stop at a value in the range [INT_MAX + 1, UINT_MAX].
But the loop might never iterate if we start counting down from
most values in that range.

Does the patch handle that?

So AFAICT this is actually handled in the generic code in
`doloop_valid_p`:

This kind of loops fail because of they are "desc->infinite", then no
loop-doloop conversion is attempted at all (even for standard
dls/le loops)

Thanks to that check I haven't been able to trigger anything like the
behaviour you describe, do you think the doloop_valid_p checks are
robust enough?

The loops I was thinking of are provably not infinite though. E.g.:

   for (unsigned int i = 0; i < UINT_MAX - 100; ++i)
 ...

is known to terminate.  And doloop conversion is safe with the normal
count-down-by-1 approach, so I don't think current code would need
to reject it.  I.e. a conversion to:

   unsigned int i = UINT_MAX - 101;
   do
 ...
   while (--i != ~0U);

would be safe, but a conversion to:

   int i = UINT_MAX - 101;
   do
 ...
   while ((i -= step, i > 0));

wouldn't, 

Re: [gentoo-user] Re: Portage reports preserved libs, but won't rebuild

[Wols Lists]

On 24/11/2023 10:27, Nuno Silva wrote:

On 2023-11-24, Arve Barsnes wrote:


On Fri, 24 Nov 2023 at 04:07, Jack  wrote:


May or may not help, but have you tried revdep-rebuild?


Also, you can try just one-shotting the reported packages, such as
(for the last one in your list):

emerge -1 sys-libs/zlib

Regards,
Arve


Shouldn't it be the other way around? I mean, isn't it freetype,
harfbuzz, glib and libpng which need to be rebuilt so that these
libraries from sys-libs/zlib and bzip2, libpcre2, graphite2, ..., are
not needed and get removed?


I regularly get "nothing to update".

I strongly suspect it's because libfreetype and harfbuzz are circular 
dependencies.


When I've built a couple of systems I regularly get "unable to install 
harfbuzz because it needs libfreetype which it can't install because it 
needs harfbuzz ..." You need to force-build one, and then it's happy.


So that's probably messed up @revdep-rebuild.

Cheers,
Wol

Re: [OT] Not clobbering bash history

[Jens Schmidt via Emacs news and miscellaneous discussions outside the scope of other Emacs mailing lists]

On 2023-11-23  13:42, Spencer Baugh wrote:
> Arsen Arsenović  writes:
>
>> Unfortunately, I have been unable to produce a decent set of
>> reproduction steps.  This issue happens (relatively) infrequently and
>> inexplicably on my machines.  It pains me to complain without solid
>> information.
>>
>> I also have shopt -s histappend set.
>>
>> I suspect that something starts a bash process and does not set
>> histappend (--norc?), leading bash to override history.
> 
> I've always suspected TRAMP of this.

Arsen's problem description rang a bell ... on my development server
at work I configure a non-standard history file in my .bashrc.  And
regardless of that, every now and then, the default ~/.bash_history
gets created.

So probably a work-around for your overwrite problems could be exactly
that: Just configure HISTFILE=~/.my_hidden_bash_history near the same
spot where you set 'shopt -s histappend'.  Any villain not respecting
the latter won't (hopefully) respect the former as well, leaving your
non-default Bash history untouched.  (Unless you have tried that
already, of course.)

Besides that, the contents and timestamp of the default ~/.bash_history,
should it still get created, could then help finding the villain.


---
via emacs-tangents mailing list 
(https://lists.gnu.org/mailman/listinfo/emacs-tangents)

Re: [OT] Not clobbering bash history

[Arsen Arsenović via Emacs news and miscellaneous discussions outside the scope of other Emacs mailing lists]

Jens Schmidt  writes:

> Moving to tangents ... please CC me.
>
> On 2023-11-22  04:32, Arsen Arsenović wrote:
>
>>> Should we suggest that the Bash developer add a feature to handle this
>>> case (multiple shells in parallel) the "right" way?  If many users
>>> would like it, that could make it worth building in.
>> 
>> That would be very nice.  This issue has almost been prolific enough to
>> force me to switch shells.
>
> This Bash-bashing made me curious, as I do not remember having issues
> with loss of its history, ever.

I do not partake in bash-bashing enthusiastically.  I'm a big fan of
readline and appreciate how reliable bash is.

> And that without such tricks as using an ever growing history file.  I
> just use "shopt -s histappend" and 4096 lines as HISTFILESIZE.  Plus I
> close my Bashes orderly before shutting down.  Plus I do not use Bash
> from Emacs, only in "real" terminals.  Eh, plus I rarely use nested
> Bashes.
>
> So given all that, is there a reproducer for this?

Unfortunately, I have been unable to produce a decent set of
reproduction steps.  This issue happens (relatively) infrequently and
inexplicably on my machines.  It pains me to complain without solid
information.

I also have shopt -s histappend set.

I suspect that something starts a bash process and does not set
histappend (--norc?), leading bash to override history.

I wonder whether, in general, if bash (libhistory?) was written with the
assumption of multiple processes writing to the history file, so that it
keeps its history in sync with other bash processes, problems of this
category would go away.
-- 
Arsen Arsenović


signature.asc
Description: PGP signature
---
via emacs-tangents mailing list 
(https://lists.gnu.org/mailman/listinfo/emacs-tangents)

Re: [PATCH] AArch64/testsuite: Use non-capturing parentheses with ccmp_1.c

[Richard Earnshaw (lists)]

On 22/11/2023 15:21, Maciej W. Rozycki wrote:
> Use non-capturing parentheses for the subexpressions used with 
> `scan-assembler-times', to avoid a quirk with double-counting.
> 
>   gcc/testsuite/
>   * gcc.target/aarch64/ccmp_1.c: Use non-capturing parentheses 
>   with `scan-assembler-times'.

OK

R.

> ---
> Hi,
> 
>  Here's another one.  I realised my original regexp used to grep the tree 
> for `scan-assembler-times' with subexpressions was too strict and with an 
> updated pattern I found this second test case that does regress once the 
> `scan-assembler-times' double-counting quirk has been fixed.
> 
>  As with the ARM change we don't need capturing parentheses here, usually 
> used for back references, so let's just avoid the double-counting quirk 
> altogether and make our matching here work whether the quirk has been 
> fixed or not.
> 
>  Verified for the `aarch64-linux-gnu' target with the quirk fix submitted 
> as  
> and the aarch64.exp subset of the C language test suite.  OK to apply?
> 
>   Maciej
> ---
>  gcc/testsuite/gcc.target/aarch64/ccmp_1.c |4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> gcc-aarch64-test-ccmp_1-non-capturing.diff
> Index: gcc/gcc/testsuite/gcc.target/aarch64/ccmp_1.c
> ===
> --- gcc.orig/gcc/testsuite/gcc.target/aarch64/ccmp_1.c
> +++ gcc/gcc/testsuite/gcc.target/aarch64/ccmp_1.c
> @@ -86,8 +86,8 @@ f13 (int a, int b)
>  /* { dg-final { scan-assembler "cmp\t(.)+35" } } */
>  
>  /* { dg-final { scan-assembler-times "\tcmp\tw\[0-9\]+, 0" 4 } } */
> -/* { dg-final { scan-assembler-times "fcmpe\t(.)+0\\.0" 2 } } */
> -/* { dg-final { scan-assembler-times "fcmp\t(.)+0\\.0" 2 } } */
> +/* { dg-final { scan-assembler-times "fcmpe\t(?:.)+0\\.0" 1 } } */
> +/* { dg-final { scan-assembler-times "fcmp\t(?:.)+0\\.0" 1 } } */
>  
>  /* { dg-final { scan-assembler "adds\t" } } */
>  /* { dg-final { scan-assembler-times "\tccmp\t" 11 } } */

Re: [OT] Not clobbering bash history

[Jens Schmidt via Emacs news and miscellaneous discussions outside the scope of other Emacs mailing lists]

Moving to tangents ... please CC me.

On 2023-11-22  04:32, Arsen Arsenović wrote:

>> Should we suggest that the Bash developer add a feature to handle this
>> case (multiple shells in parallel) the "right" way?  If many users
>> would like it, that could make it worth building in.
> 
> That would be very nice.  This issue has almost been prolific enough to
> force me to switch shells.

This Bash-bashing made me curious, as I do not remember having issues with
loss of its history, ever.  And that without such tricks as using an ever
growing history file.  I just use "shopt -s histappend" and 4096 lines as
HISTFILESIZE.  Plus I close my Bashes orderly before shutting down.  Plus
I do not use Bash from Emacs, only in "real" terminals.  Eh, plus I rarely
use nested Bashes.

So given all that, is there a reproducer for this?

---
via emacs-tangents mailing list 
(https://lists.gnu.org/mailman/listinfo/emacs-tangents)

Re: ipv6 address management - documentation

[Justin Wilson (Lists)]

Netbox or PHPipam. Phpipam allows you to break down subnets easier IMHo.


Justin Wilson
j...@j2sw.com

—
https://j2sw.com (AS399332)
https://blog.j2sw.com - Podcast and Blog

> On Nov 16, 2023, at 1:09 PM, Jason Biel  wrote:
> 
> My recommendation:
> 
> https://github.com/netbox-community
> 
> 
> On Thu, Nov 16, 2023 at 12:04 PM Aaron Gould  > wrote:
>> For years I've used an MS Excel spreadsheet to manage my IPv4 
>> addresses.  IPv6 is going to be maddening to manage in a spreadsheet.  
>> What does everyone use for their IPv6 address prefix management and 
>> documentation?  Are there open source tools/apps for this?
>> 
>> -- 
>> -Aaron
>> 
> 
> 
> --
> Jason

Re: [gentoo-user] Emerge -K ignoring new packages

[Wols Lists]

On 20/11/2023 17:12, Vitaliy Perekhovy wrote:

On Mon, Nov 20, 2023 at 05:07:45PM +, Peter Humphrey wrote:

Hello list,

Now that I have my NFS set up (with help - thanks) the next problem is that,
having new packages built by my workstation over NFS, emerge on the tiny box
is ignoring all those new packages. And yes, I have checked that they do
exist, and in the right place: /var/cache/packages/ .

The man page says that any new package will cause a remerge, so what has
tripped me up this time?

--
Regards,
Peter.


Default location for binary packages is /var/cache/binpkgs/

Can't remember what I did, but the first thing to check is you're using 
the same make flags (unless of course, you're sharing /etc/portage).


Then I seem to remember using -bK or something like that. So the command 
I'm giving emerge is "use a binary if you can find it, otherwise build it".


Because I might emerge packages on either machine, that worked great for 
me. And I actually usually emerged stuff on the slower machine, because 
it was more reliable ... :-)


Cheers,
Wol

Re: Issues with new NTFS module

[Genes Lists]

On 11/18/23 07:18, Giovanni Santini wrote:
...

Let's hope the problem gets solved soon. :)



Hi

You may have mentioned this already, but is there anything interesting 
in the kernel logs?


I see no relevant looking ntfs3 commits in the kernel after 6.6.
There were some in 6.6 [1].

Since linux-lts (6.1) is behaving differently for you than 6.6.1 you may 
want to report this upstream [2].


It could be that the above commit is related to your problem - you could 
try building a 6.6.1 kernel with it reverted and see if things work. If 
not, maybe do git bisect if you're comfortable doing that.


You may also want to be aware of: https://lore.kernel.org/ntfs3/

gene


[1] commit f69d00d12fcee9ce4b4f24bf609ad7398d10a576
Merge: 7cf4bea77ab6 e4494770a5ca
Author: Linus Torvalds 
Date:   Thu Oct 19 09:10:18 2023 -0700

Merge tag 'ntfs3_for_6.6' of 
https://github.com/Paragon-Software-Group/linux-ntfs3


[2] https://www.kernel.org/doc/html/v4.19/admin-guide/reporting-bugs.html.

   N.B. bugzilla.kernel.org is now monitored and bugs are pulled out 
and emailed to maintainers and tracked.

Re: [meta-virtualization][kirkstone] packagegroup-container: require ipv6 for podman

[Jörg Sommer via lists . yoctoproject . org]

On 08.11.23 14:57, Bruce Ashfield wrote:
> I'll do this as a cherry-pick, since when I apply this patch:

That's fine.

> remote: ##
> remote: Invalid author Jörg Sommer via lists.yoctoproject.org
> remote: ##
> To ssh://push.yoctoproject.org/meta-virtualization
>  ! [remote rejected] kirkstone -> kirkstone (pre-receive hook declined)
> error: failed to push some refs to
> 'ssh://push.yoctoproject.org/meta-virtualization'
> 
> Which is fixable via:
> 
> https://docs.yoctoproject.org/contributor-guide/submit-changes.html#fixing-your-from-identity

Thanks for this hint. I'll apply the setting for future commits. I
didn't know this.


Kind regards

Jörg Sommer
-- 
Navimatix GmbH
Tatzendpromenade 2
D-07745 Jena
Geschäftsführer: Steffen Späthe, Jan Rommeley
Registergericht: Amtsgericht Jena, HRB 501480


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

Re: [oe] [PATCH] [meta classes] sed -i destroys symlinks

[Jörg Sommer via lists . openembedded . org]

On 07.11.23 21:24, Joakim Tjernlund via lists.openembedded.org wrote:
> In /etc/passwd is a symlink, sed -i on same file will replace the

I suspect the »In« should be an »If«

> symlink with a new file. Prevent that by expanding the file with realpath
> before giving it to sed.

Using `sed -i` could be used in many places; e.g. /etc/hosts. Maybe the
replacement with a symlink should happen after all other scripts are
done. Would this be possible?


Kind regards

Jörg Sommer
-- 
Navimatix GmbH
Tatzendpromenade 2
D-07745 Jena
Geschäftsführer: Steffen Späthe, Jan Rommeley
Registergericht: Amtsgericht Jena, HRB 501480


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

[meta-virtualization][kirkstone] packagegroup-container: require ipv6 for podman

[Jörg Sommer via lists . yoctoproject . org]

The recipe *podman* requires the distro feature *ipv6*. Using a distro
without it causes the build of *packagegroup-container* fails, even if
*packagegroup-podman* is not used:

ERROR: Nothing RPROVIDES 'podman' (but 
/build/../work/layers-3rdparty/meta-virtualization/recipes-core/packagegroups/packagegroup-container.bb
 RDEPENDS on or otherwise requires it)
podman was skipped: missing required distro feature 'ipv6' (not in 
DISTRO_FEATURES)
NOTE: Runtime target 'podman' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['podman']
NOTE: Runtime target 'packagegroup-docker' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['packagegroup-docker', 
'podman']

Signed-off-by: Jörg Sommer 
Cherry-pick-of: 002aaf7029b8002acc69c9d4beea89039410d7cd
---
 recipes-core/packagegroups/packagegroup-container.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-core/packagegroups/packagegroup-container.bb 
b/recipes-core/packagegroups/packagegroup-container.bb
index 8d418e95..8309a086 100644
--- a/recipes-core/packagegroups/packagegroup-container.bb
+++ b/recipes-core/packagegroups/packagegroup-container.bb
@@ -9,7 +9,7 @@ PACKAGES = "\
 packagegroup-lxc \
 packagegroup-docker \
 packagegroup-oci \
-${@bb.utils.contains('DISTRO_FEATURES', 'seccomp', \
+${@bb.utils.contains('DISTRO_FEATURES', 'seccomp ipv6', \
  'packagegroup-podman', '', d)} \
 packagegroup-containerd \
 "
-- 
2.34.1


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

Re: [OE-Core][PATCH] scripts/resulttool: group all regressions in regression report

[Alexis Lothoré via lists . openembedded . org]

Hi Richard,
sorry for the late reply. I see that you have decided to apply the patch in the
mean time, but here are my comments

On 11/4/23 04:13, Richard Purdie wrote:
> On Fri, 2023-11-03 at 13:50 -0700, Alexis Lothoré via
> lists.openembedded.org wrote:
>> From: Alexis Lothoré 
>> 5 regression(s) for oescripts
>> oescripts.OEGitproxyTests.test_oegitproxy_proxy_dash: PASSED -> SKIPPED
>> oescripts.OEPybootchartguyTests.test_pybootchartguy_help: PASSED -> 
>> SKIPPED
>> 
>> oescripts.OEPybootchartguyTests.test_pybootchartguy_to_generate_build_pdf_output:
>>  PASSED -> SKIPPED
>> 
>> oescripts.OEPybootchartguyTests.test_pybootchartguy_to_generate_build_png_output:
>>  PASSED -> SKIPPED
>> 
>> oescripts.OEPybootchartguyTests.test_pybootchartguy_to_generate_build_svg_output:
>>  PASSED -> SKIPPED
>>
> 
> Do you have a different example? This one is tricky as I happen to know
> that test depends on the host distro and the things available there.
> There are some distros it will pass on, there are some where it is
> always skipped. There was a recipetool test added recently which will
> do something similar depending upon host python version.

If not already done, you can take a look at the report I have manually generated
for 4.3.rc2 (https://pastebin.com/fvRcqes4) which relies on this patch

> The challenge is we run the test on different host distros so it is
> hard to see it as a regression. I don't know what we can do to make
> this "clear" to the report reader...
> 
> The patch is probably ok as it doesn't make the output worse but it has
> probably already obfuscated things a bit.

I am not sure if this patch obfuscates things more, since it is mostly about
grouping regressions to avoid the repeated "1 regression(s) for <..>". I would
say it _may_ obfuscate some things if there are a lot of regressions for the
same test kind  (so the display limit is triggered) AND some tests of this
specific kind are meant to run on specific distros while some others must run on
multiple. In this case, indeed, there may be a mix of (legitimately) skipped
tests and real failing tests, hidden by the display limit. But is it the case ?

Anyway, I agree with you about the main issue (false positive due to tests not
meant to be compared between some distros/machines), but I did not find time yet
to take a better look at this and propose something relevant while making sure
not to loose any relevant comparison. The "dumb" way could be to detect that all
tests in a result have a "SKIPPED" status on target side, which hints about
those tests not being relevant for the target (in this case, we could simply
silently discard the comparison), but I have to ensure it is valid for most 
cases.

Alexis

> 
> Cheers,
> 
> Richar

-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


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

[OE-Core][PATCH] scripts/resulttool: group all regressions in regression report

[Alexis Lothoré via lists . openembedded . org]

From: Alexis Lothoré 

Commit c304fcbe0588b1078373558c2ddf36064bcdf214 introduced a grouping when
listing regressions. This grouping has been added only for ptests. It has
been observed that any other kind of tests could benefit from it. For
example, current regression reports can show the following:

1 regression(s) for oescripts.OEGitproxyTests.test_oegitproxy_proxy_dash
oescripts.OEGitproxyTests.test_oegitproxy_proxy_dash: PASSED -> SKIPPED
1 regression(s) for oescripts.OEPybootchartguyTests.test_pybootchartguy_help
oescripts.OEPybootchartguyTests.test_pybootchartguy_help: PASSED -> SKIPPED
1 regression(s) for 
oescripts.OEPybootchartguyTests.test_pybootchartguy_to_generate_build_pdf_output

oescripts.OEPybootchartguyTests.test_pybootchartguy_to_generate_build_pdf_output:
 PASSED -> SKIPPED
1 regression(s) for 
oescripts.OEPybootchartguyTests.test_pybootchartguy_to_generate_build_png_output

oescripts.OEPybootchartguyTests.test_pybootchartguy_to_generate_build_png_output:
 PASSED -> SKIPPED
1 regression(s) for 
oescripts.OEPybootchartguyTests.test_pybootchartguy_to_generate_build_svg_output

oescripts.OEPybootchartguyTests.test_pybootchartguy_to_generate_build_svg_output:
 PASSED -> SKIPPED
[...]

This output is not so useful in its current state and should be grouped per
test type too.
Enable grouping for all kind of tests, to make it llok like the following
in reports:
5 regression(s) for oescripts
oescripts.OEGitproxyTests.test_oegitproxy_proxy_dash: PASSED -> SKIPPED
oescripts.OEPybootchartguyTests.test_pybootchartguy_help: PASSED -> SKIPPED

oescripts.OEPybootchartguyTests.test_pybootchartguy_to_generate_build_pdf_output:
 PASSED -> SKIPPED

oescripts.OEPybootchartguyTests.test_pybootchartguy_to_generate_build_png_output:
 PASSED -> SKIPPED

oescripts.OEPybootchartguyTests.test_pybootchartguy_to_generate_build_svg_output:
 PASSED -> SKIPPED

Signed-off-by: Alexis Lothoré 
---
 scripts/lib/resulttool/regression.py | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/scripts/lib/resulttool/regression.py 
b/scripts/lib/resulttool/regression.py
index 8fbe5a54783a..10e7d13841a7 100644
--- a/scripts/lib/resulttool/regression.py
+++ b/scripts/lib/resulttool/regression.py
@@ -236,7 +236,8 @@ def compare_result(logger, base_name, target_name, 
base_result, target_result, d
 for k in sorted(result):
 if not result[k]['target'] or not 
result[k]['target'].startswith("PASS"):
 # Differentiate each ptest kind when listing regressions
-key = '.'.join(k.split('.')[:2]) if k.startswith('ptest') 
else k
+key_parts = k.split('.')
+key = '.'.join(key_parts[:2]) if k.startswith('ptest') 
else key_parts[0]
 # Append new regression to corresponding test family
 regressions[key] = regressions.setdefault(key, []) + ['
%s: %s -> %s\n' % (k, get_status_str(result[k]['base']), 
get_status_str(result[k]['target']))]
 resultstring += f"Total: {sum([len(regressions[r]) for r in 
regressions])} new regression(s):\n"
-- 
2.42.0


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

[RFC] vect: disable multiple calls of poly simdclones

[Andre Vieira (lists)]

Hi,

The current codegen code to support VF's that are multiples of a 
simdclone simdlen rely on BIT_FIELD_REF to create multiple input 
vectors.  This does not work for non-constant simdclones, so we should 
disable using such clones when
the VF is a multiple of the non-constant simdlen until we change the 
codegen to support those.


Enabling SVE simdclone support will cause ICEs if the vectorizer decides 
to use a SVE simdclone with a VF that is larger than the simdlen. I'll 
be away for the next two weeks, so cant' really discuss this further.
I initially tried to solve the problem, but the way 
vectorizable_simd_clone_call is structured doesn't make it easy to 
replace BIT_FIELD_REF with the poly-suitable solution right now of using 
unpack_{hi,lo}. Unfortunately I only found this now as I was adding 
further tests for SVE :(


gcc/ChangeLog:

* tree-vect-stmts.cc (vectorizable_simd_clone_call): Reject simdclones
with non-constant simdlen when VF is not exactly the same.diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index 
5f262cae2aae784e3ef4fd07455b7aa742797b51..dc3e0716161838aef66cf37342499006673336d6
 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -4165,7 +4165,10 @@ vectorizable_simd_clone_call (vec_info *vinfo, 
stmt_vec_info stmt_info,
if (!constant_multiple_p (vf * group_size, n->simdclone->simdlen,
  _calls)
|| (!n->simdclone->inbranch && (masked_call_offset > 0))
-   || (nargs != simd_nargs))
+   || (nargs != simd_nargs)
+   /* Currently we do not support multiple calls of non-constant
+  simdlen as poly vectors can not be accessed by BIT_FIELD_REF.  */
+   || (!n->simdclone->simdlen.is_constant () && num_calls != 1))
  continue;
if (num_calls != 1)
  this_badness += exact_log2 (num_calls) * 4096;

Re: [PATCH] vect: allow using inbranch simdclones for masked loops

[Andre Vieira (lists)]

On 03/11/2023 07:31, Richard Biener wrote:



OK.

I do wonder about the gfortran testsuite adjustments though.

!GCC$ builtin (sin) attributes simd (inbranch)

   ! this should not be using simd clone
   y4 = sin(x8)

previously we wouldn't vectorize this as no notinbranch simd function
is available but now we do since we use the inbranch function for the
notinbranch call.  If that's desired then a better modification of
the test would be to expect vectorization, no?



I was in two minds about this. I interpreted the test to be about the 
fact that sin is overloaded in fortran, given the name of the program 
'program test_overloaded_intrinsic', and thus I thought it was testing 
that it calls sinf when a real(4) is passed and sin for a real(8) and 
that simdclones aren't used for the wrong overload. That doesn't quite 
explain why the pragma for sin(double) was added in the first place, 
that wouldn't have been necessary, but then again neither are the cos 
and cosf.


Happy to put it back in and test that the 'masked' simdclone is used 
using some regexp too.

Re: [oe] openssl-native.rm_work runs before kernel-module.install -> no signature

[Jörg Sommer via lists . openembedded . org]

On 30.10.23 14:24, Jörg Sommer via lists.openembedded.org wrote:
> On 30.10.23 13:29, Bruce Ashfield wrote:
>> On Mon, Oct 30, 2023 at 4:40 AM Jörg Sommer  
>> wrote:
>>> On 26.10.23 17:25, Bruce Ashfield wrote:
> 
 I ran into issues with some kernel versions, but we may have moved on
 far enough that it is no longer an issue.
>>>
>>> Do you remember what kind of issues these were? Possibly I can check if
>>> they still exist.
>>
>> It was kernels older than 5.10 failing to take the r-path changes and
>> hence failing when doing the signing step.
> 
> This could be solved by setting LD_LIBRARY_PATH. Would this be okay?
> 
> ```
> diff --git i/meta/classes/module.bbclass w/meta/classes/module.bbclass
> index a09ec3ed1e..38e1c95216 100644
> --- i/meta/classes/module.bbclass
> +++ w/meta/classes/module.bbclass
> @@ -51,6 +51,7 @@ module_do_install() {
>INSTALL_FW_PATH="${D}${nonarch_base_libdir}/firmware" \
>CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
>O=${STAGING_KERNEL_BUILDDIR} \
> +  
> LD_LIBRARY_PATH="/build/tmp/sysroots-components/x86_64/openssl-native/usr/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}"
>  \
>${MODULES_INSTALL_TARGET}
>  
> if [ ! -e "${B}/${MODULES_MODULE_SYMVERS_LOCATION}/Module.symvers" ] 
> ; then
> ```

Hi Bruce,

I would like to here your opinion to this issue, because you've provided
the most to the discussion. I would like to submit a patch to fix
problem; either the BUILD_LDFLAGS one or the LD_LIBRARY_PATH.

Kind regards

Jörg Sommer
-- 
Navimatix GmbH
Tatzendpromenade 2
D-07745 Jena
Geschäftsführer: Steffen Späthe, Jan Rommeley
Registergericht: Amtsgericht Jena, HRB 501480

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

Re: [yocto] QA notification for completed autobuilder build (yocto-4.3.rc2)

[Alexis Lothoré via lists . yoctoproject . org]

Hello,

On 10/19/23 23:55, Pokybuild User wrote:
> 
> A build flagged for QA (yocto-4.3.rc2) was completed on the autobuilder 
> and is available at:
> 
> 
> https://autobuilder.yocto.io/pub/releases/yocto-4.3.rc2
> 
> 
> Build URL: 
> https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/6080

Once again this release is lacking a proper regression report. I am reacting a
bit late, but I have moved forward with the diagnostic. As for yocto-4.3.rc1,
the report is empty because of a lack in the "base" tests results, which is here
tests results from yocto-4.2. Those are in fact the tests results that we have
pushed manually during summer, because those weren't pushed automatically
(because of another unrelated tagging issue which has been fixed since then).
But it looks like we have made a mistake/omission while doing so: the tag
associated with those results (which is required to make resulttool search for
it) is not present on the mickledore branch. This issue is pretty visible when
fetching the lasts commits on mickledore branch in testresults repository (see
https://git.yoctoproject.org/yocto-testresults/log/?h=mickledore)

So to fix this, my suggestion is for someone having the proper write access on
git://git.yoctoproject.org/yocto-testresults to manually apply the missing tag
on the proper commit and to push it:

git tag mickledore/70029-g21790e71d55f417f27cd51fae9dd47549758d4a0/1
5bf0165296b3686ab5c400869ed2e030f2269c8a

(adding Michael Halstead in CC since he is the one who helped me with the manual
import of missing tests results)

I have tested locally this fix (by tagging locally my clone of testresults +
hacking around in resulttool to prevent it from reading remote tags), and I have
been able to generate the report. Here it is :

https://pastebin.com/fvRcqes4

By the way, the report comes from a slightly modified resulttool run because it
has shown that the recent regression grouping addition needs some improvements
(among some other already discussed issues), so patch incoming.

Kind regards,

-- 
Alexis Lothoré, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


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

[PATCH] vect: allow using inbranch simdclones for masked loops

[Andre Vieira (lists)]

Hi,

In a previous patch I did most of the work for this, but forgot to 
change the check for number of arguments matching between call and 
simdclone.  This check should accept calls without a mask to be matched 
against simdclones with mask arguments.  I also added tests to verify 
this feature actually works.



For the simd-builtins tests I decided to remove the sin (double) 
simdclone which would now be used, because it was inbranch and we enable 
their use for not inbranch.  Given the nature of the test, removing it 
made more sense, but thats not a strong opinion, happy to change.


Bootstrapped and regression tested on aarch64-unknown-linux-gnu and 
x86_64-pc-linux-gnu.


OK for trunk?

PS: I'll be away for two weeks from tomorrow, it would be really nice if 
this can go in for gcc-14, otherwise the previous work I did for this 
won't have any actual visible effect :(



gcc/ChangeLog:

* tree-vect-stmts.cc (vectorizable_simd_clone_call): Allow unmasked
calls to use masked simdclones.

gcc/testsuite/ChangeLog:

* gcc.dg/vect/vect-simd-clone-20.c: New file.
* gfortran.dg/simd-builtins-1.h: Adapt.
* gfortran.dg/simd-builtins-6.f90: Adapt.diff --git a/gcc/testsuite/gcc.dg/vect/vect-simd-clone-20.c 
b/gcc/testsuite/gcc.dg/vect/vect-simd-clone-20.c
new file mode 100644
index 
..9f51a68f3a0c8851af2cd26bd8235c771b851d7d
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/vect/vect-simd-clone-20.c
@@ -0,0 +1,87 @@
+/* { dg-require-effective-target vect_simd_clones } */
+/* { dg-additional-options "-fopenmp-simd --param vect-epilogues-nomask=0" } */
+/* { dg-additional-options "-mavx" { target avx_runtime } } */
+
+/* Test that simd inbranch clones work correctly.  */
+
+#ifndef TYPE
+#define TYPE int
+#endif
+
+/* A simple function that will be cloned.  */
+#pragma omp declare simd inbranch
+TYPE __attribute__((noinline))
+foo (TYPE a)
+{
+  return a + 1;
+}
+
+/* Check that "inbranch" clones are called correctly.  */
+
+void __attribute__((noipa))
+masked (TYPE * __restrict a, TYPE * __restrict b, int size)
+{
+  #pragma omp simd
+  for (int i = 0; i < size; i++)
+b[i] = foo(a[i]);
+}
+
+/* Check that "inbranch" works when there might be unrolling.  */
+
+void __attribute__((noipa))
+masked_fixed (TYPE * __restrict a, TYPE * __restrict b)
+{
+  #pragma omp simd
+  for (int i = 0; i < 128; i++)
+b[i] = foo(a[i]);
+}
+
+/* Validate the outputs.  */
+
+void
+check_masked (TYPE *b, int size)
+{
+  for (int i = 0; i < size; i++)
+if (b[i] != (TYPE)(i + 1))
+  {
+   __builtin_printf ("error at %d\n", i);
+   __builtin_exit (1);
+  }
+}
+
+int
+main ()
+{
+  TYPE a[1024];
+  TYPE b[1024];
+
+  for (int i = 0; i < 1024; i++)
+a[i] = i;
+
+  masked_fixed (a, b);
+  check_masked (b, 128);
+
+  /* Test various sizes to cover machines with different vectorization
+ factors.  */
+  for (int size = 8; size <= 1024; size *= 2)
+{
+  masked (a, b, size);
+  check_masked (b, size);
+}
+
+  /* Test sizes that might exercise the partial vector code-path.  */
+  for (int size = 8; size <= 1024; size *= 2)
+{
+  masked (a, b, size-4);
+  check_masked (b, size-4);
+}
+
+  return 0;
+}
+
+/* Ensure the the in-branch simd clones are used on targets that support them. 
 */
+/* { dg-final { scan-tree-dump-times {[\n\r] [^\n]* = foo\.simdclone} 2 "vect" 
{ target { aarch64*-*-* } } } } */
+/* { dg-final { scan-tree-dump-times {[\n\r] [^\n]* = foo\.simdclone} 4 "vect" 
{ target { x86_64*-*-* } } } } */
+
+/* The LTO test produces two dump files and we scan the wrong one.  */
+/* { dg-skip-if "" { *-*-* } { "-flto" } { "" } } */
diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-1.h 
b/gcc/testsuite/gfortran.dg/simd-builtins-1.h
index 
88d555cf41ad065ea525a63d7c05d15d3e5b54ed..08b73514a67d5791d35203530d039741946e9dcc
 100644
--- a/gcc/testsuite/gfortran.dg/simd-builtins-1.h
+++ b/gcc/testsuite/gfortran.dg/simd-builtins-1.h
@@ -1,4 +1,3 @@
-!GCC$ builtin (sin) attributes simd (inbranch)
 !GCC$ builtin (sinf) attributes simd (notinbranch)
 !GCC$ builtin (cosf) attributes simd
 !GCC$ builtin (cosf) attributes simd (notinbranch)
diff --git a/gcc/testsuite/gfortran.dg/simd-builtins-6.f90 
b/gcc/testsuite/gfortran.dg/simd-builtins-6.f90
index 
60bcac78f3e0cc492930f3eb73cf97065312dc1c..2c68f9f1818a35674a0aef15793aa312a48199a8
 100644
--- a/gcc/testsuite/gfortran.dg/simd-builtins-6.f90
+++ b/gcc/testsuite/gfortran.dg/simd-builtins-6.f90
@@ -2,7 +2,6 @@
 ! { dg-additional-options "-nostdinc -Ofast -fdump-tree-optimized" }
 ! { dg-additional-options "-msse2 -mno-avx" { target i?86-*-linux* 
x86_64-*-linux* } }
 
-!GCC$ builtin (sin) attributes simd (inbranch)
 !GCC$ builtin (sinf) attributes simd (notinbranch)
 !GCC$ builtin (cosf) attributes simd
 !GCC$ builtin (cosf) attributes simd (notinbranch)
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index 

[yocto] Call bitbake while bitbake is running

[Jörg Sommer via lists . yoctoproject . org]

Hi,

is it possible to run bitbake while bitbake is running? I'm starting
`bitbake -c menuconfig virtual/kernel` and would like to call
`diffconfig` while I'm doing configuration. The best would be from the
other window of tmux. Is this possible?

Kind regards

Jörg Sommer
-- 
Navimatix GmbH
Tatzendpromenade 2
D-07745 Jena
Geschäftsführer: Steffen Späthe, Jan Rommeley
Registergericht: Amtsgericht Jena, HRB 501480

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

Re: Automatic annotation of slide positions/fingerings for brass instruments.

[Wols Lists]

On 31/10/2023 01:36, Adam M. Griggs wrote:
Your second recommendation is situational. I see you have a *.uk 
email address. I'm familiar with the British brass band context. I get 
it—almost everything is transposed for instruments pitched in Bb or Eb, 
and in the entire ensemble, only bass trombones are notated at concert 
pitch. At this time, however, I'm operating in a concert band 
environment, working with both community and school bands. Our trombone, 
tuba, even euphonium parts are all notated at concert pitch. You are 
completely correct to suggest it, but it depends on the target audience.


And something else :-) I've only met it once, to the best of my 
knowledge, and I think it was American, I've come across a piece - in 
bass clef - and also in Bb !!!


That was a nightmare until I realised what was going on ! :-)

There's always an exception to every rule !

And over here, I think orchestras are always bass/tenor clef, brass 
bands are always Bb (or tenor clef, especially "brass and reed"), and 
concert/military/wind bands can be either.


I'm lucky, I can read all three clefs, though not tenor very well, 
simply because I rarely see it.


Cheers,
Wol

Re: [PATCH6/8] omp: Reorder call for TARGET_SIMD_CLONE_ADJUST (was Re: [PATCH7/8] vect: Add TARGET_SIMD_CLONE_ADJUST_RET_OR_PARAM)

[Andre Vieira (lists)]

Hi Richi,

Friendly ping on this. I'm going away for two weeks end of this week, so 
I won't be here for end of stage-1, but I'd still very much like to get 
this done for GCC 14.


I don't know if you had a chance to look at this yet when you reviewed 
the other patches or if you maybe just missed it? A quick td;lr this 
moves around the TARGET_SIMD_CLONE_ADJUST call after we've vectorized 
the types in simdclones to avoid having to add the extra target hooks to 
change the types.  This required some moving around of the code that 
constructed the adjustments and the code that constructed the array for 
the return value.


Kind regards,
Andre

On 18/10/2023 15:41, Andre Vieira (lists) wrote:
This patch moves the call to TARGET_SIMD_CLONE_ADJUST until after the 
arguments and return types have been transformed into vector types.  It 
also constructs the adjuments and retval modifications after this call, 
allowing targets to alter the types of the arguments and return of the 
clone prior to the modifications to the function definition.


Is this OK?

gcc/ChangeLog:

     * omp-simd-clone.cc (simd_clone_adjust_return_type): Hoist out
     code to create return array and don't return new type.
     (simd_clone_adjust_argument_types): Hoist out code that creates
     ipa_param_body_adjustments and don't return them.
     (simd_clone_adjust): Call TARGET_SIMD_CLONE_ADJUST after return
     and argument types have been vectorized, create adjustments and
     return array after the hook.
     (expand_simd_clones): Call TARGET_SIMD_CLONE_ADJUST after return
     and argument types have been vectorized.

On 04/10/2023 13:40, Andre Vieira (lists) wrote:



On 04/10/2023 11:41, Richard Biener wrote:

On Wed, 4 Oct 2023, Andre Vieira (lists) wrote:




On 30/08/2023 14:04, Richard Biener wrote:

On Wed, 30 Aug 2023, Andre Vieira (lists) wrote:

This patch adds a new target hook to enable us to adapt the types 
of return
and parameters of simd clones.  We use this in two ways, the first 
one is

to
make sure we can create valid SVE types, including the SVE type 
attribute,
when creating a SVE simd clone, even when the target options do 
not support
SVE.  We are following the same behaviour seen with x86 that 
creates simd
clones according to the ABI rules when no simdlen is provided, 
even if that
simdlen is not supported by the current target options.  Note that 
this

doesn't mean the simd clone will be used in auto-vectorization.


You are not documenting the bool parameter of the new hook.

What's wrong with doing the adjustment in TARGET_SIMD_CLONE_ADJUST?


simd_clone_adjust_argument_types is called after that hook, so by 
the time we
call TARGET_SIMD_CLONE_ADJUST the types are still in scalar, not 
vector.  The

same is true for the return type one.

Also the changes to the types need to be taken into consideration in
'adjustments' I think.


Nothing in the three existing implementations of 
TARGET_SIMD_CLONE_ADJUST

relies on this ordering I think, how about moving the hook invocation
after simd_clone_adjust_argument_types?



But that wouldn't change the 'ipa_param_body_adjustments' for when we 
have a function definition and we need to redo the body.

Richard.

PS: I hope the subject line survived, my email client is having a 
bit of a

wobble this morning... it's what you get for updating software :(

Re: Automatic annotation of slide positions/fingerings for brass instruments.

[Wols Lists]

On 29/08/2023 15:35, Adam M. Griggs wrote:
Here's a little self-help reference I made a little while back. Maybe it 
will illustrate your point about different positions for different 
octaves more clearly than words can.


Perhaps something in the tablature code can be adapted to this end.


Ouch!!!

Just to point out, for those who don't play trombone, you will never (in 
my experience at least, I'm sure people will find counter examples) find 
trombone music with those positions in the treble clef.


Like (I think) all brass instruments, the trombone in treble clef is a 
transposing instrument, and position 1 is a written C, not D.


In this example you need to swap the treble clef for a tenor clef ...

And then redo it for treble clef - your bass clef bottom Bb is written 
as treble clef middle C.


Cheers,
Wol

Re: [oe] openssl-native.rm_work runs before kernel-module.install -> no signature

[Jörg Sommer via lists . openembedded . org]

On 30.10.23 13:29, Bruce Ashfield wrote:
> On Mon, Oct 30, 2023 at 4:40 AM Jörg Sommer  wrote:
>> On 26.10.23 17:25, Bruce Ashfield wrote:

>>> I ran into issues with some kernel versions, but we may have moved on
>>> far enough that it is no longer an issue.
>>
>> Do you remember what kind of issues these were? Possibly I can check if
>> they still exist.
> 
> It was kernels older than 5.10 failing to take the r-path changes and
> hence failing when doing the signing step.

This could be solved by setting LD_LIBRARY_PATH. Would this be okay?

```
diff --git i/meta/classes/module.bbclass w/meta/classes/module.bbclass
index a09ec3ed1e..38e1c95216 100644
--- i/meta/classes/module.bbclass
+++ w/meta/classes/module.bbclass
@@ -51,6 +51,7 @@ module_do_install() {
   INSTALL_FW_PATH="${D}${nonarch_base_libdir}/firmware" \
   CC="${KERNEL_CC}" LD="${KERNEL_LD}" \
   O=${STAGING_KERNEL_BUILDDIR} \
+  
LD_LIBRARY_PATH="/build/tmp/sysroots-components/x86_64/openssl-native/usr/lib${LD_LIBRARY_PATH:+:$LD_LIBRARY_PATH}"
 \
   ${MODULES_INSTALL_TARGET}
 
if [ ! -e "${B}/${MODULES_MODULE_SYMVERS_LOCATION}/Module.symvers" ] ; 
then
```


Kind regards

Jörg Sommer
-- 
Navimatix GmbH
Tatzendpromenade 2
D-07745 Jena  
Geschäftsführer: Steffen Späthe, Jan Rommeley
Registergericht: Amtsgericht Jena, HRB 501480


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

Re: [oe] openssl-native.rm_work runs before kernel-module.install -> no signature

[Jörg Sommer via lists . openembedded . org]

On 26.10.23 17:25, Bruce Ashfield wrote:
> On Thu, Oct 26, 2023 at 7:16 AM Jörg Sommer  wrote:
>>
>> On 26.10.23 10:34, Jose Quaresma wrote:
>>>
>>>
>>> Khem Raj mailto:raj.k...@gmail.com>> escreveu no
>>> dia quarta, 25/10/2023 à(s) 18:18:
>>>
>>> I wonder if something like below would help
>>>
>>> diff --git
>>> a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
>>> 
>>> b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
>>> 
>>> index 2cff48c39c3..6133721334c 100644
>>> --- a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
>>> 
>>> +++ b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
>>> 
>>> @@ -12,7 +12,7 @@ S = "${WORKDIR}"
>>>
>>>  do_configure[depends] += "virtual/kernel:do_shared_workdir
>>> openssl-native:do_populate_sysroot"
>>>  do_compile[depends] += "virtual/kernel:do_compile_kernelmodules"
>>> -
>>> +do_populate_sysroot[depends] += "openssl-native:do_populate_sysroot"
>>>
>>>
>>> This doesn't solve the problem because at compile time the openssl is
>>> already there on native sysroot
>>
>> How about a patch like this:
>>
> 
> I proposed something similar in the earlier threads on this topic (it
> has been around for quite some time, and is in bugzilla for oe-core)/

Can you give me a link to the bugzilla entry? I didn't found it.

> I ran into issues with some kernel versions, but we may have moved on
> far enough that it is no longer an issue.

Do you remember what kind of issues these were? Possibly I can check if
they still exist.

Kind regards

Jörg Sommer
-- 
Navimatix GmbH
Tatzendpromenade 2
D-07745 Jena
Geschäftsführer: Steffen Späthe, Jan Rommeley
Registergericht: Amtsgericht Jena, HRB 501480


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

Re: [gentoo-user] Re: OFF TOPIC Need Ubuntu network help: boot loader info

[Wols Lists]

On 19/10/2023 12:55, Neil Bothwick wrote:

On Wed, 18 Oct 2023 23:49:25 -0500, Dale wrote:


That config kinda reminds me of the old grub.  A title line, location of
kernel and then options.  Sounds easy enough.  The new grub config is
almost impossible to config by hand.  They had to make a tool to do it.
That says a lot there.  ;-)


GRUB2 was designed to be able to create a config for anything
automatically, such as from an installer. It does that very well, but is
total overkill for Gentoo-like people that like to stay in control.



Such a shame it doesn't work. :-)

I tried to install SUSE dual boot, and it broke the installer - NOTHING 
would boot. I needed a rescue disk to fix the mess ...


Cheers,
Wol

Re: [Ietf-dkim] [Lists] DKIM Working Group Status Update

[lists=40francispbaker . com]

ssed potential problems and 
> fixes. 
> 
> I then called for a rough consensus for a path forward of finishing the 
> problem statement, documenting the problem and some of the solutions folks 
> have implemented and then ending the working group. 
> 
> There was more discussion from various individuals highlights include:
> Bulk sender A: Not sure how to solve the problem, they tried a few things but 
> it didn’t seem to have an effect and noted some reputation problems even when 
> DKIM signatures don’t verify
> Bulk sender B: Problem for them is currently at nuisance level, not a big 
> issue for them
> ISP A: Problem for them is currently at nuisance level, not a big issue for 
> them. Also, unlikely to state their solution on the IETF list due to concerns 
> about revealing their filtering processes. 
> Monitoring Org: Sees examples of attacks. Issues include lack of visibility 
> in the ecosystem and lack of sender awareness and understanding of the 
> impact. 
> I noted this was not an IETF (interoperability) problem and suggested that 
> the issue should be dealt with by M3AAWG or other organizations. 
> 
> I reiterated, again, the issue was getting people to show up through the IETF 
> process. We need participants to come to a rough consensus. One member 
> commented that they did show up but there was a lot of pressure to take the 
> problem back to MAAWG. I noted that there had been one very loud individual 
> who was repeatedly saying this, but he has left the list. Additionally, 
> myself and the other co-chair as well as the Area Director are monitoring the 
> situation if it reoccurs. 
> 
> After more discussion, including looking at a replacement for ARC, possibly 
> expanding the charter to address other authentication issues and other 
> digressions. I asked again for a show of hands of how many folks were willing 
> to come over to the IETF group to participate. This time there were nearly a 
> dozen hands. 
> 
> I encouraged everyone to join the IETF list. I did comment that I’d be 
> counting subscriptions to ensure that folks did join the list. However, the 
> subscription page doesn’t have join-by dates so you’re all safe in that I 
> can’t do that. I do want to see some discussion and life on the list, 
> however. 
> 
> NEXT STEPS:
> 
> As I see it, the next steps are to complete the Problem Statement document 
> describing what the problem is, what the effects of a replay attack are and 
> documenting some of the ways both senders and receivers have mitigated the 
> problem. 
> 
> I’d like to hear from folks on the list, both who were with us in Brooklyn 
> and folks who were not there about my proposed next steps. 
> 
> Laura (as chair)
> 
> -- 
> The Delivery Expert
> 
> Laura Atkins
> Word to the Wise
> la...@wordtothewise.com
> 
> Delivery hints and commentary: http://wordtothewise.com/blog  
> 
> 
> 
> 
> 
> 
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Mailing Lists" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to lists+unsubscr...@francispbaker.com 
> <mailto:lists+unsubscr...@francispbaker.com>.
> To view this discussion on the web visit 
> https://groups.google.com/a/francispbaker.com/d/msgid/lists/1FA5D3B1-EC6C-4272-A0B5-5518C868F6F1%40wordtothewise.com
>  
> <https://groups.google.com/a/francispbaker.com/d/msgid/lists/1FA5D3B1-EC6C-4272-A0B5-5518C868F6F1%40wordtothewise.com?utm_medium=email_source=footer>.
> ___
> Ietf-dkim mailing list
> Ietf-dkim@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-dkim
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Mailing Lists" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to lists+unsubscr...@francispbaker.com.
> To view this discussion on the web visit 
> https://groups.google.com/a/francispbaker.com/d/msgid/lists/1FA5D3B1-EC6C-4272-A0B5-5518C868F6F1%40wordtothewise.com.

___
Ietf-dkim mailing list
Ietf-dkim@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-dkim

You missed a call Transcription Available

[Lists Wireless Solutions|PhoneSystem]

The information transmitted by this email, including any attachments, is intended only for the person(s) or entity to which it is addressed and may contain confidential and/or legally privileged material. If you receive this in error, please contact the sender and delete the material from any computer
	  

Re: [oe] openssl-native.rm_work runs before kernel-module.install -> no signature

[Jörg Sommer via lists . openembedded . org]

On 26.10.23 10:34, Jose Quaresma wrote:
> 
> 
> Khem Raj mailto:raj.k...@gmail.com>> escreveu no
> dia quarta, 25/10/2023 à(s) 18:18:
> 
> I wonder if something like below would help
> 
> diff --git
> a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> 
> b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> 
> index 2cff48c39c3..6133721334c 100644
> --- a/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> 
> +++ b/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
> 
> @@ -12,7 +12,7 @@ S = "${WORKDIR}"
> 
>  do_configure[depends] += "virtual/kernel:do_shared_workdir
> openssl-native:do_populate_sysroot"
>  do_compile[depends] += "virtual/kernel:do_compile_kernelmodules"
> -
> +do_populate_sysroot[depends] += "openssl-native:do_populate_sysroot"
> 
> 
> This doesn't solve the problem because at compile time the openssl is
> already there on native sysroot

How about a patch like this:

```
diff --git i/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb 
w/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
index 0e420a25d9..182abd0233 100644
--- i/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
+++ w/meta/recipes-kernel/make-mod-scripts/make-mod-scripts_1.0.bb
@@ -18,6 +18,10 @@ RDEPENDS:${PN}-dev = ""
 DEPENDS += "bc-native bison-native"
 DEPENDS += "gmp-native"
 
+BUILD_LDFLAGS =+ "-L 
/build/tmp/sysroots-components/x86_64/openssl-native/usr/lib \
+   
-Wl,-rpath-link,/build/tmp/sysroots-components/x86_64/openssl-native/usr/lib \
+   -Wl,-rpath,/build/tmp/sysroots-components/x86_64/openssl-native/usr/lib"
+
 EXTRA_OEMAKE = " HOSTCC="${BUILD_CC} ${BUILD_CFLAGS} ${BUILD_LDFLAGS}" 
HOSTCPP="${BUILD_CPP}""
 EXTRA_OEMAKE += " HOSTCXX="${BUILD_CXX} ${BUILD_CXXFLAGS} ${BUILD_LDFLAGS}" 
CROSS_COMPILE=${TARGET_PREFIX}"
 
```

Regards

Jörg Sommer
-- 
Navimatix GmbH
Tatzendpromenade 2
D-07745 Jena  
Geschäftsführer: Steffen Späthe, Jan Rommeley
Registergericht: Amtsgericht Jena, HRB 501480


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

Re: [OE-core] [PATCH] openssh: Don't hardcode the dir in sshd.service

[Jörg Sommer via lists . openembedded . org]

On 26.10.23 09:04, Yu, Mingli via lists.openembedded.org wrote:
> From: Mingli Yu 
> 
> Don't hardcode the directory of the binary in sshd.service.
> 
> Signed-off-by: Mingli Yu 
> ---
>  meta/recipes-connectivity/openssh/openssh/sshd.service | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-connectivity/openssh/openssh/sshd.service 
> b/meta/recipes-connectivity/openssh/openssh/sshd.service
> index 6ace67d8ae..2a997b656a 100644
> --- a/meta/recipes-connectivity/openssh/openssh/sshd.service
> +++ b/meta/recipes-connectivity/openssh/openssh/sshd.service
> @@ -6,7 +6,7 @@ After=sshdgenkeys.service
>  [Service]
>  Environment="SSHD_OPTS="
>  EnvironmentFile=-/etc/default/ssh
> -ExecStartPre=/usr/bin/mkdir -p /var/run/sshd
> +ExecStartPre=@BASE_BINDIR@/mkdir -p /var/run/sshd

How about using `RuntimeDirectory=sshd` or don't hardcode any path and
call `ExecStartPre=mkdir -p …`

>  ExecStart=-@SBINDIR@/sshd -D $SSHD_OPTS
>  ExecReload=@BASE_BINDIR@/kill -HUP $MAINPID

Same here. This would match the example in the Manual page
systemd.service(5):

```
ExecReload=
Commands to execute to trigger a configuration reload in the
service. This argument takes multiple command lines, following the same
scheme as described
for ExecStart= above. Use of this setting is optional. Specifier and
environment variable substitution is supported here following the same
scheme as for
ExecStart=.

One additional, special environment variable is set: if known,
$MAINPID is set to the main process of the daemon, and may be used for
command lines like
the following:

ExecReload=kill -HUP $MAINPID
```

>  KillMode=process


Kind regards

Jörg Sommer
-- 
Navimatix GmbH
Tatzendpromenade 2
D-07745 Jena
Geschäftsführer: Steffen Späthe, Jan Rommeley
Registergericht: Amtsgericht Jena, HRB 501480


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

[oe] openssl-native.rm_work runs before kernel-module.install -> no signature

[Jörg Sommer via lists . openembedded . org]

Hi,

I'm having an odd problem building the external kernel module
kernel-module-imx-gpu-viv [1]. I'm using kirkstone and have rm_work
enabled.

[1]  https://layers.openembedded.org/layerindex/recipe/40267/

The module builds fine, but the install step contains the module signing
which **silently** fails with *libcrypto.so.3* not found:

```
| make -C /build/tmp/work-shared/ziborium/kernel-source
M=/build/tmp/work/machine-pyxis-linux/kernel-module-imx-gpu-viv/6.4.3.p4.2-r0/git/src
modules_install
| make[1]: Entering directory '/build/tmp/work-shared/machine/kernel-source'
| make -C /build/tmp/work-shared/machine/kernel-build-artifacts -f
/build/tmp/work-shared/machine/kernel-source/Makefile modules_install
| make[2]: Entering directory
'/build/tmp/work-shared/machine/kernel-build-artifacts'
| test -e include/generated/autoconf.h -a -e include/config/auto.conf ||
(   \
| echo >&2; \
| echo >&2 "  ERROR: Kernel configuration is invalid."; \
| echo >&2 " include/generated/autoconf.h or
include/config/auto.conf are missing.";\
| echo >&2 " Run 'make oldconfig && make prepare' on kernel src
to fix it.";\
| echo >&2 ;\
| /bin/false)
| make -f
/build/tmp/work-shared/machine/kernel-source/scripts/Makefile.modinst
|   mkdir -p
/build/tmp/work/machine-dist-linux/kernel-module-imx-gpu-viv/6.4.3.p4.2-r0/image/usr/lib/modules/5.15.60-imx8mm+g343e81c0e39e/extra/;
cp
/build/tmp/work/machine-dist-linux/kernel-module-imx-gpu-viv/6.4.3.p4.2-r0/git/src/galcore.ko
/build/tmp/work/machine-dist-linux/kernel-module-imx-gpu-viv/6.4.3.p4.2-r0/image/usr/lib/modules/5.15.60-imx8mm+g343e81c0e39e/extra/galcore.ko
|   :
|   scripts/sign-file "sha1" "certs/signing_key.pem"
certs/signing_key.x509
/build/tmp/work/machine-dist-linux/kernel-module-imx-gpu-viv/6.4.3.p4.2-r0/image/usr/lib/modules/5.15.60-imx8mm+g343e81c0e39e/extra/galcore.ko
|| true
| scripts/sign-file: error while loading shared libraries:
libcrypto.so.3: cannot open shared object file: No such file or directory
|   sh /build/tmp/work-shared/machine/kernel-source/scripts/depmod.sh
echo 5.15.60-imx8mm+g343e81c0e39e
| Warning: modules_install: missing 'System.map' file. Skipping depmod.
| make[2]: Leaving directory
'/build/tmp/work-shared/machine/kernel-build-artifacts'
| make[1]: Leaving directory '/build/tmp/work-shared/machine/kernel-source'
```

I noticed that there are special dependency definitions in make-mod-scripts

```
do_configure[depends] += "virtual/kernel:do_shared_workdir
openssl-native:do_populate_sysroot"
do_compile[depends] += "virtual/kernel:do_compile_kernelmodules"
```

and module-base.bbclass (inherited by module.bbclass)

```
# We do the dependency this way because the output is not preserved
# in sstate, so we must force do_compile to run (once).
do_configure[depends] += "make-mod-scripts:do_compile"
```

Is there an additional dependency needed to address rm_work?

Kind regards

Jörg Sommer
-- 
Navimatix GmbH
Tatzendpromenade 2
D-07745 Jena
Geschäftsführer: Steffen Späthe, Jan Rommeley
Registergericht: Amtsgericht Jena, HRB 501480

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