from:"Patrick"

From: Greg McGary 

Add option -m(no-)autovec-segment to enable/disable autovectorizer
from emitting vector segment load/store instructions. This is useful for
performance experiments.

gcc/ChangeLog:
* config/riscv/autovec.md (vec_mask_len_load_lanes, 
vec_mask_len_store_lanes):
  Predicate with TARGET_VECTOR_AUTOVEC_SEGMENT
* gcc/config/riscv/riscv-opts.h (TARGET_VECTOR_AUTOVEC_SEGMENT): New 
macro.
* gcc/config/riscv/riscv.opt (-m(no-)autovec-segment): New option.
* testsuite/gcc.target/riscv/rvv/autovec/struct/*_noseg*.c,
testsuite/gcc.target/riscv/rvv/autovec/no-segment.c: New tests.

Tested-by: Edwin Lu 
---
Added tested-by on Vineet's recommendation. Please wait for riscv precommit to
finish before committing.

v3 changelog:
Use dg-ice to expect the no-segment.c ICE.
Converted remaining testcases to use -mrvv-vector-bits=_.
---
 gcc/config/riscv/autovec.md   |  4 +-
 gcc/config/riscv/riscv-opts.h |  5 ++
 gcc/config/riscv/riscv.opt|  4 ++
 .../gcc.target/riscv/rvv/autovec/no-segment.c | 62 +++
 .../autovec/struct/mask_struct_load_noseg-1.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-2.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-3.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-4.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-5.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-6.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-7.c |  6 ++
 .../struct/mask_struct_load_noseg_run-1.c |  4 ++
 .../struct/mask_struct_load_noseg_run-2.c |  4 ++
 .../struct/mask_struct_load_noseg_run-3.c |  4 ++
 .../struct/mask_struct_load_noseg_run-4.c |  4 ++
 .../struct/mask_struct_load_noseg_run-5.c |  4 ++
 .../struct/mask_struct_load_noseg_run-6.c |  4 ++
 .../struct/mask_struct_load_noseg_run-7.c |  4 ++
 .../struct/mask_struct_store_noseg-1.c|  6 ++
 .../struct/mask_struct_store_noseg-2.c|  6 ++
 .../struct/mask_struct_store_noseg-3.c|  6 ++
 .../struct/mask_struct_store_noseg-4.c|  6 ++
 .../struct/mask_struct_store_noseg-5.c|  6 ++
 .../struct/mask_struct_store_noseg-6.c|  6 ++
 .../struct/mask_struct_store_noseg-7.c|  6 ++
 .../struct/mask_struct_store_noseg_run-1.c|  4 ++
 .../struct/mask_struct_store_noseg_run-2.c|  4 ++
 .../struct/mask_struct_store_noseg_run-3.c|  4 ++
 .../struct/mask_struct_store_noseg_run-4.c|  4 ++
 .../struct/mask_struct_store_noseg_run-5.c|  4 ++
 .../struct/mask_struct_store_noseg_run-6.c|  4 ++
 .../struct/mask_struct_store_noseg_run-7.c|  4 ++
 .../rvv/autovec/struct/struct_vect_noseg-1.c  |  8 +++
 .../rvv/autovec/struct/struct_vect_noseg-10.c |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-11.c |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-12.c |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-13.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-14.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-15.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-16.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-17.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-18.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-2.c  |  8 +++
 .../rvv/autovec/struct/struct_vect_noseg-3.c  |  8 +++
 .../rvv/autovec/struct/struct_vect_noseg-4.c  |  8 +++
 .../rvv/autovec/struct/struct_vect_noseg-5.c  |  8 +++
 .../rvv/autovec/struct/struct_vect_noseg-6.c  |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-7.c  |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-8.c  |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-9.c  |  7 +++
 .../autovec/struct/struct_vect_noseg_run-1.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-10.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-11.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-12.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-13.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-14.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-15.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-16.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-17.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-18.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-2.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-3.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-4.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-5.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-6.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-7.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-8.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-9.c  |  4 ++
 68 files changed, 410 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/no-segment.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg-1.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg-2.c
 create

[PATCH v3 2/2] Prevent divide-by-zero

From: Greg McGary 

gcc/ChangeLog:
* gcc/tree-vect-stmts.cc (gcc/tree-vect-stmts.cc): Prevent 
divide-by-zero.
* testsuite/gcc.target/riscv/rvv/autovec/no-segment.c: Remove dg-ice.
---
No changes in v3. Depends on the risc-v backend option added in patch 1 to
trigger the ICE.
---
 gcc/testsuite/gcc.target/riscv/rvv/autovec/no-segment.c | 1 -
 gcc/tree-vect-stmts.cc  | 3 ++-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/no-segment.c 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/no-segment.c
index dfbe09f01a1..79d03612a22 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/no-segment.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/no-segment.c
@@ -1,6 +1,5 @@
 /* { dg-do compile } */
 /* { dg-options "-march=rv64gcv -mabi=lp64d -mrvv-vector-bits=scalable -O3 
-mno-autovec-segment" } */
-/* { dg-ice "Floating point exception" } */

 enum e { c, d };
 enum g { f };
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index 4219ad832db..34f5736ba00 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -11558,7 +11558,8 @@ vectorizable_load (vec_info *vinfo,
 - (vec_num * j + i) * nunits);
/* remain should now be > 0 and < nunits.  */
unsigned num;
-   if (constant_multiple_p (nunits, remain, ))
+   if (known_gt (remain, 0)
+   && constant_multiple_p (nunits, remain, ))
  {
tree ptype;
new_vtype
--
2.43.2

[PATCH v3 0/2] RISC-V: add option -m(no-)autovec-segment

Sending v3 to fixup testsuite issues and whitespace linter issue.

v2 changelog:
Rebased to squash Edwin's fixup into Greg's patch. Split out the middle-end
change and xfailed the associated testcase so the second patch can land
seperately.

Relying on pre-commit CI for full testing.

v3 changelog:
Use dg-ice to xfail the no-segment.c testcase properly.
Converted remaining testcases to use -mrvv-vector-bits=_.

Greg McGary (2):
  RISC-V: add option -m(no-)autovec-segment
  Prevent divide-by-zero

 gcc/config/riscv/autovec.md   |  4 +-
 gcc/config/riscv/riscv-opts.h |  5 ++
 gcc/config/riscv/riscv.opt|  4 ++
 .../gcc.target/riscv/rvv/autovec/no-segment.c | 61 +++
 .../autovec/struct/mask_struct_load_noseg-1.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-2.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-3.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-4.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-5.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-6.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-7.c |  6 ++
 .../struct/mask_struct_load_noseg_run-1.c |  4 ++
 .../struct/mask_struct_load_noseg_run-2.c |  4 ++
 .../struct/mask_struct_load_noseg_run-3.c |  4 ++
 .../struct/mask_struct_load_noseg_run-4.c |  4 ++
 .../struct/mask_struct_load_noseg_run-5.c |  4 ++
 .../struct/mask_struct_load_noseg_run-6.c |  4 ++
 .../struct/mask_struct_load_noseg_run-7.c |  4 ++
 .../struct/mask_struct_store_noseg-1.c|  6 ++
 .../struct/mask_struct_store_noseg-2.c|  6 ++
 .../struct/mask_struct_store_noseg-3.c|  6 ++
 .../struct/mask_struct_store_noseg-4.c|  6 ++
 .../struct/mask_struct_store_noseg-5.c|  6 ++
 .../struct/mask_struct_store_noseg-6.c|  6 ++
 .../struct/mask_struct_store_noseg-7.c|  6 ++
 .../struct/mask_struct_store_noseg_run-1.c|  4 ++
 .../struct/mask_struct_store_noseg_run-2.c|  4 ++
 .../struct/mask_struct_store_noseg_run-3.c|  4 ++
 .../struct/mask_struct_store_noseg_run-4.c|  4 ++
 .../struct/mask_struct_store_noseg_run-5.c|  4 ++
 .../struct/mask_struct_store_noseg_run-6.c|  4 ++
 .../struct/mask_struct_store_noseg_run-7.c|  4 ++
 .../rvv/autovec/struct/struct_vect_noseg-1.c  |  8 +++
 .../rvv/autovec/struct/struct_vect_noseg-10.c |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-11.c |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-12.c |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-13.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-14.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-15.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-16.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-17.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-18.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-2.c  |  8 +++
 .../rvv/autovec/struct/struct_vect_noseg-3.c  |  8 +++
 .../rvv/autovec/struct/struct_vect_noseg-4.c  |  8 +++
 .../rvv/autovec/struct/struct_vect_noseg-5.c  |  8 +++
 .../rvv/autovec/struct/struct_vect_noseg-6.c  |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-7.c  |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-8.c  |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-9.c  |  7 +++
 .../autovec/struct/struct_vect_noseg_run-1.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-10.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-11.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-12.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-13.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-14.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-15.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-16.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-17.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-18.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-2.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-3.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-4.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-5.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-6.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-7.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-8.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-9.c  |  4 ++
 gcc/tree-vect-stmts.cc|  3 +-
 69 files changed, 411 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/no-segment.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg-1.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg-2.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg-3.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg-4.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg-5.c
 create mode 100644

Re: [blink-dev] Intent to Extend Experiment: Compression Dictionary Transport

2024-05-29 Thread Patrick Meenan

Sorry, probably some confusion with the process.

This is for the 3rd round of OT on the platform status entry
(CompressionDictionaryTransportV3) so "extend" may not be the right
terminology.  V1 really ended at 122 and we had the same confusion the last
time around and the V2 trial was created that went from 123-125 (and is the
current active trial).

I'll leave it to Tsuyoshi so I don't accidentally break anything, but I
assume we need to mark the v3 trial as the active stage.

On Wed, May 29, 2024 at 7:16 PM Panos Astithas  wrote:

> Hi Tsuyoshi,
>
> Is this a request to extend the V1 OT as it appears in Chromestatus and in
> the title of this thread or are you trying to create a new V3 trial as it
> seems to be the intent based on the content of your intent? Note that V1
> ended at M125, so teh extension would be for 4 milestones.
>
> On Wed, May 29, 2024 at 10:22 AM Mike Taylor 
> wrote:
>
>> Thanks all. LGTM to extend from 127 to 129 inclusive.
>> On 5/29/24 10:51 AM, Patrick Meenan wrote:
>>
>> On the spec side of things, there is one more issue outstanding in the
>> IETF discussion but it's not API-impacting and we expect that this latest
>> draft
>> <https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/04/>,
>> which this OT implements, has the final API shape. There will be some
>> tweaks around the edges as we go through the final steps of the RFC process
>> but the V3 OT will give sites something to test against that matches what
>> we expect to ship.
>>
>> There are some fairly substantial changes from the previous OT that it
>> would be useful to get feedback on. In particular, the change to the file
>> format that embeds the dictionary hash into the file itself instead of
>> being a separate response header.
>>
>> On Wed, May 29, 2024 at 10:37 AM Yoav Weiss (@Shopify) <
>> yoavwe...@chromium.org> wrote:
>>
>>>
>>>
>>> On Wed, May 29, 2024 at 4:31 PM Mike Taylor 
>>> wrote:
>>>
>>>> Hi there,
>>>>
>>>> Would you mind commenting on progress for the following items, per OT
>>>> renewal guidelines:
>>>>
>>> 
>>>
>>>> Draft spec (early draft is ok, but must be spec-like and associated
>>>> with the appropriate standardization venue, or WICG)
>>>>
>>> Recently published
>>> <https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/>
>>>  with
>>> above-mentioned changes.
>>> +Patrick Meenan  can probably add precision there,
>>> but it's making good progress in the HTTPWG.
>>>
>>> TAG review (see exceptions)
>>>>
>>> https://github.com/w3ctag/design-reviews/issues/877
>>>
>>>> bit.ly/blink-signals requests
>>>>
>>> Both Mozilla <https://github.com/mozilla/standards-positions/issues/771>
>>> and WebKit <https://github.com/WebKit/standards-positions/issues/160>
>>> are positive (with ongoing discussion about some details with Mozilla
>>> folks).
>>>
>>>> Outreach for feedback from the spec community
>>>>
>>> Regular HTTPWG and WebPerfWG engagement.
>>>
>>>> WPT tests
>>>>
>>>
>>> https://wpt.fyi/results/fetch/compression-dictionary?label=experimental=master
>>>
>>>
>>>> thanks,
>>>> Mike
>>>> On 5/28/24 5:59 AM, Tsuyoshi Horo wrote:
>>>>
>>>> Contact emails
>>>>
>>>> h...@chromium.org, pmee...@chromium.org, yoavwe...@chromium.org,
>>>> kenjibah...@chromium.org, denom...@chromium.org
>>>>
>>>>
>>>> Explainer
>>>>
>>>> https://github.com/WICG/compression-dictionary-transport
>>>>
>>>>
>>>> Specification
>>>>
>>>>
>>>> https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/
>>>>
>>>>
>>>> Design docs
>>>>
>>>>
>>>> https://docs.google.com/document/d/1IcRHLv-e9boECgPA5J4t8NDv9FPHDGgn0C12kfBgANg/edit
>>>>
>>>> https://github.com/WICG/compression-dictionary-transport
>>>>
>>>>
>>>> https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/
>>>>
>>>>
>>>> Summary
>>>>
>>>> We are running the second round of the Origin Trial until Chrome 125.
>>>> The design of the feature has also evolved d

[gentoo-commits] repo/gentoo:master commit in: app-admin/salt/

2024-05-29 Thread Patrick McLean

commit: 48cec285139b07e307428d117f5dc2b02db5dde2
Author: Patrick McLean  gentoo  org>
AuthorDate: Wed May 29 22:05:56 2024 +
Commit:     Patrick McLean  gentoo  org>
CommitDate: Wed May 29 22:05:56 2024 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=48cec285

app-admin/salt: add 3007.1

Signed-off-by: Patrick McLean  gentoo.org>

 app-admin/salt/Manifest   |   1 +
 app-admin/salt/salt-3007.1.ebuild | 611 ++
 2 files changed, 612 insertions(+)

diff --git a/app-admin/salt/Manifest b/app-admin/salt/Manifest
index 779c5a6e36ea..e2718884de8b 100644
--- a/app-admin/salt/Manifest
+++ b/app-admin/salt/Manifest
@@ -2,3 +2,4 @@ DIST salt-3005.5.tar.gz 17940104 BLAKE2B 
c7a820bc946c2cd8124fb6f559608ab1dc3cd85
 DIST salt-3006.5.tar.gz 20536455 BLAKE2B 
cf475dc5e919f6ab180578db2aae5f3655623b39b134d67609da4f607be909340c6e55c940cfb66f129cc75d40b5cdda094e866db116d8a45aa5eef26d8fa1eb
 SHA512 
8aaf5c5d36d8aa17b3fe867cee470f7b3c5dd1f6abaf5bdb49a3df76d3498d0dc1fa305a069bc95ad057489db229454b38b0ea9c1ade1e46b5d9b57aeef10c23
 DIST salt-3006.7.tar.gz 20562663 BLAKE2B 
b4ff9039509b1de7151060cb0e68252868d493e114e327a3c48bfc5584f67521a2106b41b77377f6d43ab5795399b6fe5860ce8e091459687c4a5b2378752729
 SHA512 
9d1759a7c0dfc9ad4fdc94460f0f3799483737207bfdc8ddd1424e5c6083ea74ef520f13c323d5cbd7f65c1d9bb13bbbeb5f2cafe6dcacbc2689e733794aef2d
 DIST salt-3007.0.tar.gz 20304228 BLAKE2B 
3db95ce779cfd08d61536dcfb4ff6ac31788ad1d6d4665b640dcc430f5a33847f231f94fd574c5d8df7b14e2854511c80610a37cd19be5429c4643be8bd9e0eb
 SHA512 
0e49d76dafdb981ee380ea89ceba2cddeae8cd95df1d188a6f8ba64a175c606aaf2f8101bacb040792255afdb46ae668cbc9464d0dbb055986e85cee4d5c130b
+DIST salt-3007.1.tar.gz 19401831 BLAKE2B 
ea8c89a24991467367dc0c50e3d2f864e2f6211ba9a71195d6308a86df16229fc77baa2ec837f043ebad36d9d7a6673fefa3a1a826472d900925e657e2152718
 SHA512 
732820bae98ce2eb74175a2c37c986076572e0e60d04a270861fd3b0b6871cd2cc703683a8c0d97ffc43b2f7fffb76ae709a1aea839d10abc9f5d0837eaade4b

diff --git a/app-admin/salt/salt-3007.1.ebuild 
b/app-admin/salt/salt-3007.1.ebuild
new file mode 100644
index ..d8b9533aac5e
--- /dev/null
+++ b/app-admin/salt/salt-3007.1.ebuild
@@ -0,0 +1,611 @@
+# Copyright 1999-2024 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=8
+PYTHON_COMPAT=( python3_1{0..2} )
+
+DISTUTILS_USE_PEP517=setuptools
+inherit systemd distutils-r1
+
+DESCRIPTION="Salt is a remote execution and configuration manager"
+HOMEPAGE="https://www.saltstack.com/resources/community/
+   https://github.com/saltstack;
+
+if [[ ${PV} == * ]]; then
+   inherit git-r3
+   EGIT_REPO_URI="https://github.com/${PN}stack/${PN}.git;
+   EGIT_BRANCH="develop"
+else
+   inherit pypi
+   KEYWORDS="~amd64 ~riscv ~x86"
+fi
+
+LICENSE="Apache-2.0"
+SLOT="0"
+IUSE="
+   cheetah cherrypy ldap libcloud libvirt genshi gnupg keyring mako
+   mongodb neutron nova portage profile redis selinux test raet
+   +zeromq vim-syntax
+"
+
+RDEPEND="
+   sys-apps/pciutils
+   dev-libs/openssl:0=[-bindist(-)]
+   dev-python/aiohttp[${PYTHON_USEDEP}]
+   >=dev-python/cherrypy-18.6.1[${PYTHON_USEDEP}]
+   >=dev-python/cryptography-42.0.0[${PYTHON_USEDEP}]
+   >=dev-python/distro-1.5[${PYTHON_USEDEP}]
+   dev-python/importlib-metadata[${PYTHON_USEDEP}]
+   >=dev-python/jinja-3.1.3[${PYTHON_USEDEP}]
+   dev-python/jmespath[${PYTHON_USEDEP}]
+   dev-python/libnacl[${PYTHON_USEDEP}]
+   dev-python/looseversion[${PYTHON_USEDEP}]
+   >=dev-python/msgpack-1.0.0[${PYTHON_USEDEP}]
+   >=dev-python/packaging-21.3[${PYTHON_USEDEP}]
+   >=dev-python/psutil-5.0.0[${PYTHON_USEDEP}]
+   >=dev-python/pycryptodome-3.19.1[${PYTHON_USEDEP}]
+   >=dev-python/pyopenssl-24.0.0[${PYTHON_USEDEP}]
+   >=dev-python/python-dateutil-2.8.1[${PYTHON_USEDEP}]
+   dev-python/python-gnupg[${PYTHON_USEDEP}]
+   >=dev-python/pyyaml-6.0.1[${PYTHON_USEDEP}]
+   >=dev-python/markupsafe-2.1.2[${PYTHON_USEDEP}]
+   >=dev-python/requests-2.31.0[${PYTHON_USEDEP}]
+   dev-python/setproctitle[${PYTHON_USEDEP}]
+   dev-python/setuptools[${PYTHON_USEDEP}]
+   dev-python/tomli[${PYTHON_USEDEP}]
+   dev-python/tornado[${PYTHON_USEDEP}]
+   dev-python/watchdog[${PYTHON_USEDEP}]
+   libcloud? (
+   >=dev-python/aiohttp-3.9.0[${PYTHON_USEDEP}]
+   dev-python/aiosignal[${PYTHON_USEDEP}]
+   >=dev-python/apache-libcloud-2.5.0[${PYTHON_USEDEP}]
+   dev-python/async-timeout[${PYTHON_USEDEP}]
+   )
+   mako? ( dev-python/mako[${PYTHON_USEDEP}] )
+   ldap? ( dev-python/python-ldap[${PYTHON_USEDEP}] )
+   libvirt? (
+   dev-python/libvirt-python[${PYTHON_USEDEP}]
+   )
+

Re: [PATCH v2 2/2] Prevent divide-by-zero



On 5/29/24 00:20, Richard Biener wrote:

On Wed, May 29, 2024 at 1:39 AM Patrick O'Neill  wrote:

From: Greg McGary

gcc/ChangeLog:
 * gcc/tree-vect-stmts.cc (gcc/tree-vect-stmts.cc): Prevent 
divide-by-zero.
 * testsuite/gcc.target/riscv/rvv/autovec/no-segment.c: Remove xfail.
---
  gcc/testsuite/gcc.target/riscv/rvv/autovec/no-segment.c | 1 -
  gcc/tree-vect-stmts.cc  | 3 ++-
  2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/no-segment.c 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/no-segment.c
index fd996a27501..79d03612a22 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/no-segment.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/no-segment.c
@@ -1,6 +1,5 @@
  /* { dg-do compile } */
  /* { dg-options "-march=rv64gcv -mabi=lp64d -mrvv-vector-bits=scalable -O3 
-mno-autovec-segment" } */
-/* { xfail *-*-* } */

  enum e { c, d };
  enum g { f };
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index 4219ad832db..34f5736ba00 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -11558,7 +11558,8 @@ vectorizable_load (vec_info *vinfo,
  - (vec_num * j + i) * nunits);
 /* remain should now be > 0 and < nunits.  */

^^^


 unsigned num;
-   if (constant_multiple_p (nunits, remain, ))
+   if (known_gt (remain, 0)

So this shouldn't happen.  Do you have a testcase where this triggers?
If < nunits doesn't hold things will also go wrong.


This ICE appears after patch 1 of the series is applied with the testcase:
testsuite/gcc.target/riscv/rvv/autovec/no-segment.c

Executing on host: 
/home/runner/work/gcc-precommit-ci/gcc-precommit-ci/riscv-gnu-toolchain/build/build-gcc-linux-stage2/gcc/xgcc
 
-B/home/runner/work/gcc-precommit-ci/gcc-precommit-ci/riscv-gnu-toolchain/build/build-gcc-linux-stage2/gcc/
  
/home/runner/work/gcc-precommit-ci/gcc-precommit-ci/riscv-gnu-toolchain/gcc/gcc/testsuite/gcc.target/riscv/rvv/autovec/no-segment.c
  -march=rv64gc_zba_zbb_zbc_zbs -mabi=lp64d -mcmodel=medlow   
-fdiagnostics-plain-output  -O3 -ftree-vectorize -march=rv64gcv -mabi=lp64d 
-mrvv-vector-bits=scalable -O3 -mno-autovec-segment -S   -o no-segment.s    
(timeout = 600)
spawn -ignore SIGHUP 
/home/runner/work/gcc-precommit-ci/gcc-precommit-ci/riscv-gnu-toolchain/build/build-gcc-linux-stage2/gcc/xgcc
 
-B/home/runner/work/gcc-precommit-ci/gcc-precommit-ci/riscv-gnu-toolchain/build/build-gcc-linux-stage2/gcc/
 
/home/runner/work/gcc-precommit-ci/gcc-precommit-ci/riscv-gnu-toolchain/gcc/gcc/testsuite/gcc.target/riscv/rvv/autovec/no-segment.c
 -march=rv64gc_zba_zbb_zbc_zbs -mabi=lp64d -mcmodel=medlow 
-fdiagnostics-plain-output -O3 -ftree-vectorize -march=rv64gcv -mabi=lp64d 
-mrvv-vector-bits=scalable -O3 -mno-autovec-segment -S -o no-segment.s
during GIMPLE pass: vect
/home/runner/work/gcc-precommit-ci/gcc-precommit-ci/riscv-gnu-toolchain/gcc/gcc/testsuite/gcc.target/riscv/rvv/autovec/no-segment.c:
 In function 'ClutImageChannel':
/home/runner/work/gcc-precommit-ci/gcc-precommit-ci/riscv-gnu-toolchain/gcc/gcc/testsuite/gcc.target/riscv/rvv/autovec/no-segment.c:45:1:
 internal compiler error: Floating point exception
0x13e06b3 crash_signal
    ../../../gcc/gcc/toplev.cc:319
0x2840977 poly_int<2u, poly_result::result_kind>::type> operator-<2u, unsigned long, unsigned long>(poly_int<2u, unsigned long> 
const&, poly_int<2u, unsigned long> const&)
    ../../../gcc/gcc/poly-int.h:871
0x2840977 vectorizable_load
    ../../../gcc/gcc/tree-vect-stmts.cc:11558
0x284da2d vect_transform_stmt(vec_info*, _stmt_vec_info*, 
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
    ../../../gcc/gcc/tree-vect-stmts.cc:13416
0x16a00ce vect_transform_loop_stmt
    ../../../gcc/gcc/tree-vect-loop.cc:11618
0x16ca4f2 vect_transform_loop(_loop_vec_info*, gimple*)
    ../../../gcc/gcc/tree-vect-loop.cc:12144
0x1712a8d vect_transform_loops
    ../../../gcc/gcc/tree-vectorizer.cc:1006
0x17131c3 try_vectorize_loop_1
    ../../../gcc/gcc/tree-vectorizer.cc:1152
0x17131c3 try_vectorize_loop
    ../../../gcc/gcc/tree-vectorizer.cc:1182
0x17137fc execute
    ../../../gcc/gcc/tree-vectorizer.cc:1298
Please submit a full bug report, with preprocessed source (by using 
-freport-bug).
Please include the complete backtrace with any bug report.
See<https://gcc.gnu.org/bugs/>  for instructions.
compiler exited with status 1

Greg created this patch as a fix for that ICE so I'm guessing it was 
root-caused to be a nunits == 0 divide-by-zero.


@Greg McGary is the author of this patch and would know best.

Patrick



Richard.



+   && constant_multiple_p (nunits, remain, ))
   {
 tree ptype;
 new_vtype
--
2.43.2

Console consumer crashing

2024-05-29 Thread Patrick G. Heck

Hi folks,

I was troubleshooting a program trying to receive a kafka message (local
kafka, for development), and decided I needed to verify kafka itself was
happy. So I created a topic named 'fubar' and started the consumer
listening to it. Then I started the console producer in another terminal
window and typed in foo and it appeared nicely on the consumer
terminal. Then I typed bar and got this:

NS2-MacBook-Pro:kafka_2.13-3.7.0 gus$ bin/kafka-console-consumer.sh
--bootstrap-server localhost:9092 --topic fubar --from-beginning

foo

[2024-05-29 11:56:07,183] ERROR Error processing message, terminating
consumer process:  (kafka.tools.ConsoleConsumer$)

org.apache.kafka.common.protocol.types.SchemaException: Buffer underflow
while parsing response for request with header RequestHeader(apiKey=FETCH,
apiVersion=16, clientId=console-consumer, correlationId=608,
headerVersion=2)

at
org.apache.kafka.clients.NetworkClient.parseResponse(NetworkClient.java:758)

at
org.apache.kafka.clients.NetworkClient.handleCompletedReceives(NetworkClient.java:929)

at org.apache.kafka.clients.NetworkClient.poll(NetworkClient.java:594)

at
org.apache.kafka.clients.consumer.internals.ConsumerNetworkClient.poll(ConsumerNetworkClient.java:281)

at
org.apache.kafka.clients.consumer.internals.ConsumerNetworkClient.poll(ConsumerNetworkClient.java:252)

at
org.apache.kafka.clients.consumer.internals.LegacyKafkaConsumer.pollForFetches(LegacyKafkaConsumer.java:686)

at
org.apache.kafka.clients.consumer.internals.LegacyKafkaConsumer.poll(LegacyKafkaConsumer.java:617)

at
org.apache.kafka.clients.consumer.internals.LegacyKafkaConsumer.poll(LegacyKafkaConsumer.java:590)

at
org.apache.kafka.clients.consumer.KafkaConsumer.poll(KafkaConsumer.java:874)

at
kafka.tools.ConsoleConsumer$ConsumerWrapper.receive(ConsoleConsumer.scala:473)

at kafka.tools.ConsoleConsumer$.process(ConsoleConsumer.scala:103)

at kafka.tools.ConsoleConsumer$.run(ConsoleConsumer.scala:77)

at kafka.tools.ConsoleConsumer$.main(ConsoleConsumer.scala:54)

at kafka.tools.ConsoleConsumer.main(ConsoleConsumer.scala)

Caused by: java.nio.BufferUnderflowException

at java.base/java.nio.Buffer.nextGetIndex(Buffer.java:651)

at java.base/java.nio.HeapByteBuffer.getInt(HeapByteBuffer.java:402)

at
org.apache.kafka.common.protocol.ByteBufferAccessor.readInt(ByteBufferAccessor.java:43)

at
org.apache.kafka.common.message.ResponseHeaderData.read(ResponseHeaderData.java:90)

at
org.apache.kafka.common.message.ResponseHeaderData.(ResponseHeaderData.java:66)

at
org.apache.kafka.common.requests.ResponseHeader.parse(ResponseHeader.java:100)

at
org.apache.kafka.common.requests.AbstractResponse.parseResponse(AbstractResponse.java:100)

at
org.apache.kafka.clients.NetworkClient.parseResponse(NetworkClient.java:756)

... 13 more

[2024-05-29 11:56:07,183] ERROR [Consumer clientId=console-consumer,
groupId=console-consumer-59661] Heartbeat thread failed due to unexpected
error (org.apache.kafka.clients.consumer.internals.ConsumerCoordinator)

java.lang.IllegalStateException: There are no in-flight requests for node 0

at
org.apache.kafka.clients.InFlightRequests.requestQueue(InFlightRequests.java:62)

at
org.apache.kafka.clients.InFlightRequests.completeNext(InFlightRequests.java:70)

at
org.apache.kafka.clients.NetworkClient.handleCompletedReceives(NetworkClient.java:927)

at org.apache.kafka.clients.NetworkClient.poll(NetworkClient.java:594)

at
org.apache.kafka.clients.consumer.internals.ConsumerNetworkClient.poll(ConsumerNetworkClient.java:281)

at
org.apache.kafka.clients.consumer.internals.ConsumerNetworkClient.pollNoWakeup(ConsumerNetworkClient.java:322)

at
org.apache.kafka.clients.consumer.internals.AbstractCoordinator$HeartbeatThread.run(AbstractCoordinator.java:1490)

Processed a total of 1 messages

NS2-MacBook-Pro:kafka_2.13-3.7.0 gus$


Any idea what's happening? Certainly doesn't look copacetic.

Producer was started like this:

NS2-MacBook-Pro:kafka_2.13-3.7.0 gus$ bin/kafka-topics.sh --list
--bootstrap-server localhost:9092

__consumer_offsets

fubar

NS2-MacBook-Pro:kafka_2.13-3.7.0 gus$ bin/kafka-console-producer.sh
--bootstrap-server localhost:9092 --topic fubar

>foo

>bar

>

-Gus

Founder, Chief Architect, Needham Software LLC
Commiter & PMC member Apache Solr & Apache Lucene
508-333-5312
https://www.needhamsoftware.com

Re: [blink-dev] Intent to Extend Experiment: Compression Dictionary Transport

2024-05-29 Thread 'Patrick Meenan' via blink-dev

On the spec side of things, there is one more issue outstanding in the IETF
discussion but it's not API-impacting and we expect that this latest draft
<https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/04/>,
which this OT implements, has the final API shape. There will be some
tweaks around the edges as we go through the final steps of the RFC process
but the V3 OT will give sites something to test against that matches what
we expect to ship.

There are some fairly substantial changes from the previous OT that it
would be useful to get feedback on. In particular, the change to the file
format that embeds the dictionary hash into the file itself instead of
being a separate response header.

On Wed, May 29, 2024 at 10:37 AM Yoav Weiss (@Shopify) <
yoavwe...@chromium.org> wrote:

>
>
> On Wed, May 29, 2024 at 4:31 PM Mike Taylor 
> wrote:
>
>> Hi there,
>>
>> Would you mind commenting on progress for the following items, per OT
>> renewal guidelines:
>>
> 
>
>> Draft spec (early draft is ok, but must be spec-like and associated with
>> the appropriate standardization venue, or WICG)
>>
> Recently published
> <https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/> 
> with
> above-mentioned changes.
> +Patrick Meenan  can probably add precision there,
> but it's making good progress in the HTTPWG.
>
> TAG review (see exceptions)
>>
> https://github.com/w3ctag/design-reviews/issues/877
>
>> bit.ly/blink-signals requests
>>
> Both Mozilla <https://github.com/mozilla/standards-positions/issues/771>
> and WebKit <https://github.com/WebKit/standards-positions/issues/160> are
> positive (with ongoing discussion about some details with Mozilla folks).
>
>> Outreach for feedback from the spec community
>>
> Regular HTTPWG and WebPerfWG engagement.
>
>> WPT tests
>>
>
> https://wpt.fyi/results/fetch/compression-dictionary?label=experimental=master
>
>
>> thanks,
>> Mike
>> On 5/28/24 5:59 AM, Tsuyoshi Horo wrote:
>>
>> Contact emails
>>
>> h...@chromium.org, pmee...@chromium.org, yoavwe...@chromium.org,
>> kenjibah...@chromium.org, denom...@chromium.org
>>
>>
>> Explainer
>>
>> https://github.com/WICG/compression-dictionary-transport
>>
>>
>> Specification
>>
>>
>> https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/
>>
>>
>> Design docs
>>
>>
>> https://docs.google.com/document/d/1IcRHLv-e9boECgPA5J4t8NDv9FPHDGgn0C12kfBgANg/edit
>>
>> https://github.com/WICG/compression-dictionary-transport
>>
>>
>> https://datatracker.ietf.org/doc/draft-ietf-httpbis-compression-dictionary/
>>
>>
>> Summary
>>
>> We are running the second round of the Origin Trial until Chrome 125. The
>> design of the feature has also evolved during the origin trial and RFC
>> process. We’d like to run a third round of the Origin Trial to get more
>> feedback on the updated
>> <https://chromium.googlesource.com/chromium/src/+/d934bf37456735d9bc03107c577804f439f8a986/docs/experiments/compression-dictionary-transport.md#changes-in-m127>
>> design.
>>
>>
>> Blink component
>>
>> Blink>Network
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3ENetwork>
>>
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/877
>> TAG review status
>>
>> Closed
>> Risks Interoperability and Compatibility
>>
>> Interoperability and Compatibility risk are low. This feature introduces
>> a new compression method for transporting resources over HTTP. Web sites
>> can know the browser support for the new feature by checking
>> `document.createElement('link').relList.supports('compression-dictionary')`.
>> The feature is a negotiation between servers and clients that involves a
>> server specifying that a resource should be used as a dictionary for future
>> requests with a ‘Use-As-Dictionary’ response header. Clients that don’t
>> support the feature will ignore the header and nothing further will happen.
>>
>> This feature is an opt-in feature. And the dictionary storage is isolated
>> using the top level site and the frame origin as the key. That means, if
>> there is no dictionary registered for the site, the behavior of Chrome will
>> not change while browsing the site. Also this feature is only usable within
>> a secure-context so this feature will not increase the risk of having
>> network proxies meddle with the content’

Re: 2 installations on the same PC - Add partition in Ftab

2024-05-29 Thread Patrick O'Callaghan

On Wed, 2024-05-29 at 01:24 -0300, soles.g wrote:
> Así se monta cuando lo monto desde Dolphin
> 
> This is how it is set up when I mount it from Dolphin
> 
> > soles_40@garibaldina-40:/run/media/soles_40/desde_fedora_37$
> 
> porque desde la terminal no me deja de ninguna manera:
> 
> because from the terminal it won't let me in any way:
> 
> soles_40@garibaldina-40:~$ sudo mount -n /dev/sda7 
> /run/media/soles_40/desde_fedora_37
> mount: /run/media/soles_40/desde_fedora_37: mount point does not
> exist.
>    dmesg(1) may have more information after failed mount system
> call.

As others have said, Dolphin is using a temporary mount point (under
/run/media, which is used for removable media). To mount the drive
permanently you should create a permanent mount point somewhere else,
e.g. as /Fedora47, and put that in /etc/fstab.

   Como dicen otras respuestas, Dolphin está creando un punto de
   montaje temporal bajo /run/media (esto lo hace para los medios
   removibles). Para montarlo en forma permanente, es mejor crear un
   punto de montaje en otro sitio, por ejemplo como /Fedora47, y poner
   eso en /etc/fstab.

poc
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [PATCH] Makefile: Fix include directory for OF_UPSTREAM

2024-05-29 Thread Patrick Barsanti

Hi Sumit,

On Wed, 29 May 2024 at 08:57, Sumit Garg  wrote:

> Hi Patrick,
>
> On Tue, 28 May 2024 at 14:16, Patrick Barsanti
>  wrote:
> >
> > Always prioritizing u-boot includes causes problems when trying to
> > migrate boards to OF_UPSTREAM that have divergent devicetree files with
> > respect to the upstream ones.
> >
> > For example, migrating a board based on `imx6ul.dtsi` to OF_UPSTREAM
> > breaks it, as there are some missing defines in the local dtsi file;
> > the solutions would be to either patch it, which defeats the purpose of
> > OF_UPSTREAM, or delete it entirely. This last option would then break all
> > the other boards which have not yet been migrated to OF_UPSTREAM.
>
> Can you elaborate more here regarding which dt-bindings headers
> conflict? Also, is it only the DTS files consumer for those headers or
> there are U-Boot drivers depending on them too?
>
> -Sumit
>

Sorry, I think I have worded my commit message wrong. I should
have used differ instead of diverge, which is slightly misleading.

The specific case I am talking about can be found in:
include/dt-bindings/clock/imx6ul-clock.h
dts/upstream/include/dt-bindings/clock/imx6ul-clock.h

The local header is missing the last commit from the kernel, which is
4e197ee880c2 ("clk: imx6ul: add ethernet refclock mux support").
This added some new defines, which are not present in the u-boot
header.
Following this commit, the `imx6ul.dtsi` was patched in the kernel to
use one of the new defines.

Because of this, at the current state, migrating a board which is
somehow based on `imx6ul.dtsi` will give a dtc error given by a value
being used in the upstream dtsi which is not defined in the local
header, because local includes always have priority with respect
to upstream ones even when setting OF_UPSTREAM.

Regards,
Patrick


> >
> > The opposite problem also exists: by always prioritizing upstream
> > includes, if changes are made in the kernel headers and devicetree
> > files that are not backwards compatible, again all boards which have not
> > been migrated to OF_UPSTREAM will break.
> >
> > This patch fixes this problem by prioritizing upstream includes when
> > `CONFIG_OF_UPSTREAM=y`, while keeping current prioritization when
> > it is not.
> >
> > Signed-off-by: Patrick Barsanti 
> > ---
> >  Makefile | 14 ++
> >  1 file changed, 14 insertions(+)
> >
> > diff --git a/Makefile b/Makefile
> > index 79b28c2d81..899ae664ca 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -826,6 +826,19 @@ KBUILD_HOSTCFLAGS += $(if $(CONFIG_TOOLS_DEBUG),-g)
> >
> >  # Use UBOOTINCLUDE when you must reference the include/ directory.
> >  # Needed to be compatible with the O= option
> > +ifeq ($(CONFIG_OF_UPSTREAM),y)
> > +UBOOTINCLUDE:= \
> > +   -I$(srctree)/dts/upstream/include \
> > +   -Iinclude \
> > +   $(if $(KBUILD_SRC), -I$(srctree)/include) \
> > +   $(if $(CONFIG_$(SPL_)SYS_THUMB_BUILD), \
> > +   $(if $(CONFIG_HAS_THUMB2), \
> > +   $(if $(CONFIG_CPU_V7M), \
> > +   -I$(srctree)/arch/arm/thumb1/include), \
> > +   -I$(srctree)/arch/arm/thumb1/include)) \
> > +   -I$(srctree)/arch/$(ARCH)/include \
> > +   -include $(srctree)/include/linux/kconfig.h
> > +else
> >  UBOOTINCLUDE:= \
> > -Iinclude \
> > $(if $(KBUILD_SRC), -I$(srctree)/include) \
> > @@ -837,6 +850,7 @@ UBOOTINCLUDE:= \
> > -I$(srctree)/arch/$(ARCH)/include \
> > -include $(srctree)/include/linux/kconfig.h \
> > -I$(srctree)/dts/upstream/include
> > +endif
> >
> >  NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC)
> -print-file-name=include)
> >
> > --
> > 2.43.0
> >
>

[gcc r15-892] c++: canonicity of fn types w/ instantiated eh specs [PR115223]

2024-05-29 Thread Patrick Palka via Gcc-cvs

https://gcc.gnu.org/g:58b8c87b7fb281e35a6817cc91a292096fdc02dc

commit r15-892-g58b8c87b7fb281e35a6817cc91a292096fdc02dc
Author: Patrick Palka 
Date:   Wed May 29 04:49:37 2024 -0400

c++: canonicity of fn types w/ instantiated eh specs [PR115223]

When propagating structural equality in build_cp_fntype_variant, we
should consider structural equality of the exception-less variant, not
of the given type which might use structural equality only because it
has a (complex) noexcept-spec that we're intending to replace, as in
maybe_instantiate_noexcept which calls build_exception_variant using
the deferred-noexcept function type.  Otherwise we might pessimistically
use structural equality for a function type with a simple instantiated
noexcept-spec, leading to a LTO-triggered type verification failure if we
later use that (structural-equality) type as the canonical version of
some other variant.

PR c++/115223

gcc/cp/ChangeLog:

* tree.cc (build_cp_fntype_variant): Propagate structural
equality of the exception-less variant.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/noexcept87.C: New test.

Reviewed-by: Jason Merrill 

Diff:
---
 gcc/cp/tree.cc  |  4 
 gcc/testsuite/g++.dg/cpp0x/noexcept87.C | 11 +++
 2 files changed, 15 insertions(+)

diff --git a/gcc/cp/tree.cc b/gcc/cp/tree.cc
index fe3f034d000..72dd46e1bd1 100644
--- a/gcc/cp/tree.cc
+++ b/gcc/cp/tree.cc
@@ -2796,6 +2796,10 @@ build_cp_fntype_variant (tree type, cp_ref_qualifier 
rqual,
   bool complex_eh_spec_p = (cr && cr != noexcept_true_spec
&& !UNPARSED_NOEXCEPT_SPEC_P (cr));
 
+  if (!complex_eh_spec_p && TYPE_RAISES_EXCEPTIONS (type))
+/* We want to consider structural equality of the exception-less
+   variant since we'll be replacing the exception specification.  */
+type = build_cp_fntype_variant (type, rqual, /*raises=*/NULL_TREE, late);
   if (TYPE_STRUCTURAL_EQUALITY_P (type) || complex_eh_spec_p)
 /* Propagate structural equality.  And always use structural equality
for function types with a complex noexcept-spec since their identity
diff --git a/gcc/testsuite/g++.dg/cpp0x/noexcept87.C 
b/gcc/testsuite/g++.dg/cpp0x/noexcept87.C
new file mode 100644
index 000..339569d15ae
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/noexcept87.C
@@ -0,0 +1,11 @@
+// PR c++/115223
+// { dg-do compile { target c++11 } }
+// { dg-additional-options -flto }
+
+template
+void f() noexcept(bool(T() || true));
+
+void g() { f(); }
+
+using type = void;
+type callDestructorIfNecessary() noexcept {}

size of fedora 40 live

2024-05-29 Thread Patrick Dupre via users

Hello,

Could somebody tell the size of the iso image of fedora 40 workstation live?
I need to known before download.

Thanks

===
 Patrick DUPRÉ | | email: pdu...@gmx.com
===
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: [RBW] DIY build or order complete?

On Tue, May 28, 2024 at 6:40 PM Eric Daume  wrote:

> Riv framesets come with a headset installed. That's the hardest job for a
> home mechanic, in my experience.
>

Not if you use a hammer. Seriously, this is how I installed my first ones,
but those were cheap steel and I was lucky. No, don't try it. Now I use a
crude press made from thick threaded rod with big fender washers and nuts;
works fine and I do this only every 10 years or so.

The next hardest job is ordering the correct parts: bottom bracket spindle
> length and crank and (if you're using one) the front derailer all need to
> play together correctly.
>

+1. Buy your parts at a good shop who can tell you what size you need. FDs:
Am I right in thinking that fds from the 5 sp era were more fiddly than
modern (I count 7400s as modern) ones? Or am I just more experienced? I
used to sweat over fds.

Interesting thread. I started tearing down and building bikes in complete
and blissful ignorance on a dirty concrete garage floor with poor light and
minimal tools -- monkey wrench for headsets and bb fixed cup, nail and
hammer and big nut for chains, largely pliers and vise grip for the rest.
If you have good set of general DIY tools you are already light years ahead.

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/CALuTfgt2sqXjqPKtY0nJ3BWpcHLcpntHTZ0tzPoCHSYDXiu9_A%40mail.gmail.com.

Re: [RBW] Re: DIY build or order complete?

I have to agree with Piaw here. It's not hard to build a bike, at least if
it's a Rivendell-type bike, if you start by buying the correct parts from a
knowledgeable shop instead of trying to learn seat-of-pants by yourelf. But
I disagree about racks and fenders: racks are rarely a problem, IME, if you
use rim brakes and even plastic fenders are not that hard to install. I
agree that the first 2 or so pairs of metal fenders will be an education,
and I suggested to a friend that if he use VOs or Honjos he buy a practice
pair along with the"real" pair; kidding but not by too much; but I managed
to install my first pair (Berthouds?) with enough time and they were only a
wee bit warped in the rear, but not noticeable unless you looked closely.
But even metal fenders aren't that hard if you have decent tools and follow
good instructions; Jitensha used to have the best instructions, but this
was a decade or more ago.

As for square taper bb bearing assemblies, they're all cartridge now* and
all you need is for a reputable shop to tell you which length you need for
a given crank.

* Unless someone wants to buy my NIP Suntour Grease Guard, 125 mm -- was
hoping it would work on Matt #1, but nope. But even loose ball bb
assemblies aren't hard as long as you have been told what size to buy; in
all of this it's the variety of lengths and which to choose for which crank
that can be confusing.

On Tue, May 28, 2024 at 6:26 PM Mathias Steiner 
wrote:

> Piaw said:
>
> >> Don't worry about assembling the bike. Modern bikes are easy and modern
> parts even easier.
>
> Clearly, you have not added racks and fenders much :)
>
> Especially the latter are usually finicky... been doing this since 1986,
> can't count how many times.
> Sometimes it goes OK, but I got some Honjos to put on right now and lemme
> tell you...
>
> >> (I avoid the square taper BB for that reason)
>
> That I've had no trouble with, cartridge or traditional.
>
> cheers -mathias
>
>
>
>
>
> On Tuesday, May 28, 2024 at 8:12:12 PM UTC-4 Piaw Na wrote:
>
>> I've been building my own bikes since 2007. It's not nearly as hard as
>> building a wheel. The only issue I can see is the the Sam Hillborne runs
>> cantilever/v-brakes, which have never worked out for me (I only buy
>> sidepull brake bikes to sidestep that problem). I recently built my wife's
>> bike. During the build due to bad lighting in my garage I assembled the
>> microshift bar-end wrong in such a way that the lever throw was half of
>> what it should have been. I scratched my head and rode it to the bike shop,
>> where the mechanic diagnosed the problem while telling me that it's silly
>> to put MTB derailleurs and a 1x drivetrain on my wife's road bike. But they
>> were about to close up shop. I decided to just ride the bike back home,
>> undo the shifter/derailleur cable assembly and redo it (which took all of
>> 15 minutes) and now the bike's perfect and she's setting PRs on her commute.
>>
>> The lesson:
>>
>>- Have good lighting in your workshop. Saves lots of time.
>>- Don't worry about assembling the bike. Modern bikes are easy and
>>modern parts even easier. (I avoid the square taper BB sfor that reason)
>>- The only way to get the parts you want on a bike is to buy them
>>yourself and assemble it yourself. I've had reputable shops like R 
>> cycles
>>refuse to custom build a road bike with a 1x drivetrain. I do it myself 
>> and
>>have no complaints about my mechanic refuse to do entirely reasonable
>>things.
>>
>>
>> On Tuesday, May 28, 2024 at 8:32:14 AM UTC-7 Michael wrote:
>>
>>> Hi all,
>>> Ordered a Sam as my first Riv but unsure whether or not I should tackle
>>> building it up myself or just let Riv have at it. I have never built a bike
>>> before but I do have a workshop and am good with tools/mechanically
>>> inclined.
>>>
>>> Are there any specific steps that you would absolutely not recommend a
>>> beginner attempt? By the time i purchase specialty tools, it may have been
>>> wiser to just order it complete?
>>>
>>> Let me know what you guys think, I really don't want to do something
>>> stupid!
>>>
>>> Thanks,
>>>
>> --
> You received this message because you are subscribed to the Google Groups
> "RBW Owners Bunch" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rbw-owners-bunch+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rbw-owners-bunch/d5a1510b-30f4-40fa-bf5b-261a8e5264ecn%40

[PATCH v2 1/2] RISC-V: add option -m(no-)autovec-segment

From: Greg McGary 

Add option -m(no-)autovec-segment to enable/disable autovectorizer
from emitting vector segment load/store instructions. This is useful for
performance experiments.

gcc/ChangeLog:
* config/riscv/autovec.md (vec_mask_len_load_lanes, 
vec_mask_len_store_lanes):
  Predicate with TARGET_VECTOR_AUTOVEC_SEGMENT
* gcc/config/riscv/riscv-opts.h (TARGET_VECTOR_AUTOVEC_SEGMENT): New 
macro.
* gcc/config/riscv/riscv.opt (-m(no-)autovec-segment): New option.
* testsuite/gcc.target/riscv/rvv/autovec/struct/*_noseg*.c,
testsuite/gcc.target/riscv/rvv/autovec/no-segment.c: New tests.

Tested-by: Edwin Lu 
---
Added tested-by on Vineet's recommendation. Please wait for riscv precommit to
finish before committing.
---
 gcc/config/riscv/autovec.md   |  4 +-
 gcc/config/riscv/riscv-opts.h |  5 ++
 gcc/config/riscv/riscv.opt|  4 ++
 .../gcc.target/riscv/rvv/autovec/no-segment.c | 62 +++
 .../autovec/struct/mask_struct_load_noseg-1.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-2.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-3.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-4.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-5.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-6.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-7.c |  6 ++
 .../struct/mask_struct_load_noseg_run-1.c |  4 ++
 .../struct/mask_struct_load_noseg_run-2.c |  4 ++
 .../struct/mask_struct_load_noseg_run-3.c |  4 ++
 .../struct/mask_struct_load_noseg_run-4.c |  4 ++
 .../struct/mask_struct_load_noseg_run-5.c |  4 ++
 .../struct/mask_struct_load_noseg_run-6.c |  4 ++
 .../struct/mask_struct_load_noseg_run-7.c |  4 ++
 .../struct/mask_struct_store_noseg-1.c|  6 ++
 .../struct/mask_struct_store_noseg-2.c|  6 ++
 .../struct/mask_struct_store_noseg-3.c|  6 ++
 .../struct/mask_struct_store_noseg-4.c|  6 ++
 .../struct/mask_struct_store_noseg-5.c|  6 ++
 .../struct/mask_struct_store_noseg-6.c|  6 ++
 .../struct/mask_struct_store_noseg-7.c|  6 ++
 .../struct/mask_struct_store_noseg_run-1.c|  4 ++
 .../struct/mask_struct_store_noseg_run-2.c|  4 ++
 .../struct/mask_struct_store_noseg_run-3.c|  4 ++
 .../struct/mask_struct_store_noseg_run-4.c|  4 ++
 .../struct/mask_struct_store_noseg_run-5.c|  4 ++
 .../struct/mask_struct_store_noseg_run-6.c|  4 ++
 .../struct/mask_struct_store_noseg_run-7.c|  4 ++
 .../rvv/autovec/struct/struct_vect_noseg-1.c  |  8 +++
 .../rvv/autovec/struct/struct_vect_noseg-10.c |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-11.c |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-12.c |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-13.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-14.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-15.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-16.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-17.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-18.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-2.c  |  8 +++
 .../rvv/autovec/struct/struct_vect_noseg-3.c  |  8 +++
 .../rvv/autovec/struct/struct_vect_noseg-4.c  |  8 +++
 .../rvv/autovec/struct/struct_vect_noseg-5.c  |  8 +++
 .../rvv/autovec/struct/struct_vect_noseg-6.c  |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-7.c  |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-8.c  |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-9.c  |  7 +++
 .../autovec/struct/struct_vect_noseg_run-1.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-10.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-11.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-12.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-13.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-14.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-15.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-16.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-17.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-18.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-2.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-3.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-4.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-5.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-6.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-7.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-8.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-9.c  |  4 ++
 68 files changed, 410 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/no-segment.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg-1.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg-2.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg-3.c
 create mode 100644

[PATCH v2 2/2] Prevent divide-by-zero

From: Greg McGary 

gcc/ChangeLog:
* gcc/tree-vect-stmts.cc (gcc/tree-vect-stmts.cc): Prevent 
divide-by-zero.
* testsuite/gcc.target/riscv/rvv/autovec/no-segment.c: Remove xfail.
---
 gcc/testsuite/gcc.target/riscv/rvv/autovec/no-segment.c | 1 -
 gcc/tree-vect-stmts.cc  | 3 ++-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.target/riscv/rvv/autovec/no-segment.c 
b/gcc/testsuite/gcc.target/riscv/rvv/autovec/no-segment.c
index fd996a27501..79d03612a22 100644
--- a/gcc/testsuite/gcc.target/riscv/rvv/autovec/no-segment.c
+++ b/gcc/testsuite/gcc.target/riscv/rvv/autovec/no-segment.c
@@ -1,6 +1,5 @@
 /* { dg-do compile } */
 /* { dg-options "-march=rv64gcv -mabi=lp64d -mrvv-vector-bits=scalable -O3 
-mno-autovec-segment" } */
-/* { xfail *-*-* } */

 enum e { c, d };
 enum g { f };
diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index 4219ad832db..34f5736ba00 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -11558,7 +11558,8 @@ vectorizable_load (vec_info *vinfo,
 - (vec_num * j + i) * nunits);
/* remain should now be > 0 and < nunits.  */
unsigned num;
-   if (constant_multiple_p (nunits, remain, ))
+   if (known_gt (remain, 0)
+   && constant_multiple_p (nunits, remain, ))
  {
tree ptype;
new_vtype
--
2.43.2

[PATCH v2 0/2] RISC-V: add option -m(no-)autovec-segment

Rebased to squash Edwin's fixup into Greg's patch. Split out the middle-end
change and xfailed the associated testcase so the second patch can land
seperately.

Relying on pre-commit CI for full testing.

Greg McGary (2):
  RISC-V: add option -m(no-)autovec-segment
  Prevent divide-by-zero

 gcc/config/riscv/autovec.md   |  4 +-
 gcc/config/riscv/riscv-opts.h |  5 ++
 gcc/config/riscv/riscv.opt|  4 ++
 .../gcc.target/riscv/rvv/autovec/no-segment.c | 61 +++
 .../autovec/struct/mask_struct_load_noseg-1.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-2.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-3.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-4.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-5.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-6.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-7.c |  6 ++
 .../struct/mask_struct_load_noseg_run-1.c |  4 ++
 .../struct/mask_struct_load_noseg_run-2.c |  4 ++
 .../struct/mask_struct_load_noseg_run-3.c |  4 ++
 .../struct/mask_struct_load_noseg_run-4.c |  4 ++
 .../struct/mask_struct_load_noseg_run-5.c |  4 ++
 .../struct/mask_struct_load_noseg_run-6.c |  4 ++
 .../struct/mask_struct_load_noseg_run-7.c |  4 ++
 .../struct/mask_struct_store_noseg-1.c|  6 ++
 .../struct/mask_struct_store_noseg-2.c|  6 ++
 .../struct/mask_struct_store_noseg-3.c|  6 ++
 .../struct/mask_struct_store_noseg-4.c|  6 ++
 .../struct/mask_struct_store_noseg-5.c|  6 ++
 .../struct/mask_struct_store_noseg-6.c|  6 ++
 .../struct/mask_struct_store_noseg-7.c|  6 ++
 .../struct/mask_struct_store_noseg_run-1.c|  4 ++
 .../struct/mask_struct_store_noseg_run-2.c|  4 ++
 .../struct/mask_struct_store_noseg_run-3.c|  4 ++
 .../struct/mask_struct_store_noseg_run-4.c|  4 ++
 .../struct/mask_struct_store_noseg_run-5.c|  4 ++
 .../struct/mask_struct_store_noseg_run-6.c|  4 ++
 .../struct/mask_struct_store_noseg_run-7.c|  4 ++
 .../rvv/autovec/struct/struct_vect_noseg-1.c  |  8 +++
 .../rvv/autovec/struct/struct_vect_noseg-10.c |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-11.c |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-12.c |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-13.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-14.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-15.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-16.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-17.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-18.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-2.c  |  8 +++
 .../rvv/autovec/struct/struct_vect_noseg-3.c  |  8 +++
 .../rvv/autovec/struct/struct_vect_noseg-4.c  |  8 +++
 .../rvv/autovec/struct/struct_vect_noseg-5.c  |  8 +++
 .../rvv/autovec/struct/struct_vect_noseg-6.c  |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-7.c  |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-8.c  |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-9.c  |  7 +++
 .../autovec/struct/struct_vect_noseg_run-1.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-10.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-11.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-12.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-13.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-14.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-15.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-16.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-17.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-18.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-2.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-3.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-4.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-5.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-6.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-7.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-8.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-9.c  |  4 ++
 gcc/tree-vect-stmts.cc|  3 +-
 69 files changed, 411 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/no-segment.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg-1.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg-2.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg-3.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg-4.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg-5.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg-6.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg-7.c
 create mode 100644

Re: leapp-upgrade from SL79 to AL89 ?

2024-05-28 Thread Patrick J. LoPresti

[EXTERNAL] – This message is from an external sender

On Thu, May 16, 2024 at 4:08 AM Nico Kadel-Garcia 
mailto:nka...@gmail.com>> wrote:
>
> I did this sort of stunt years ago with previous Red HGat and RHEL,
> and even had some tools to switch Scientific Linux releases to the
> matching CentOS releases and back. I do *not* recommend it! Resolving
> the library differences for core libraries, and getting the file
> systems built with the features of newer "mkfs" tools is not a trivial
> problem. The time and cleverness expended is usually better spent on
> your backup process.

I will echo this advice.

Based on 20+ years of painful experience, I recommend you forget about upgrades 
and instead turn your effort towards getting your infrastructure to where you 
would be comfortable reinstalling any O/S on any server at any time.

Unfortunately, I suspect this is the sort of thing that is usually learned only 
through painful experience.

 - Pat

[PATCH 2/2] RISC-V: Fix testcases renamed test flag options

From: Edwin Lu 

Some testcases still had --param=riscv-autovec-preference=_,
update to use -mrvv-vector-bits=_.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/autovec/no-segment.c: Update dejagnu flags
* gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg_run-1.c: 
Ditto
* gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg_run-2.c: 
Ditto
* gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg_run-3.c: 
Ditto
* gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg_run-4.c: 
Ditto
* gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg_run-5.c: 
Ditto
* gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg_run-6.c: 
Ditto
* gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg_run-7.c: 
Ditto
* gcc.target/riscv/rvv/autovec/struct/mask_struct_store_noseg_run-1.c: 
Ditto
* gcc.target/riscv/rvv/autovec/struct/mask_struct_store_noseg_run-2.c: 
Ditto
* gcc.target/riscv/rvv/autovec/struct/mask_struct_store_noseg_run-3.c: 
Ditto
* gcc.target/riscv/rvv/autovec/struct/mask_struct_store_noseg_run-4.c: 
Ditto
* gcc.target/riscv/rvv/autovec/struct/mask_struct_store_noseg_run-5.c: 
Ditto
* gcc.target/riscv/rvv/autovec/struct/mask_struct_store_noseg_run-6.c: 
Ditto
* gcc.target/riscv/rvv/autovec/struct/mask_struct_store_noseg_run-7.c: 
Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-1.c:
  Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-10.c: Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-11.c: Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-12.c: Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-13.c: Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-14.c: Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-15.c: Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-16.c: Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-17.c: Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-18.c: Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-2.c:
  Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-3.c:
  Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-4.c:
  Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-5.c:
  Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-6.c:
  Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-7.c:
  Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-8.c:
  Ditto
* gcc.target/riscv/rvv/autovec/struct/struct_vect_noseg_run-9.c:
  Ditto
---
 gcc/testsuite/gcc.target/riscv/rvv/autovec/no-segment.c   | 2 +-
 .../riscv/rvv/autovec/struct/mask_struct_load_noseg_run-1.c   | 2 +-
 .../riscv/rvv/autovec/struct/mask_struct_load_noseg_run-2.c   | 2 +-
 .../riscv/rvv/autovec/struct/mask_struct_load_noseg_run-3.c   | 2 +-
 .../riscv/rvv/autovec/struct/mask_struct_load_noseg_run-4.c   | 2 +-
 .../riscv/rvv/autovec/struct/mask_struct_load_noseg_run-5.c   | 2 +-
 .../riscv/rvv/autovec/struct/mask_struct_load_noseg_run-6.c   | 2 +-
 .../riscv/rvv/autovec/struct/mask_struct_load_noseg_run-7.c   | 2 +-
 .../riscv/rvv/autovec/struct/mask_struct_store_noseg_run-1.c  | 2 +-
 .../riscv/rvv/autovec/struct/mask_struct_store_noseg_run-2.c  | 2 +-
 .../riscv/rvv/autovec/struct/mask_struct_store_noseg_run-3.c  | 2 +-
 .../riscv/rvv/autovec/struct/mask_struct_store_noseg_run-4.c  | 2 +-
 .../riscv/rvv/autovec/struct/mask_struct_store_noseg_run-5.c  | 2 +-
 .../riscv/rvv/autovec/struct/mask_struct_store_noseg_run-6.c  | 2 +-
 .../riscv/rvv/autovec/struct/mask_struct_store_noseg_run-7.c  | 2 +-
 .../riscv/rvv/autovec/struct/struct_vect_noseg_run-1.c| 2 +-
 .../riscv/rvv/autovec/struct/struct_vect_noseg_run-10.c   | 4 ++--
 .../riscv/rvv/autovec/struct/struct_vect_noseg_run-11.c   | 2 +-
 .../riscv/rvv/autovec/struct/struct_vect_noseg_run-12.c   | 2 +-
 .../riscv/rvv/autovec/struct/struct_vect_noseg_run-13.c   | 2 +-
 .../riscv/rvv/autovec/struct/struct_vect_noseg_run-14.c   | 2 +-
 .../riscv/rvv/autovec/struct/struct_vect_noseg_run-15.c   | 2 +-
 .../riscv/rvv/autovec/struct/struct_vect_noseg_run-16.c   | 2 +-
 .../riscv/rvv/autovec/struct/struct_vect_noseg_run-17.c   | 2 +-
 .../riscv/rvv/autovec/struct/struct_vect_noseg_run-18.c   | 2 +-
 .../riscv/rvv/autovec/struct/struct_vect_noseg_run-2.c| 2 +-
 .../riscv/rvv/autovec/struct/struct_vect_noseg_run-3.c| 2 +-
 .../riscv/rvv/autovec/struct/struct_vect_noseg_run-4.c| 2 +-
 .../riscv/rvv/autovec/struct/struct_vect_noseg_run-5.c| 2 +-

[PATCH 1/2] RISC-V: add option -m(no-)autovec-segment

From: Greg McGary 

Add option -m(no-)autovec-segment to enable/disable autovectorizer
from emitting vector segment load/store instructions. This is useful for
performance experiments.

gcc/ChangeLog:
* config/riscv/autovec.md (vec_mask_len_load_lanes, 
vec_mask_len_store_lanes):
  Predicate with TARGET_VECTOR_AUTOVEC_SEGMENT
* gcc/config/riscv/riscv-opts.h (TARGET_VECTOR_AUTOVEC_SEGMENT): New 
macro.
* gcc/config/riscv/riscv.opt (-m(no-)autovec-segment): New option.
* gcc/tree-vect-stmts.cc (gcc/tree-vect-stmts.cc): Prevent 
divide-by-zero.
* testsuite/gcc.target/riscv/rvv/autovec/struct/*_noseg*.c,
testsuite/gcc.target/riscv/rvv/autovec/no-segment.c: New tests.
---
 gcc/config/riscv/autovec.md   |  4 +-
 gcc/config/riscv/riscv-opts.h |  5 ++
 gcc/config/riscv/riscv.opt|  4 ++
 .../gcc.target/riscv/rvv/autovec/no-segment.c | 61 +++
 .../autovec/struct/mask_struct_load_noseg-1.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-2.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-3.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-4.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-5.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-6.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-7.c |  6 ++
 .../struct/mask_struct_load_noseg_run-1.c |  4 ++
 .../struct/mask_struct_load_noseg_run-2.c |  4 ++
 .../struct/mask_struct_load_noseg_run-3.c |  4 ++
 .../struct/mask_struct_load_noseg_run-4.c |  4 ++
 .../struct/mask_struct_load_noseg_run-5.c |  4 ++
 .../struct/mask_struct_load_noseg_run-6.c |  4 ++
 .../struct/mask_struct_load_noseg_run-7.c |  4 ++
 .../struct/mask_struct_store_noseg-1.c|  6 ++
 .../struct/mask_struct_store_noseg-2.c|  6 ++
 .../struct/mask_struct_store_noseg-3.c|  6 ++
 .../struct/mask_struct_store_noseg-4.c|  6 ++
 .../struct/mask_struct_store_noseg-5.c|  6 ++
 .../struct/mask_struct_store_noseg-6.c|  6 ++
 .../struct/mask_struct_store_noseg-7.c|  6 ++
 .../struct/mask_struct_store_noseg_run-1.c|  4 ++
 .../struct/mask_struct_store_noseg_run-2.c|  4 ++
 .../struct/mask_struct_store_noseg_run-3.c|  4 ++
 .../struct/mask_struct_store_noseg_run-4.c|  4 ++
 .../struct/mask_struct_store_noseg_run-5.c|  4 ++
 .../struct/mask_struct_store_noseg_run-6.c|  4 ++
 .../struct/mask_struct_store_noseg_run-7.c|  4 ++
 .../rvv/autovec/struct/struct_vect_noseg-1.c  |  8 +++
 .../rvv/autovec/struct/struct_vect_noseg-10.c |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-11.c |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-12.c |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-13.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-14.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-15.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-16.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-17.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-18.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-2.c  |  8 +++
 .../rvv/autovec/struct/struct_vect_noseg-3.c  |  8 +++
 .../rvv/autovec/struct/struct_vect_noseg-4.c  |  8 +++
 .../rvv/autovec/struct/struct_vect_noseg-5.c  |  8 +++
 .../rvv/autovec/struct/struct_vect_noseg-6.c  |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-7.c  |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-8.c  |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-9.c  |  7 +++
 .../autovec/struct/struct_vect_noseg_run-1.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-10.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-11.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-12.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-13.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-14.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-15.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-16.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-17.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-18.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-2.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-3.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-4.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-5.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-6.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-7.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-8.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-9.c  |  4 ++
 gcc/tree-vect-stmts.cc|  3 +-
 69 files changed, 411 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/no-segment.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg-1.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg-2.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg-3.c
 create mode 100644

[PATCH 0/2] RISC-V: Add -m(no-)autovec-segment option

Rebased and combined these two patches into a series for precommit-CI to
properly test.

Edwin Lu (1):
  RISC-V: Fix testcases renamed test flag options

Greg McGary (1):
  RISC-V: add option -m(no-)autovec-segment

 gcc/config/riscv/autovec.md   |  4 +-
 gcc/config/riscv/riscv-opts.h |  5 ++
 gcc/config/riscv/riscv.opt|  4 ++
 .../gcc.target/riscv/rvv/autovec/no-segment.c | 61 +++
 .../autovec/struct/mask_struct_load_noseg-1.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-2.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-3.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-4.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-5.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-6.c |  6 ++
 .../autovec/struct/mask_struct_load_noseg-7.c |  6 ++
 .../struct/mask_struct_load_noseg_run-1.c |  4 ++
 .../struct/mask_struct_load_noseg_run-2.c |  4 ++
 .../struct/mask_struct_load_noseg_run-3.c |  4 ++
 .../struct/mask_struct_load_noseg_run-4.c |  4 ++
 .../struct/mask_struct_load_noseg_run-5.c |  4 ++
 .../struct/mask_struct_load_noseg_run-6.c |  4 ++
 .../struct/mask_struct_load_noseg_run-7.c |  4 ++
 .../struct/mask_struct_store_noseg-1.c|  6 ++
 .../struct/mask_struct_store_noseg-2.c|  6 ++
 .../struct/mask_struct_store_noseg-3.c|  6 ++
 .../struct/mask_struct_store_noseg-4.c|  6 ++
 .../struct/mask_struct_store_noseg-5.c|  6 ++
 .../struct/mask_struct_store_noseg-6.c|  6 ++
 .../struct/mask_struct_store_noseg-7.c|  6 ++
 .../struct/mask_struct_store_noseg_run-1.c|  4 ++
 .../struct/mask_struct_store_noseg_run-2.c|  4 ++
 .../struct/mask_struct_store_noseg_run-3.c|  4 ++
 .../struct/mask_struct_store_noseg_run-4.c|  4 ++
 .../struct/mask_struct_store_noseg_run-5.c|  4 ++
 .../struct/mask_struct_store_noseg_run-6.c|  4 ++
 .../struct/mask_struct_store_noseg_run-7.c|  4 ++
 .../rvv/autovec/struct/struct_vect_noseg-1.c  |  8 +++
 .../rvv/autovec/struct/struct_vect_noseg-10.c |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-11.c |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-12.c |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-13.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-14.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-15.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-16.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-17.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-18.c |  6 ++
 .../rvv/autovec/struct/struct_vect_noseg-2.c  |  8 +++
 .../rvv/autovec/struct/struct_vect_noseg-3.c  |  8 +++
 .../rvv/autovec/struct/struct_vect_noseg-4.c  |  8 +++
 .../rvv/autovec/struct/struct_vect_noseg-5.c  |  8 +++
 .../rvv/autovec/struct/struct_vect_noseg-6.c  |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-7.c  |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-8.c  |  7 +++
 .../rvv/autovec/struct/struct_vect_noseg-9.c  |  7 +++
 .../autovec/struct/struct_vect_noseg_run-1.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-10.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-11.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-12.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-13.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-14.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-15.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-16.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-17.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-18.c |  4 ++
 .../autovec/struct/struct_vect_noseg_run-2.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-3.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-4.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-5.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-6.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-7.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-8.c  |  4 ++
 .../autovec/struct/struct_vect_noseg_run-9.c  |  4 ++
 gcc/tree-vect-stmts.cc|  3 +-
 69 files changed, 411 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/autovec/no-segment.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg-1.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg-2.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg-3.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg-4.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg-5.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg-6.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg-7.c
 create mode 100644 
gcc/testsuite/gcc.target/riscv/rvv/autovec/struct/mask_struct_load_noseg_run-1.c
 create mode 100644

GSL use within NASA

2024-05-28 Thread Patrick Alken


Hello all,

  If anyone is a NASA employee using GSL, or if anyone knows of a 
current NASA mission using GSL, can you please contact me?


Thanks,

Patrick

[PATCH] Makefile: Fix include directory for OF_UPSTREAM

2024-05-28 Thread Patrick Barsanti

Always prioritizing u-boot includes causes problems when trying to
migrate boards to OF_UPSTREAM that have divergent devicetree files with
respect to the upstream ones.

For example, migrating a board based on `imx6ul.dtsi` to OF_UPSTREAM
breaks it, as there are some missing defines in the local dtsi file;
the solutions would be to either patch it, which defeats the purpose of
OF_UPSTREAM, or delete it entirely. This last option would then break all
the other boards which have not yet been migrated to OF_UPSTREAM.

The opposite problem also exists: by always prioritizing upstream
includes, if changes are made in the kernel headers and devicetree
files that are not backwards compatible, again all boards which have not
been migrated to OF_UPSTREAM will break.

This patch fixes this problem by prioritizing upstream includes when
`CONFIG_OF_UPSTREAM=y`, while keeping current prioritization when
it is not.

Signed-off-by: Patrick Barsanti 
---
 Makefile | 14 ++
 1 file changed, 14 insertions(+)

diff --git a/Makefile b/Makefile
index 79b28c2d81..899ae664ca 100644
--- a/Makefile
+++ b/Makefile
@@ -826,6 +826,19 @@ KBUILD_HOSTCFLAGS += $(if $(CONFIG_TOOLS_DEBUG),-g)
 
 # Use UBOOTINCLUDE when you must reference the include/ directory.
 # Needed to be compatible with the O= option
+ifeq ($(CONFIG_OF_UPSTREAM),y)
+UBOOTINCLUDE:= \
+   -I$(srctree)/dts/upstream/include \
+   -Iinclude \
+   $(if $(KBUILD_SRC), -I$(srctree)/include) \
+   $(if $(CONFIG_$(SPL_)SYS_THUMB_BUILD), \
+   $(if $(CONFIG_HAS_THUMB2), \
+   $(if $(CONFIG_CPU_V7M), \
+   -I$(srctree)/arch/arm/thumb1/include), \
+   -I$(srctree)/arch/arm/thumb1/include)) \
+   -I$(srctree)/arch/$(ARCH)/include \
+   -include $(srctree)/include/linux/kconfig.h
+else
 UBOOTINCLUDE:= \
-Iinclude \
$(if $(KBUILD_SRC), -I$(srctree)/include) \
@@ -837,6 +850,7 @@ UBOOTINCLUDE:= \
-I$(srctree)/arch/$(ARCH)/include \
-include $(srctree)/include/linux/kconfig.h \
-I$(srctree)/dts/upstream/include
+endif
 
 NOSTDINC_FLAGS += -nostdinc -isystem $(shell $(CC) -print-file-name=include)
 
-- 
2.43.0

Re: [RBW] DIY build or order complete?

Oh, one more very particular rule: If you are completely clueless about
something, try to grasp and accept this reality, and get a professional to
do the job. With my first bike build I had no idea that certain frames were
designed for certain wheel sizes, and I built up a frame that would take no
rim brake known to man. I rode it in hilly narrow roads with speeding
traffic and downtown with a freewheel and no brakes and only Bismarck's
"special providence" kept me alive. ("There's a special providence that
watches over fools, drunkards, children, and the United States of
America.") (I later came to what sense I had and had a coaster brake
installed.)

On Tue, May 28, 2024 at 9:47 AM Patrick Moore  wrote:

> Alas, I think that the only way to get personal experience sufficient to
> learn how you really want to build up a bike is lengthy and expensive trial
> and error; at least, that's how I learned to know exactly what I want in a
> frame and in a build.
>
> So my recommendation would be:
>
> 1. If you want quick and convenient and relatively cheap with good
> results: let Rivendell do it.
>
> 2. If you are willing to spend money and time to learn what really works
> and what doesn't, by all means do it yourself.
>
> Apart from that, I have no particular advice except perhaps one thing:
> don't try to save money and hope that an iffy component might work as well
> as a proven but more expensive component. For example, if you know that you
> like Brooks saddles, don't buy a Nashbar saddle hoping that it might just
> work. Believe me, it's cheaper in the not-so-very long run just to buy what
> you already know works for you.
>
> Patrick "building bad bikes since December 1970 (Xmas vacation,
> southern-hemisphere mid-summer, sophomore year)" Moore.
>
> On Tue, May 28, 2024 at 9:32 AM Michael  wrote:
>
>> Hi all,
>> Ordered a Sam as my first Riv but unsure whether or not I should tackle
>> building it up myself or just let Riv have at it. I have never built a bike
>> before but I do have a workshop and am good with tools/mechanically
>> inclined.
>>
>> Are there any specific steps that you would absolutely not recommend a
>> beginner attempt? By the time i purchase specialty tools, it may have been
>> wiser to just order it complete?
>>
>> Let me know what you guys think, I really don't want to do something
>> stupid!
>>
>> Thanks,
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "RBW Owners Bunch" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to rbw-owners-bunch+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/rbw-owners-bunch/25e3bad5-587a-4d8f-bd29-8ca1f70295aen%40googlegroups.com
>> <https://groups.google.com/d/msgid/rbw-owners-bunch/25e3bad5-587a-4d8f-bd29-8ca1f70295aen%40googlegroups.com?utm_medium=email_source=footer>
>> .
>>
>
>
> --
>
> Patrick Moore
> Alburquerque, Nuevo Mexico, Etats Unis d'Amerique, Orbis Terrarum
>
> ---
>
> Executive resumes, LinkedIn profiles, bios, letters, and other writing
> services
>
>
> ---
>
> *When thou didst not, savage, k**now thine own meaning,*
>
> *But wouldst gabble like a** thing most brutish,*
>
> *I endowed thy purposes w**ith words that made them known.*
>


-- 

Patrick Moore
Alburquerque, Nuevo Mexico, Etats Unis d'Amerique, Orbis Terrarum
---

Executive resumes, LinkedIn profiles, bios, letters, and other writing
services

---

*When thou didst not, savage, k**now thine own meaning,*

*But wouldst gabble like a** thing most brutish,*

*I endowed thy purposes w**ith words that made them known.*

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/CALuTfgsGFa-cNa1s6k7oe7YsgO0Q8ZRod6jiZUn2rWt0Ao0qWA%40mail.gmail.com.

Re: [RBW] DIY build or order complete?

Alas, I think that the only way to get personal experience sufficient to
learn how you really want to build up a bike is lengthy and expensive trial
and error; at least, that's how I learned to know exactly what I want in a
frame and in a build.

So my recommendation would be:

1. If you want quick and convenient and relatively cheap with good results:
let Rivendell do it.

2. If you are willing to spend money and time to learn what really works
and what doesn't, by all means do it yourself.

Apart from that, I have no particular advice except perhaps one thing:
don't try to save money and hope that an iffy component might work as well
as a proven but more expensive component. For example, if you know that you
like Brooks saddles, don't buy a Nashbar saddle hoping that it might just
work. Believe me, it's cheaper in the not-so-very long run just to buy what
you already know works for you.

Patrick "building bad bikes since December 1970 (Xmas vacation,
southern-hemisphere mid-summer, sophomore year)" Moore.

On Tue, May 28, 2024 at 9:32 AM Michael  wrote:

> Hi all,
> Ordered a Sam as my first Riv but unsure whether or not I should tackle
> building it up myself or just let Riv have at it. I have never built a bike
> before but I do have a workshop and am good with tools/mechanically
> inclined.
>
> Are there any specific steps that you would absolutely not recommend a
> beginner attempt? By the time i purchase specialty tools, it may have been
> wiser to just order it complete?
>
> Let me know what you guys think, I really don't want to do something
> stupid!
>
> Thanks,
>
> --
> You received this message because you are subscribed to the Google Groups
> "RBW Owners Bunch" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rbw-owners-bunch+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rbw-owners-bunch/25e3bad5-587a-4d8f-bd29-8ca1f70295aen%40googlegroups.com
> <https://groups.google.com/d/msgid/rbw-owners-bunch/25e3bad5-587a-4d8f-bd29-8ca1f70295aen%40googlegroups.com?utm_medium=email_source=footer>
> .
>

-- 

Patrick Moore
Alburquerque, Nuevo Mexico, Etats Unis d'Amerique, Orbis Terrarum
---

Executive resumes, LinkedIn profiles, bios, letters, and other writing
services

---

*When thou didst not, savage, k**now thine own meaning,*

*But wouldst gabble like a** thing most brutish,*

*I endowed thy purposes w**ith words that made them known.*

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/CALuTfguzq3tTSz0oYhVmR%3Dq3PWr5_Jad%3DS%3DzormY2cp1nLazfA%40mail.gmail.com.

[RBW] Re: How much can you vary wheel diameter and tire width without degrading handling?

Thanks, all. I suppose the best thing to do is to try some good 42 mm tires
-- I agree that 42 mm is a good width for pavement with firmer dirt or
gravel, at least in my 559 size.

OTOH, since the Somas roll so well and handle very nicely ?

After Jay mentioned his Fargo, I remembered that I'd done the same thing
with mine, 10-14 years ago. The "main" wheelset had 60 mm Big Apples but I
got a "road" wheelset with ~33-4 mm Kojaks. I didn't use this set as much
as the other one and have only fuzzy memories of it, but those memories,
such as they are, don't include much degraded handling, unlike the horrible
handling of 22s on my NORBA-era conversions in place of 50s.

Segueing: just the other day found that I can reduce air pressure in the
~49 mm Oracle Ridge regular casings to 16-17 psi to reduce jarring
noticeably over small bumps compared to the 20 psi I'd defined as a
personal minimum for 50s. Yes, a noticeable improvement in cushion.
Bu, *mirabile
dictu*, cornering and rolling on pavement seem no different. I'm 175 kitted
out and the bike is about 33 lb ready to ride with luggage but no load.

I expect that the EL Oracles might require a lb or 2 more; I used to ride
my 60 mm ultralight/paperthin Big Ones at 18. I must try the similarly
paper thin Somas at 16 and see if they too need a psi or 2 more.

This might well be a bike tire pressure race to the bottom; we'll see...

I used Jim's site to get wheel diameters for the tires that I haven't
measured directly, but I just now went back and checked trail and flop.
50s: 64/19, 42s: 61/18. I used to ride the bike with 60s: 67/20. My problem
is that I can't yet translate these numbers into riding experience, as I
can say for gear inches. But it does show that there is no more difference
between 50 -- empirical handling sweet spot -- and 42s than between 60s and
50s; again, not quite sure what to make of that in terms of person
experiences of bike handling. Thus, others' experiences will be usefully
educational.

--
You received this message because you are subscribed to the Google Groups "RBW
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/rbw-owners-bunch/CALuTfguk99r2eypwi6pnd0XO7Fd9fDW43HL3mn%2B2EgAVj6vAKg%40mail.gmail.com.

Re: [fr-users] Utilisation de Libre Office

2024-05-28 Thread Patrick


Bonjour Patrice,

Est-ce que vous avez un message d'erreur ? une fenêtre popup ?
Quelle version de Libre Office avez (ou aviez) vous ?
Y a-t-il eu une mise à jour Windows™vendredi ?
de ce je me rappelle de Windows™, les mises à jour se font en milieu de 
mois (entre le 12 et 15 de chaque mois) mais peut-être n'aviez vous pas 
fait la dernière mise à jour et qu'elle se serait passée entre jeudi et 
vendredi dernier ?

Avez-vous des points de reprise Windows™  ?
il serait intéressant de vérifier ce qu'il s'est passé entre la dernière 
fois que vous avez utilisé LO et vendredi.


(il semblerait que vous avez aussi le même problème que d'autres 
précédemment, avec la messagerie "orange" les lettres accentuées ne 
passent pas dans les messages distribués par la liste !)


Bonne fin de journée
Patrick
PS : ceci dit je suis maintenant le moins bien placé pour des problèmes 
liés "peut-être" à Windows™, n'ayant plus ce magnifique OS depuis 12 ans 
  Mais il y aura bien quelqu'un ou quelqu'une qui essaiera de vous 
dépanner.




Le 27/05/2024 à 20:43, Patrice GACHES a écrit :


Bonsoir,


Je dispose d'un PC avec Windows 11. Depuis vendredi, je ne parviens plus ni  
utiliser le logiciel Libre Office ni  ouvrir mes fichiers. Quel est selon vous 
le problme ? Comment puis-je y remdier ?


Sincrement,


Patrice Gaches




--
Envoyez un mail à users+unsubscr...@fr.libreoffice.org pour vous désinscrire
Les archives de la liste sont disponibles à 
https://listarchives.libreoffice.org/fr/users/
Privacy Policy: https://www.documentfoundation.org/privacy

[RBW] How much can you vary wheel diameter and tire width without degrading handling?

Frames are designed to handle best with wheels of a certain diameter with
tires of a certain width, but sometimes you can vary tire size and get away
with it without making the bike handle strangely  or risking pedal strike.

Instance: 25 years ago I built up several nice pre-susp mtbs with 3 wheels,
2" knobbies, ~26" in diameter, 32-5 mm slicks, ~25" in diameter, for
commuting, and gofast wheels with 26X1" = 22-23 mm in real world width
Specialized Turbos (nice tires), 24", for unladed weekend pavement riding.
So, diameters from 26" to 24". A bit later I had 2 wheelsets for my 1992
XO-1, 24" diameter Turbos and 25" diameter Tioga City Slickers. The
skinnies made the bike a bit quicker to turn.

With the converted mtbs, the bikes handled very nicely with 2" tires, quite
nicely with ~32s, and horribly with 22 mm actual Turbos -- twitchy in
straight line, hesitant and inconsistent in turns.

That was the long windup to this question: for a frame designed for "up to
622X 60s and 584 X 80s"(+ fenders) -- both about 750 mm in diameter, and,
#2, one that in fact handles very nicely with 622 X 50s --  ~730 mm -- how
skinny can one go before compromising handling?

I have no interest in installing 23s, but I think of installing extralight
42s, 714 mm diameter, so a 3/4' or 19 mm drop in real world bb height.

Any thoughts?

Background: I got a second wheelset for the Matthews #1 "road bike for
dirt" for 50 mm* RH Oracle Ridge tires. I meant ot have  this knobby
wheelset for our sandy dirt and leave the original, otherwise identical,
wheelset with the 50 mm Soma Supple Vitesse SLs for pavement riding, this
after I discovered that the Somas do poorly on sandy surfaces.

It turns out that the Oracles roll and handle closely enough to the Somas
that I rather think it's redundant to have a road wheelset with 50 mm
tires, even though these Somas at 360 grams roll exceptionally well and
make this bike handle much like my Riv Roads.

So I wonder about 42s -- no narrower, unless you present good evidence for
narrower -- for lighter weight and perhaps handline a wee bit "crisper."

* ~Actual widths for both OR and SSVSL.

-- 

Patrick Moore
Alburquerque, Nuevo Mexico, Etats Unis d'Amerique, Orbis Terrarum
---

Executive resumes, LinkedIn profiles, bios, letters, and other writing
services

---

*When thou didst not, savage, k**now thine own meaning,*

*But wouldst gabble like a** thing most brutish,*

*I endowed thy purposes w**ith words that made them known.*

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/CALuTfgsRXEbouOpNea_KBx8n2RHnp_FywX3tGYcEgNAgtUjPkg%40mail.gmail.com.

Re: [RBW] Re: Style on the bike

Robert and everyone, I apologize; Robert is right, these are not the model
I know and love.

Apparently, REI no longer carries these; too bad. If anyone knows of
similar pants available from another source, I would be interested in
hearing about them.

https://www.rei.com/product/158172/rei-co-op-sahara-roll-up-cargo-pants-mens

REI Co-op   <https://www.rei.com/b/rei-co-op>Sahara Roll-Up Cargo Pants -
Men's
3.4128  Reviews View the 128 reviews with an average rating of 3.4 out of 5
stars
<https://www.rei.com/product/158172/rei-co-op-sahara-roll-up-cargo-pants-mens#>

*This product is not available.*

On Mon, May 27, 2024 at 10:55 AM  wrote:

> I have a couple pairs of those Sahara pants as well and I love them.
> These look like they got rid of the roll up legs with snaps and replaced
> them with zip off legs? I can’t find the roll up leg version on their site.
>
> Robert Tilley
> San Diego, CA
>
>
> Sent from my iPhone
>
> On May 27, 2024, at 7:03 AM, Patrick Moore  wrote:
>
> 
> I'll recommend the REI "Sahara" cargo pants for occasions when you want to
> ride a bike to an event where shorts are inappropriate. They're on sale
> now, too:
> https://www.rei.com/product/202030/rei-co-op-sahara-convertible-pants-mens?CAWELAID=120217890013538185_mmc=PLA_Bing%7C2170001700551_2020300028%7C92700067489897493%7CPB%7C7170081306883=ds
>
> Very light but densely woven and -- after several years of regular
> warm-weather Sunday use -- quite durable, decent colors (tho' only earth
> tones), well sewn with intelligently designed pockets.*
>
> I used to use light nylon pants with zip-off legs, but the hassle of
> getting the legs off over cycling shoes (or removing the shoes to remove
> the unzipped legs, then putting them on again) was too much. The REI pants
> let you roll the legs to either knickers height or to shorts height.
>
> My brother just gave one of his pairs of same, but oddly a bit too short
> -- he's 4" taller than I; he likes high water pants, I guess -- that I
> might have converted into knickers. If I do that, can anyone recommend a
> nice dark tan, khaki, light brown, or olive green cotton knee sock, with
> source?
>
> As to style: Winter is easy: dark or neutrally colored cycling pants --
> Endura, Osloh* for example -- or wool knickers with wool pullover + knee
> socks under Ibex wool vest and/or "light navy" cycling wind shell with pit
> zips. Summer: I used to ride in lycra and change in the bathroom, but the
> REI rollups paired with nice wicking ss bush shirts in heather sky blue or
> more-or-less tattersall that are trim but not tight (I like my civilian
> shirts baggy) works very well. These bush shirts, found on sale from Kohl's
> some years ago (I'd just written a resume for a Kohl's marketing exec) have
> the usual stink problem of synthetic fabrics but are good for a
> several-hour first wearing and, as I discovered last summer, if you swish
> such synthetics -- works for plastic jerseys too -- in a gallon or so of
> cold water when you get home and hang to drip dry you can wear them as long
> as you can wool.
>
> As to wool, I have 2 remaining of a collection of 4-5 nice retro wool med
> weight ss jerseys; these are good up to the low 90s in low humidity but
> hotter and I accept synthetics. Light wool, including the Riv lightweight
> merino Woolywarms, IME aren't nearly as durable -- snags and moth holes. I
> gave my 2 pr away.
>
> --
> You received this message because you are subscribed to the Google Groups
> "RBW Owners Bunch" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rbw-owners-bunch+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rbw-owners-bunch/CALuTfgvc22yRi0o6mxQ%3D_VMXB97K7i_Lak0jYJ2jGx%2BvbZGA7g%40mail.gmail.com
> <https://groups.google.com/d/msgid/rbw-owners-bunch/CALuTfgvc22yRi0o6mxQ%3D_VMXB97K7i_Lak0jYJ2jGx%2BvbZGA7g%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "RBW Owners Bunch" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rbw-owners-bunch+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rbw-owners-bunch/D8F5CD0D-CBB2-49BF-9CAA-835916D92957%40gmail.com
> <https://groups.google.com/d/msgid/rbw-owners-bunch/D8F5CD0D-CBB2-49BF-9CAA-835916D92957%40gmail.com?utm_medium=email_source=footer>
> .
>


-- 

Patrick Moore
Alburquerque, Nuevo Mexico, Etats Unis d'Amerique, Orbis Terrarum
---

Re: [RBW] Re: Big Joe goes to Snowdonia

Lovely photos; thanks for sharing them.

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/CALuTfgtxtsVJKWU%2BPD-%3DG2D-fFVSydr_tVuL1-iwoB3HoybF2A%40mail.gmail.com.

[swtbot-dev] SWTBot 4.2.0 release in 2024-06

2024-05-27 Thread Patrick Tasse via swtbot-dev

Hi,

A little late to the game but I would like to do the usual annual release
SWTBot 4.2.0 in 2024-06. I plan to create the build for 2024-06 RC1 on or
before Wednesday.

Let me know if you have any concerns or have any patch that you want in
before the release. 2024-06 RC1 +3 is on Wednesday May 29th.

Thanks,
Patrick
___
swtbot-dev mailing list
swtbot-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/swtbot-dev

Re: [RBW] Silver Hub sound

The header immediately made me think of "Music With Her Silver Sound;"
https://www.discogs.com/master/1425787-English-Consort-Of-Viols-Martyn-Hill-Anthony-Rooley-Music-With-Her-Silver-Sound-Works-By-Bull-Byrd-C

The founder of the ensemble was Marco Pallis, author of Peaks and Lamas.
Remarkable man: https://www.discogs.com/artist/3344162-Marco-Pallis

Maybe Rivendell could tune the sound of their hubs to the music of John
Dowland.

On Mon, May 27, 2024 at 6:03 AM Brian Turner  wrote:

> I can’t seem to find the link, but a few years ago, Will posted a video of
> the sound of a Silver hub.
>
> I’d say the description of being slightly louder than a Deore XT hub is
> accurate. But, nowhere near as loud as a White hub, that’s for sure.
>
> - Brian
> Lexington KY
>
> --
> You received this message because you are subscribed to the Google Groups
> "RBW Owners Bunch" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rbw-owners-bunch+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rbw-owners-bunch/82DACF27-2464-4295-8C76-4E9A3426CCD3%40gmail.com
> .
>


-- 

Patrick Moore
Alburquerque, Nuevo Mexico, Etats Unis d'Amerique, Orbis Terrarum
---

Executive resumes, LinkedIn profiles, bios, letters, and other writing
services

---

*When thou didst not, savage, k**now thine own meaning,*

*But wouldst gabble like a** thing most brutish,*

*I endowed thy purposes w**ith words that made them known.*

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/CALuTfgtMRkqLyBvP-wBGyFuxkW-fp3cvepWUJ3pa2oCeJ8d6XQ%40mail.gmail.com.

Re: [RBW] Re: Style on the bike

I'll recommend the REI "Sahara" cargo pants for occasions when you want to
ride a bike to an event where shorts are inappropriate. They're on sale
now, too:
https://www.rei.com/product/202030/rei-co-op-sahara-convertible-pants-mens?CAWELAID=120217890013538185_mmc=PLA_Bing%7C2170001700551_2020300028%7C92700067489897493%7CPB%7C7170081306883=ds

Very light but densely woven and -- after several years of regular
warm-weather Sunday use -- quite durable, decent colors (tho' only earth
tones), well sewn with intelligently designed pockets.*

I used to use light nylon pants with zip-off legs, but the hassle of
getting the legs off over cycling shoes (or removing the shoes to remove
the unzipped legs, then putting them on again) was too much. The REI pants
let you roll the legs to either knickers height or to shorts height.

My brother just gave one of his pairs of same, but oddly a bit too short --
he's 4" taller than I; he likes high water pants, I guess -- that I might
have converted into knickers. If I do that, can anyone recommend a nice
dark tan, khaki, light brown, or olive green cotton knee sock, with source?

As to style: Winter is easy: dark or neutrally colored cycling pants --
Endura, Osloh* for example -- or wool knickers with wool pullover + knee
socks under Ibex wool vest and/or "light navy" cycling wind shell with pit
zips. Summer: I used to ride in lycra and change in the bathroom, but the
REI rollups paired with nice wicking ss bush shirts in heather sky blue or
more-or-less tattersall that are trim but not tight (I like my civilian
shirts baggy) works very well. These bush shirts, found on sale from Kohl's
some years ago (I'd just written a resume for a Kohl's marketing exec) have
the usual stink problem of synthetic fabrics but are good for a
several-hour first wearing and, as I discovered last summer, if you swish
such synthetics -- works for plastic jerseys too -- in a gallon or so of
cold water when you get home and hang to drip dry you can wear them as long
as you can wool.

As to wool, I have 2 remaining of a collection of 4-5 nice retro wool med
weight ss jerseys; these are good up to the low 90s in low humidity but
hotter and I accept synthetics. Light wool, including the Riv lightweight
merino Woolywarms, IME aren't nearly as durable -- snags and moth holes. I
gave my 2 pr away.

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/CALuTfgvc22yRi0o6mxQ%3D_VMXB97K7i_Lak0jYJ2jGx%2BvbZGA7g%40mail.gmail.com.

Re: [cross-project-issues-dev] Eclipse IDE 2024-06 Project Participation Page

2024-05-27 Thread Patrick Tasse via cross-project-issues-dev

Hi,

Eclipse Trace Compass will contribute
https://projects.eclipse.org/projects/tools.tracecompass/releases/10.0.0
Eclipse SWTBot will contribute
https://projects.eclipse.org/projects/technology.swtbot/releases/4.2.0

Thanks,
Patrick

On Wed, May 22, 2024 at 5:56 PM Wayne Beaton via cross-project-issues-dev <
cross-project-issues-dev@eclipse.org> wrote:

> Greetings folks!
>
> I've assembled the release information for participating projects here
> <https://projects.eclipse.org/releases/2024-06>.
>
> Note that the list of projects reflects our long time practice of only
> including projects whose teams are actively participating in the
> simultaneous release. If you look hard enough, you'll notice that projects
> that have been "sponsored in" by participating projects are absent from the
> list. This is per the requirements. I expect that these requirements will
> change in some future release.
>
> A lot of the releases are quite old, and based on the activity in the
> simrel.build <https://github.com/eclipse-simrel/simrel.build>
> repository,  at least a few projects need to create some release records,
> and some may need to engage in a progress review (I've done my usual thing
> of making by best guess based on the release records in the system).
>
> If your project is contributing a different release than what you see
> here, please ensure that you've created a release record
> <https://www.eclipse.org/projects/handbook/#pmi-commands-release>, and
> let me know. If your project has not engaged in a progress (or release)
> review <https://www.eclipse.org/projects/handbook/#progress-review> in
> more than one year, please engage with the EMO ASAP to schedule a review.
>
> Be sure to set the New and Noteworthy URL in your release record: it is
> through this relationship that we build the aggregate N
>
> Please make sure that you've made your best effort to engage in the IP Due
> Diligence Process for all third party content before you engage with the
> EMO for review. Bear in mind that you should be engaging in the IP Due
> Diligence Process
> <https://www.eclipse.org/projects/handbook/#ip-third-party> on an ongoing
> basis and that all releases (regardless of whether or not they correspond
> with a progress or release review) must only contain content that has been
> vetted through the due diligence process. With the Eclipse Dash License
> Tool <https://github.com/eclipse/dash-licenses> and the ability to use it
> to automatically create review requests, it should be *easier than ever*
> before to engage (the README has extensive information on how to engage,
> and does include some pointers for using it with Eclipse Tycho
> <https://github.com/eclipse/dash-licenses#eclipse-tycho>-based builds).
> Connect with the EMO if you need assistance.
>
> Here are some things that I've observed:
>
> Eclipse Client Platform has been removed.
>
> The aggrcon files for the following projects are disabled; if any of these
> projects are dropping from the release, please let me know:
>
>- Eclipse Xpand
>- Eclipse BPMN2 Modeler Project
>- Eclipse RCPTT
>
> Let me know what I've missed.
>
> Thanks,
>
> Wayne
> --
>
> Wayne Beaton
>
> Director of Open Source Projects | Eclipse Foundation
>
>
> My working day may not be your working day! Please don’t feel obliged to
> read or reply to this e-mail outside of your normal working hours.
> ___
> cross-project-issues-dev mailing list
> cross-project-issues-dev@eclipse.org
> To unsubscribe from this list, visit
> https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev
>
___
cross-project-issues-dev mailing list
cross-project-issues-dev@eclipse.org
To unsubscribe from this list, visit 
https://www.eclipse.org/mailman/listinfo/cross-project-issues-dev

core.git: Branch 'libreoffice-24-2-4' - vcl/inc vcl/osx

2024-05-27 Thread Patrick Luby (via logerrit)

 vcl/inc/osx/a11ywrapper.h|2 
 vcl/osx/a11yactionwrapper.mm |   10 ++-
 vcl/osx/a11ycomponentwrapper.mm  |5 +
 vcl/osx/a11yfactory.mm   |3 
 vcl/osx/a11yrolehelper.mm|4 -
 vcl/osx/a11yselectionwrapper.mm  |   12 +++
 vcl/osx/a11ytextattributeswrapper.mm |   12 ++-
 vcl/osx/a11ytextwrapper.mm   |   17 -
 vcl/osx/a11ywrapper.mm   |  110 ++-
 vcl/osx/a11ywrapperbutton.mm |2 
 vcl/osx/a11ywrappercheckbox.mm   |4 +
 vcl/osx/a11ywrappercombobox.mm   |6 +
 vcl/osx/a11ywrappergroup.mm  |2 
 vcl/osx/a11ywrapperlist.mm   |2 
 vcl/osx/a11ywrapperradiobutton.mm|4 +
 vcl/osx/a11ywrapperradiogroup.mm |2 
 vcl/osx/a11ywrapperrow.mm|2 
 vcl/osx/a11ywrapperscrollarea.mm |2 
 vcl/osx/a11ywrapperscrollbar.mm  |2 
 vcl/osx/a11ywrappersplitter.mm   |2 
 vcl/osx/a11ywrapperstatictext.mm |2 
 vcl/osx/a11ywrappertabgroup.mm   |2 
 vcl/osx/a11ywrappertextarea.mm   |2 
 vcl/osx/a11ywrappertoolbar.mm|2 
 vcl/osx/salmenu.cxx  |1 
 25 files changed, 157 insertions(+), 57 deletions(-)

New commits:
commit 92ed1c31467db58d4feca4cf5dc556bac32fcc5e
Author: Patrick Luby 
AuthorDate: Fri May 24 20:26:23 2024 -0400
Commit: Noel Grandin 
CommitDate: Mon May 27 08:16:10 2024 +0200

Related tdf#158914: fix memory leaks by calling (auto)release selectors

Found the following memory leaks using Xcode's Instruments application:

1. Posting an NSAccessibilityUIElementDestroyedNotification
   notification causes [ AquaA11yWrapper isAccessibilityElement ]
   to be called on the object so mark the object as disposed
   before posting the destroyed notification and test for disposed
   in all of the standard NSAccessibility selectors to prevent
   any calls to likely disposed C++ accessibility objects.

2. In [ AquaA11yWrapper accessibilityHitTest: ],
   [ AquaA11yFactory wrapperForAccessibleContext: ] already retains
   the returned object so retaining it until the next call to this
   selector can lead to a memory leak when dragging selected cells
   in Calc to a new location. So autorelease the object so that
   transient objects stay alive but not past the next clearing of
   the autorelease pool.

3. [ AquaA11ySelectionWrapper selectedChildrenAttributeForElement: ] is
   expected to return an autoreleased object.

4. [ AquaA11yFactory wrapperForAccessible: ] is not a getter. It
   expects the caller to release the returned object.

5. CreateNSString() is not a getter. It expects the caller to
   release the returned string.

Change-Id: I824740d7e3851b0c3e31e2c009860aa822c94222
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168034
Reviewed-by: Patrick Luby 
Reviewed-by: Noel Grandin 
Tested-by: Jenkins
(cherry picked from commit 0735a4306da86c6fa0390b85f1f391ec404b2699)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168058
Reviewed-by: Michael Weghorn 
Tested-by: Noel Grandin 

diff --git a/vcl/inc/osx/a11ywrapper.h b/vcl/inc/osx/a11ywrapper.h
index 1eb4039c57e9..48fdd8e2a582 100644
--- a/vcl/inc/osx/a11ywrapper.h
+++ b/vcl/inc/osx/a11ywrapper.h
@@ -67,6 +67,7 @@ struct ReferenceWrapper
 ReferenceWrapper maReferenceWrapper;
 BOOL mActsAsRadioGroup;
 BOOL mIsTableCell;
+BOOL mIsDisposed;
 }
 // NSAccessibility Protocol
 -(id)accessibilityAttributeValue:(NSString *)attribute;
@@ -101,6 +102,7 @@ struct ReferenceWrapper
 -(NSWindow*)windowForParent;
 -(id)init;
 -(id)initWithAccessibleContext: (css::uno::Reference < 
css::accessibility::XAccessibleContext >) anAccessibleContext;
+-(void)setDisposed;
 -(void) setDefaults: (css::uno::Reference < 
css::accessibility::XAccessibleContext >) rxAccessibleContext;
 +(void)setPopupMenuOpen:(BOOL)popupMenuOpen;
 -(css::accessibility::XAccessibleAction *)accessibleAction;
diff --git a/vcl/osx/a11yactionwrapper.mm b/vcl/osx/a11yactionwrapper.mm
index 9bea25c11934..77d670c958b6 100644
--- a/vcl/osx/a11yactionwrapper.mm
+++ b/vcl/osx/a11yactionwrapper.mm
@@ -55,7 +55,10 @@
 NSMutableArray * actionNames = [ [ NSMutableArray alloc ] init ];
 if ( [ wrapper accessibleAction ] ) {
 for ( int cnt = 0; cnt < [ wrapper accessibleAction ] -> 
getAccessibleActionCount(); cnt++ ) {
-[ actionNames addObject: [ AquaA11yActionWrapper 
nativeActionNameFor: CreateNSString ( [ wrapper accessibleAction ] -> 
getAccessibleActionDescription ( cnt ) ) ] ];
+// Related tdf#158914: explicitly call autorelease selector
+// CreateNSString() is not a getter. It expects the caller to
+// release the returned string.
+[ actionNames addObject: [ AquaA11yActionWrapper

core.git: Branch 'libreoffice-24-2' - vcl/inc vcl/osx

2024-05-26 Thread Patrick Luby (via logerrit)

 vcl/inc/osx/a11ywrapper.h|2 
 vcl/osx/a11yactionwrapper.mm |   10 ++-
 vcl/osx/a11ycomponentwrapper.mm  |5 +
 vcl/osx/a11yfactory.mm   |3 
 vcl/osx/a11yrolehelper.mm|4 -
 vcl/osx/a11yselectionwrapper.mm  |   12 +++
 vcl/osx/a11ytextattributeswrapper.mm |   12 ++-
 vcl/osx/a11ytextwrapper.mm   |   17 -
 vcl/osx/a11ywrapper.mm   |  110 ++-
 vcl/osx/a11ywrapperbutton.mm |2 
 vcl/osx/a11ywrappercheckbox.mm   |4 +
 vcl/osx/a11ywrappercombobox.mm   |6 +
 vcl/osx/a11ywrappergroup.mm  |2 
 vcl/osx/a11ywrapperlist.mm   |2 
 vcl/osx/a11ywrapperradiobutton.mm|4 +
 vcl/osx/a11ywrapperradiogroup.mm |2 
 vcl/osx/a11ywrapperrow.mm|2 
 vcl/osx/a11ywrapperscrollarea.mm |2 
 vcl/osx/a11ywrapperscrollbar.mm  |2 
 vcl/osx/a11ywrappersplitter.mm   |2 
 vcl/osx/a11ywrapperstatictext.mm |2 
 vcl/osx/a11ywrappertabgroup.mm   |2 
 vcl/osx/a11ywrappertextarea.mm   |2 
 vcl/osx/a11ywrappertoolbar.mm|2 
 vcl/osx/salmenu.cxx  |1 
 25 files changed, 157 insertions(+), 57 deletions(-)

New commits:
commit c24d9bef5502fb9176f5838bbf15eadcbee1e742
Author: Patrick Luby 
AuthorDate: Fri May 24 20:26:23 2024 -0400
Commit: Michael Weghorn 
CommitDate: Mon May 27 06:04:15 2024 +0200

Related tdf#158914: fix memory leaks by calling (auto)release selectors

Found the following memory leaks using Xcode's Instruments application:

1. Posting an NSAccessibilityUIElementDestroyedNotification
   notification causes [ AquaA11yWrapper isAccessibilityElement ]
   to be called on the object so mark the object as disposed
   before posting the destroyed notification and test for disposed
   in all of the standard NSAccessibility selectors to prevent
   any calls to likely disposed C++ accessibility objects.

2. In [ AquaA11yWrapper accessibilityHitTest: ],
   [ AquaA11yFactory wrapperForAccessibleContext: ] already retains
   the returned object so retaining it until the next call to this
   selector can lead to a memory leak when dragging selected cells
   in Calc to a new location. So autorelease the object so that
   transient objects stay alive but not past the next clearing of
   the autorelease pool.

3. [ AquaA11ySelectionWrapper selectedChildrenAttributeForElement: ] is
   expected to return an autoreleased object.

4. [ AquaA11yFactory wrapperForAccessible: ] is not a getter. It
   expects the caller to release the returned object.

5. CreateNSString() is not a getter. It expects the caller to
   release the returned string.

Change-Id: I824740d7e3851b0c3e31e2c009860aa822c94222
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168034
Reviewed-by: Patrick Luby 
Reviewed-by: Noel Grandin 
Tested-by: Jenkins
(cherry picked from commit 0735a4306da86c6fa0390b85f1f391ec404b2699)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168057
Reviewed-by: Michael Weghorn 

diff --git a/vcl/inc/osx/a11ywrapper.h b/vcl/inc/osx/a11ywrapper.h
index 1eb4039c57e9..48fdd8e2a582 100644
--- a/vcl/inc/osx/a11ywrapper.h
+++ b/vcl/inc/osx/a11ywrapper.h
@@ -67,6 +67,7 @@ struct ReferenceWrapper
 ReferenceWrapper maReferenceWrapper;
 BOOL mActsAsRadioGroup;
 BOOL mIsTableCell;
+BOOL mIsDisposed;
 }
 // NSAccessibility Protocol
 -(id)accessibilityAttributeValue:(NSString *)attribute;
@@ -101,6 +102,7 @@ struct ReferenceWrapper
 -(NSWindow*)windowForParent;
 -(id)init;
 -(id)initWithAccessibleContext: (css::uno::Reference < 
css::accessibility::XAccessibleContext >) anAccessibleContext;
+-(void)setDisposed;
 -(void) setDefaults: (css::uno::Reference < 
css::accessibility::XAccessibleContext >) rxAccessibleContext;
 +(void)setPopupMenuOpen:(BOOL)popupMenuOpen;
 -(css::accessibility::XAccessibleAction *)accessibleAction;
diff --git a/vcl/osx/a11yactionwrapper.mm b/vcl/osx/a11yactionwrapper.mm
index 9bea25c11934..77d670c958b6 100644
--- a/vcl/osx/a11yactionwrapper.mm
+++ b/vcl/osx/a11yactionwrapper.mm
@@ -55,7 +55,10 @@
 NSMutableArray * actionNames = [ [ NSMutableArray alloc ] init ];
 if ( [ wrapper accessibleAction ] ) {
 for ( int cnt = 0; cnt < [ wrapper accessibleAction ] -> 
getAccessibleActionCount(); cnt++ ) {
-[ actionNames addObject: [ AquaA11yActionWrapper 
nativeActionNameFor: CreateNSString ( [ wrapper accessibleAction ] -> 
getAccessibleActionDescription ( cnt ) ) ] ];
+// Related tdf#158914: explicitly call autorelease selector
+// CreateNSString() is not a getter. It expects the caller to
+// release the returned string.
+[ actionNames addObject: [ AquaA11yActionWrapper 
nativeActionNameFor: [ Creat

Re: [RBW] Re: New Bike Day: My Little Platy

2024-05-26 Thread Patrick Moore

+ 1 for blue Loctite on shift lever threads -- it works. Me, I am less
careful than Armand and simple put a big dollop on the threads, screw it
all together, adjust tension, and let it dry -- this method hasn't failed
yet over many years.

On Sun, May 26, 2024 at 10:41 AM Armand Kizirian 
wrote:

> Leah,
>
> Remove the "thumb screw" from the shifters. Place some blue threadlocker
> on the threads, let it dry, and do another coating as well. They won't hold
> their setting and eventually unscrew from use, creating ghost shifts,
> particularly at the worst possible time (out of the saddle sprints, etc.).
> A few layers of threadlocker help them hold their position without issue.
>
> If you happen to powdercoat things in the future, check out the color
> "prismatic universe". I powdercoated my mtb that color with a high gloss
> clear coat and it is insane in the sun. I'll have to send some pics when
> it's all together. Doing some light oil slick parts too as a theme.
>
> On Sunday, May 26, 2024 at 5:55:44 AM UTC-7 Bicycle Belle Ding Ding! wrote:
>
>> I’ve had so much fun putting the first 50 miles on my new bike. I love
>> looking at it and wish I could see it when I’m riding it. The spokes do
>> gleam in the sun as the wheels rotate, which thrills me. I don’t know
>> anything, but it feels to me like my 700c wheels are faster than these
>> 650b. I am not slow on them, but also I would never use this bike for a
>> club ride if my other Platy was in the shop. Both bikes have Velocity
>> Quills, set up tubeless, but the Racing Platy has 42mm Ultradynamicos and
>> the My Little Platy has 48 mm Gravel Kings. Maybe these things are the real
>> differences, I don’t know.
>>
>> The bike is more compact and manageable but does not feel too small. I’m
>> so grateful for my 81 cm PBH, which allows me the flexibility to ride both
>> frame sizes. I have pretty heavy racks on the My Little Platy and yet the
>> bike doesn’t feel THAT heavy. I bet it would feel light as a feather if I
>> didn’t have fenders, racks, dyno and bags all over it.
>>
>> The Silver shifters are taking some getting used to. One wingnut handle
>> flops and the other stays in place. The shifting was like butter, but when
>> I tightened the nut (hoping to stop the handle flapping) it made the lever
>> difficult to move. So, I loosened it again and I’m having some ghost
>> shifting. On my red bike, I have Microshift and I never miss a gear. I can
>> hit it perfectly, every darn time. Hoping I get the hang of these shifters,
>> because they come highly lauded.
>>
>> The front end feels a bit shaky when I stand and pedal, another thing I
>> don’t understand. These are Albatross bars and I have Billies on the
>> others. Also, this bike has a front rack. Maybe that’s why.
>>
>> At any rate, I have a lot to think about, fine tune and to learn. And I’m
>> having such fun in the process.
>> Leah
>>
>>
>> On May 24, 2024, at 7:44 PM, Leah Peterson  wrote:
>>
>> So deep. I couldn’t stand putting a solid color on the spacer when I saw
>> so many oil slick option in 1 1/4 inch. Sure enough, the BMXers came
>> through with the 1 in for me.
>>
>>
>> Sent from my iPhone
>>
>> On May 24, 2024, at 11:27 AM, Wesley  wrote:
>>
>> You know you're in deep when you're sourcing BMX parts to get the look
>> right. It's funny how the bike world is almost completely separated between
>> BMX and all other bikes - the brands, the language, and the parts standards
>> apparently have almost no contact across the divide.
>> -Wes
>> On Thursday, May 23, 2024 at 3:51:53 PM UTC-7 Patrick Moore wrote:
>>
>>> IMO this ties with the other customized Platypus featured here recently
>>> for "nicest-looking Platypus in list history," and it probably wins the
>>> award for "most attention paid to aesthetics" in list history. Note: I
>>> think very many of the Rivs posted are lovely to look at.
>>>
>>> Me, as with Mitch, "I am a guy." I am fully OC about my bikes for parts
>>> and builds and design (I remember most of the parts from my first 1970 full
>>> build), but not aesthetics, and it's interesting to see how others'
>>> passions turn out.
>>>
>>> Cerakoting is new to me; had to Google it. I see it differs from
>>> anodizing, but, how exactly? Too bad webmeisters are generally better fancy
>>> web page design than conveying information -- this for global corporate
>>> websites as well as bike websites; the latter on the whole do better. I
>>> gather that

Re: [RBW] Re: Style on the bike

2024-05-26 Thread Patrick Moore

This is starting to remind me of the early '90s.

Patrick Moore, who once built a gofast '92 XO-1 with bright purple anodized
Sun M14A "semi-aero" rims (and later ruined them with Easy Off -- left them
at the curb for the recycling truck).

On Sun, May 26, 2024 at 6:41 AM Bicycle Belle Ding Ding! <
jonasandle...@gmail.com> wrote:

> Time to revive this thread. Because…well, when you have the perfect shoes
> for your bike, you gotta let people know.
>
>
> On Sunday, November 19, 2023 at 10:28:46 PM UTC-5 Bicycle Belle Ding Ding!
> wrote:
>
>> Excellent kit and you look amazing. I love the bike style posts and am so
>> tickled every time I get one!
>> Sent from my iPhone
>>
>> On Nov 19, 2023, at 9:29 PM, Jason Fuller  wrote:
>>
>> Today's cool but not too cold ride was with Randi Jo wool cap, wool
>> button up from Anian, and the buckskin gloves that Ron & Arya brand and
>> resell - which, for the record, are awesome! All of this kit is excellent -
>> warm and pretty water resistant as well.
>>
>>
>>
>> 
>>
>>
>>
>>
>> On Sunday, 5 November 2023 at 12:48:30 UTC-8 Patrick Moore wrote:
>>
>>> I'll try to remember to take a photo of the knickers (not of me) when
>>> it's next cold enough to wear them. They are very, very comfortable and
>>> nice looking.
>>>
>>> Balmy upper 60s on today's ride home wearing my new (to me) bright green
>>> Cheviot cap while riding a forest green Matthews.
>>>
>>> On Sat, Nov 4, 2023 at 10:20 AM RichS  wrote:
>>>
>>>> Patrick,
>>>>
>>>> +1 on your church going cycling attire. The description is vivid enough
>>>> so I can clearly see it. Your warm weather sartorial choices are impressive
>>>> as well.
>>>> I need to up my game and enhance my decade old Rivendell knickers.
>>>> Thanks for the inspiration:-)
>>>>
>>>> Best,
>>>> Rich in ATL
>>>>
>>>>
>>>> On Friday, November 3, 2023 at 11:28:12 PM UTC-4 Patrick Moore wrote:
>>>>
>>>>> I broke out my oh, so elegant! grey flannel cycling knickers* last
>>>>> Sunday for the ride to church, matched with Rick's (Reisemberg) 
>>>>> medium-dark
>>>>> grey knee socks and a charcoal grey merino mock turtleneck pullover under 
>>>>> a
>>>>> navy Wabi Woolen LS jersey cunningly made into a light cycling jacket with
>>>>> the (very professional) addition of a full-length zipper. Shoes should 
>>>>> have
>>>>> been Dromartis, but I use plain black canvas Specialized SPD shoes because
>>>>> they have a wide toe box and a flat bottom, better for standing during 2+
>>>>> hour liturgies. Topped off with ironically-retro, deliberately jarring
>>>>> green-and-red Legnano cycling cap; not quite cold enough for ear flaps.
>>>>>
>>>>> Only 1 person did a double take at the knickers.
>>>>>
>>>>> Must take a fashion shot.
>>>>>
>>>>> But temps have risen almost 20* this week, so it looks like I'll be
>>>>> back to the light nylon REI roll-up-legs-and-snap-in-place pants and 
>>>>> cotton
>>>>> collared shirt this Sunday.
>>>>>
>>>>> Much more casually, this afternoon, temp about 72* with moderate wind,
>>>>> wore a blue and white wool ss jersey with Italian lycra arm warmers over
>>>>> black Rapha Randonee shorts. Black ankle socks with catchy "Route 66"
>>>>> graphic and late 1980s/1990s Shimano 3-strap SPD shoes and custom cycling
>>>>> cap from Little Packet, no longer in business.
>>>>>
>>>>> * Very tastefully converted from a very nice pair of Nordstrom wool
>>>>> dress flannels with nylon wind panels on inside front and replaceable
>>>>> matched-color wear panel on seat and crotch.
>>>>>
>>>>> I have to say: I've spent considerable bucks on very many supposedly
>>>>> purpose-designed riding pants, knickers and long pants, and I have never
>>>>> had a pair of cycling pants that fit as well and are so well adapted to
>>>>> pedaling as converted dress pants, with the high waist and roomy -- not
>>>>> baggy; not 1950s -- cut. They come up high enough in back that you don't
>>>>> have that continual exposed skin anxiety, and they just feel much more
>>>>> comfor

[systemd-devel] Long delay for ping Systemd 252.25 when DNSSEC is enabled

2024-05-26 Thread Patrick ZAJDA


Hello,

I am on Debian Bookworm, SystemD 252.25 (bookworm-proposed-update).

When I type ping  I have to wait at least 10 seconds to have a 
response when the host resolves to an IPv6 address if dnssec is set to 
yes, output when sending a ping to freedesktop.org:

$ time ping -c1 freedesktop.org
PING freedesktop.org(annarchy.freedesktop.org 
(2610:10:20:722:a800:ff:feda:470f)) 56 data bytes
64 bytes from annarchy.freedesktop.org 
(2610:10:20:722:a800:ff:feda:470f): icmp_seq=1 ttl=44 time=143 ms


--- freedesktop.org ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 143.376/143.376/143.376/0.000 ms

real    0m22,106s
user    0m0,002s
sys    0m0,006s

When disabling dnssec:
$ time ping -c1 freedesktop.org

PING freedesktop.org(annarchy.freedesktop.org 
(2610:10:20:722:a800:ff:feda:470f)) 56 data bytes
64 bytes from annarchy.freedesktop.org 
(2610:10:20:722:a800:ff:feda:470f): icmp_seq=1 ttl=44 time=144 ms


--- freedesktop.org ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 143.902/143.902/143.902/0.000 ms

real    0m1,741s
user    0m0,001s
sys    0m0,005s

Still longer than sending a ping to a host resolving to an IPv4 address 
but really better.


First of all, I thought it was because 
https://github.com/systemd/systemd/pull/31827 was not merged to the 
252-stable branch but it is since 252.24 according to the reply I had 
when opening an issue.


I cannot really test on most recent version of systemd, I prefer 
avoiding breaking things so I don't know at all how it happens with last 
version of SystemD.


Are there some fixes pending on the 252-stable branch which could 
potentially fix this still long delay?


I am lost about how to obtain more diagnostics on systemd resolved and 
where should I open an issue: on systemd-stable repository on GitHub or 
on Debian?


Best regards,

--
Patrick ZAJDA

Re: [PATCH][v2] tree-optimization/115144 - improve sinking destination choice

2024-05-26 Thread Patrick O'Neill

Relevant bugzilla:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115220

Patrick

On Sun, May 26, 2024 at 2:30 AM Li, Pan2  wrote:
>
> Hi Richard,
>
> Looks this commit may result one ICE similar as below when build the newlib, 
> feel free to ping me if you need one PR for this.
>
> CC RISC-V port for awareness.
>
> In file included from 
> /home/pli/gcc/111/riscv-gnu-toolchain/newlib/newlib/libc/stdlib/setenv_r.c:26:
> /home/pli/gcc/111/riscv-gnu-toolchain/newlib/newlib/libc/include/stdlib.h: In 
> function '_setenv_r':
> /home/pli/gcc/111/riscv-gnu-toolchain/newlib/newlib/libc/include/stdlib.h:212:9:
>  error: stmt with wrong VUSE
>   212 | int _setenv_r (struct _reent *, const char *__string, const char 
> *__value, int __overwrite);
>   | ^
> # .MEM_109 = VDEF <.MEM_67>
> *C_59 = 61;
> expected .MEM_106
> during GIMPLE pass: sink
> /home/pli/gcc/111/riscv-gnu-toolchain/newlib/newlib/libc/include/stdlib.h:212:9:
>  internal compiler error: verify_ssa failed
>
> Pan
>
>
> -Original Message-
> From: Richard Biener 
> Sent: Friday, May 24, 2024 7:01 PM
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH][v2] tree-optimization/115144 - improve sinking destination 
> choice
>
> When sinking code closer to its uses we already try to minimize the
> distance we move by inserting at the start of the basic-block.  The
> following makes sure to sink closest to the control dependence
> check of the region we want to sink to as well as make sure to
> ignore control dependences that are only guarding exceptional code.
> This restores somewhat the old profile check but without requiring
> nearly even probabilities.  The patch also makes sure to not give
> up completely when the best sink location is one we do not want to
> sink to but possibly then choose the next best one.
>
> This addresses fallout observed in building libgo.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
>
> PR tree-optimization/115144
> * tree-ssa-sink.cc (do_not_sink): New function, split out
> from ...
> (select_best_block): Here.  First pick valid block to
> sink to.  From that search for the best valid block,
> avoiding sinking across conditions to exceptional code.
> (sink_code_in_bb): When updating vuses of stores in
> paths we do not sink a store to make sure we didn't
> pick a dominating sink location.
>
> * gcc.dg/tree-ssa/ssa-sink-22.c: New testcase.
> ---
>  gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-22.c |  14 +++
>  gcc/tree-ssa-sink.cc| 106 +---
>  2 files changed, 86 insertions(+), 34 deletions(-)
>  create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-22.c
>
> diff --git a/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-22.c 
> b/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-22.c
> new file mode 100644
> index 000..e35626d4070
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/tree-ssa/ssa-sink-22.c
> @@ -0,0 +1,14 @@
> +/* { dg-do compile } */
> +/* { dg-options "-O2 -fdump-tree-sink1-details" } */
> +
> +extern void abort (void);
> +
> +int foo (int x, int y, int f)
> +{
> +  int tem = x / y;
> +  if (f)
> +abort ();
> +  return tem;
> +}
> +
> +/* { dg-final { scan-tree-dump-not "Sinking" "sink1" } } */
> diff --git a/gcc/tree-ssa-sink.cc b/gcc/tree-ssa-sink.cc
> index 2188b7523c7..b0fe871cf1e 100644
> --- a/gcc/tree-ssa-sink.cc
> +++ b/gcc/tree-ssa-sink.cc
> @@ -172,6 +172,39 @@ nearest_common_dominator_of_uses (def_operand_p def_p, 
> bool *debug_stmts)
>return commondom;
>  }
>
> +/* Return whether sinking STMT from EARLY_BB to BEST_BB should be avoided.  
> */
> +
> +static bool
> +do_not_sink (gimple *stmt, basic_block early_bb, basic_block best_bb)
> +{
> +  /* Placing a statement before a setjmp-like function would be invalid
> + (it cannot be reevaluated when execution follows an abnormal edge).
> + If we selected a block with abnormal predecessors, just punt.  */
> +  if (bb_has_abnormal_pred (best_bb))
> +return true;
> +
> +  /* If the latch block is empty, don't make it non-empty by sinking
> + something into it.  */
> +  if (best_bb == early_bb->loop_father->latch
> +  && empty_block_p (best_bb))
> +return true;
> +
> +  /* Avoid turning an unconditional read into a conditional one when we
> + still might want to perform vectorization.  */
> +  if (best_bb->loop_father == early_bb->loop_father
> +  && loop_outer (best_bb->loop_father)
> +  && !best_bb->loop_father->inner
> +

[PATCH v6 2/2] backlight: Add new lm3509 backlight driver

2024-05-26 Thread Patrick Gansterer

This is a general driver for LM3509 backlight chip of TI.
LM3509 is High Efficiency Boost for White LEDs and/or OLED Displays with
Dual Current Sinks. This driver supports OLED/White LED select, brightness
control and sub/main control.
The datasheet can be found at http://www.ti.com/product/lm3509.

Signed-off-by: Patrick Gansterer 
Reviewed-by: Daniel Thompson 
---
 drivers/video/backlight/Kconfig |   7 +
 drivers/video/backlight/Makefile|   1 +
 drivers/video/backlight/lm3509_bl.c | 340 
 3 files changed, 348 insertions(+)
 create mode 100644 drivers/video/backlight/lm3509_bl.c

diff --git a/drivers/video/backlight/Kconfig b/drivers/video/backlight/Kconfig
index 230bca07b09d..3614a5d29c71 100644
--- a/drivers/video/backlight/Kconfig
+++ b/drivers/video/backlight/Kconfig
@@ -373,6 +373,13 @@ config BACKLIGHT_AAT2870
  If you have a AnalogicTech AAT2870 say Y to enable the
  backlight driver.
 
+config BACKLIGHT_LM3509
+   tristate "Backlight Driver for LM3509"
+   depends on I2C
+   select REGMAP_I2C
+   help
+ This supports TI LM3509 Backlight Driver
+
 config BACKLIGHT_LM3630A
tristate "Backlight Driver for LM3630A"
depends on I2C && PWM
diff --git a/drivers/video/backlight/Makefile b/drivers/video/backlight/Makefile
index 8d2cb252042d..8fc98f760a8a 100644
--- a/drivers/video/backlight/Makefile
+++ b/drivers/video/backlight/Makefile
@@ -36,6 +36,7 @@ obj-$(CONFIG_BACKLIGHT_IPAQ_MICRO)+= ipaq_micro_bl.o
 obj-$(CONFIG_BACKLIGHT_KTD253) += ktd253-backlight.o
 obj-$(CONFIG_BACKLIGHT_KTD2801)+= ktd2801-backlight.o
 obj-$(CONFIG_BACKLIGHT_KTZ8866)+= ktz8866.o
+obj-$(CONFIG_BACKLIGHT_LM3509) += lm3509_bl.o
 obj-$(CONFIG_BACKLIGHT_LM3533) += lm3533_bl.o
 obj-$(CONFIG_BACKLIGHT_LM3630A)+= lm3630a_bl.o
 obj-$(CONFIG_BACKLIGHT_LM3639) += lm3639_bl.o
diff --git a/drivers/video/backlight/lm3509_bl.c 
b/drivers/video/backlight/lm3509_bl.c
new file mode 100644
index ..ab57f79ffe23
--- /dev/null
+++ b/drivers/video/backlight/lm3509_bl.c
@@ -0,0 +1,340 @@
+// SPDX-License-Identifier: GPL-2.0-or-later
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define LM3509_NAME "lm3509_bl"
+
+#define LM3509_SINK_MAIN 0
+#define LM3509_SINK_SUB 1
+#define LM3509_NUM_SINKS 2
+
+#define LM3509_DEF_BRIGHTNESS 0x12
+#define LM3509_MAX_BRIGHTNESS 0x1F
+
+#define REG_GP 0x10
+#define REG_BMAIN 0xA0
+#define REG_BSUB 0xB0
+#define REG_MAX 0xFF
+
+enum {
+   REG_GP_ENM_BIT = 0,
+   REG_GP_ENS_BIT,
+   REG_GP_UNI_BIT,
+   REG_GP_RMP0_BIT,
+   REG_GP_RMP1_BIT,
+   REG_GP_OLED_BIT,
+};
+
+struct lm3509_bl {
+   struct regmap *regmap;
+   struct backlight_device *bl_main;
+   struct backlight_device *bl_sub;
+   struct gpio_desc *reset_gpio;
+};
+
+struct lm3509_bl_led_data {
+   const char *label;
+   int led_sources;
+   u32 brightness;
+   u32 max_brightness;
+};
+
+static void lm3509_reset(struct lm3509_bl *data)
+{
+   if (data->reset_gpio) {
+   gpiod_set_value(data->reset_gpio, 1);
+   udelay(1);
+   gpiod_set_value(data->reset_gpio, 0);
+   udelay(10);
+   }
+}
+
+static int lm3509_update_status(struct backlight_device *bl,
+   unsigned int en_mask, unsigned int br_reg)
+{
+   struct lm3509_bl *data = bl_get_data(bl);
+   int ret;
+   bool en;
+
+   ret = regmap_write(data->regmap, br_reg, backlight_get_brightness(bl));
+   if (ret < 0)
+   return ret;
+
+   en = !backlight_is_blank(bl);
+   return regmap_update_bits(data->regmap, REG_GP, en_mask,
+ en ? en_mask : 0);
+}
+
+static int lm3509_main_update_status(struct backlight_device *bl)
+{
+   return lm3509_update_status(bl, BIT(REG_GP_ENM_BIT), REG_BMAIN);
+}
+
+static const struct backlight_ops lm3509_main_ops = {
+   .options = BL_CORE_SUSPENDRESUME,
+   .update_status = lm3509_main_update_status,
+};
+
+static int lm3509_sub_update_status(struct backlight_device *bl)
+{
+   return lm3509_update_status(bl, BIT(REG_GP_ENS_BIT), REG_BSUB);
+}
+
+static const struct backlight_ops lm3509_sub_ops = {
+   .options = BL_CORE_SUSPENDRESUME,
+   .update_status = lm3509_sub_update_status,
+};
+
+static struct backlight_device *
+lm3509_backlight_register(struct device *dev, const char *name_suffix,
+ struct lm3509_bl *data,
+ const struct backlight_ops *ops,
+ const struct lm3509_bl_led_data *led_data)
+
+{
+   struct backlight_device *bd;
+   struct backlight_properties props;
+   const char *label = led_data->label;
+   char name[64];
+
+   memset(, 0, sizeof(props));
+   props.type = BAC

[PATCH v6 0/2] backlight: Add new lm3509 backlight driver

2024-05-26 Thread Patrick Gansterer

This is a general driver for LM3509 backlight chip of TI.
LM3509 is High Efficiency Boost for White LEDs and/or OLED Displays with
Dual Current Sinks. This driver supports OLED/White LED select, brightness
control and sub/main control.
The datasheet can be found at http://www.ti.com/product/lm3509.
---
Changes in v6:
  Removed unnecessary allOf in device tree binding

v5: https://lore.kernel.org/all/20240330145931.729116-1-par...@paroga.com/

Changes in v5:
  Renamed lm3509_bl_led_pdata to lm3509_bl_led_data
  Set backlight_properties.scale to BACKLIGHT_SCALE_NON_LINEAR
  Add dev_err_probe() for first write to a register
  Use dev_err_probe() instead of dev_err()

v4: https://lore.kernel.org/all/20240310135344.3455294-1-par...@paroga.com/

Changes in v4:
  Use backlight_*() to access backlight_device
  Do not set backlight_properties.power

v3: https://lore.kernel.org/all/20240309132521.1290173-1-par...@paroga.com/

Changes in v3:
  Improved device tree bindings documentation

v2: https://lore.kernel.org/all/20240308215617.1729664-1-par...@paroga.com/

Changes in v2:
  Add device tree nodes for each output
  Addressed multiple smaller review comments

v1: https://lore.kernel.org/all/20240302212757.1871164-1-par...@paroga.com/

Patrick Gansterer (2):
  dt-bindings: backlight: Add Texas Instruments LM3509
  backlight: Add new lm3509 backlight driver

 .../bindings/leds/backlight/ti,lm3509.yaml| 136 +++
 drivers/video/backlight/Kconfig   |   7 +
 drivers/video/backlight/Makefile  |   1 +
 drivers/video/backlight/lm3509_bl.c   | 340 ++
 4 files changed, 484 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/leds/backlight/ti,lm3509.yaml
 create mode 100644 drivers/video/backlight/lm3509_bl.c

-- 
2.45.1

[PATCH v6 1/2] dt-bindings: backlight: Add Texas Instruments LM3509

2024-05-26 Thread Patrick Gansterer

Add Device Tree bindings for Texas Instruments LM3509 - a
High Efficiency Boost for White LED's and/or OLED Displays

Signed-off-by: Patrick Gansterer 
Reviewed-by: Krzysztof Kozlowski 
Reviewed-by: Daniel Thompson 
---
 .../bindings/leds/backlight/ti,lm3509.yaml| 136 ++
 1 file changed, 136 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/leds/backlight/ti,lm3509.yaml

diff --git a/Documentation/devicetree/bindings/leds/backlight/ti,lm3509.yaml 
b/Documentation/devicetree/bindings/leds/backlight/ti,lm3509.yaml
new file mode 100644
index ..482fae71dd53
--- /dev/null
+++ b/Documentation/devicetree/bindings/leds/backlight/ti,lm3509.yaml
@@ -0,0 +1,136 @@
+# SPDX-License-Identifier: (GPL-2.0 OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/leds/backlight/ti,lm3509.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: TI LM3509 High Efficiency Boost for White LED's and/or OLED Displays
+
+maintainers:
+  - Patrick Gansterer 
+
+description:
+  The LM3509 current mode boost converter offers two separate outputs.
+  https://www.ti.com/product/LM3509
+
+properties:
+  compatible:
+const: ti,lm3509
+
+  reg:
+maxItems: 1
+
+  "#address-cells":
+const: 1
+
+  "#size-cells":
+const: 0
+
+  reset-gpios:
+maxItems: 1
+
+  ti,brightness-rate-of-change-us:
+description: Brightness Rate of Change in microseconds.
+enum: [51, 13000, 26000, 52000]
+
+  ti,oled-mode:
+description: Enable OLED mode.
+type: boolean
+
+patternProperties:
+  "^led@[01]$":
+type: object
+description: Properties for a string of connected LEDs.
+$ref: common.yaml#
+
+properties:
+  reg:
+description:
+  The control register that is used to program the two current sinks.
+  The LM3509 has two registers (BMAIN and BSUB) and are represented
+  as 0 or 1 in this property. The two current sinks can be controlled
+  independently with both registers, or register BMAIN can be
+  configured to control both sinks with the led-sources property.
+minimum: 0
+maximum: 1
+
+  label: true
+
+  led-sources:
+minItems: 1
+maxItems: 2
+items:
+  minimum: 0
+  maximum: 1
+
+  default-brightness:
+minimum: 0
+maximum: 31
+default: 18
+
+  max-brightness:
+minimum: 0
+maximum: 31
+default: 31
+
+required:
+  - reg
+
+additionalProperties: false
+
+required:
+  - compatible
+  - reg
+
+additionalProperties: false
+
+examples:
+  - |
+#include 
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+backlight@36 {
+compatible = "ti,lm3509";
+reg = <0x36>;
+reset-gpios = < 5 GPIO_ACTIVE_LOW>;
+
+ti,oled-mode;
+ti,brightness-rate-of-change-us = <52000>;
+
+#address-cells = <1>;
+#size-cells = <0>;
+
+led@0 {
+reg = <0>;
+led-sources = <0 1>;
+label = "lcd-backlight";
+default-brightness = <12>;
+max-brightness = <31>;
+};
+};
+};
+  - |
+i2c {
+#address-cells = <1>;
+#size-cells = <0>;
+
+backlight@36 {
+compatible = "ti,lm3509";
+reg = <0x36>;
+
+#address-cells = <1>;
+#size-cells = <0>;
+
+led@0 {
+reg = <0>;
+default-brightness = <12>;
+};
+
+led@1 {
+reg = <1>;
+default-brightness = <15>;
+};
+};
+};
-- 
2.45.1

core.git: Branch 'distro/collabora/co-24.04' - vcl/ios

2024-05-26 Thread Patrick Luby (via logerrit)

 vcl/ios/iosinst.cxx |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

New commits:
commit 2802ba82d2ac0b9d831117dcc47375fd1dd01415
Author: Patrick Luby 
AuthorDate: Sat May 25 21:09:46 2024 -0400
Commit: Andras Timar 
CommitDate: Sun May 26 11:31:53 2024 +0200

Fix a memory leak

CreateNSString() expects the caller to release the returned string.

Change-Id: I578488dd99c4c2737894287ab3e597ba8607669e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168040
Reviewed-by: Andras Timar 
Reviewed-by: Patrick Luby 
Tested-by: Jenkins CollaboraOffice 

diff --git a/vcl/ios/iosinst.cxx b/vcl/ios/iosinst.cxx
index 371d5c246ca1..548da31e58b6 100644
--- a/vcl/ios/iosinst.cxx
+++ b/vcl/ios/iosinst.cxx
@@ -157,7 +157,7 @@ int IosSalSystem::ShowNativeDialog( const OUString& rTitle,
 {
 (void)rButtons;
 
-NSLog(@"%@: %@", CreateNSString(rTitle), CreateNSString(rMessage));
+NSLog(@"%@: %@", [CreateNSString(rTitle) autorelease], 
[CreateNSString(rMessage) autorelease]);
 
 return 0;
 }

core.git: vcl/inc vcl/osx

2024-05-26 Thread Patrick Luby (via logerrit)

 vcl/inc/osx/a11ywrapper.h|2 
 vcl/osx/a11yactionwrapper.mm |   10 ++-
 vcl/osx/a11ycomponentwrapper.mm  |5 +
 vcl/osx/a11yfactory.mm   |3 
 vcl/osx/a11yrolehelper.mm|4 -
 vcl/osx/a11yselectionwrapper.mm  |   12 +++
 vcl/osx/a11ytextattributeswrapper.mm |   12 ++-
 vcl/osx/a11ytextwrapper.mm   |   17 -
 vcl/osx/a11ywrapper.mm   |  110 ++-
 vcl/osx/a11ywrapperbutton.mm |2 
 vcl/osx/a11ywrappercheckbox.mm   |4 +
 vcl/osx/a11ywrappercombobox.mm   |6 +
 vcl/osx/a11ywrappergroup.mm  |2 
 vcl/osx/a11ywrapperlist.mm   |2 
 vcl/osx/a11ywrapperradiobutton.mm|4 +
 vcl/osx/a11ywrapperradiogroup.mm |2 
 vcl/osx/a11ywrapperrow.mm|2 
 vcl/osx/a11ywrapperscrollarea.mm |2 
 vcl/osx/a11ywrapperscrollbar.mm  |2 
 vcl/osx/a11ywrappersplitter.mm   |2 
 vcl/osx/a11ywrapperstatictext.mm |2 
 vcl/osx/a11ywrappertabgroup.mm   |2 
 vcl/osx/a11ywrappertextarea.mm   |2 
 vcl/osx/a11ywrappertoolbar.mm|2 
 vcl/osx/salmenu.cxx  |1 
 25 files changed, 157 insertions(+), 57 deletions(-)

New commits:
commit 0735a4306da86c6fa0390b85f1f391ec404b2699
Author: Patrick Luby 
AuthorDate: Fri May 24 20:26:23 2024 -0400
Commit: Noel Grandin 
CommitDate: Sun May 26 09:52:41 2024 +0200

Related tdf#158914: fix memory leaks by calling (auto)release selectors

Found the following memory leaks using Xcode's Instruments application:

1. Posting an NSAccessibilityUIElementDestroyedNotification
   notification causes [ AquaA11yWrapper isAccessibilityElement ]
   to be called on the object so mark the object as disposed
   before posting the destroyed notification and test for disposed
   in all of the standard NSAccessibility selectors to prevent
   any calls to likely disposed C++ accessibility objects.

2. In [ AquaA11yWrapper accessibilityHitTest: ],
   [ AquaA11yFactory wrapperForAccessibleContext: ] already retains
   the returned object so retaining it until the next call to this
   selector can lead to a memory leak when dragging selected cells
   in Calc to a new location. So autorelease the object so that
   transient objects stay alive but not past the next clearing of
   the autorelease pool.

3. [ AquaA11ySelectionWrapper selectedChildrenAttributeForElement: ] is
   expected to return an autoreleased object.

4. [ AquaA11yFactory wrapperForAccessible: ] is not a getter. It
   expects the caller to release the returned object.

5. CreateNSString() is not a getter. It expects the caller to
   release the returned string.

Change-Id: I824740d7e3851b0c3e31e2c009860aa822c94222
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168034
Reviewed-by: Patrick Luby 
Reviewed-by: Noel Grandin 
Tested-by: Jenkins

diff --git a/vcl/inc/osx/a11ywrapper.h b/vcl/inc/osx/a11ywrapper.h
index 1eb4039c57e9..48fdd8e2a582 100644
--- a/vcl/inc/osx/a11ywrapper.h
+++ b/vcl/inc/osx/a11ywrapper.h
@@ -67,6 +67,7 @@ struct ReferenceWrapper
 ReferenceWrapper maReferenceWrapper;
 BOOL mActsAsRadioGroup;
 BOOL mIsTableCell;
+BOOL mIsDisposed;
 }
 // NSAccessibility Protocol
 -(id)accessibilityAttributeValue:(NSString *)attribute;
@@ -101,6 +102,7 @@ struct ReferenceWrapper
 -(NSWindow*)windowForParent;
 -(id)init;
 -(id)initWithAccessibleContext: (css::uno::Reference < 
css::accessibility::XAccessibleContext >) anAccessibleContext;
+-(void)setDisposed;
 -(void) setDefaults: (css::uno::Reference < 
css::accessibility::XAccessibleContext >) rxAccessibleContext;
 +(void)setPopupMenuOpen:(BOOL)popupMenuOpen;
 -(css::accessibility::XAccessibleAction *)accessibleAction;
diff --git a/vcl/osx/a11yactionwrapper.mm b/vcl/osx/a11yactionwrapper.mm
index 9bea25c11934..77d670c958b6 100644
--- a/vcl/osx/a11yactionwrapper.mm
+++ b/vcl/osx/a11yactionwrapper.mm
@@ -55,7 +55,10 @@
 NSMutableArray * actionNames = [ [ NSMutableArray alloc ] init ];
 if ( [ wrapper accessibleAction ] ) {
 for ( int cnt = 0; cnt < [ wrapper accessibleAction ] -> 
getAccessibleActionCount(); cnt++ ) {
-[ actionNames addObject: [ AquaA11yActionWrapper 
nativeActionNameFor: CreateNSString ( [ wrapper accessibleAction ] -> 
getAccessibleActionDescription ( cnt ) ) ] ];
+// Related tdf#158914: explicitly call autorelease selector
+// CreateNSString() is not a getter. It expects the caller to
+// release the returned string.
+[ actionNames addObject: [ AquaA11yActionWrapper 
nativeActionNameFor: [ CreateNSString ( [ wrapper accessibleAction ] -> 
getAccessibleActionDescription ( cnt ) ) autorelease ] ] ];
 }
 }
 return actionNames;
@@ -64,7 +67,10 @@
 +(void)doA

[PATCH] c++: canonicity of fn types w/ instantiated eh specs [PR115223]

2024-05-25 Thread Patrick Palka

Bootstrap and regtest on x86_64-pc-linux-gnu in progress,
does this look OK for trunk if successful?

-- >8 --

When propagating structural equality in build_cp_fntype_variant, we
should consider structural equality of the exception-less variant, not
of the given type which might use structural equality only because of
the (complex) noexcept-spec we're intending to replace, as in
maybe_instantiate_noexcept which calls build_exception_variant using
the function type with a deferred noexcept-spec.  Otherwise we might
pessimisticly use structural equality for a function type with a simple
instantiated noexcept-spec, leading to a failed LTO-specific sanity
check if we later use that (structural-equality) type as the canonical
version of some other variant.

PR c++/115223

gcc/cp/ChangeLog:

* tree.cc (build_cp_fntype_variant): Propagate structural
equality of the exception-less variant.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/noexcept87.C: New test.
---
 gcc/cp/tree.cc  |  4 
 gcc/testsuite/g++.dg/cpp0x/noexcept87.C | 11 +++
 2 files changed, 15 insertions(+)
 create mode 100644 gcc/testsuite/g++.dg/cpp0x/noexcept87.C

diff --git a/gcc/cp/tree.cc b/gcc/cp/tree.cc
index 4d87661b4ad..f810b8cd777 100644
--- a/gcc/cp/tree.cc
+++ b/gcc/cp/tree.cc
@@ -2796,6 +2796,10 @@ build_cp_fntype_variant (tree type, cp_ref_qualifier 
rqual,
   bool complex_eh_spec_p = (cr && cr != noexcept_true_spec
&& !UNPARSED_NOEXCEPT_SPEC_P (cr));
 
+  if (!complex_eh_spec_p && TYPE_RAISES_EXCEPTIONS (type))
+/* We want to consider structural equality of the exception-less
+   variant since we'll be replacing the exception specification.  */
+type = build_cp_fntype_variant (type, rqual, /*raises=*/NULL_TREE, late);
   if (TYPE_STRUCTURAL_EQUALITY_P (type) || complex_eh_spec_p)
 /* Propagate structural equality.  And always use structural equality
for function types with a complex noexcept-spec since their identity
diff --git a/gcc/testsuite/g++.dg/cpp0x/noexcept87.C 
b/gcc/testsuite/g++.dg/cpp0x/noexcept87.C
new file mode 100644
index 000..60b1497472b
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/noexcept87.C
@@ -0,0 +1,11 @@
+// PR c++/115223
+// { dg-do compile { target c++11 } }
+// { dg-additional-options -flto }
+
+template
+void f() noexcept(bool(T() || true));
+
+void g(int n) { f(); }
+
+using type = void;
+type callDestructorIfNecessary() noexcept {}
-- 
2.45.1.246.gb9cfe4845c

Bug#1071092: systemd-resolved: Ping reply about 15 seconds after instead of near instantaneously

2024-05-25 Thread Patrick ZAJDA


On Tue, 14 May 2024 10:42:21 +0100 Luca Boccassi  wrote:
> On Tue, 14 May 2024 09:13:20 +0200 Patrick ZAJDA 
> wrote:
> > Package: systemd-resolved
> > Version: 254.5-1~bpo12+3
> > Severity: normal
> > Tags: ipv6 upstream
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > Dear Maintainer,
> >
> > I use Network-Manager as my network manager but this also applies for
> other E.G. same occurs with Systemd Network.
> > Until now, when sending a ping to a domain which resolves to an IPv6
> address, it takes a very short delay to have an output returned.
> > But with SystemD-resolved, resolution takes about 15 seconds.
> > This issue should have been fixed upstream [1] but I don't precisely
> know which SystemD version solves it nor if it is stable.
> > It makes ping less efficient with this long delay before having a
> reply.
> >
> > It occurs with the Backport version as specified but also with the
> version in Bookworm (252.22-1~deb12u1).
> >
> > Could it be possible to backport the fix to Bookworm?
> > For bookworm-backports, is it planned to release a new version when
> available?
>
> There will be no more backports updates.
>
> --

About Bookworm, do you have an idea of the moment the version with the 
fix will be available at least on bookworm-proposed-update?


Kind regards,

--
Patrick ZAJDA


OpenPGP_0x9D4AD35BEA273DCA.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Bug#1071092: systemd-resolved: Ping reply about 15 seconds after instead of near instantaneously

2024-05-25 Thread Patrick ZAJDA


On Tue, 14 May 2024 10:42:21 +0100 Luca Boccassi  wrote:
> On Tue, 14 May 2024 09:13:20 +0200 Patrick ZAJDA 
> wrote:
> > Package: systemd-resolved
> > Version: 254.5-1~bpo12+3
> > Severity: normal
> > Tags: ipv6 upstream
> >
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> >
> > Dear Maintainer,
> >
> > I use Network-Manager as my network manager but this also applies for
> other E.G. same occurs with Systemd Network.
> > Until now, when sending a ping to a domain which resolves to an IPv6
> address, it takes a very short delay to have an output returned.
> > But with SystemD-resolved, resolution takes about 15 seconds.
> > This issue should have been fixed upstream [1] but I don't precisely
> know which SystemD version solves it nor if it is stable.
> > It makes ping less efficient with this long delay before having a
> reply.
> >
> > It occurs with the Backport version as specified but also with the
> version in Bookworm (252.22-1~deb12u1).
> >
> > Could it be possible to backport the fix to Bookworm?
> > For bookworm-backports, is it planned to release a new version when
> available?
>
> There will be no more backports updates.
>
> --

About Bookworm, do you have an idea of the moment the version with the 
fix will be available at least on bookworm-proposed-update?


Kind regards,

--
Patrick ZAJDA


OpenPGP_0x9D4AD35BEA273DCA.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

[Info-gsl] GSL 2.8 released

2024-05-25 Thread Patrick Alken


Dear GNU community,

  Version 2.8 of the GNU Scientific Library (GSL) has been released.
Thank you to all who helped test the library prior to the release, and
thank you to everyone for using the library and giving feedback and
reports. The following changes have been added to the library:

* What is new in gsl-2.8:

** apply patch for bug #63679 (F. Weimer)

** updated multilarge TSQR method to store ||z_2|| and
   provide it to the user

** add routines for Hermite B-spline interpolation

** fix for bug #59624

** fix for bug #59781 (M. Dunlap)

** bug fix #61094 (reported by A. Cheylus)

** add functions:
   - gsl_matrix_complex_conjugate
   - gsl_vector_complex_conj_memcpy
   - gsl_vector_complex_div_real
   - gsl_linalg_QR_lssolvem_r
   - gsl_linalg_complex_QR_lssolvem_r
   - gsl_linalg_complex_QR_QHmat_r
   - gsl_linalg_QR_UR_lssolve
   - gsl_linalg_QR_UR_lssvx
   - gsl_linalg_QR_UR_QTvec
   - gsl_linalg_QR_UU_lssvx
   - gsl_linalg_QR_UD_lssvx
   - gsl_linalg_QR_UD_QTvec
   - gsl_linalg_complex_cholesky_{decomp2,svx2,solve2,scale,scale_apply}
   - gsl_linalg_SV_{solve2,lssolve}
   - gsl_rstat_norm

** add Lebedev quadrature (gsl_integration_lebedev)

** major overhaul to the B-spline module to add
   new functionality



___
Info-gsl mailing list
Info-gsl@gnu.org
https://lists.gnu.org/mailman/listinfo/info-gsl

GSL 2.8 Released

2024-05-25 Thread Patrick Alken


Dear GSL community,

  Version 2.8 of the GNU Scientific Library (GSL) has been released. 
Thank you to all who helped test the library prior to the release, and 
thank you to everyone for using the library and giving feedback and 
reports. The following changes have been added to the library:


* What is new in gsl-2.8:

** apply patch for bug #63679 (F. Weimer)

** updated multilarge TSQR method to store ||z_2|| and
   provide it to the user

** add routines for Hermite B-spline interpolation

** fix for bug #59624

** fix for bug #59781 (M. Dunlap)

** bug fix #61094 (reported by A. Cheylus)

** add functions:
   - gsl_matrix_complex_conjugate
   - gsl_vector_complex_conj_memcpy
   - gsl_vector_complex_div_real
   - gsl_linalg_QR_lssolvem_r
   - gsl_linalg_complex_QR_lssolvem_r
   - gsl_linalg_complex_QR_QHmat_r
   - gsl_linalg_QR_UR_lssolve
   - gsl_linalg_QR_UR_lssvx
   - gsl_linalg_QR_UR_QTvec
   - gsl_linalg_QR_UU_lssvx
   - gsl_linalg_QR_UD_lssvx
   - gsl_linalg_QR_UD_QTvec
   - gsl_linalg_complex_cholesky_{decomp2,svx2,solve2,scale,scale_apply}
   - gsl_linalg_SV_{solve2,lssolve}
   - gsl_rstat_norm

** add Lebedev quadrature (gsl_integration_lebedev)

** major overhaul to the B-spline module to add
   new functionality

Re: Need system to run 24/7

2024-05-25 Thread Patrick O'Callaghan

On Sat, 2024-05-25 at 07:51 -0400, Robert McBroom via users wrote:
> 
> On 5/25/24 4:01 AM, Barry wrote:
> > 
> > > On 24 May 2024, at 22:47, Michael D. Setzer II via users
> > >  wrote:
> > > 
> > > Seems it was related to Lenova wanting to get
> > > some kind of higher power saving rating with Linux?? Don't know
> > > why they made it the default settings.
> > I recall the default of suspend after 15 mins is a legal/regulatory
> > driven change.
> > 
> > The owner has to opt into keeping a device on by turning off the
> > power saving defaults.
> > 
> > Barry
> None of the various desktop powers setting menus that I could find 
> showed such an option.

I use KDE, where the various options are under the Power menu in
Settings. I've never had the system power down autonomously.

poc
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: Need system to run 24/7

2024-05-25 Thread Patrick O'Callaghan

On Sat, 2024-05-25 at 07:47 -0400, Robert McBroom via users wrote:
> 
> On 5/24/24 11:57 PM, Tim via users wrote:
> > On Thu, 2024-05-23 at 18:37 -0400, Robert McBroom via users wrote:
> > > This thread has been on before but I lost it. I need my system to
> > > run
> > > long simulations without my intervention. It keeps going to a
> > > reboot
> > > intermittently.  The program has recovery that all is not lost
> > > with a
> > > shutdown but the time getting back to check on the system.  Don't
> > > remember the setting to tell fedora what to do for always on
> > > systems.
> > There's some info about systems suspending after a certain amount
> > of
> > (perhaps ill-conceived ideas of) idleness:
> > 
> > https://discussion.fedoraproject.org/t/gnome-suspends-after-15-minutes-of-user-inactivity-even-on-ac-power/79801
> > 
> > But if it's rebooting rather than simply shutting down, I wonder if
> > something is crashing?
> Quirk of multi os system. Windows is first in the boot/efi list so a 
> restore from sleep starts windows not any of the linux systems

You can change that using efibootmanager.

poc
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[gentoo-commits] repo/gentoo:master commit in: dev-util/bpftop/

commit: 06cf905e2f055d06ae4c382c88fa7862ff82d769
Author: Patrick McLean  gentoo  org>
AuthorDate: Fri May 24 19:10:27 2024 +
Commit:     Patrick McLean  gentoo  org>
CommitDate: Fri May 24 19:10:27 2024 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=06cf905e

dev-util/bpftop: add 0.5.1

Signed-off-by: Patrick McLean  gentoo.org>

 dev-util/bpftop/Manifest| 122 ++
 dev-util/bpftop/bpftop-0.5.1.ebuild | 203 
 2 files changed, 325 insertions(+)

diff --git a/dev-util/bpftop/Manifest b/dev-util/bpftop/Manifest
index 2d00a66e96a0..7de364d48e87 100644
--- a/dev-util/bpftop/Manifest
+++ b/dev-util/bpftop/Manifest
@@ -1,89 +1,211 @@
+DIST adler-1.0.2.crate 12778 BLAKE2B 
a1dc17786adae945ac09d3525e609ed944e6465690787bbb831a1b9d53793cba1989793d0a5606d5d23ee20d36457923d451b1b3530c9ec7072a487aa3e55bbd
 SHA512 
7ab190d31890fc05b0b55d8e2c6527a505e06793d5496be0b3831e0513412f9ba97f8148f6f68ed0770fa9cd980a5092d885e058becf1d5506b7c74b82674aa1
+DIST ahash-0.8.11.crate 43607 BLAKE2B 
7dff8e41798ba25df8c4827ff414a182bb25da4825f0119a74916fe775db5445b87be8fc87f7c7f98d3b5053e1d47546f98873de1a942d36e5f308a3fb7dd620
 SHA512 
47d211b2422de0b381dfe32229faa346406eb7a22dff867dc04c22389609a8671ce3218e662000c49891a06c259d82e0ff4413740f007729d80e097a6c3f0d9d
 DIST ahash-0.8.7.crate 42894 BLAKE2B 
56f4b2f577eb2752e675fa2b3191c65e0bb88575f92e8d906714296fca1daace46e93256672fce08cc5b4ac11d40a690a06b32a99fb50fd0df4f042773c33b6c
 SHA512 
2c9eaa22f7bda47a781994c769d4a2ef15ba0f511fdd4ec4680c13d4c1809f1ce01adecc3b3776793158062d28ad9e5f0b1d1c0a9429e43dd07cd99540eae7a6
+DIST aho-corasick-1.1.3.crate 183311 BLAKE2B 
8dfcbba0b9d94e55eae739b16f5c6474baa43ee7854c5ca792f426a9f46fb0eece79cd493b804e51449181bcad338b96819fe977c02c9907654d713e26b9f830
 SHA512 
ba422a54688c4678fcf16e34fdf3ed06c333e6e3fc8b75af9272a215add494d43ebaef319021134b61327fd5d3572aec0dc655b714ffb3bc71ba3c265c9ebb69
 DIST allocator-api2-0.2.16.crate 59025 BLAKE2B 
fda69b52435a7243eb19bc55914a1961e59dbad5ac12c40db39cccdf7a99c742da59c3ef160350808698db24b91e0ce655cd1acedbbcbe20c717604aae23ea5e
 SHA512 
e1eb0df6b44b62115795ebf772f81e9ac0b6d273afd81659dbddb7eb6628b6e5ef6a60ea21413e79ee638afb72e6872ba83a075f6324daf93f2f1eda48daff2f
+DIST allocator-api2-0.2.18.crate 62504 BLAKE2B 
8152c5a611be91ba23b1e8647511e21f48e7d4f1a7b9a828083f5bb8747cdc92aee66f73251b19195bbdc1f65aad992632e820d86cbeff287d598257ae3628a6
 SHA512 
5e5b0e23e1f5b259e5d3746e3e05817af8dee95af7105ea775a5c1d69b4e537a4d6a25e2c1d46ab83e2385217b158f7940dc1315ae581c35ee23289647105e73
+DIST android-tzdata-0.1.1.crate 7674 BLAKE2B 
4385a4875aadaacd5284a9ca7d1bf8a7bf14bf8925d1563d52fbabacc3af2c1ea08bfcf77106f3648f4fa052ac295158a21e7a0131d31eb9aecd99ea4ba20055
 SHA512 
4294024c21ddd0090c42c8eedf708d40d917f55ad5a4cb7aa3e64cfb6551b6df60f2e36bc08620c1d2fc8c7ba7207411518ee5c8635f60ed8ad9efdd458a2077
+DIST android_system_properties-0.1.5.crate 5243 BLAKE2B 
86f68ec3bdabf8c6ec47881d794970f08a9eefc7417fc8a2bf4fe9faf9bdd2a2024a94adb0cbf96673409f5fbbd4d0111a1ac371339e7a90a277b6cd5003524e
 SHA512 
b09f51339f9772c0e2e4241b36cf51573c6b96b19ffc1fbbc94b1c1d1d2fdfe8eac3134af54174a675ab05d18ef4f6bcb2c7fcc20114bbeef6e17e3692202191
+DIST anstream-0.6.14.crate 29160 BLAKE2B 
1120895a51ed7a285c5d5a03d2f7e26dc956d95f39cf500ba9f547d71a62ed0326f519860ddcf8db77cb09e9119e914a62693369eca51cbf9c01ef874ade9112
 SHA512 
65ece20958e3fb1ed4a5ff1d45f5bfdcb942c64994a3d14eefb0dfd5b04f433f6e1b06ebff240c67ed8ff7cc01d93ca0acf8c8ea29cb41309c6c882e7c192b34
+DIST anstyle-1.0.7.crate 15709 BLAKE2B 
872e0ed09e7e94c6f6b812349e39f949aff4d7cbb87744ab26fe49f57a7d330e0f79447213374f7f862ea276aab2dd1077dc8df3f7c5f34079ef30c4d17eeeba
 SHA512 
e20d49f7d148e03f7b127be7802e0b6b7a2b05720614d46c2ade5e440ce322b44ddd3a9239b897886faa03ed1cb30f947ee27d3811fa83dffba10b3975eba7ed
+DIST anstyle-parse-0.2.4.crate 23069 BLAKE2B 
e80bd81e351326a38b3f559020a2430ac37293e61b6b6309b37bbb8bdb78ec11ca9c0fd270098af5e5ffb2f5660cfbfda949d20fd2efd336ed1c143215b2
 SHA512 
c1dac475df77d090a4d2041ba40ff418abe66e93e4ddda54653bf024fb4995e431166684343509a2337bc813fe06f362d3df8a1d7d05d177cec1a488bcb9942a
+DIST anstyle-query-1.0.3.crate 9742 BLAKE2B 
cfcba0a2773f07b9292279afd70832c5d4eb441ed61bcacdbeeda9184c63b7e01af70a8744d6efceb7f74a2c2dfa5672b873255cc1d273bd6a2d3d7ee08c2d2b
 SHA512 
38637f49e547836a4958d9f528cb270abfc81c5ca644d6d43b0f3aaef8c6f1301a8bc30a23afec5e71722c3afe7eb0f48f9fdea88b73e36f597b74531da84226
+DIST anstyle-wincon-3.0.3.crate 12179 BLAKE2B 
37793975a05ad60bb2b670c208db11c5cda8a2a456242cd118748709d0a220b541b6f088676eccd19870cfb8f910d4aa1e7764393785a6db0531af4a3ffc8047
 SHA512 
55217c65fc9ec674e5b4dd70716a221bd108b507dce9baaeb542f0e0a47027ec7fe61f9cd3cccfda43e4a4cd785b42f13400daf89884c32d3768e48bdff2d179
 DIST anyhow-1.0.80.crate 45138 BLAKE2B 
4985d3d8f1d5b5886fae5c7d1a61f921d3d64fb51e24710044b85dfadd2dae2b25b8995cab419cb7cdb5c8cb6b50ad0de93b9a942d34bc45014bd5fb9aecbd3

[gentoo-commits] repo/gentoo:master commit in: dev-libs/simdjson/

commit: efb7b1d7fcb468f848bf3c47904b7cfa8f18e585
Author: Patrick McLean  gentoo  org>
AuthorDate: Fri May 24 19:00:52 2024 +
Commit:     Patrick McLean  gentoo  org>
CommitDate: Fri May 24 19:00:52 2024 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=efb7b1d7

dev-libs/simdjson: add 3.9.2

Signed-off-by: Patrick McLean  gentoo.org>

 dev-libs/simdjson/Manifest  |   1 +
 dev-libs/simdjson/simdjson-3.9.2.ebuild | 103 
 2 files changed, 104 insertions(+)

diff --git a/dev-libs/simdjson/Manifest b/dev-libs/simdjson/Manifest
index b26a7d8c5b5c..8a4aeaf4ce5d 100644
--- a/dev-libs/simdjson/Manifest
+++ b/dev-libs/simdjson/Manifest
@@ -2,4 +2,5 @@ DIST simdjson-3.6.3.gh.tar.gz 2302220 BLAKE2B 
c46eeb8a07460cc5427fc35714fd262069
 DIST simdjson-3.6.4.gh.tar.gz 2301736 BLAKE2B 
512effe54c6d36e31c95983cd9bd2ddb000c979c5050cb0c4b8ae2eae743ec50720e15ccf8b457b085d7d5bea24e0a0f793cba97a0af35dedbe59cab105ab2b9
 SHA512 
30dbc39166f092808d8642a2e4ca37c10999c511aa90e349409b3f4765c638498070ed9ed53ec7bfda9a9442557c7407ee0468a0845d53346d4a990f6d8c3c5b
 DIST simdjson-3.7.1.gh.tar.gz 2319851 BLAKE2B 
06de2f3dbdb65e7cd5aa418ecb7db27ae01f1e205e355f4d8cb38929d284407bb3edc93a5ee13e30457123ee83bdee35923a265ada520ff94365d1eb71de6ccb
 SHA512 
536f2cd174d50890611942accdcc5b41f5a0d0bc6f03d5627a64c75fa6d88efc9bf4304da4c4607b472223d2a713edaeecbfa66e0e7e5efa1f45a60c93eee96a
 DIST simdjson-3.9.1.gh.tar.gz 2636602 BLAKE2B 
82c4956ebc902574ed1b36196097c6c07e9ca0f11384f71b260ae95ff5e7c436ce016da417197f84c21ece0ae2239fc1c4e02cf63672fae98b3fa69831de3adb
 SHA512 
b8c091e7ecce4cdc67f538ab6715ce89bff16e68f6d56bdc37e05ab0b110b90bc6b039d5c76e2dceef9e30f35cb6ace5e4e230d4c70e928329a376f989b23bed
+DIST simdjson-3.9.2.gh.tar.gz 2638581 BLAKE2B 
987702626ad08ad8021488c76b096627ac2b0448294bf2155cb9892b5b1f3621e61c2829e4bae3b8b5ff3f6978b89cf45dc00bf8291e578dab3e9e525eb6a622
 SHA512 
7ef6b0c054cb2d2b87b79d8ad35435b953fb5f9c062de4c0206487dd8e13948c9389d7fbc4cd53505888a98567bdc9cd28bcd525a3ce0651d0ed5e1a7fe694e9
 DIST simdjson-data-a5b13babe65c1bba7186b41b43d4cbdc20a5c470.tar.gz 6635706 
BLAKE2B 
563376147f18d590a176a5a0398365db1a3e677b773c018f335efa7fff05ac22ac5dc37613792082a32e6c9b91a773a590f7dfd15efa5ba660f9142b128b28a7
 SHA512 
168198404b11b8c76ff4f53645d7b5a88a5c72b4a5b6646b4410859ec3416ae9b37fc59f7d2f014ccc785615ea5c31dc00b145dbb1a7acb701b94029dd4ea1e1

diff --git a/dev-libs/simdjson/simdjson-3.9.2.ebuild 
b/dev-libs/simdjson/simdjson-3.9.2.ebuild
new file mode 100644
index ..1936e556eb93
--- /dev/null
+++ b/dev-libs/simdjson/simdjson-3.9.2.ebuild
@@ -0,0 +1,103 @@
+# Copyright 2020-2024 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=8
+
+inherit toolchain-funcs cmake
+
+DATA_HASH="a5b13babe65c1bba7186b41b43d4cbdc20a5c470"
+DESCRIPTION="SIMD accelerated C++ JSON library"
+HOMEPAGE="
+   https://simdjson.org/
+   https://github.com/simdjson/simdjson
+"
+SRC_URI="
+   https://github.com/${PN}/${PN}/archive/v${PV}.tar.gz -> ${P}.gh.tar.gz
+   test? ( https://github.com/${PN}/${PN}-data/archive/${DATA_HASH}.tar.gz 
-> ${PN}-data-${DATA_HASH}.tar.gz )
+"
+
+LICENSE="Apache-2.0 Boost-1.0 BSD MIT"
+SLOT="0/22"
+KEYWORDS="~amd64 ~arm ~arm64 ~loong ~ppc64 ~riscv ~x86"
+IUSE="+all-impls test tools"
+
+BDEPEND="
+   sys-apps/file
+   sys-apps/grep
+   virtual/pkgconfig
+"
+DEPEND="
+   tools? (

[gentoo-commits] repo/gentoo:master commit in: dev-util/difftastic/

commit: 0bb3d72edb1a75cc3fd1fcc9c602de500e6ba432
Author: Patrick McLean  gentoo  org>
AuthorDate: Fri May 24 18:43:10 2024 +
Commit:     Patrick McLean  gentoo  org>
CommitDate: Fri May 24 18:43:54 2024 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0bb3d72e

dev-util/difftastic: add 0.58.0

Signed-off-by: Patrick McLean  gentoo.org>

 dev-util/difftastic/Manifest |   3 +
 dev-util/difftastic/difftastic-0.58.0.ebuild | 195 +++
 2 files changed, 198 insertions(+)

diff --git a/dev-util/difftastic/Manifest b/dev-util/difftastic/Manifest
index 2a944137e723..829c393d9727 100644
--- a/dev-util/difftastic/Manifest
+++ b/dev-util/difftastic/Manifest
@@ -4,6 +4,7 @@ DIST aho-corasick-1.0.5.crate 172064 BLAKE2B 
bab7767070b959e8e4c054bf505b9423d7f
 DIST aho-corasick-1.1.3.crate 183311 BLAKE2B 
8dfcbba0b9d94e55eae739b16f5c6474baa43ee7854c5ca792f426a9f46fb0eece79cd493b804e51449181bcad338b96819fe977c02c9907654d713e26b9f830
 SHA512 
ba422a54688c4678fcf16e34fdf3ed06c333e6e3fc8b75af9272a215add494d43ebaef319021134b61327fd5d3572aec0dc655b714ffb3bc71ba3c265c9ebb69
 DIST allocator-api2-0.2.16.crate 59025 BLAKE2B 
fda69b52435a7243eb19bc55914a1961e59dbad5ac12c40db39cccdf7a99c742da59c3ef160350808698db24b91e0ce655cd1acedbbcbe20c717604aae23ea5e
 SHA512 
e1eb0df6b44b62115795ebf772f81e9ac0b6d273afd81659dbddb7eb6628b6e5ef6a60ea21413e79ee638afb72e6872ba83a075f6324daf93f2f1eda48daff2f
 DIST assert_cmd-2.0.5.crate 22683 BLAKE2B 
cea13643d387466d0e18a2d15b97ae329d1023ed409a5bb29e2d25b3e958e72e801b5779a12ab4cd2f42d0e865296d06b30db1acf65f8c3a0f23c0a33a7519bd
 SHA512 
21046c01a6ca5b6cc679dd69914fdda75a5c9c17a572378d59ca17fce3952416dd95d25e3639d6f416f811f4c6485191c92f6bececd53c3644bbfd0a0c3b9c8f
+DIST assert_cmd-2.0.8.crate 24347 BLAKE2B 
b69beb301a11e893ee1c7b59a08ac7860c16a598dc404d7bfd38b2554790898cfb82d1e602750e9b720b4122154e4da140c7b077645786f0a788796d5dafe272
 SHA512 
886d789af9fe7f8155d393e2742c7982d5c0bb8d44a09f66e5552faed2effcedd000d567f9f00e08ad6d7c17fac9374d7a234ba001f38c9cf444ee41dbe07428
 DIST atty-0.2.14.crate 5470 BLAKE2B 
2db856a9e898a430258f059aeaf7c844a153293e8856d90ac81f7d91a888c89198768ad5cb09303c23241fe85c560a55148fa56a303651a82b0edb895616bfab
 SHA512 
d7b6c4b9a0f898d91ddbc41a5ee45bbf45d1d269508c8cc87ee3e3990500e41e0ec387afb1f3bc7db55bedac396dd86c6509f4bf9e5148d809c3802edcc5e1d9
 DIST autocfg-1.1.0.crate 13272 BLAKE2B 
7724055c337d562103f191f4e36cab469e578f0c51cc24d33624dea155d108a07578703766341fd6a4cc1ef52acda406e7dba1650d59115f18261281e5b40203
 SHA512 
df972c09abbdc0b6cb6bb55b1e29c7fed706ece38a62613d9e275bac46a19574a7f96f0152cccb0239efea04ee90083a146b58b15307696c4c81878cd12de28f
 DIST bitflags-1.3.2.crate 23021 BLAKE2B 
eb990bb27b2bdeb66fd7212ce582cb36e1c616debbac85df642d0c82b25439e6bf9b1e811fac76b59e58ea3c1bbea6170d03a61e8f9a395e4334a0e2e2987eda
 SHA512 
3c698f757b5cc62f815f9a1cce365c3d2dd88e4db71f331dff8bba86c2865f755b81cb4c9bfc59bd86b7643b0943f9e09a7c4f8ad75eb2ab0e714803d0129f62
@@ -42,6 +43,7 @@ DIST difflib-0.4.0.crate 7638 BLAKE2B 
57c703de0d467c997bcbedc4d6577569b3d72c612d
 DIST difftastic-0.54.0.gh.tar.gz 58647254 BLAKE2B 
93900c7a89399893e44bffcd010b5201e540d76aca22a753cc4e16cae51695004d5bcdeba7c7dc6e5a8d4669ac6cc18ceb151bbb77f5ff18a24daae7319ae17d
 SHA512 
8dd476fedc9638cddb7391b127dc563f1dfeba5a2c74c00eda6673dd4aa59b6e1eb5ddf3d72ca34996a6aca4cd5de545d5fbe1419ceaa0062cc9f3bf8c82c9e7
 DIST difftastic-0.55.0.gh.tar.gz 61809092 BLAKE2B 
28a5b0da275f886f0960b870d3d171969df58ff99c2a67a143c4fe167ae1056daebda0e8df0d71bbb604fd66d6c91c8021501bf9b54540bf499ddc43ff8972d5
 SHA512 
1a597a9bce65e996bbae1a3403f3f2f9f3db9a7e805908334f134a84bc42749b9b13bd2e50d97c032d5e274e3416d99b8563a6e6f9729f4bbda7b4b04dd2bac5
 DIST difftastic-0.57.0.gh.tar.gz 42654201 BLAKE2B 
f5772e29537eef6775ce2d731f4ea15ed04c3534e724fd4eaada02aeeb376b773a66b31ff4db9c8eb9d0b5c8311bb76fbf3a48756c4785692b9b487f76329a47
 SHA512 
30303a50b6d7daca7dd2d8ed40aa157e16eef52df01c5605ebcdb53789d252ca526d34156c2f6e842ca90e4cabe89ab7f2b0ce05058ca7b59dffa1d9d60fe9a5
+DIST difftastic-0.58.0.gh.tar.gz 42962336 BLAKE2B 
88f3ebea8ed3f00406da4679a8b26226b54d27c29215b41b7622d2f30f185de0b673972da678dff78e6ee7a932ccce290996bd61038c7a040c48ee228393b7a5
 SHA512 
b6bd3f8919df84aa084e645552a2ce468b2112a245f1757889b353243007ad08ff5cd5d144bf290624db643a9ef5f8607398a7686974e2c450010baf95b883c0
 DIST doc-comment-0.3.3.crate 4123 BLAKE2B 
a82d1c1a7a90af6e111b5e684a1298d7eac5fd8e4bf7d5baf6c7403d26b609958716d57e51122fe7ad7626fe00a2d824dcfef3cc2fd7679fdb7b5099603de1cd
 SHA512 
e98ff9646a3612bd41bb6f278e7b6e9a0c58747f8b82524da814cf51b7f06c76ad4d65b502ac5740e818744abb295f78f15f8262d0b50ced1523f6d1a26939ba
 DIST either-1.10.0.crate 18334 BLAKE2B 
ac5d81e0822132846e29f8959671b14ac6047330d54020ea7d4ad790ef985ecb4ddcb96ec7e327b1a66b9c89d37b112dae33c9ac35232c136f60ad9baab7d5a2
 SHA512 
2de38a37b7f3e61effa89648acadbf220eacfda1ca7c82fb77484e45577769b724f7dbaa297e73e3d355d6b1bd5109373c3e96e4c1a13a918176162

[gentoo-commits] repo/gentoo:master commit in: dev-vcs/tig/

commit: a4c31d1baf9555c4c1d388bbe282877e13ebcef6
Author: Patrick McLean  gentoo  org>
AuthorDate: Fri May 24 17:46:09 2024 +
Commit:     Patrick McLean  gentoo  org>
CommitDate: Fri May 24 18:26:28 2024 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=a4c31d1b

dev-vcs/tig: add 2.5.10

Signed-off-by: Patrick McLean  gentoo.org>

 dev-vcs/tig/Manifest  |  1 +
 dev-vcs/tig/tig-2.5.10.ebuild | 66 +++
 2 files changed, 67 insertions(+)

diff --git a/dev-vcs/tig/Manifest b/dev-vcs/tig/Manifest
index 1672674199e1..775e3a301a49 100644
--- a/dev-vcs/tig/Manifest
+++ b/dev-vcs/tig/Manifest
@@ -1 +1,2 @@
+DIST tig-2.5.10.tar.gz 1183631 BLAKE2B 
a2d58e9a79bf7fdabf74704a04f2d0dee30e8fd348319786ab639119c0912c3dc632a143ef586b24f33841a040f1c06101cb52f3a8e8e8a7ee36cc175685fba9
 SHA512 
6b89a2edebfc58cd2f5e855bbd2137ba4e1be65e793c04a7a9858f3a32b31681f5a80f33e5c1d2d69104e4c37817d806a70ab9a1fc8807d5f49751d4f283d788
 DIST tig-2.5.8.tar.gz 1179844 BLAKE2B 
eff20358443bd794de2985e1c76db8be25f4461ac82182a72004ab380156c15c5ed27dc1c66fb347b1f3d1ccddcead0a031638762e48f7e88a3b0593a278d3d7
 SHA512 
f4e7648ae7c58e936251f69071a092617368a04eabb4ae6726b2de1dbd305c559b7235f7aa70868f4ada02611196593a6e1c241062f57cd05a9c98685385053e

diff --git a/dev-vcs/tig/tig-2.5.10.ebuild b/dev-vcs/tig/tig-2.5.10.ebuild
new file mode 100644
index ..53f71e86c348
--- /dev/null
+++ b/dev-vcs/tig/tig-2.5.10.ebuild
@@ -0,0 +1,66 @@
+# Copyright 1999-2024 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=8
+
+inherit bash-completion-r1
+
+if [[ ${PV} == "" ]] ; then
+   EGIT_REPO_URI="https://github.com/jonas/tig.git;
+   inherit git-r3 autotools
+else
+   
SRC_URI="https://github.com/jonas/tig/releases/download/${P}/${P}.tar.gz;
+   KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~mips ~ppc ~ppc64 
~riscv ~s390 ~sparc ~x86 ~amd64-linux ~x86-linux ~ppc-macos"
+fi
+
+DESCRIPTION="text mode interface for git"
+HOMEPAGE="https://jonas.github.io/tig/;
+
+LICENSE="GPL-2"
+SLOT="0"
+IUSE="pcre test unicode"
+REQUIRED_USE="test? ( unicode )"
+
+DEPEND="
+   sys-libs/ncurses:=[unicode(+)?]
+   sys-libs/readline:0=
+   pcre? ( dev-libs/libpcre2:= )
+"
+RDEPEND="
+   ${DEPEND}
+   dev-vcs/git
+"
+[[ ${PV} == "" ]] && BDEPEND+=" app-text/asciidoc app-text/xmlto"
+
+# encoding/env issues
+RESTRICT="test"
+
+src_prepare() {
+   default
+   [[ ${PV} == "" ]] && eautoreconf
+}
+
+src_configure() {
+   econf \
+   $(use_with pcre) \
+   $(use_with unicode ncursesw)
+}
+
+src_compile() {
+   emake V=1
+   [[ ${PV} == "" ]] && emake V=1 doc-man doc-html
+}
+
+src_test() {
+   # workaround parallel test failures
+   LC_ALL=en_US.utf8 emake -j1 test
+}
+
+src_install() {
+   emake DESTDIR="${D}" install install-doc-man
+   dodoc doc/manual.html README.html NEWS.html
+   newbashcomp contrib/tig-completion.bash ${PN}
+
+   docinto examples
+   dodoc contrib/*.tigrc
+}

[gentoo-commits] repo/gentoo:master commit in: dev-util/cargo-tarpaulin/

commit: 40fd2f587747018c235c23f706394b5004cb271d
Author: Patrick McLean  gentoo  org>
AuthorDate: Fri May 24 17:56:52 2024 +
Commit:     Patrick McLean  gentoo  org>
CommitDate: Fri May 24 18:26:28 2024 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=40fd2f58

dev-util/cargo-tarpaulin: add 0.30.0, drop 0.28.0

Signed-off-by: Patrick McLean  gentoo.org>

 dev-util/cargo-tarpaulin/Manifest  | 109 +---
 ...0.28.0.ebuild => cargo-tarpaulin-0.30.0.ebuild} | 111 ++---
 2 files changed, 99 insertions(+), 121 deletions(-)

diff --git a/dev-util/cargo-tarpaulin/Manifest 
b/dev-util/cargo-tarpaulin/Manifest
index 7f0405ed6e57..1a3c0e533121 100644
--- a/dev-util/cargo-tarpaulin/Manifest
+++ b/dev-util/cargo-tarpaulin/Manifest
@@ -4,15 +4,13 @@ DIST adler32-1.2.0.crate 6411 BLAKE2B 
51d44ccfd774158687b8244e83377e40ff896364e3
 DIST aho-corasick-1.1.3.crate 183311 BLAKE2B 
8dfcbba0b9d94e55eae739b16f5c6474baa43ee7854c5ca792f426a9f46fb0eece79cd493b804e51449181bcad338b96819fe977c02c9907654d713e26b9f830
 SHA512 
ba422a54688c4678fcf16e34fdf3ed06c333e6e3fc8b75af9272a215add494d43ebaef319021134b61327fd5d3572aec0dc655b714ffb3bc71ba3c265c9ebb69
 DIST android-tzdata-0.1.1.crate 7674 BLAKE2B 
4385a4875aadaacd5284a9ca7d1bf8a7bf14bf8925d1563d52fbabacc3af2c1ea08bfcf77106f3648f4fa052ac295158a21e7a0131d31eb9aecd99ea4ba20055
 SHA512 
4294024c21ddd0090c42c8eedf708d40d917f55ad5a4cb7aa3e64cfb6551b6df60f2e36bc08620c1d2fc8c7ba7207411518ee5c8635f60ed8ad9efdd458a2077
 DIST android_system_properties-0.1.5.crate 5243 BLAKE2B 
86f68ec3bdabf8c6ec47881d794970f08a9eefc7417fc8a2bf4fe9faf9bdd2a2024a94adb0cbf96673409f5fbbd4d0111a1ac371339e7a90a277b6cd5003524e
 SHA512 
b09f51339f9772c0e2e4241b36cf51573c6b96b19ffc1fbbc94b1c1d1d2fdfe8eac3134af54174a675ab05d18ef4f6bcb2c7fcc20114bbeef6e17e3692202191
-DIST ansi_term-0.12.1.crate 24838 BLAKE2B 
f636772c34e2d68cda7b8d3b2b86abda074585a62bd2654812ce92384244655a9197fa66e6939e19a674c0148ca605313d83de262bb18c2339a8a4eb4438a791
 SHA512 
b840e28b3e7700689a69a39659b1e066560078dd4a58326b91a028915819e7af883399ee53e920db68fd974c58d35bb1ddf8d427af5937d5f696f57c4376b671
-DIST anstream-0.6.13.crate 30928 BLAKE2B 
0c6d0932dc486ccbe8d7e6f97bd8aae03fb84d4db90d0488070b7109de673e0af845a70a39e546af87f71f4c7f7bb159ab8ed68ac0f03a0297457062d9d69dc0
 SHA512 
4f9ccfd135de9be22a01230f39d571c8d8ccf7c3eba837fbf0868c9660693b60ee0c1c2f9490a587d5307e892ed45cb946da7a0690a9f972619c94fb050bde09
-DIST anstyle-1.0.6.crate 14604 BLAKE2B 
0716d0dbb62bf05c63c2bfe1c689896660073a423d26965ce2570f11e1925752a61209d78c2f2fe65ec4eb64ea4ffbb39669e789c0ba5d1b71e75de929153b20
 SHA512 
dc0e505465be54799b9faad70d0c6f7f0dcf9f5e1aaa43177b826c85dae626b054910244da0499862f066f6723a1560ad12100aec523f28c6198f1ea0d1b78fa
-DIST anstyle-parse-0.2.3.crate 24699 BLAKE2B 
17e8638187ccc1ca0174a8cec7f7daeee7e0d8b8c430f7e74f9b10d8de4b49fd1c6facfdafde305b7a3e55b1ebf2b4e8ec4975a0cce691514ddae9eb5b5e711e
 SHA512 
4a6d0f706d75c9b3c5144f34efdef3ef8fcd075962c594a23a6209ed56112563a34b3c01e05a08a0868d59204272d06211b2585cb9d06ce075ea875bedb2f399
-DIST anstyle-query-1.0.2.crate 8739 BLAKE2B 
c06643e8616f1f4469a32f9c0512941ce53ac5db9ebfa7a5b2f19233040cd4438dd2ee69ab89ecbc1c239e92b674dea9df15ed673408c6f3fe21787cc17d76f3
 SHA512 
f409b624cbeecf58fd87c47f85be28cae1fe48f65d692195fb80854c514e38c40d0e0ffad3a5b388a3929c47bd2060302ebb635aa98dc57329f3a5ed7be3e2dc
-DIST anstyle-wincon-3.0.2.crate 11272 BLAKE2B 
73e124773f618a744b17017d4680ec6ccc84ff94fbe2e565073fbcc0facecd3cb65356cf27746d07f453bc917cbeb2ade3a618c6b8578d64cff4828c99569868
 SHA512 
4cc194faacffa01c6989354c1cadbf1134f0945250f67b7020ab5b475e30db34c799176bd335a6265386cb9c5e8b5bcbdf35894ec0c809b140ffe1c406751931
-DIST anyhow-1.0.82.crate 45361 BLAKE2B 
558bac4de847a432fc80427e7be4e78cae4b01c4da852eae2121416af4d7e6ddeaeffd7de9bb69e55340b9a228436b975fdea88e380391a77c782a3776b835dd
 SHA512 
e0d25a8c0b9c45e1db2072618097aff3908f70bfcbf0963d3c9dd9c97be27a85c4a763c5cb74e1ccd1b0a2059360e0879df4be80e10e58e0a5346b65f4fa1a69
-DIST atty-0.2.14.crate 5470 BLAKE2B 
2db856a9e898a430258f059aeaf7c844a153293e8856d90ac81f7d91a888c89198768ad5cb09303c23241fe85c560a55148fa56a303651a82b0edb895616bfab
 SHA512 
d7b6c4b9a0f898d91ddbc41a5ee45bbf45d1d269508c8cc87ee3e3990500e41e0ec387afb1f3bc7db55bedac396dd86c6509f4bf9e5148d809c3802edcc5e1d9
-DIST autocfg-1.2.0.crate 14808 BLAKE2B 
122327d6ffd32e08dc9fbdb4dcf69128b19d56280f9d934311b946741003b40571cdd1f3ef54b2be02c8dc505aea11c962b244d33a92206bf4ee8f6b2b9da432
 SHA512 
66cbfd13e33b36284cf4c74c8d654f93adcc45893d127d9aaa4c1d183e47336096e72d74e7c17dd481fb7a98931ab6cfec7e4d4165cfb491861d4e3ffe2416fc
+DIST anstream-0.6.14.crate 29160 BLAKE2B 
1120895a51ed7a285c5d5a03d2f7e26dc956d95f39cf500ba9f547d71a62ed0326f519860ddcf8db77cb09e9119e914a62693369eca51cbf9c01ef874ade9112
 SHA512 
65ece20958e3fb1ed4a5ff1d45f5bfdcb942c64994a3d14eefb0dfd5b04f433f6e1b06ebff240c67ed8ff7cc01d93ca0acf8c8ea29cb41309c6c882e7c192b34
+DIST anstyle-1.0.7

[gentoo-commits] repo/gentoo:master commit in: app-misc/check-jsonschema/

commit: 8611c860bc3b33f55611d61f30e8cbd052a563bb
Author: Patrick McLean  gentoo  org>
AuthorDate: Fri May 24 18:26:19 2024 +
Commit:     Patrick McLean  gentoo  org>
CommitDate: Fri May 24 18:26:29 2024 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=8611c860

app-misc/check-jsonschema: add 0.28.4

Signed-off-by: Patrick McLean  gentoo.org>

 app-misc/check-jsonschema/Manifest |  1 +
 .../check-jsonschema-0.28.4.ebuild | 58 ++
 2 files changed, 59 insertions(+)

diff --git a/app-misc/check-jsonschema/Manifest 
b/app-misc/check-jsonschema/Manifest
index d76976b7fc45..d5f1c7620cba 100644
--- a/app-misc/check-jsonschema/Manifest
+++ b/app-misc/check-jsonschema/Manifest
@@ -1,2 +1,3 @@
 DIST check-jsonschema-0.21.0.gh.tar.gz 214872 BLAKE2B 
0ee013e379523e5a957e745d550c2014872eab9fc3281aad575f92abfada30b7e0853177bd06147b69a81100bf6b987b485342a087830845c32648efc1c7a9a0
 SHA512 
dd839a9bb104e1fc68e4a7507077dc991dfc9e840f785c4b7024f2838488eb8b8c6a8f7718f0f821981f5b6b23b1d67745948f48db55a0c589395cf43bfdd2a7
 DIST check-jsonschema-0.23.3.gh.tar.gz 229537 BLAKE2B 
a8a40ddc383f38096693a2079b73a8a8fe2ceed5d1e118e539957c205c500807518c0380aa18cae2524efdeda33987f057350ba73b7a699240706ff4e276eafc
 SHA512 
14f9eb6b203e3aec6ca35f75304bd24fd5a09c2b89bcbbf69c22e0c0f44c587972015677498fef1a378683c77f94d9319450daccadddf5fecbe7c738dd16c726
+DIST check-jsonschema-0.28.4.gh.tar.gz 270302 BLAKE2B 
a5355ed124d6e3bd076403448c3d7fa7c62524c6da49eb5a61d226485639812bdea28b53c570b084e976749b92c1ee586b0285111a543b1a3e8a734ea8d6cc67
 SHA512 
f4c693ea0951c246814775f26d5c3e5de8020484a92ae15e2a13e284ccb2c58f2bdf7dbdb66612661304f5ff9e6ba88eb3f89e7f0ad23a3f6fc8fcc61372ceea

diff --git a/app-misc/check-jsonschema/check-jsonschema-0.28.4.ebuild 
b/app-misc/check-jsonschema/check-jsonschema-0.28.4.ebuild
new file mode 100644
index ..82adc69ea0e5
--- /dev/null
+++ b/app-misc/check-jsonschema/check-jsonschema-0.28.4.ebuild
@@ -0,0 +1,58 @@
+# Copyright 2023-2024 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=8
+
+PYTHON_COMPAT=( python3_{10..12} pypy3 )
+DISTUTILS_USE_PEP517=setuptools
+inherit optfeature distutils-r1
+
+DESCRIPTION="A CLI and set of pre-commit hooks for jsonschema validation"
+HOMEPAGE="
+   https://pypi.org/project/check-jsonschema/
+   https://github.com/python-jsonschema/check-jsonschema
+"
+SRC_URI="https://github.com/python-jsonschema/${PN}/archive/refs/tags/${PV}.tar.gz
 -> ${P}.gh.tar.gz"
+
+LICENSE="Apache-2.0"
+SLOT="0"
+KEYWORDS="~amd64"
+
+RDEPEND="
+   >=dev-python/ruamel-yaml-0.18.6[${PYTHON_USEDEP}]
+   >=dev-python/jsonschema-4.5.1[${PYTHON_USEDEP}]
+   dev-python/regress[${PYTHON_USEDEP}]
+   dev-python/requests[${PYTHON_USEDEP}]
+   dev-python/click[${PYTHON_USEDEP}]
+   dev-python/tomli[${PYTHON_USEDEP}]
+"
+BDEPEND="
+   test? (
+   ${RDEPEND}
+   dev-python/json5[${PYTHON_USEDEP}]
+   dev-python/pytest-xdist[${PYTHON_USEDEP}]
+   >=dev-python/responses-0.25.0[${PYTHON_USEDEP}]
+   )
+"
+
+DOCS=(
+   README.md
+   CONTRIBUTING.md
+   CHANGELOG.rst
+)
+
+distutils_enable_tests pytest
+distutils_enable_sphinx docs \
+   dev-python/sphinx-issues \
+   dev-python/furo
+
+python_prepare_all() {
+   # relax deps in setup.cfg
+   sed -r -e 's:([a-zA-Z.-]+)([<>]|==|[<>]=)+.+:\1: ; 
/importlib-resources/ d' -i setup.cfg || die
+
+   distutils-r1_python_prepare_all
+}
+
+pkg_postinst() {
+   optfeature "json5 support" dev-python/json5
+}

[gentoo-commits] repo/gentoo:master commit in: dev-libs/libbpf/

commit: e89a4ea024ec25bc26ddb60e3f7fdc17c1ed9b09
Author: Patrick McLean  gentoo  org>
AuthorDate: Fri May 24 17:49:05 2024 +
Commit:     Patrick McLean  gentoo  org>
CommitDate: Fri May 24 18:26:28 2024 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e89a4ea0

dev-libs/libbpf: add 1.4.2

Signed-off-by: Patrick McLean  gentoo.org>

 dev-libs/libbpf/Manifest|  1 +
 dev-libs/libbpf/libbpf-1.4.2.ebuild | 65 +
 2 files changed, 66 insertions(+)

diff --git a/dev-libs/libbpf/Manifest b/dev-libs/libbpf/Manifest
index 2cbf2e2cd5bc..930e6db27407 100644
--- a/dev-libs/libbpf/Manifest
+++ b/dev-libs/libbpf/Manifest
@@ -2,3 +2,4 @@ DIST libbpf-0.8.1.tar.gz 942702 BLAKE2B 
084be7d4258500fa894560ed2e52821addcc5d15
 DIST libbpf-1.2.2.tar.gz 1000104 BLAKE2B 
45a2ceabd38b3ea55f466de68d0806df6ae802b509063ca12d670ba972bac3dc5c7e518e8c9904915dbc9877c27ea892a7b857aa03d4e86016969b2d278b0b4a
 SHA512 
bc7620207e6f521b9b5baab00bd81346084b8eabf81bff3ec24e5367d389f2a331a0b082798f8bb5d4fea836c3c0cc961fc881abc3a4e05d91152150bdfe47be
 DIST libbpf-1.3.0.tar.gz 999282 BLAKE2B 
5ee0a45cd06be482c9523ec2a9bb26cf12b89df23f515b037badda868770069d5ffb751c011222b86b1d43034a1cdd537cb263883ed0645641548adc9c9896eb
 SHA512 
59990189538e47765542e9ed6e88bc78c9d29bc077b5666bb1303cf15579c90b3d35a0d631b9bbd4bff2708243dc91d901bd68c119fb74dfd10a3e1066aa9acc
 DIST libbpf-1.4.0.tar.gz 1015490 BLAKE2B 
46932f972201581f9f5be98063888216fd522ac549561efdec09603dfcbf0132418f50c2aed80d656fd25b235a9dc3b4ffe459cab9445a8508a7af620989072f
 SHA512 
400c91a4870be8bb115f7abcc12c460700980fb6a3afdf43c885b1cdbe28fed1d37142d3987a85e12b4c565787a48f5cd0b07cafff067d91902d70713528929f
+DIST libbpf-1.4.2.tar.gz 1016045 BLAKE2B 
7529e6521337d45210ee2e3d00aae7c8cac309a4b3f36ffdd9c4a6c4439f266ee654b6ad6abaea2e43310260182bd9ad52ff162339545027050329d8307fe0d5
 SHA512 
b0faf45e77fc0197239b87d74010bad6b7ef7d48c1b3de2a3960164d9029851e2ad204b92d0cccb2fde2d0dfe44d9fa7f24b35a4917179dbab1bee192d3780db

diff --git a/dev-libs/libbpf/libbpf-1.4.2.ebuild 
b/dev-libs/libbpf/libbpf-1.4.2.ebuild
new file mode 100644
index ..6cd9245fc9a6
--- /dev/null
+++ b/dev-libs/libbpf/libbpf-1.4.2.ebuild
@@ -0,0 +1,65 @@
+# Copyright 2019-2024 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=8
+
+inherit flag-o-matic toolchain-funcs
+
+DESCRIPTION="Stand-alone build of libbpf from the Linux kernel"
+HOMEPAGE="https://github.com/libbpf/libbpf;
+
+if [[ ${PV} =~ [9]{4,} ]]; then
+   inherit git-r3
+   EGIT_REPO_URI="https://github.com/libbpf/libbpf.git;
+else
+   SRC_URI="https://github.com/${PN}/${PN}/archive/v${PV}.tar.gz -> 
${P}.tar.gz"
+   KEYWORDS="~alpha ~amd64 ~arm ~arm64 ~hppa ~ia64 ~loong ~m68k ~mips ~ppc 
~ppc64 ~riscv ~s390 ~sparc ~x86"
+fi
+S="${WORKDIR}/${P}/src"
+
+LICENSE="GPL-2 LGPL-2.1 BSD-2"
+SLOT="0/$(ver_cut 1-2 ${PV})"
+IUSE="static-libs"
+
+DEPEND="
+   sys-kernel/linux-headers
+   virtual/libelf
+"
+RDEPEND="
+   ${DEPEND}
+"
+BDEPEND="
+   virtual/pkgconfig
+"
+
+DOCS=(
+   ../{README,SYNC}.md
+)
+
+PATCHES=(
+   "${FILESDIR}"/libbpf--paths.patch
+)
+
+src_configure() {
+   append-cflags -fPIC
+   tc-export CC AR PKG_CONFIG
+   export LIBSUBDIR="$(get_libdir)"
+   export PREFIX="${EPREFIX}/usr"
+   export V=1
+}
+
+src_install() {
+   emake \
+   DESTDIR="${D}" \
+   LIBSUBDIR="${LIBSUBDIR}" \
+   install install_uapi_headers
+
+   if ! use static-libs; then
+   find "${ED}" -name '*.a' -delete || die
+   fi
+
+   dodoc "${DOCS[@]}"
+
+   insinto /usr/$(get_libdir)/pkgconfig
+   doins ${PN}.pc
+}

[gentoo-commits] repo/gentoo:master commit in: dev-python/regress/

commit: 0af3592052af202e288911ec39a9038ac7b8
Author: Patrick McLean  gentoo  org>
AuthorDate: Fri May 24 18:16:02 2024 +
Commit:     Patrick McLean  gentoo  org>
CommitDate: Fri May 24 18:26:29 2024 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=0af35777

dev-python/regress: new package, add 0.4.5

Signed-off-by: Patrick McLean  gentoo.org>

 dev-python/regress/Manifest | 40 +++
 dev-python/regress/metadata.xml | 12 ++
 dev-python/regress/regress-0.4.5.ebuild | 70 +
 3 files changed, 122 insertions(+)

diff --git a/dev-python/regress/Manifest b/dev-python/regress/Manifest
new file mode 100644
index ..827b4da32e46
--- /dev/null
+++ b/dev-python/regress/Manifest
@@ -0,0 +1,40 @@
+DIST ahash-0.8.3.crate 42416 BLAKE2B 
84836a4e33451012ff32c1a1a90500d87eb7ce649b60dff4eecfb0d25b9782a186376c154673c3121b154ff4616016d1718dfd687b88f4772c2c89eeb2f119b6
 SHA512 
cf2d2f1201ac0969cf4e2a0c47090bee971b2287ac44b5e091c90a9eced03cf6ff56d7900cc0f529d4acedc30bd400261c15e50efabdd1731f79951b449af53e
+DIST autocfg-1.1.0.crate 13272 BLAKE2B 
7724055c337d562103f191f4e36cab469e578f0c51cc24d33624dea155d108a07578703766341fd6a4cc1ef52acda406e7dba1650d59115f18261281e5b40203
 SHA512 
df972c09abbdc0b6cb6bb55b1e29c7fed706ece38a62613d9e275bac46a19574a7f96f0152cccb0239efea04ee90083a146b58b15307696c4c81878cd12de28f
+DIST bitflags-1.3.2.crate 23021 BLAKE2B 
eb990bb27b2bdeb66fd7212ce582cb36e1c616debbac85df642d0c82b25439e6bf9b1e811fac76b59e58ea3c1bbea6170d03a61e8f9a395e4334a0e2e2987eda
 SHA512 
3c698f757b5cc62f815f9a1cce365c3d2dd88e4db71f331dff8bba86c2865f755b81cb4c9bfc59bd86b7643b0943f9e09a7c4f8ad75eb2ab0e714803d0129f62
+DIST cfg-if-1.0.0.crate 7934 BLAKE2B 
e99a5589c11d79d77a4537b34ce0a45d37b981c123b79b807cea836c89fc3926d693458893baca2882448d3d44e3f64e06141f6d916b748daa10b8cc1ae16d1b
 SHA512 
0fb16a8882fd30e86b62c5143b1cb18ab564e84e75bd1f28fd12f24ffdc4a42e0d2e012a99abb606c12efe3c11061ff5bf8e24ab053e550ae083f7d90f6576ff
+DIST hashbrown-0.13.2.crate 105265 BLAKE2B 
e9ff7e6e753166ab3051a834df6f2da81a19ac6997ba269ab13a65e0abb9ce00839311785aefb451553284ad5ef3a0cda925dc2bc188d2a138a78578e530969c
 SHA512 
21dae7a283326d21e16bb32ae0dd1481c4936939a32a06478a3351c2dec97941be532437b808e99ac40e7900a75433fe0efbd852158659a682461245e19d0e70
+DIST heck-0.4.1.crate 11567 BLAKE2B 
520aeea740cfa30b0cca12f73594ffa655f32959673b1c9caaca1ea0162e455546ae3033881394c0ba0516bcd5c9a997da02162e1585522d665813b9096eabd9
 SHA512 
8c80e959d2f10a2893f9a71994720f90747742bb5b61fc0a539eed3ea5679b140c48fd7f7690d7122cd6af5f7f20a19d412e3569fe741c6d31f6b2ce1e0b80e8
+DIST indoc-2.0.4.crate 14311 BLAKE2B 
8d604e20825ae64530014081c627abe4ecec6447e1e214408743aca79ed217531baad4bd7021137ae6628555d769a248f06acc556cc3254d2626074aab110a44
 SHA512 
ef1b8d19d89d848c1133f2865247e0ce23cbe5552454805910ed0478ac4acb11b11629aa4a5ce8756d0ed5cbc0644abedeac0246f433166c68f47cf58cf4487a
+DIST libc-0.2.140.crate 669153 BLAKE2B 
f4269549f6b450a3da3196ecaae52afe178d5b6905666fae04e2879f975f0129788898ca2ccd214d721af42a8b2fa86b26355d6baa0a81c223b56c658ee66dd5
 SHA512 
f450fe619ea2f45e4ada2567981987f19d35a9f13f88a0ce3a53e1751c6fbff708ca69fa6a64d807cce5dfe18b08751f0695d8a01e68e269da1aafc831528b7b
+DIST lock_api-0.4.9.crate 25685 BLAKE2B 
8adf5c3cccebdf6aff6ec977f230cd2a208b0b188ef57deacbbc6019431f0ede1a760b2384ba3cb49c96b8a589dc56c0f46a6359b3e62277e7ae1a1c3f586fa3
 SHA512 
9215381d9bb6b80d217c73a900db43df043b3e939b5bd7a292a02e9ab911cf0eacd8f883d35bdf72b3a0e78df8f1bc3e843ca4c775294c7a7a03091dc1a74990
+DIST memchr-2.5.0.crate 65812 BLAKE2B 
57966413a1f933dcb2d2d4ccb29c247070f65a83299b2a9f5aa83f5a48a5c5f1c4c7c632fa63bd19f9508e9291e7258db2f16e2813a56fd84e0856f70f1e67ab
 SHA512 
444a163b484c233e78c0e2e4d51f01ce2da93d7d29f516a95e4b0866b20bdfd3f34137653abed53eb70387991ee3e2b5937d8d4360a85bbcb50a93005a75defa
+DIST memoffset-0.9.0.crate 9033 BLAKE2B 
19090c1af8b8cf54a2cf7593748aff4d3dc685ec7080aa476139c1721ef71555495e1bc513b1efaddc7e7702f83e0e1c2a8f71ff40009d266539484c9297e0ed
 SHA512 
2f04f9b6fed31e94388c18162ad275897a835df7b9ac827f4df0f4b0ecf71064ef247f7ad11dbc27d7a6d448984a0f29d1c000e3c8d5fa6e121fa9571770ec55
+DIST once_cell-1.17.1.crate 32856 BLAKE2B 
8bde2aaaf9ef45d1f6b8458686179f1fe9295ee8faea269e9b49779583ce26ab9dafe988c3584e841a9e5d05e28430ca967ef3b25e755f48f0120d9c99cdb7bc
 SHA512 
1302d51801e38bfee23e74c0046f1ecb1d3c27309b5fe11c2b6c99553b357db502ce1718695602f9d8b10429e8ff03f91c016d5d604957083728293824c05904
+DIST parking_lot-0.12.1.crate 40967 BLAKE2B 
940a112a066e3cbd15e2f6df89bfff37e4ece2194118618a96fa14871813c91798f93181ab0f768d3e1f3d60805508f216724013afb7e3da95678d0d951a42d4
 SHA512 
07327d3b737a913508dffb66023766348ce7f9d555c224a099cabb05baefd16a28e15fec638e3a148a5169dbd980c4541b0f8820ae9d06dfe0704482838fbd5c
+DIST parking_lot_core-0.9.7.crate 32412 BLAKE2B 
fec3ed2cf28e6d5090aae6a7c0ad583acf3ce6e54e881b78a9cb6721ca1e7040d46c044d405852728e74baff6ff1feaee7a89a64c69d20531f29942

[gentoo-commits] repo/gentoo:master commit in: dev-python/pbs-installer/

commit: 40f8436fd1c71cfba1e271d8d9cf7630361963a5
Author: Patrick McLean  gentoo  org>
AuthorDate: Fri May 24 17:41:49 2024 +
Commit:     Patrick McLean  gentoo  org>
CommitDate: Fri May 24 17:41:49 2024 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=40f8436f

dev-python/pbs-installer: add 2024.4.24, drop 2024.4.1

Signed-off-by: Patrick McLean  gentoo.org>

 dev-python/pbs-installer/Manifest   | 2 +-
 .../{pbs-installer-2024.4.1.ebuild => pbs-installer-2024.4.24.ebuild}   | 0
 2 files changed, 1 insertion(+), 1 deletion(-)

diff --git a/dev-python/pbs-installer/Manifest 
b/dev-python/pbs-installer/Manifest
index 64f270ba927d..d0044d88a2a0 100644
--- a/dev-python/pbs-installer/Manifest
+++ b/dev-python/pbs-installer/Manifest
@@ -1 +1 @@
-DIST pbs-installer-2024.4.1.gh.tar.gz 68006 BLAKE2B 
5455b00dd08881e78fbbc9b565e9224ee7d04f17855da9869fcb420fcbf8ee3743e6f21113d406bcfb66e786788735bd1ef2d3bfa30a14a5a74fb2c36e8f3d0a
 SHA512 
407ffc7a7f5430d8f889f32b53614cc2c5e3fb05937905d6b43c7ca9151f3d5cb794bcd60633e4945dc62555cc6575d75e0b7b7a1e5dc0c9f99c2318fada3a10
+DIST pbs-installer-2024.4.24.gh.tar.gz 73601 BLAKE2B 
f56483899dc7795d0334b4698e08f71799ede456fdb7f78accc9278f32437a6b785055ec0b61854c6ec05663bc3b4bd41be8d45138a5793dcab35aa80da32de8
 SHA512 
7bd440e1522a1c826dcfac801763ad256d79f60315a30828082ea65169e5f4cc8527866491a5c4d84d847150ed6f90167b550104031f417e0103640e2c291aeb

diff --git a/dev-python/pbs-installer/pbs-installer-2024.4.1.ebuild 
b/dev-python/pbs-installer/pbs-installer-2024.4.24.ebuild
similarity index 100%
rename from dev-python/pbs-installer/pbs-installer-2024.4.1.ebuild
rename to dev-python/pbs-installer/pbs-installer-2024.4.24.ebuild

Re: [RBW] Re: Are bikes becoming too complicated?

2024-05-24 Thread Patrick Moore

SaaS -- Shifting-as-a-Service, and "your personal power assistant." I love
it.

On Fri, May 24, 2024 at 10:41 AM Robert Calton  wrote:

> To add an amusing, cynical thought: can you imagine Shifting-as-a-Service?
> New fully integrated wireless 5G groupsets charge you $10/month for 1,000
> shifts and then you're stuck with a fixie. Or pony up $40/month for
> unlimited shifts and get your shifting analytics pushed to the latest Shimano
> E-Tube app .

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/CALuTfguv%2BFgNVS5whbsbQ_2eFDW%2BBwVK4T6npXxAKodjqPqF7A%40mail.gmail.com.

Re: 2 installations on the same PC - Add partition in Ftab

On Fri, 2024-05-24 at 07:48 -0400, Robert McBroom via users wrote:
> Two installations of Fedora can be run on the same system With each 
> installation on a separate drive. The installation to be executed can
> then be started from the bios. The partitions /boot/efi, /boot and
> /root 
> are all unique to the installation. Can even include Windows.

I know that. Which is why I asked the OP if they really wanted two
installations. Given that they are a beginning user, it seemed
unlikely.

/boot/efi is indeed mounted on Fedora, basically so it can be modified,
and I should have remembered that. Nevertheless, its function is as a
partition which can be booted from the BIOS, i.e. it's not a directory
within the ext4 (or whatever) Linux filesystem.

poc
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40: strange network issue after upgrade of laptop from F39

On Fri, 2024-05-24 at 11:52 +0200, Sjoerd Mullender via users wrote:
> On 24/05/2024 11.38, Patrick O'Callaghan wrote:
> > On Thu, 2024-05-23 at 17:32 -0500, Ranjan Maitra via users wrote:
> > > Hi,
> > > 
> > > I have a strange issue after upgrading a laptop (Dell XPS 13,
> > > 2013
> > > edition). That is that I am connected (whether through WiFi or
> > > ethernet cable) to a university network which claims after the
> > > upgrade that the laptop is no longer registered. I went through
> > > the
> > > registration process again through the browser (and was told: why
> > > are
> > > you registering this machine again, it is registered, simply
> > > restart
> > > the network/reboot) but the problem does not go away. I upgraded
> > > a
> > > desktop on the same ethernet switch and this problem did not go
> > > show
> > > up there (I am using that to write this email).
> > > 
> > > I should mention that the network on this upgraded laptop works
> > > fine
> > > when I take the laptop home and connect.
> > > 
> > > So what could be the problem? I have not had such an issue with
> > > installations and upgrades for 40.5 versions of Fedora (the 0.5
> > > is
> > > for RH9 that I think I used mid-2003 to late 2003 before Fedora
> > > Core
> > > 1). How do I troubleshoot this?
> > 
> > I´d suggest you talk to the university network admins.
> 
> Probably the new way in which Fedora is handling MAC addresses.  I 
> believe it is now supposed to be random, but stable per SSID, but I
> do 
> not remember any details.  So it may be that you're using a different
> MAC address than before, and the university doesn't recognize it.

Again, talk to the admins. They should be able to tell you. However
since many mobile devices use randomised MAC addresses they must have a
way of dealing with this, assuming that is indeed the problem.

poc
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: F40: strange network issue after upgrade of laptop from F39

On Thu, 2024-05-23 at 17:32 -0500, Ranjan Maitra via users wrote:
> Hi,
> 
> I have a strange issue after upgrading a laptop (Dell XPS 13, 2013
> edition). That is that I am connected (whether through WiFi or
> ethernet cable) to a university network which claims after the
> upgrade that the laptop is no longer registered. I went through the
> registration process again through the browser (and was told: why are
> you registering this machine again, it is registered, simply restart
> the network/reboot) but the problem does not go away. I upgraded a
> desktop on the same ethernet switch and this problem did not go show
> up there (I am using that to write this email).
> 
> I should mention that the network on this upgraded laptop works fine
> when I take the laptop home and connect.
> 
> So what could be the problem? I have not had such an issue with
> installations and upgrades for 40.5 versions of Fedora (the 0.5 is
> for RH9 that I think I used mid-2003 to late 2003 before Fedora Core
> 1). How do I troubleshoot this?

I´d suggest you talk to the university network admins.

poc
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Re: 2 installations on the same PC - Add partition in Ftab

On Thu, 2024-05-23 at 19:43 -0300, soles.g wrote:
> I did two installations of Fedora40
> on the same hard drive.
> 

¿Esto fue a propósito o por error? No está claro para qué necesitas dos
instalaciones de F40.

   Was this on purpose or by mistake? It's not clear why you would need
   two installations of F40.

> I didn't know how to do it
> so you don't have to create
> in each of the facilities
> the directory? /efi.
> 

Lo usual es tener una sola partición EFI (la cual no está dentro de
Fedora sino es accesible desde el BIOS. El comando efibootmanager te
permite configurar las opciones. No hace falta montarla en Fedora
porque dicho comando lo manipula directamente. Puedes especificar el
disco duro a usar.

   The usual setup is to have one EFI partition (not a Fedora
   directory). You can use the efibootmanager command to change
   options. You don't need to mount the EFI in Fedora as the command
   accesses it directly. You can specify which hard drive it should
   use.

> ├─sda1 vfat FAT16 EFI 0B9B-8F19
> 
> ├─sda8 vfat FAT32 boot 0566-61F4
> /dev/sda8: LABEL_FATBOOT="boot" LABEL="boot" UUID="0533-61F4"
> BLOCK_SIZE="512" TYPE="vfat" PARTLABEL="
> EFI System Partition" PARTUUID="916a4cb1-8f50-42c7-92be-dc53d80a4bdb"
> 
> So when the machine starts up it tells me something about two 
> 'journal'... I don't know what...
> 

No está claro si puedes usar el sistema o no, pero en caso que sí
sugeriría deshabilitar el boot de una de las particiones usando el
efibootmanager.

   It's unclear if you have a working system, but if so I'd suggest
   disabling one of the boot partitions using efibootmanager,

> I wish I could fix it
> just to have it done well
> (if it could...)
> 
> The other thing I don't understand
> It's what I have to write in the fstab
> to tell you that when you start...
> Also start a partition: /sda7...
> which is not /home...
> 

Hay otras respuestas en la lista que te dan la solución.

   Other people have already answered this.

> If you could tell me
> that I have to write with the mount command
> to mount it manually from the terminal...
> I would like it more... :-)
> 
> Well... I'm going to ask san google translate to translate this
> to save you work... do you think...?

It's no bother and Google Translate is a poor translator of meaning in
context.

poc
--
___
users mailing list -- users@lists.fedoraproject.org
To unsubscribe send an email to users-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/users@lists.fedoraproject.org
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

[webkit-changes] [WebKit/WebKit] e03a25: [Navigation] Set formData on NavigateEvent

2024-05-24 Thread Patrick

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: e03a2518eb73ce8bf82bf9870c96fdc1077f9444
  
https://github.com/WebKit/WebKit/commit/e03a2518eb73ce8bf82bf9870c96fdc1077f9444
  Author: Patrick Griffis 
  Date:   2024-05-23 (Thu, 23 May 2024)

  Changed paths:
M LayoutTests/TestExpectations
M 
LayoutTests/imported/w3c/web-platform-tests/navigation-api/navigate-event/navigate-form-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/navigation-api/navigate-event/navigate-form-reload-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/navigation-api/navigate-event/navigate-form-requestSubmit-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/navigation-api/navigate-event/navigate-form-traverse-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/navigation-api/navigate-event/navigate-form-userInitiated-expected.txt
M 
LayoutTests/imported/w3c/web-platform-tests/navigation-api/navigate-event/navigate-form-with-target-expected.txt
M Source/WebCore/loader/FrameLoader.cpp
M Source/WebCore/loader/FrameLoader.h
M Source/WebCore/page/History.cpp
M Source/WebCore/page/Navigation.cpp
M Source/WebCore/page/Navigation.h

  Log Message:
  ---
  [Navigation] Set formData on NavigateEvent
https://bugs.webkit.org/show_bug.cgi?id=274561

Reviewed by Alex Christensen.

This includes form data in all push/replace events on same-origin-domain form 
submissions.

The two failing tests are passes except for the navigation type which is an 
unrelated issue.

* 
LayoutTests/imported/w3c/web-platform-tests/navigation-api/navigate-event/navigate-form-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/navigation-api/navigate-event/navigate-form-reload-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/navigation-api/navigate-event/navigate-form-requestSubmit-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/navigation-api/navigate-event/navigate-form-traverse-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/navigation-api/navigate-event/navigate-form-userInitiated-expected.txt:
* 
LayoutTests/imported/w3c/web-platform-tests/navigation-api/navigate-event/navigate-form-with-target-expected.txt:
* Source/WebCore/loader/FrameLoader.cpp:
(WebCore::FrameLoader::loadURL):
(WebCore::FrameLoader::loadWithDocumentLoader):
(WebCore::FrameLoader::dispatchNavigateEvent):
* Source/WebCore/loader/FrameLoader.h:
* Source/WebCore/page/History.cpp:
(WebCore::History::stateObjectAdded):
* Source/WebCore/page/Navigation.cpp:
(WebCore::Navigation::innerDispatchNavigateEvent):
(WebCore::Navigation::dispatchTraversalNavigateEvent):
(WebCore::Navigation::dispatchPushReplaceReloadNavigateEvent):
(WebCore::Navigation::dispatchDownloadNavigateEvent):
* Source/WebCore/page/Navigation.h:

Canonical link: https://commits.webkit.org/279257@main



To unsubscribe from these emails, change your notification settings at 
https://github.com/WebKit/WebKit/settings/notifications
___
webkit-changes mailing list
webkit-changes@lists.webkit.org
https://lists.webkit.org/mailman/listinfo/webkit-changes

Re: [RBW] Re: Sam Hillborne Pictures Thread

2024-05-23 Thread Patrick Moore

Thanks, Andrew.

On Thu, May 23, 2024 at 5:10 PM Andrew Joseph 
wrote:

> Patrick,
>
> Thank you!
>
> Those little contraptions are actually called “Cable Cherries.”  They are
> easily installed and tightened via a 1.5 mm hex.  They are quite fun, come
> in some great colors and are available from Forager Cycles, and Paul, among
> others.  See below for the description from Forager…
>
> “The Cable Cherries are durable, reusable cable ends with a huge grip - no
> more crimps wiggling off leaving a frayed, pokey end! The easy-to-grab
> sphere shape makes adjusting cable tension or swapping components simple.
> Tape the included 1.5mm hex key to your tire lever, and you’re set!
>
> Easily grab the sphere to snug up your cable tension. Take them on and off
> as much as you need with the included 1.5mm hex key & set screw. The Cable
> Cherries are CNC machined in Oakland, CA on the same equipment that makes
> surgical pins & screws. Get 'em tight, and have 'em for life.”
> The saddle is a Berthoud Galibier.  A bit more narrow (and Ti rails) than
> their normal offerings.
>
> Hope this is helpful.
>
> Best,
>
> Drew
>
> Sent from my iPhone
>
> On May 23, 2024, at 6:01 PM, Patrick Moore  wrote:
>
> 
> Andrew: nice. Pray, what is the little orange globular cable end -- I
> guess I really mean, how is it designed and how does it clamp to the cable
> -- and where do you get them?
>
> And, what is the saddle? Brooks Swift? Or trimmed Pro? Or another marque?
>
> Patrick Moore, ruthlessly bottom-trimming and wondering what to do with
> the very, very nice -- thick leather! -- as-new B17N that he got recently
> for ~$47 + shipping.
>
>
> On Thu, May 23, 2024 at 4:50 PM Andrew Joseph 
> wrote:
>
>> Better photos…
>>
>> 
>>
>> Sent from my iPhone
>>
> --
> You received this message because you are subscribed to the Google Groups
> "RBW Owners Bunch" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rbw-owners-bunch+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rbw-owners-bunch/CALuTfgu%2Bgi3yeqRQ99Y_jwUX7kd1iZPwQqvnSkiLHk_wgsVLnQ%40mail.gmail.com
> <https://groups.google.com/d/msgid/rbw-owners-bunch/CALuTfgu%2Bgi3yeqRQ99Y_jwUX7kd1iZPwQqvnSkiLHk_wgsVLnQ%40mail.gmail.com?utm_medium=email_source=footer>
> .
>
> --
> You received this message because you are subscribed to the Google Groups
> "RBW Owners Bunch" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to rbw-owners-bunch+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/rbw-owners-bunch/A00BBC2A-BD71-4028-93D5-57C421C9AB4F%40gmail.com
> <https://groups.google.com/d/msgid/rbw-owners-bunch/A00BBC2A-BD71-4028-93D5-57C421C9AB4F%40gmail.com?utm_medium=email_source=footer>
> .
>


-- 

Patrick Moore
Alburquerque, Nuevo Mexico, Etats Unis d'Amerique, Orbis Terrarum
---

Executive resumes, LinkedIn profiles, bios, letters, and other writing
services

---

*When thou didst not, savage, k**now thine own meaning,*

*But wouldst gabble like a** thing most brutish,*

*I endowed thy purposes w**ith words that made them known.*

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/CALuTfgt918XFnBXOBNHVaAA-27BtirJ8zz6Y2ssKrZGfU5PoZg%40mail.gmail.com.

Re: [RBW] Re: New Bike Day: My Little Platy

2024-05-23 Thread Patrick Moore

IMO this ties with the other customized Platypus featured here recently for
"nicest-looking Platypus in list history," and it probably wins the award
for "most attention paid to aesthetics" in list history. Note: I think very
many of the Rivs posted are lovely to look at.

Me, as with Mitch, "I am a guy." I am fully OC about my bikes for parts and
builds and design (I remember most of the parts from my first 1970 full
build), but not aesthetics, and it's interesting to see how others'
passions turn out.

Cerakoting is new to me; had to Google it. I see it differs from anodizing,
but, how exactly? Too bad webmeisters are generally better fancy web page
design than conveying information -- this for global corporate websites as
well as bike websites; the latter on the whole do better. I gather that
anodizing is colored (or not) oxidizing while cerakoting is a --- coating.

One of the early links that DDG turned up said: "Anodized versus Cerakote:
Which is better for your AR15?"

On Thu, May 23, 2024 at 9:56 AM Armand Kizirian 
wrote:

> Looks super fun. Good to know Paul can anodize parts like that! Also
> interested to hear how the different size rides for you. Enjoy!
>

-- 
You received this message because you are subscribed to the Google Groups "RBW 
Owners Bunch" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to rbw-owners-bunch+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/rbw-owners-bunch/CALuTfgvbfHM7Dnb4oN%2BqG4uYAKT1G%2BCjiejBDH9FGYqmw%3D%2Bzvw%40mail.gmail.com.

Re: [PATCH v2] libstdc++: Fix std::ranges::iota not included in numeric [PR108760]

On Fri, 17 May 2024, Michael Levine (BLOOMBERG/ 731 LEX) wrote:

> This is the revised version of my patch incorporating the provided feedback 
> from Patrick Palka and Jonathan Wakely.
> This patch fixes GCC Bug 108760: 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108760
> I moved out_value_result to , moved std::ranges:iota 
> into , removed my new test, and moved and renamed the existing test.

Nice, thanks!  The incremental changes seem good, but could you send a
single squashed patch containing all the changes?  That's what we'll end
up pushing after all.

> 
> I built my local version of gcc using the following configuration: $ 
> ../gcc/configure --disable-bootstrap --prefix="$(pwd)/_pfx/" 
> --enable-languages=c,c++,lto
> I then ran $ make -jN
> and $ make -jN install
> 
> Using the locally installed version, the following code compiled: 
> https://godbolt.org/z/33EPeqd1b
> 
> I tested my changes by running: $ make check-c++ -jN -k
> I personally found it difficult to understand the results of running the 
> tests.
> 
> I ran this on the following OS:
> 
> Virtualization: wsl
> Operating System: Ubuntu 20.04.6 LTS
> Kernel: Linux 5.15.146.1-microsoft-standard-WSL2
> Architecture: x86-64
> 
> 
> 
> From: Michael Levine (BLOOMBERG/ 731 LEX) At: 04/17/24 14:24:24 UTC-4:00
> To: libstd...@gcc.gnu.org, gcc-patches@gcc.gnu.org
> Subject: [PATCH] libstdc++: Fix std::ranges::iota is not included in numeric 
> [PR108760]
> 
> This patch fixes GCC Bug 108760: 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108760
> Before this patch, using std::ranges::iota required including  
> when it should have been sufficient to only include .
> 
> When the patch is applied, the following code will compile: 
> https://godbolt.org/z/33EPeqd1b
> 
> I added a test case for this change as well.
> 
> I built my local version of gcc using the following configuration: $ 
> ../gcc/configure --disable-bootstrap --prefix="$(pwd)/_pfx/" 
> --enable-languages=c,c++,lto
> 
> and I tested my changes by running: $ make check-c++ -jN -k
> 
> I ran this on the following OS:
> 
> Virtualization: wsl
> Operating System: Ubuntu 20.04.6 LTS
> Kernel: Linux 5.15.146.1-microsoft-standard-WSL2
> Architecture: x86-64
> 
> 
> 
> 
>

Re: [PATCH v2] libstdc++: Fix std::ranges::iota not included in numeric [PR108760]

On Fri, 17 May 2024, Michael Levine (BLOOMBERG/ 731 LEX) wrote:

> This is the revised version of my patch incorporating the provided feedback 
> from Patrick Palka and Jonathan Wakely.
> This patch fixes GCC Bug 108760: 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108760
> I moved out_value_result to , moved std::ranges:iota 
> into , removed my new test, and moved and renamed the existing test.

Nice, thanks!  The incremental changes seem good, but could you send a
single squashed patch containing all the changes?  That's what we'll end
up pushing after all.

> 
> I built my local version of gcc using the following configuration: $ 
> ../gcc/configure --disable-bootstrap --prefix="$(pwd)/_pfx/" 
> --enable-languages=c,c++,lto
> I then ran $ make -jN
> and $ make -jN install
> 
> Using the locally installed version, the following code compiled: 
> https://godbolt.org/z/33EPeqd1b
> 
> I tested my changes by running: $ make check-c++ -jN -k
> I personally found it difficult to understand the results of running the 
> tests.
> 
> I ran this on the following OS:
> 
> Virtualization: wsl
> Operating System: Ubuntu 20.04.6 LTS
> Kernel: Linux 5.15.146.1-microsoft-standard-WSL2
> Architecture: x86-64
> 
> 
> 
> From: Michael Levine (BLOOMBERG/ 731 LEX) At: 04/17/24 14:24:24 UTC-4:00
> To: libstdc++@gcc.gnu.org, gcc-patc...@gcc.gnu.org
> Subject: [PATCH] libstdc++: Fix std::ranges::iota is not included in numeric 
> [PR108760]
> 
> This patch fixes GCC Bug 108760: 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108760
> Before this patch, using std::ranges::iota required including  
> when it should have been sufficient to only include .
> 
> When the patch is applied, the following code will compile: 
> https://godbolt.org/z/33EPeqd1b
> 
> I added a test case for this change as well.
> 
> I built my local version of gcc using the following configuration: $ 
> ../gcc/configure --disable-bootstrap --prefix="$(pwd)/_pfx/" 
> --enable-languages=c,c++,lto
> 
> and I tested my changes by running: $ make check-c++ -jN -k
> 
> I ran this on the following OS:
> 
> Virtualization: wsl
> Operating System: Ubuntu 20.04.6 LTS
> Kernel: Linux 5.15.146.1-microsoft-standard-WSL2
> Architecture: x86-64
> 
> 
> 
> 
>

Re: [PATCH][14 backport] c++: Fix instantiation of imported temploid friends [PR114275]

 * g++.dg/modules/tpl-friend-12_f.C: New test.
>   * g++.dg/modules/tpl-friend-13_a.C: New test.
>   * g++.dg/modules/tpl-friend-13_b.C: New test.
>   * g++.dg/modules/tpl-friend-13_c.C: New test.
>   * g++.dg/modules/tpl-friend-13_d.C: New test.
>   * g++.dg/modules/tpl-friend-13_e.C: New test.
>   * g++.dg/modules/tpl-friend-13_f.C: New test.
>   * g++.dg/modules/tpl-friend-13_g.C: New test.
>   * g++.dg/modules/tpl-friend-14_a.C: New test.
>   * g++.dg/modules/tpl-friend-14_b.C: New test.
>   * g++.dg/modules/tpl-friend-14_c.C: New test.
>   * g++.dg/modules/tpl-friend-14_d.C: New test.
>   * g++.dg/modules/tpl-friend-9.C: New test.
> 
> Signed-off-by: Nathaniel Shead 
> Reviewed-by: Jason Merrill 
> Reviewed-by: Patrick Palka 
> ---
>  gcc/cp/cp-tree.h  |  3 +
>  gcc/cp/decl.cc| 41 ++
>  gcc/cp/module.cc  | 75 +++
>  gcc/cp/name-lookup.cc | 53 +
>  gcc/cp/pt.cc  | 32 +++-
>  .../g++.dg/modules/tpl-friend-10_a.C  | 15 
>  .../g++.dg/modules/tpl-friend-10_b.C  |  5 ++
>  .../g++.dg/modules/tpl-friend-10_c.C  |  7 ++
>  .../g++.dg/modules/tpl-friend-10_d.C  |  8 ++
>  .../g++.dg/modules/tpl-friend-11_a.C  | 14 
>  .../g++.dg/modules/tpl-friend-11_b.C  |  5 ++
>  .../g++.dg/modules/tpl-friend-12_a.C  | 10 +++
>  .../g++.dg/modules/tpl-friend-12_b.C  |  9 +++
>  .../g++.dg/modules/tpl-friend-12_c.C  | 10 +++
>  .../g++.dg/modules/tpl-friend-12_d.C  |  8 ++
>  .../g++.dg/modules/tpl-friend-12_e.C  |  7 ++
>  .../g++.dg/modules/tpl-friend-12_f.C  |  8 ++
>  .../g++.dg/modules/tpl-friend-13_a.C  | 13 
>  .../g++.dg/modules/tpl-friend-13_b.C  | 11 +++
>  .../g++.dg/modules/tpl-friend-13_c.C  | 13 
>  .../g++.dg/modules/tpl-friend-13_d.C  |  7 ++
>  .../g++.dg/modules/tpl-friend-13_e.C  | 18 +
>  .../g++.dg/modules/tpl-friend-13_f.C  |  7 ++
>  .../g++.dg/modules/tpl-friend-13_g.C  | 11 +++
>  .../g++.dg/modules/tpl-friend-14_a.C  |  8 ++
>  .../g++.dg/modules/tpl-friend-14_b.C  |  8 ++
>  .../g++.dg/modules/tpl-friend-14_c.C  |  7 ++
>  .../g++.dg/modules/tpl-friend-14_d.C  |  9 +++
>  gcc/testsuite/g++.dg/modules/tpl-friend-9.C   | 13 
>  29 files changed, 418 insertions(+), 17 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/modules/tpl-friend-10_a.C
>  create mode 100644 gcc/testsuite/g++.dg/modules/tpl-friend-10_b.C
>  create mode 100644 gcc/testsuite/g++.dg/modules/tpl-friend-10_c.C
>  create mode 100644 gcc/testsuite/g++.dg/modules/tpl-friend-10_d.C
>  create mode 100644 gcc/testsuite/g++.dg/modules/tpl-friend-11_a.C
>  create mode 100644 gcc/testsuite/g++.dg/modules/tpl-friend-11_b.C
>  create mode 100644 gcc/testsuite/g++.dg/modules/tpl-friend-12_a.C
>  create mode 100644 gcc/testsuite/g++.dg/modules/tpl-friend-12_b.C
>  create mode 100644 gcc/testsuite/g++.dg/modules/tpl-friend-12_c.C
>  create mode 100644 gcc/testsuite/g++.dg/modules/tpl-friend-12_d.C
>  create mode 100644 gcc/testsuite/g++.dg/modules/tpl-friend-12_e.C
>  create mode 100644 gcc/testsuite/g++.dg/modules/tpl-friend-12_f.C
>  create mode 100644 gcc/testsuite/g++.dg/modules/tpl-friend-13_a.C
>  create mode 100644 gcc/testsuite/g++.dg/modules/tpl-friend-13_b.C
>  create mode 100644 gcc/testsuite/g++.dg/modules/tpl-friend-13_c.C
>  create mode 100644 gcc/testsuite/g++.dg/modules/tpl-friend-13_d.C
>  create mode 100644 gcc/testsuite/g++.dg/modules/tpl-friend-13_e.C
>  create mode 100644 gcc/testsuite/g++.dg/modules/tpl-friend-13_f.C
>  create mode 100644 gcc/testsuite/g++.dg/modules/tpl-friend-13_g.C
>  create mode 100644 gcc/testsuite/g++.dg/modules/tpl-friend-14_a.C
>  create mode 100644 gcc/testsuite/g++.dg/modules/tpl-friend-14_b.C
>  create mode 100644 gcc/testsuite/g++.dg/modules/tpl-friend-14_c.C
>  create mode 100644 gcc/testsuite/g++.dg/modules/tpl-friend-14_d.C
>  create mode 100644 gcc/testsuite/g++.dg/modules/tpl-friend-9.C
> 
> diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
> index 9975dc78456..0c14241fce7 100644
> --- a/gcc/cp/cp-tree.h
> +++ b/gcc/cp/cp-tree.h
> @@ -7417,6 +7417,8 @@ extern unsigned get_importing_module (tree, bool = 
> false) ATTRIBUTE_PURE;
>  extern void set_instantiating_module (tree);
>  extern void set_defining_module (tree);
>  extern void maybe_key_decl (tree ctx, tree decl);
> +extern void propagate_defining_module (tree decl, tree orig);
> +extern void remove_defining_module (tree decl);
>  
>  extern void man

Re: [PATCH v26 01/13] libstdc++: Optimize std::is_const compilation performance

On Sat, 11 May 2024, Ken Matsui wrote:

> This patch optimizes the compilation performance of std::is_const
> by dispatching to the new __is_const built-in trait.

This patch series LGTM

> 
> libstdc++-v3/ChangeLog:
> 
>   * include/std/type_traits (is_const): Use __is_const built-in
>   trait.
>   (is_const_v): Likewise.
> 
> Signed-off-by: Ken Matsui 
> ---
>  libstdc++-v3/include/std/type_traits | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/libstdc++-v3/include/std/type_traits 
> b/libstdc++-v3/include/std/type_traits
> index b441bf9908f..8df0cf3ac3b 100644
> --- a/libstdc++-v3/include/std/type_traits
> +++ b/libstdc++-v3/include/std/type_traits
> @@ -835,6 +835,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>// Type properties.
>  
>/// is_const
> +#if _GLIBCXX_USE_BUILTIN_TRAIT(__is_const)
> +  template
> +struct is_const
> +: public __bool_constant<__is_const(_Tp)>
> +{ };
> +#else
>template
>  struct is_const
>  : public false_type { };
> @@ -842,6 +848,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>template
>  struct is_const<_Tp const>
>  : public true_type { };
> +#endif
>  
>/// is_volatile
>template
> @@ -3331,10 +3338,15 @@ template 
>inline constexpr bool is_member_pointer_v = is_member_pointer<_Tp>::value;
>  #endif
>  
> +#if _GLIBCXX_USE_BUILTIN_TRAIT(__is_const)
> +template 
> +  inline constexpr bool is_const_v = __is_const(_Tp);
> +#else
>  template 
>inline constexpr bool is_const_v = false;
>  template 
>inline constexpr bool is_const_v = true;
> +#endif
>  
>  #if _GLIBCXX_USE_BUILTIN_TRAIT(__is_function)
>  template 
> -- 
> 2.44.0
> 
>

Re: [PATCH v26 01/13] libstdc++: Optimize std::is_const compilation performance

On Sat, 11 May 2024, Ken Matsui wrote:

> This patch optimizes the compilation performance of std::is_const
> by dispatching to the new __is_const built-in trait.

This patch series LGTM

> 
> libstdc++-v3/ChangeLog:
> 
>   * include/std/type_traits (is_const): Use __is_const built-in
>   trait.
>   (is_const_v): Likewise.
> 
> Signed-off-by: Ken Matsui 
> ---
>  libstdc++-v3/include/std/type_traits | 12 
>  1 file changed, 12 insertions(+)
> 
> diff --git a/libstdc++-v3/include/std/type_traits 
> b/libstdc++-v3/include/std/type_traits
> index b441bf9908f..8df0cf3ac3b 100644
> --- a/libstdc++-v3/include/std/type_traits
> +++ b/libstdc++-v3/include/std/type_traits
> @@ -835,6 +835,12 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>// Type properties.
>  
>/// is_const
> +#if _GLIBCXX_USE_BUILTIN_TRAIT(__is_const)
> +  template
> +struct is_const
> +: public __bool_constant<__is_const(_Tp)>
> +{ };
> +#else
>template
>  struct is_const
>  : public false_type { };
> @@ -842,6 +848,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
>template
>  struct is_const<_Tp const>
>  : public true_type { };
> +#endif
>  
>/// is_volatile
>template
> @@ -3331,10 +3338,15 @@ template 
>inline constexpr bool is_member_pointer_v = is_member_pointer<_Tp>::value;
>  #endif
>  
> +#if _GLIBCXX_USE_BUILTIN_TRAIT(__is_const)
> +template 
> +  inline constexpr bool is_const_v = __is_const(_Tp);
> +#else
>  template 
>inline constexpr bool is_const_v = false;
>  template 
>inline constexpr bool is_const_v = true;
> +#endif
>  
>  #if _GLIBCXX_USE_BUILTIN_TRAIT(__is_function)
>  template 
> -- 
> 2.44.0
> 
>

Re: [PATCH] libstdc++: Implement ranges::concat_view from P2542R7

On Mon, 29 Apr 2024, Jonathan Wakely wrote:

> On Mon, 22 Apr 2024 at 22:43, Patrick Palka wrote:
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?  More tests
> > are needed but I figured I'd submit this now for possible consideration into
> > GCC 14 since we're getting close to release..  All changes are confined to
> > C++26.
> 
> OK for trunk. Maybe we can backport it for 14.2 later, but not now.
> Sorry for the review being slow.

No worries, thanks a lot!  I pushed this now, though I realized I didn't
implement the latest/approved revision of the paper, R8 vs R7, which
notably changes the constraints on operator-(it, default_sentinel).
Since that seems to be the only significant change, I reckon I'll fix
that in a follow-up patch.

> 
> 
> >
> > -- >8 --
> >
> > libstdc++-v3/ChangeLog:
> >
> > * include/bits/version.def (ranges_concat): Define.
> > * include/bits/version.h: Regenerate.
> > * include/std/ranges (__detail::__concat_reference_t): Define
> > for C++26.
> > (__detail::__concat_value_t): Likewise.
> > (__detail::__concat_rvalue_reference_t): Likewise.
> > (__detail::__concat_indirectly_readable_impl): Likewise.
> > (__detail::__concat_indirectly_readable): Likewise.
> > (__detail::__concatable): Likewise.
> > (__detail::__all_but_last_common): Likewise.
> > (__detail::__concat_is_random_access): Likewise.
> > (__detail::__concat_is_bidirectional): Likewise.
> > (__detail::__last_is_common): Likewise.
> > (concat_view): Likewise.
> > (__detail::__concat_view_iter_cat): Likewise.
> > (concat_view::iterator): Likewise.
> > (views::__detail::__can_concat_view): Likewise.
> > (views::_Concat, views::concat): Likewise.
> > * testsuite/std/ranges/concat/1.cc: New test.
> > ---
> >  libstdc++-v3/include/bits/version.def |   8 +
> >  libstdc++-v3/include/bits/version.h   |  10 +
> >  libstdc++-v3/include/std/ranges   | 584 ++
> >  libstdc++-v3/testsuite/std/ranges/concat/1.cc |  61 ++
> >  4 files changed, 663 insertions(+)
> >  create mode 100644 libstdc++-v3/testsuite/std/ranges/concat/1.cc
> >
> > diff --git a/libstdc++-v3/include/bits/version.def 
> > b/libstdc++-v3/include/bits/version.def
> > index 5c0477fb61e..af13090c094 100644
> > --- a/libstdc++-v3/include/bits/version.def
> > +++ b/libstdc++-v3/include/bits/version.def
> > @@ -1796,6 +1796,14 @@ ftms = {
> >};
> >  };
> >
> > +ftms = {
> > +  name = ranges_concat;
> > +  values = {
> > +v = 202403;
> > +cxxmin = 26;
> > +  };
> > +};
> > +
> >  // Standard test specifications.
> >  stds[97] = ">= 199711L";
> >  stds[03] = ">= 199711L";
> > diff --git a/libstdc++-v3/include/bits/version.h 
> > b/libstdc++-v3/include/bits/version.h
> > index 65e708c73fb..1f27bfe050d 100644
> > --- a/libstdc++-v3/include/bits/version.h
> > +++ b/libstdc++-v3/include/bits/version.h
> > @@ -2003,4 +2003,14 @@
> >  #endif /* !defined(__cpp_lib_to_string) && 
> > defined(__glibcxx_want_to_string) */
> >  #undef __glibcxx_want_to_string
> >
> > +#if !defined(__cpp_lib_ranges_concat)
> > +# if (__cplusplus >  202302L)
> > +#  define __glibcxx_ranges_concat 202403L
> > +#  if defined(__glibcxx_want_all) || defined(__glibcxx_want_ranges_concat)
> > +#   define __cpp_lib_ranges_concat 202403L
> > +#  endif
> > +# endif
> > +#endif /* !defined(__cpp_lib_ranges_concat) && 
> > defined(__glibcxx_want_ranges_concat) */
> > +#undef __glibcxx_want_ranges_concat
> > +
> >  #undef __glibcxx_want_all
> > diff --git a/libstdc++-v3/include/std/ranges 
> > b/libstdc++-v3/include/std/ranges
> > index afce818376b..28a39bf6f34 100644
> > --- a/libstdc++-v3/include/std/ranges
> > +++ b/libstdc++-v3/include/std/ranges
> > @@ -55,6 +55,7 @@
> >  #define __glibcxx_want_ranges_as_const
> >  #define __glibcxx_want_ranges_as_rvalue
> >  #define __glibcxx_want_ranges_cartesian_product
> > +#define __glibcxx_want_ranges_concat
> >  #define __glibcxx_want_ranges_chunk
> >  #define __glibcxx_want_ranges_chunk_by
> >  #define __glibcxx_want_ranges_enumerate
> > @@ -9514,6 +9515,589 @@ namespace __detail
> >  } // namespace ranges
> >  #endif // __cpp_lib_ranges_to_container
> >
> > +#if __cpp_lib_ranges_concat // C++ >= C+

Re: [PATCH] libstdc++: Implement ranges::concat_view from P2542R7

On Mon, 29 Apr 2024, Jonathan Wakely wrote:

> On Mon, 22 Apr 2024 at 22:43, Patrick Palka wrote:
> >
> > Tested on x86_64-pc-linux-gnu, does this look OK for trunk?  More tests
> > are needed but I figured I'd submit this now for possible consideration into
> > GCC 14 since we're getting close to release..  All changes are confined to
> > C++26.
> 
> OK for trunk. Maybe we can backport it for 14.2 later, but not now.
> Sorry for the review being slow.

No worries, thanks a lot!  I pushed this now, though I realized I didn't
implement the latest/approved revision of the paper, R8 vs R7, which
notably changes the constraints on operator-(it, default_sentinel).
Since that seems to be the only significant change, I reckon I'll fix
that in a follow-up patch.

> 
> 
> >
> > -- >8 --
> >
> > libstdc++-v3/ChangeLog:
> >
> > * include/bits/version.def (ranges_concat): Define.
> > * include/bits/version.h: Regenerate.
> > * include/std/ranges (__detail::__concat_reference_t): Define
> > for C++26.
> > (__detail::__concat_value_t): Likewise.
> > (__detail::__concat_rvalue_reference_t): Likewise.
> > (__detail::__concat_indirectly_readable_impl): Likewise.
> > (__detail::__concat_indirectly_readable): Likewise.
> > (__detail::__concatable): Likewise.
> > (__detail::__all_but_last_common): Likewise.
> > (__detail::__concat_is_random_access): Likewise.
> > (__detail::__concat_is_bidirectional): Likewise.
> > (__detail::__last_is_common): Likewise.
> > (concat_view): Likewise.
> > (__detail::__concat_view_iter_cat): Likewise.
> > (concat_view::iterator): Likewise.
> > (views::__detail::__can_concat_view): Likewise.
> > (views::_Concat, views::concat): Likewise.
> > * testsuite/std/ranges/concat/1.cc: New test.
> > ---
> >  libstdc++-v3/include/bits/version.def |   8 +
> >  libstdc++-v3/include/bits/version.h   |  10 +
> >  libstdc++-v3/include/std/ranges   | 584 ++
> >  libstdc++-v3/testsuite/std/ranges/concat/1.cc |  61 ++
> >  4 files changed, 663 insertions(+)
> >  create mode 100644 libstdc++-v3/testsuite/std/ranges/concat/1.cc
> >
> > diff --git a/libstdc++-v3/include/bits/version.def 
> > b/libstdc++-v3/include/bits/version.def
> > index 5c0477fb61e..af13090c094 100644
> > --- a/libstdc++-v3/include/bits/version.def
> > +++ b/libstdc++-v3/include/bits/version.def
> > @@ -1796,6 +1796,14 @@ ftms = {
> >};
> >  };
> >
> > +ftms = {
> > +  name = ranges_concat;
> > +  values = {
> > +v = 202403;
> > +cxxmin = 26;
> > +  };
> > +};
> > +
> >  // Standard test specifications.
> >  stds[97] = ">= 199711L";
> >  stds[03] = ">= 199711L";
> > diff --git a/libstdc++-v3/include/bits/version.h 
> > b/libstdc++-v3/include/bits/version.h
> > index 65e708c73fb..1f27bfe050d 100644
> > --- a/libstdc++-v3/include/bits/version.h
> > +++ b/libstdc++-v3/include/bits/version.h
> > @@ -2003,4 +2003,14 @@
> >  #endif /* !defined(__cpp_lib_to_string) && 
> > defined(__glibcxx_want_to_string) */
> >  #undef __glibcxx_want_to_string
> >
> > +#if !defined(__cpp_lib_ranges_concat)
> > +# if (__cplusplus >  202302L)
> > +#  define __glibcxx_ranges_concat 202403L
> > +#  if defined(__glibcxx_want_all) || defined(__glibcxx_want_ranges_concat)
> > +#   define __cpp_lib_ranges_concat 202403L
> > +#  endif
> > +# endif
> > +#endif /* !defined(__cpp_lib_ranges_concat) && 
> > defined(__glibcxx_want_ranges_concat) */
> > +#undef __glibcxx_want_ranges_concat
> > +
> >  #undef __glibcxx_want_all
> > diff --git a/libstdc++-v3/include/std/ranges 
> > b/libstdc++-v3/include/std/ranges
> > index afce818376b..28a39bf6f34 100644
> > --- a/libstdc++-v3/include/std/ranges
> > +++ b/libstdc++-v3/include/std/ranges
> > @@ -55,6 +55,7 @@
> >  #define __glibcxx_want_ranges_as_const
> >  #define __glibcxx_want_ranges_as_rvalue
> >  #define __glibcxx_want_ranges_cartesian_product
> > +#define __glibcxx_want_ranges_concat
> >  #define __glibcxx_want_ranges_chunk
> >  #define __glibcxx_want_ranges_chunk_by
> >  #define __glibcxx_want_ranges_enumerate
> > @@ -9514,6 +9515,589 @@ namespace __detail
> >  } // namespace ranges
> >  #endif // __cpp_lib_ranges_to_container
> >
> > +#if __cpp_lib_ranges_concat // C++ >= C+

[gcc r15-809] libstdc++: Implement ranges::concat_view from P2542R7

2024-05-23 Thread Patrick Palka via Libstdc++-cvs

https://gcc.gnu.org/g:66d2a76dcf625f8dbe43d3c512e9c43f588fdc25

commit r15-809-g66d2a76dcf625f8dbe43d3c512e9c43f588fdc25
Author: Patrick Palka 
Date:   Thu May 23 18:03:56 2024 -0400

libstdc++: Implement ranges::concat_view from P2542R7

libstdc++-v3/ChangeLog:

* include/bits/version.def (ranges_concat): Define.
* include/bits/version.h: Regenerate.
* include/std/ranges (__detail::__concat_reference_t): Define
for C++26.
(__detail::__concat_value_t): Likewise.
(__detail::__concat_rvalue_reference_t): Likewise.
(__detail::__concat_indirectly_readable_impl): Likewise.
(__detail::__concat_indirectly_readable): Likewise.
(__detail::__concatable): Likewise.
(__detail::__all_but_last_common): Likewise.
(__detail::__concat_is_random_access): Likewise.
(__detail::__concat_is_bidirectional): Likewise.
(__detail::__last_is_common): Likewise.
(concat_view): Likewise.
(__detail::__concat_view_iter_cat): Likewise.
(concat_view::iterator): Likewise.
(views::__detail::__can_concat_view): Likewise.
(views::_Concat, views::concat): Likewise.
* testsuite/std/ranges/concat/1.cc: New test.

Reviewed-by: Jonathan Wakely 

Diff:
---
 libstdc++-v3/include/bits/version.def |   8 +
 libstdc++-v3/include/bits/version.h   |  10 +
 libstdc++-v3/include/std/ranges   | 580 ++
 libstdc++-v3/testsuite/std/ranges/concat/1.cc |  74 
 4 files changed, 672 insertions(+)

diff --git a/libstdc++-v3/include/bits/version.def 
b/libstdc++-v3/include/bits/version.def
index 5cbc9d1a8d8..683b967d54b 100644
--- a/libstdc++-v3/include/bits/version.def
+++ b/libstdc++-v3/include/bits/version.def
@@ -1805,6 +1805,14 @@ ftms = {
   };
 };
 
+ftms = {
+  name = ranges_concat;
+  values = {
+v = 202403;
+cxxmin = 26;
+  };
+};
+
 // Standard test specifications.
 stds[97] = ">= 199711L";
 stds[03] = ">= 199711L";
diff --git a/libstdc++-v3/include/bits/version.h 
b/libstdc++-v3/include/bits/version.h
index 164ebed4983..4850041c0a3 100644
--- a/libstdc++-v3/include/bits/version.h
+++ b/libstdc++-v3/include/bits/version.h
@@ -2013,4 +2013,14 @@
 #endif /* !defined(__cpp_lib_to_string) && defined(__glibcxx_want_to_string) */
 #undef __glibcxx_want_to_string
 
+#if !defined(__cpp_lib_ranges_concat)
+# if (__cplusplus >  202302L)
+#  define __glibcxx_ranges_concat 202403L
+#  if defined(__glibcxx_want_all) || defined(__glibcxx_want_ranges_concat)
+#   define __cpp_lib_ranges_concat 202403L
+#  endif
+# endif
+#endif /* !defined(__cpp_lib_ranges_concat) && 
defined(__glibcxx_want_ranges_concat) */
+#undef __glibcxx_want_ranges_concat
+
 #undef __glibcxx_want_all
diff --git a/libstdc++-v3/include/std/ranges b/libstdc++-v3/include/std/ranges
index afce818376b..b1e827c9a72 100644
--- a/libstdc++-v3/include/std/ranges
+++ b/libstdc++-v3/include/std/ranges
@@ -55,6 +55,7 @@
 #define __glibcxx_want_ranges_as_const
 #define __glibcxx_want_ranges_as_rvalue
 #define __glibcxx_want_ranges_cartesian_product
+#define __glibcxx_want_ranges_concat
 #define __glibcxx_want_ranges_chunk
 #define __glibcxx_want_ranges_chunk_by
 #define __glibcxx_want_ranges_enumerate
@@ -9514,6 +9515,585 @@ namespace __detail
 } // namespace ranges
 #endif // __cpp_lib_ranges_to_container
 
+#if __cpp_lib_ranges_concat // C++ >= C++26
+namespace ranges
+{
+  namespace __detail
+  {
+template
+  using __concat_reference_t = 
common_reference_t...>;
+
+template
+  using __concat_value_t = common_type_t...>;
+
+template
+  using __concat_rvalue_reference_t
+   = common_reference_t...>;
+
+template
+  concept __concat_indirectly_readable_impl = requires(const _It __it) {
+   { *__it } -> convertible_to<_Ref>;
+   { ranges::iter_move(__it) } -> convertible_to<_RRef>;
+  };
+
+template
+  concept __concat_indirectly_readable
+   = common_reference_with<__concat_reference_t<_Rs...>&&, 
__concat_value_t<_Rs...>&>
+ && common_reference_with<__concat_reference_t<_Rs...>&&,
+  __concat_rvalue_reference_t<_Rs...>&&>
+ && common_reference_with<__concat_rvalue_reference_t<_Rs...>&&,
+  __concat_value_t<_Rs...> const&>
+ && (__concat_indirectly_readable_impl<__concat_reference_t<_Rs...>,
+   
__concat_rvalue_reference_t<_Rs...>,
+   iterator_t<_Rs>>
+ && ...);
+
+template
+  concept __concatable = requires

Re: [PATCH] c++: alias CTAD and copy deduction guide [PR115198]