[OE-Core][PATCH v2 0/5] testimage: add failed test post actions and fetch more data

[Alexis Lothoré via lists . openembedded . org]

Hello,
this small series is related to some disk space issue observed by the SWAT
team (see [1]) which eventually leads to tests failure. In order to help
diagnose those issues, I propose to enrich the retrieved artifacts with
some additional data, like disk usage on target and on host (in case the
target is a virtualized guest)

This v2 is mostly about creating a python module instead of a bbclass.
Link to v1: [2]

[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=15220
[2] 
https://lore.kernel.org/openembedded-core/20240220200159.13419-1-alexis.loth...@bootlin.com/

Signed-off-by: Alexis Lothoré 

Alexis Lothoré (5):
  lib/oeqa: share get_json_result_dir helper
  testimage: create a list of failed test post actions
  oeqa/utils/postactions: isolate directory creation in dedicated action
  oeqa/utils/postactions: add target disk usage stat as post action
  oeqa/utils/postactions: testimage: add host disk usage stat as post
action

 meta/classes-recipe/testimage.bbclass | 54 ++-
 meta/lib/oeqa/sdk/testsdk.py  | 11 +--
 meta/lib/oeqa/utils/__init__.py   |  7 ++
 meta/lib/oeqa/utils/postactions.py| 98 +++
 4 files changed, 112 insertions(+), 58 deletions(-)
 create mode 100644 meta/lib/oeqa/utils/postactions.py

-- 
2.43.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196085): 
https://lists.openembedded.org/g/openembedded-core/message/196085
Mute This Topic: https://lists.openembedded.org/mt/104528470/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 v2 5/5] oeqa/utils/postactions: testimage: add host disk usage stat as post action

[Alexis Lothoré via lists . openembedded . org]

From: Alexis Lothoré 

Since the target under test can be a virtualized guest, when some tests
fail because of disk usage (see [1]), also fetch disk usage statistics from
host to allow checking whether a host disk space saturation could affect
running tests.

[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=15220

Signed-off-by: Alexis Lothoré 
---
Changes in v2:
- use new shared helper get_json_result_dir()
---
 meta/lib/oeqa/utils/postactions.py | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/utils/postactions.py 
b/meta/lib/oeqa/utils/postactions.py
index 008968b56a3f..03cecdc21578 100644
--- a/meta/lib/oeqa/utils/postactions.py
+++ b/meta/lib/oeqa/utils/postactions.py
@@ -32,6 +32,16 @@ def get_target_disk_usage(d, tc):
 except Exception as e:
 bb.warn(f"Can not get target disk usage: {e}")
 
+def get_host_disk_usage(d, tc):
+import subprocess
+
+output_file = os.path.join(get_json_result_dir(d), "artifacts", 
"host_disk_usage.txt")
+try:
+with open(output_file, 'w') as f:
+output = subprocess.run(['/usr/bin/df', '-hl'], check=True, 
text=True, stdout=f)
+except Exception as e:
+bb.warn(f"Can not get host disk usage: {e}")
+
 ##
 # Artifacts retrieval
 ##
@@ -80,7 +90,8 @@ def run_failed_tests_post_actions(d, tc):
 post_actions=[
 create_artifacts_directory,
 list_and_fetch_failed_tests_artifacts,
-get_target_disk_usage
+get_target_disk_usage,
+get_host_disk_usage
 ]
 
 for action in post_actions:
-- 
2.43.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196090): 
https://lists.openembedded.org/g/openembedded-core/message/196090
Mute This Topic: https://lists.openembedded.org/mt/104528475/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 v2 4/5] oeqa/utils/postactions: add target disk usage stat as post action

[Alexis Lothoré via lists . openembedded . org]

From: Alexis Lothoré 

In order to debug issues related to disk space (see [1]),  add a failed
tests post action to retrieve disk usage on the target. Rely on the test
context object to run the corresponding command onto the target

[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=15220

Signed-off-by: Alexis Lothoré 
---
Changes in v2:
- - use new shared helper get_json_result_dir()
---
 meta/lib/oeqa/utils/postactions.py | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/utils/postactions.py 
b/meta/lib/oeqa/utils/postactions.py
index 7014b2830a9c..008968b56a3f 100644
--- a/meta/lib/oeqa/utils/postactions.py
+++ b/meta/lib/oeqa/utils/postactions.py
@@ -18,6 +18,20 @@ def create_artifacts_directory(d, tc):
 
 os.makedirs(local_artifacts_dir)
 
+##
+# Host/target statistics
+##
+
+def get_target_disk_usage(d, tc):
+output_file = os.path.join(get_json_result_dir(d), "artifacts", 
"target_disk_usage.txt")
+try:
+(status, output) = tc.target.run('df -hl')
+with open(output_file, 'w') as f:
+f.write(output)
+f.write("\n")
+except Exception as e:
+bb.warn(f"Can not get target disk usage: {e}")
+
 ##
 # Artifacts retrieval
 ##
@@ -65,7 +79,8 @@ def list_and_fetch_failed_tests_artifacts(d, tc):
 def run_failed_tests_post_actions(d, tc):
 post_actions=[
 create_artifacts_directory,
-list_and_fetch_failed_tests_artifacts
+list_and_fetch_failed_tests_artifacts,
+get_target_disk_usage
 ]
 
 for action in post_actions:
-- 
2.43.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196089): 
https://lists.openembedded.org/g/openembedded-core/message/196089
Mute This Topic: https://lists.openembedded.org/mt/104528474/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 v2 2/5] testimage: create a list of failed test post actions

[Alexis Lothoré via lists . openembedded . org]

From: Alexis Lothoré 

testimage is able to detect whenever a test run leads to some tests
failing, and execute some actions in this case. The only action currently
defined in such case is to retrieve artifacts from the target under test,
as listed in TESTIMAGE_FAILED_QA_ARTIFACTS

In order to be able to add multiple actions, define a central function to
gather all "post actions" to run whenever a test has failed
(run_failed_tests_post_actions). This function contains a table listing all
functions to be called whenever a test fails. Any function in this table
will be provided with bitbake internal data dictionary ("d") and the
current runtime testing context ("tc"). Isolate all this feature in a
dedicated postactions.py file inherited by testimage.
This patch does not bring any functional change.

Signed-off-by: Alexis Lothoré 
---
Changes in v2:
- move functions in a lib in oeqa instead of a bbclass
- use new shared helper get_json_result_dir()
---
 meta/classes-recipe/testimage.bbclass | 42 +
 meta/lib/oeqa/utils/postactions.py| 68 +++
 2 files changed, 70 insertions(+), 40 deletions(-)
 create mode 100644 meta/lib/oeqa/utils/postactions.py

diff --git a/meta/classes-recipe/testimage.bbclass 
b/meta/classes-recipe/testimage.bbclass
index c450566dadea..ad040ee8f071 100644
--- a/meta/classes-recipe/testimage.bbclass
+++ b/meta/classes-recipe/testimage.bbclass
@@ -170,40 +170,6 @@ def get_testimage_boot_patterns(d):
 boot_patterns[flag] = flagval.encode().decode('unicode-escape')
 return boot_patterns
 
-def get_artifacts_list(target, raw_list):
-result = []
-# Passed list may contains patterns in paths, expand them directly on 
target
-for raw_path in raw_list.split():
-cmd = f"for p in {raw_path}; do if [ -e $p ]; then echo $p; fi; done"
-try:
-status, output = target.run(cmd)
-if status != 0 or not output:
-raise Exception()
-result += output.split()
-except:
-bb.note(f"No file/directory matching path {raw_path}")
-
-return result
-
-def retrieve_test_artifacts(target, artifacts_list, target_dir):
-import shutil
-
-local_artifacts_dir = os.path.join(target_dir, "artifacts")
-if os.path.isdir(local_artifacts_dir):
-shutil.rmtree(local_artifacts_dir)
-
-os.makedirs(local_artifacts_dir)
-for artifact_path in artifacts_list:
-if not os.path.isabs(artifact_path):
-bb.warn(f"{artifact_path} is not an absolute path")
-continue
-try:
-dest_dir = os.path.join(local_artifacts_dir, 
os.path.dirname(artifact_path[1:]))
-os.makedirs(dest_dir, exist_ok=True)
-target.copyFrom(artifact_path, dest_dir)
-except Exception as e:
-bb.warn(f"Can not retrieve {artifact_path} from test target: {e}")
-
 def testimage_main(d):
 import os
 import json
@@ -218,6 +184,7 @@ def testimage_main(d):
 from oeqa.core.utils.test import getSuiteCases
 from oeqa.utils import make_logger_bitbake_compatible
 from oeqa.utils import get_json_result_dir
+from oeqa.utils.postactions import run_failed_tests_post_actions
 
 def sigterm_exception(signum, stackframe):
 """
@@ -400,12 +367,7 @@ def testimage_main(d):
 results = tc.runTests()
 complete = True
 if results.hasAnyFailingTest():
-artifacts_list = get_artifacts_list(tc.target, 
d.getVar("TESTIMAGE_FAILED_QA_ARTIFACTS"))
-if not artifacts_list:
-bb.warn("Could not load artifacts list, skip artifacts 
retrieval")
-else:
-bb.warn(f"Retrieving artifacts: 
{d.getVar('TESTIMAGE_FAILED_QA_ARTIFACTS')}")
-retrieve_test_artifacts(tc.target, artifacts_list, 
get_testimage_json_result_dir(d))
+run_failed_tests_post_actions(d, tc)
 except (KeyboardInterrupt, BlockingIOError) as err:
 if isinstance(err, KeyboardInterrupt):
 bb.error('testimage interrupted, shutting down...')
diff --git a/meta/lib/oeqa/utils/postactions.py 
b/meta/lib/oeqa/utils/postactions.py
new file mode 100644
index ..09c338ef6886
--- /dev/null
+++ b/meta/lib/oeqa/utils/postactions.py
@@ -0,0 +1,68 @@
+#
+# Copyright OpenEmbedded Contributors
+#
+# SPDX-License-Identifier: MIT
+#
+
+# Run a set of actions after tests. The runner provides internal data
+# dictionary as well as test context to any action to run.
+
+from oeqa.utils import get_json_result_dir
+
+##
+# Artifacts retrieval
+##
+
+def get_artifacts_list(target, raw_list):
+result = []
+# Passed list may contains patterns in paths, expand them directly on 
target
+for raw_path in raw_list.split():
+cmd = f"for p in {raw_path}; do if [ -e $p ]; then echo 

[OE-Core][PATCH v2 3/5] oeqa/utils/postactions: isolate directory creation in dedicated action

[Alexis Lothoré via lists . openembedded . org]

From: Alexis Lothoré 

In order to be able to create actions that could store new files during
failed test post actions, we need to split artifacts directory creation
from artifacts retrieval.

Create a new dedicated action to create artifacts main directory so we can
add actions creating files in this new directory, without worrying about
actions order if at least this action is set first.

Signed-off-by: Alexis Lothoré 
---
Changes in v2:
- use new shared helper get_json_result_dir()
---
 meta/lib/oeqa/utils/postactions.py | 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/meta/lib/oeqa/utils/postactions.py 
b/meta/lib/oeqa/utils/postactions.py
index 09c338ef6886..7014b2830a9c 100644
--- a/meta/lib/oeqa/utils/postactions.py
+++ b/meta/lib/oeqa/utils/postactions.py
@@ -9,6 +9,15 @@
 
 from oeqa.utils import get_json_result_dir
 
+def create_artifacts_directory(d, tc):
+import shutil
+
+local_artifacts_dir = os.path.join(get_json_result_dir(d), "artifacts")
+if os.path.isdir(local_artifacts_dir):
+shutil.rmtree(local_artifacts_dir)
+
+os.makedirs(local_artifacts_dir)
+
 ##
 # Artifacts retrieval
 ##
@@ -29,13 +38,7 @@ def get_artifacts_list(target, raw_list):
 return result
 
 def retrieve_test_artifacts(target, artifacts_list, target_dir):
-import shutil
-
 local_artifacts_dir = os.path.join(target_dir, "artifacts")
-if os.path.isdir(local_artifacts_dir):
-shutil.rmtree(local_artifacts_dir)
-
-os.makedirs(local_artifacts_dir)
 for artifact_path in artifacts_list:
 if not os.path.isabs(artifact_path):
 bb.warn(f"{artifact_path} is not an absolute path")
@@ -61,6 +64,7 @@ def list_and_fetch_failed_tests_artifacts(d, tc):
 
 def run_failed_tests_post_actions(d, tc):
 post_actions=[
+create_artifacts_directory,
 list_and_fetch_failed_tests_artifacts
 ]
 
-- 
2.43.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196088): 
https://lists.openembedded.org/g/openembedded-core/message/196088
Mute This Topic: https://lists.openembedded.org/mt/104528473/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 v2 1/5] lib/oeqa: share get_json_result_dir helper

[Alexis Lothoré via lists . openembedded . org]

From: Alexis Lothoré 

Multiple places in oeqa need to get the log output path, and redefine a
small helper to accomplish this

Define this helper in lib/oeqa/utils/__init__.py and import it wherever
needed to allow using it.

Signed-off-by: Alexis Lothoré 
---
There is one additional place re-definining (slightly) differently this
helper, which is in selftest/context.py. This one does not check
OEQA_JSON_RESULT_DIR from the datastore but through test data embedded in
the test context. Trying to check the origin of this test data, I
eventually see that it comes from bitbake environment, so I am not sure it
is 100% compatible with the datastore content. Please let me know if I'm
wrong, if so I can also replace selftest redefinition with the shared
helper too.
---
 meta/classes-recipe/testimage.bbclass | 12 +++-
 meta/lib/oeqa/sdk/testsdk.py  | 11 ++-
 meta/lib/oeqa/utils/__init__.py   |  7 +++
 3 files changed, 12 insertions(+), 18 deletions(-)

diff --git a/meta/classes-recipe/testimage.bbclass 
b/meta/classes-recipe/testimage.bbclass
index bee19674ef4f..c450566dadea 100644
--- a/meta/classes-recipe/testimage.bbclass
+++ b/meta/classes-recipe/testimage.bbclass
@@ -149,13 +149,6 @@ def get_testimage_configuration(d, test_type, machine):
 return configuration
 get_testimage_configuration[vardepsexclude] = "DATETIME"
 
-def get_testimage_json_result_dir(d):
-json_result_dir = os.path.join(d.getVar("LOG_DIR"), 'oeqa')
-custom_json_result_dir = d.getVar("OEQA_JSON_RESULT_DIR")
-if custom_json_result_dir:
-json_result_dir = custom_json_result_dir
-return json_result_dir
-
 def get_testimage_result_id(configuration):
 return '%s_%s_%s_%s' % (configuration['TEST_TYPE'], 
configuration['IMAGE_BASENAME'], configuration['MACHINE'], 
configuration['STARTTIME'])
 
@@ -224,6 +217,7 @@ def testimage_main(d):
 from oeqa.core.target.qemu import supported_fstypes
 from oeqa.core.utils.test import getSuiteCases
 from oeqa.utils import make_logger_bitbake_compatible
+from oeqa.utils import get_json_result_dir
 
 def sigterm_exception(signum, stackframe):
 """
@@ -427,14 +421,14 @@ def testimage_main(d):
 # Show results (if we have them)
 if results:
 configuration = get_testimage_configuration(d, 'runtime', machine)
-results.logDetails(get_testimage_json_result_dir(d),
+results.logDetails(get_json_result_dir(d),
 configuration,
 get_testimage_result_id(configuration),
 dump_streams=d.getVar('TESTREPORT_FULLLOGS'))
 results.logSummary(pn)
 
 # Copy additional logs to tmp/log/oeqa so it's easier to find them
-targetdir = os.path.join(get_testimage_json_result_dir(d), d.getVar("PN"))
+targetdir = os.path.join(get_json_result_dir(d), d.getVar("PN"))
 os.makedirs(targetdir, exist_ok=True)
 os.symlink(bootlog, os.path.join(targetdir, os.path.basename(bootlog)))
 os.symlink(d.getVar("BB_LOGFILE"), os.path.join(targetdir, 
os.path.basename(d.getVar("BB_LOGFILE") + "." + d.getVar('DATETIME'
diff --git a/meta/lib/oeqa/sdk/testsdk.py b/meta/lib/oeqa/sdk/testsdk.py
index b4719110edbc..518b09febb61 100644
--- a/meta/lib/oeqa/sdk/testsdk.py
+++ b/meta/lib/oeqa/sdk/testsdk.py
@@ -22,14 +22,6 @@ class TestSDKBase(object):
 'LAYERS': get_layers(d.getVar("BBLAYERS"))}
 return configuration
 
-@staticmethod
-def get_sdk_json_result_dir(d):
-json_result_dir = os.path.join(d.getVar("LOG_DIR"), 'oeqa')
-custom_json_result_dir = d.getVar("OEQA_JSON_RESULT_DIR")
-if custom_json_result_dir:
-json_result_dir = custom_json_result_dir
-return json_result_dir
-
 @staticmethod
 def get_sdk_result_id(configuration):
 return '%s_%s_%s_%s_%s' % (configuration['TEST_TYPE'], 
configuration['IMAGE_BASENAME'], configuration['SDKMACHINE'], 
configuration['MACHINE'], configuration['STARTTIME'])
@@ -72,6 +64,7 @@ class TestSDK(TestSDKBase):
 
 from bb.utils import export_proxies
 from oeqa.utils import make_logger_bitbake_compatible
+from oeqa.utils import get_json_result_dir
 
 pn = d.getVar("PN")
 logger = make_logger_bitbake_compatible(logging.getLogger("BitBake"))
@@ -134,7 +127,7 @@ class TestSDK(TestSDKBase):
 component = "%s %s" % (pn, self.context_executor_class.name)
 context_msg = "%s:%s" % (os.path.basename(tcname), 
os.path.basename(sdk_env))
 configuration = self.get_sdk_configuration(d, self.test_type)
-result.logDetails(self.get_sdk_json_result_dir(d),
+result.logDetails(get_json_result_dir(d),
 configuration,
 self.get_sdk_result_id(configuration))
 result.logSummary(component, context_msg)
diff --git a/meta/lib/oeqa/utils/__init__.py 

Re: [PATCH v1 00/13] Add aarch64-w64-mingw32 target

[Richard Earnshaw (lists)]

On 21/02/2024 17:47, Evgeny Karpov wrote:
> Hello,
> 
> We would like to take your attention to the review of changes for the
> new GCC target, aarch64-w64-mingw32. The new target will be
> supported, tested, added to CI, and maintained by Linaro. This marks
> the first of three planned patch series contributing to the GCC C
> compiler's support for Windows Arm64.
> 
> 1. Minimal aarch64-w64-mingw32 C implementation to cross-compile
> hello-world with libgcc for Windows Arm64 using MinGW.
> 2. Extension of the aarch64-w64-mingw32 C implementation to
> cross-compile OpenSSL, OpenBLAS, FFmpeg, and libjpeg-turbo. All
> packages successfully pass tests.
> 3. Addition of call stack support for debugging, resolution of
> optimization issues in the C compiler, and DLL export/import for the
> aarch64-w64-mingw32 target.
> 
> This patch series introduces the 1st point, which involves building
> hello-world for the aarch64-w64-mingw32 target. The patch depends on
> the binutils changes for the aarch64-w64-mingw32 target that have
> already been merged.
> 
> The binutils should include recent relocation fixes.
> f87eaf8ff3995a5888c6dc4996a20c770e6bcd36
> aarch64: Add new relocations and limit COFF AArch64 relocation offsets
> 
> The series is structured in a way to trivially show that it should not
> affect any other targets.
> 
> In this patch, several changes have been made to support the
> aarch64-w64-mingw32 target for GCC. The modifications include the
> definition of the MS ABI for aarch64, adjustments to FIXED_REGISTERS
> and STATIC_CHAIN_REGNUM for different ABIs, and specific definitions
> for COFF format on AArch64. Additionally, the patch reuses MinGW
>  types and definitions from i386, relocating them to a new
> mingw folder for shared usage between both targets.
> 
> MinGW-specific options have been introduced for AArch64, along with
> override options for aarch64-w64-mingw32. Builtin stack probing for
> override options for aarch64-w64-mingw32. Builtin stack probing for
> AArch64 has been enabled as an alternative for chkstk. Symbol name
> encoding and section information handling for aarch64-w64-mingw32 have
> been incorporated, and the MinGW environment has been added, which
> will also be utilized for defining the Cygwin environment in the
> future.
> 
> The patch includes renaming "x86 Windows Options" to "Cygwin and MinGW
> Options," which now encompasses AArch64 as well. AArch64-specific
> Cygwin and MinGW Options have been introduced for the unique
> requirements of the AArch64 architecture.
> 
> Function type declaration and named sections support have been added.
> The necessary objects for Cygwin and MinGW have been built for the
> aarch64-w64-mingw32 target, and relevant files such as msformat-c.cc
> and winnt-d.cc have been moved to the mingw folder for reuse in
> AArch64.
> 
> Furthermore, the aarch64-w64-mingw32 target has been included in both
> libatomic and libgcc, ensuring support for the AArch64 architecture
> within these libraries. These changes collectively enhance the
> capabilities of GCC for the specified target.
> 
> Coauthors: Zac Walker ,
> Mark Harmstone   and
> Ron Riddle 
> 
> Refactored, prepared, and validated by 
> Radek Barton  and 
> Evgeny Karpov 
> 
> Special thanks to the Linaro GNU toolchain team for internal review
> and assistance in preparing the patch series!
> 
> Regards,
> Evgeny

Thanks for posting this.

I've only read quickly through this patch series and responded where I think 
some action is obviously required.  That doesn't necessarily mean the other 
patches are perfect, though, just that nothing immediately caught my attention.

R.

> 
> 
> Zac Walker (13):
>   Introduce aarch64-w64-mingw32 target
>   aarch64: The aarch64-w64-mingw32 target implements the MS ABI
>   aarch64: Mark x18 register as a fixed register for MS ABI
>   aarch64: Add aarch64-w64-mingw32 COFF
>   Reuse MinGW from i386 for AArch64
>   Rename section and encoding functions from i386 which will be used in
> aarch64
>   Exclude i386 functionality from aarch64 build
>   aarch64: Add Cygwin and MinGW environments for AArch64
>   aarch64: Add SEH to machine_function
>   Rename "x86 Windows Options" to "Cygwin and MinGW Options"
>   aarch64: Build and add objects for Cygwin and MinGW for AArch64
>   aarch64: Add aarch64-w64-mingw32 target to libatomic
>   Add aarch64-w64-mingw32 target to libgcc
> 
>  fixincludes/mkfixinc.sh   |   3 +-
>  gcc/config.gcc|  47 +++--
>  gcc/config/aarch64/aarch64-coff.h |  92 +
>  gcc/config/aarch64/aarch64-opts.h |   7 +
>  gcc/config/aarch64/aarch64-protos.h   |   5 +
>  gcc/config/aarch64/aarch64.h  |  25 ++-
>  gcc/config/aarch64/cygming.h  | 178 ++
>  gcc/config/i386/cygming.h |  18 +-
>  gcc/config/i386/cygming.opt.urls  |  30 ---
>  gcc/config/i386/i386-protos.h  

Re: [PATCH v1 13/13] Add aarch64-w64-mingw32 target to libgcc

[Richard Earnshaw (lists)]

On 21/02/2024 18:40, Evgeny Karpov wrote:
> 
+aarch64-*-mingw*)

This doesn't match the glob pattern you added to config.gcc in an earlier 
patch, but see my comment on that.  The two should really be consistent with 
each other or you might get build failures late on.

R.

Re: [PATCH v1 10/13] Rename "x86 Windows Options" to "Cygwin and MinGW Options"

[Richard Earnshaw (lists)]

On 21/02/2024 18:38, Evgeny Karpov wrote:
> 
For this change you might want to put some form of re-direct in the manual 
under the old name so that anybody used to looking for the old entry will know 
where things have been moved to.  Something like

x86 Windows Options
  See xref(Cygwin and MinGW Options).

R.

Re: [PATCH v1 08/13] aarch64: Add Cygwin and MinGW environments for AArch64

[Richard Earnshaw (lists)]

On 21/02/2024 18:36, Evgeny Karpov wrote:
> 
+/* GNU as supports weak symbols on PECOFF.  */
+#ifdef HAVE_GAS_WEAK

Can't we assume this is true?  It was most likely needed on i386 because 
support goes back longer than the assembler had this feature, but it looks like 
it was added in 2000, or thereabouts, so significantly before aarch64 was 
supported in the assembler.

+#ifndef HAVE_GAS_ALIGNED_COMM

And this was added to GCC in 2009, which probably means it predates 
aarch64-coff support in gas as well.

R.

Re: [PATCH v1 03/13] aarch64: Mark x18 register as a fixed register for MS ABI

[Richard Earnshaw (lists)]

On 21/02/2024 18:30, Evgeny Karpov wrote:
> 
+   tm_defines="${tm_defines} TARGET_ARM64_MS_ABI=1"

I missed this on first reading...

The GCC port name uses AARCH64, please use that internally rather than other 
names.  The only time when we should be using ARM64 is when it's needed for 
compatibility with other compilers and that doesn't apply here AFAICT.

R.

Re: [PATCH v1 03/13] aarch64: Mark x18 register as a fixed register for MS ABI

[Richard Earnshaw (lists)]

On 21/02/2024 18:30, Evgeny Karpov wrote:
> 
+/* X18 reserved for the TEB on Windows.  */
+#ifdef TARGET_ARM64_MS_ABI
+# define FIXED_X18 1
+# define CALL_USED_X18 0
+#else
+# define FIXED_X18 0
+# define CALL_USED_X18 1
+#endif

I'm not overly keen on ifdefs like this (and the one below), it can get quite 
confusing if we have to support more than a couple of ABIs.  Perhaps we could 
create a couple of new headers, one for the EABI (which all existing targets 
would then need to include) and one for the MS ABI.  Then the mingw port would 
use that instead of the EABI header.

An alternative is to make all this dynamic, based on the setting of the 
aarch64_calling_abi enum and to make the adjustments in 
aarch64_conditional_register_usage.

+# define CALL_USED_X18 0

Is that really correct?  If the register is really reserved, but some code 
modifies it anyway, this will cause the compiler to restore the old value at 
the end of a function; generally, for a reserved register, code that knows what 
it's doing would want to make permanent changes to this value.

+#ifdef TARGET_ARM64_MS_ABI
+# define STATIC_CHAIN_REGNUM   R17_REGNUM
+#else
+# define STATIC_CHAIN_REGNUM   R18_REGNUM
+#endif

If we went the enum way, we'd want something like

#define STATIC_CHAIN_REGNUM (calling_abi == AARCH64_CALLING_ABI_MS ? R17_REGNUM 
: R18_REGNUM)

R.

Re: [PATCH v1 02/13] aarch64: The aarch64-w64-mingw32 target implements

[Richard Earnshaw (lists)]

On 21/02/2024 18:26, Evgeny Karpov wrote:
> 
+/* Available call ABIs.  */
+enum calling_abi
+{
+  AARCH64_EABI = 0,
+  MS_ABI = 1
+};
+

The convention in this file seems to be that all enum types to start with 
aarch64.  Also, the enumeration values should start with the name of the 
enumeration type in upper case, so:

enum aarch64_calling_abi
{
  AARCH64_CALLING_ABI_EABI,
  AARCH64_CALLING_ABI_MS
};

or something very much like that.

R.

Re: [PATCH v1 01/13] Introduce aarch64-w64-mingw32 target

[Richard Earnshaw (lists)]

On 21/02/2024 18:16, Evgeny Karpov wrote:
> 
+aarch64*-*-mingw*)

Other targets are a bit inconsistent here as well, but, as Andrew mentioned, if 
you don't want to handle big-endian, it might be better to match 
aarch64-*-mingw* here.

R.

Re: [PATCH v1 05/13] Reuse MinGW from i386 for AArch64

[Richard Earnshaw (lists)]

On 21/02/2024 21:34, rep.dot@gmail.com wrote:
> On 21 February 2024 19:34:43 CET, Evgeny Karpov  
> wrote:
>>
> 
> Please use git send-email. Your mail ends up as empty as here, otherwise.

I don't see anything wrong with it; niether does patchwork 
(https://patchwork.sourceware.org/project/gcc/list/?series=31191) nor does the 
Linaro CI bot.  So perhaps it's your mailer that's misconfigured.

> 
> The ChangeLog has to be expressed in present tense, as mandated by the 
> standard; s/Moved/Move/g etc.

Agreed, but that's a detail that we can get to once the patch has been properly 
reviewed.

> 
> In any sane world ( and in gcc ) to fold, respectively a folder, is something 
> else compared to a directory ( which you probably mean when moving a file 
> from one directory to another directory as you seem to do ).
> 
> Most of the free world has left COFF behind since several decades, so I won't 
> comment on that. YMMV.

This isn't helpful.  Windows platforms use (a derivative of) COFF, so that's 
what the tools need to use when targetting that platform.

R.

Re: [PATCH] ARM: Fix conditional execution [PR113915]

[Richard Earnshaw (lists)]

On 21/02/2024 14:34, Wilco Dijkstra wrote:
> 
> By default most patterns can be conditionalized on Arm targets.  However
> Thumb-2 predication requires the "predicable" attribute be explicitly
> set to "yes".  Most patterns are shared between Arm and Thumb(-2) and are
> marked with "predicable".  Given this sharing, it does not make sense to
> use a different default for Arm.  So only consider conditional execution
> of instructions that have the predicable attribute set to yes.  This ensures
> that patterns not explicitly marked as such are never accidentally 
> conditionally executed like in the PR.
> 
> GLIBC codesize was ~0.014% worse due to atomic operations now being
> unconditional and a small number of patterns not setting "predicable".
> 
> Passes regress and bootstrap, OK for commit?
> 
> gcc/ChangeLog:
> PR target/113915
> * config/arm/arm.md (NOCOND): Improve comment.
> * config/arm/arm.cc (arm_final_prescan_insn): Add check for
> PREDICABLE_YES.
> 
> gcc/testsuite/ChangeLog:
> PR target/113915
> * gcc.target/arm/builtin-bswap-1.c: Fix test.
> 
> ---
> 
> diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc
> index 
> c44047c377a802d0c1dc1406df1b88a6b079607b..29771d284831a995adcf9adbb525396fbabb1ea2
>  100644
> --- a/gcc/config/arm/arm.cc
> +++ b/gcc/config/arm/arm.cc
> @@ -25610,11 +25610,12 @@ arm_final_prescan_insn (rtx_insn *insn)
> break;
>  
>   case INSN:
> -   /* Instructions using or affecting the condition codes make it
> -  fail.  */
> +   /* Check the instruction is explicitly marked as predicable.
> +  Instructions using or affecting the condition codes are not.  
> */
> scanbody = PATTERN (this_insn);
> if (!(GET_CODE (scanbody) == SET
>   || GET_CODE (scanbody) == PARALLEL)
> +   || get_attr_predicable (this_insn) != PREDICABLE_YES
> || get_attr_conds (this_insn) != CONDS_NOCOND)
>   fail = TRUE;
> break;
> diff --git a/gcc/config/arm/arm.md b/gcc/config/arm/arm.md
> index 
> 5816409f86f1106b410c5e21d77e599b485f85f2..671f093862259c2c0df93a986fc22fa56a8ea6c7
>  100644
> --- a/gcc/config/arm/arm.md
> +++ b/gcc/config/arm/arm.md
> @@ -307,6 +307,8 @@
>  ;
>  ; NOCOND means that the instruction does not use or alter the condition
>  ;   codes but can be converted into a conditionally exectuted instruction.
> +;   Given that NOCOND is the default for most instructions if omitted,
> +;   the attribute predicable must be set to yes as well.
>  
>  (define_attr "conds" "use,set,clob,unconditional,nocond"
>   (if_then_else

While this is ok, 

> diff --git a/gcc/testsuite/gcc.target/arm/builtin-bswap-1.c 
> b/gcc/testsuite/gcc.target/arm/builtin-bswap-1.c
> index 
> c1e7740d14d3ca4e93a71e38b12f82c19791a204..3de7cea81c1128c2fe5a9e1216e6b027d26bcab9
>  100644
> --- a/gcc/testsuite/gcc.target/arm/builtin-bswap-1.c
> +++ b/gcc/testsuite/gcc.target/arm/builtin-bswap-1.c
> @@ -5,14 +5,8 @@
> of the instructions.  Add an -mtune option known to facilitate that.  */
>  /* { dg-additional-options "-O2 -mtune=cortex-a53" } */
>  /* { dg-final { scan-assembler-not "orr\[ \t\]" } } */
> -/* { dg-final { scan-assembler-times "revsh\\t" 1 { target { arm_nothumb } } 
> } }  */
> -/* { dg-final { scan-assembler-times "revshne\\t" 1 { target { arm_nothumb } 
> } } }  */
> -/* { dg-final { scan-assembler-times "revsh\\t" 2 { target { ! arm_nothumb } 
> } } }  */
> -/* { dg-final { scan-assembler-times "rev16\\t" 1 { target { arm_nothumb } } 
> } }  */
> -/* { dg-final { scan-assembler-times "rev16ne\\t" 1 { target { arm_nothumb } 
> } } }  */
> -/* { dg-final { scan-assembler-times "rev16\\t" 2 { target { ! arm_nothumb } 
> } } }  */
> -/* { dg-final { scan-assembler-times "rev\\t" 2 { target { arm_nothumb } } } 
> }  */
> -/* { dg-final { scan-assembler-times "revne\\t" 2 { target { arm_nothumb } } 
> } }  */
> -/* { dg-final { scan-assembler-times "rev\\t" 4 { target { ! arm_nothumb } } 
> } }  */
> +/* { dg-final { scan-assembler-times "revsh\\t" 2 } }  */
> +/* { dg-final { scan-assembler-times "rev16\\t" 2 } }  */
> +/* { dg-final { scan-assembler-times "rev\\t" 4 } }  */
>  
>  #include "builtin-bswap.x"

This bit isn't.  The correct fix here is to fix the pattern(s) concerned to add 
the missing predicate.

Note that builtin-bswap.x explicitly mentions predicated mnemonics in the 
comments.

R.

Re: [OE-Core][PATCH 1/4] testimage: create a list of failed test post actions

[Alexis Lothoré via lists . openembedded . org]

On 2/21/24 08:56, Richard Purdie wrote:
> On Wed, 2024-02-21 at 08:53 +0100, Alexis Lothoré wrote:
>> On 2/21/24 08:34, Richard Purdie wrote:
>>> On Tue, 2024-02-20 at 21:01 +0100, Alexis Lothoré via
>>> lists.openembedded.org wrote:
 From: Alexis Lothoré 
>>
>> [...]
>>
 +
 ##
 +# General post actions runner
 +
 ##
 +
 +def run_failed_tests_post_actions(d, tc):
 +    post_actions=[
 +    list_and_fetch_failed_tests_artifacts
 +    ]
 +
 +    for action in post_actions:
 +    action(d, tc)
>>>
>>> Rather than create a bbclass class of python functions, these
>>> should
>>> move to lib/oe and become a proper python library file?
>>
>> ACK, I will do that and create a proper python file for this.
>>
>>> Moving functions out of the class files is on my long term todo
>>> list so
>>> this seems like an idea opportunity.
>>
>> So should this series take the opportunity to move all already
>> existing python
>> functions from testimage to a lib ? I can certainly do that if that's
>> your point :)
> 
> I'm saying over time I think many of the python functions need to move.
> This close to feature freeze may not be the best time, I just wanted to
> give a clear view of my intent.
> 
> Sometimes the variable dependencies don't work the same way from the
> python library so we need to be careful.

Ok, thanks for the clarification. I will then only fix my series to not create a
new bbclass but a lib for now.

> Cheers,
> 
> Richard
> 
> 
> 

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


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

Re: [OE-Core][PATCH 1/4] testimage: create a list of failed test post actions

[Alexis Lothoré via lists . openembedded . org]

Hello Richard,

On 2/21/24 08:34, Richard Purdie wrote:
> On Tue, 2024-02-20 at 21:01 +0100, Alexis Lothoré via
> lists.openembedded.org wrote:
>> From: Alexis Lothoré 

[...]

>> +##
>> +# General post actions runner
>> +##
>> +
>> +def run_failed_tests_post_actions(d, tc):
>> +    post_actions=[
>> +    list_and_fetch_failed_tests_artifacts
>> +    ]
>> +
>> +    for action in post_actions:
>> +    action(d, tc)
> 
> Rather than create a bbclass class of python functions, these should
> move to lib/oe and become a proper python library file?

ACK, I will do that and create a proper python file for this.

> Moving functions out of the class files is on my long term todo list so
> this seems like an idea opportunity.

So should this series take the opportunity to move all already existing python
functions from testimage to a lib ? I can certainly do that if that's your 
point :)

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


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#195960): 
https://lists.openembedded.org/g/openembedded-core/message/195960
Mute This Topic: https://lists.openembedded.org/mt/104474968/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 3/4] testimage: add target disk usage stat as post action

[Alexis Lothoré via lists . openembedded . org]

From: Alexis Lothoré 

In order to debug issues related to disk space (see [1]),  add a failed
tests post action to retrieve disk usage on the target. Rely on the test
context object to run the corresponding command onto the target

[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=15220

Signed-off-by: Alexis Lothoré 
---
 .../failed-tests-post-actions.bbclass   | 17 -
 1 file changed, 16 insertions(+), 1 deletion(-)

diff --git a/meta/classes-recipe/failed-tests-post-actions.bbclass 
b/meta/classes-recipe/failed-tests-post-actions.bbclass
index eaf08fb792f3..a8604fca2b9d 100644
--- a/meta/classes-recipe/failed-tests-post-actions.bbclass
+++ b/meta/classes-recipe/failed-tests-post-actions.bbclass
@@ -5,6 +5,20 @@
 #
 
 
+##
+# Host/target statistics
+##
+
+def get_target_disk_usage(d, tc):
+output_file = os.path.join(get_testimage_json_result_dir(d), "artifacts", 
"target_disk_usage.txt")
+try:
+(status, output) = tc.target.run('df -hl')
+with open(output_file, 'w') as f:
+f.write(output)
+f.write("\n")
+except Exception as e:
+bb.warn(f"Can not get target disk usage: {e}")
+
 ##
 # Artifacts retrieval
 ##
@@ -61,7 +75,8 @@ def list_and_fetch_failed_tests_artifacts(d, tc):
 def run_failed_tests_post_actions(d, tc):
 post_actions=[
 create_artifacts_directory,
-list_and_fetch_failed_tests_artifacts
+list_and_fetch_failed_tests_artifacts,
+get_target_disk_usage
 ]
 
 for action in post_actions:
-- 
2.43.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#195928): 
https://lists.openembedded.org/g/openembedded-core/message/195928
Mute This Topic: https://lists.openembedded.org/mt/104474969/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 4/4] testimage: add host disk usage stat as post action

[Alexis Lothoré via lists . openembedded . org]

From: Alexis Lothoré 

Since the target under test can be a virtualized guest, when some tests
fail because of disk usage (see [1]), also fetch disk usage statistics from
host to allow checking whether a host disk space saturation could affect
running tests.

[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=15220

Signed-off-by: Alexis Lothoré 
---
 .../failed-tests-post-actions.bbclass   | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/meta/classes-recipe/failed-tests-post-actions.bbclass 
b/meta/classes-recipe/failed-tests-post-actions.bbclass
index a8604fca2b9d..a9e92aa2427e 100644
--- a/meta/classes-recipe/failed-tests-post-actions.bbclass
+++ b/meta/classes-recipe/failed-tests-post-actions.bbclass
@@ -19,6 +19,16 @@ def get_target_disk_usage(d, tc):
 except Exception as e:
 bb.warn(f"Can not get target disk usage: {e}")
 
+def get_host_disk_usage(d, tc):
+import subprocess
+
+output_file = os.path.join(get_testimage_json_result_dir(d), "artifacts", 
"host_disk_usage.txt")
+try:
+with open(output_file, 'w') as f:
+output = subprocess.run(['/usr/bin/df', '-hl'], check=True, 
text=True, stdout=f)
+except Exception as e:
+bb.warn(f"Can not get host disk usage: {e}")
+
 ##
 # Artifacts retrieval
 ##
@@ -76,7 +86,8 @@ def run_failed_tests_post_actions(d, tc):
 post_actions=[
 create_artifacts_directory,
 list_and_fetch_failed_tests_artifacts,
-get_target_disk_usage
+get_target_disk_usage,
+get_host_disk_usage
 ]
 
 for action in post_actions:
-- 
2.43.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#195929): 
https://lists.openembedded.org/g/openembedded-core/message/195929
Mute This Topic: https://lists.openembedded.org/mt/104474970/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 0/4] testimage: add failed test post actions and fetch more data

[Alexis Lothoré via lists . openembedded . org]

Hello,
this small series is related to some disk space issue observed by the SWAT
team (see [1]) which eventually leads to tests failure. In order to help
diagnose those issues, I propose to enrich the retrieved artifacts with
some additional data, like disk usage on target and on host (in case the
target is a virtualized guest)

To do so, this series first reworks a bit actions executed on failed tests
to allow declaring a sequence of actions. It then introduces two small
actions which basically run "df" on target and host. I chose to store
those stats in dedicated files, thinking it is better than "contaminating"
tests steps logs with those very specific data.

[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=15220

Signed-off-by: Alexis Lothoré 

Alexis Lothoré (4):
  testimage: create a list of failed test post actions
  testimage: isolate artifacts directory creation in dedicated post
action
  testimage: add target disk usage stat as post action
  testimage: add host disk usage stat as post action

 .../failed-tests-post-actions.bbclass | 94 +++
 meta/classes-recipe/testimage.bbclass | 42 +
 2 files changed, 96 insertions(+), 40 deletions(-)
 create mode 100644 meta/classes-recipe/failed-tests-post-actions.bbclass

-- 
2.43.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#195925): 
https://lists.openembedded.org/g/openembedded-core/message/195925
Mute This Topic: https://lists.openembedded.org/mt/104474966/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 2/4] testimage: isolate artifacts directory creation in dedicated post action

[Alexis Lothoré via lists . openembedded . org]

From: Alexis Lothoré 

In order to be able to create actions that could store new files during
failed test post actions, we need to split artifacts directory creation
from artifacts retrieval.

Create a new dedicated action to create artifacts main directory so we can
add actions creating files in this new directory, without worrying about
actions order if at least this action is set first.

Signed-off-by: Alexis Lothoré 
---
 .../failed-tests-post-actions.bbclass| 16 ++--
 1 file changed, 10 insertions(+), 6 deletions(-)

diff --git a/meta/classes-recipe/failed-tests-post-actions.bbclass 
b/meta/classes-recipe/failed-tests-post-actions.bbclass
index 7c7d3391298f..eaf08fb792f3 100644
--- a/meta/classes-recipe/failed-tests-post-actions.bbclass
+++ b/meta/classes-recipe/failed-tests-post-actions.bbclass
@@ -9,6 +9,15 @@
 # Artifacts retrieval
 ##
 
+def create_artifacts_directory(d, tc):
+import shutil
+
+local_artifacts_dir = os.path.join(get_testimage_json_result_dir(d), 
"artifacts")
+if os.path.isdir(local_artifacts_dir):
+shutil.rmtree(local_artifacts_dir)
+
+os.makedirs(local_artifacts_dir)
+
 def get_artifacts_list(target, raw_list):
 result = []
 # Passed list may contains patterns in paths, expand them directly on 
target
@@ -25,13 +34,7 @@ def get_artifacts_list(target, raw_list):
 return result
 
 def retrieve_test_artifacts(target, artifacts_list, target_dir):
-import shutil
-
 local_artifacts_dir = os.path.join(target_dir, "artifacts")
-if os.path.isdir(local_artifacts_dir):
-shutil.rmtree(local_artifacts_dir)
-
-os.makedirs(local_artifacts_dir)
 for artifact_path in artifacts_list:
 if not os.path.isabs(artifact_path):
 bb.warn(f"{artifact_path} is not an absolute path")
@@ -57,6 +60,7 @@ def list_and_fetch_failed_tests_artifacts(d, tc):
 
 def run_failed_tests_post_actions(d, tc):
 post_actions=[
+create_artifacts_directory,
 list_and_fetch_failed_tests_artifacts
 ]
 
-- 
2.43.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#195926): 
https://lists.openembedded.org/g/openembedded-core/message/195926
Mute This Topic: https://lists.openembedded.org/mt/104474967/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 1/4] testimage: create a list of failed test post actions

[Alexis Lothoré via lists . openembedded . org]

From: Alexis Lothoré 

testimage is able to detect whenever a test run leads to some tests
failing, and execute some actions in this case. The only action currently
defined in such case is to retrieve artifacts from the target under test,
as listed in TESTIMAGE_FAILED_QA_ARTIFACTS

In order to be able to add multiple actions, define a central function to
gather all "post actions" to run whenever a test has failed
(run_failed_tests_post_actions). This function contains a table listing all
functions to be called whenever a test fails. Any function in this table
will be provided with bitbake internal data dictionary ("d") and the
current runtime testing context ("tc"). Isolate all this feature in a
dedicated bbclass file inherited by testimage.
This patch does not bring any functional change.

Signed-off-by: Alexis Lothoré 
---
 .../failed-tests-post-actions.bbclass | 64 +++
 meta/classes-recipe/testimage.bbclass | 42 +---
 2 files changed, 66 insertions(+), 40 deletions(-)
 create mode 100644 meta/classes-recipe/failed-tests-post-actions.bbclass

diff --git a/meta/classes-recipe/failed-tests-post-actions.bbclass 
b/meta/classes-recipe/failed-tests-post-actions.bbclass
new file mode 100644
index ..7c7d3391298f
--- /dev/null
+++ b/meta/classes-recipe/failed-tests-post-actions.bbclass
@@ -0,0 +1,64 @@
+#
+# Copyright OpenEmbedded Contributors
+#
+# SPDX-License-Identifier: MIT
+#
+
+
+##
+# Artifacts retrieval
+##
+
+def get_artifacts_list(target, raw_list):
+result = []
+# Passed list may contains patterns in paths, expand them directly on 
target
+for raw_path in raw_list.split():
+cmd = f"for p in {raw_path}; do if [ -e $p ]; then echo $p; fi; done"
+try:
+status, output = target.run(cmd)
+if status != 0 or not output:
+raise Exception()
+result += output.split()
+except:
+bb.note(f"No file/directory matching path {raw_path}")
+
+return result
+
+def retrieve_test_artifacts(target, artifacts_list, target_dir):
+import shutil
+
+local_artifacts_dir = os.path.join(target_dir, "artifacts")
+if os.path.isdir(local_artifacts_dir):
+shutil.rmtree(local_artifacts_dir)
+
+os.makedirs(local_artifacts_dir)
+for artifact_path in artifacts_list:
+if not os.path.isabs(artifact_path):
+bb.warn(f"{artifact_path} is not an absolute path")
+continue
+try:
+dest_dir = os.path.join(local_artifacts_dir, 
os.path.dirname(artifact_path[1:]))
+os.makedirs(dest_dir, exist_ok=True)
+target.copyFrom(artifact_path, dest_dir)
+except Exception as e:
+bb.warn(f"Can not retrieve {artifact_path} from test target: {e}")
+
+def list_and_fetch_failed_tests_artifacts(d, tc):
+artifacts_list = get_artifacts_list(tc.target, 
d.getVar("TESTIMAGE_FAILED_QA_ARTIFACTS"))
+if not artifacts_list:
+bb.warn("Could not load artifacts list, skip artifacts retrieval")
+else:
+retrieve_test_artifacts(tc.target, artifacts_list, 
get_testimage_json_result_dir(d))
+
+
+##
+# General post actions runner
+##
+
+def run_failed_tests_post_actions(d, tc):
+post_actions=[
+list_and_fetch_failed_tests_artifacts
+]
+
+for action in post_actions:
+action(d, tc)
diff --git a/meta/classes-recipe/testimage.bbclass 
b/meta/classes-recipe/testimage.bbclass
index bee19674ef4f..d2b525d40f41 100644
--- a/meta/classes-recipe/testimage.bbclass
+++ b/meta/classes-recipe/testimage.bbclass
@@ -4,6 +4,7 @@
 
 inherit metadata_scm
 inherit image-artifact-names
+inherit failed-tests-post-actions
 
 # testimage.bbclass enables testing of qemu images using python unittests.
 # Most of the tests are commands run on target image over ssh.
@@ -177,40 +178,6 @@ def get_testimage_boot_patterns(d):
 boot_patterns[flag] = flagval.encode().decode('unicode-escape')
 return boot_patterns
 
-def get_artifacts_list(target, raw_list):
-result = []
-# Passed list may contains patterns in paths, expand them directly on 
target
-for raw_path in raw_list.split():
-cmd = f"for p in {raw_path}; do if [ -e $p ]; then echo $p; fi; done"
-try:
-status, output = target.run(cmd)
-if status != 0 or not output:
-raise Exception()
-result += output.split()
-except:
-bb.note(f"No file/directory matching path {raw_path}")
-
-return result
-
-def retrieve_test_artifacts(target, artifacts_list, target_dir):
-import shutil
-
-local_artifacts_dir = os.path.join(target_dir, "artifacts")
-if 

Re: [AFMUG] Wood Pole Mount

[Jeff Broadwick - Lists]

Chain mount.  Chuck has them as does PV and CommScope.Regards,Jeff Jeff BroadwickCTIconnect312-205-2519 Office574-220-7826 Celljbroadw...@cticonnect.comOn Feb 20, 2024, at 1:06 PM, Ken Hohhof  wrote:I think I’ve got some of the Valmont ones on the shelf.  Like everything from SitePro1, they are huskier than they look in the catalog. From: AF  On Behalf Of dmmoff...@gmail.comSent: Tuesday, February 20, 2024 11:40 AMTo: 'AnimalFarm Microwave Users Group' Subject: Re: [AFMUG] Wood Pole Mount +1 to both of those suggestions.I’ve seen plenty of universal mounts attached to a wooden pole (J-arms, J-pipes, or whatever you want to call them).Rohn WM4 is the name brand galvanized 4” wall mount, but there are a thousand copies out there.  Just watch out for zinc plating or other BS finishes.  I’m sure Channel Master is fine. One other thing, you’re not supposed to drill into the top surface of a wooden pole because rain will pool in the holes and speed up rotting.  You’re also not supposed to drill the sides within so many inches of the top (4” maybe? I don’t recall).  That’s why those pole-top mounts you see are straddling the top and have bolt holes farther down.  If you put a galvanized pipe into one of those wall mounts then you can have your mast above the top and also not be putting hardware at the top.  Electric/phone companies won’t like that solution because it uses more vertical real estate, but if it’s just a light pole then it ought not be a problem. If you do want something heavy duty that won’t break the bank then look at the Site Pro version of the WM4:https://www.sitepro1.com/store/cart.php?m=product_list=1218https://valmont-sitepro1-cdn.s3.amazonaws.com/spec-sheet/HDWM04%20(Assembly).pdfI don’t know the thickness of the steel stock, but the Channel Master one weighs 1 pound and the Site Pro one weighs 6.8 pounds, so I’m sure it’s sufficiently burly for most equipment. -Adam  From: AF  On Behalf Of Ken HohhofSent: Tuesday, February 20, 2024 10:52 AMTo: af@af.afmug.comSubject: Re: [AFMUG] Wood Pole Mount Or the ChannelMaster 4" offset wall mounts, we call them W brackets. Original Message From: "Josh Luthman" Sent: 2/20/2024 9:37:59 AMTo: "AnimalFarm Microwave Users Group" Subject: Re: [AFMUG] Wood Pole MountJust use a Jpole?  Or an MTOW? On Tue, Feb 20, 2024 at 10:31?AM Matt  wrote:I need to mount a small steel pole to a wood light pole. The kits Isee online are like $300 range and way more robust than I need. Justmounting a small yagi a few feet above the top of the wood pole. Doesanyone know of anything?-- AF mailing listAF@af.afmug.comhttp://af.afmug.com/mailman/listinfo/af_af.afmug.com-- AF mailing listAF@af.afmug.comhttp://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

Re: [tor-relays] Problem with relay and ovh??

[lists]

On Sonntag, 18. Februar 2024 01:42:30 CET Keifer Bly wrote:

Every few months the same question with the same log messages :-(

> 00:36:35.000 [warn] You are running Tor as root. You don't need to, and you
> probably shouldn't.
^^Still not fixed.

> Feb 18 00:36:34.640 [notice] Opening OR listener on [::]:9001
> Feb 18 00:36:34.640 [notice] Opened OR listener connection (ready) on [::]9001
IPv6 is not configured in torrc.
If anything is unclear, 'man torrc' helps. Search|grep 'Address' & 'ORPort'

> Feb 18 00:36:50.000 [notice] Unable to find IPv6 address for ORPort 9001.
> You might want to specify IPv4Only to it or set an explicit address or set or 
> set Address.
The error message is clear and precise.

-- 
╰_╯ 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

[OE-Core][PATCH] testimage: log exception when failing to retrieve artifacts

[Alexis Lothoré via lists . openembedded . org]

From: Alexis Lothoré 

Despite managing to retrieve the failed ptests artifacts, testimage seems
to dump some retrieval errors like the following one:

WARNING: core-image-ptest-valgrind-1.0-r0 do_testimage: Can not retrieve
/usr/lib/valgrind/ptest from test target

Log the corresponding exception to help analyzing such issue

Signed-off-by: Alexis Lothoré 
---
As a more detailed example, such log is visible in [1], while artifacts
have been properly pushed in the corresponding web server in [2]

[1] 
https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/6099/steps/13/logs/stdio
[2] 
https://autobuilder.yocto.io/pub/non-release/20240218-3/testresults/qemuarm64-ptest/artifacts/usr/lib/valgrind/ptest/
---
 meta/classes-recipe/testimage.bbclass | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes-recipe/testimage.bbclass 
b/meta/classes-recipe/testimage.bbclass
index 934272b6b837..bee19674ef4f 100644
--- a/meta/classes-recipe/testimage.bbclass
+++ b/meta/classes-recipe/testimage.bbclass
@@ -208,8 +208,8 @@ def retrieve_test_artifacts(target, artifacts_list, 
target_dir):
 dest_dir = os.path.join(local_artifacts_dir, 
os.path.dirname(artifact_path[1:]))
 os.makedirs(dest_dir, exist_ok=True)
 target.copyFrom(artifact_path, dest_dir)
-except:
-bb.warn(f"Can not retrieve {artifact_path} from test target")
+except Exception as e:
+bb.warn(f"Can not retrieve {artifact_path} from test target: {e}")
 
 def testimage_main(d):
 import os
-- 
2.43.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#195917): 
https://lists.openembedded.org/g/openembedded-core/message/195917
Mute This Topic: https://lists.openembedded.org/mt/104467041/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] overlayfs: add missing vardeps

[Christoph Vogtländer via lists . openembedded . org]

Fixes [YOCTO #15120]

Consider OVERLAYFS_WRITABLE_PATHS as dependecy of do_create_overlayfs_units() in
order to rebuild the recipe when changing the used mount point.

Tested in a local recipe by changing the used mount point and verified that the
recipe was re-build: passed

Signed-off-by: Christoph Vogtländer 

---
 meta/classes-recipe/overlayfs.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes-recipe/overlayfs.bbclass 
b/meta/classes-recipe/overlayfs.bbclass
index 53d65d7531..a82763ec10 100644
--- a/meta/classes-recipe/overlayfs.bbclass
+++ b/meta/classes-recipe/overlayfs.bbclass
@@ -138,4 +138,5 @@ do_install:append() {
 done
 }
 
+do_create_overlayfs_units[vardeps] += "OVERLAYFS_WRITABLE_PATHS"
 addtask create_overlayfs_units before do_install
-- 
2.34.1


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

Re: [comitted] bitint: Fix testism where __seg_gs was being used for all targets

[Andre Vieira (lists)]

On 19/02/2024 16:17, Jakub Jelinek wrote:

On Mon, Feb 19, 2024 at 04:13:29PM +, Andre Vieira (lists) wrote:

Replaced uses of __seg_gs with the MACRO SEG defined in the testcase to pick
(if any) the right __seg_{gs,fs} keyword based on target.

gcc/testsuite/ChangeLog:

* gcc.dg/bitint-86.c (__seg_gs): Replace with SEG MACRO.


ChangeLog should be
* gcc.dg/bitint-86.c (foo, bar, baz): Replace __seg_gs with SEG.
Otherwise, LGTM.
Sorry for forgetting to do that myself.


Jakub



That makes sense ... but I already pushed it upstream, thought it was 
obvious. Apologies for the ChangeLog mistake :(

[comitted] bitint: Fix testism where __seg_gs was being used for all targets

[Andre Vieira (lists)]

Replaced uses of __seg_gs with the MACRO SEG defined in the testcase to 
pick (if any) the right __seg_{gs,fs} keyword based on target.


gcc/testsuite/ChangeLog:

* gcc.dg/bitint-86.c (__seg_gs): Replace with SEG MACRO.diff --git a/gcc/testsuite/gcc.dg/bitint-86.c b/gcc/testsuite/gcc.dg/bitint-86.c
index 
4e5761a203bc39150540326df9c0d88544bb02ef..10a2392b6f530ae165252bdac750061e92d53131
 100644
--- a/gcc/testsuite/gcc.dg/bitint-86.c
+++ b/gcc/testsuite/gcc.dg/bitint-86.c
@@ -15,14 +15,14 @@ struct T { struct S b[4]; };
 #endif
 
 void
-foo (__seg_gs struct T *p)
+foo (SEG struct T *p)
 {
   struct S s;
   p->b[0] = s;
 }
 
 void
-bar (__seg_gs struct T *p, _BitInt(710) x, int y, double z)
+bar (SEG struct T *p, _BitInt(710) x, int y, double z)
 {
   p->b[0].a = x + 42;
   p->b[1].a = x << y;
@@ -31,7 +31,7 @@ bar (__seg_gs struct T *p, _BitInt(710) x, int y, double z)
 }
 
 int
-baz (__seg_gs struct T *p, _BitInt(710) x, _BitInt(710) y)
+baz (SEG struct T *p, _BitInt(710) x, _BitInt(710) y)
 {
   return __builtin_add_overflow (x, y, >b[1].a);
 }

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

[Andre Vieira (lists)]

Hi all,

OK to backport this to gcc-12 and gcc-13? Patch applies cleanly, 
bootstrapped and regression tested on aarch64-unknown-linux-gnu. Only 
change is in the testcase as I had to use -march=armv9-a because 
-march=armv8-a+sve conflicts with -mcpu=neoverse-n2 in previous gcc 
versions.


Kind Regards,
Andre

On 20/12/2023 14:30, Richard Biener wrote:

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


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.


OK.

Richard.


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.

Re: [PATCH]AArch64: xfail modes_1.f90 [PR107071]

[Richard Earnshaw (lists)]

On 19/02/2024 10:58, Tamar Christina wrote:
>> -Original Message-
>> From: Tamar Christina
>> Sent: Thursday, February 15, 2024 11:05 AM
>> To: Richard Earnshaw (lists) ; gcc-
>> patc...@gcc.gnu.org
>> Cc: nd ; Marcus Shawcroft ; Kyrylo
>> Tkachov ; Richard Sandiford
>> 
>> Subject: RE: [PATCH]AArch64: xfail modes_1.f90 [PR107071]
>>
>>> -Original Message-
>>> From: Richard Earnshaw (lists) 
>>> Sent: Thursday, February 15, 2024 11:01 AM
>>> To: Tamar Christina ; gcc-patches@gcc.gnu.org
>>> Cc: nd ; Marcus Shawcroft ;
>> Kyrylo
>>> Tkachov ; Richard Sandiford
>>> 
>>> Subject: Re: [PATCH]AArch64: xfail modes_1.f90 [PR107071]
>>>
>>> On 15/02/2024 10:57, Tamar Christina wrote:
>>>> Hi All,
>>>>
>>>> This test has never worked on AArch64 since the day it was committed.  It 
>>>> has
>>>> a number of issues that prevent it from working on AArch64:
>>>>
>>>> 1.  IEEE does not require that FP operations raise a SIGFPE for FP 
>>>> operations,
>>>>     only that an exception is raised somehow.
>>>>
>>>> 2. Most Arm designed cores don't raise SIGFPE and instead set a status 
>>>> register
>>>>    and some partner cores raise a SIGILL instead.
>>>>
>>>> 3. The way it checks for feenableexcept doesn't really work for AArch64.
>>>>
>>>> As such this test doesn't seem to really provide much value on AArch64 so 
>>>> we
>>>> should just xfail it.
>>>>
>>>> Regtested on aarch64-none-linux-gnu and no issues.
>>>>
>>>> Ok for master?
>>>
>>> Wouldn't it be better to just skip the test.  XFAIL just adds clutter to 
>>> verbose
>> output
>>> and suggests that someday the tools might be fixed for this case.
>>>
>>> Better still would be a new dg-requires fp_exceptions_raise_sigfpe as a 
>>> guard for
>>> the test.
>>
> 
> It looks like this is similar to 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314 so
> I'll just similarly skip it.
> 
> --- inline copy of patch ---
> 
> diff --git a/gcc/testsuite/gfortran.dg/ieee/modes_1.f90 
> b/gcc/testsuite/gfortran.dg/ieee/modes_1.f90
> index 
> 205c47f38007d06116289c19d6b23cf3bf83bd48..e29d8c678e6e51c3f2e5dac53c7703bb18a99ac4
>  100644
> --- a/gcc/testsuite/gfortran.dg/ieee/modes_1.f90
> +++ b/gcc/testsuite/gfortran.dg/ieee/modes_1.f90
> @@ -1,5 +1,5 @@
>  ! { dg-do run }
> -!
> +! { dg-skip-if "PR libfortran/78314" { aarch64*-*-gnu* arm*-*-gnueabi 
> arm*-*-gnueabihf } }
>  ! Test IEEE_MODES_TYPE, IEEE_GET_MODES and IEEE_SET_MODES
>  
> Regtested on aarch64-none-linux-gnu and no issues.
> 
> Ok for master?

OK, but please give the fortran maintainers 24hrs to comment before pushing.

R.

> 
> Thanks,
> Tamar
> 
> gcc/testsuite/ChangeLog:
> 
>   PR fortran/107071
>   * gfortran.dg/ieee/modes_1.f90: skip aarch64, arm.

Re: OT - Video editing and Post Production

[lists]

Hey Cotty,


> On 18 Feb 2024, at 23:43, Steve Cottrell  wrote:
> 
> Hi Pentaxers
> 
> I know some of you shoot video now and then, perhaps even do a little editing.
> 
> I’ve put together this *little* (ahem) film about the post-production process 
> for newbies that some might find interesting.
> 
> It’s in chapters for interrupted viewing.
> 
> https://www.youtube.com/watch?v=oUG0ZqttMNw 
> 


Nice little tutorial!


I knew most of it, but still learned some new tricks or insights

I may want to step up from my more amateurisch ‘MOVAVI’ NLE to something like 
yours :-)


Great work!


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: [tor-relays] Tor is not upgrading via apt from deb.torproject.org

[lists]

On Donnerstag, 15. Februar 2024 13:54:51 CET s7r wrote:

> I have recently found something interesting on my relays. On all relays 
> and clients actually.
> 
> As always I am using Debian and apt to get Tor from deb.torproject.org 
> tor-nightly-main-bullseye main (for example). I also have the keyring 
> installed, proper key and everything.
> 
> Currently I am on:
> 
> Tor version 0.4.9.0-alpha-dev.
Mee too.

I let nightly's upgrade automatically, but not stable.
Therefore I have the following config in
/etc/apt/50unattended-upgrades

Unattended-Upgrade::Origins-Pattern {
...
// Update TorProject's nightly dev packages: (Suite & Codename: 
tor-nightly-main-bookworm)
//   apt-cache policy | grep release
"o=TorProject,a=tor-nightly-main-bookworm,n=tor-nightly-main-bookworm";
};

> 
> If I manually check out deb.torproject.org with my browser I see there 
> is another package released in February 2024, except it notes as the 
> same version 4.9.0-alpha-dev but it has a different timestamp.
> 
> $ apt update reports no errors, looks like is working fine, but it 
> doesn't notify there's a newer version and does not apply any updates to 
> Tor. This happens only to Tor package from nightly, rest of packages 
> from debian.org deb are updated as usual.
> 
> So, anyone else experienced this?

Damn, you're right:

http://deb.torproject.org/torproject.org/dists/tor-nightly-main-bullseye/InRelease
Suite: tor-nightly-main-bullseye
Codename: tor-nightly-main-bullseye
Date: Fri, 09 Feb 2024 11:28:02 UTC
Valid-Until: Wed, 20 Mar 2024 11:28:02 UTC

root@boldsuck:~# apt update
root@boldsuck:~# apt-cache show tor
Package: tor
Version: 0.4.9.0-alpha-dev-20230909T020422Z-1~d12.bookworm+1

So I also have the last version from September 9th, 2023,
although one from February 9th, 2024 is in the archive. :-(
Tor stable update is OK.

Full log output:
https://paste.debian.net/1307420/

-- 
╰_╯ 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

Re: [PATCH][GCC][Arm] Missing optimization pattern for rev16 on architectures with thumb1

[Richard Earnshaw (lists)]

On 12/02/2024 13:48, Matthieu Longo wrote:
> This patch marks a rev16 test as XFAIL for architectures having only Thumb1 
> support. The generated code is functionally correct, but the optimization is 
> disabled when -mthumb is equivalent to Thumb1. Fixing the root issue would 
> requires changes that are not suitable for GCC14 stage 4.
> 
> More information at https://linaro.atlassian.net/browse/GNU-1141
> 
> gcc/testsuite/ChangeLog:
> 
> * gcc.target/arm/rev16_2.c: XFAIL when compiled with Thumb1.

Thanks, I've tweaked the commit message slightly and pushed this.

R.

Re: [PATCH]AArch64: xfail modes_1.f90 [PR107071]

[Richard Earnshaw (lists)]

On 15/02/2024 10:57, Tamar Christina wrote:
> Hi All,
> 
> This test has never worked on AArch64 since the day it was committed.  It has
> a number of issues that prevent it from working on AArch64:
> 
> 1.  IEEE does not require that FP operations raise a SIGFPE for FP operations,
>     only that an exception is raised somehow.
> 
> 2. Most Arm designed cores don't raise SIGFPE and instead set a status 
> register
>    and some partner cores raise a SIGILL instead.
> 
> 3. The way it checks for feenableexcept doesn't really work for AArch64.
> 
> As such this test doesn't seem to really provide much value on AArch64 so we
> should just xfail it.
> 
> Regtested on aarch64-none-linux-gnu and no issues.
> 
> Ok for master?

Wouldn't it be better to just skip the test.  XFAIL just adds clutter to 
verbose output and suggests that someday the tools might be fixed for this case.

Better still would be a new dg-requires fp_exceptions_raise_sigfpe as a guard 
for the test.

R.

> 
> Thanks,
> Tamar
> 
> gcc/testsuite/ChangeLog:
> 
>     PR fortran/107071
>     * gfortran.dg/ieee/modes_1.f90: xfail aarch64.
> 
> --- inline copy of patch --
> diff --git a/gcc/testsuite/gfortran.dg/ieee/modes_1.f90 
> b/gcc/testsuite/gfortran.dg/ieee/modes_1.f90
> index 
> 205c47f38007d06116289c19d6b23cf3bf83bd48..3667571969427ae7b2b96684ec1af8b3fdd4985f
>  100644
> --- a/gcc/testsuite/gfortran.dg/ieee/modes_1.f90
> +++ b/gcc/testsuite/gfortran.dg/ieee/modes_1.f90
> @@ -1,4 +1,4 @@
> -! { dg-do run }
> +! { dg-do run { xfail { aarch64*-*-* } } }
>  !
>  ! Test IEEE_MODES_TYPE, IEEE_GET_MODES and IEEE_SET_MODES
>  
> 
> 
> 
> 
> -- 

Re: [PATCH] Arm: Fix incorrect tailcall-generation for indirect calls [PR113780]

[Richard Earnshaw (lists)]

On 14/02/2024 09:20, Tejas Belagod wrote:
> On 2/7/24 11:41 PM, Richard Earnshaw (lists) wrote:
>> On 07/02/2024 07:59, Tejas Belagod wrote:
>>> This patch fixes a bug that causes indirect calls in PAC-enabled functions
>>> to be tailcalled incorrectly when all argument registers R0-R3 are used.
>>>
>>> Tested on arm-none-eabi for armv8.1-m.main. OK for trunk?
>>>
>>> 2024-02-07  Tejas Belagod  
>>>
>>> PR target/113780
>>> * gcc/config/arm.cc (arm_function_ok_for_sibcall): Don't allow tailcalls
>>>   for indirect calls with 4 or more arguments in pac-enabled functions.
>>>
>>> * gcc.target/arm/pac-sibcall.c: New.
>>> ---
>>>   gcc/config/arm/arm.cc  | 12 
>>>   gcc/testsuite/gcc.target/arm/pac-sibcall.c | 11 +++
>>>   2 files changed, 19 insertions(+), 4 deletions(-)
>>>   create mode 100644 gcc/testsuite/gcc.target/arm/pac-sibcall.c
>>>
>>> diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc
>>> index c44047c377a..c1f8286a4d4 100644
>>> --- a/gcc/config/arm/arm.cc
>>> +++ b/gcc/config/arm/arm.cc
>>> @@ -7980,10 +7980,14 @@ arm_function_ok_for_sibcall (tree decl, tree exp)
>>>     && DECL_WEAK (decl))
>>>   return false;
>>>   -  /* We cannot do a tailcall for an indirect call by descriptor if all 
>>> the
>>> - argument registers are used because the only register left to load the
>>> - address is IP and it will already contain the static chain.  */
>>> -  if (!decl && CALL_EXPR_BY_DESCRIPTOR (exp) && !flag_trampolines)
>>> +  /* We cannot do a tailcall for an indirect call by descriptor or for an
>>> + indirect call in a pac-enabled function if all the argument registers
>>> + are used because the only register left to load the address is IP and
>>> + it will already contain the static chain or the PAC signature in the
>>> + case of PAC-enabled functions.  */
>>
>> This comment is becoming a bit unwieldy.  I suggest restructuring it as:
>>
>> We cannot tailcall an indirect call by descriptor if all the call-clobbered
>> general registers are live (r0-r3 and ip).  This can happen when:
>>    - IP contains the static chain, or
>>    - IP is needed for validating the PAC signature.
>>
>>
>>> +  if (!decl
>>> +  && ((CALL_EXPR_BY_DESCRIPTOR (exp) && !flag_trampolines)
>>> +  || arm_current_function_pac_enabled_p()))
>>>   {
>>>     tree fntype = TREE_TYPE (TREE_TYPE (CALL_EXPR_FN (exp)));
>>>     CUMULATIVE_ARGS cum;
>>> diff --git a/gcc/testsuite/gcc.target/arm/pac-sibcall.c 
>>> b/gcc/testsuite/gcc.target/arm/pac-sibcall.c
>>> new file mode 100644
>>> index 000..c57bf7a952c
>>> --- /dev/null
>>> +++ b/gcc/testsuite/gcc.target/arm/pac-sibcall.c
>>> @@ -0,0 +1,11 @@
>>> +/* Testing return address signing.  */
>>> +/* { dg-do compile } */
>>> +/* { dg-require-effective-target mbranch_protection_ok } */
>>> +/* { dg-options " -mcpu=cortex-m85 -mbranch-protection=pac-ret+leaf -O2" } 
>>> */
>>
>> No, you can't just add options like this, you need to first check that they 
>> won't result in conflicts with other options on the command line.  See 
>> https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644077.html for an 
>> example of how to handle this.
>>
> Thanks for the review, Richard. Respin attached.
> 
> Thanks,
> Tejas.
> 
>>> +
>>> +void fail(void (*f)(int, int, int, int))
>>> +{
>>> +  f(1, 2, 3, 4);
>>> +}
>>> +
>>> +/* { dg-final { scan-assembler-not "bx\tip\t@ indirect register sibling 
>>> call" } } */
>>
>> R.
>>
+++ b/gcc/testsuite/gcc.target/arm/pac-sibcall.c
@@ -0,0 +1,14 @@
+/* If all call-clobbered general registers are live (r0-r3, ip), disable
+   indirect tail-call for a PAC-enabled function.  */
+
+/* { dg-do compile } */
+/* { dg-require-effective-target mbranch_protection_ok } */
This only checks if -mbranch-protection can work with the existing 
architecture/cpu; not with the flags you're about to add below.  You should 
check for arm_arch_v8_1m_main_pacbti_ok instead; then you can assume that 
-mbranch-protection can be added.

+/* { dg-add-options arm_arch_v8_1m_main_pacbti } */
+/* { dg-additional-options "-mbranch-protection=pac-ret+leaf -O2" } */

Otherwise this is OK if you fix the above.

R.

Re: [gentoo-user] Re: Suggestions for backup scheme?

[Wols Lists]

On 09/02/2024 12:57, J. Roeleveld wrote:

I don't understand it exactly, but what I think happens is when I create
the snapshot it allocates, let's say, 1GB. As I write to the master
copy, it fills up that 1GB with CoW blocks, and the original blocks are
handed over to the backup snapshot. And when that backup snapshot is
full of blocks that have been "overwritten" (or in reality replaced),
lvm just adds another 1GB or whatever I told it to.



That works with a single snapshot.
But, when I last used LVM like this, I would have multiple snapshots. When I
change something on the LV, the original data would be copied to the snapshot.
If I would have 2 snapshots for that LV, both would grow at the same time.

Or is that changed in recent versions?


Has what changed? As I understand it, the whole point of LVM is that 
everything is COW. So any individual block can belong to multiple snapshots.


When you write a block, the original block is not changed. A new block 
is linked in to the current snapshot to replace the original. The 
original block remains linked in to any other snapshots.


So disk usage basically grows by the number of blocks you write. Taking 
a snapshot will use just a couple of blocks, no matter how large your LV is.



So when I delete a snapshot, it just goes through those few blocks,
decrements their use count (if they've been used in multiple snapshots),
and if the use count goes to zero they're handed back to the "empty" pool.

I know this is how ZFS snapshots work. But am not convinced LVM snapshots work
the same way.


All I have to do is make sure that the sum of my snapshots does not fill
the lv (logical volume). Which in my case is a raid-5.

I assume you mean PV (Physical Volume)?


Quite possibly. VG, PV, LV. I know which one I need (by reading the 
docs), I don't particularly remember which is which off the top of my head.


I actually ditched the whole idea of raid-5 when drives got bigger than 1TB. I
currently use Raid-6 (or specifically RaidZ2, which is the ZFS "equivalent")

Well, I run my raid over dm-integrity so, allegedly, I can't suffer disk 
corruption. My only fear is a disk loss, which raid-5 will happily 
recover from. And I'm not worried about a double failure - yes it could 
happen, but ...


Given that my brother's ex-employer was quite happily running a raid-6 
with maybe petabytes of data, over a double disk failure (until an 
employee went into the data centre and said "what are those red 
lights"), I don't think my 20TB of raid-5 is much :-)


Cheers,
Wol

Re: [PATCH] testsuite, arm: Fix testcase arm/pr112337.c to check for the options first

[Richard Earnshaw (lists)]

On 30/01/2024 17:07, Saurabh Jha wrote:
> Hey,
> 
> Previously, this test was added to fix this bug: 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112337. However, it did not 
> check the compilation options before using them, leading to errors.
> 
> This patch fixes the test by first checking whether it can use the options 
> before using them.
> 
> Tested for arm-none-eabi and found no regressions. The output of check-gcc 
> with RUNTESTFLAGS="arm.exp=*" changed like this:
> 
> Before:
> # of expected passes  5963
> # of unexpected failures  64
> 
> After:
> # of expected passes  5964
> # of unexpected failures  63
> 
> Ok for master?
> 
> Regards,
> Saurabh
> 
> gcc/testsuite/ChangeLog:
> 
> * gcc.target/arm/pr112337.c: Check whether we can use the compilation 
> options before using them.

My apologies for missing this earlier.  It didn't show up in patchwork. That's 
most likely because the attachment is a binary blob instead of text/plain.  
That also means that the Linaro CI system hasn't seen this patch either.  
Please can you fix your mailer to add plain text patch files.

-/* { dg-options "-O2 -march=armv8.1-m.main+fp.dp+mve.fp -mfloat-abi=hard" } */
+/* { dg-require-effective-target arm_hard_ok } */
+/* { dg-require-effective-target arm_v8_1m_mve_ok } */
+/* { dg-options "-O2 -mfloat-abi=hard" } */
+/* { dg-add-options arm_v8_1m_mve } */

This is moving in the right direction, but it adds more than necessary now: 
checking for, and adding -mfloat-abi=hard is not necessary any more as 
arm_v8_1m_mve_ok will work out what float-abi flags are needed to make the 
options work. (What's more, it will prevent the test from running if the base 
configuration of the compiler is incompatible with the hard float ABI, which is 
more than we need.).

So please can you re-spin removing the hard-float check and removing that from 
dg-options.

Thanks,
R.

Re: [gentoo-user] Re: Suggestions for backup scheme?

[Wols Lists]

On 08/02/2024 06:38, J. Roeleveld wrote:

ZFS doesn't have this "max amount of changes", but will happily fill up the
entire pool keeping all versions available.
But it was easier to add zpool monitoring for this on ZFS then it was to add
snapshot monitoring to LVM.

I wonder, how do you deal with snapshots getting "full" on your system?


As far as I'm, concerned, snapshots are read-only once they're created. 
But there is a "grow the snapshot as required" option.


I don't understand it exactly, but what I think happens is when I create 
the snapshot it allocates, let's say, 1GB. As I write to the master 
copy, it fills up that 1GB with CoW blocks, and the original blocks are 
handed over to the backup snapshot. And when that backup snapshot is 
full of blocks that have been "overwritten" (or in reality replaced), 
lvm just adds another 1GB or whatever I told it to.


So when I delete a snapshot, it just goes through those few blocks, 
decrements their use count (if they've been used in multiple snapshots), 
and if the use count goes to zero they're handed back to the "empty" pool.


All I have to do is make sure that the sum of my snapshots does not fill 
the lv (logical volume). Which in my case is a raid-5.


Cheers,
Wol

Re: [gentoo-user] Re: Suggestions for backup scheme?

[Wols Lists]

On 08/02/2024 06:32, J. Roeleveld wrote:

Personally, I'd go the MPL2 route, but that's my choice. It might not
suit you. But to achieve what you want, you need a copyleft, GPL-style
licence.



I'll have a look at that one.


Basically, each individual source file is copyleft, but not the work as 
a whole. So if anybody copies/modifies YOUR work, they have to 
distribute your work with their binary, but this requirement does not 
extend to everyone else's work.


Maybe not included fully into the kernel, but there is nothing preventing it
to be packaged with a Linux distribution.
It's just the hostility from Linus Torvalds and Greg Kroah-Hartman against ZFS
causing the issues.

See the following post for a clear description (much better written than I
can):
https://eerielinux.wordpress.com/2019/01/28/zfs-and-gpl-terror-how-much-freedom-is-there-in-linux/

Especially the lkml thread linked from there:
https://lore.kernel.org/lkml/20190110182413.ga6...@kroah.com/


After all, there's nothing stopping*you*  from combining Linux and ZFS,
it's just that somebody else can't do that for you, and then give you
the resulting binary.



Linux (kernel) and ZFS can't be merged. Fine.


But they can.


But, Linux (the OS, as in, kernel + userspace) and ZFS can be merged legally.


Likewise here, they can.

The problem is, the BINARY can NOT be distributed. And the problem is 
the ZFS licence, not Linux.


What Linus, and the kernel devs, and that crowd *think* is irrelevant. 
What matters is what SUSE, and Red Hat, and Canonical et al think. And 
if they're not prepared to take the risk of distributing the kernel with 
ZFS built in, because they think it's a legal minefield, then that's 
THEIR decision.


That problem doesn't apply to gentoo, because it distributes the linux 
kernel and ZFS separately, and combines them ON THE USER'S MACHINE. But 
the big distros are not prepared to take the risk of combining linux and 
ZFS, and distributing the resulting *derived* *work*.


Cheers,
Wol

Re: [gentoo-user] Re: Suggestions for backup scheme?

[Wols Lists]

On 07/02/2024 11:11, J. Roeleveld wrote:

On Tuesday, February 6, 2024 9:27:35 PM CET Wols Lists wrote:

On 06/02/2024 13:12, J. Roeleveld wrote:

Clearly Oracle likes this state of affairs.  Either that, or they are
encumbered in some way from just GPLing the ZFS code.  Since they on
paper own the code for both projects it seems crazy to me that this
situation persists.


GPL is not necessarily the best license for releasing code. I've got some
private projects that I could publish. But before I do that, I'd have to
decide on a License. I would prefer something other than GPL.


Okay. What do you want to achieve. Let's just lump licences into two
categories to start with and ask the question "Who do you want to free?"


I want my code to be usable by anyone, but don't want anyone to fork it and
start making money off of it without giving me a fair share.


Okay, that instantly says you want a copyleft licence. So you're stuck 
with a GPL-style licence, and if they want to include it in a commercial 
closed source product, they need to come back to you and dual licence it.


Personally, I'd go the MPL2 route, but that's my choice. It might not 
suit you. But to achieve what you want, you need a copyleft, GPL-style 
licence.



If that sounds weird, it's because both Copyleft and Permissive claim to
be free, but have completely different target audiences. Once you've
answered that question, it'll make choosing a licence so much easier.

GPL gives freedom to the END USER. It's intended to protect the users of
your program from being held to ransom.


That's not how the kernel devs handle the GPL. They use it to remove choice
from the end user (me) to use what I want (ZFS).
And it's that which I don't like about the GPL.

No. That's Oracle's fault. The kernel devs can't include ZFS in linux, 
because Oracle (or rather Sun, at the time, I believe) deliberately 
*designed* the ZFS licence to be incompatible with the GPL.


After all, there's nothing stopping *you* from combining Linux and ZFS, 
it's just that somebody else can't do that for you, and then give you 
the resulting binary.


At the end of the day, if someone wants to be an arsehole, there's not a 
lot you can do to stop them, and with ZFS that honour apparently goes to 
Sun.


Cheers,
Wol

Re: [gentoo-user] Re: Suggestions for backup scheme?

[Wols Lists]

On 07/02/2024 11:07, J. Roeleveld wrote:

Because snapshotting uses so much less space?

So much so that, for normal usage, I probably have no need to delete any
snapshots, for YEARS?

My comment was based on using rsync to copy from the source to the backup
filesystem.


Well, that's EXACTLY what I'm doing too. NO DIFFERENCE. Actually, there 
is a minor difference - because I'm using lvm, I'm also using rsync's 
"overwrite in place" switch. In other words, it compares source and 
destination *in*place*, and if any block has changed, it overwrites the 
change, rather than creating a complete new copy.


Because lvm is COW, that means I have two copies of the file, in two 
different snapshots, but inasmuch as the files are identical, there's 
only one copy of the identical bits.



Okay, space is not an expensive commodity, and you don't want too many
snapshots, simply because digging through all those snapshots would be a
nightmare, but personally I wouldn't use a crude rsync simply because I
prefer to be frugal in my use of resources.



What is "too many"?
I currently have about 1800 snapshots on my server. Do have a tool that
ensures it doesn't get out of hand and will remove several over time.

"Too many" is whatever you define it to be. I'm likely to hang on to my 
/home snapshots for yonks. My / snapshots, on the other hand, I delete 
anything more than a couple of months old.


If I can store several years of /home snapshots without running out of 
space, why shouldn't I? The problem, if I *am* running out of space, I'm 
going to have to delete a *lot* of snapshots to make much difference...


Cheers,
Wol

[Corpora-List] 12th International Conference and Workshops on Technology and Chinese Language Teaching

[bbs lists via Corpora]

 Call for papers:
12th International Conference and Workshops on Technology and Chinese
Language Teaching (TCLT12),  June 22 to 23, 202, University of California,
Los Angeles.
Conference will be held online.

More information about the conference can be found from the conference
website.:
http://www.tclt.us/tclt12/cfp.php
___
Corpora mailing list -- corpora@list.elra.info
https://list.elra.info/mailman3/postorius/lists/corpora.list.elra.info/
To unsubscribe send an email to corpora-le...@list.elra.info

Re: [PATCH] Arm: Fix incorrect tailcall-generation for indirect calls [PR113780]

[Richard Earnshaw (lists)]

On 07/02/2024 07:59, Tejas Belagod wrote:
> This patch fixes a bug that causes indirect calls in PAC-enabled functions
> to be tailcalled incorrectly when all argument registers R0-R3 are used.
> 
> Tested on arm-none-eabi for armv8.1-m.main. OK for trunk?
> 
> 2024-02-07  Tejas Belagod  
> 
>   PR target/113780
>   * gcc/config/arm.cc (arm_function_ok_for_sibcall): Don't allow tailcalls
>   for indirect calls with 4 or more arguments in pac-enabled functions.
> 
>   * gcc.target/arm/pac-sibcall.c: New.
> ---
>  gcc/config/arm/arm.cc  | 12 
>  gcc/testsuite/gcc.target/arm/pac-sibcall.c | 11 +++
>  2 files changed, 19 insertions(+), 4 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/arm/pac-sibcall.c
> 
> diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc
> index c44047c377a..c1f8286a4d4 100644
> --- a/gcc/config/arm/arm.cc
> +++ b/gcc/config/arm/arm.cc
> @@ -7980,10 +7980,14 @@ arm_function_ok_for_sibcall (tree decl, tree exp)
>&& DECL_WEAK (decl))
>  return false;
>  
> -  /* We cannot do a tailcall for an indirect call by descriptor if all the
> - argument registers are used because the only register left to load the
> - address is IP and it will already contain the static chain.  */
> -  if (!decl && CALL_EXPR_BY_DESCRIPTOR (exp) && !flag_trampolines)
> +  /* We cannot do a tailcall for an indirect call by descriptor or for an
> + indirect call in a pac-enabled function if all the argument registers
> + are used because the only register left to load the address is IP and
> + it will already contain the static chain or the PAC signature in the
> + case of PAC-enabled functions.  */

This comment is becoming a bit unwieldy.  I suggest restructuring it as:

We cannot tailcall an indirect call by descriptor if all the call-clobbered
general registers are live (r0-r3 and ip).  This can happen when:
  - IP contains the static chain, or
  - IP is needed for validating the PAC signature.


> +  if (!decl
> +  && ((CALL_EXPR_BY_DESCRIPTOR (exp) && !flag_trampolines)
> +   || arm_current_function_pac_enabled_p()))
>  {
>tree fntype = TREE_TYPE (TREE_TYPE (CALL_EXPR_FN (exp)));
>CUMULATIVE_ARGS cum;
> diff --git a/gcc/testsuite/gcc.target/arm/pac-sibcall.c 
> b/gcc/testsuite/gcc.target/arm/pac-sibcall.c
> new file mode 100644
> index 000..c57bf7a952c
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/arm/pac-sibcall.c
> @@ -0,0 +1,11 @@
> +/* Testing return address signing.  */
> +/* { dg-do compile } */
> +/* { dg-require-effective-target mbranch_protection_ok } */
> +/* { dg-options " -mcpu=cortex-m85 -mbranch-protection=pac-ret+leaf -O2" } */

No, you can't just add options like this, you need to first check that they 
won't result in conflicts with other options on the command line.  See 
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644077.html for an 
example of how to handle this.

> +
> +void fail(void (*f)(int, int, int, int))
> +{
> +  f(1, 2, 3, 4);
> +}
> +
> +/* { dg-final { scan-assembler-not "bx\tip\t@ indirect register sibling 
> call" } } */

R.

Re: [gentoo-user] Re: Suggestions for backup scheme?

[Wols Lists]

On 06/02/2024 16:19, J. Roeleveld wrote:

Ah! Got it. That's one of the things I've been trying to figure out
this entire thread, do I need to switch home and root to ZFS to take
advantage of its snapshot support for backups? In the case you're
describing the "source" filesystem(s) can be anything. It's only the
_backup_  filesystem that needs to be ZFS (or similar).



If you want to use snapshots, the filesystem will need to support it. (either
LVM or ZFS). If you only want to create snapshots on the backupserver, I
actually don't see much benefit over using rsync.


Because snapshotting uses so much less space?

So much so that, for normal usage, I probably have no need to delete any 
snapshots, for YEARS?


Okay, space is not an expensive commodity, and you don't want too many 
snapshots, simply because digging through all those snapshots would be a 
nightmare, but personally I wouldn't use a crude rsync simply because I 
prefer to be frugal in my use of resources.


Cheers,
Wol

Re: [gentoo-user] Re: Suggestions for backup scheme?

[Wols Lists]

On 06/02/2024 15:35, Grant Edwards wrote:

If (like rsnapshot/rsync's hard-link scheme) ZFS snapshots are normal
directory trees that can be "browsed" with normal filesystem tools,
that would be ideal. [I'll do some googling...]


Bear in mind I'm talking lvm snapshots, not ZFS ...

And you can configure snapshots to grow as required.

I know it's nothing really to do with backups, but if you read the raid 
wiki page https://raid.wiki.kernel.org/index.php/System2020 - that's how 
I set up my system, with a smattering of lvm. Just look at the sections 
pvcreate, vgcreate, lvcreate, it'll tell you how to create the lvm. Then 
you just format your lvcreate'd partitions, and you can mount them, 
snapshot them, whatever them.


So you can either have one backup partition per source partition, or one 
backup partition and copy all your sources into just that one.


Your choice :-)

Cheers,
Wol

Re: [gentoo-user] Re: Suggestions for backup scheme?

[Wols Lists]

On 06/02/2024 13:12, J. Roeleveld wrote:

Clearly Oracle likes this state of affairs.  Either that, or they are
encumbered in some way from just GPLing the ZFS code.  Since they on
paper own the code for both projects it seems crazy to me that this
situation persists.



GPL is not necessarily the best license for releasing code. I've got some
private projects that I could publish. But before I do that, I'd have to
decide on a License. I would prefer something other than GPL.


Okay. What do you want to achieve. Let's just lump licences into two 
categories to start with and ask the question "Who do you want to free?"


If that sounds weird, it's because both Copyleft and Permissive claim to 
be free, but have completely different target audiences. Once you've 
answered that question, it'll make choosing a licence so much easier.


GPL gives freedom to the END USER. It's intended to protect the users of 
your program from being held to ransom.


Permissive gives freedom to the DEVELOPER. It's intended to let other 
programmers take advantage of your code and use it.


Once you've decided what sort of licence you want, it'll be easier to 
decide what licence you want.


Cheers,
Wol

Re: [gentoo-user] Re: Suggestions for backup scheme?

[Wols Lists]

On 04/02/2024 15:48, Grant Edwards wrote:

OK I see. That's a bit different than what I'm doing.  I'm backing up
a specific set of directory trees from a couple different
filesystems. There are large portions of the "source" filesystems that
I have no need to back up.  And within those directory trees that do
get backed up there are also some excluded subtrees.


But my scheme still works here. The filesystem I'm snapshotting is the 
backup. As such, it only contains the stuff I want backed up, copied 
across using rsync.


There's nothing stopping me running several rsyncs from the live system, 
from several different partitions, to the backup partition.


Cheers,
Wol

Re: [gentoo-user] Re: Suggestions for backup scheme?

[Wols Lists]

On 04/02/2024 06:24, Grant Edwards wrote:

On 2024-02-03, Wol  wrote:

On 03/02/2024 16:02, Grant Edwards wrote:

rsnapshot is an application that uses rsync to do
hourly/daily/weekly/monthly (user-configurable) backups of selected
directory trees. It's done using rsync to create snapshots. They are
in-effect "incremental" backups, because the snapshots themselves are
effectively "copy-on-write" via clever use of hard-links by rsync. A
year's worth of backups for me is 7 daily + 4 weekly + 12 monthly
snapshots for a total of 23 snapshots.  If nothing has changed during
the year, those 23 snapshots take up the same amount of space as a
single snapshot.


So as I understand it, it looks like you first do a "cp with hardlinks"
creating a complete new directory structure, but all the files are
hardlinks so you're not using THAT MUCH space for your new image?


No, the first snaphost is a complete copy of all files.  The snapshots
are on a different disk, in a different filesystem, and they're just
plain directory trees that you can brose with normal filesystem
tools. It's not possible to hard-link between the "live" filesystem
and the backup snapshots. The hard-links are to inodes "shared"
between different snapshot directory trees. The first snapshot copies
everything to the backup drive (using rsync).


Yes I get that. You create a new partition and copy all your files into it.

I create a new pv (physical volume), lv (logical volume), and copy all 
my files into it.


The next snapshot creates a second directory tree with all unchanged
files hard-linked to the files that were copied as part of the first
snapshot. Any changed files just-plain-copied into the second snapshot
directory tree.


You create a complete new directory structure, which uses at least one 
block per directory. You can't hard link directories.


I create a LVM snapshot. Dunno how much that is - a couple of blocks?

You copy all the files that have changed, leaving the old copy in the 
old tree and the new copy in the new tree - for a 10MB file that's 
changed, you use 10MB.


I use rsync's "Overwrite in place" mode, so if I change 10 bytes at the 
end of that 10MB file I use ONE block to overwrite it (unless sod 
strikes). The old block is left in the old volume, the new block is left 
in the new volume.


The third snapshot does the same thing (starting with the second
snapshot directory tree).


So you end up with multiple directory trees (which could be large in 
themselves), and multiple copies of files that have changed. Which could 
be huge files.


I end up with ONE copy of my current data, and a whole bunch of dated 
mount points, each of which is a full copy as of that date, but only 
actually uses enough space to store a diff of the volume - if I change 
that 10MB file every backup, but only change lets say 10KB over three 
4KB disk blocks, I've only used four blocks - 16KB - per backup!


Rinse and repeat.

Old snapshots trees are simply removed a-la 'rm -rf" when they're no
longer wanted.


So each snapshot is using the space required by the directory
structure, plus the space required by any changed files.


Sort of. The backup filesystem has to contain one copy of every file
so that there's something to hard-link to. The backup is completely
stand-alone, so it doesn't make sense to talk about all of the
snapshots containing only deltas. When you get to the "oldest"
snapshot, there's nothing to delta "from".


I get that - it's a different hard drive.



[...]

And that is why I like "ext over lvm copying with rsync" as my
strategy (not that I actually do it). You have lvm on your backup
disk. When you do a backup you do "rsync with overwrite in place",
which means rsync only writes blocks which have changed. You then
take an lvm snapshot which uses almost no space whatsoever.

So to compare "lvm plus overwrite in place" to "rsnapshot", my
strategy uses the space for an lvm header and a copy of all blocks
that have changed.

Your strategy takes a copy of the entire directory structure, plus a
complete copy of every file that has changed. That's a LOT more.


I don't understand, are you saying that somehow your backup doesn't
contain a copy of every file?

YES! Let's make it clear though, we're talking about EVERY VERSION of 
every backed up file.


And you need to get your head round the fact I'm not - actually - 
backing up my filesystem. I'm actually snapshoting my disk volume, my 
disk partition if you like.


Your strategy contains a copy of every file in your original backup, a 
full copy of the file structure for every snapshot, and a full copy of 
every version of every file that's been changed.


My version contains a complete copy of the current backup and (thanks to 
the magic of lvm) a block level diff of every snapshot, which appears to 
the system as a complete backup, despite taking up much less space than 
your typical incremental backup.


To change analogies completely - think git. My lvm snapshot is like 

Re: [PATCH v2] arm: Fix missing bti instruction for virtual thunks

[Richard Earnshaw (lists)]

On 26/01/2024 15:31, Richard Ball wrote:
> v2: Formatting and test options fix.
> 
> Adds missing bti instruction at the beginning of a virtual
> thunk, when bti is enabled.
> 
> gcc/ChangeLog:
> 
>   * config/arm/arm.cc (arm_output_mi_thunk): Emit
>   insn for bti_c when bti is enabled.
> 
> gcc/testsuite/ChangeLog:
> 
> * lib/target-supports.exp: Add v8_1_m_main_pacbti.
> * g++.target/arm/bti_thunk.C: New test.

OK, thanks.

R.

[pfx] migrating server to new host

[lists--- via Postfix-users]

I have postfix/dovecot/mysql with virtual domains on centos;
I would like to migrate working server setup to new host on rocky 8
installed new rocky with postfix as is available for rocky

what's the best way to do such ?

do I install ghettoforge repo on rocky, get version pf 3.8.5 then copy
main/master .cf , start it and check for errors ?


existing centos server:
# postconf mail_version
mail_version = 3.8.5


# postconf -m
btree cidr environ fail hash inline internal ldap memcache mysql nis pcre
pipemap proxy randmap regexp socketmap static tcp texthash unionmap unix

rocky:
# postconf mail_version
mail_version = 3.5.8

# postconf -m
btree cidr environ fail hash inline internal ldap memcache mysql nis pcre
pipemap proxy randmap regexp socketmap static tcp texthash unionmap unix

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

Re: kernel module sg gone

[Genes Lists]

On Thu, 2024-02-01 at 14:16 -0500, Jude DaShiell wrote:

Quick thought - did you reboot after the kernel update?
If not - the update wiped previous kernel modules away

You can make sure to keep sg loaded by creating a file:

    /etc/modules-load.d/loadme.conf

And add these :
loop
sg

Loop is handy if you want to be able to mount usb drives after kernel
update before rebooting.

-- 
Gene

Re: kernel module sg gone

[Genes Lists]

On Thu, 2024-02-01 at 14:16 -0500, Jude DaShiell wrote:
> ...
> sg first.  That's gone with latest update of kernel and modules and
> ...

The module is in arch kernels :

 $ ls /usr/lib/modules/6.7.3-arch1-1/kernel/drivers/scsi/sg.ko.zst 
24 /usr/lib/modules/6.7.3-arch1-1/kernel/drivers/scsi/sg.ko.zst

What does this command return for you on the problem machine:

   modinfo sg


Gene

Re: [tor-relays] Relay in AT marked as DE in metrics

[lists]

On Mittwoch, 31. Januar 2024 19:50:13 CET Carlo P. via tor-relays wrote:

> I have a relay on 152.53.17.183 / 2a0a:4cc0:1:1333::beef which is listed as
> "German" in metrics.torproject.org, but actually it is in Austria 

Was just a topic here recently:
https://lists.torproject.org/pipermail/tor-relays/2024-January/021472.html

Ask geofeed from the provider and submit a bug report.

-- 
╰_╯ 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

Re: [PATCH 1/3] vect: Pass stmt_vec_info to TARGET_SIMD_CLONE_USABLE

[Andre Vieira (lists)]

On 01/02/2024 07:19, Richard Biener wrote:

On Wed, 31 Jan 2024, Andre Vieira (lists) wrote:


The patch didn't come with a testcase so it's really hard to tell
what goes wrong now and how it is fixed ...


My bad! I had a testcase locally but never added it...

However... now I look at it and ran it past Richard S, the codegen isn't 
'wrong', but it does have the potential to lead to some pretty slow 
codegen, especially for inbranch simdclones where it transforms the SVE 
predicate into an Advanced SIMD vector by inserting the elements one at 
a time...


An example of which can be seen if you do:

gcc -O3 -march=armv8-a+sve -msve-vector-bits=128  -fopenmp-simd t.c -S

with the following t.c:
#pragma omp declare simd simdlen(4) inbranch
int __attribute__ ((const)) fn5(int);

void fn4 (int *a, int *b, int n)
{
for (int i = 0; i < n; ++i)
b[i] = fn5(a[i]);
}

Now I do have to say, for our main usecase of libmvec we won't have any 
'inbranch' Advanced SIMD clones, so we avoid that issue... But of course 
that doesn't mean user-code will.


I'm gonna remove this patch and run another test regression to see if it 
catches anything weird, but if not then I guess we do have the option to 
not use this patch and aim to solve the costing or codegen issue in 
GCC-15. We don't currently do any simdclone costing and I don't have a 
clear suggestion for how given openmp has no mechanism that I know off 
to expose the speedup of a simdclone over it's scalar variant, so how 
would we 'compare' a simdclone call with extra overhead of argument 
preparation vs scalar, though at least we could prefer a call to a 
different simdclone with less argument preparation. Anyways I digress.


Other tests, these require aarch64-autovec-preference=2 so that also has 
me worried less...


gcc -O3 -march=armv8-a+sve -msve-vector-bits=128 --param 
aarch64-autovec-preference=2 -fopenmp-simd t.c -S


t.c:
#pragma omp declare simd simdlen(2) notinbranch
float __attribute__ ((const)) fn1(double);

void fn0 (float *a, float *b, int n)
{
for (int i = 0; i < n; ++i)
b[i] = fn1((double) a[i]);
}

#pragma omp declare simd simdlen(2) notinbranch
float __attribute__ ((const)) fn3(float);

void fn2 (float *a, double *b, int n)
{
for (int i = 0; i < n; ++i)
b[i] = (double) fn3(a[i]);
}


Richard.



That said, I wonder how we end up mixing things up in the first place.

Richard.

Re: [gentoo-user] Re: Suggestions for backup scheme?

[Wols Lists]

On 31/01/2024 17:56, Rich Freeman wrote:

I don't think there are
any RAID implementations that do full write journaling to protect
against the write hole problem, but those would obviously underperform
zfs as well.


This feature has been added to mdraid, iirc.

Cheers,
Wol

Re: [PATCH 1/3] vect: Pass stmt_vec_info to TARGET_SIMD_CLONE_USABLE

[Andre Vieira (lists)]

On 31/01/2024 14:35, Richard Biener wrote:

On Wed, 31 Jan 2024, Andre Vieira (lists) wrote:




On 31/01/2024 13:58, Richard Biener wrote:

On Wed, 31 Jan 2024, Andre Vieira (lists) wrote:




On 31/01/2024 12:13, Richard Biener wrote:

On Wed, 31 Jan 2024, Richard Biener wrote:


On Tue, 30 Jan 2024, Andre Vieira wrote:



This patch adds stmt_vec_info to TARGET_SIMD_CLONE_USABLE to make sure
the
target can reject a simd_clone based on the vector mode it is using.
This is needed because for VLS SVE vectorization the vectorizer accepts
Advanced SIMD simd clones when vectorizing using SVE types because the
simdlens
might match.  This will cause type errors later on.

Other targets do not currently need to use this argument.


Can you instead pass down the mode?


Thinking about that again the cgraph_simd_clone info in the clone
should have sufficient information to disambiguate.  If it doesn't
then we should amend it.

Richard.


Hi Richard,

Thanks for the review, I don't think cgraph_simd_clone_info is the right
place
to pass down this information, since this is information about the caller
rather than the simdclone itself. What we are trying to achieve here is
making
the vectorizer being able to accept or reject simdclones based on the ISA
we
are vectorizing for. To distinguish between SVE and Advanced SIMD ISAs we
use
modes, I am also not sure that's ideal but it is what we currently use. So
to
answer your earlier question, yes I can also pass down mode if that's
preferable.


Note cgraph_simd_clone_info has simdlen and we seem to check elsewhere
whether that's POLY or constant.  I wonder how aarch64_sve_mode_p
comes into play here which in the end classifies VLS SVE modes as
non-SVE?



Using -msve-vector-bits=128
(gdb) p TYPE_MODE (STMT_VINFO_VECTYPE (stmt_vinfo))
$4 = E_VNx4SImode
(gdb) p  TYPE_SIZE (STMT_VINFO_VECTYPE (stmt_vinfo))
$5 = (tree) 0xf741c1b0
(gdb) p debug (TYPE_SIZE (STMT_VINFO_VECTYPE (stmt_vinfo)))
128
(gdb) p aarch64_sve_mode_p (TYPE_MODE (STMT_VINFO_VECTYPE (stmt_vinfo)))
$5 = true

and for reference without vls codegen:
(gdb) p TYPE_MODE (STMT_VINFO_VECTYPE (stmt_vinfo))
$1 = E_VNx4SImode
(gdb) p  debug (TYPE_SIZE (STMT_VINFO_VECTYPE (stmt_vinfo)))
POLY_INT_CST [128, 128]

Having said that I believe that the USABLE targethook implementation for
aarch64 should also block other uses, like an Advanced SIMD mode being used as
input for a SVE VLS SIMDCLONE. The reason being that for instance 'half'
registers like VNx2SI are packed differently from V2SI.

We could teach the vectorizer to support these of course, but that requires
more work and is not extremely useful just yet. I'll add the extra check that
to the patch once we agree on how to pass down the information we need. Happy
to use either mode, or stmt_vec_info and extract the mode from it like it does
now.


As said, please pass down 'mode'.  But I wonder how to document it,
which mode is that supposed to be?  Any of result or any argument
mode that happens to be a vector?  I think that we might be able
to mix Advanced SIMD modes and SVE modes with -msve-vector-bits=128
in the same loop?

Are the simd clones you don't want to use with -msve-vector-bits=128
having constant simdlen?  If so why do you generate them in the first
place?


So this is where things get a bit confusing and I will write up some 
text for these cases to put in our ABI document (currently in Beta and 
in need of some tlc).


Our intended behaviour is for a 'declare simd' without a simdlen to 
generate simdclones for:
* Advanced SIMD 128 and 64-bit vectors, where possible (we don't allow 
for simdlen 1, Tamar fixed that in gcc recently),

* SVE VLA vectors.

Let me illustrate this with an example:

__attribute__ ((simd (notinbranch), const)) float cosf(float);

Should tell the compiler the following simd clones are available:
__ZGVnN4v_cosf 128-bit 4x4 float Advanced SIMD clone
__ZGVnN2v_cosf 64-bit  4x2 float Advanced SIMD clone
__ZGVsMxv_cosf [128, 128]-bit 4x4xN SVE SIMD clone

[To save you looking into the abi let me break this down, _ZGV is 
prefix, then 'n' or 's' picks between Advanced SIMD and SVE, 'N' or 'M' 
picks between Not Masked and Masked (SVE is always masked even if we ask 
for notinbranch), then a digit or 'x' picks between Vector Length or 
VLA, and after that you get a letter per argument, where v = vector mapped]


Regardless of -msve-vector-bits, however, the vectorizer (and any other 
part of the compiler) may assume that the VL of the VLA SVE clone is 
that specified by -msve-vector-bits, which if the clone is written in a 
VLA way will still work.


If the attribute is used with a function definition rather than 
declaration, so:


__attribute__ ((simd (notinbranch), const)) float fn0(float a)
{
  return a + 1.0f;
}

the compiler should again generate the three simd clones:
__ZGVnN4v_fn0 128-bit 4x4 float Advanced SIMD clone
__ZGVnN2v_fn0 64-bit  4x2 float Advanced SIMD clone
__ZGVsMxv_fn0 [128, 128]-bit 4x4xN SVE SIMD

Re: [PATCH 1/3] vect: Pass stmt_vec_info to TARGET_SIMD_CLONE_USABLE

[Andre Vieira (lists)]

On 31/01/2024 14:03, Richard Biener wrote:

On Wed, 31 Jan 2024, Richard Biener wrote:


On Wed, 31 Jan 2024, Andre Vieira (lists) wrote:




On 31/01/2024 12:13, Richard Biener wrote:

On Wed, 31 Jan 2024, Richard Biener wrote:


On Tue, 30 Jan 2024, Andre Vieira wrote:



This patch adds stmt_vec_info to TARGET_SIMD_CLONE_USABLE to make sure the
target can reject a simd_clone based on the vector mode it is using.
This is needed because for VLS SVE vectorization the vectorizer accepts
Advanced SIMD simd clones when vectorizing using SVE types because the
simdlens
might match.  This will cause type errors later on.

Other targets do not currently need to use this argument.


Can you instead pass down the mode?


Thinking about that again the cgraph_simd_clone info in the clone
should have sufficient information to disambiguate.  If it doesn't
then we should amend it.

Richard.


Hi Richard,

Thanks for the review, I don't think cgraph_simd_clone_info is the right place
to pass down this information, since this is information about the caller
rather than the simdclone itself. What we are trying to achieve here is making
the vectorizer being able to accept or reject simdclones based on the ISA we
are vectorizing for. To distinguish between SVE and Advanced SIMD ISAs we use
modes, I am also not sure that's ideal but it is what we currently use. So to
answer your earlier question, yes I can also pass down mode if that's
preferable.


Note cgraph_simd_clone_info has simdlen and we seem to check elsewhere
whether that's POLY or constant.  I wonder how aarch64_sve_mode_p
comes into play here which in the end classifies VLS SVE modes as
non-SVE?


Maybe it's just a bit non-obvious as you key on mangling:

  static int
-aarch64_simd_clone_usable (struct cgraph_node *node)
+aarch64_simd_clone_usable (struct cgraph_node *node, stmt_vec_info
stmt_vinfo)
  {
switch (node->simdclone->vecsize_mangle)
  {
  case 'n':
if (!TARGET_SIMD)
 return -1;
+  if (STMT_VINFO_VECTYPE (stmt_vinfo)
+ && aarch64_sve_mode_p (TYPE_MODE (STMT_VINFO_VECTYPE
(stmt_vinfo
+   return -1;

?  What does 'n' mean?  It's documented as

   /* The mangling character for a given vector size.  This is used
  to determine the ISA mangling bit as specified in the Intel
  Vector ABI.  */
   unsigned char vecsize_mangle;


I'll update the comment, but yeh 'n' is for Advanced SIMD, 's' is for SVE.


which is slightly misleading.

Re: [PATCH 1/3] vect: Pass stmt_vec_info to TARGET_SIMD_CLONE_USABLE

[Andre Vieira (lists)]

On 31/01/2024 13:58, Richard Biener wrote:

On Wed, 31 Jan 2024, Andre Vieira (lists) wrote:




On 31/01/2024 12:13, Richard Biener wrote:

On Wed, 31 Jan 2024, Richard Biener wrote:


On Tue, 30 Jan 2024, Andre Vieira wrote:



This patch adds stmt_vec_info to TARGET_SIMD_CLONE_USABLE to make sure the
target can reject a simd_clone based on the vector mode it is using.
This is needed because for VLS SVE vectorization the vectorizer accepts
Advanced SIMD simd clones when vectorizing using SVE types because the
simdlens
might match.  This will cause type errors later on.

Other targets do not currently need to use this argument.


Can you instead pass down the mode?


Thinking about that again the cgraph_simd_clone info in the clone
should have sufficient information to disambiguate.  If it doesn't
then we should amend it.

Richard.


Hi Richard,

Thanks for the review, I don't think cgraph_simd_clone_info is the right place
to pass down this information, since this is information about the caller
rather than the simdclone itself. What we are trying to achieve here is making
the vectorizer being able to accept or reject simdclones based on the ISA we
are vectorizing for. To distinguish between SVE and Advanced SIMD ISAs we use
modes, I am also not sure that's ideal but it is what we currently use. So to
answer your earlier question, yes I can also pass down mode if that's
preferable.


Note cgraph_simd_clone_info has simdlen and we seem to check elsewhere
whether that's POLY or constant.  I wonder how aarch64_sve_mode_p
comes into play here which in the end classifies VLS SVE modes as
non-SVE?



Using -msve-vector-bits=128
(gdb) p TYPE_MODE (STMT_VINFO_VECTYPE (stmt_vinfo))
$4 = E_VNx4SImode
(gdb) p  TYPE_SIZE (STMT_VINFO_VECTYPE (stmt_vinfo))
$5 = (tree) 0xf741c1b0
(gdb) p debug (TYPE_SIZE (STMT_VINFO_VECTYPE (stmt_vinfo)))
128
(gdb) p aarch64_sve_mode_p (TYPE_MODE (STMT_VINFO_VECTYPE (stmt_vinfo)))
$5 = true

and for reference without vls codegen:
(gdb) p TYPE_MODE (STMT_VINFO_VECTYPE (stmt_vinfo))
$1 = E_VNx4SImode
(gdb) p  debug (TYPE_SIZE (STMT_VINFO_VECTYPE (stmt_vinfo)))
POLY_INT_CST [128, 128]

Having said that I believe that the USABLE targethook implementation for 
aarch64 should also block other uses, like an Advanced SIMD mode being 
used as input for a SVE VLS SIMDCLONE. The reason being that for 
instance 'half' registers like VNx2SI are packed differently from V2SI.


We could teach the vectorizer to support these of course, but that 
requires more work and is not extremely useful just yet. I'll add the 
extra check that to the patch once we agree on how to pass down the 
information we need. Happy to use either mode, or stmt_vec_info and 
extract the mode from it like it does now.



Regards,
Andre

Re: [PATCH 1/3] vect: Pass stmt_vec_info to TARGET_SIMD_CLONE_USABLE

[Andre Vieira (lists)]

On 31/01/2024 12:13, Richard Biener wrote:

On Wed, 31 Jan 2024, Richard Biener wrote:


On Tue, 30 Jan 2024, Andre Vieira wrote:



This patch adds stmt_vec_info to TARGET_SIMD_CLONE_USABLE to make sure the
target can reject a simd_clone based on the vector mode it is using.
This is needed because for VLS SVE vectorization the vectorizer accepts
Advanced SIMD simd clones when vectorizing using SVE types because the simdlens
might match.  This will cause type errors later on.

Other targets do not currently need to use this argument.


Can you instead pass down the mode?


Thinking about that again the cgraph_simd_clone info in the clone
should have sufficient information to disambiguate.  If it doesn't
then we should amend it.

Richard.


Hi Richard,

Thanks for the review, I don't think cgraph_simd_clone_info is the right 
place to pass down this information, since this is information about the 
caller rather than the simdclone itself. What we are trying to achieve 
here is making the vectorizer being able to accept or reject simdclones 
based on the ISA we are vectorizing for. To distinguish between SVE and 
Advanced SIMD ISAs we use modes, I am also not sure that's ideal but it 
is what we currently use. So to answer your earlier question, yes I can 
also pass down mode if that's preferable.


Regards,
Andre

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

[Richard Earnshaw (lists)]

On 30/01/2024 14:09, Andre Simoes Dias Vieira wrote:
> Hi Richard,
> 
> Thanks for the reviews, I'm making these changes but just a heads up.
> 
> When hardcoding LR_REGNUM like this we need to change the way we compare the 
> register in doloop_condition_get. This function currently compares the rtx 
> nodes by address, which I think happens to be fine before we assign hard 
> registers, as I suspect we always share the rtx node for the same pseudo, but 
> when assigning registers it seems like we create copies, so things like:
> `XEXP (inc_src, 0) == reg` will fail for
> inc_src: (plus (reg LR) (const_int -n)'
> reg: (reg LR)
> 
> Instead I will substitute the operand '==' with calls to 'rtx_equal_p (op1, 
> op2, NULL)'.

Yes, that's fine.

R.

> 
> Sound good?
> 
> Kind regards,
> Andre
> 
> ____
> From: Richard Earnshaw (lists) 
> Sent: Tuesday, January 30, 2024 11:36 AM
> To: Andre Simoes Dias Vieira; gcc-patches@gcc.gnu.org
> Cc: Kyrylo Tkachov; Stam Markianos-Wright
> Subject: Re: [PATCH v3 2/2] arm: Add support for MVE Tail-Predicated Low 
> Overhead Loops
> 
> On 19/01/2024 14:40, Andre Vieira wrote:
>>
>> Respin after comments from Kyrill and rebase. I also removed an if-then-else
>> construct in arm_mve_check_reg_origin_is_num_elems similar to the other 
>> functions
>> Kyrill pointed out.
>>
>> After an earlier comment from Richard Sandiford I also added comments to the
>> two tail predication patterns added to explain the need for the unspecs.
> 
> [missing ChangeLog]
> 
> I'm just going to focus on loop-doloop.c in this reply, I'll respond to the 
> other bits in a follow-up.
> 
>   2)  (set (reg) (plus (reg) (const_int -1))
> - (set (pc) (if_then_else (reg != 0)
> -(label_ref (label))
> -(pc))).
> +(set (pc) (if_then_else (reg != 0)
> +(label_ref (label))
> +(pc))).
> 
>   Some targets (ARM) do the comparison before the branch, as in the
>   following form:
> 
> - 3) (parallel [(set (cc) (compare ((plus (reg) (const_int -1), 0)))
> -   (set (reg) (plus (reg) (const_int -1)))])
> -(set (pc) (if_then_else (cc == NE)
> ...
> 
> 
> This comment is becoming confusing.  Really the text leading up to 3)... 
> should be inside 3.  Something like:
> 
>   3) Some targets (ARM) do the comparison before the branch, as in the
>   following form:
> 
>   (parallel [(set (cc) (compare (plus (reg) (const_int -1)) 0))
>  (set (reg) (plus (reg) (const_int -1)))])
>   (set (pc) (if_then_else (cc == NE)
>   (label_ref (label))
>   (pc)))])
> 
> 
> The same issue on the comment structure also applies to the new point 4...
> 
> +  The ARM target also supports a special case of a counter that 
> decrements
> +  by `n` and terminating in a GTU condition.  In that case, the compare 
> and
> +  branch are all part of one insn, containing an UNSPEC:
> +
> +  4) (parallel [
> +   (set (pc)
> +   (if_then_else (gtu (unspec:SI [(plus:SI (reg:SI 14 lr)
> +   (const_int -n))])
> +  (const_int n-1]))
> +   (label_ref)
> +   (pc)))
> +   (set (reg:SI 14 lr)
> +(plus:SI (reg:SI 14 lr)
> + (const_int -n)))
> + */
> 
> I think this needs a bit more clarification.  Specifically that this 
> construct supports a predicated vectorized do loop.  Also, the placement of 
> the unspec inside the comparison is ugnly and unnecessary.  It should be 
> sufficient to have the unspec inside a USE expression, which the mid-end can 
> then ignore entirely.  So
> 
> (parallel
>  [(set (pc) (if_then_else (gtu (plus (reg) (const_int -n))
>(const_int n-1))
>   (label_ref) (pc)))
>   (set (reg) (plus (reg) (const_int -n)))
>   (additional clobbers and uses)])
> 
> For Arm, we then add a (use (unspec [(const_int 0)] N)) that is specific to 
> this pattern to stop anything else from matching it.
> 
> Note that we don't need to mention that the register is 'LR' or the modes, 
> those are specific to a particular backend, not the generic pattern we want 
> to match.
> 
> +  || !CONST_INT_P (XEXP (inc_src, 1))
> +  || INTVAL (XEXP (inc_src, 1)) >= 0)
>  re

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

[Richard Earnshaw (lists)]

On 19/01/2024 14:40, Andre Vieira wrote:
> 
> Respin after comments from Kyrill and rebase. I also removed an if-then-else
> construct in arm_mve_check_reg_origin_is_num_elems similar to the other 
> functions
> Kyrill pointed out.
> 
> After an earlier comment from Richard Sandiford I also added comments to the
> two tail predication patterns added to explain the need for the unspecs.

[missing ChangeLog]

I'm just going to focus on loop-doloop.c in this reply, I'll respond to the 
other bits in a follow-up.

  2)  (set (reg) (plus (reg) (const_int -1))
- (set (pc) (if_then_else (reg != 0)
-(label_ref (label))
-(pc))).  
+(set (pc) (if_then_else (reg != 0)
+(label_ref (label))
+(pc))).
 
  Some targets (ARM) do the comparison before the branch, as in the
  following form:
 
- 3) (parallel [(set (cc) (compare ((plus (reg) (const_int -1), 0)))
-   (set (reg) (plus (reg) (const_int -1)))])
-(set (pc) (if_then_else (cc == NE)
...


This comment is becoming confusing.  Really the text leading up to 3)... should 
be inside 3.  Something like:

  3) Some targets (ARM) do the comparison before the branch, as in the
  following form:
 
  (parallel [(set (cc) (compare (plus (reg) (const_int -1)) 0))
 (set (reg) (plus (reg) (const_int -1)))])
  (set (pc) (if_then_else (cc == NE)
  (label_ref (label))
  (pc)))])


The same issue on the comment structure also applies to the new point 4...

+  The ARM target also supports a special case of a counter that decrements
+  by `n` and terminating in a GTU condition.  In that case, the compare and
+  branch are all part of one insn, containing an UNSPEC:
+
+  4) (parallel [
+   (set (pc)
+   (if_then_else (gtu (unspec:SI [(plus:SI (reg:SI 14 lr)
+   (const_int -n))])
+  (const_int n-1]))
+   (label_ref)
+   (pc)))
+   (set (reg:SI 14 lr)
+(plus:SI (reg:SI 14 lr)
+ (const_int -n)))
+ */

I think this needs a bit more clarification.  Specifically that this construct 
supports a predicated vectorized do loop.  Also, the placement of the unspec 
inside the comparison is ugnly and unnecessary.  It should be sufficient to 
have the unspec inside a USE expression, which the mid-end can then ignore 
entirely.  So

(parallel
 [(set (pc) (if_then_else (gtu (plus (reg) (const_int -n))
   (const_int n-1))
  (label_ref) (pc)))
  (set (reg) (plus (reg) (const_int -n)))
  (additional clobbers and uses)])

For Arm, we then add a (use (unspec [(const_int 0)] N)) that is specific to 
this pattern to stop anything else from matching it.

Note that we don't need to mention that the register is 'LR' or the modes, 
those are specific to a particular backend, not the generic pattern we want to 
match.

+  || !CONST_INT_P (XEXP (inc_src, 1))
+  || INTVAL (XEXP (inc_src, 1)) >= 0)
 return 0;
+  int dec_num = abs (INTVAL (XEXP (inc_src, 1)));

We can just use '-INTVAL(...)' here, we've verified just above that the 
constant is negative.

-  if ((XEXP (condition, 0) == reg)
+  /* For the ARM special case of having a GTU: re-form the condition without
+ the unspec for the benefit of the middle-end.  */
+  if (GET_CODE (condition) == GTU)
+{
+  condition = gen_rtx_fmt_ee (GTU, VOIDmode, inc_src,
+ GEN_INT (dec_num - 1));
+  return condition;
+}

If you make the change I mentioned above, this re-forming isn't needed any 
more, so the arm-specific comment goes away
 
-   {
+{
  if (GET_CODE (pattern) != PARALLEL)
  /*  For the second form we expect:

You've fixed the indentation of the brace (good), but the body of the braced 
expression needs re-indenting as well.

R.

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

[Richard Earnshaw (lists)]

On 19/01/2024 14:40, Andre Vieira wrote:
> 
> Reposting for testing purposes, no changes from v2 (other than rebase).

We seem to have lost the ChangeLog for this hunk :(

The code itself looks OK, though.

Re: [gentoo-user] The hopeless futility of printing.

[Wols Lists]

On 29/01/2024 18:19, Alan Grimes wrote:

k...@aspodata.se wrote:

>> Absolutely suprimo HP laser jet network printer.
You didn't write what model, hard to help you then.


It's a LaserJet Pro M453-4.


I have absolutely no trouble with HP. But I always used hplip. I notice 
though it's not installed on my current server/workstation ??? That 
prints fine.


My printer's an M477 - with scanner and everything - but that's 
configured as "scan to network" so it just opens a samba share and dumps 
the scan there.


Under "make and model", cups says "HP Color LaserJet Series PCL 6 CUPS".

Cheers,
Wol

[oe] [meta-oe][PATCH v5] 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: [yocto] How to build two images with different settings of a recipe in Yocto

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

Thanks for your reply. It helps, but I see some issues with the 
ROOTFS_POSTPROCESS_COMMAND.

For the config file this is a possible solution. But what can I do if I need 
code changes? SSH announced they'll disable DSA support by default in a few 
months and for all other images except one I would stay with this default. I 
have to supply another setting to configure when building the recipe for one 
image. And I have more images they require reduced (or widened) settings of 
packages.

And editing the image has the drawback that it doesn't play well with package 
management. If I install/update the sshd ipk, it doesn't contain the change 
from ROOTFS_POSTPROCESS_COMMAND.

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

[yocto] How to build two images with different settings of a recipe in Yocto

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

[I posted this question on Stackoverflow: 
https://stackoverflow.com/q/77871008/8452187]

I have two images with the same distro and the same machine and each image 
should contain the same package, but build with different settings.

For example, the config file sshd_config is part of the opensshd package, but I 
need a different set of HostKeyAlgorithms depending on the image. (Yes, I could 
use Include, but that's not the point of this question.)

How can I build two different flavours of the same package? One way would be to 
have a different distro for each image, but this wouldn't scale. My other idea 
is to use local.conf to change the build behaviour of the recipe and control 
the image content (and the difference between both) with different local.conf. 
(BTW: I'm using KAS ( https://ghcr.io/siemens/kas ) which makes local.conf 
generation easy.) But what's best practice?

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

Re: libjxl upgrade issue

[Genes Lists]

On Thu, 2024-01-25 at 21:27 +0100, Brian Allred wrote:
...
> the same issue with libvpx after today's update. Discord, Telegram,
and xfreerdp all complain about missing the shared library
"libvpx.so.8".
> 
>

May or may not be the issue, but best I can tell libvpx package is not
a dependency of discord :

pactree -s discord | grep libvpx

returns nothing - which may explain why it is not being rebuilt after
updated libvpx. 

Does

   ldd /usr/bin/discord | grep libvpx

show anything useful?

    
-- 
Gene

Re: [PATCH] Make gcc.target/arm/bics_3.c testcase a bit more generic [PR113542]

[Richard Earnshaw (lists)]

On 25/01/2024 10:29, Maxim Kuvyrkov wrote:
> After fwprop improvement in r14-8319-g86de9b66480, codegen in
> bics_3.c test changed from "bics" to "bic" instruction, with
> the overall instruction stream remaining at the same quality.
> 
> This patch makes the scan-assembler directive accept both
> "bics" and "bic".
> 
> BEFORE r14-8319-g86de9b66480:
>   bicsr0, r0, r1 @ 9  [c=4 l=4]  *andsi_notsi_si_compare0_scratch
>   mov r0, #1  @ 23[c=4 l=4]  *thumb2_movsi_vfp/1
>   it  eq
>   moveq   r0, #0  @ 26[c=8 l=4]  *p *thumb2_movsi_vfp/2
>   bx  lr  @ 29[c=8 l=4]  *thumb2_return
> 
> AFTER r14-8319-g86de9b66480:
>   bic r0, r0, r1  @ 8 [c=4 l=4]  andsi_notsi_si
>   subsr0, r0, #0  @ 22[c=4 l=4]  cmpsi2_addneg/0
>   it  ne
>   movne   r0, #1  @ 23[c=8 l=4]  *p *thumb2_movsi_vfp/2
>   bx  lr  @ 26[c=8 l=4]  *thumb2_return
> 
> gcc/testsuite/ChangeLog:
> 
>   PR target/113542
>   * gcc.target/arm/bics_3.c: Update scan-assembler directive.
> ---
>  gcc/testsuite/gcc.target/arm/bics_3.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/gcc/testsuite/gcc.target/arm/bics_3.c 
> b/gcc/testsuite/gcc.target/arm/bics_3.c
> index e056b264e15..c5bed3c92d2 100644
> --- a/gcc/testsuite/gcc.target/arm/bics_3.c
> +++ b/gcc/testsuite/gcc.target/arm/bics_3.c
> @@ -35,6 +35,6 @@ main (void)
>return 0;
>  }
>  
> -/* { dg-final { scan-assembler-times "bics\tr\[0-9\]+, r\[0-9\]+, r\[0-9\]+" 
> 2 } } */
> -/* { dg-final { scan-assembler-times "bics\tr\[0-9\]+, r\[0-9\]+, r\[0-9\]+, 
> .sl #2" 1 } } */
> +/* { dg-final { scan-assembler-times "bics?\tr\[0-9\]+, r\[0-9\]+, 
> r\[0-9\]+" 2 } } */
> +/* { dg-final { scan-assembler-times "bics?\tr\[0-9\]+, r\[0-9\]+, 
> r\[0-9\]+, .sl #2" 1 } } */
>  


The test was added (r6-823-g0454e698401a3e) specifically to check that a BICS 
instruction was being generated.  Whether or not that is right is somewhat 
debatable, but this change seems to be papering over a different issue.

Either we should generate BICS, making this change incorrect, or we should 
disable the test for thumb code on the basis that this isn't really a win.

But really, we should fix the compiler to do better here.  We really want 
something like

BICS  r0, r0, r1  // r0 is 0 or non-zero
MOVNE r0, #1  // convert all non-zero to 1

in Arm state (ie using the BICS instruction to set the result to zero); and in 
thumb2, perhaps something like:

BICS  r0, r0, r1
ITne
MOVNE r0, #1

or maybe even better:

BIC  r0, r0, r1
SUBS r1, r0, #1
SBC  r0, r0, r1

which is slightly better than BICS because SUBS breaks a condition-code chain 
(all the flag bits are set).

There are similar quality issues for other NE(arith-op, 0) cases; we just don't 
have tests for those.

R.

Re: [OE-Core][PATCH 1/2] testimage: move TESTIMAGE_FAILED_QA_ARTIFACTS default value to core-image-minimal

[Alexis Lothoré via lists . openembedded . org]

On 1/24/24 17:20, Richard Purdie wrote:
> On Wed, 2024-01-24 at 15:29 +0100, Alexis Lothoré via
> lists.openembedded.org wrote:
>> From: Alexis Lothoré 

[...]

>> +
>> +# When any test fails, TESTIMAGE_FAILED_QA ARTIFACTS will be parsed and for
>> +# each entry in it, if artifact pointed by path description exists on 
>> target,
>> +# it will be retrieved onto host
>> +TESTIMAGE_FAILED_QA_ARTIFACTS ?= "\
>> +${localstatedir}/log \
>> +${sysconfdir}/version \
>> +${sysconfdir}/os-release"
>> \ No newline at end of file
> 
> I'm a little puzzled by this. Doesn't this mean it won't work for any
> image that isn't based upon minimal (which is most of them)?

Arg, I may have made wrong assumptions there. I focused on ptest images (ptest
fast and ptest all), observed that at some point they inherited from minimal,
and assumed it would be the case for any image used for runtime tests.

Checking autobuilder config.json, I see indeed that a lot of runtime tests are
for example done on core-image-sato, which does not depend on
core-image-minimal.So indeed this default value needs to move elsewhere, maybe
remain in testimage (but I will have to find a fix for issues mentioned in the
commit). I'll check how to properly fix this.

Thanks,

Alexis

> 
> Cheers,
> 
> Richard
> 

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


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

Re: [Postfix] Warn that databases need regeneration

[Genes Lists]

On Wed, 2024-01-24 at 17:03 +0100, Geert Hendrickx wrote:
> ...
> This has been reverted in postfix 3.8.5-2, so you may need to postmap
> your .db files again.  (users not on [testing] won't have this issue)

Geert - this should be okay as the revert takes db5 back to db6 (again)
- the earlier problem was likely stemming from 6 going down to 5.

> 
> FYI: it's being considered to move away from Berkeley DB entirely,
> see:
> https://gitlab.archlinux.org/archlinux/packaging/packages/postfix/-
> /issues/3
> So you may already want to look into cdb: or lmdb: alternatives.
> 
> 
This is a good suggestion.  I have changed all my lookup table maps to
no longer use 'hash:'


-- 
Gene

[OE-Core][PATCH 0/2] testimage: enable artifacts retrieval for failed tests

[Alexis Lothoré via lists . openembedded . org]

Hello,
this small series is a very late follow-up to my initial artifacts
retrieval series (sorry for the delay).
The initial series can be found in [1]. The goal is to retrieve some
specific files from target whenever some tests fail, to ease debugging. The
feature relies on a new TESTIMAGE_FAILED_QA_ARTIFACTS variable listing some
files, and the testimage class using this variable after failed tests to
save corresponding files in tmp/log/oeqa/artifacts.

Most of the initial series has been merged, except the part enriching
TESTIMAGE_FAILED_QA_ARTIFACTS with ptest files path from target to save
files specific to ptests ([2]), so the feature is currently not usable to
debug ptests. There was some discussions around how to properly set default
value and then enrich this variable. After wrapping my head around all the
ways to affect this variable (and mostly, struggling with recipes parsing
order), I came up with this new version, which:
- sets default TESTIMAGE_FAILED_QA_ARTIFACTS in core-image-minimal (because
  basically, testimage.bbclass is parsed too late, while we need to tune
  this variable in some core layers)
- uses += instead of append syntax in core layers (e.g: in ptest images),
  so the variable can still be tuned with append/prepend/remove syntax in 
downstream layers

[1] 
https://lore.kernel.org/openembedded-core/20230609064802.11777-1-alexis.loth...@bootlin.com/
[2] 
https://lore.kernel.org/openembedded-core/20230609064802.11777-5-alexis.loth...@bootlin.com/

Alexis Lothoré (2):
  testimage: move TESTIMAGE_FAILED_QA_ARTIFACTS default value to
core-image-minimal
  core-image-ptest: retrieve ptests directory when ptests fail

 meta/classes-recipe/testimage.bbclass  | 9 -
 meta/recipes-core/images/core-image-minimal.bb | 8 
 meta/recipes-core/images/core-image-ptest.bb   | 2 ++
 3 files changed, 10 insertions(+), 9 deletions(-)

-- 
2.42.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#194291): 
https://lists.openembedded.org/g/openembedded-core/message/194291
Mute This Topic: https://lists.openembedded.org/mt/103932522/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 2/2] core-image-ptest: retrieve ptests directory when ptests fail

[Alexis Lothoré via lists . openembedded . org]

From: Alexis Lothoré 

TESTIMAGE_FAILED_QA_ARTIFACTS is defined in core-image-minimal with a
minimal list of files to retrieve whenever a runtime test fails. By
appending the ptest directory only in core-image-ptest.bb, thanks to
multiconfig feature used in the recipe, only failing ptests will lead to
corresponding ptest artifacts retrieval, instead of all ptests artifacts
retrieval.

Signed-off-by: Alexis Lothoré 
---
This patch was present in the original artifacts series ([1])

Changes since previous series:
- use += instead of append syntax

[1] 
https://lore.kernel.org/openembedded-core/20230609064802.11777-4-alexis.loth...@bootlin.com/
---
 meta/recipes-core/images/core-image-ptest.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-core/images/core-image-ptest.bb 
b/meta/recipes-core/images/core-image-ptest.bb
index b6f5c2fd6049..fb96c542c0a3 100644
--- a/meta/recipes-core/images/core-image-ptest.bb
+++ b/meta/recipes-core/images/core-image-ptest.bb
@@ -43,3 +43,5 @@ python () {
 raise bb.parse.SkipRecipe("No class extension set")
 }
 
+# Include ptest directory in artifacts to retrieve if there is a failed test
+TESTIMAGE_FAILED_QA_ARTIFACTS += "${libdir}/${MCNAME}/ptest"
-- 
2.42.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#194289): 
https://lists.openembedded.org/g/openembedded-core/message/194289
Mute This Topic: https://lists.openembedded.org/mt/103932520/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 1/2] testimage: move TESTIMAGE_FAILED_QA_ARTIFACTS default value to core-image-minimal

[Alexis Lothoré via lists . openembedded . org]

From: Alexis Lothoré 

TESTIMAGE_FAILED_QA_ARTIFACTS currently sets a default list of files to be
saved whenever some tests fail. Unfortunately, this default value is very
easily discarded, because TESTIMAGE_FAILED_QA_ARTIFACTS is expected to be
enriched by some core recipes (example: ptest images) which are often
parsed before testimage.bbclass. Those core recipes could still manage to
get the default value AND add some files by using override syntax, but then
it makes it difficult for downstream recipes or bbappend files to tune this
variable.

Allow to set this default value and make sure it is not overwritten by
recipes wanting to tune it, by setting the default value in
core-image-minimal.
While doing so, set it as a default value instead of a weak default value.

Signed-off-by: Alexis Lothoré 
---
 meta/classes-recipe/testimage.bbclass  | 9 -
 meta/recipes-core/images/core-image-minimal.bb | 8 
 2 files changed, 8 insertions(+), 9 deletions(-)

diff --git a/meta/classes-recipe/testimage.bbclass 
b/meta/classes-recipe/testimage.bbclass
index f36d9418914f..cfda5b631ba8 100644
--- a/meta/classes-recipe/testimage.bbclass
+++ b/meta/classes-recipe/testimage.bbclass
@@ -18,15 +18,6 @@ inherit image-artifact-names
 
 TESTIMAGE_AUTO ??= "0"
 
-# When any test fails, TESTIMAGE_FAILED_QA ARTIFACTS will be parsed and for
-# each entry in it, if artifact pointed by path description exists on target,
-# it will be retrieved onto host
-
-TESTIMAGE_FAILED_QA_ARTIFACTS ??= "\
-${localstatedir}/log \
-${sysconfdir}/version \
-${sysconfdir}/os-release"
-
 # You can set (or append to) TEST_SUITES in local.conf to select the tests
 # which you want to run for your target.
 # The test names are the module names in meta/lib/oeqa/runtime/cases.
diff --git a/meta/recipes-core/images/core-image-minimal.bb 
b/meta/recipes-core/images/core-image-minimal.bb
index 84343adcd8e2..8f5fb0d2ae51 100644
--- a/meta/recipes-core/images/core-image-minimal.bb
+++ b/meta/recipes-core/images/core-image-minimal.bb
@@ -10,3 +10,11 @@ inherit core-image
 
 IMAGE_ROOTFS_SIZE ?= "8192"
 IMAGE_ROOTFS_EXTRA_SPACE:append = "${@bb.utils.contains("DISTRO_FEATURES", 
"systemd", " + 4096", "", d)}"
+
+# When any test fails, TESTIMAGE_FAILED_QA ARTIFACTS will be parsed and for
+# each entry in it, if artifact pointed by path description exists on target,
+# it will be retrieved onto host
+TESTIMAGE_FAILED_QA_ARTIFACTS ?= "\
+${localstatedir}/log \
+${sysconfdir}/version \
+${sysconfdir}/os-release"
\ No newline at end of file
-- 
2.42.1


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

Re: [PATCH] arm: Fix missing bti instruction for virtual thunks

[Richard Earnshaw (lists)]

On 23/01/2024 15:53, Richard Ball wrote:
> Adds missing bti instruction at the beginning of a virtual
> thunk, when bti is enabled.
> 
> gcc/ChangeLog:
> 
>   * config/arm/arm.cc (arm_output_mi_thunk): Emit
>   insn for bti_c when bti is enabled.
> 
> gcc/testsuite/ChangeLog:
> 
> * g++.target/arm/bti_thunk.C: New test.


diff --git a/gcc/config/arm/arm.cc b/gcc/config/arm/arm.cc
index 
e5a944486d7bd583627b0e22dfe8f95862e975bb..91eee8be7c1a59118fbf443557561fb3e0689d61
 100644
--- a/gcc/config/arm/arm.cc
+++ b/gcc/config/arm/arm.cc
@@ -29257,6 +29257,8 @@ arm_output_mi_thunk (FILE *file, tree thunk, 
HOST_WIDE_INT delta,
   const char *fnname = IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (thunk));
 
   assemble_start_function (thunk, fnname);
+  if (aarch_bti_enabled ())
+emit_insn (aarch_gen_bti_c());

Missing space between ...bit_c and the parenthesis.

   if (TARGET_32BIT)
 arm32_output_mi_thunk (file, thunk, delta, vcall_offset, function);
   else

diff --git a/gcc/testsuite/g++.target/arm/bti_thunk.C 
b/gcc/testsuite/g++.target/arm/bti_thunk.C
new file mode 100644
index 
..5c4a8e5a8d74581eca2b877c000a5b34ddca0e9b
--- /dev/null
+++ b/gcc/testsuite/g++.target/arm/bti_thunk.C
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-options "-march=armv8.1-m.main+pacbti -O1 -mbranch-protection=bti 
--save-temps" } */

You can't just add options like this; they may not work with other options 
passed by the testsuite framework.  Instead, you should a suitable entry to 
lib/target-supports.exp in the table starting "foreach { armfunc armflag 
armdefs } {" that tests whether the options can be safely added, and then use 
dg-require-effective-target and dg-add-options for your new set of options.

\ No newline at end of file

Please add one :)

R.

Re: PESO - selfie in the 'hood

[lists]

> On 18 Jan 2024, at 16:42, ann sanfedele  wrote:
> 
> Between FB and INSTAGRAM and PDML FB and using messenger online occasionally 
> where I see most of you, I've been mostly lurking here. confessing that any
> discussion of new tech of any photo related stuff is of little interest  I 
> hardly ever post here these days.  since I can see your photos (which does 
> interest me) elsewhere.
> I'm not doing much new stuff except editing archives and listing stuff  I'm 
> selling on ebay or on the create photo calendars site)
> 
> So for the few who haven't seen me for a while and only look/lurk here  - 
> this is a new one  taken a couple of days before my 87th birthday in Dec.  a 
> few blocks from
> my apt.  The thing that looks like a photo equip bag is an insulated lunch 
> bag for shopping .  I don't do any photo walks - just slip the tiniest camera 
> I have into my pocket
> when I go out and don't anticipate carrying too much other stuff on my way 
> home.  anyway, I kinda like this one.

Nice one Ann!

And who’s the young lady in the mirror?  ;-)

Regards, Jan van Wijk


=
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] Used Juniper

[Justin Wilson (Lists)]

The key is to make your network modular so you can swap out Cisco for Juniper 
or Juniper for Cisco or whatever the flavor of router/switch you may like at 
that point in time. Try not to get tied to an ecosystem.


Justin Wilson
j...@mtin.net

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

> On Jan 23, 2024, at 10:45 AM,   
> wrote:
> 
> I started on Cisco forever ago.  During my WISP times it was a blend of 
> Mikrotiks and refurb Cisco’s.
> I started on Juniper a few years ago.  It was alien at first, but I learned 
> to like it.  Networks are never homogenous….at least not forever. 
> And after 25 years of scripting, programming, system admin, network 
> engineering, etc I have had to learn a lot of different syntax so I don’t see 
> a problem adding one more to the mix.  I wouldn’t have a lot of sympathy for 
> an employee  who’s stuck on Juniper or Cisco and doesn’t want to do the other.
>  
> Call me crazy if you want.
>  
>  
> From: AF  On Behalf Of Peter Kranz via AF
> Sent: Monday, January 22, 2024 1:51 PM
> To: 'AnimalFarm Microwave Users Group' 
> Cc: Peter Kranz 
> Subject: Re: [AFMUG] Used Juniper
>  
> Juniper has an entirely different programming style that Cisco.. most network 
> folks like one or the other, I would not suggest mixing them in your network.
>  
> Peter Kranz
> www.UnwiredLtd.com 
> Desk: 510-868-1614 x100
> Mobile: 510-207-
> pkr...@unwiredltd.com 
>> .
> -- 
> 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

Re: Stepping down as Python maintainer

[Genes Lists]

On Wed, 2023-12-13 at 16:28 +0200, Felix Yan wrote:
> Hello,
> 
> ...
> so I am
> making room for others to try on the 3.11 and 3.12 rebuilds. As Jelle
> has progressed a lot now, I feel it's approaching the right time for
> me 
> to step down as the Python maintainer.
> 
> ..

Thank you Felix  for all the work you've done over the years helping to
make Arch into what it is today. 

I wonder if you could share any updates on the maintainer
transition and any thoughts around the rather large 3.12 project?

I also notice that while many python modules have continued to be
updated some have not.  Is the thinking perhaps  to hold on some,
especially perhaps the more complicated ones like pandas, until 3.12 is
out?

gene

Re: [Postfix] Warn that databases need regeneration

[Genes Lists]

On Tue, 2024-01-23 at 15:16 +, Polarian wrote


See:

https://gitlab.archlinux.org/archlinux/packaging/packages/postfix/-/issues/2

Re: [PATCH][GCC][Arm] Add pattern for bswap + rotate -> rev16 [Bug 108933]

[Richard Earnshaw (lists)]

On 22/01/2024 12:18, Matthieu Longo wrote:
> rev16 pattern was not recognised anymore as a change in the bswap tree
> pass was introducing a new GIMPLE form, not recognized by the assembly
> final transformation pass.
> 
> More details in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108933
> 
> gcc/ChangeLog:
> 
>     PR target/108933
>     * config/arm/arm.md (*arm_rev16si2_alt3): new pattern to convert
>   a bswap + rotate by 16 bits into rev16

ChangeLog entries need to be written as sentences, so start with a capital 
letter and end with a full stop; continuation lines should start in column 8 
(one hard tab, don't use spaces).  But in this case, "New pattern." is 
sufficient.

> 
> gcc/testsuite/ChangeLog:
> 
>     PR target/108933
>     * gcc.target/arm/rev16.c: Moved to...
>     * gcc.target/arm/rev16_1.c: ...here.
>     * gcc.target/arm/rev16_2.c: New test to check that rev16 is
>   emitted.


+;; Similar pattern to match (rotate (bswap) 16)
+(define_insn "*arm_rev16si2_alt3"
+  [(set (match_operand:SI 0 "register_operand" "=l,r")
+(rotate:SI (bswap:SI (match_operand:SI 1 "register_operand" "l,r"))
+ (const_int 16)))]
+  "arm_arch6"
+  "rev16\\t%0, %1"
+  [(set_attr "arch" "t,32")
+   (set_attr "length" "2,4")
+   (set_attr "type" "rev")]
+)
+

Unfortunately, this is insufficient.  When generating Arm or Thumb2 code (but 
not thumb1) we also have to handle conditional execution: we need to have '%?' 
in the output template at the point where a condition code might be needed.  
That means we need separate output templates for all three alternatives (as we 
need a 16-bit variant for thumb2 that's conditional and a 16-bit for thumb1 
that isn't).  See the output of arm_rev16 for a guide of what is really needed.

I note that the arm_rev16si2_alt1, and arm_rev16si2_alt2 patterns are incorrect 
in this regard as well; that will need fixing.

I also see that arm_rev16si2 currently expands to the alt1 variant above; given 
that the preferred canonical form would now appear to use bswap + rotate, we 
should change that as well.  In fact, we can merge your new pattern with the 
expand entirely and eliminate the need to call gen_arm_rev16si2_alt1.  
Something like:

(define_insn "arm_rev16si2"
  [(set (match_operand:SI 0 "s_register_operand")
(rotate:SI (bswap:SI (match_operand:SI 1 "s_register_operand")) 
(const_int 16))]
  "arm_arch6"
  "@
  rev16...
  ...


R.

Re: [PATCH] arm: Fix parsecpu.awk for aliases [PR113030]

[Richard Earnshaw (lists)]

On 21/01/2024 07:29, Andrew Pinski wrote:
> So the problem here is the 2 functions check_cpu and check_arch use
> the wrong variable to check if an alias is valid for that cpu/arch.
> check_cpu uses cpu_optaliases instead of cpu_opt_alias. cpu_optaliases
> is an array of index'ed by the cpuname that contains all of the valid aliases
> for that cpu but cpu_opt_alias is an double index array which is index'ed
> by cpuname and the alias which provides what is the alias for that option.
> Similar thing happens for check_arch and arch_optaliases vs arch_optaliases.
> 
> Tested by running:
> ```
> awk -f config/arm/parsecpu.awk -v cmd="chkarch armv7-a+simd" 
> config/arm/arm-cpus.in
> awk -f config/arm/parsecpu.awk -v cmd="chkarch armv7-a+neon" 
> config/arm/arm-cpus.in
> awk -f config/arm/parsecpu.awk -v cmd="chkarch armv7-a+neon-vfpv3" 
> config/arm/arm-cpus.in
> ```
> And they don't return error back.
> 
> gcc/ChangeLog:
> 
>   PR target/113030
>   * config/arm/parsecpu.awk (check_cpu): Use cpu_opt_alias
>   instead of cpu_optaliases.
>   (check_arch): Use arch_opt_alias instead of arch_optaliases.

OK

Thanks,

R.

> 
> Signed-off-by: Andrew Pinski 
> ---
>  gcc/config/arm/parsecpu.awk | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/gcc/config/arm/parsecpu.awk b/gcc/config/arm/parsecpu.awk
> index ddd4f3b440a..384462bdb5b 100644
> --- a/gcc/config/arm/parsecpu.awk
> +++ b/gcc/config/arm/parsecpu.awk
> @@ -529,7 +529,7 @@ function check_cpu (name) {
>  
>  for (n = 2; n <= exts; n++) {
>   if (!((cpu_name, extensions[n]) in cpu_opt_remove)  \
> - && !((cpu_name, extensions[n]) in cpu_optaliases)) {
> + && !((cpu_name, extensions[n]) in cpu_opt_alias)) {
>   return "error"
>   }
>  }
> @@ -552,7 +552,7 @@ function check_arch (name) {
>  
>  for (n = 2; n <= exts; n++) {
>   if (!((extensions[1], extensions[n]) in arch_opt_remove)\
> - && !((extensions[1], extensions[n]) in arch_optaliases)) {
> + && !((extensions[1], extensions[n]) in arch_opt_alias)) {
>   return "error"
>   }
>  }

Re: Console freezes on AMDGPU RX 7600

[Alexis de BRUYN [Mailing Lists]]

I had the same issue several months ago. I red here [1] that the Radeon 
RX 7600 series needs DRM Linux 6.3.


I guess this should worked now with [2].

[1] https://www.phoronix.com/review/amd-radeon-rx-7600-linux
[2] https://marc.info/?l=openbsd-cvs=170544826019326=2

On 05/01/2024 00:31, Искандер Низамутдинов wrote:

Synopsis: Screen refresh rate drops upon switching from X onto Console
Category: system
Environment:

 System  : OpenBSD 7.4
 Details   : OpenBSD 7.4-current (GENERIC.MP) #1587: Sat Dec 30
22:44:51 MST 2023

dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP

 Architecture: OpenBSD.amd64
 Machine  : amd64

Description:

 If X session was started and the user switches to console, working
inside console
 becomes practically impossible after approximately 5 seconds: screen starts
 to refresh only every 2-5 seconds while user types. User's input
is accepted by
 the system, just not shown until the next screen update.

 Console output while the user not types seems smooth. Upon "cat 
/dev/random"
 command output is smooth, presumably at the maximum refresh rate that the
 system supports.

 Hitting Enter or Ctrl+C almost always refreshes the screen. Screen
could be freezed
 for less than a second while Enter/Ctrl+C is held.

 If the user switches to X and back to console, the cycle repeats.
The user once again has
 ~5 seconds to type normally, then the screen freezes start.

 The bug is not present if X session had never started during the
session. The bug
 does reproduce after "rcctl stop xenodm".

 I presume the problem is somehow related to my GPU because on the
7.4 release I had
 almost the same behaviour on keyboard input inside X session in
terminal emulators
 (xterm, xfce4-terminal). Moving a mouse / watching a video made
the screen refreshing
 normal. I also have a "WARNING" message related to amdgpu in dmesg.

How-To-Repeat:

 0. Presumably have AMD GPU RX 7600 installed
 1. Start X session / Have X session started
 2. Switch to console
 3. Type continuously
 Result: For the first ~5 seconds everything looks normal, then the
image starts to refresh
 only every 2-5 seconds.

Fix:

 Unknown to me.



dmesg:
OpenBSD 7.4-current (GENERIC.MP) #1587: Sat Dec 30 22:44:51 MST 2023
 dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
real mem = 34173661184 (32590MB)
avail mem = 33117683712 (31583MB)
random: good seed from bootblocks
mpath0 at root
scsibus0 at mpath0: 256 targets
mainbus0 at root
bios0 at mainbus0: SMBIOS rev. 3.5 @ 0x39a4e000 (107 entries)
bios0: vendor American Megatrends International, LLC. version "F5"
date 03/07/2023
bios0: Gigabyte Technology Co., Ltd. Z790 UD
efi0 at bios0: UEFI 2.8
efi0: American Megatrends rev 0x5001b
acpi0 at bios0: ACPI 6.4
acpi0: sleep states S0 S3 S4 S5
acpi0: tables DSDT FACP FIDT SSDT SSDT SSDT SSDT SSDT SSDT HPET APIC
MCFG SSDT SSDT NHLT LPIT SSDT SSDT DBGP DBG2 SSDT FPDT SSDT SSDT SSDT
SSDT VFCT TPM2 BGRT PHAT WSMT
acpi0: wakeup devices PEG1(S4) PEGP(S4) PEGP(S4) PEG0(S4) PEGP(S4)
PS2K(S3) PS2M(S3) RP09(S4) PXSX(S4) RP10(S4) PXSX(S4) RP11(S4)
PXSX(S4) RP12(S4) PXSX(S4) RP13(S4) [...]
acpitimer0 at acpi0: 3579545 Hz, 24 bits
acpihpet0 at acpi0: 1920 Hz
acpimadt0 at acpi0 addr 0xfee0: PC-AT compat
cpu0 at mainbus0: apid 0 (boot processor)
cpu0: 13th Gen Intel(R) Core(TM) i7-13700KF, 3400.99 MHz, 06-b7-01,
patch 011d
cpu0: 
FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CFLUSH,DS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE,SSE3,PCLMUL,DTES64,MWAIT,DS-CPL,VMX,EST,TM2,SSSE3,SDBG,FMA3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,DEADLINE,AES,XSAVE,AVX,F16C,RDRAND,NXE,PAGE1GB,RDTSCP,LONG,LAHF,ABM,3DNOWP,PERF,ITSC,FSGSBASE,TSC_ADJUST,BMI1,AVX2,SMEP,BMI2,ERMS,INVPCID,RDSEED,ADX,SMAP,CLFLUSHOPT,CLWB,PT,SHA,UMIP,PKU,WAITPKG,PKS,MD_CLEAR,IBT,IBRS,IBPB,STIBP,L1DF,SSBD,SENSOR,ARAT,IBRS_ALL,SKIP_L1DFL,MDS_NO,IF_PSCHANGE,TAA_NO,MISC_PKG_CT,ENERGY_FILT,DOITM,SBDR_SSDP_N,FBSDP_NO,PSDP_NO,RRSBA,OVERCLOCK,GDS_NO,XSAVEOPT,XSAVEC,XGETBV1,XSAVES
cpu0: 48KB 64b/line 12-way D-cache, 32KB 64b/line 8-way I-cache, 2MB
64b/line 16-way L2 cache, 30MB 64b/line 12-way L3 cache
cpu0: smt 0, core 0, package 0
mtrr: Pentium Pro MTRR support, 10 var ranges, 88 fixed ranges
cpu0: apic clock running at 38MHz
cpu0: mwait min=64, max=64, C-substates=0.2.0.2.0.1.0.1, IBE
cpu1 at mainbus0: apid 1 (application processor)
cpu1: 13th Gen Intel(R) Core(TM) i7-13700KF, 3401.00 MHz, 06-b7-01,
patch 011d
cpu1: 

Re: [gentoo-user] Kmail does not show all imap folders

[Wols Lists]

On 22/01/2024 07:04, Alexander Puchmayr wrote:

I checked folder subscriptions in kmail, but I do not see the missing folders
there either. Also akonadi-console does not show them. I also tried
curl imaps:///
Showing all of the missing folders, so I think its an akonadi/kmail problem
and not an imap problem.

Any ideas?


I occasionally get this problem in Thunderbird, and one of the options 
in folder properties is "delete the index". If you've got that option 
for the parent folder, do it, and then kmail should rebuild from scratch 
and find the folders.


Cheers,
Wol

Re: add volatile flag to PV/LVs (for cache) to avoid degraded state on reboot

[lists . linux . dev]

On Thu, Jan 18, 2024 at 04:40:47PM +0100, Zdenek Kabelac wrote:
> Cache can contain blocks that are still being 'synchronized' to the cache
> origin. So while the 'writing' process doesn't get ACK for writes - the
> cache
> may have valid blocks that are 'dirty' in terms of being synchronized to
> origin device.
> 
> And while this is usually not a problem when system works properly,
> it's getting into weird 'state machine' model when i.e. origin device has
> errors - which might be even 'transient' with all the variety of storage
> types and raid arrays with integrity and self-healing and so on...
> 
> So while it's usually not a problem for a laptop with 2 disks, the world is
> more complex...

Ehm, but wouldn't anything other than discarding that block from the cache and 
using whatever is on the backing storage introduce unpredictable errors?
As like you already said it was never ACKed, so the software that tried to 
write it never expected it to be written.
Why exactly are we allowed to use the data from the write-through cache to 
modify the data on the backing storage in such cases?
I.E. Why can we safely consider it as valid data?

> metadata - so if there is again some 'reboot' and PV with cache appears back
> - it will not interfere with the system (aka providing some historical
> cached blocks,  so just like mirrored leg needs some care...)

Same here, why do we have to consider these blocks at all and can't discard 
them? We know when a drive re-appears, so we could just not use it without 
validation, or in the case the volatile flag I suggested would be used, just 
wipe it and start over...

After all I don't know anyone that designs their storage systems with the 
assumption that the write-through cache has to be redundant.
Even more, I know enough people in data center environments that reuse their 
"failing but still kinda good" SSDs and NVMEs for write-through caches using 
the assumption that them failing at most impacts read performance but not data 
security.

Is there some common missconception at play? Or what exaclty am I missing here?

Sincerely,
Klaus Frank

Re: [tor-relays] A new kind of attack?

[lists]

On Montag, 15. Januar 2024 23:19:37 CET Chris Enkidu-6 wrote:
> I've noticed a new kind of possible attack on some of my relays, as
> early as Dec.23 which causes huge spikes of outbound traffic
> 
> I have included charts and excerpts from the log in my post in Tor forum
> at below link:
> 
> https://forum.torproject.org/t/new-kind-of-attack/11122

This seems to be related to what we already had in September:
https://forum.torproject.org/t/excessive-unbalanced-relay-traffic/9291

It is always only intermittent and only some off my relays are affected.
https://forum.torproject.org/t/excessive-unbalanced-relay-traffic/9291/8

-- 
╰_╯ 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

Re: [OE-core] [PATCH] uboot-sign: support to load optee-os and TFA images

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

On 15.01.24 08:54, Jamin Lin via lists.openembedded.org wrote:
> Currently, u-boot FIT image only support to load u-boot image.
> To support optee-os and trusted-firmware-a, update ITS file generation
> scripts, so users are able to use u-boot FIT image to load
> u-boot, optee-os and treustred-firmware-a images
> 
> Add a variable "UBOOT_FIT_ARM_TRUSTED_FIRMWARE_A" to
> enable trusted-firmware-a image and it is disable by default.
> 
> Add a variable "UBOOT_FIT_OPTEE_OS" to enable optee-os image
> and it is disable by default.
> 
> The ITS file creation loos like as following.


Is here a K missing?


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

Re: boot partition expansion

[Genes Lists]

On Mon, 2024-01-15 at 19:30 +, Serge Korol wrote:
> sizes of img files with latest mkinitcpio 37.2-1
> 

 * Things seem quite reasonable again with the latest release of
mkinitcpio

 * I stopped keeping fallback images for both dracut and mkinitcpio.
 You may or may not choose to do this too.

 * -If- you choose to do this and ever need a driver in the initrd for
changed hardware (e.g. root drive disk controller) then for that  
somewhat rare case one should keep a handy usb drive with arch
installer so you can boot that and regen the initrd.  

  Benefits of no fallback:
   * smaller space usage and much faster regeneration of initrd [1]

 * If you choose to no longer keep fallback image then the following is
one way to do it:

   1) edit /etc/mkinitcpio.d/linux.preset
       Change preset line to be
       PRESETS=('default')

   2)  rm /boot/initramfs-linux-fallback.img

   3) Confirm regen initrd:

       mkinitcpio -P (or -p linux)


gene

 [1] Its initramfs but initrd, while not the same, is sometimes used in
place of initramfs and its shorter to type 

add volatile flag to PV/LVs (for cache) to avoid degraded state on reboot

[lists . linux . dev]

Hi,

at first, a happy new year to everyone.

I'm currently considering to use dm-cache with a ramdisk/volatile PV for a 
small project and noticed some usability issues that make using it less 
appealing.


Currently this means:
1. Adding a cache to a VG will cause the entire VG to depend on the cache. If 
one of the cache drives fails or is missing it cannot be accessed and even 
worse if this was the VG containing the root filesystem it also causes the 
entire system to fail to boot. Even though we may already know that we don't 
have any dataloss but just degraded access times.
2. Requires manual scripting to activate the VG and handle potentially 
missing/failing cache PVs
3. LVM doesn't have a way to clearly indicate that the physical volume is 
volatile and that dataloss on it is expected. Maybe even including the PV 
header itself. Or alternatively a way to indicate "if something is wrong with 
the cache, just forget about it (if possible)".
4. Just recreating the 'pvcreate --zero --pvmetadatacopies 0 --norestorefile 
--uuid' appears to be enough to get a write-through cache and thereby also the 
associated volume working again. Therefore it doesn't look like LVM cares about 
the cache data being lost, but only about the PV itself. Therefore failing to 
activate the VG appears to be a bit too convservative and probably the error 
handling here could be improved (see above).
6. Also as there is currently no place within the LVM metadata to label a 
PV/VG/LV as "volatile" it is also not clear both to LVM as well as admins 
looking at output of tools like lvdisplay that a specific LV is volatile. 
Therefore there will also be no safeguards and warnings against actions that 
would cause dataloss (like adding a ramdisk to a raid0, or even just adding a 
write-back instead of a write-through cache).


Therefore I'd like to ask if it would be possible to make two small 
improvements:
1. Add a "volatile" flag to PVs, LVs, and VGs to allow to clearly indicate that 
they are non-persistent and that dataloss is expected.
2. And one of:
 a. Change error handling and automatic recovery from missing PVs if the LV or 
VG has the volatile flag. Like e.g. automatically `--uncache`-ing the volume 
and mount it without the cache that is missing its PV. This is even more 
important for boot volumes, where such a configuration would prevent the system 
from booting at all.
 b. Alternatively, add native support for ramdisks. This mainly would require 
extending the VG metadata with an 'is-RAMdisk' flag that causes the lookup for 
the PV to be skipped and instead a new ramdisk being allocated while the VG is 
being activated (we know its size from the VG metadata, as we know how much we 
allocate/use). This could also help with unit tests and CI/CD usages (where 
currently the PV is manually created with brd before activating/creating the 
VG). Including our own test/lib/aux.sh, test/shell/devicesfile-misc.sh, 
test/shell/devicesfile-refresh.sh, test/shell/devicesfile-serial.sh.
 c. Same as 2a, but instead of automatically uncaching the volume, add a flag 
to the VG metadata that allows LVM to use the hints file to find the PV and 
automatically re-initialize it regardless of its header. Maybe together with an 
additional configuration option to demand the block device being zeroed (I.E. 
to avoid reading the entire block device, the first 4 sectors) to safeguard 
against accidental data-loss that we normally get by looking for the correct PV 
header.
 d. Same as 2b, but limited to caches only. Considering how caching is 
currently implemented adding ramdisks with an limitation to caches may cause 
unecessary additional work and be less useful compared to adding them as a new 
additional kind of PV. Also it wouldn't help the additional usecase with unit 
tests and CI/CD pipelines. Additionally it would also simplify "playing with" 
and learning about LVM.
 e. Add an option to have lvconvert enable caching but WITHOUT saving it within 
the VGs metadata. Causing LVM to forget about the case. I.E. next time the 
system boots LVM would mount the VG normally without the cache. For 
write-through caches this should always be safe and for write-back it only 
causes dataloss when the system crashes without flushing it.

My personal favourite is 2b, followed by 2e.
2b basically realizes my entire usecase within LVM natively and 2e at least 
avoids the need to automating the LVM recovery just to be able to reboot the 
system and allow me to write a systemd service to add the cache at runtime.

Best regards

Re: [PATCH v3 00/12] [GCC] arm: vld1q vst1 vst1q vst1 intrinsics

[Richard Earnshaw (lists)]

On 02/01/2024 09:23, ezra.sito...@arm.com wrote:
> From: Ezra Sitorus 
> 
> Add vld1q, vst1, vst1q and vst1 intrinsics to arm port.
> 
> Ezra Sitorus (12):
>   [GCC] arm: vld1q_types_x2 ACLE intrinsics
>   [GCC] arm: vld1q_types_x3 ACLE intrinsics
>   [GCC] arm: vld1q_types_x4 ACLE intrinsics
>   [GCC] arm: vst1_types_x2 ACLE intrinsics
>   [GCC] arm: vst1_types_x3 ACLE intrinsics
>   [GCC] arm: vst1_types_x4 ACLE intrinsics
>   [GCC] arm: vst1q_types_x2 ACLE intrinsics
>   [GCC] arm: vst1q_types_x3 ACLE intrinsics
>   [GCC] arm: vst1q_types_x4 ACLE intrinsics
>   [GCC] arm: vld1_types_x2 ACLE intrinsics
>   [GCC] arm: vld1_types_x3 ACLE intrinsics
>   [GCC] arm: vld1_types_x4 ACLE intrinsics
> 
>  gcc/config/arm/arm_neon.h | 2032 ++---
>  gcc/config/arm/arm_neon_builtins.def  |   12 +
>  gcc/config/arm/iterators.md   |6 +
>  gcc/config/arm/neon.md|  249 ++
>  gcc/config/arm/unspecs.md |8 +
>  .../gcc.target/arm/simd/vld1_base_xN_1.c  |  176 ++
>  .../gcc.target/arm/simd/vld1_bf16_xN_1.c  |   23 +
>  .../gcc.target/arm/simd/vld1_fp16_xN_1.c  |   23 +
>  .../gcc.target/arm/simd/vld1_p64_xN_1.c   |   23 +
>  .../gcc.target/arm/simd/vld1q_base_xN_1.c |  183 ++
>  .../gcc.target/arm/simd/vld1q_bf16_xN_1.c |   24 +
>  .../gcc.target/arm/simd/vld1q_fp16_xN_1.c |   24 +
>  .../gcc.target/arm/simd/vld1q_p64_xN_1.c  |   24 +
>  .../gcc.target/arm/simd/vst1_base_xN_1.c  |  176 ++
>  .../gcc.target/arm/simd/vst1_bf16_xN_1.c  |   22 +
>  .../gcc.target/arm/simd/vst1_fp16_xN_1.c  |   23 +
>  .../gcc.target/arm/simd/vst1_p64_xN_1.c   |   23 +
>  .../gcc.target/arm/simd/vst1q_base_xN_1.c |  185 ++
>  .../gcc.target/arm/simd/vst1q_bf16_xN_1.c |   24 +
>  .../gcc.target/arm/simd/vst1q_fp16_xN_1.c |   24 +
>  .../gcc.target/arm/simd/vst1q_p64_xN_1.c  |   24 +
>  21 files changed, 3018 insertions(+), 290 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.target/arm/simd/vld1_base_xN_1.c
>  create mode 100644 gcc/testsuite/gcc.target/arm/simd/vld1_bf16_xN_1.c
>  create mode 100644 gcc/testsuite/gcc.target/arm/simd/vld1_fp16_xN_1.c
>  create mode 100644 gcc/testsuite/gcc.target/arm/simd/vld1_p64_xN_1.c
>  create mode 100644 gcc/testsuite/gcc.target/arm/simd/vld1q_base_xN_1.c
>  create mode 100644 gcc/testsuite/gcc.target/arm/simd/vld1q_bf16_xN_1.c
>  create mode 100644 gcc/testsuite/gcc.target/arm/simd/vld1q_fp16_xN_1.c
>  create mode 100644 gcc/testsuite/gcc.target/arm/simd/vld1q_p64_xN_1.c
>  create mode 100644 gcc/testsuite/gcc.target/arm/simd/vst1_base_xN_1.c
>  create mode 100644 gcc/testsuite/gcc.target/arm/simd/vst1_bf16_xN_1.c
>  create mode 100644 gcc/testsuite/gcc.target/arm/simd/vst1_fp16_xN_1.c
>  create mode 100644 gcc/testsuite/gcc.target/arm/simd/vst1_p64_xN_1.c
>  create mode 100644 gcc/testsuite/gcc.target/arm/simd/vst1q_base_xN_1.c
>  create mode 100644 gcc/testsuite/gcc.target/arm/simd/vst1q_bf16_xN_1.c
>  create mode 100644 gcc/testsuite/gcc.target/arm/simd/vst1q_fp16_xN_1.c
>  create mode 100644 gcc/testsuite/gcc.target/arm/simd/vst1q_p64_xN_1.c
> 

Thanks, I've pushed this series.

Reviewing this series did highlight a couple of issues with the existing code 
base (not your patch); I'll follow up on these separately.

R.

[oe] [meta-oe][PATCH] i2cdev: Fix MUSL build

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

From: Jörg Sommer 

Building the recipe with MUSL fails, because it uses error.h which isn't
supported by MUSL. Because the usage is only in one expression, it's easy to
rewrite this.

Signed-off-by: Jörg Sommer 
---
 .../recipes-bsp/i2cdev/i2cdev/fix-musl.patch  | 122 ++
 meta-oe/recipes-bsp/i2cdev/i2cdev_git.bb  |   1 +
 2 files changed, 123 insertions(+)
 create mode 100644 meta-oe/recipes-bsp/i2cdev/i2cdev/fix-musl.patch

diff --git a/meta-oe/recipes-bsp/i2cdev/i2cdev/fix-musl.patch 
b/meta-oe/recipes-bsp/i2cdev/i2cdev/fix-musl.patch
new file mode 100644
index 0..59fd379de
--- /dev/null
+++ b/meta-oe/recipes-bsp/i2cdev/i2cdev/fix-musl.patch
@@ -0,0 +1,122 @@
+From ce3affeb45a65649dda1edc9a4f0586e9db47ada Mon Sep 17 00:00:00 2001
+Message-Id: 

+From: =?UTF-8?q?J=C3=B6rg=20Sommer?= 
+Date: Fri, 12 Jan 2024 13:59:51 +0100
+Subject: [PATCH] lsi2c: Replace error() by fprintf, drop error.h
+
+The MUSL C library doesn't support error.h. Because the only usage of this
+is the *error* function in lsi2c.c, this gets replaced by a *fprintf*. This
+doesn't print the program name, but keeps the message and the error
+description.
+
+Upstream-Status: Submitted [https://github.com/costad2/i2cdev/pull/5]
+---
+ libi2cdev/access.c | 1 -
+ libi2cdev/i2c-bus-parser.c | 1 -
+ libi2cdev/i2c-dev-path.c   | 1 -
+ libi2cdev/i2c-error.c  | 1 -
+ libi2cdev/init.c   | 2 --
+ libi2cdev/sysfs.c  | 1 -
+ lsi2c/lsi2c.c  | 4 ++--
+ 7 files changed, 2 insertions(+), 9 deletions(-)
+
+diff --git a/libi2cdev/access.c b/libi2cdev/access.c
+index 62a3f59..2e77659 100644
+--- a/libi2cdev/access.c
 b/libi2cdev/access.c
+@@ -16,7 +16,6 @@
+ 
+ #include "busses.h"
+ #include "data.h"
+-#include "error.h"
+ #include "sysfs.h"
+ 
+ #include "i2cdiscov.h"
+diff --git a/libi2cdev/i2c-bus-parser.c b/libi2cdev/i2c-bus-parser.c
+index c4b8688..8c760e0 100644
+--- a/libi2cdev/i2c-bus-parser.c
 b/libi2cdev/i2c-bus-parser.c
+@@ -27,7 +27,6 @@
+ #include 
+ #include 
+ #include 
+-#include 
+ #include 
+ #include 
+ 
+diff --git a/libi2cdev/i2c-dev-path.c b/libi2cdev/i2c-dev-path.c
+index b156db7..361761c 100644
+--- a/libi2cdev/i2c-dev-path.c
 b/libi2cdev/i2c-dev-path.c
+@@ -11,7 +11,6 @@
+ #include 
+ #include 
+ #include 
+-#include 
+ 
+ #include 
+ 
+diff --git a/libi2cdev/i2c-error.c b/libi2cdev/i2c-error.c
+index f92fb6b..540c112 100644
+--- a/libi2cdev/i2c-error.c
 b/libi2cdev/i2c-error.c
+@@ -9,7 +9,6 @@
+ 
+ #include 
+ #include 
+-#include 
+ #include 
+ #include 
+ #include 
+diff --git a/libi2cdev/init.c b/libi2cdev/init.c
+index 99a7edd..dfc4090 100644
+--- a/libi2cdev/init.c
 b/libi2cdev/init.c
+@@ -16,10 +16,8 @@
+ #include 
+ #include 
+ #include 
+-#include 
+ #include 
+ #include 
+-#include 
+ #include 
+ #include 
+ 
+diff --git a/libi2cdev/sysfs.c b/libi2cdev/sysfs.c
+index 2811500..a7e13a8 100644
+--- a/libi2cdev/sysfs.c
 b/libi2cdev/sysfs.c
+@@ -17,7 +17,6 @@
+ #include 
+ #include 
+ #include 
+-#include 
+ #include 
+ 
+ #include 
+diff --git a/lsi2c/lsi2c.c b/lsi2c/lsi2c.c
+index 7af5313..34c6225 100644
+--- a/lsi2c/lsi2c.c
 b/lsi2c/lsi2c.c
+@@ -38,7 +38,6 @@
+ #include 
+ #include 
+ #include 
+-#include 
+ #include 
+ #include 
+ 
+@@ -205,7 +204,8 @@ static int read_config_file(const char *config_file_name)
+ if (err < 0) {
+ err = -err;
+ }
+-error(0, err, "Failed to initialize i2cdevices");
++fflush(stdout);
++fprintf(stderr, "Failed to initialize i2cdevices: %s", strerror(err));
+ if (config_file) {
+ fclose(config_file);
+ }
+-- 
+2.34.1
+
diff --git a/meta-oe/recipes-bsp/i2cdev/i2cdev_git.bb 
b/meta-oe/recipes-bsp/i2cdev/i2cdev_git.bb
index b41ecffae..b2b5fda09 100644
--- a/meta-oe/recipes-bsp/i2cdev/i2cdev_git.bb
+++ b/meta-oe/recipes-bsp/i2cdev/i2cdev_git.bb
@@ -17,6 +17,7 @@ PR = "git${SRCPV}"
 SRC_URI = "\
 git://github.com/costad2/i2cdev.git;protocol=https;branch=master \
 file://fix-lsi2c-makefile.patch \
+file://fix-musl.patch \
 "
 SRCREV = "ed9ad777d842880e7ac6ca5e0de4bd2d3b4d02dc"
 
-- 
2.34.1


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

Re: has anyone tried the new firmware update?

[lists]

> On 11 Jan 2024, at 23:56, Henk Terhell  wrote:
> 
> Larry, the new firmware V2.40 for K-1 and K-1 II has been corrected and is 
> out now as 2.41. I guess it should be safe now to update.
> For K-1: https://www.ricoh-imaging.co.jp/english/support/digital/k1.html
> 

I just updated my K1 2.20 FW to 2.41, no problems sofar.

I like the simpler mode-3 astrotracer function (but have not used it yet 
obviously)
Also like that focus-limiting now works for my DA 35mm macro lens :-)

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: [PATCH v2 7/7] aarch64,arm: Move branch-protection data to targets

[Richard Earnshaw (lists)]

On 11/01/2024 14:43, Szabolcs Nagy wrote:
> The 12/07/2023 13:13, Richard Earnshaw wrote:
>> On 03/11/2023 15:36, Szabolcs Nagy wrote:
>>> * config/aarch64/aarch64.cc (aarch_handle_no_branch_protection): Copy.
>>> (aarch_handle_standard_branch_protection): Copy.
>>> (aarch_handle_pac_ret_protection): Copy.
>>> (aarch_handle_pac_ret_leaf): Copy.
>>> (aarch_handle_pac_ret_b_key): Copy.
>>> (aarch_handle_bti_protection): Copy.
>>
>> I think all of the above functions that have been moved back from
>> aarch-common should be renamed back to aarch64_..., unless they are directly
>> referenced statically by code in aarch-common.c.
> 
> done.
> 
>>> +const struct aarch_branch_protect_type aarch_branch_protect_types[] = {
>>
>> can this be made static now?  And maybe pass the structure as a parameter if
>> that's not done already.
> 
> done in v4.
> 
>> It would be nice if, when we raise an error, we could print out the list of
>> valid options (and modifiers), much like we do on Arm for -march/-mcpu.
>>
>> eg.
>> $ gcc -mcpu=crotex-a8
>> cc1: error: unrecognised -mcpu target: crotex-a8
>> cc1: note: valid arguments are: arm8 arm810 strongarm strongarm110 fa526
>> [...rest of list]; did you mean ‘cortex-a8’?
> 
> i implemented this with candidates_list_and_hint but it does
> not work very well if the typo is in a subtype, so i think
> this should be done in a separate patch if at all.
> 

I'd build the candidates list from all the types + subtypes, so that the 
suggestion code has a full list to pick from; but fair enough.

R.

[RFC] aarch64: Add support for __BitInt

[Andre Vieira (lists)]

Hi,

This patch is still work in progress, but posting to show failure with 
bitint-7 test where handle_stmt called from lower_mergeable_stmt ICE's 
because the idx (3) is out of range for the __BitInt(135) with a 
limb_prec of 64.


I hacked gcc locally to work around this issue and still have one 
outstanding failure, so will look to resolve that failure before posting 
a new version.


Kind Regards,
Andrediff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index 
a5a6b52730d6c5013346d128e89915883f1707ae..15fb0ece5256f25c2ca8bb5cb82fc61488d0393e
 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -6534,7 +6534,7 @@ aarch64_return_in_memory_1 (const_tree type)
   machine_mode ag_mode;
   int count;
 
-  if (!AGGREGATE_TYPE_P (type)
+  if (!(AGGREGATE_TYPE_P (type) || TREE_CODE (type) == BITINT_TYPE)
   && TREE_CODE (type) != COMPLEX_TYPE
   && TREE_CODE (type) != VECTOR_TYPE)
 /* Simple scalar types always returned in registers.  */
@@ -6618,6 +6618,10 @@ aarch64_function_arg_alignment (machine_mode mode, 
const_tree type,
 
   gcc_assert (TYPE_MODE (type) == mode);
 
+  if (TREE_CODE (type) == BITINT_TYPE
+  && int_size_in_bytes (type) > 16)
+return GET_MODE_ALIGNMENT (TImode);
+
   if (!AGGREGATE_TYPE_P (type))
 {
   /* The ABI alignment is the natural alignment of the type, without
@@ -21773,6 +21777,11 @@ aarch64_composite_type_p (const_tree type,
   if (type && (AGGREGATE_TYPE_P (type) || TREE_CODE (type) == COMPLEX_TYPE))
 return true;
 
+  if (type
+  && TREE_CODE (type) == BITINT_TYPE
+  && int_size_in_bytes (type) > 16)
+return true;
+
   if (mode == BLKmode
   || GET_MODE_CLASS (mode) == MODE_COMPLEX_FLOAT
   || GET_MODE_CLASS (mode) == MODE_COMPLEX_INT)
@@ -28265,6 +28274,29 @@ aarch64_excess_precision (enum excess_precision_type 
type)
   return FLT_EVAL_METHOD_UNPREDICTABLE;
 }
 
+/* Implement TARGET_C_BITINT_TYPE_INFO.
+   Return true if _BitInt(N) is supported and fill its details into *INFO.  */
+bool
+aarch64_bitint_type_info (int n, struct bitint_info *info)
+{
+  if (n <= 8)
+info->limb_mode = QImode;
+  else if (n <= 16)
+info->limb_mode = HImode;
+  else if (n <= 32)
+info->limb_mode = SImode;
+  else
+info->limb_mode = DImode;
+
+  if (n > 128)
+info->abi_limb_mode = TImode;
+  else
+info->abi_limb_mode = info->limb_mode;
+  info->big_endian = TARGET_BIG_END;
+  info->extended = false;
+  return true;
+}
+
 /* Implement TARGET_SCHED_CAN_SPECULATE_INSN.  Return true if INSN can be
scheduled for speculative execution.  Reject the long-running division
and square-root instructions.  */
@@ -30374,6 +30406,9 @@ aarch64_run_selftests (void)
 #undef TARGET_C_EXCESS_PRECISION
 #define TARGET_C_EXCESS_PRECISION aarch64_excess_precision
 
+#undef TARGET_C_BITINT_TYPE_INFO
+#define TARGET_C_BITINT_TYPE_INFO aarch64_bitint_type_info
+
 #undef  TARGET_EXPAND_BUILTIN
 #define TARGET_EXPAND_BUILTIN aarch64_expand_builtin
 
diff --git a/libgcc/config/aarch64/t-softfp b/libgcc/config/aarch64/t-softfp
index 
2e32366f891361e2056c680b2e36edb1871c7670..4302ad52eb881825d0fb65b9ebd21031781781f5
 100644
--- a/libgcc/config/aarch64/t-softfp
+++ b/libgcc/config/aarch64/t-softfp
@@ -4,7 +4,8 @@ softfp_extensions := sftf dftf hftf bfsf
 softfp_truncations := tfsf tfdf tfhf tfbf dfbf sfbf hfbf
 softfp_exclude_libgcc2 := n
 softfp_extras += fixhfti fixunshfti floattihf floatuntihf \
-floatdibf floatundibf floattibf floatuntibf
+floatdibf floatundibf floattibf floatuntibf \
+fixtfbitint floatbitinttf
 
 TARGET_LIBGCC2_CFLAGS += -Wno-missing-prototypes
 

Re: [gentoo-user] startx error

[Wols Lists]

On 09/01/2024 22:20, the...@sys-concept.com wrote:

I today's AI age I am supersized we have add it manually to run-level. :-/


Today's clever AI runs on Berkeley. The LSD version, not BSD.

Cheers,
Wol

[oe] [meta-oe][PATCH v4] 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: [gentoo-user] Genlop wonky again

[Wols Lists]

On 09/01/2024 03:35, Peter Humphrey wrote:

On Sunday, 7 January 2024 08:34:15 GMT Wols Lists wrote:


Weird! I took a module on statistics in my Open University (Chemistry)
degree 40-odd years ago. Probably the same one? I've still got the
modules as a reference work, though I probably couldn't lay my hands on
them easily now ...


Could have been the same. It was M100, the first version of their maths
foundation course, in 1976.

Ah. So you predate me slightly. I took M101. But I also took the second 
level statistics course, can't remember what it was ...


Cheers,
Wol

[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: [gentoo-user] Genlop wonky again

[Wols Lists]

On 07/01/2024 00:52, Peter Humphrey wrote:

They seemed to say that the subject was founded on two
basic principles; then they proceeded to define each of them in terms of the
other.


I should add, I dug into this sort of stuff, and you do know the entire 
edifice of Peano (ie number theory), thanks to Godel, is built on the 
edifice that " true == false " :-) ?


Basically, no matter how hard you try, you cannot escape the Cretan Paradox.

To quote some famous mathematician - "If you define a religion as the 
irrational belief in the unprovable, then Mathematics is the only 
religion that can prove it is one".


That's why the Ancient Philosophers debated how many Angels can dance on 
the Head of a Pin. Set aside your prejudices, your beliefs that "that 
*must* be stupid", read Terry Pratchett's "Science of Diskworld", and 
realise that it doesn't matter WHERE you start, the application of logic 
and reason will lead you down the Rabbit Hole into Wonderland.


And modern man is no better at avoiding that trap than the ancients.

Cheers,
Wol

Re: [gentoo-user] Genlop wonky again

[Wols Lists]

On 07/01/2024 00:52, Peter Humphrey wrote:

On Saturday, 6 January 2024 19:28:05 GMT Wols Lists wrote:


Statistics is one of those areas where, if you don't know what you're
doing and you use the wrong maths, then you are going to get stupid results.

"Statistics tell you how to get from A to B. What they don't tell you is
that you're all at C".


I took a module on statistics in my Open University maths degree 40-odd years
ago. I was bemused. They seemed to say that the subject was founded on two
basic principles; then they proceeded to define each of them in terms of the
other.

Weird! I took a module on statistics in my Open University (Chemistry) 
degree 40-odd years ago. Probably the same one? I've still got the 
modules as a reference work, though I probably couldn't lay my hands on 
them easily now ...



I'm still waiting for the entire edifice to come crashing down around our ears.
:)

Nah - it's been abused for so long nobody's noticed it came down 
centuries ago :-)


Cheers,
Wol

Re: [gentoo-user] Emerge load again

[Wols Lists]

On 06/01/2024 17:52, Peter Humphrey wrote:

In other cases, there may be a hundred separate tasks, make fires off a
hundred tasks shared amongst all the resource it can find, and sits back
and waits.



And that's how the very first installation goes, with single-host distcc. Then,
when it gets to gcc, it collapses to 2 threads and everything gained so far is
lost many-fold. (I set USE=-fortran to avoid pointless recompilation, since
nothing needs it here.)


So if it's consistently gcc that collapses to two threads, then 
something (maybe explicit settings, maybe dependencies, maybe yadda 
yadda) is telling make that only two jobs can run at the same time else 
they'll trip over each other.


Could be a dev has hard-coded the "two jobs" rule to make those random 
crashes go away :-) Or maybe they found the problem, and that's why only 
two jobs can run in parallel.


Cheers,
Wol