Re: How do I Contact the Rpmfusion List?

[Thomas Cameron]

On 6/10/24 5:18 PM, Stephen Morris wrote:

Hi,
     I have installed Jellyfin from rpmfusion by following the 
instructions on the Jellyfin web site for Fedora.
     After activating Developer Mode on my TV I used Docker to install 
the Jellyfin client on the TV.
     I ran the Jellyfin script to open up Jellyfin in Firewalld (After 
starting FirewallD as the service seemed to not have been activated 
after the upgrade to F40).
     I then enabled and started the Jellyfin service on my pc to start 
the server.
     When I invoke Jellyfin on the TV and supply the require IP address 
of my pc and required port, the Jellyfin client tells me the server (I 
think) needs to be upgraded and gives me the Github URL to get the upgrade.
     Hence I need to approach the Rpmfusion guys to see if they can 
upgrade the server to the latest version.


regards,
Steve


Have a look at https://rpmfusion.org/ReportingBugs - it tells you to 
open a bug at https://bugzilla.rpmfusion.org/.


You can also contact the developers at 
https://lists.rpmfusion.org/archives/ but that's not the ideal. Follow 
the instructions about reporting bugs.


Hope this helps!

--
Thomas
--
___
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

Hex File Snooper

[Thomas Passin]

Sometimes it is useful to view the first N bytes of a file without reading 
the whole file.  The file might be much too large to load into a text 
editor or a Leo node, for example. The Linux command *head* will show you 
just the start of a file, but Windows doesn't have that command out of the 
box.  Often it's better to look at the hex bytes rather than the text, 
especially if the file is binary.  Say, for example, that you want to see 
if a file is a zip file or not, or if the EXIF data is embedded in a .jpg 
picture file.

Here is a Leo command that loads a file using the file dialog.  It creates 
a new node at the end of your outline and fills it with a classic hex view 
of the first 4096 bytes.

I have this script as an *@command* node in my myLeoSettings.leo file, and 
I also have a custom menu item for it.  I don't use it all the time but 
it's invaluable when it is needed.

Here is the script:

"""Display as hex the first 4096 bytes of a file in body of a new node."""

data = ''

def format_bytes(bytes):
"""Format byte data into classic hex bytes display."""
text = ''
asc = ' ' * 3  # For translation of bytes to ascii characters
n = 0
for i, b in enumerate(bytes):
text += f'{b:02x}'
asc += chr(b) if b > 0x1F else '.'
if i > 0 and i % 10 == 9:
# Complete the current line
text += asc
text += '\n'
asc = ' ' * 3
n += 1
if n % 8 == 0:
# Insert a blank line for readability
text += '\n'
else:
text += ' '
return text

filetypes = [('Any', '*.*'),]
path = g.app.gui.runOpenFileDialog(c, 'Choose File To Sample', 
filetypes=filetypes)
g.es(path)

if path:
try:
with open(path, 'rb') as f:
data = f.read(4096)
except IOError as e:
g.es(e)

if data:
# Create and select target node
p_last = c.lastVisible()
target = p_last.insertAfter()
target.h = f'first bytes of {path}'
target.b = f'{format_bytes(data)}'
target.setDirty()
c.selectPosition(target)
while c.canMoveOutlineLeft():
c.moveOutlineLeft()
c.redraw()

Here is (just the first part) of the bytes of an image file of mine.  We 
can see the signature of a .jpg file. and that it uses the *sRGB* color map.

ff d8 ff e0 00 10 4a 46 49 46   ÿØÿà..JFIF
00 01 01 00 00 01 00 01 00 00   ..
ff e2 0c 58 49 43 43 5f 50 52   ÿâ.XICC_PR
4f 46 49 4c 45 00 01 01 00 00   OFILE.
0c 48 6c 63 6d 73 02 10 00 00   .Hlcms
6d 6e 74 72 52 47 42 20 58 59   mntrRGB XY
5a 20 07 ce 00 02 00 09 00 06   Z .Î..
00 31 00 00 61 63 73 70 4d 53   .1..acspMS

46 54 00 00 00 00 49 45 43 20   FTIEC 
73 52 47 42 00 00 00 00 00 00   sRGB..
00 00 00 00 00 00 00 00 f6 d6   öÖ
00 01 00 00 00 00 d3 2d 6c 63   ..Ó-lc
6d 73 00 00 00 00 00 00 00 00   ms
00 00 00 00 00 00 00 00 00 00   ..
00 00 00 00 00 00 00 00 00 00   ..
00 00 00 00 00 00 00 00 00 00   ..

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/e50dd9cf-2015-4345-8c31-7a0d0bddcba9n%40googlegroups.com.

Re: libpq v17 PQsocketPoll timeout is not granular enough

[Thomas Munro]

On Tue, Jun 11, 2024 at 2:36 AM Dominique Devienne  wrote:
> Hi. I've noticed [that libpq API in v17 beta1][1], and wanted to use
> it to replace an existing Boost.ASIO-based async polling of the
> connection's socket, waiting for notifications. The use case being
> using PostgreSQL LISTEN/NOTIFY for a simple message queue. The code
> needs to be cross-platform Windows and Linux. My goal would be to
> eliminate that Boost.ASIO dependency for that, to use just libpq.

One idea I have wondered about is why you wouldn't just use poll()
directly, if you want a facility that works on all known operating
systems without extra portability libraries.  Windows has WSApoll(),
which AFAIK was designed to be Unix-compatible and a drop-in
replacement, requiring just a rename but otherwise having the same
macros and struct etc.

For some period of time, people who had to deal with socket connection
events (that includes us) avoided it, with the Curl guys' blog being
the most often cited public explanation for why:

https://daniel.haxx.se/blog/2012/10/10/wsapoll-is-broken/

However, as far as I know, that was fixed ~4 years ago:

https://learn.microsoft.com/en-us/windows/win32/api/winsock2/nf-winsock2-wsapoll

"Note  As of Windows 10 version 2004, when a TCP socket fails to
connect, (POLLHUP \| POLLERR \| POLLWRNORM) is indicated."

I wonder if that means that it's now completely usable on all
reasonable versions of the OS.  I think so?  I don't use Windows
myself, my interest in this topic is that I have a slow moving
background project to figure out how and when to remove all remaining
uses of select() from our tree, and this one is on my hit list.

> PQsocketPoll() being based on time_t, it has only second resolution, AFAIK.
> Despite the [underlying implementation in fe-misc.c][2] supporting at
> least milliseconds.

Yeah, that is not nice and your complaint is very reasonable, and we
should probably do something like what Tom suggested.

Hmm, but if what I speculated above is true, I wonder if the extern
function is even worth its bits...  but I don't know how to determine
that completely.

Re: [External] : Why do I get the following error `wrong signature length` when I try to validate a signed file using the c++ OpenSSL 3.1 library?

[Thomas Dwyer III via openssl-users]

|if (EVP_PKEY_verify(ctx, licenseSignature, sizeof(licenseSignature), 
licenseContent, sizeof(licenseContent)) <= 0)|


The sizeof operator is not doing what you think it's doing. It's 
computing the sizes of the pointers (typically 4 or 8 bytes depending on 
your architecture) and not the sizes of your signature & signed content. 
You need to pass additional size_t values to your verifyLicense() 
function so that EVP_PKEY_verify() can know what those lengths really 
are. It's impossible to determine this from just a char* pointer.



Tom.III


On 6/10/24 13:15, Christian F. Gonzalez Di Antonio wrote:
I posted this on 
https://stackoverflow.com/questions/78604338/why-do-i-get-the-following-error-wrong-signature-length-when-i-try-to-validate 
 



I'm writing an c++ program LicenseValidator -> 
https://github.com/christiangda/LicenseValidator 
 to 
validate a hypothetical |program license| using OpenSSL 3.1 Library 
, 
and when I tried to validate the licensed content I got the following 
error:


|Failed to verify license 008C1AF90100:error:0277:rsa 
routines:ossl_rsa_verify:wrong signature 
length:crypto/rsa/rsa_sign.c:338: 
008C1AF90100:error:1C880004:Provider routines:rsa_verify:RSA 
lib:providers/implementations/signature/rsa_sig.c:785: |


I would appreciate any help or guidance on what I am doing wrong.

I am not at all an expert in the c/c++ programming language and this 
is the first time I have tried to use the OpenSSL library.


Of course, I've used GitHub Copilot, gemini, and chatgpt to write and 
understand the repository code. The chalenge is about the examples I 
found on internet, the majority of them are about OpenSSL v1 and the 
v3 is very different, so was hard to understand the migration.


The README.md 
 file 
has the instructions to create all the necessary keys, etc, references 
I used and the instructions to compile it using cmake.


The core function is LicenseValidator/src/License.cpp 
:


|bool verifyLicense(const unsigned char *licenseContent, const 
unsigned char *licenseSignature, const std::string pubkey) { EVP_PKEY 
*pkey = loadRsaPemPubKey(pubkey); if (pkey == NULL) { std::cerr << 
"Failed to load public key" << std::endl; ERR_print_errors_fp(stdout); 
return false; } EVP_PKEY_CTX *ctx = EVP_PKEY_CTX_new(pkey, NULL); if 
(ctx == NULL) { std::cerr << "Failed to create EVP_PKEY_CTX" << 
std::endl; EVP_PKEY_free(pkey); ERR_print_errors_fp(stdout); return 
false; } if (EVP_PKEY_verify_init(ctx) <= 0) { std::cerr << "Failed to 
initialize EVP_PKEY_CTX" << std::endl; EVP_PKEY_CTX_free(ctx); 
EVP_PKEY_free(pkey); ERR_print_errors_fp(stdout); return false; } // 
PKCS1 padding scheme if (EVP_PKEY_CTX_set_rsa_padding(ctx, 
RSA_PKCS1_PADDING) <= 0) { std::cerr << "Failed to set RSA padding" << 
std::endl; EVP_PKEY_CTX_free(ctx); EVP_PKEY_free(pkey); 
ERR_print_errors_fp(stdout); return false; } // SHA256 digest if 
(EVP_PKEY_CTX_set_signature_md(ctx, EVP_sha256()) <= 0) { std::cerr << 
"Failed to set signature MD" << std::endl; EVP_PKEY_CTX_free(ctx); 
EVP_PKEY_free(pkey); ERR_print_errors_fp(stdout); return false; } if 
(EVP_PKEY_verify(ctx, licenseSignature, sizeof(licenseSignature), 
licenseContent, sizeof(licenseContent)) <= 0) { std::cerr << "Failed 
to verify license" << std::endl; EVP_PKEY_CTX_free(ctx); 
EVP_PKEY_free(pkey); ERR_print_errors_fp(stdout); return false; } 
EVP_PKEY_CTX_free(ctx); EVP_PKEY_free(pkey); return true; } |


Some guidance about how to solve the error I got.


--
Saludos,
Christian

Re: [PATCH] drm/amd: force min_input_signal to 0 on Framework AMD 13/16

[Thomas Weißschuh]

On 2024-06-10 14:58:02+, Mario Limonciello wrote:
> +Kieran
> 
> On 6/10/2024 14:26, Thomas Weißschuh wrote:
> > The value of "min_input_signal" returned from ATIF on a Framework AMD 13
> > is "12". This leads to a fairly bright minimum display backlight.
> > 
> > Introduce a quirk to override "min_input_signal" to "0" which leads to a
> > much lower minimum brightness, which is still readable even in daylight.
> > 
> > Tested on a Framework AMD 13 BIOS 3.05 and Framework AMD 16.
> > 
> > Link: https://community.frame.work/t/25711/9
> > Link: https://community.frame.work/t/47036
> > Signed-off-by: Thomas Weißschuh 
> > ---
> >   drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 35 
> > 
> >   1 file changed, 35 insertions(+)
> > 
> > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c 
> > b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> > index 7099ff9cf8c5..b481889f7491 100644
> > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
> > @@ -25,6 +25,7 @@
> >   #include 
> >   #include 
> >   #include 
> > +#include 
> >   #include 
> >   #include 
> >   #include 
> > @@ -130,6 +131,35 @@ static struct amdgpu_acpi_priv {
> > struct amdgpu_atcs atcs;
> >   } amdgpu_acpi_priv;
> > +struct amdgpu_acpi_quirks {
> > +   bool ignore_min_input_signal;
> > +};
> > +
> > +static const struct dmi_system_id amdgpu_acpi_quirk_table[] = {
> > +   {
> > +   /* the Framework Laptop 13 (AMD Ryzen) and 16 (AMD Ryzen) */
> > +   .matches = {
> > +   DMI_MATCH(DMI_SYS_VENDOR, "Framework"),
> > +   DMI_MATCH(DMI_PRODUCT_NAME, "AMD Ryzen"),
> > +   DMI_MATCH(DMI_PRODUCT_FAMILY, "Laptop"),
> > +   },
> 
> Two problems I see:
> 
> 1) This really "should" be fixed in the BIOS. I added Kieran to the thread
> for comments if that's viable.

Agreed!

> 2) IMO this is going to match too liberally across all potential Framework
> models.  If they introduce a refreshed motherboard for either product then
> the quirk would apply to both products when we don't know that such a
> deficiency would exist.

Also agreed.
In addition to be really specific this should also match by display type
(via EDID?).

So far this was only tested with the matte panel.
(I forgot to mention that, sorry)

> You can reference drivers/platform/x86/amd/pmc/pmc-quirks.c for what we used
> for a quirk that was matching against a single product and single BIOS.

Will do for the next revision, but let's gather some feedback first.

> But FWIW if that issue isn't fixed in the next BIOS I think we'll end up
> needing to tear out the BIOS string match and match just the platform.

I'm wondering what the longterm strategy will have to be.
Given that there are different kinds of displays, and new ones will be
released, each new display type will require an update to the firmware.

When there are no firmware updates for a device anymore, but new,
compatible displays are released, then the kernel will need the quirks
again.

> > +   .driver_data = &(struct amdgpu_acpi_quirks) {
> > +   .ignore_min_input_signal = true,
> > +   },
> > +   },
> > +   {}
> > +};
> > +
> > +static const struct amdgpu_acpi_quirks *amdgpu_acpi_get_quirks(void)
> > +{
> > +   const struct dmi_system_id *dmi_id;
> > +
> > +   dmi_id = dmi_first_match(amdgpu_acpi_quirk_table);
> > +   if (!dmi_id)
> > +   return NULL;
> > +   return dmi_id->driver_data;
> > +}
> > +
> >   /* Call the ATIF method
> >*/
> >   /**
> > @@ -1388,6 +1418,7 @@ bool amdgpu_acpi_should_gpu_reset(struct 
> > amdgpu_device *adev)
> >*/
> >   void amdgpu_acpi_detect(void)
> >   {
> > +   const struct amdgpu_acpi_quirks *quirks = amdgpu_acpi_get_quirks();
> > struct amdgpu_atif *atif = _acpi_priv.atif;
> > struct amdgpu_atcs *atcs = _acpi_priv.atcs;
> > struct pci_dev *pdev = NULL;
> > @@ -1429,6 +1460,10 @@ void amdgpu_acpi_detect(void)
> > ret);
> > atif->backlight_caps.caps_valid = false;
> > }
> > +   if (quirks && quirks->ignore_min_input_signal) {
> > +   DRM_INFO("amdgpu_acpi quirk: min_input_signal=0\n");
> > +   atif->backlight_caps.min_input_signal = 0;
> > +   }
> > } else {
> > atif->backlight_caps.caps_valid = false;
> > }
> > 
> > ---
> > base-commit: 83a7eefedc9b56fe7bfeff13b6c7356688ffa670
> > change-id: 20240610-amdgpu-min-backlight-quirk-8402fd8e736a
> > 
> > Best regards,
> 

[PATCH] drm/amd: force min_input_signal to 0 on Framework AMD 13/16

[Thomas Weißschuh]

The value of "min_input_signal" returned from ATIF on a Framework AMD 13
is "12". This leads to a fairly bright minimum display backlight.

Introduce a quirk to override "min_input_signal" to "0" which leads to a
much lower minimum brightness, which is still readable even in daylight.

Tested on a Framework AMD 13 BIOS 3.05 and Framework AMD 16.

Link: https://community.frame.work/t/25711/9
Link: https://community.frame.work/t/47036
Signed-off-by: Thomas Weißschuh 
---
 drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c | 35 
 1 file changed, 35 insertions(+)

diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c 
b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
index 7099ff9cf8c5..b481889f7491 100644
--- a/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
+++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_acpi.c
@@ -25,6 +25,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -130,6 +131,35 @@ static struct amdgpu_acpi_priv {
struct amdgpu_atcs atcs;
 } amdgpu_acpi_priv;
 
+struct amdgpu_acpi_quirks {
+   bool ignore_min_input_signal;
+};
+
+static const struct dmi_system_id amdgpu_acpi_quirk_table[] = {
+   {
+   /* the Framework Laptop 13 (AMD Ryzen) and 16 (AMD Ryzen) */
+   .matches = {
+   DMI_MATCH(DMI_SYS_VENDOR, "Framework"),
+   DMI_MATCH(DMI_PRODUCT_NAME, "AMD Ryzen"),
+   DMI_MATCH(DMI_PRODUCT_FAMILY, "Laptop"),
+   },
+   .driver_data = &(struct amdgpu_acpi_quirks) {
+   .ignore_min_input_signal = true,
+   },
+   },
+   {}
+};
+
+static const struct amdgpu_acpi_quirks *amdgpu_acpi_get_quirks(void)
+{
+   const struct dmi_system_id *dmi_id;
+
+   dmi_id = dmi_first_match(amdgpu_acpi_quirk_table);
+   if (!dmi_id)
+   return NULL;
+   return dmi_id->driver_data;
+}
+
 /* Call the ATIF method
  */
 /**
@@ -1388,6 +1418,7 @@ bool amdgpu_acpi_should_gpu_reset(struct amdgpu_device 
*adev)
  */
 void amdgpu_acpi_detect(void)
 {
+   const struct amdgpu_acpi_quirks *quirks = amdgpu_acpi_get_quirks();
struct amdgpu_atif *atif = _acpi_priv.atif;
struct amdgpu_atcs *atcs = _acpi_priv.atcs;
struct pci_dev *pdev = NULL;
@@ -1429,6 +1460,10 @@ void amdgpu_acpi_detect(void)
ret);
atif->backlight_caps.caps_valid = false;
}
+   if (quirks && quirks->ignore_min_input_signal) {
+   DRM_INFO("amdgpu_acpi quirk: min_input_signal=0\n");
+   atif->backlight_caps.min_input_signal = 0;
+   }
} else {
atif->backlight_caps.caps_valid = false;
}

---
base-commit: 83a7eefedc9b56fe7bfeff13b6c7356688ffa670
change-id: 20240610-amdgpu-min-backlight-quirk-8402fd8e736a

Best regards,
-- 
Thomas Weißschuh 

Re: execute-external-file & execute-general-script

[Thomas Passin]

I don't have an example for *execute-general-script*, but I want to point 
out that it is *not* the same command as *CTRL-B*, *execute-script*.

On Sunday, June 9, 2024 at 11:23:35 PM UTC-4 Thomas Passin wrote:

> Good to know, Felix.  Please see if you can test it on one or another 
> Linux distros - I had a hard time getting the script to work with some of 
> them.
>
> I think getting the script to work is an important milestone.  It means 
> that we can develop code with LeoJs in many other languages than 
> javascript/txx
>
> On Sunday, June 9, 2024 at 10:22:40 PM UTC-4 Félix wrote:
>
>> I got it working with the julia setup you provided! thanks a lot for your 
>> example. 
>>
>> I also tried it with a simple shell script like this and it also worked 
>> [image: example.png]
>>
>> and I also got the 'execute-general-script' command working so I'll 
>> release a new LeoJS beta version with all the new stuff and recent fixes in 
>> a day or two! 
>>
>> :)
>>
>> Thanks again! 
>>
>> On Sunday, June 9, 2024 at 5:48:42 PM UTC-4 tbp1...@gmail.com wrote:
>>
>>> Go, Félix!
>>>
>>> On Sunday, June 9, 2024 at 5:39:48 PM UTC-4 Félix wrote:
>>>
>>>> Merci Thomas! :)
>>>>
>>>> On Sunday, June 9, 2024 at 4:26:16 PM UTC-4 tbp1...@gmail.com wrote:
>>>>
>>>>> For the *execute-external-file* script*, *here is one of my test 
>>>>> files,  a tiny Julia file (of course, install Julia first):
>>>>>
>>>>> headline: @file julia-1.jl
>>>>> # function to calculate the volume of a sphere
>>>>> function sphere_vol(r)
>>>>> # julia allows Unicode names (in UTF-8 encoding)
>>>>> # so either "pi" or the symbol π can be used
>>>>> # return (4/3)*pi*r^3
>>>>> return (4/3)*π*r^3
>>>>> end
>>>>>
>>>>> vol = sphere_vol(3)
>>>>>
>>>>> # @printf allows number formatting but does not automatically append 
>>>>> the \n to statements
>>>>> using Printf
>>>>> @printf "volume = %0.3f\n" vol
>>>>>
>>>>> For the command to find the Julia processor, you have to create an 
>>>>> @data settings node named *@data run-external-processor-map, *like 
>>>>> this one (.py scripts are hardcoded in, of course, and don't need to be 
>>>>> included here):
>>>>>
>>>>> EXTENSIONS
>>>>> .jl: julia  # Trailing comments are allowed
>>>>> .lua: lua
>>>>> .rb: ruby
>>>>> .nim: nim
>>>>>
>>>>> PROCESSORS
>>>>> julia: julia
>>>>> lua: lua
>>>>> nim: nim
>>>>> # Originally, ruby was not on the PATH, so we needed its full path:
>>>>> # ruby: C:\Ruby27-x64\bin\ruby.exe
>>>>>
>>>>> # After ruby was added to the PATH, we could use its bare name:
>>>>> ruby: ruby
>>>>>
>>>>> This command is supposed to open a new terminal window and run the 
>>>>> command in it.  The terminal *must* stay open after the external program 
>>>>> ends so that the user can read any output (especially error messages!).  
>>>>> The trickiest part of the command is figuring out the terminal launch 
>>>>> command for Linux that will launch and stay open at the end, since there 
>>>>> is 
>>>>> no one standard method good on all Linux distros.  My script uses some 
>>>>> heuristics to try to get it right.  These can include scanning the 
>>>>> --help output of the candidate terminal, IIRC.
>>>>> On Sunday, June 9, 2024 at 3:56:45 PM UTC-4 Félix wrote:
>>>>>
>>>>>> Hello Leonistas! :)
>>>>>>
>>>>>> I'm currently implementing and testing the *execute-external-file *& 
>>>>>> *execute-general-script 
>>>>>> *commands in LeoJS.
>>>>>>
>>>>>> *execute-external-file was made by Thomas around February 2023 while 
>>>>>> execute-general-script was made by Edward around june 2021.*
>>>>>>
>>>>>> I was just wondering if anyone could send me 
>>>>>> 'minimal/proof-of-concept' stripped down leo file(s) to test any of 
>>>>>> those 
>>>>>> two commands. (with simple 'toy'/'hello-world' scripts to run with them) 
>>>>>> If 
>>>>>> you have a few minutes to spare to prepare such a thing... :)
>>>>>>
>>>>>> Thanks! 
>>>>>>
>>>>>> Félix
>>>>>>
>>>>>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/4bcfc530-a5fe-4095-9df8-9d7b42f1670fn%40googlegroups.com.

Bug#1020217: snapshot.debian.org: write a generic file driver supporting multiple backend (such as object-storage)

[thomas]

Even worse than this: closed source SERVICE that can be taken down at any 
moment in a split of a second... 


Sponsored cloud services are a very dangerous drugs to be addicted to. Someone 
else computer, like the FSFE puts it! 


As for the work, again, that'd be on me for the setup and maintenance (though 
not physical setup, but we can pay a service provider for that if we have no 
other option...). 


Thomas 


Sent from Workspace ONE Boxer 


On Jun 9, 2024 8:10 PM, Andreas Tille  wrote:

Hi Thomas, 

Am Sun, Jun 09, 2024 at 12:17:05PM +0200 schrieb Thomas Goirand: 
> 
> However, it is disappointing to see it moving toward an s3 implementation, 
> which is a protocol from a closed-source service. I already wrote multiple 
> times that my company (Infomaniak) was willing to sponsor storage space on 
> Swift for it. 
> ... 
> So all together, we're looking at a 100kEUR spending. Note that this type of 
> swift cluster could also be used for artifact storage for Salsa (gitlab has 
> a swift backend storage driver). 

As far as I understand the problem you see is that a valuable service of 
Debian might get dependant from a closed-source service, right?  I would 
like to hear the opinion of the poeple who are actually working on this. 

Kind regards 
Andreas. 

-- 
https://fam-tille.de 

Bug#1020217: snapshot.debian.org: write a generic file driver supporting multiple backend (such as object-storage)

[thomas]

Even worse than this: closed source SERVICE that can be taken down at any 
moment in a split of a second... 


Sponsored cloud services are a very dangerous drugs to be addicted to. Someone 
else computer, like the FSFE puts it! 


As for the work, again, that'd be on me for the setup and maintenance (though 
not physical setup, but we can pay a service provider for that if we have no 
other option...). 


Thomas 


Sent from Workspace ONE Boxer 


On Jun 9, 2024 8:10 PM, Andreas Tille  wrote:

Hi Thomas, 

Am Sun, Jun 09, 2024 at 12:17:05PM +0200 schrieb Thomas Goirand: 
> 
> However, it is disappointing to see it moving toward an s3 implementation, 
> which is a protocol from a closed-source service. I already wrote multiple 
> times that my company (Infomaniak) was willing to sponsor storage space on 
> Swift for it. 
> ... 
> So all together, we're looking at a 100kEUR spending. Note that this type of 
> swift cluster could also be used for artifact storage for Salsa (gitlab has 
> a swift backend storage driver). 

As far as I understand the problem you see is that a valuable service of 
Debian might get dependant from a closed-source service, right?  I would 
like to hear the opinion of the poeple who are actually working on this. 

Kind regards 
Andreas. 

-- 
https://fam-tille.de 

Re: Release Apache MINA SSHD 2.13.0?

[Thomas Wolf]

Guillaume, could you please prepare and stage a release?

Cheers,

  Thomas

On 08.06.24 21:35 , Gary Gregory wrote:

Sounds  good to me.

Gary

On Sat, Jun 8, 2024, 2:56 PM Thomas Wolf <mailto:tw...@apache.org>> wrote:


On 2024-06-08 20:48 , Thomas Wolf wrote:
 > I suggest we start with a release for Apache MINA 2.13.0.

Apache MINA SSHD, of course.

Cheers,

        Thomas


-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
<mailto:dev-unsubscr...@mina.apache.org>
For additional commands, e-mail: dev-h...@mina.apache.org
<mailto:dev-h...@mina.apache.org>




-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

[VOTE RESULT] Release Apache Felix SCR 2.2.12

[Thomas Watson]

Hi,

I neglected to close out this vote, doing so now ...

The vote passed with four binding +1

Tom

Re: [VOTE] Release Apache Felix SCR 2.2.12

[Thomas Watson]

+1

Tom

On Thu, May 2, 2024 at 12:03 PM Karl Pauls  wrote:

> +1
>
> regards,
>
> Karl
>
> On Thursday, May 2, 2024, Carsten Ziegeler  wrote:
>
> > +1
> >
> > Carsten
> >
> > On 02.05.2024 15:24, Thomas Watson wrote:
> >
> >> Hi,
> >>
> >> We solved one issues for SCR 2.2.12
> >> https://issues.apache.org/jira/projects/FELIX/versions/12354172
> >>
> >>
> >> Staging repository:
> >> https://repository.apache.org/content/repositories/orgapachefelix-1494
> >>
> >> You can use this UNIX script to download the release and verify the
> >> signatures:
> >> https://github.com/apache/felix-dev/blob/master/check_staged_release.sh
> >>
> >> Usage:
> >> sh check_staged_release.sh 1493 /tmp/felix-staging
> >>
> >> Please vote to approve this release:
> >>
> >> [ ] +1 Approve the release
> >> [ ] -1 Veto the release (please provide specific comments)
> >>
> >> This vote will be open for 72 hours.
> >>
> >> Thanks
> >> Tom
> >>
> >>
> > --
> > Carsten Ziegeler
> > Adobe
> > cziege...@apache.org
> >
>
>
> --
> Karl Pauls
> karlpa...@gmail.com
>

[PATCH v2 1/3] drm/mgag200: Consolidate VGA output

[Thomas Zimmermann]

The various models have common code for the VGA output's encoder and
connector. Move everything into a single shared source file. Remove some
obsolete initializer macros. No functional changes.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/mgag200/Makefile  |  3 +-
 drivers/gpu/drm/mgag200/mgag200_drv.h | 24 +++-
 drivers/gpu/drm/mgag200/mgag200_g200.c| 46 +--
 drivers/gpu/drm/mgag200/mgag200_g200eh.c  | 46 +--
 drivers/gpu/drm/mgag200/mgag200_g200eh3.c | 46 +--
 drivers/gpu/drm/mgag200/mgag200_g200er.c  | 46 +--
 drivers/gpu/drm/mgag200/mgag200_g200ev.c  | 46 +--
 drivers/gpu/drm/mgag200/mgag200_g200ew3.c | 46 +--
 drivers/gpu/drm/mgag200/mgag200_g200se.c  | 46 +--
 drivers/gpu/drm/mgag200/mgag200_g200wb.c  | 46 +--
 drivers/gpu/drm/mgag200/mgag200_vga.c | 68 +++
 11 files changed, 95 insertions(+), 368 deletions(-)
 create mode 100644 drivers/gpu/drm/mgag200/mgag200_vga.c

diff --git a/drivers/gpu/drm/mgag200/Makefile b/drivers/gpu/drm/mgag200/Makefile
index 0b919352046eb..d1b25f9f6586e 100644
--- a/drivers/gpu/drm/mgag200/Makefile
+++ b/drivers/gpu/drm/mgag200/Makefile
@@ -11,6 +11,7 @@ mgag200-y := \
mgag200_g200ew3.o \
mgag200_g200se.o \
mgag200_g200wb.o \
-   mgag200_mode.o
+   mgag200_mode.o \
+   mgag200_vga.o
 
 obj-$(CONFIG_DRM_MGAG200) += mgag200.o
diff --git a/drivers/gpu/drm/mgag200/mgag200_drv.h 
b/drivers/gpu/drm/mgag200/mgag200_drv.h
index 20e3710e056b3..db89fddc26dcb 100644
--- a/drivers/gpu/drm/mgag200/mgag200_drv.h
+++ b/drivers/gpu/drm/mgag200/mgag200_drv.h
@@ -283,8 +283,12 @@ struct mga_device {
 
struct drm_plane primary_plane;
struct drm_crtc crtc;
-   struct drm_encoder encoder;
-   struct drm_connector connector;
+   struct {
+   struct {
+   struct drm_encoder encoder;
+   struct drm_connector connector;
+   } vga;
+   } output;
 };
 
 static inline struct mga_device *to_mga_device(struct drm_device *dev)
@@ -417,25 +421,15 @@ void mgag200_crtc_atomic_destroy_state(struct drm_crtc 
*crtc, struct drm_crtc_st
.atomic_duplicate_state = mgag200_crtc_atomic_duplicate_state, \
.atomic_destroy_state = mgag200_crtc_atomic_destroy_state
 
-#define MGAG200_DAC_ENCODER_FUNCS \
-   .destroy = drm_encoder_cleanup
-
-#define MGAG200_VGA_CONNECTOR_HELPER_FUNCS \
-   .get_modes = drm_connector_helper_get_modes
-
-#define MGAG200_VGA_CONNECTOR_FUNCS \
-   .reset  = drm_atomic_helper_connector_reset, \
-   .fill_modes = drm_helper_probe_single_connector_modes, \
-   .destroy= drm_connector_cleanup, \
-   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state, \
-   .atomic_destroy_state   = drm_atomic_helper_connector_destroy_state
-
 void mgag200_set_mode_regs(struct mga_device *mdev, const struct 
drm_display_mode *mode);
 void mgag200_set_format_regs(struct mga_device *mdev, const struct 
drm_format_info *format);
 void mgag200_enable_display(struct mga_device *mdev);
 void mgag200_init_registers(struct mga_device *mdev);
 int mgag200_mode_config_init(struct mga_device *mdev, resource_size_t 
vram_available);
 
+/* mgag200_vga.c */
+int mgag200_vga_output_init(struct mga_device *mdev);
+
/* mgag200_bmc.c */
 void mgag200_bmc_disable_vidrst(struct mga_device *mdev);
 void mgag200_bmc_enable_vidrst(struct mga_device *mdev);
diff --git a/drivers/gpu/drm/mgag200/mgag200_g200.c 
b/drivers/gpu/drm/mgag200/mgag200_g200.c
index 39a29d8ffca6e..ff467b0f9cbf3 100644
--- a/drivers/gpu/drm/mgag200/mgag200_g200.c
+++ b/drivers/gpu/drm/mgag200/mgag200_g200.c
@@ -9,7 +9,6 @@
 #include 
 #include 
 
-#include "mgag200_ddc.h"
 #include "mgag200_drv.h"
 
 static int mgag200_g200_init_pci_options(struct pci_dev *pdev)
@@ -184,26 +183,11 @@ static const struct drm_crtc_funcs 
mgag200_g200_crtc_funcs = {
MGAG200_CRTC_FUNCS,
 };
 
-static const struct drm_encoder_funcs mgag200_g200_dac_encoder_funcs = {
-   MGAG200_DAC_ENCODER_FUNCS,
-};
-
-static const struct drm_connector_helper_funcs 
mgag200_g200_vga_connector_helper_funcs = {
-   MGAG200_VGA_CONNECTOR_HELPER_FUNCS,
-};
-
-static const struct drm_connector_funcs mgag200_g200_vga_connector_funcs = {
-   MGAG200_VGA_CONNECTOR_FUNCS,
-};
-
 static int mgag200_g200_pipeline_init(struct mga_device *mdev)
 {
struct drm_device *dev = >base;
struct drm_plane *primary_plane = >primary_plane;
struct drm_crtc *crtc = >crtc;
-   struct drm_encoder *encoder = >encoder;
-   struct drm_connector *connector = >connector;
-   struct i2c_adapter *ddc;
int ret;
 
ret = drm_universal_plane_init(dev, primary_plane, 0,
@@ -231,35 +215,9 @@ static int mgag200_g200_pip

[PATCH v2 2/3] drm/mgag200: Add BMC output

[Thomas Zimmermann]

The BMC output can be viewed via the BMC's web interface or a
similar client. Represent it as virtual encoder and connector.
It's attached to the same CRTC as the VGA connector.

The connector's status depends on the physical connector's status.
The BMC is only connected if the physical connector is not. This
is necessary to support userspace clients that can only handle a
single output per CRTC.

The BMC is a server feature. Add a BMC output for all server chips,
but not the desktop models.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/mgag200/mgag200_bmc.c | 107 ++
 drivers/gpu/drm/mgag200/mgag200_drv.h |  10 ++
 drivers/gpu/drm/mgag200/mgag200_g200eh.c  |   4 +
 drivers/gpu/drm/mgag200/mgag200_g200eh3.c |   4 +
 drivers/gpu/drm/mgag200/mgag200_g200er.c  |   4 +
 drivers/gpu/drm/mgag200/mgag200_g200ev.c  |   4 +
 drivers/gpu/drm/mgag200/mgag200_g200ew3.c |   4 +
 drivers/gpu/drm/mgag200/mgag200_g200se.c  |   4 +
 drivers/gpu/drm/mgag200/mgag200_g200wb.c  |   4 +
 9 files changed, 145 insertions(+)

diff --git a/drivers/gpu/drm/mgag200/mgag200_bmc.c 
b/drivers/gpu/drm/mgag200/mgag200_bmc.c
index 2ba2e3c5086a5..23ef85aa7e378 100644
--- a/drivers/gpu/drm/mgag200/mgag200_bmc.c
+++ b/drivers/gpu/drm/mgag200/mgag200_bmc.c
@@ -2,8 +2,18 @@
 
 #include 
 
+#include 
+#include 
+#include 
+#include 
+
 #include "mgag200_drv.h"
 
+static struct mgag200_bmc_connector *to_mgag200_bmc_connector(struct 
drm_connector *connector)
+{
+   return container_of(connector, struct mgag200_bmc_connector, base);
+}
+
 void mgag200_bmc_disable_vidrst(struct mga_device *mdev)
 {
u8 tmp;
@@ -97,3 +107,100 @@ void mgag200_bmc_enable_vidrst(struct mga_device *mdev)
tmp &= ~0x10;
WREG_DAC(MGA1064_GEN_IO_DATA, tmp);
 }
+
+static const struct drm_encoder_funcs mgag200_bmc_encoder_funcs = {
+   .destroy = drm_encoder_cleanup,
+};
+
+static int mgag200_bmc_connector_helper_detect_ctx(struct drm_connector 
*connector,
+  struct 
drm_modeset_acquire_ctx *ctx,
+  bool force)
+{
+   struct mgag200_bmc_connector *bmc_connector = 
to_mgag200_bmc_connector(connector);
+   struct drm_connector *physical_connector = 
bmc_connector->physical_connector;
+
+   /*
+* Most user-space compositors cannot handle more than one connected
+* connector per CRTC. Hence, we only mark the BMC as connected if the
+* physical connector is disconnected. If the physical connector's 
status
+* is connected or unknown, the BMC remains disconnected. This has no
+* effect on the output of the BMC.
+*
+* FIXME: Remove this logic once user-space compositors can handle more
+*than one connector per CRTC. The BMC should always be 
connected.
+*/
+
+   if (physical_connector && physical_connector->status == 
connector_status_disconnected)
+   return connector_status_connected;
+
+   return connector_status_disconnected;
+}
+
+static int mgag200_bmc_connector_helper_get_modes(struct drm_connector 
*connector)
+{
+   struct drm_device *dev = connector->dev;
+   struct mga_device *mdev = to_mga_device(dev);
+   const struct mgag200_device_info *minfo = mdev->info;
+
+   return drm_add_modes_noedid(connector, minfo->max_hdisplay, 
minfo->max_vdisplay);
+}
+
+static const struct drm_connector_helper_funcs 
mgag200_bmc_connector_helper_funcs = {
+   .get_modes = mgag200_bmc_connector_helper_get_modes,
+   .detect_ctx = mgag200_bmc_connector_helper_detect_ctx,
+};
+
+static const struct drm_connector_funcs mgag200_bmc_connector_funcs = {
+   .reset = drm_atomic_helper_connector_reset,
+   .fill_modes = drm_helper_probe_single_connector_modes,
+   .destroy = drm_connector_cleanup,
+   .atomic_duplicate_state = drm_atomic_helper_connector_duplicate_state,
+   .atomic_destroy_state = drm_atomic_helper_connector_destroy_state,
+};
+
+static int mgag200_bmc_connector_init(struct drm_device *dev,
+ struct mgag200_bmc_connector 
*bmc_connector,
+ struct drm_connector *physical_connector)
+{
+   struct drm_connector *connector = _connector->base;
+   int ret;
+
+   ret = drm_connector_init(dev, connector, _bmc_connector_funcs,
+DRM_MODE_CONNECTOR_VIRTUAL);
+   if (ret)
+   return ret;
+   drm_connector_helper_add(connector, 
_bmc_connector_helper_funcs);
+
+   bmc_connector->physical_connector = physical_connector;
+
+   return 0;
+}
+
+int mgag200_bmc_output_init(struct mga_device *mdev, struct drm_connector 
*physical_connector)
+{
+   struct drm_device *dev = >base;
+   struct drm_crtc *crtc = >crtc;
+   struct drm_encoder *encoder;
+   struct mgag200_bmc_co

[PATCH v2 3/3] drm/mgag200: Set .detect_ctx() and enable connector polling

[Thomas Zimmermann]

Set .detect_ctx() in struct drm_connector_helper_funcs to the
common helper drm_connector_helper_detect_from_ddc() and enable
polling for the connector. Mgag200 will now test for the monitor's
presence by probing the DDC in regular intervals.

Signed-off-by: Thomas Zimmermann 
---
 drivers/gpu/drm/mgag200/mgag200_g200.c| 1 +
 drivers/gpu/drm/mgag200/mgag200_g200eh.c  | 1 +
 drivers/gpu/drm/mgag200/mgag200_g200eh3.c | 1 +
 drivers/gpu/drm/mgag200/mgag200_g200er.c  | 1 +
 drivers/gpu/drm/mgag200/mgag200_g200ev.c  | 1 +
 drivers/gpu/drm/mgag200/mgag200_g200ew3.c | 1 +
 drivers/gpu/drm/mgag200/mgag200_g200se.c  | 1 +
 drivers/gpu/drm/mgag200/mgag200_g200wb.c  | 1 +
 drivers/gpu/drm/mgag200/mgag200_vga.c | 6 +-
 9 files changed, 13 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/mgag200/mgag200_g200.c 
b/drivers/gpu/drm/mgag200/mgag200_g200.c
index ff467b0f9cbf3..f874e29498409 100644
--- a/drivers/gpu/drm/mgag200/mgag200_g200.c
+++ b/drivers/gpu/drm/mgag200/mgag200_g200.c
@@ -401,6 +401,7 @@ struct mga_device *mgag200_g200_device_create(struct 
pci_dev *pdev, const struct
return ERR_PTR(ret);
 
drm_mode_config_reset(dev);
+   drm_kms_helper_poll_init(dev);
 
return mdev;
 }
diff --git a/drivers/gpu/drm/mgag200/mgag200_g200eh.c 
b/drivers/gpu/drm/mgag200/mgag200_g200eh.c
index 6f31c5249f0b1..52bf49ead5c50 100644
--- a/drivers/gpu/drm/mgag200/mgag200_g200eh.c
+++ b/drivers/gpu/drm/mgag200/mgag200_g200eh.c
@@ -277,6 +277,7 @@ struct mga_device *mgag200_g200eh_device_create(struct 
pci_dev *pdev, const stru
return ERR_PTR(ret);
 
drm_mode_config_reset(dev);
+   drm_kms_helper_poll_init(dev);
 
return mdev;
 }
diff --git a/drivers/gpu/drm/mgag200/mgag200_g200eh3.c 
b/drivers/gpu/drm/mgag200/mgag200_g200eh3.c
index 5befe8da4beb2..e7f89b2a59fd0 100644
--- a/drivers/gpu/drm/mgag200/mgag200_g200eh3.c
+++ b/drivers/gpu/drm/mgag200/mgag200_g200eh3.c
@@ -182,6 +182,7 @@ struct mga_device *mgag200_g200eh3_device_create(struct 
pci_dev *pdev,
return ERR_PTR(ret);
 
drm_mode_config_reset(dev);
+   drm_kms_helper_poll_init(dev);
 
return mdev;
 }
diff --git a/drivers/gpu/drm/mgag200/mgag200_g200er.c 
b/drivers/gpu/drm/mgag200/mgag200_g200er.c
index 55c275180cde2..4e8a1756138d7 100644
--- a/drivers/gpu/drm/mgag200/mgag200_g200er.c
+++ b/drivers/gpu/drm/mgag200/mgag200_g200er.c
@@ -316,6 +316,7 @@ struct mga_device *mgag200_g200er_device_create(struct 
pci_dev *pdev, const stru
return ERR_PTR(ret);
 
drm_mode_config_reset(dev);
+   drm_kms_helper_poll_init(dev);
 
return mdev;
 }
diff --git a/drivers/gpu/drm/mgag200/mgag200_g200ev.c 
b/drivers/gpu/drm/mgag200/mgag200_g200ev.c
index 2466126140db6..d884f3cb0ec79 100644
--- a/drivers/gpu/drm/mgag200/mgag200_g200ev.c
+++ b/drivers/gpu/drm/mgag200/mgag200_g200ev.c
@@ -321,6 +321,7 @@ struct mga_device *mgag200_g200ev_device_create(struct 
pci_dev *pdev, const stru
return ERR_PTR(ret);
 
drm_mode_config_reset(dev);
+   drm_kms_helper_poll_init(dev);
 
return mdev;
 }
diff --git a/drivers/gpu/drm/mgag200/mgag200_g200ew3.c 
b/drivers/gpu/drm/mgag200/mgag200_g200ew3.c
index a52e60609c3de..839401e8b4654 100644
--- a/drivers/gpu/drm/mgag200/mgag200_g200ew3.c
+++ b/drivers/gpu/drm/mgag200/mgag200_g200ew3.c
@@ -202,6 +202,7 @@ struct mga_device *mgag200_g200ew3_device_create(struct 
pci_dev *pdev,
return ERR_PTR(ret);
 
drm_mode_config_reset(dev);
+   drm_kms_helper_poll_init(dev);
 
return mdev;
 }
diff --git a/drivers/gpu/drm/mgag200/mgag200_g200se.c 
b/drivers/gpu/drm/mgag200/mgag200_g200se.c
index 212770acdd477..a824bb8ad5791 100644
--- a/drivers/gpu/drm/mgag200/mgag200_g200se.c
+++ b/drivers/gpu/drm/mgag200/mgag200_g200se.c
@@ -521,6 +521,7 @@ struct mga_device *mgag200_g200se_device_create(struct 
pci_dev *pdev, const stru
return ERR_PTR(ret);
 
drm_mode_config_reset(dev);
+   drm_kms_helper_poll_init(dev);
 
return mdev;
 }
diff --git a/drivers/gpu/drm/mgag200/mgag200_g200wb.c 
b/drivers/gpu/drm/mgag200/mgag200_g200wb.c
index cb6daa0426fbc..835df0f4fc13d 100644
--- a/drivers/gpu/drm/mgag200/mgag200_g200wb.c
+++ b/drivers/gpu/drm/mgag200/mgag200_g200wb.c
@@ -326,6 +326,7 @@ struct mga_device *mgag200_g200wb_device_create(struct 
pci_dev *pdev, const stru
return ERR_PTR(ret);
 
drm_mode_config_reset(dev);
+   drm_kms_helper_poll_init(dev);
 
return mdev;
 }
diff --git a/drivers/gpu/drm/mgag200/mgag200_vga.c 
b/drivers/gpu/drm/mgag200/mgag200_vga.c
index 6d8982990c2c3..60568f32736dd 100644
--- a/drivers/gpu/drm/mgag200/mgag200_vga.c
+++ b/drivers/gpu/drm/mgag200/mgag200_vga.c
@@ -12,7 +12,8 @@ static const struct drm_encoder_funcs 
mgag200_dac_encoder_funcs = {
 };
 
 static const struct drm_connector_helper_funcs 
mgag200_vga_connector_helper_funcs = {
-   .get_modes

[PATCH v2 0/3] drm/mgag200: Detect connector status

[Thomas Zimmermann]

Detect the connector status by polling the DDC. Update the status at
runtime. Add a dedicated BMC output to still display to the BMC while
the VGA connector is not attached.

This patchset fixes a long-standing problem where attaching the VGA
display a runtime resulted in incorrect display modes.

Tested on various Matrox hardware.

v2:
- move the DDC clean up into a separate patchset [1]
- add dedicated BMC support (Jocelyn)

[1] https://patchwork.freedesktop.org/series/133537/

Thomas Zimmermann (3):
  drm/mgag200: Consolidate VGA output
  drm/mgag200: Add BMC output
  drm/mgag200: Set .detect_ctx() and enable connector polling

 drivers/gpu/drm/mgag200/Makefile  |   3 +-
 drivers/gpu/drm/mgag200/mgag200_bmc.c | 107 ++
 drivers/gpu/drm/mgag200/mgag200_drv.h |  34 ---
 drivers/gpu/drm/mgag200/mgag200_g200.c|  47 +-
 drivers/gpu/drm/mgag200/mgag200_g200eh.c  |  47 +-
 drivers/gpu/drm/mgag200/mgag200_g200eh3.c |  47 +-
 drivers/gpu/drm/mgag200/mgag200_g200er.c  |  47 +-
 drivers/gpu/drm/mgag200/mgag200_g200ev.c  |  47 +-
 drivers/gpu/drm/mgag200/mgag200_g200ew3.c |  47 +-
 drivers/gpu/drm/mgag200/mgag200_g200se.c  |  47 +-
 drivers/gpu/drm/mgag200/mgag200_g200wb.c  |  47 +-
 drivers/gpu/drm/mgag200/mgag200_vga.c |  72 +++
 12 files changed, 238 insertions(+), 354 deletions(-)
 create mode 100644 drivers/gpu/drm/mgag200/mgag200_vga.c


base-commit: 2bea08bd31298d60d416b2a6ed346bb53dd28037
-- 
2.45.2

[jira] [Commented] (OAK-8046) Result items are not always correctly counted against the configured read limit if a query uses a lucene index

[Thomas Mueller (Jira)]

[ 
https://issues.apache.org/jira/browse/OAK-8046?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=17853671#comment-17853671
 ] 

Thomas Mueller commented on OAK-8046:
-

>  I guess the only thing we can do is move this class to an ignored log file 

[~royteeuwen] No. Best is if the queries read less than 200 nodes, and 
relatively quickly (within a second or so). 

> Result items are not always correctly counted against the configured read 
> limit if a query uses a lucene index 
> ---
>
> Key: OAK-8046
> URL: https://issues.apache.org/jira/browse/OAK-8046
> Project: Jackrabbit Oak
>  Issue Type: Improvement
>  Components: lucene
>Affects Versions: 1.8.7
>Reporter: Georg Henzler
>Assignee: Vikas Saurabh
>Priority: Major
> Fix For: 1.12.0, 1.10.1, 1.8.12
>
> Attachments: OAK-8046-take2.patch, OAK-8046.patch
>
>
> There are cases where an index is re-opened during query execution. In that 
> case, already returned entries are read again and skipped, so basically 
> counted twice. This should be fixed to only count entries once (see also [1])
> The issue most likely exists since the read limit was introduced with OAK-6875
> [1] 
> https://lists.apache.org/thread.html/dddf9834fee0bccb6e48f61ba2a01430e34fc0b464b12809f7dfe2eb@%3Coak-dev.jackrabbit.apache.org%3E



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

Re: [PATCH] drm/edid: reduce DisplayID log spamming

[Thomas Zimmermann]

Am 06.06.24 um 14:35 schrieb Jani Nikula:

Debug printing at DisplayID validation leads to lots of log spamming as
it's called at DisplayID iterators during EDID parsing. Remove it, and
replace with a less noisy message at connector EDID update.

Signed-off-by: Jani Nikula 


Acked-by: Thomas Zimmermann 


---
  drivers/gpu/drm/drm_displayid.c | 3 ---
  drivers/gpu/drm/drm_edid.c  | 5 +
  2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_displayid.c b/drivers/gpu/drm/drm_displayid.c
index 9d01d762801f..b4fd43783c50 100644
--- a/drivers/gpu/drm/drm_displayid.c
+++ b/drivers/gpu/drm/drm_displayid.c
@@ -33,9 +33,6 @@ validate_displayid(const u8 *displayid, int length, int idx)
if (IS_ERR(base))
return base;
  
-	DRM_DEBUG_KMS("base revision 0x%x, length %d, %d %d\n",

- base->rev, base->bytes, base->prod_id, base->ext_count);
-
/* +1 for DispID checksum */
dispid_length = sizeof(*base) + base->bytes + 1;
if (dispid_length > length - idx)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index f68a41eeb1fa..9fc7292f5382 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -6629,6 +6629,11 @@ static void update_displayid_info(struct drm_connector 
*connector,
  
  	displayid_iter_edid_begin(drm_edid, );

displayid_iter_for_each(block, ) {
+   drm_dbg_kms(connector->dev,
+   "[CONNECTOR:%d:%s] DisplayID extension version 0x%02x, 
primary use 0x%02x\n",
+   connector->base.id, connector->name,
+   displayid_version(),
+   displayid_primary_use());
if (displayid_version() == DISPLAY_ID_STRUCTURE_VER_20 &&
(displayid_primary_use() == 
PRIMARY_USE_HEAD_MOUNTED_VR ||
 displayid_primary_use() == 
PRIMARY_USE_HEAD_MOUNTED_AR))


--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)

Re: [PATCH] drm/edid: reduce DisplayID log spamming

[Thomas Zimmermann]

Am 06.06.24 um 14:35 schrieb Jani Nikula:

Debug printing at DisplayID validation leads to lots of log spamming as
it's called at DisplayID iterators during EDID parsing. Remove it, and
replace with a less noisy message at connector EDID update.

Signed-off-by: Jani Nikula 


Acked-by: Thomas Zimmermann 


---
  drivers/gpu/drm/drm_displayid.c | 3 ---
  drivers/gpu/drm/drm_edid.c  | 5 +
  2 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/gpu/drm/drm_displayid.c b/drivers/gpu/drm/drm_displayid.c
index 9d01d762801f..b4fd43783c50 100644
--- a/drivers/gpu/drm/drm_displayid.c
+++ b/drivers/gpu/drm/drm_displayid.c
@@ -33,9 +33,6 @@ validate_displayid(const u8 *displayid, int length, int idx)
if (IS_ERR(base))
return base;
  
-	DRM_DEBUG_KMS("base revision 0x%x, length %d, %d %d\n",

- base->rev, base->bytes, base->prod_id, base->ext_count);
-
/* +1 for DispID checksum */
dispid_length = sizeof(*base) + base->bytes + 1;
if (dispid_length > length - idx)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index f68a41eeb1fa..9fc7292f5382 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -6629,6 +6629,11 @@ static void update_displayid_info(struct drm_connector 
*connector,
  
  	displayid_iter_edid_begin(drm_edid, );

displayid_iter_for_each(block, ) {
+   drm_dbg_kms(connector->dev,
+   "[CONNECTOR:%d:%s] DisplayID extension version 0x%02x, 
primary use 0x%02x\n",
+   connector->base.id, connector->name,
+   displayid_version(),
+   displayid_primary_use());
if (displayid_version() == DISPLAY_ID_STRUCTURE_VER_20 &&
(displayid_primary_use() == 
PRIMARY_USE_HEAD_MOUNTED_VR ||
 displayid_primary_use() == 
PRIMARY_USE_HEAD_MOUNTED_AR))


--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)

Re: Bug: bash redirect "magic" variable content to input of command hangs (upstream of https://github.com/git-for-windows/git/issues/5001)

[Thomas Wolff via Cygwin]

Am 10.06.2024 um 13:12 schrieb Holger Klene via Cygwin:

Hi Cygwin,

On reading a magic value back from a bash variable, the involved command (wc, 
grep, cat, ...) hangs indefinitely and has to be stopped by Ctrl+C

Editing it's content by deleting lines, the "magic" goes away. Also as 
demonstrated, other text-files (even twice the size) work fine.

See this bash session:
---
holgerk@BX-NB-015 /cygdrive/c/Users/holgerk
$ wc -l magic.txt text.log
   2074 magic.txt
   4214 text.log
   6288 insgesamt

holgerk@BX-NB-015 /cygdrive/c/Users/holgerk
$ md5sum magic.txt text.log
8ee7af38464d80a716d18d44c0a22f22 *magic.txt
0211535797c8d2e6b363f7dde147949f *text.log

holgerk@BX-NB-015 /cygdrive/c/Users/holgerk
$ cat magic.txt | wc -l
2074

holgerk@BX-NB-015 /cygdrive/c/Users/holgerk
$ cat text.log | wc -l
4214

holgerk@BX-NB-015 /cygdrive/c/Users/holgerk
$ declare ctrl=$(cat magic.txt) && printf '%s\n' "$ctrl" | wc -l
2074

holgerk@BX-NB-015 /cygdrive/c/Users/holgerk
$ declare ctrl=$(cat text.log) && printf '%s\n' "$ctrl" | wc -l
4214

holgerk@BX-NB-015 /cygdrive/c/Users/holgerk
$ declare ctrl=$(cat text.log) && wc -l <<< "$ctrl"
4214

holgerk@BX-NB-015 /cygdrive/c/Users/holgerk
$ declare ctrl=$(cat magic.txt) && wc -l <<< "$ctrl"


holgerk@BX-NB-015 /cygdrive/c/Users/holgerk
$ declare ctrl=$(cat magic.txt) && grep hallo <<< "$ctrl"



holgerk@BX-NB-015 /cygdrive/c/Users/holgerk
$ declare ctrl=$(cat magic.txt) && cat <<< "$ctrl"


Works for me.


---

This is:
GNU bash, Version 5.2.21(1)-release (x86_64-pc-cygwin)

Was also reproduced in git-bash 5.2.26(1)-release (also cygwin)
but not in WSL-bash 5.1.16 (independent of cygwin)


Thanks
Holger

PS: I reported this to git first:


Gesendet: Montag, 10. Juni 2024 um 11:58 Uhr
Von: "Johannes Schindelin" 
An: "git-for-windows/git" 
Cc: "Holger Klene" , "Mention" 
Betreff: Re: [git-for-windows/git] bash redirect "magic" variable content to 
input of command hangs (Issue #5001)

I just verified that this is happening in regular https://cygwin.com/ which, in 
this ticket's context is an upstream project of Git for Windows, as we use a 
slightly modified version of the Cygwin runtime as POSIX emulation layer that 
allows Bash to work.
@hklene[https://github.com/hklene] would you mind reporting it 
there[https://cygwin.com/problems.html]?
—
Reply to this email directly, view it on 
GitHub[https://github.com/git-for-windows/git/issues/5001#issuecomment-2157897799],
 or unsubscribe.




--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Bug#1071007: Bug#1072733: sherlock: Must not ship /usr/lib/python3/dist-packages/__init__.py

[Thomas Goirand]

On 6/9/24 18:47, Samuel Henrique wrote:

Zigo,

I just saw that sherlock (the social networks package) moved its python
files to /usr/share, instead of /usr/lib/python3/dist-packages
. This was
the sensible thing to do, as it doesn't really need to expose itself as
Python module.


Not really, that was done by accident when Nilson was trying to remove the
system-wide init file (#1071007) and was reverted already.

Upstream has mentioned (to me) that their intention is to provide a library for
sherlock, as we've had since the package was introduced.


Well, sherlock is an app, and therefore, it's the sensible thing to do 
to push it's Python code in /usr/share. IMO, it shouldn't have been 
reverted.


Normally, the one that owns the PyPi name such as:
https://pypi.org/project/sherlock/

also get to have the python module name. Clearly, sherlock (the social 
media package) didn't do that.


Now, if you know upstream, then probably you can convince them to rename 
their lib to something that doesn't clash? And also, maybe, add its 
software on PyPi?



Therefore, this bug can be closed, and there's IMO nothing more to do in
the python-sherlock (the cluster lock package), as the conflict is now
solved.


I'll reopen 1072733 since the clash still exists.


:(

Cheers,

Thomas Goirand (zigo)

Bug#1071007: Bug#1072733: sherlock: Must not ship /usr/lib/python3/dist-packages/__init__.py

[Thomas Goirand]

On 6/9/24 18:47, Samuel Henrique wrote:

Zigo,

I just saw that sherlock (the social networks package) moved its python
files to /usr/share, instead of /usr/lib/python3/dist-packages
. This was
the sensible thing to do, as it doesn't really need to expose itself as
Python module.


Not really, that was done by accident when Nilson was trying to remove the
system-wide init file (#1071007) and was reverted already.

Upstream has mentioned (to me) that their intention is to provide a library for
sherlock, as we've had since the package was introduced.


Well, sherlock is an app, and therefore, it's the sensible thing to do 
to push it's Python code in /usr/share. IMO, it shouldn't have been 
reverted.


Normally, the one that owns the PyPi name such as:
https://pypi.org/project/sherlock/

also get to have the python module name. Clearly, sherlock (the social 
media package) didn't do that.


Now, if you know upstream, then probably you can convince them to rename 
their lib to something that doesn't clash? And also, maybe, add its 
software on PyPi?



Therefore, this bug can be closed, and there's IMO nothing more to do in
the python-sherlock (the cluster lock package), as the conflict is now
solved.


I'll reopen 1072733 since the clash still exists.


:(

Cheers,

Thomas Goirand (zigo)

Bug#1034672: new ISO

[Thomas Lange]

Hi,

there are new FAI ISO available using FAI 6.2.2. Does this problem still exist?
-- 
viele Grüße Thomas

Re: RFR: 8330846: Add stacks of mounted virtual threads to the HotSpot thread dump [v8]

[Thomas Stuefe]

On Tue, 4 Jun 2024 13:46:16 GMT, Inigo Mediavilla Saiz  wrote:

>> src/hotspot/share/runtime/threads.cpp line 1336:
>> 
>>> 1334: oop vt = p->vthread();
>>> 1335: assert(vt != nullptr, "");
>>> 1336: st->print_cr("   \tMounted virtual thread #" 
>>> INT64_FORMAT, (int64_t)java_lang_Thread::thread_id(vt));
>> 
>> Please no manual indentation, see remarks above.
>
> I'm leaving minimal indentation and I will update the code on a new PR to 
> rely on your changes if it's OK for you @tstuefe

Okay, that works.

-

PR Review Comment: https://git.openjdk.org/jdk/pull/19482#discussion_r1632931400

[krita] [Bug 482365] Crash

[Thomas Krenn]

https://bugs.kde.org/show_bug.cgi?id=482365

--- Comment #6 from Thomas Krenn  ---
Hello all,
below is the kritacrash.log:

Error occurred on Sunday, June 9, 2024 at 11:15:08.

krita.exe caused an Access Violation at location 7FF81156DD48 in module
libkritaimage.dll Reading from location 0010.

AddrPC   Params
7FF81156DD48 65DDC283A4C6 02A2 02A2D1D213D0 
libkritaimage.dll!KisKeyframeChannel::allKeyframeTimes+0x18
7FF8271E0F85    
kritawebpexport.dll!KisWebPExport::convert+0x15b5
7FF807A3A8E6 02A2C46602D8 00E6 00E0 
libkritaui.dll!KisImportExportManager::doExportImpl+0x126
7FF807A39F07 0010  7FF814A967E8 
libkritaui.dll!KisImportExportManager::doExport+0x67
7FF807A3D2EA   02A2C9A94A10 
libkritaui.dll!std::__1::__invoke[abi:v15000],
KisPinnedSharedPtr, QString),
KisImportExportManager*&, QString&, QSharedPointer&,
KisPinnedSharedPtr&, QString&, void>+0xaa
7FF807A3CE2C  7FF8576EFDE6 02A2E4D1BE60 
libkritaui.dll!QtConcurrent::StoredFunctorCall0,
KisPinnedSharedPtr, QString),
KisImportExportManager*, QString const&,
QSharedPointer&,
KisPinnedSharedPtr&, QString const&>
>::runFunctor+0x3c
7FF807A3CD4C  7FF8145CC98C 02A2F1D36EB0 
libkritaui.dll!QtConcurrent::RunFunctionTask::run+0x2c
7FF8145D1056    
Qt5Core.dll!QThreadPoolThread::run+0xb6
7FF8145CD59A    
Qt5Core.dll!QThreadPrivate::start+0x10a
7FF8596A7034    
KERNEL32.DLL!BaseThreadInitThunk+0x14
7FF859D42651    
ntdll.dll!RtlUserThreadStart+0x21

7FF7616C-7FF761705000 krita.exe 5.2.2.100
7FF859CF-7FF859EE5000 ntdll.dll 6.2.19041.1288
7FF85969-7FF85974E000 KERNEL32.DLL  6.2.19041.1202
7FF85741-7FF8576D9000 KERNELBASE.dll6.2.19041.1202
7FF8576E-7FF8577E ucrtbase.dll  6.2.19041.789
7FF815C7-7FF816315000 krita.dll
7FF81120-7FF811858000 libkritaimage.dll
7FF8074E-7FF807E2 libkritaui.dll
7FF8362D-7FF8363BF000 libkritaresources.dll
7FF833BD-7FF833CCA000 libkritaglobal.dll
7FF852CB-7FF852CBD000 libkritamultiarch.dll
7FF814DE-7FF815344000 Qt5Widgets.dll5.15.7.0
7FF857FA-7FF8586DF000 SHELL32.dll   6.2.19041.1266
7FF857B9-7FF857C2D000 msvcp_win.dll 6.2.19041.789
7FF85980-7FF8599A1000 USER32.dll6.2.19041.1202
7FF857A2-7FF857A42000 win32u.dll6.2.19041.1288
7FF8599B-7FF8599DB000 GDI32.dll 6.2.19041.1202
7FF857C3-7FF857D3B000 gdi32full.dll 6.2.19041.1110
7FF858E7-7FF858F9A000 ole32.dll 6.2.19041.1202
7FF85906-7FF85918A000 RPCRT4.dll6.2.19041.1288
7FF858B1-7FF858E65000 combase.dll   6.2.19041.1288
7FF806D7-7FF8074DE000 Qt5Gui.dll5.15.7.0
7FF83879-7FF8387E1000 libKF5I18n.dll
7FF83806-7FF8380BA000 libKF5ConfigCore.dll
7FF8145B-7FF814B26000 Qt5Core.dll   5.15.7.0
7FF833AA-7FF833BCC000 libc++.dll
7FF859BB-7FF859C1B000 WS2_32.dll6.2.19041.546
7FF8599E-7FF859A8C000 ADVAPI32.dll  6.2.19041.1052
7FF85976-7FF8597FE000 msvcrt.dll7.0.19041.546
7FF8588F-7FF85898B000 sechost.dll   6.2.19041.906
7FF8508F-7FF8508FE000 libunwind.dll
7FF836F0-7FF836F7E000 libkritapsdutils.dll
7FF84E9B-7FF84E9E libkritametadata.dll
7FF83143-7FF8315BF000 libfftw3.dll
7FF82108-7FF8213DE000 libkritapigment.dll
7FF844B9-7FF844BAE000 libkritacommand.dll
7FF83E4F-7FF83E53C000 libHalf-2_5.dll
7FF82FAA-7FF82FBE1000 libkritawidgetutils.dll
7FF841F1-7FF841F32000 libkritaplugin.dll
7FF8365F-7FF836632000 Qt5Xml.dll5.15.7.0
7FF83F36-7FF83F397000 Qt5Sql.dll5.15.7.0
7FF843B5-7FF843B69000 libkritastore.dll
7FF841E5-7FF841E8 libquazip5.dll
7FF84E9A-7FF84E9AA000 libkritaversion.dll
7FF82F94-7FF82FA95000 Qt5Network.dll5.15.7.0
7FF83F2E-7FF83F32 libpng16.dll
7FF84360-7FF84361E000 libkritaimpex.dll
7FF8455B-7FF8455BB000 libkritacolor.dll
7FF83627-7FF8362C4000 libkritalibbrush.dll
7FF8339B-7FF833A9F000 libkritawidgets.dll
7FF8578C-7FF857A16000 CRYPT32.dll   6.2.19041.1202
7FF83E66-7FF83E693000 libKF5Completion.dll
7FF841E0-7FF841E22000 libmlt++-7.dll
7FF821A8-7FF821CF9000 libkri

[dns-operations] Google traffic pattern

[Thomas Dupas via dns-operations]

--- Begin Message ---
Hi,

Is there anyone from Google, apart from probing Warren, on this list available 
for some inquiries in private?
There are some strange patterns we’re seeing past few days towards.

Br,

Thomas

--
Thomas Dupas
www.dnsbelgium.be<http://www.dnsbelgium.be>

[DNS_PUNT_Belgium_RGB]


--- End Message ---
___
dns-operations mailing list
dns-operations@lists.dns-oarc.net
https://lists.dns-oarc.net/mailman/listinfo/dns-operations

Integrated: 8322811: jcmd System.dump_map help info has conflicting statements

[Thomas Stuefe]

On Fri, 7 Jun 2024 10:40:07 GMT, Thomas Stuefe  wrote:

> @dholmes-ora this is one of yours.
> 
> This was a tad annoying to fix (fix is simple though), since the jcmd 
> framework has no good way to allow for default parameters that are not used 
> literally. E.g. in this case, the real value for the file name will contain 
> the process pid, which of course cannot be hard-coded.
> 
> New output:
> 
> 
> Syntax : System.dump_map [options]
> 
> Options: (options must be specified using the  or = syntax)
> -H : [optional] Human readable format (BOOLEAN, false)
> -F : [optional] file path (STRING, vm_memory_map_.txt)

This pull request has now been integrated.

Changeset: 83b34410
Author:Thomas Stuefe 
URL:   
https://git.openjdk.org/jdk/commit/83b34410e326c47f357a37c3a337b7dedb8cbbda
Stats: 11 lines in 1 file changed: 7 ins; 0 del; 4 mod

8322811: jcmd System.dump_map help info has conflicting statements

Reviewed-by: dholmes, kevinw

-

PR: https://git.openjdk.org/jdk/pull/19596

Re: RFR: 8322811: jcmd System.dump_map help info has conflicting statements

[Thomas Stuefe]

On Mon, 10 Jun 2024 08:35:06 GMT, Kevin Walls  wrote:

>> @dholmes-ora this is one of yours.
>> 
>> This was a tad annoying to fix (fix is simple though), since the jcmd 
>> framework has no good way to allow for default parameters that are not used 
>> literally. E.g. in this case, the real value for the file name will contain 
>> the process pid, which of course cannot be hard-coded.
>> 
>> New output:
>> 
>> 
>> Syntax : System.dump_map [options]
>> 
>> Options: (options must be specified using the  or = syntax)
>> -H : [optional] Human readable format (BOOLEAN, false)
>> -F : [optional] file path (STRING, vm_memory_map_.txt)
>
> Looks good to me, yes non-literal defaults are a bit awkward here.

Thanks @kevinjwalls, @dholmes-ora !

-

PR Comment: https://git.openjdk.org/jdk/pull/19596#issuecomment-2157761743

Re: [PATCH] drm/managed: Simplify if condition

[Thomas Zimmermann]

Am 05.06.24 um 13:50 schrieb Thorsten Blum:

The if condition !A || A && B can be simplified to !A || B.

Fixes the following Coccinelle/coccicheck warning reported by
excluded_middle.cocci:

WARNING !A || A && B is equivalent to !A || B

Compile-tested only.

Signed-off-by: Thorsten Blum 


Acked-by: Thomas Zimmermann 


---
  drivers/gpu/drm/drm_managed.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_managed.c b/drivers/gpu/drm/drm_managed.c
index 7646f67bda4e..79ce86a5bd67 100644
--- a/drivers/gpu/drm/drm_managed.c
+++ b/drivers/gpu/drm/drm_managed.c
@@ -197,7 +197,7 @@ void drmm_release_action(struct drm_device *dev,
spin_lock_irqsave(>managed.lock, flags);
list_for_each_entry_reverse(dr, >managed.resources, node.entry) {
if (dr->node.release == action) {
-   if (!data || (data && *(void **)dr->data == data)) {
+   if (!data || *(void **)dr->data == data) {
dr_match = dr;
del_dr(dev, dr_match);
    break;


--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)

Re: [PATCH] drm/fbdev-dma: fix getting smem_start

[Thomas Zimmermann]

Hi

Am 04.06.24 um 10:03 schrieb Peng Fan (OSS):

From: Peng Fan 

If 'info->screen_buffer' locates in vmalloc address space, virt_to_page
will not be able to get correct results. With CONFIG_DEBUG_VM and
CONFIG_DEBUG_VIRTUAL enabled on ARM64, there is dump below:


Which graphics driver triggers this bug?


[3.536043] [ cut here ]
[3.540716] virt_to_phys used for non-linear address: 7fc4f540 
(0x800086001000)
[3.552628] WARNING: CPU: 4 PID: 61 at arch/arm64/mm/physaddr.c:12 
__virt_to_phys+0x68/0x98
[3.565455] Modules linked in:
[3.568525] CPU: 4 PID: 61 Comm: kworker/u12:5 Not tainted 
6.6.23-06226-g4986cc3e1b75-dirty #250
[3.577310] Hardware name: NXP i.MX95 19X19 board (DT)
[3.582452] Workqueue: events_unbound deferred_probe_work_func
[3.588291] pstate: 6049 (nZCv daif +PAN -UAO -TCO -DIT -SSBS BTYPE=--)
[3.595233] pc : __virt_to_phys+0x68/0x98
[3.599246] lr : __virt_to_phys+0x68/0x98
[3.603276] sp : 800083603990
[3.677939] Call trace:
[3.680393]  __virt_to_phys+0x68/0x98
[3.684067]  drm_fbdev_dma_helper_fb_probe+0x138/0x238
[3.689214]  __drm_fb_helper_initial_config_and_unlock+0x2b0/0x4c0
[3.695385]  drm_fb_helper_initial_config+0x4c/0x68
[3.700264]  drm_fbdev_dma_client_hotplug+0x8c/0xe0
[3.705161]  drm_client_register+0x60/0xb0
[3.709269]  drm_fbdev_dma_setup+0x94/0x148

So add a check 'is_vmalloc_addr'.

Fixes: b79fe9abd58b ("drm/fbdev-dma: Implement fbdev emulation for GEM DMA 
helpers")
Signed-off-by: Peng Fan 


Reviewed-by: Thomas Zimmermann 

Best regards
Thomas


---
  drivers/gpu/drm/drm_fbdev_dma.c | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/gpu/drm/drm_fbdev_dma.c b/drivers/gpu/drm/drm_fbdev_dma.c
index 6c9427bb4053..9e2eddb6eb5c 100644
--- a/drivers/gpu/drm/drm_fbdev_dma.c
+++ b/drivers/gpu/drm/drm_fbdev_dma.c
@@ -130,7 +130,12 @@ static int drm_fbdev_dma_helper_fb_probe(struct 
drm_fb_helper *fb_helper,
info->flags |= FBINFO_READS_FAST; /* signal caching */
info->screen_size = sizes->surface_height * fb->pitches[0];
info->screen_buffer = map.vaddr;
-   info->fix.smem_start = page_to_phys(virt_to_page(info->screen_buffer));
+
+   if (is_vmalloc_addr(info->screen_buffer))
+   info->fix.smem_start = 
page_to_phys(vmalloc_to_page(info->screen_buffer));
+   else
+   info->fix.smem_start = 
page_to_phys(virt_to_page(info->screen_buffer));
+
info->fix.smem_len = info->screen_size;
  
  	return 0;


--
--
Thomas Zimmermann
Graphics Driver Developer
SUSE Software Solutions Germany GmbH
Frankenstrasse 146, 90461 Nuernberg, Germany
GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman
HRB 36809 (AG Nuernberg)

Re: RFR: 8332400: isspace argument should be a valid unsigned char

[Thomas Stuefe]

On Mon, 10 Jun 2024 08:20:38 GMT, David Holmes  wrote:

> > "To use these functions safely with plain chars (or signed chars), the 
> > argument should first be converted to unsigned char"
> 
> @tstuefe wow! Okay. That is a surprise to me. A cast to unsigned char doesn't 
> actually do anything. Every char is "representable" as an unsigned char 
> because it holds a bit pattern between 0x00 and 0xff i.e. the function is 
> well defined if the incoming int is either EOF (int -1) or else in the range 
> 0x00 to 0xff. But I did a bit of searching and it seems it comes down to 
> potential arithmetic operations on the "char" the might behave differently 
> depending on the signed-ness. :(

I was surprised as well. Turns out you can use something for 20+ years and not 
notice :)

-

PR Comment: https://git.openjdk.org/jdk/pull/19567#issuecomment-2157711653

Re: RFR: 8332400: isspace argument should be a valid unsigned char

[Thomas Stuefe]

On Mon, 10 Jun 2024 08:20:38 GMT, David Holmes  wrote:

> > "To use these functions safely with plain chars (or signed chars), the 
> > argument should first be converted to unsigned char"
> 
> @tstuefe wow! Okay. That is a surprise to me. A cast to unsigned char doesn't 
> actually do anything. Every char is "representable" as an unsigned char 
> because it holds a bit pattern between 0x00 and 0xff i.e. the function is 
> well defined if the incoming int is either EOF (int -1) or else in the range 
> 0x00 to 0xff. But I did a bit of searching and it seems it comes down to 
> potential arithmetic operations on the "char" the might behave differently 
> depending on the signed-ness. :(

I was surprised as well. Turns out you can use something for 20+ years and not 
notice :)

-

PR Comment: https://git.openjdk.org/jdk/pull/19567#issuecomment-2157711653

Tagging June releases

[Mark Thomas]

Hi all,

A bunch of minor issues built up in my TODO list while I was at 
Community over Code and the Tomcat security day. I'd like to clear these 
before I tag the June releases.


In related news, the release ballots for Servlet and Pages have 
completed successfully. There is some admin that needs to be completed 
there as well but the key impact for us is that the next Tomcat 11 vote 
will be for a BETA release rather than an ALPHA release.


My current guess is that I'll be in a position to tag 11.0.x towards the 
end of the week. I'll provide an update if that changes after I have 
triaged my inbox.


Mark


-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [Patch, fortran] PR59104

[Paul Richard Thomas]

Hi Harald,

Thanks for the loophole detection! It is obvious now I see it, as is the
fix. I'll get on to it as soon as I find some time.

Cheers

Paul


On Sun, 9 Jun 2024 at 21:35, Harald Anlauf  wrote:

> Hi Paul,
>
> your approach sounds entirely reasonable.
>
> But as the following addition to the testcase shows, there seem to
> be loopholes left.
>
> When I add the following to function f:
>
>   integer :: l1(size(y))
>   integer :: l2(size(z))
>   print *, size (l1), size (l2), size (z)
>
> I get:
>
> 0   0   3
>
> Expected:
>
> 2   3   3
>
> Can you please check?
>
> Thanks,
> Harald
>
>
> Am 09.06.24 um 17:57 schrieb Paul Richard Thomas:
> > Hi All,
> >
> > I have extended the testcase - see below and have
> > s/dependent_decls_2/dependent_decls_2.f90/ in the ChnageLog.
> >
> > Cheers
> >
> > Paul
> >
> > ! { dg-do run }
> > !
> > ! Fix for PR59104 in which the dependence on the old style function
> result
> > ! was not taken into account in the ordering of auto array allocation and
> > ! characters with dependent lengths.
> > !
> > ! Contributed by Tobias Burnus  
> > !
> > module m
> > implicit none
> > integer, parameter :: dp = kind([double precision::])
> > contains
> >function f(x)
> >   integer, intent(in) :: x
> >   real(dp) f(x/2)
> >   real(dp) g(x/2)
> >   integer y(size (f)+1) ! This was the original problem
> >   integer z(size (f) + size (y)) ! Found in development of the
> fix
> >   integer w(size (f) + size (y) + x) ! Check dummy is OK
> >   f = 10.0
> >   y = 1! Stop -Wall from complaining
> >   z = 1
> >   g = 1
> >   w = 1
> >   if (size (f) .ne. 1) stop 1
> >   if (size (g) .ne. 1) stop 2
> >   if (size (y) .ne. 2) stop 3
> >   if (size (z) .ne. 3) stop 4
> >   if (size (w) .ne. 5) stop 5
> >end function f
> >function e(x) result(f)
> >   integer, intent(in) :: x
> >   real(dp) f(x/2)
> >   real(dp) g(x/2)
> >   integer y(size (f)+1)
> >   integer z(size (f) + size (y)) ! As was this.
> >   integer w(size (f) + size (y) + x)
> >   f = 10.0
> >   y = 1
> >   z = 1
> >   g = 1
> >   w = 1
> >   if (size (f) .ne. 2) stop 6
> >   if (size (g) .ne. 2) stop 7
> >   if (size (y) .ne. 3) stop 8
> >   if (size (z) .ne. 5) stop 9
> >   if (size (w) .ne. 9) stop 10
> >end function
> >function d(x)  ! After fixes to arrays, what was needed was known!
> >  integer, intent(in) :: x
> >  character(len = x/2) :: d
> >  character(len = len (d)) :: line
> >  character(len = len (d) + len (line)) :: line2
> >  character(len = len (d) + len (line) + x) :: line3
> >  line = repeat ("a", len (d))
> >  line2 = repeat ("b", x)
> >      line3 = repeat ("c", len (line3))
> >  if (len (line2) .ne. x) stop 11
> >  if (line3 .ne. "") stop 12
> >  d = line
> >end
> > end module m
> >
> > program p
> > use m
> > implicit none
> > real(dp) y
> >
> > y = sum (f (2))
> > if (int (y) .ne. 10) stop 13
> > y = sum (e (4))
> > if (int (y) .ne. 20) stop 14
> > if (d (4) .ne. "aa") stop 15
> > end program p
> >
> >
> >
> > On Sun, 9 Jun 2024 at 07:14, Paul Richard Thomas <
> > paul.richard.tho...@gmail.com> wrote:
> >
> >> Hi All,
> >>
> >> The attached fixes a problem that, judging by the comments, has been
> >> looked at periodically over the last ten years but just looked to be too
> >> fiendishly complicated to fix. This is not in small part because of the
> >> confusing ordering of dummies in the tlink chain and the unintuitive
> >> placement of all deferred initializations to the front of the init
> chain in
> >> the wrapped block.
> >>
> >> The result of the existing ordering is that the initialization code for
> >> non-dummy variables that depends on the function result occurs before
> any
> >> initialization code for the function result itself. The fix ensures
> that:
> >> (i) These variables are placed correctly in the tlink chain, respecting
> >> inter-dependencies; and (ii) The dependent initializations are placed at
> >> the end of the wrapped block init chain.  The details appear in the
> >> comments in the patch. It is entirely possible that a less clunky fix
> >> exists but I failed to find it.
> >>
> >> OK for mainline?
> >>
> >> Regards
> >>
> >> Paul
> >>
> >>
> >>
> >>
> >
>
>

Re: [Patch, fortran] PR59104

[Paul Richard Thomas]

Hi Harald,

Thanks for the loophole detection! It is obvious now I see it, as is the
fix. I'll get on to it as soon as I find some time.

Cheers

Paul


On Sun, 9 Jun 2024 at 21:35, Harald Anlauf  wrote:

> Hi Paul,
>
> your approach sounds entirely reasonable.
>
> But as the following addition to the testcase shows, there seem to
> be loopholes left.
>
> When I add the following to function f:
>
>   integer :: l1(size(y))
>   integer :: l2(size(z))
>   print *, size (l1), size (l2), size (z)
>
> I get:
>
> 0   0   3
>
> Expected:
>
> 2   3   3
>
> Can you please check?
>
> Thanks,
> Harald
>
>
> Am 09.06.24 um 17:57 schrieb Paul Richard Thomas:
> > Hi All,
> >
> > I have extended the testcase - see below and have
> > s/dependent_decls_2/dependent_decls_2.f90/ in the ChnageLog.
> >
> > Cheers
> >
> > Paul
> >
> > ! { dg-do run }
> > !
> > ! Fix for PR59104 in which the dependence on the old style function
> result
> > ! was not taken into account in the ordering of auto array allocation and
> > ! characters with dependent lengths.
> > !
> > ! Contributed by Tobias Burnus  
> > !
> > module m
> > implicit none
> > integer, parameter :: dp = kind([double precision::])
> > contains
> >function f(x)
> >   integer, intent(in) :: x
> >   real(dp) f(x/2)
> >   real(dp) g(x/2)
> >   integer y(size (f)+1) ! This was the original problem
> >   integer z(size (f) + size (y)) ! Found in development of the
> fix
> >   integer w(size (f) + size (y) + x) ! Check dummy is OK
> >   f = 10.0
> >   y = 1! Stop -Wall from complaining
> >   z = 1
> >   g = 1
> >   w = 1
> >   if (size (f) .ne. 1) stop 1
> >   if (size (g) .ne. 1) stop 2
> >   if (size (y) .ne. 2) stop 3
> >   if (size (z) .ne. 3) stop 4
> >   if (size (w) .ne. 5) stop 5
> >end function f
> >function e(x) result(f)
> >   integer, intent(in) :: x
> >   real(dp) f(x/2)
> >   real(dp) g(x/2)
> >   integer y(size (f)+1)
> >   integer z(size (f) + size (y)) ! As was this.
> >   integer w(size (f) + size (y) + x)
> >   f = 10.0
> >   y = 1
> >   z = 1
> >   g = 1
> >   w = 1
> >   if (size (f) .ne. 2) stop 6
> >   if (size (g) .ne. 2) stop 7
> >   if (size (y) .ne. 3) stop 8
> >   if (size (z) .ne. 5) stop 9
> >   if (size (w) .ne. 9) stop 10
> >end function
> >function d(x)  ! After fixes to arrays, what was needed was known!
> >  integer, intent(in) :: x
> >  character(len = x/2) :: d
> >  character(len = len (d)) :: line
> >  character(len = len (d) + len (line)) :: line2
> >  character(len = len (d) + len (line) + x) :: line3
> >  line = repeat ("a", len (d))
> >  line2 = repeat ("b", x)
> >      line3 = repeat ("c", len (line3))
> >  if (len (line2) .ne. x) stop 11
> >  if (line3 .ne. "") stop 12
> >  d = line
> >end
> > end module m
> >
> > program p
> > use m
> > implicit none
> > real(dp) y
> >
> > y = sum (f (2))
> > if (int (y) .ne. 10) stop 13
> > y = sum (e (4))
> > if (int (y) .ne. 20) stop 14
> > if (d (4) .ne. "aa") stop 15
> > end program p
> >
> >
> >
> > On Sun, 9 Jun 2024 at 07:14, Paul Richard Thomas <
> > paul.richard.tho...@gmail.com> wrote:
> >
> >> Hi All,
> >>
> >> The attached fixes a problem that, judging by the comments, has been
> >> looked at periodically over the last ten years but just looked to be too
> >> fiendishly complicated to fix. This is not in small part because of the
> >> confusing ordering of dummies in the tlink chain and the unintuitive
> >> placement of all deferred initializations to the front of the init
> chain in
> >> the wrapped block.
> >>
> >> The result of the existing ordering is that the initialization code for
> >> non-dummy variables that depends on the function result occurs before
> any
> >> initialization code for the function result itself. The fix ensures
> that:
> >> (i) These variables are placed correctly in the tlink chain, respecting
> >> inter-dependencies; and (ii) The dependent initializations are placed at
> >> the end of the wrapped block init chain.  The details appear in the
> >> comments in the patch. It is entirely possible that a less clunky fix
> >> exists but I failed to find it.
> >>
> >> OK for mainline?
> >>
> >> Regards
> >>
> >> Paul
> >>
> >>
> >>
> >>
> >
>
>

RFR: 8322811: jcmd System.dump_map help info has conflicting statements

[Thomas Stuefe]

@dholmes-ora this is one of yours.

This was a tad annoying to fix (fix is simple though), since the jcmd framework 
has no good way to allow for default parameters that are not used literally. 
E.g. in this case, the real value for the file name will contain the process 
pid, which of course cannot be hard-coded.

New output:


Syntax : System.dump_map [options]

Options: (options must be specified using the  or = syntax)
-H : [optional] Human readable format (BOOLEAN, false)
-F : [optional] file path (STRING, vm_memory_map_.txt)

-

Commit messages:
 - JDK-8322811-jcmd-System-dump_map-help-info-has-conflicting-statements

Changes: https://git.openjdk.org/jdk/pull/19596/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk=19596=00
  Issue: https://bugs.openjdk.org/browse/JDK-8322811
  Stats: 11 lines in 1 file changed: 7 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/19596.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19596/head:pull/19596

PR: https://git.openjdk.org/jdk/pull/19596

Re: execute-external-file & execute-general-script

[Thomas Passin]

Good to know, Felix.  Please see if you can test it on one or another Linux 
distros - I had a hard time getting the script to work with some of them.

I think getting the script to work is an important milestone.  It means 
that we can develop code with LeoJs in many other languages than 
javascript/txx

On Sunday, June 9, 2024 at 10:22:40 PM UTC-4 Félix wrote:

> I got it working with the julia setup you provided! thanks a lot for your 
> example. 
>
> I also tried it with a simple shell script like this and it also worked 
> [image: example.png]
>
> and I also got the 'execute-general-script' command working so I'll 
> release a new LeoJS beta version with all the new stuff and recent fixes in 
> a day or two! 
>
> :)
>
> Thanks again! 
>
> On Sunday, June 9, 2024 at 5:48:42 PM UTC-4 tbp1...@gmail.com wrote:
>
>> Go, Félix!
>>
>> On Sunday, June 9, 2024 at 5:39:48 PM UTC-4 Félix wrote:
>>
>>> Merci Thomas! :)
>>>
>>> On Sunday, June 9, 2024 at 4:26:16 PM UTC-4 tbp1...@gmail.com wrote:
>>>
>>>> For the *execute-external-file* script*, *here is one of my test 
>>>> files,  a tiny Julia file (of course, install Julia first):
>>>>
>>>> headline: @file julia-1.jl
>>>> # function to calculate the volume of a sphere
>>>> function sphere_vol(r)
>>>> # julia allows Unicode names (in UTF-8 encoding)
>>>> # so either "pi" or the symbol π can be used
>>>> # return (4/3)*pi*r^3
>>>> return (4/3)*π*r^3
>>>> end
>>>>
>>>> vol = sphere_vol(3)
>>>>
>>>> # @printf allows number formatting but does not automatically append 
>>>> the \n to statements
>>>> using Printf
>>>> @printf "volume = %0.3f\n" vol
>>>>
>>>> For the command to find the Julia processor, you have to create an 
>>>> @data settings node named *@data run-external-processor-map, *like 
>>>> this one (.py scripts are hardcoded in, of course, and don't need to be 
>>>> included here):
>>>>
>>>> EXTENSIONS
>>>> .jl: julia  # Trailing comments are allowed
>>>> .lua: lua
>>>> .rb: ruby
>>>> .nim: nim
>>>>
>>>> PROCESSORS
>>>> julia: julia
>>>> lua: lua
>>>> nim: nim
>>>> # Originally, ruby was not on the PATH, so we needed its full path:
>>>> # ruby: C:\Ruby27-x64\bin\ruby.exe
>>>>
>>>> # After ruby was added to the PATH, we could use its bare name:
>>>> ruby: ruby
>>>>
>>>> This command is supposed to open a new terminal window and run the 
>>>> command in it.  The terminal *must* stay open after the external program 
>>>> ends so that the user can read any output (especially error messages!).  
>>>> The trickiest part of the command is figuring out the terminal launch 
>>>> command for Linux that will launch and stay open at the end, since there 
>>>> is 
>>>> no one standard method good on all Linux distros.  My script uses some 
>>>> heuristics to try to get it right.  These can include scanning the 
>>>> --help output of the candidate terminal, IIRC.
>>>> On Sunday, June 9, 2024 at 3:56:45 PM UTC-4 Félix wrote:
>>>>
>>>>> Hello Leonistas! :)
>>>>>
>>>>> I'm currently implementing and testing the *execute-external-file *& 
>>>>> *execute-general-script 
>>>>> *commands in LeoJS.
>>>>>
>>>>> *execute-external-file was made by Thomas around February 2023 while 
>>>>> execute-general-script was made by Edward around june 2021.*
>>>>>
>>>>> I was just wondering if anyone could send me 
>>>>> 'minimal/proof-of-concept' stripped down leo file(s) to test any of those 
>>>>> two commands. (with simple 'toy'/'hello-world' scripts to run with them) 
>>>>> If 
>>>>> you have a few minutes to spare to prepare such a thing... :)
>>>>>
>>>>> Thanks! 
>>>>>
>>>>> Félix
>>>>>
>>>>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/9b11dcc5-9baf-443c-97bc-f4e4ca73272bn%40googlegroups.com.

Re: Assert in heapgettup_pagemode() fails due to underlying buffer change

[Thomas Munro]

I adjusted the code a bit more to look like the 16 coding including
restoring some very useful comments that had been lost, and pushed.

Thanks very much to Alexander and Noah for (independently) chasing
this down and reporting, testing etc, and Alvaro and Robert for review
comments.

(Passing thought: it's a bit weird that we need to zero pages at all
before restoring FPIs or initialising them.  Perhaps there is some way
to defer marking the buffer valid until after the caller gets a chance
to initialise?  Or something like that...)

pgsql: Fix RBM_ZERO_AND_LOCK.

[Thomas Munro]

Fix RBM_ZERO_AND_LOCK.

Commit 210622c6 accidentally zeroed out pages even if they were found in
the buffer pool.  It should always lock the page, but it should only
zero pages that were not already valid.  Otherwise, concurrent readers
that hold only a pin could see corrupted page contents changing under
their feet.

While here, rename ZeroAndLockBuffer() to match the RBM_ flag name.
Also restore a some useful comments lost by 210622c6's refactoring, and
add some new ones to clarify why we need to use the BM_IO_IN_PROGRESS
infrastructure despite not doing I/O.

Reported-by: Noah Misch 
Reported-by: Alexander Lakhin 
Reviewed-by: Alvaro Herrera  (earlier version)
Reviewed-by: Robert Haas  (earlier version)
Discussion: https://postgr.es/m/20240512171658.7e.nmi...@google.com
Discussion: https://postgr.es/m/7ed10231-ce47-03d5-d3f9-4aea0dc7d5a4%40gmail.com

Branch
--
master

Details
---
https://git.postgresql.org/pg/commitdiff/e656657f2b93a96b83fd4038ec5120c5ec9845e5

Modified Files
--
src/backend/storage/buffer/bufmgr.c | 88 -
1 file changed, 67 insertions(+), 21 deletions(-)

Re: execute-external-file & execute-general-script

[Thomas Passin]

Go, Félix!

On Sunday, June 9, 2024 at 5:39:48 PM UTC-4 Félix wrote:

> Merci Thomas! :)
>
> On Sunday, June 9, 2024 at 4:26:16 PM UTC-4 tbp1...@gmail.com wrote:
>
>> For the *execute-external-file* script*, *here is one of my test files,  
>> a tiny Julia file (of course, install Julia first):
>>
>> headline: @file julia-1.jl
>> # function to calculate the volume of a sphere
>> function sphere_vol(r)
>> # julia allows Unicode names (in UTF-8 encoding)
>> # so either "pi" or the symbol π can be used
>> # return (4/3)*pi*r^3
>> return (4/3)*π*r^3
>> end
>>
>> vol = sphere_vol(3)
>>
>> # @printf allows number formatting but does not automatically append the 
>> \n to statements
>> using Printf
>> @printf "volume = %0.3f\n" vol
>>
>> For the command to find the Julia processor, you have to create an @data 
>> settings node named *@data run-external-processor-map, *like this one 
>> (.py scripts are hardcoded in, of course, and don't need to be included 
>> here):
>>
>> EXTENSIONS
>> .jl: julia  # Trailing comments are allowed
>> .lua: lua
>> .rb: ruby
>> .nim: nim
>>
>> PROCESSORS
>> julia: julia
>> lua: lua
>> nim: nim
>> # Originally, ruby was not on the PATH, so we needed its full path:
>> # ruby: C:\Ruby27-x64\bin\ruby.exe
>>
>> # After ruby was added to the PATH, we could use its bare name:
>> ruby: ruby
>>
>> This command is supposed to open a new terminal window and run the 
>> command in it.  The terminal *must* stay open after the external program 
>> ends so that the user can read any output (especially error messages!).  
>> The trickiest part of the command is figuring out the terminal launch 
>> command for Linux that will launch and stay open at the end, since there is 
>> no one standard method good on all Linux distros.  My script uses some 
>> heuristics to try to get it right.  These can include scanning the --help 
>> output of the candidate terminal, IIRC.
>> On Sunday, June 9, 2024 at 3:56:45 PM UTC-4 Félix wrote:
>>
>>> Hello Leonistas! :)
>>>
>>> I'm currently implementing and testing the *execute-external-file *& 
>>> *execute-general-script 
>>> *commands in LeoJS.
>>>
>>> *execute-external-file was made by Thomas around February 2023 while 
>>> execute-general-script was made by Edward around june 2021.*
>>>
>>> I was just wondering if anyone could send me 'minimal/proof-of-concept' 
>>> stripped down leo file(s) to test any of those two commands. (with simple 
>>> 'toy'/'hello-world' scripts to run with them) If you have a few minutes to 
>>> spare to prepare such a thing... :)
>>>
>>> Thanks! 
>>>
>>> Félix
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/e17815e8-a667-4706-ab2f-35b0cce96d7en%40googlegroups.com.

CVS commit: src/doc

[Thomas Klausner]

Module Name:src
Committed By:   wiz
Date:   Sun Jun  9 20:47:55 UTC 2024

Modified Files:
src/doc: 3RDPARTY

Log Message:
doc: update 3RDPARTY entry for libarchive update


To generate a diff of this commit:
cvs rdiff -u -r1.2007 -r1.2008 src/doc/3RDPARTY

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

Modified files:

Index: src/doc/3RDPARTY
diff -u src/doc/3RDPARTY:1.2007 src/doc/3RDPARTY:1.2008
--- src/doc/3RDPARTY:1.2007	Thu Jun  6 20:50:49 2024
+++ src/doc/3RDPARTY	Sun Jun  9 20:47:55 2024
@@ -1,4 +1,4 @@
-#	$NetBSD: 3RDPARTY,v 1.2007 2024/06/06 20:50:49 wiz Exp $
+#	$NetBSD: 3RDPARTY,v 1.2008 2024/06/09 20:47:55 wiz Exp $
 #
 # This file contains a list of the software that has been integrated into
 # NetBSD where we are not the primary maintainer.
@@ -717,12 +717,12 @@ for importation.  Run ./configure before
 Talk to mrg before importing any new version.
 
 Package:	libarchive
-Version:	3.4.0
-Current Vers:	3.7.2
+Version:	3.7.4
+Current Vers:	3.7.4
 Maintainer:	kient...@freebsd.org, jo...@netbsd.org
 Archive Site:	https://github.com/libarchive/libarchive/releases
 Home Page: 	http://www.libarchive.org
-Date:		2021-03-01
+Date:		2024-06-09
 Responsible:	joerg
 License:	BSD (2-clause)
 Location:	external/bsd/libarchive/dist

CVS commit: src/doc

[Thomas Klausner]

Module Name:src
Committed By:   wiz
Date:   Sun Jun  9 20:47:55 UTC 2024

Modified Files:
src/doc: 3RDPARTY

Log Message:
doc: update 3RDPARTY entry for libarchive update


To generate a diff of this commit:
cvs rdiff -u -r1.2007 -r1.2008 src/doc/3RDPARTY

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.

shutdown/reboot taking a long time

[Thomas Klausner]

Hi!

Recently I noticed that after a longer uptime, shutdown takes a while.

I think it's in the step where it tears down the swap.

The last time I rebooted, there was no memory pressure (no big
processes running), but the reboot took over 5 hours.

The swap setup is:

> swapctl -lh
Device  Size UsedAvail Capacity  Priority
/dev/dk2127G 269M 127G 0%0
/dev/dk7192G 271M 192G 0%0
/dev/dk4128G 270M 128G 0%0
Total   447G 810M 446G 0%

Has anyone else seen this?
 Thomas

Re: execute-external-file & execute-general-script

[Thomas Passin]

For the *execute-external-file* script*, *here is one of my test files,  a 
tiny Julia file (of course, install Julia first):

headline: @file julia-1.jl
# function to calculate the volume of a sphere
function sphere_vol(r)
# julia allows Unicode names (in UTF-8 encoding)
# so either "pi" or the symbol π can be used
# return (4/3)*pi*r^3
return (4/3)*π*r^3
end

vol = sphere_vol(3)

# @printf allows number formatting but does not automatically append the \n 
to statements
using Printf
@printf "volume = %0.3f\n" vol

For the command to find the Julia processor, you have to create an @data 
settings node named *@data run-external-processor-map, *like this one (.py 
scripts are hardcoded in, of course, and don't need to be included here):

EXTENSIONS
.jl: julia  # Trailing comments are allowed
.lua: lua
.rb: ruby
.nim: nim

PROCESSORS
julia: julia
lua: lua
nim: nim
# Originally, ruby was not on the PATH, so we needed its full path:
# ruby: C:\Ruby27-x64\bin\ruby.exe

# After ruby was added to the PATH, we could use its bare name:
ruby: ruby

This command is supposed to open a new terminal window and run the command 
in it.  The terminal *must* stay open after the external program ends so 
that the user can read any output (especially error messages!).  The 
trickiest part of the command is figuring out the terminal launch command 
for Linux that will launch and stay open at the end, since there is no one 
standard method good on all Linux distros.  My script uses some heuristics 
to try to get it right.  These can include scanning the --help output of 
the candidate terminal, IIRC.
On Sunday, June 9, 2024 at 3:56:45 PM UTC-4 Félix wrote:

> Hello Leonistas! :)
>
> I'm currently implementing and testing the *execute-external-file *& 
> *execute-general-script 
> *commands in LeoJS.
>
> *execute-external-file was made by Thomas around February 2023 while 
> execute-general-script was made by Edward around june 2021.*
>
> I was just wondering if anyone could send me 'minimal/proof-of-concept' 
> stripped down leo file(s) to test any of those two commands. (with simple 
> 'toy'/'hello-world' scripts to run with them) If you have a few minutes to 
> spare to prepare such a thing... :)
>
> Thanks! 
>
> Félix
>

-- 
You received this message because you are subscribed to the Google Groups 
"leo-editor" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to leo-editor+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/leo-editor/b9b0294e-eab1-467e-9827-d9049fc5141fn%40googlegroups.com.

Re: BXLE instruction

[Jim Thomas]

My Apologies  Clicked send before I was done ...

SELECT BRXH R15,R15,NZ
WHEN (16)
   something ..
 WHEN (8)
something ..
  ENDSEL ,

If so desired, you could have IF statements with your WHEN ... e.g. let's say 
you want to check for a reason code of 200 in R0 ..

   WHEN (4)
IF (CHI,R0,EQ,200)
 something
ENDIF , (or, ELSEIF for another IF)

From: IBM Mainframe Discussion List  on behalf of Jim 
Thomas 
Sent: Sunday, June 9, 2024 2:33 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Re: BXLE instruction

Seymour,

I'd use a SELECT rather than an IF (since you're looking for more than one 
possibility) but ... none the less (and using branch relative) ...

BRXH R15,R15,non_zero 
Continue for R15 = zero ..

Kind Regards
Jim Thomas

From: IBM Mainframe Discussion List  on behalf of 
Seymour J Metz 
Sent: Sunday, June 9, 2024 1:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Fw: BXLE instruction

I meant to repost this last year but it slipped through the cracks. If anyone 
can help Bill with his registration issue I'd appreciate it. Also, if anybody 
has a machine-readable copy of the TR I'd love to see it.

The trick in question relies on the use of the same odd register as the R1 and 
R3 in BXH,  BXHG, BXLE, BXLEG, JXH, JXHG, JXLE and JXLEG. You can only test 30 
consecutive bits with the 32-bit version and 62 with the 64-bit version; the 
high and low bits should be zero. The code, arbitrarily picking GR 1 as the odd 
register, looks something like:

 L R1,STATUS
 IF(BXH,R15,r15)
 action 1
 ENDIF
 ...
 IF(BXH,R15,r15)
 action 30
 ENDIF
...
STATUS   DCA.1(0,flag1,...,flag31,0)

Where the test is a BXH or BXLE depending on which way you want to test.

If you have to work it out with pencil and paper in order to understand what's 
going on, welcome to the club. I thought that it was slick the first time I saw 
it, and I still  think so. I think it would be a good example in PoOps.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר

From: William Collier 
Sent: Wednesday, November 2, 2022 11:27 AM
To: Seymour J Metz
Subject: BXLE instruction


To:  Seymour J Metz mailto:sme...@gmu.edu>>

Hi,

  Last night I enjoyed reading your comment on the IBM-MAIN
listserv:

The slickest thing that I saw in OS/360 was code testing
successive bits using BXH and BXLE.

  I would like to respond with the note below.  I have followed
(I believe) all the directions for creating a password in order
to be allowed to post a note responding to your note.  It hasn't
worked (yet).  Would you, in the interest of timeliness, be
willing to post the note below on my behalf?  If not, that's OK.
I will figure it out.

Bill Collier

==

Re: End of several eras

  Back in 1965 IBM Poughkeepsie our job was to write an operating
system for System/360 which would fit into 1K bytes (sic) of an
8k byte machine.  I figured out how to use a BXLE instruction to
both test and advance a bit string in a register.  It saved us
maybe 30-some bytes.  I described this in IBM TR 00.1412-1, June
22, 1966.  Thank you, Seymour Metz, for your note reminding us of
the fun we had in those days.

  Bill Collier
  coll...@acm.org<mailto:coll...@acm.org>


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: [drm:amdgpu_fill_buffer [amdgpu]] *ERROR* Trying to clear memory with ring turned off.

[Thomas Glanzmann]

Hello Alex,

> Should be fixed with this patch:
> https://patchwork.freedesktop.org/patch/597421/

works for me.

Tested-by: Thomas Glanzmann 

Thanks.

Cheers,
    Thomas

Re: BXLE instruction

[Jim Thomas]

Seymour,

I'd use a SELECT rather than an IF (since you're looking for more than one 
possibility) but ... none the less (and using branch relative) ...

BRXH R15,R15,non_zero 
Continue for R15 = zero ..

Kind Regards
Jim Thomas

From: IBM Mainframe Discussion List  on behalf of 
Seymour J Metz 
Sent: Sunday, June 9, 2024 1:25 PM
To: IBM-MAIN@LISTSERV.UA.EDU 
Subject: Fw: BXLE instruction

I meant to repost this last year but it slipped through the cracks. If anyone 
can help Bill with his registration issue I'd appreciate it. Also, if anybody 
has a machine-readable copy of the TR I'd love to see it.

The trick in question relies on the use of the same odd register as the R1 and 
R3 in BXH,  BXHG, BXLE, BXLEG, JXH, JXHG, JXLE and JXLEG. You can only test 30 
consecutive bits with the 32-bit version and 62 with the 64-bit version; the 
high and low bits should be zero. The code, arbitrarily picking GR 1 as the odd 
register, looks something like:

 L R1,STATUS
 IF(BXH,R15,r15)
 action 1
 ENDIF
 ...
 IF(BXH,R15,r15)
 action 30
 ENDIF
...
STATUS   DCA.1(0,flag1,...,flag31,0)

Where the test is a BXH or BXLE depending on which way you want to test.

If you have to work it out with pencil and paper in order to understand what's 
going on, welcome to the club. I thought that it was slick the first time I saw 
it, and I still  think so. I think it would be a good example in PoOps.

--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
עַם יִשְׂרָאֵל חַי
נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר

From: William Collier 
Sent: Wednesday, November 2, 2022 11:27 AM
To: Seymour J Metz
Subject: BXLE instruction


To:  Seymour J Metz mailto:sme...@gmu.edu>>

Hi,

  Last night I enjoyed reading your comment on the IBM-MAIN
listserv:

The slickest thing that I saw in OS/360 was code testing
successive bits using BXH and BXLE.

  I would like to respond with the note below.  I have followed
(I believe) all the directions for creating a password in order
to be allowed to post a note responding to your note.  It hasn't
worked (yet).  Would you, in the interest of timeliness, be
willing to post the note below on my behalf?  If not, that's OK.
I will figure it out.

Bill Collier

==

Re: End of several eras

  Back in 1965 IBM Poughkeepsie our job was to write an operating
system for System/360 which would fit into 1K bytes (sic) of an
8k byte machine.  I figured out how to use a BXLE instruction to
both test and advance a bit string in a register.  It saved us
maybe 30-some bytes.  I described this in IBM TR 00.1412-1, June
22, 1966.  Thank you, Seymour Metz, for your note reminding us of
the fun we had in those days.

  Bill Collier
  coll...@acm.org<mailto:coll...@acm.org>


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN

Re: Mailgun SSL_accept error

[Thomas Barth via postfix-users]

Hallo

Am 2024-06-09 14:59, schrieb Stefan Fuhrmann:

Hallo Thomas,

wie sieht es bei dir mit dem DNS aus?

zB https://talk.plesk.com/threads/tls-library-problem-error-42.358436/


deine certis sind von letsencrypt?

deine main.cf hat solche Einträge:

smtpd_tls_mandatory_protocols = !SSLv2, !SSLv3
smtpd_tls_protocols = !SSLv2,!SSLv3
smtp_tls_protocols = !SSLv2,!SSLv3



Ja, Zertifikate sind von letsencrypt. Ich weiß nicht, wie du an die 
Einstellungen gekommen bist. Aber meine Einträge dazu sind:


# Disable TLSv1 TLSv1.1
smtpd_tls_protocols = !TLSv1 !TLSv1.1
smtpd_tls_mandatory_protocols = !TLSv1 !TLSv1.1

smtp_tls_protocols = !TLSv1 !TLSv1.1
smtp_tls_mandatory_protocols = !TLSv1 !TLSv1.1

und erhalte dazu bei testssl die Ausgabe:

 Testing protocols via sockets

 SSLv2  not offered (OK)
 SSLv3  not offered (OK)
 TLS 1  not offered
 TLS 1.1not offered
 TLS 1.2offered (OK)
 TLS 1.3offered (OK): final

Ich musste dann noch rDNS auf die Domain umstellen, die auch im 
Zertifikat aufgelistet ist. rDNS verwies noch auf eine Domain vom 
Hoster. Mit diesen Änderungen bin ich die Rot markierten Testergebnisse 
losgeworden.

Re: Wrong component for firmware-nvidia-gsp/525.147.05-7~deb12u1~bpo11+1 in bullseye-backports/non-free-firmware

[Brent Thomas]

debian-backports@lists.debian.org
sudo apt install flatpak

Re: [Patch, fortran] PR59104

[Paul Richard Thomas]

Hi All,

I have extended the testcase - see below and have
s/dependent_decls_2/dependent_decls_2.f90/ in the ChnageLog.

Cheers

Paul

! { dg-do run }
!
! Fix for PR59104 in which the dependence on the old style function result
! was not taken into account in the ordering of auto array allocation and
! characters with dependent lengths.
!
! Contributed by Tobias Burnus  
!
module m
   implicit none
   integer, parameter :: dp = kind([double precision::])
   contains
  function f(x)
 integer, intent(in) :: x
 real(dp) f(x/2)
 real(dp) g(x/2)
 integer y(size (f)+1) ! This was the original problem
 integer z(size (f) + size (y)) ! Found in development of the fix
 integer w(size (f) + size (y) + x) ! Check dummy is OK
 f = 10.0
 y = 1! Stop -Wall from complaining
 z = 1
 g = 1
 w = 1
 if (size (f) .ne. 1) stop 1
 if (size (g) .ne. 1) stop 2
 if (size (y) .ne. 2) stop 3
 if (size (z) .ne. 3) stop 4
 if (size (w) .ne. 5) stop 5
  end function f
  function e(x) result(f)
 integer, intent(in) :: x
 real(dp) f(x/2)
 real(dp) g(x/2)
 integer y(size (f)+1)
 integer z(size (f) + size (y)) ! As was this.
 integer w(size (f) + size (y) + x)
 f = 10.0
 y = 1
 z = 1
 g = 1
 w = 1
 if (size (f) .ne. 2) stop 6
 if (size (g) .ne. 2) stop 7
 if (size (y) .ne. 3) stop 8
 if (size (z) .ne. 5) stop 9
 if (size (w) .ne. 9) stop 10
  end function
  function d(x)  ! After fixes to arrays, what was needed was known!
integer, intent(in) :: x
character(len = x/2) :: d
character(len = len (d)) :: line
character(len = len (d) + len (line)) :: line2
character(len = len (d) + len (line) + x) :: line3
line = repeat ("a", len (d))
line2 = repeat ("b", x)
line3 = repeat ("c", len (line3))
if (len (line2) .ne. x) stop 11
if (line3 .ne. "") stop 12
d = line
  end
end module m

program p
   use m
   implicit none
   real(dp) y

   y = sum (f (2))
   if (int (y) .ne. 10) stop 13
   y = sum (e (4))
   if (int (y) .ne. 20) stop 14
   if (d (4) .ne. "aa") stop 15
end program p



On Sun, 9 Jun 2024 at 07:14, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:

> Hi All,
>
> The attached fixes a problem that, judging by the comments, has been
> looked at periodically over the last ten years but just looked to be too
> fiendishly complicated to fix. This is not in small part because of the
> confusing ordering of dummies in the tlink chain and the unintuitive
> placement of all deferred initializations to the front of the init chain in
> the wrapped block.
>
> The result of the existing ordering is that the initialization code for
> non-dummy variables that depends on the function result occurs before any
> initialization code for the function result itself. The fix ensures that:
> (i) These variables are placed correctly in the tlink chain, respecting
> inter-dependencies; and (ii) The dependent initializations are placed at
> the end of the wrapped block init chain.  The details appear in the
> comments in the patch. It is entirely possible that a less clunky fix
> exists but I failed to find it.
>
> OK for mainline?
>
> Regards
>
> Paul
>
>
>
>

Re: [Patch, fortran] PR59104

[Paul Richard Thomas]

Hi All,

I have extended the testcase - see below and have
s/dependent_decls_2/dependent_decls_2.f90/ in the ChnageLog.

Cheers

Paul

! { dg-do run }
!
! Fix for PR59104 in which the dependence on the old style function result
! was not taken into account in the ordering of auto array allocation and
! characters with dependent lengths.
!
! Contributed by Tobias Burnus  
!
module m
   implicit none
   integer, parameter :: dp = kind([double precision::])
   contains
  function f(x)
 integer, intent(in) :: x
 real(dp) f(x/2)
 real(dp) g(x/2)
 integer y(size (f)+1) ! This was the original problem
 integer z(size (f) + size (y)) ! Found in development of the fix
 integer w(size (f) + size (y) + x) ! Check dummy is OK
 f = 10.0
 y = 1! Stop -Wall from complaining
 z = 1
 g = 1
 w = 1
 if (size (f) .ne. 1) stop 1
 if (size (g) .ne. 1) stop 2
 if (size (y) .ne. 2) stop 3
 if (size (z) .ne. 3) stop 4
 if (size (w) .ne. 5) stop 5
  end function f
  function e(x) result(f)
 integer, intent(in) :: x
 real(dp) f(x/2)
 real(dp) g(x/2)
 integer y(size (f)+1)
 integer z(size (f) + size (y)) ! As was this.
 integer w(size (f) + size (y) + x)
 f = 10.0
 y = 1
 z = 1
 g = 1
 w = 1
 if (size (f) .ne. 2) stop 6
 if (size (g) .ne. 2) stop 7
 if (size (y) .ne. 3) stop 8
 if (size (z) .ne. 5) stop 9
 if (size (w) .ne. 9) stop 10
  end function
  function d(x)  ! After fixes to arrays, what was needed was known!
integer, intent(in) :: x
character(len = x/2) :: d
character(len = len (d)) :: line
character(len = len (d) + len (line)) :: line2
character(len = len (d) + len (line) + x) :: line3
line = repeat ("a", len (d))
line2 = repeat ("b", x)
line3 = repeat ("c", len (line3))
if (len (line2) .ne. x) stop 11
if (line3 .ne. "") stop 12
d = line
  end
end module m

program p
   use m
   implicit none
   real(dp) y

   y = sum (f (2))
   if (int (y) .ne. 10) stop 13
   y = sum (e (4))
   if (int (y) .ne. 20) stop 14
   if (d (4) .ne. "aa") stop 15
end program p



On Sun, 9 Jun 2024 at 07:14, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:

> Hi All,
>
> The attached fixes a problem that, judging by the comments, has been
> looked at periodically over the last ten years but just looked to be too
> fiendishly complicated to fix. This is not in small part because of the
> confusing ordering of dummies in the tlink chain and the unintuitive
> placement of all deferred initializations to the front of the init chain in
> the wrapped block.
>
> The result of the existing ordering is that the initialization code for
> non-dummy variables that depends on the function result occurs before any
> initialization code for the function result itself. The fix ensures that:
> (i) These variables are placed correctly in the tlink chain, respecting
> inter-dependencies; and (ii) The dependent initializations are placed at
> the end of the wrapped block init chain.  The details appear in the
> comments in the patch. It is entirely possible that a less clunky fix
> exists but I failed to find it.
>
> OK for mainline?
>
> Regards
>
> Paul
>
>
>
>

Re: [VOTE] Release Apache Commons Configuration 2.11.0 based on RC1

[Thomas Vandahl]

Hi Gary,

> Am 07.06.2024 um 15:53 schrieb Gary Gregory :
> 
> We have fixed a few bugs and added enhancements since Apache Commons
> Configuration 2.10.1 was released, so I would like to release Apache
> Commons Configuration 2.11.0.
> 
> Apache Commons Configuration 2.11.0 RC1 is available for review here:
>https://dist.apache.org/repos/dist/dev/commons/configuration/2.11.0-RC1
> (svn revision 69603)
...
>  [X] +1 Release these artifacts
>  [ ] +0 OK, but...
>  [ ] -0 OK, but really should fix...
>  [ ] -1 I oppose this release because...
> 

Checksums and signatures are ok. Build, tests and site generation run fine with
   mvn clean verify site
using
--8<--
Apache Maven 3.9.6 (bc0240f3c744dd6b6ec2920b3cd08dcc295161ae)
Java version: 17.0.8, vendor: Oracle Corporation, runtime: 
/Library/Java/JavaVirtualMachines/jdk-17.jdk/Contents/Home
Default locale: de_DE, platform encoding: UTF-8
OS name: "mac os x", version: "11.7.10", arch: "x86_64", family: "mac"
--8<--

Bye, Thomas 


-
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Re: Mailgun SSL_accept error

[Thomas Barth via postfix-users]

Super, dank dir. Solche Tools, die anzeigen, was noch optimiert werden 
kann, liebe ich ja.


Ich habe kleine Änderungen vornehmen können, die in der Ausgabe als rot 
oder gelb markiert waren. Mal sehen, wie es sich verhält, wenn wieder 
eine Mail (Newsletter) über Mailgun geliefert wird.


Gruß
Thomas

Am 2024-06-08 21:26, schrieb Stefan Fuhrmann via postfix-users:

Hallo Thomas,


ich würde erstmal schaun, was denn für certis ausgeliefert 
werden...local wie remote schaust du testssl.sh


https://testssl.sh/


Gruß

Stefan

Am 08.06.24 um 09:04 schrieb Thomas Barth via postfix-users:

Hallo,
immer wenn eine Mail über Mailgun eingeliefert wird, kommt es zunächst 
zu einer Fehlermeldung.


Jun 07 16:55:04 mx1 postfix/smtpd[196980]: connect from 
m204-56.eu.mailgun.net[161.38.204.56]
Jun 07 16:55:04 mx1 postfix/smtpd[196983]: SSL_accept error from 
m204-56.eu.mailgun.net[161.38.204.56]: -1
Jun 07 16:55:04 mx1 postfix/smtpd[196983]: warning: TLS library 
problem: error:0A000412:SSL routines::sslv3 alert bad 
certificate:../ssl/record/rec_layer_s3.c:1586:SSL alert number 42:
Jun 07 16:55:04 mx1 postfix/smtpd[196983]: lost connection after 
STARTTLS from m204-56.eu.mailgun.net[161.38.204.56]


Dann funktioniert es aber doch

Jun 07 16:55:04 mx1 postfix/smtpd[196980]: Anonymous TLS connection 
established from m204-56.eu.mailgun.net[161.38.204.56]: TLSv1.3 with 
cipher TLS_AES_128_GCM_SHA256 ...


Verstehe es richtig, dass Mailgun bei der Einlieferung ein Zertifikat 
präsentiert, welches nicht akzeptiert werden kann, weil es einfach nur 
"schlecht" ist oder weil auf dem Server noch eine 
Konfigurationseinstellung fehlt?

Bug#1072861: RM: python-rednose -- ROM; no reverse depends, nose removal

[Thomas Goirand]

Package: ftp.debian.org
Severity: normal
User: ftp.debian@packages.debian.org
Usertags: remove
X-Debbugs-Cc: python-redn...@packages.debian.org
Control: affects -1 + src:python-rednose

Hi,

Rednose was a plugin for nose, and I just removed its last
reverse depends (in python3-sure), so it can be safely
removed from Debian.

Cheers,

Thomas Goirand (zigo)

Bug#1020217: snapshot.debian.org: write a generic file driver supporting multiple backend (such as object-storage)

[Thomas Goirand]

Hi there!

I'm hereby cc-ing our DPL, to get him involved an eventual storage 
cluster purchase for the project.


I have been mentioning such an object storage driver, so we could use 
OpenStack swift for snapshot.d.o for years. I am happy that it finally 
brings traction, and that Lucas is implementing this. Thanks Lucas.


However, it is disappointing to see it moving toward an s3 
implementation, which is a protocol from a closed-source service. I 
already wrote multiple times that my company (Infomaniak) was willing to 
sponsor storage space on Swift for it.


FYI, we currently manage more than 110 PB of storage over 7500+ HDD and 
growing, so I am not scared at all about storage space. Some clusters we 
manage are around 40PB, with billions of files.


Though I do not envision *any* sponsor to provide the storage space, but 
rather, Debian maintaining its own storage cluster. To give you a rough 
idea of what this would represent, let me give you some idea of what 
type of hardware involved, and it pricing.


I would currently recommend this type of 2U server:
https://www.aicipc.com/en/productdetail/51224

They provide 24 HDD storage, plus 2x SSD for the system. Equipped with a 
decent amount of RAM (128 GB) and a CPU, the cost is around 4000 EUR per 
server without the HDDs. Currently, 22TB Seagate HDDs are at around 350 
EUR per piece. So such a server fully equipped with HDD would be at 
around 12000 EUR per server. If we want 6 of them (which is IMO the bare 
minimum for redundancy, as each file is stored 3 times), we're talking 
of around 75000 EUR, plus 3 smaller servers to act as auth server (ie: 
Keytsone), at let's say 4000 each (which is average price for a decent 
server with 128 GB of RAM and 2x SSD system, plus 32 cores CPU), we 
would end up spending around 90kEUR for such a storage cluster. This 
would provide 1 PB of redundant (ie: copied 3 times) storage space.


This would need 15U of rack space, plus an eventual switch.

Though if we want to be safe, we could purchase at least one spare node 
and a few HDDs.


So all together, we're looking at a 100kEUR spending. Note that this 
type of swift cluster could also be used for artifact storage for Salsa 
(gitlab has a swift backend storage driver).


Also note that we're currently (at Infomaniak) using these AIC chassis 
with amd64, but we're looking at replacing the boards with some Gigabyte 
motherboard using Ampere CPU (ie: ARM64 based, with 80 cores).


If we need to save on costs at first, we could lower the amount of HDDs 
(let's say half), and add more HDDs later on. But you got my point, it's 
not *that* expensive, and for sure, something we could afford (we do 
have the budget).


I am hereby volunteering to setup such an OpenStack swift cluster for 
snapshot.d.o, or other Debian use. It'd be easy to find other people 
interested in helping me maintain this (I know some persons that already 
volunteered to help me when I'm away, in holidays or otherwise).


Your thoughts? Would the DPL agree on such a spending? Do we have 
somewhere to host this? At UBC? What would be the DSA opinion about 
this? Would they get involved? (IMO, we can do without DSA if they don't 
want to get involved, but I'd prefer if they would...)


Cheers,

Thomas Goirand (zigo)

P.S: Please CC me.

Bug#1020217: snapshot.debian.org: write a generic file driver supporting multiple backend (such as object-storage)

[Thomas Goirand]

Hi there!

I'm hereby cc-ing our DPL, to get him involved an eventual storage 
cluster purchase for the project.


I have been mentioning such an object storage driver, so we could use 
OpenStack swift for snapshot.d.o for years. I am happy that it finally 
brings traction, and that Lucas is implementing this. Thanks Lucas.


However, it is disappointing to see it moving toward an s3 
implementation, which is a protocol from a closed-source service. I 
already wrote multiple times that my company (Infomaniak) was willing to 
sponsor storage space on Swift for it.


FYI, we currently manage more than 110 PB of storage over 7500+ HDD and 
growing, so I am not scared at all about storage space. Some clusters we 
manage are around 40PB, with billions of files.


Though I do not envision *any* sponsor to provide the storage space, but 
rather, Debian maintaining its own storage cluster. To give you a rough 
idea of what this would represent, let me give you some idea of what 
type of hardware involved, and it pricing.


I would currently recommend this type of 2U server:
https://www.aicipc.com/en/productdetail/51224

They provide 24 HDD storage, plus 2x SSD for the system. Equipped with a 
decent amount of RAM (128 GB) and a CPU, the cost is around 4000 EUR per 
server without the HDDs. Currently, 22TB Seagate HDDs are at around 350 
EUR per piece. So such a server fully equipped with HDD would be at 
around 12000 EUR per server. If we want 6 of them (which is IMO the bare 
minimum for redundancy, as each file is stored 3 times), we're talking 
of around 75000 EUR, plus 3 smaller servers to act as auth server (ie: 
Keytsone), at let's say 4000 each (which is average price for a decent 
server with 128 GB of RAM and 2x SSD system, plus 32 cores CPU), we 
would end up spending around 90kEUR for such a storage cluster. This 
would provide 1 PB of redundant (ie: copied 3 times) storage space.


This would need 15U of rack space, plus an eventual switch.

Though if we want to be safe, we could purchase at least one spare node 
and a few HDDs.


So all together, we're looking at a 100kEUR spending. Note that this 
type of swift cluster could also be used for artifact storage for Salsa 
(gitlab has a swift backend storage driver).


Also note that we're currently (at Infomaniak) using these AIC chassis 
with amd64, but we're looking at replacing the boards with some Gigabyte 
motherboard using Ampere CPU (ie: ARM64 based, with 80 cores).


If we need to save on costs at first, we could lower the amount of HDDs 
(let's say half), and add more HDDs later on. But you got my point, it's 
not *that* expensive, and for sure, something we could afford (we do 
have the budget).


I am hereby volunteering to setup such an OpenStack swift cluster for 
snapshot.d.o, or other Debian use. It'd be easy to find other people 
interested in helping me maintain this (I know some persons that already 
volunteered to help me when I'm away, in holidays or otherwise).


Your thoughts? Would the DPL agree on such a spending? Do we have 
somewhere to host this? At UBC? What would be the DSA opinion about 
this? Would they get involved? (IMO, we can do without DSA if they don't 
want to get involved, but I'd prefer if they would...)


Cheers,

Thomas Goirand (zigo)

P.S: Please CC me.

[krita] [Bug 482365] Crash

[Thomas Krenn]

https://bugs.kde.org/show_bug.cgi?id=482365

Thomas Krenn  changed:

   What|Removed |Added

 CC||thomas.kr...@kabsi.at

--- Comment #5 from Thomas Krenn  ---
Hello all,
can confirm that loading the provided webp file and then trying to save it as
webp (default settings) results in a crash (on win10).
Below is the call stack from visual studio (without symbols). I can provide a
.dmp file if necessary.

libkritaimage.dll!7ff81156dd48()Unknown No symbols loaded.
kritawebpexport.dll!7ff820a50f85()  Unknown No symbols loaded.
libkritaui.dll!7ff807a3a8e6()   Unknown No symbols loaded.
libkritaui.dll!7ff807a39f07()   Unknown No symbols loaded.
libkritaui.dll!7ff807a3d2ea()   Unknown No symbols loaded.
libkritaui.dll!7ff807a3ce2c()   Unknown No symbols loaded.
libkritaui.dll!7ff807a3cd4c()   Unknown No symbols loaded.
Qt5Core.dll!7ff8145d1056()  Unknown No symbols loaded.
Qt5Core.dll!7ff8145cd59a()  Unknown No symbols loaded.
kernel32.dll!BaseThreadInitThunk() Unknown Symbols loaded.
ntdll.dll!RtlUserThreadStart() Unknown Symbols loaded.

Thanks for providing Krita.
Best regards
Thomas

-- 
You are receiving this mail because:
You are watching all bug changes.

[Patch, fortran] PR59104

[Paul Richard Thomas]

Hi All,

The attached fixes a problem that, judging by the comments, has been looked
at periodically over the last ten years but just looked to be too
fiendishly complicated to fix. This is not in small part because of the
confusing ordering of dummies in the tlink chain and the unintuitive
placement of all deferred initializations to the front of the init chain in
the wrapped block.

The result of the existing ordering is that the initialization code for
non-dummy variables that depends on the function result occurs before any
initialization code for the function result itself. The fix ensures that:
(i) These variables are placed correctly in the tlink chain, respecting
inter-dependencies; and (ii) The dependent initializations are placed at
the end of the wrapped block init chain.  The details appear in the
comments in the patch. It is entirely possible that a less clunky fix
exists but I failed to find it.

OK for mainline?

Regards

Paul


Change.Logs
Description: Binary data
diff --git a/gcc/fortran/dependency.cc b/gcc/fortran/dependency.cc
index bafe8cbc5bc..97ace8c778e 100644
--- a/gcc/fortran/dependency.cc
+++ b/gcc/fortran/dependency.cc
@@ -2497,3 +2497,63 @@ gfc_omp_expr_prefix_same (gfc_expr *lexpr, gfc_expr *rexpr)
 
   return true;
 }
+
+
+/* gfc_function_dependency returns true for non-dummy symbols with dependencies
+   on an old-fashioned function result (ie. proc_name = proc_name->result).
+   This is used to ensure that initialization code appears after the function
+   result is treated and that any mutual dependencies between these symbols are
+   respected.  */
+
+static bool
+dependency_fcn (gfc_expr *e, gfc_symbol *sym,
+		 int *f ATTRIBUTE_UNUSED)
+{
+  if (e == NULL)
+return false;
+
+  if (e && e->expr_type == EXPR_VARIABLE
+  && e->symtree
+  && e->symtree->n.sym == sym)
+return true;
+
+  return false;
+}
+
+
+bool
+gfc_function_dependency (gfc_symbol *sym, gfc_symbol *proc_name)
+{
+  bool front = false;
+
+  if (proc_name && proc_name->attr.function
+  && proc_name == proc_name->result
+  && !(sym->attr.dummy || sym->attr.result))
+{
+  if (sym->as && sym->as->type == AS_EXPLICIT)
+	{
+	  for (int dim = 0; dim < sym->as->rank; dim++)
+	{
+	  if (sym->as->lower[dim]
+		  && sym->as->lower[dim]->expr_type != EXPR_CONSTANT)
+		front = gfc_traverse_expr (sym->as->lower[dim], proc_name,
+	   dependency_fcn, 0);
+	  if (front)
+		break;
+	  if (sym->as->upper[dim]
+		  && sym->as->upper[dim]->expr_type != EXPR_CONSTANT)
+		front = gfc_traverse_expr (sym->as->upper[dim], proc_name,
+	   dependency_fcn, 0);
+	  if (front)
+		break;
+	}
+	}
+
+  if (sym->ts.type == BT_CHARACTER
+	  && sym->ts.u.cl && sym->ts.u.cl->length
+	  && sym->ts.u.cl->length->expr_type != EXPR_CONSTANT)
+	front = gfc_traverse_expr (sym->ts.u.cl->length, proc_name,
+   dependency_fcn, 0);
+}
+  return front;
+ }
diff --git a/gcc/fortran/dependency.h b/gcc/fortran/dependency.h
index ea4bd04b0e8..0fa5f93d0fc 100644
--- a/gcc/fortran/dependency.h
+++ b/gcc/fortran/dependency.h
@@ -23,7 +23,7 @@ enum gfc_dep_check
 {
   NOT_ELEMENTAL,/* Not elemental case: normal dependency check.  */
   ELEM_CHECK_VARIABLE,  /* Test whether variables overlap.  */
-  ELEM_DONT_CHECK_VARIABLE  /* Test whether variables overlap only if used 
+  ELEM_DONT_CHECK_VARIABLE  /* Test whether variables overlap only if used
 			   in an expression.  */
 };
 
@@ -43,3 +43,5 @@ bool gfc_are_equivalenced_arrays (gfc_expr *, gfc_expr *);
 bool gfc_omp_expr_prefix_same (gfc_expr *, gfc_expr *);
 
 gfc_expr * gfc_discard_nops (gfc_expr *);
+
+bool gfc_function_dependency (gfc_symbol *, gfc_symbol *);
\ No newline at end of file
diff --git a/gcc/fortran/error.cc b/gcc/fortran/error.cc
index 65e38b0e866..60f607ecc4f 100644
--- a/gcc/fortran/error.cc
+++ b/gcc/fortran/error.cc
@@ -892,7 +892,7 @@ error_print (const char *type, const char *format0, va_list argp)
 #else
 	  m = INTTYPE_MAXIMUM (ptrdiff_t);
 #endif
-	  m = 2 * m + 1;  
+	  m = 2 * m + 1;
 	  error_uinteger (a & m);
 	}
 	  else
diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
index 0a1646def67..7e39981e843 100644
--- a/gcc/fortran/symbol.cc
+++ b/gcc/fortran/symbol.cc
@@ -27,6 +27,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "parse.h"
 #include "match.h"
 #include "constructor.h"
+#include "dependency.h"
 
 
 /* Strings for all symbol attributes.  We use these for dumping the
@@ -948,15 +949,18 @@ conflict_std:
 void
 gfc_set_sym_referenced (gfc_symbol *sym)
 {
+  gfc_symbol *proc_name = sym->ns->proc_name ? sym->ns->proc_name : NULL;
 
   if (sym->attr.referenced)
 return;
 
   sym->attr.referenced = 1;
 
-  /* Remember which order dummy variables are accessed in.  */
-  if (sym->attr.dummy)
-sym->dummy_order = next_dummy_order++;
+  /* Remember which order dummy variables and symbols with function result
+ dependencies are accessed in.  

[Patch, fortran] PR59104

[Paul Richard Thomas]

Hi All,

The attached fixes a problem that, judging by the comments, has been looked
at periodically over the last ten years but just looked to be too
fiendishly complicated to fix. This is not in small part because of the
confusing ordering of dummies in the tlink chain and the unintuitive
placement of all deferred initializations to the front of the init chain in
the wrapped block.

The result of the existing ordering is that the initialization code for
non-dummy variables that depends on the function result occurs before any
initialization code for the function result itself. The fix ensures that:
(i) These variables are placed correctly in the tlink chain, respecting
inter-dependencies; and (ii) The dependent initializations are placed at
the end of the wrapped block init chain.  The details appear in the
comments in the patch. It is entirely possible that a less clunky fix
exists but I failed to find it.

OK for mainline?

Regards

Paul


Change.Logs
Description: Binary data
diff --git a/gcc/fortran/dependency.cc b/gcc/fortran/dependency.cc
index bafe8cbc5bc..97ace8c778e 100644
--- a/gcc/fortran/dependency.cc
+++ b/gcc/fortran/dependency.cc
@@ -2497,3 +2497,63 @@ gfc_omp_expr_prefix_same (gfc_expr *lexpr, gfc_expr *rexpr)
 
   return true;
 }
+
+
+/* gfc_function_dependency returns true for non-dummy symbols with dependencies
+   on an old-fashioned function result (ie. proc_name = proc_name->result).
+   This is used to ensure that initialization code appears after the function
+   result is treated and that any mutual dependencies between these symbols are
+   respected.  */
+
+static bool
+dependency_fcn (gfc_expr *e, gfc_symbol *sym,
+		 int *f ATTRIBUTE_UNUSED)
+{
+  if (e == NULL)
+return false;
+
+  if (e && e->expr_type == EXPR_VARIABLE
+  && e->symtree
+  && e->symtree->n.sym == sym)
+return true;
+
+  return false;
+}
+
+
+bool
+gfc_function_dependency (gfc_symbol *sym, gfc_symbol *proc_name)
+{
+  bool front = false;
+
+  if (proc_name && proc_name->attr.function
+  && proc_name == proc_name->result
+  && !(sym->attr.dummy || sym->attr.result))
+{
+  if (sym->as && sym->as->type == AS_EXPLICIT)
+	{
+	  for (int dim = 0; dim < sym->as->rank; dim++)
+	{
+	  if (sym->as->lower[dim]
+		  && sym->as->lower[dim]->expr_type != EXPR_CONSTANT)
+		front = gfc_traverse_expr (sym->as->lower[dim], proc_name,
+	   dependency_fcn, 0);
+	  if (front)
+		break;
+	  if (sym->as->upper[dim]
+		  && sym->as->upper[dim]->expr_type != EXPR_CONSTANT)
+		front = gfc_traverse_expr (sym->as->upper[dim], proc_name,
+	   dependency_fcn, 0);
+	  if (front)
+		break;
+	}
+	}
+
+  if (sym->ts.type == BT_CHARACTER
+	  && sym->ts.u.cl && sym->ts.u.cl->length
+	  && sym->ts.u.cl->length->expr_type != EXPR_CONSTANT)
+	front = gfc_traverse_expr (sym->ts.u.cl->length, proc_name,
+   dependency_fcn, 0);
+}
+  return front;
+ }
diff --git a/gcc/fortran/dependency.h b/gcc/fortran/dependency.h
index ea4bd04b0e8..0fa5f93d0fc 100644
--- a/gcc/fortran/dependency.h
+++ b/gcc/fortran/dependency.h
@@ -23,7 +23,7 @@ enum gfc_dep_check
 {
   NOT_ELEMENTAL,/* Not elemental case: normal dependency check.  */
   ELEM_CHECK_VARIABLE,  /* Test whether variables overlap.  */
-  ELEM_DONT_CHECK_VARIABLE  /* Test whether variables overlap only if used 
+  ELEM_DONT_CHECK_VARIABLE  /* Test whether variables overlap only if used
 			   in an expression.  */
 };
 
@@ -43,3 +43,5 @@ bool gfc_are_equivalenced_arrays (gfc_expr *, gfc_expr *);
 bool gfc_omp_expr_prefix_same (gfc_expr *, gfc_expr *);
 
 gfc_expr * gfc_discard_nops (gfc_expr *);
+
+bool gfc_function_dependency (gfc_symbol *, gfc_symbol *);
\ No newline at end of file
diff --git a/gcc/fortran/error.cc b/gcc/fortran/error.cc
index 65e38b0e866..60f607ecc4f 100644
--- a/gcc/fortran/error.cc
+++ b/gcc/fortran/error.cc
@@ -892,7 +892,7 @@ error_print (const char *type, const char *format0, va_list argp)
 #else
 	  m = INTTYPE_MAXIMUM (ptrdiff_t);
 #endif
-	  m = 2 * m + 1;  
+	  m = 2 * m + 1;
 	  error_uinteger (a & m);
 	}
 	  else
diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
index 0a1646def67..7e39981e843 100644
--- a/gcc/fortran/symbol.cc
+++ b/gcc/fortran/symbol.cc
@@ -27,6 +27,7 @@ along with GCC; see the file COPYING3.  If not see
 #include "parse.h"
 #include "match.h"
 #include "constructor.h"
+#include "dependency.h"
 
 
 /* Strings for all symbol attributes.  We use these for dumping the
@@ -948,15 +949,18 @@ conflict_std:
 void
 gfc_set_sym_referenced (gfc_symbol *sym)
 {
+  gfc_symbol *proc_name = sym->ns->proc_name ? sym->ns->proc_name : NULL;
 
   if (sym->attr.referenced)
 return;
 
   sym->attr.referenced = 1;
 
-  /* Remember which order dummy variables are accessed in.  */
-  if (sym->attr.dummy)
-sym->dummy_order = next_dummy_order++;
+  /* Remember which order dummy variables and symbols with function result
+ dependencies are accessed in.  

Bug#1072786: addch.3ncurses: some remarks and editorial changes for this man page

[Thomas Dickey]

On Fri, Jun 07, 2024 at 08:40:59PM +, Bjarni Ingi Gislason wrote:
> Package: ncurses-doc
> Version: 6.5-2
> Severity: minor
> Tags: patch
...
> 
> :189: warning: table row does not fit on page 1

Branden Robinson made a fix for this two weeks ago.

> Split lines longer than 80 characters into two or more lines.
> Appropriate break points are the end of a sentence and a subordinate
> clause; after punctuation marks.
>  
> addch.3ncurses: line 69 length 84

I don't use that check.  Instead, I use a script which warns me if the
rendered line would be too long.  This one ends at column 64.
 
> \fBint mvwaddch(WINDOW *\fIwin\fP, int \fIy\fP, int \fIx\fP, const chtype 
> \fIch\fP);

-- 
Thomas E. Dickey 
https://invisible-island.net


signature.asc
Description: PGP signature

[education/rkward] /: Documentation improvements

[Thomas Friedrichsmeier]

Git commit dafafe96c8c96275b65f7988c67027a08102dc51 by Thomas Friedrichsmeier.
Committed on 08/06/2024 at 22:10.
Pushed by tfry into branch 'master'.

Documentation improvements

M  +2-1doc/rkward/man-rkward.1.docbook
M  +19   -3rkward/pages/rkward_trouble_shooting.rkh
M  +1-0rkward/rbackend/rksessionvars.cpp
M  +11   -1rkward/rkward.cpp
M  +0-1rkward/settings/rksettings.cpp

https://invent.kde.org/education/rkward/-/commit/dafafe96c8c96275b65f7988c67027a08102dc51

diff --git a/doc/rkward/man-rkward.1.docbook b/doc/rkward/man-rkward.1.docbook
index 03a2bf739..efe5deb8e 100644
--- a/doc/rkward/man-rkward.1.docbook
+++ b/doc/rkward/man-rkward.1.docbook
@@ -86,7 +86,8 @@ SPDX-License-Identifier: GFDL-1.2-no-invariants-or-later OR 
GPL-2.0-or-later
 
 
 --r-executable command
-In the case of several R installations, specify the 
installation to use,  /usr/bin/R. You can also use the 
string "auto", in  which case RKWard will try to 
find R at one of the known standard installation paths. 
NOTE that while RKWard will often 
work with newer versions of R, it will sometimes need to 
be re-compiled for that version, or it may be incompatible 
altogether.
+In the case of several R installations, specify the 
installation to use,  /usr/bin/R. You can also use the 
string "auto", in  which case RKWard will try to 
find R at one of the known standard installation paths. 
NOTE that while RKWard will often 
work with newer versions of R, it will sometimes need to 
be re-compiled for that version, or it may be incompatible altogether.
+This option changes the R installation only for the current session, not 
persistently.
 
 
 --reuse
diff --git a/rkward/pages/rkward_trouble_shooting.rkh 
b/rkward/pages/rkward_trouble_shooting.rkh
index 395b9ace6..cd8ac5970 100644
--- a/rkward/pages/rkward_trouble_shooting.rkh
+++ b/rkward/pages/rkward_trouble_shooting.rkh
@@ -7,15 +7,28 @@ SPDX-License-Identifier: GPL-2.0-or-later
 
Trouble Shooting / FAQ

-   RKWard is far from complete and certainly there are many issues that 
need to be fixed. However, some of the things you notice are not due to the 
nature of RKWard but R or something else. This section will try to cover some 
common issues. See also https://rkward.kde.org/faq;>the online 
FAQ.
+   This page will try to cover some common issues you may encounter when 
using RKWard. See also https://rkward.kde.org/faq;>the online 
FAQ.


This problem will often occur, when moving an RKWard 
installation to a different path, esp. on Windows and Mac. You may have to visit
Settings->Configure RKWard->Plugins and re-add the relevant 
".pluginmap"-files. Starting with version 0.6.3, RKWard should detect
a changed installation path, and adjust paths, automatically.

-   
-   Yes, it's a very odd name. ;) However, R comes obviously from 
the http://www.r-project.org/;>R-language, which is the 
statistical basis of RKWard. K is derived from http://kde.org/;>KDE, which delivered the basic GUI technologies 
for RKWard. And http://en.wikipedia.org/wiki/Ward;>Ward? 
That's another story.
+   
+   A times the R backend will fail to start due to a configuration 
or installation problem. Common causes are changed paths, or an update to R. 
Usually,
+   in these cases, the setup dialog is shown when starting RKWard, 
and this allows to select a different installation of R. (Note: You will be 
offered
+   a selection of installations found a common paths, but you can 
also specify a non-detected installation, manually.)
+
+   In many cases, it will "just work" to select a version of R 
other than what has been used at compile time. Should you run into trouble, it 
is advised to
+   use the same, or a similar version of R to what was available 
during compilation, however.
+
+   You can manually change the R backend at any time, using 
Settings->Check installation. Be sure to save your data, before changing the 
backend! You can
+   also use the command-line option --r-executable in order to 
start a session using a specific installation of R.
+   
+   
+   The AppImage includes an installation of R for convenience, but 
this installation is not, and cannot technically be made fully functional. 
Importantly,
+   you will not generally be able to install R packages (other 
than ones implemented purely in R). Also, you may run into conflicts between 
the R installation
+   inside the AppImage, and R packages that are installed 
system-wide. This may cause subtle and surprising bugs.


This happens because RKWard starts first and subsequent R is 
started in the background. Depending on the speed of your machine it can take 
some time to

[education/rkward] /: Documentation updates

[Thomas Friedrichsmeier]

Git commit 57d3ecd7d44fc4671a0ed0b2884c89bb6b87aeee by Thomas Friedrichsmeier.
Committed on 08/06/2024 at 22:10.
Pushed by tfry into branch 'master'.

Documentation updates

M  +8-3doc/rkward/man-rkward.1.docbook
M  +4-3rkward/main.cpp
M  +4-4rkward/rkward.cpp
M  +1-1rkward/rkward.h

https://invent.kde.org/education/rkward/-/commit/57d3ecd7d44fc4671a0ed0b2884c89bb6b87aeee

diff --git a/doc/rkward/man-rkward.1.docbook b/doc/rkward/man-rkward.1.docbook
index c7caae5a8..03a2bf739 100644
--- a/doc/rkward/man-rkward.1.docbook
+++ b/doc/rkward/man-rkward.1.docbook
@@ -21,8 +21,8 @@ SPDX-License-Identifier: GFDL-1.2-no-invariants-or-later OR 
GPL-2.0-or-later
 rkward-de...@kde.org
 
 
-2023-11-30
-RKWard 0.7.5
+2024-05-26
+RKWard 0.8.0
 KDE Applications
 
 
@@ -98,7 +98,12 @@ SPDX-License-Identifier: GFDL-1.2-no-invariants-or-later OR 
GPL-2.0-or-later
 
 
 --nowarn-external
-Usually, when invoking  plugins from the command line 
( when files_to_open contains s of the form 
rkward://runplugin/...),  will show a 
warning that such s could be used to trigger 
malicious actions on your system. This warning applies specifically to links 
found on untrusted websites, or other untrusted external sources. If you want 
to script  locally, you can avoid this warning by adding 
--nowarn-external to the command line.
+Usually, when invoking  plugins from the command line 
( when files_to_open contains s of the form 
rkward://runplugin/...),  will show a 
warning that such s could be used to trigger 
malicious actions on your system. This warning applies specifically to links 
found on untrusted websites, or other untrusted external sources. If you want 
to script  locally, you can avoid this warning by adding 
--nowarn-external to the command line.
+(If used in combination with --reuse, then *both* commands in question 
will need to be invoked with --nowarn-external, in order to suppress the 
warning.)
+
+
+--setup
+Act as if a new version of RKWard had been installed, 
importantly re-installing the R support package, and showing the setup wizard. 
This feature is mostly targetted at developers, and testers.
 
 
 --quirkmode
diff --git a/rkward/main.cpp b/rkward/main.cpp
index 9deb10d0d..8029ccbb3 100644
--- a/rkward/main.cpp
+++ b/rkward/main.cpp
@@ -325,8 +325,7 @@ int main (int argc, char *argv[]) {
if (!app_singleton.isPrimaryInstance()) {
QByteArray call;
QDataStream stream(, QIODevice::WriteOnly);
-   // TODO: nowarn-external
-   stream << QVariant(QStringLiteral("openAnyUrl")) << 
QVariant(url_args) << QVariant(parser.isSet("nowarn-external"));
+   stream << QVariant(QStringLiteral("openAnyUrl")) << 
args[RKCommandLineArgs::UrlArgs] << args[RKCommandLineArgs::NoWarnExternal];
app_singleton.sendMessageWithTimeout(call, 1000);
// TODO: should always debug to terminal in this case!
RK_DEBUG (DEBUG_ALL, DL_INFO, "Reusing running 
instance");
@@ -392,7 +391,9 @@ int main (int argc, char *argv[]) {
stream >> urls;
stream >> nowarn;
if (call == QStringLiteral("openAnyUrl")) {
-   
main->openUrlsFromCommandLineOrDBus(!nowarn.toBool(), urls.toStringList());
+   QTimer::singleShot(0, main, [nowarn, urls, 
main]() {
+   
main->openUrlsFromCommandLineOrExternal(nowarn.toBool(), urls.toStringList());
+   });
} else {
RK_DEBUG (APP, DL_ERROR, "Unrecognized 
SingleApplication call");
}
diff --git a/rkward/rkward.cpp b/rkward/rkward.cpp
index 1905784d1..73fa7329a 100644
--- a/rkward/rkward.cpp
+++ b/rkward/rkward.cpp
@@ -224,7 +224,6 @@ void RKWardMainWindow::doPostInit () {
RK_TRACE (APP);
 
QStringList open_urls = 
RKCommandLineArgs::get(RKCommandLineArgs::UrlArgs).toStringList();
-   bool warn_external = 
!RKCommandLineArgs::get(RKCommandLineArgs::NoWarnExternal).toBool();
QString evaluate_code = 
RKCommandLineArgs::get(RKCommandLineArgs::Evaluate).toString();
 
initPlugins ();
@@ -258,7 +257,7 @@ void RKWardMainWindow::doPostInit () {
// the help window will be on top
if (RKSettingsModuleGeneral::showHelpOnStartup ()) 
toplevel_actions->showRKWardHelp ();
 
-   openUrlsFromCommandLineOrDBus (warn_external, open_urls);
+   openUrlsFromCommandLineOrExternal(true, open_urls);
} else {
if (RKSettingsModuleGeneral::openRestoreFileOnLoad() && 
QFile::exists(".RData")) {
 

Re: Assert in heapgettup_pagemode() fails due to underlying buffer change

[Thomas Munro]

On Fri, Jun 7, 2024 at 8:05 PM Alvaro Herrera  wrote:
> In passing, I noticed that WaitReadBuffers has zero comments, which
> seems an insufficient number of them.

Ack.  Here is a patch for that.  I guess I hadn't put a comment there
because it's hard to write anything without sort of duplicating what
is already said by the StartReadBuffers() comment and doubling down on
descriptions of future plans... but, in for a penny, in for a pound as
they say.
From db5e56825e4b4c595885373c413011c50fedd3e8 Mon Sep 17 00:00:00 2001
From: Thomas Munro 
Date: Sun, 9 Jun 2024 09:51:02 +1200
Subject: [PATCH] Add comment for WaitReadBuffers().

Per complaint from Alvaro while reviewing something else.

Reported-by: Alvaro Herrera 
Discussion: https://postgr.es/m/202406070805.icofqromovvn%40alvherre.pgsql
---
 src/backend/storage/buffer/bufmgr.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/src/backend/storage/buffer/bufmgr.c b/src/backend/storage/buffer/bufmgr.c
index a8e3377263f..409210a6ed2 100644
--- a/src/backend/storage/buffer/bufmgr.c
+++ b/src/backend/storage/buffer/bufmgr.c
@@ -1371,6 +1371,17 @@ WaitReadBuffersCanStartIO(Buffer buffer, bool nowait)
 		return StartBufferIO(GetBufferDescriptor(buffer - 1), true, nowait);
 }
 
+/*
+ * The second step of a StartReadBuffers(), WaitReadBuffers() sequence.  It is
+ * only necessary to call this if StartReadBuffers() returned true, indicating
+ * that I/O was necessary.
+ *
+ * Currently, this function performs synchronous I/O system calls.  The earlier
+ * StartReadBuffers() call might have issued advice to give the OS a head
+ * start so that it completes quickly.  In future work, a true asynchronous I/O
+ * could be started by StartReadBuffers(), and this function would wait for it
+ * to complete.
+ */
 void
 WaitReadBuffers(ReadBuffersOperation *operation)
 {
-- 
2.45.1

Re: Assert in heapgettup_pagemode() fails due to underlying buffer change

[Thomas Munro]

New version.  Same code as v2, but comments improved to explain the
reasoning, with reference to README's buffer access rules.  I'm
planning to push this soon if there are no objections.
From 1fa26f407622cd69d82f3b4ea68fddf2c357cf06 Mon Sep 17 00:00:00 2001
From: Thomas Munro 
Date: Fri, 7 Jun 2024 17:49:19 +1200
Subject: [PATCH v3] Fix RBM_ZERO_AND_LOCK.

Commit 210622c6 accidentally zeroed out pages even if they were found in
the buffer pool.  It should always lock the page, but it should only
zero pages that were not already found as an optimization to avoid I/O.
Otherwise, concurrent readers that hold only a pin might see corrupted
page contents changing under their feet.  This is done with the standard
BM_IO_IN_PROGRESS infrastructure to test for BM_VALID and wake
concurrent waiters without races (as it was in earlier releases).

Reported-by: Noah Misch 
Reported-by: Alexander Lakhin 
Reviewed-by: Alvaro Herrera  (earlier version)
Reviewed-by: Robert Haas  (earlier version)
Discussion: https://postgr.es/m/20240512171658.7e.nmi...@google.com
Discussion: https://postgr.es/m/7ed10231-ce47-03d5-d3f9-4aea0dc7d5a4%40gmail.com
---
 src/backend/storage/buffer/bufmgr.c | 64 -
 1 file changed, 45 insertions(+), 19 deletions(-)

diff --git a/src/backend/storage/buffer/bufmgr.c b/src/backend/storage/buffer/bufmgr.c
index 49637284f91..a8e3377263f 100644
--- a/src/backend/storage/buffer/bufmgr.c
+++ b/src/backend/storage/buffer/bufmgr.c
@@ -1010,43 +1010,69 @@ ExtendBufferedRelTo(BufferManagerRelation bmr,
 }
 
 /*
- * Zero a buffer and lock it, as part of the implementation of
+ * Lock and optionally zero a buffer, as part of the implementation of
  * RBM_ZERO_AND_LOCK or RBM_ZERO_AND_CLEANUP_LOCK.  The buffer must be already
- * pinned.  It does not have to be valid, but it is valid and locked on
- * return.
+ * pinned.  If the buffer is not already valid, it is zeroed and made valid.
  */
 static void
-ZeroBuffer(Buffer buffer, ReadBufferMode mode)
+ZeroAndLockBuffer(Buffer buffer, ReadBufferMode mode, bool already_valid)
 {
 	BufferDesc *bufHdr;
-	uint32		buf_state;
+	bool		need_to_zero;
 
 	Assert(mode == RBM_ZERO_AND_LOCK || mode == RBM_ZERO_AND_CLEANUP_LOCK);
 
-	if (BufferIsLocal(buffer))
+	if (already_valid)
+	{
+		/*
+		 * If the caller already knew the buffer was valid, we can skip some
+		 * header interaction.  The caller just wants to lock the buffer.
+		 */
+		need_to_zero = false;
+	}
+	else if (BufferIsLocal(buffer))
+	{
+		/* Simple case for non-shared buffers. */
 		bufHdr = GetLocalBufferDescriptor(-buffer - 1);
+		need_to_zero = (pg_atomic_read_u32(>state) & BM_VALID) == 0;
+	}
 	else
 	{
+		/*
+		 * Take BM_IO_IN_PROGRESS, or discover that BM_VALID has been set
+		 * concurrently.  Even though we aren't doing I/O, that protocol
+		 * ensures that we don't zero a page that someone else has pinned.  An
+		 * exclusive content lock wouldn't be enough, because readers are
+		 * allowed to drop the content lock after determining that a tuple is
+		 * visible (see buffer access rules in README).
+		 */
 		bufHdr = GetBufferDescriptor(buffer - 1);
+		need_to_zero = StartBufferIO(bufHdr, true, false);
+	}
+
+	if (need_to_zero)
+		memset(BufferGetPage(buffer), 0, BLCKSZ);
+
+	/* Acquire the requested lock before setting BM_VALID. */
+	if (!BufferIsLocal(buffer))
+	{
 		if (mode == RBM_ZERO_AND_LOCK)
 			LockBuffer(buffer, BUFFER_LOCK_EXCLUSIVE);
 		else
 			LockBufferForCleanup(buffer);
 	}
 
-	memset(BufferGetPage(buffer), 0, BLCKSZ);
-
-	if (BufferIsLocal(buffer))
-	{
-		buf_state = pg_atomic_read_u32(>state);
-		buf_state |= BM_VALID;
-		pg_atomic_unlocked_write_u32(>state, buf_state);
-	}
-	else
+	/*
+	 * Set BM_VALID, and wake anyone waiting for BM_IO_IN_PROGRESS to be
+	 * cleared.
+	 */
+	if (need_to_zero)
 	{
-		buf_state = LockBufHdr(bufHdr);
-		buf_state |= BM_VALID;
-		UnlockBufHdr(bufHdr, buf_state);
+		if (BufferIsLocal(buffer))
+			pg_atomic_write_u32(>state,
+pg_atomic_read_u32(>state) | BM_VALID);
+		else
+			TerminateBufferIO(bufHdr, false, BM_VALID, true);
 	}
 }
 
@@ -1185,7 +1211,7 @@ ReadBuffer_common(Relation rel, SMgrRelation smgr, char smgr_persistence,
 
 		buffer = PinBufferForBlock(rel, smgr, smgr_persistence,
    forkNum, blockNum, strategy, );
-		ZeroBuffer(buffer, mode);
+		ZeroAndLockBuffer(buffer, mode, found);
 		return buffer;
 	}
 
-- 
2.45.1

Re: From JoyceUlysses.txt -- words occurring exactly once

[Thomas Passin via Python-list]

On 6/8/2024 2:46 PM, avi.e.gr...@gmail.com wrote:

Agreed, Thomas.

As someone who has spent lots of time writing code OR requirements of various 
levels or having to deal with the bugs afterwards, there can be a huge 
disconnect between the people trying to decide what to do and the people having 
to do it. It is not necessarily easy to come back later and ask for changes 
that wewre not anticipated in the design or implementation.


And typical contract vehicles aren't often flexible to allow for this 
kind of thing. I've always tried to persuade my management to allow 
built-in phases where re-evaluation can take place based on what's been 
learned. To have a hope of that working, though, there needs to be a lot 
of trust between client and development folks.  Can be hard to come by.



I recently wrote a program where the original specifications seemed reasonable. 
In one part, I was asked to make a graph with some random number (or all) of 
the data shown as a series of connected line segments showing values for the 
same entity at different measurement periods and then superimpose the mean for 
all the original data, not just the subsample shown. This needed to be done on 
multiple subsamples of the original/calculated data so I made it into a 
function.

One of the datasets contained a column that was either A or B and the function 
was called multiple times to show what a random sample of A+B, just A and just 
B graphed like along with the mean of the specific data it was drawn from. But 
then, I got an innocuously simple request.

Could we graph A+B and overlay not only the means for A+B as was now done, but 
also the mean for A and the mean for B. Ideally, this would mean three bolder 
jaged lines superimposed above the plot and seemed simple enough.

But was it? To graph the means in the first place, I made a more complex data 
structure needed so when graphed, it aligned well with what was below it. But 
that was hard coded in my function, but in one implementation, I now needed it 
three times. Extracting it into a new function was not trivial as it depended 
initially on other things within the body of the function. But, it was doable 
and might have been done that way had I known such a need might arise. It often 
is like that when there seems no need to write a function for just one use. The 
main function now needed to be modified to allow optionally adding one or two 
more datasets and if available, call the new function on each and add layers to 
the graph with the additional means (dashed and dotted) if they are called 
while otherwise, the function worked as before.


I feel your pain. In the generalized X-Y graphing program I've evolved 
over several generations, I have graphing methods that can plot points 
and curves, optionally overlaying them.  Any function that wants to plot 
something has to generate a dataset object of the type that the plotter 
knows how to plot.  No exceptions. Nothing else ever plots to the 
screen.  It's simple and works very well ... but I only designed it to 
have axis labels and the title of the plot. They are all three 
interactive, editable by the user.  That's good, but for anything else 
it's hack time.  Witness lines, legends, point labels, etc., etc. don't 
have a natural home.



But did I do it right? Well, if next time I am asked to have the data extended to 
have more measurements in more columns at more times, I might have to rewrite quite 
a bit of the code. My localized change allowed one or two additional means to be 
plotted. Adding an arbitrary number takes a different approach and, frankly, there 
are limits on how many kinds of 'line" segments can be used to differentiate 
among them.


This is the kind of situation where it needs to be implemented three 
times before it gets good.  One always thinks that the second time 
around will work well because all the lessons were learned the first 
time around.  But no, it's not the second but the third implementation 
that can start to be really good.



Enough of the example except to make a point. In some projects, it is not 
enough to tell a programmer what you want NOW. You may get what you want fairly 
quickly but if you have ideas of possible extensions or future upgrades, it 
would be wiser to make clear some of the goals so the programmer creates an 
implementation that can be more easily adjusted to do more. Such code can take 
longer and be more complex so it may not pay off immediately.

But, having said that, plenty of software may benefit from looking at what is 
happening and adjusting on the fly. Clearly my client cannot know what feedback 
they may get when showing an actual result to others who then suggest changes 
or enhancements. The results may not be anticipated so well in advance and 
especially not when the client has no idea what is doable and so on.

A related example was a request for how to modify a sort of Venn Diagram  chart 
to change the font size

Re: Release Apache MINA SSHD 2.13.0?

[Thomas Wolf]

On 2024-06-08 20:48 , Thomas Wolf wrote:

I suggest we start with a release for Apache MINA 2.13.0.


Apache MINA SSHD, of course.

Cheers,

  Thomas


-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

Release Apache MINA SSHD 2.13.0?

[Thomas Wolf]

I suggest we start with a release for Apache MINA 2.13.0.

The 2.12.0 release was in January. Since then, we've had a number
of minor bug fixes, some SFTP client improvements to deal with
broken servers doing strange things, and a lot of clean-ups (thanks, Gary!).

The most important changes are fixes in ciphers, and removing CBC 
ciphers from the server's proposal. (The ciphers are still there, but

would need to be enabled explicitly.)

We've upgraded the Bouncy Castle (optional) dependency to 1.78.1,
and if BC 1.78.1 is present we now have sntrup761x25519-sha512 KEX.

The full list of noteworthy changes is, as always, at [1].

Cheers,

  Thomas

[1] https://github.com/apache/mina-sshd/blob/master/CHANGES.md

-
To unsubscribe, e-mail: dev-unsubscr...@mina.apache.org
For additional commands, e-mail: dev-h...@mina.apache.org

Re: From JoyceUlysses.txt -- words occurring exactly once

[Thomas Passin via Python-list]

On 6/8/2024 11:54 AM, Larry Martell via Python-list wrote:

On Sat, Jun 8, 2024 at 10:39 AM Mats Wichmann via Python-list <
python-list@python.org> wrote:


On 6/5/24 05:10, Thomas Passin via Python-list wrote:


Of course, we see this lack of clarity all the time in questions to the
list.  I often wonder how these askers can possibly come up with
acceptable code if they don't realize they don't truly know what it's
supposed to do.


Fortunately, having to explain to someone else why something is giving
you trouble can help shed light on the fact the problem statement isn't
clear, or isn't clearly understood. Sometimes (sadly, many times it
doesn't).



The original question struck me as homework or an interview question for a
junior position. But having no clear requirements or specifications is good
training for the real world where that is often the case. When you question
that, you are told to just do something, and then you’re told it’s not what
is wanted. That frustrates people but it’s often part of the process.
People need to see something to help them know what they really want.


At the extremes, there are two kinds of approaches you are alluding to. 
One is what I learned to call "rock management": "Bring me a rock ... 
no, that's not the right one, bring me another ... no that's not what 
I'm looking for, bring me another...".  If this is your situation, so, 
so sorry!


At the other end, there is a mutual evolution of the requirements 
because you and your client could not have known what they should be 
until you have spent effort and time feeling your way along.  With the 
right client and management, this kind of project can be a joy to work 
on.  I've been lucky enough to have worked on several projects of this kind.


In truth, there always are requirements.  Often (usually?) they are not 
thought out, not consistent, not articulated clearly, and not 
communicated well. They may live only in the mind of one person.


--
https://mail.python.org/mailman/listinfo/python-list

[NTG-context] Re: ConTeXt source from XML

[Thomas A. Schmitz]

On 6/8/24 10:49, vm via ntg-context wrote:

in the document
https://wiki.contextgarden.net/images/8/8c/xhtml.pdf

near the end an essential line got truncated:

\startxmlsetups xml:img
\placefigure[here]
[\xmlatt{#1}{src}]
{\xmlatt{#1}{alt}}
{\externalfigure[\xmlatt{#1}{src}][width=\ctxlua{getmeas("\xmla
\stopxmlsetups




how should this line continue ?
{\externalfigure[\xmlatt{#1}{src}][width=\ctxlua{getmeas("\xmla




That would be

{\externalfigure[\xmlatt{#1}{src}]
[width=\ctxlua{getmeas("\xmlatt{#1}{width}")}]}

Thomas
___
If your question is of interest to others as well, please add an entry to the 
Wiki!

maillist : ntg-context@ntg.nl / 
https://mailman.ntg.nl/mailman3/lists/ntg-context.ntg.nl
webpage  : https://www.pragma-ade.nl / https://context.aanhet.net (mirror)
archive  : https://github.com/contextgarden/context
wiki : https://wiki.contextgarden.net
___

Mailgun SSL_accept error

[Thomas Barth via postfix-users]

Hallo,
immer wenn eine Mail über Mailgun eingeliefert wird, kommt es zunächst 
zu einer Fehlermeldung.


Jun 07 16:55:04 mx1 postfix/smtpd[196980]: connect from 
m204-56.eu.mailgun.net[161.38.204.56]
Jun 07 16:55:04 mx1 postfix/smtpd[196983]: SSL_accept error from 
m204-56.eu.mailgun.net[161.38.204.56]: -1
Jun 07 16:55:04 mx1 postfix/smtpd[196983]: warning: TLS library problem: 
error:0A000412:SSL routines::sslv3 alert bad 
certificate:../ssl/record/rec_layer_s3.c:1586:SSL alert number 42:
Jun 07 16:55:04 mx1 postfix/smtpd[196983]: lost connection after 
STARTTLS from m204-56.eu.mailgun.net[161.38.204.56]


Dann funktioniert es aber doch

Jun 07 16:55:04 mx1 postfix/smtpd[196980]: Anonymous TLS connection 
established from m204-56.eu.mailgun.net[161.38.204.56]: TLSv1.3 with 
cipher TLS_AES_128_GCM_SHA256 ...


Verstehe es richtig, dass Mailgun bei der Einlieferung ein Zertifikat 
präsentiert, welches nicht akzeptiert werden kann, weil es einfach nur 
"schlecht" ist oder weil auf dem Server noch eine 
Konfigurationseinstellung fehlt?

Re: Assert in heapgettup_pagemode() fails due to underlying buffer change

[Thomas Munro]

On Sat, Jun 8, 2024 at 12:47 AM Robert Haas  wrote:
>
> On Fri, Jun 7, 2024 at 4:05 AM Alvaro Herrera  wrote:
> > >  static void
> > > -ZeroBuffer(Buffer buffer, ReadBufferMode mode)
> > > +ZeroBuffer(Buffer buffer, ReadBufferMode mode, bool zero)
> >
> > This change makes the API very strange.  Should the function be called
> > ZeroAndLockBuffer() instead?  Then the addition of a "bool zero"
> > argument makes a lot more sense.
>
> I agree that's better, but it still looks a bit weird. You have to
> realize that 'bool zero' means 'is already zeroed' here -- or at
> least, I guess that's the intention. But then I wonder why you'd call
> a function called ZeroAndLockBuffer if all you need to do is
> LockBuffer.

The name weirdness comes directly from RBM_ZERO_AND_LOCK (the fact
that it doesn't always zero despite shouting ZERO is probably what
temporarily confused me).  But coming up with a better name is hard
and I certainly don't propose to change it now.  I think it's
reasonable for this internal helper function to have that matching
name as Alvaro suggested, with a good comment about that.

Even though that quick-demonstration change fixed the two reported
repros, I think it is still probably racy (or if it isn't, it relies
on higher level interlocking that I don't want to rely on).  This case
really should be using the standard StartBufferIO/TerminateBufferIO
infrastructure as it was before.  I had moved that around to deal with
multi-block I/O, but dropped the ball on the zero case... sorry.

Here's a version like that.  The "zero" argument (yeah that was not a
good name) is now inverted and called "already_valid", but it's only a
sort of optimisation for the case where we already know for sure that
it's valid.  If it isn't, we do the standard
BM_IO_IN_PROGRESS/BM_VALID/CV dance, for correct interaction with any
concurrent read or zero operation.


v2-0001-Fix-RBM_ZERO_AND_LOCK.patch
Description: Binary data

[clang] [llvm] [APFloat] Add APFloat support for FP6 data types (PR #94735)

[Thomas Raoux via cfe-commits]

https://github.com/ThomasRaoux approved this pull request.

LGTM, please wait to confirm that everybody is happy with the naming before 
merging.

@krzysz00 was your comment meant to be a blocker?

https://github.com/llvm/llvm-project/pull/94735
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Bug#1072080: murano-agent: diff for NMU version 1:12.0.0-1.1

[thomas]

I haven't look at details but I trust fellow DDs. Please go ahead! MR on Salsa 
are always welcome for NMUs too... 


Thomas 


Sent from Workspace ONE Boxer 


On Jun 7, 2024 3:39 PM, Chris Hofstaedtler  wrote:

Control: tags 1072080 + patch 
Control: tags 1072080 + pending 


Dear maintainer, 

I've prepared an NMU for murano-agent (versioned as 1:12.0.0-1.1) and 
uploaded it to DELAYED/7. Please feel free to tell me if I 
should delay it longer. 

Regards. 

[clang] [llvm] [APFloat] Add APFloat support for FP6 data types (PR #94735)

[Thomas Raoux via cfe-commits]

ThomasRaoux wrote:

> (If it's for MLIR support, I'd like to have a discussion there, since I don't 
> thisk these scalars belong in `FloatType` and that the long-term solution is 
> to allow arbitrary newtypes / tags on bits / ... up there)

I don't want to speak for the author but I'm interested in this support. I 
replied on your thread on discourse:
https://discourse.llvm.org/t/rfc-should-the-ocp-microscaling-float-scalars-be-added-to-apfloat-and-floattype/77530/8

https://github.com/llvm/llvm-project/pull/94735
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [llvm] [APFloat] Add APFloat support for FP6 data types (PR #94735)

[Thomas Raoux via cfe-commits]

https://github.com/ThomasRaoux commented:

Looks good to me once the other comments are addressed. Thanks for the patch.

https://github.com/llvm/llvm-project/pull/94735
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: Batik cannot render bar charts generated by XChart

[Thomas DeWeese]

Sorry if my use of terrible offended you.

I thought I was pretty clear that I thought throwing a useful error and/or
logging a useful message indicating the non-compliance would IMO be the
correct response.

I agree that the patch does not make Batik non-conforming.

In my experience patches like the proposed one slow down conformant
rendering (a bunch of extra checks for non-conforming content), make the
code base a mine field for following developers (what is this weird check -
is this part of the spec? why are we generating infinite rectangles, how
does dropping them help, etc) and tend to lead to harder and harder to
understand error conditions (like this patch could lead to non-conformant
elements silently being dropped not generating proper update regions etc).

Thomas

On Fri, Jun 7, 2024 at 10:11 AM Peter Hull  wrote:

> On Fri, 7 Jun 2024 at 14:31, Thomas DeWeese 
> wrote:
> > I personally think that is a terrible idea to add hacks/work arounds to
> partially fix the invalid content.  It is helpful to tell people their
> content is invalid and ideally where and why - doing partial work arounds
> for invalid content IMO does no-one any favors - it's adding complexity and
> still going to lead to failures in other areas that are likely going to be
> harder to find/debug/explain.
> I don't like it either, but I'd stop short of "terrible" (I've had
> some terrible ideas in the past, and this doesn't come close!) because
> it's consistent with "from a compliance perspective the renderer is
> free to do whatever is convenient for it" and doesn't fail any tests.
> I think this is a judgement call, so it needs the judgement of someone
> who knows what they're talking about (ie. you), so I'm grateful for
> that. As far as I can see, browsers take a different approach, and try
> to render something, which is consistent with the way they treat
> invalid HTML, isn't it?
> What do you think would be the best - throwing an error, printing a
> log message or something else?
>
> >   If you feel that single precision float is too limiting it would be
> much better to try and migrate everything to double precision - but I
> suspect that would be a long road.
> I agree. Also it will still be possible to write an out-of-bounds literal.
>
> -
> To unsubscribe, e-mail: batik-users-unsubscr...@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-h...@xmlgraphics.apache.org
>
>

Bug#1072746: Further investigation

[Thomas Goirand]

Hi,

After further investigation, it looks like to me that the issue is only 
with newer kernel, like 6.1.0 (ie: currently backport kernels).


Since during the lifetime of oldstable, it may be upgraded to the 
backport kernel, I still would like this patch to get in Bullseye, 
especially *before* it becomes LTS.


Thanks.

Cheers,

Thomas Goirand (zigo)

Bug#1072746: Further investigation

[Thomas Goirand]

Hi,

After further investigation, it looks like to me that the issue is only 
with newer kernel, like 6.1.0 (ie: currently backport kernels).


Since during the lifetime of oldstable, it may be upgraded to the 
backport kernel, I still would like this patch to get in Bullseye, 
especially *before* it becomes LTS.


Thanks.

Cheers,

Thomas Goirand (zigo)

Bug#1072746: Patch header updated

[Thomas Goirand]

Hi,

FYI, I have updated the patch header to contain the upstream comments, 
and giving back original authorship.


Cheers,

Thomas Goirand (zigo)

Bug#1072746: Patch header updated

[Thomas Goirand]

Hi,

FYI, I have updated the patch header to contain the upstream comments, 
and giving back original authorship.


Cheers,

Thomas Goirand (zigo)

[Wurfpost] Umzug der Wurfpost auf neuen Server und neue Adresse!

[Thomas Griesbaum via Wurfpost]

Liebe Wurfpost-Abonnenten,

leider kann die Wurfpost-Mailingliste aus organisatorisch-technischen Gründen 
nicht mehr an der Uni Koblenz fortgeführt werden. Daher wird sie in den 
nächsten Tagen auf einen neuen Server umgezogen (und künftig über eine andere 
Mailadresse erreichbar sein).

Beim Umzug erhalten alle aktuellen Abonnenten eine Einladungsmail vom neuen 
Listen-Server mit einem Link, über den sie bestätigen müssen, dass sie Mails 
von der neuen Liste bekommen wollen.

Weitere Informationen werden kurz vor dem Umzug der Abonnenten-Adressen 
mitgeteilt.

Grüße vom
Listen-Admin Markus Lust
und
Thomas Griesbaum

___
Wurfpost mailing list
Wurfpost@list.uni-koblenz.de
https://list.uni-koblenz.de/mailman/listinfo/wurfpost

[drm:amdgpu_fill_buffer [amdgpu]] *ERROR* Trying to clear memory with ring turned off.

[Thomas Glanzmann]

027345]  init_module_from_file+0x86/0xc0
[   11.027347]  idempotent_init_module+0x120/0x2a0
[   11.027349]  __x64_sys_finit_module+0x5a/0xb0
[   11.027351]  do_syscall_64+0x80/0x190
[   11.027353]  ? vm_mmap_pgoff+0x129/0x1c0
[   11.027356]  ? fpregs_assert_state_consistent+0x1d/0x40
[   11.027359]  ? syscall_exit_to_user_mode+0x76/0x1f0
[   11.027360]  ? do_syscall_64+0x8c/0x190
[   11.027361]  ? __do_sys_newfstatat+0x4e/0x80
[   11.027364]  ? fpregs_assert_state_consistent+0x1d/0x40
[   11.027366]  ? syscall_exit_to_user_mode+0x76/0x1f0
[   11.027367]  ? do_syscall_64+0x8c/0x190
[   11.027368]  ? fpregs_restore_userregs+0x11/0xc0
[   11.027370]  ? syscall_exit_to_user_mode+0x76/0x1f0
[   11.027371]  ? do_syscall_64+0x8c/0x190
[   11.027372]  ? do_syscall_64+0x8c/0x190
[   11.027373]  ? fpregs_assert_state_consistent+0x1d/0x40
[   11.027374]  entry_SYSCALL_64_after_hwframe+0x4b/0x53
[   11.027376] RIP: 0033:0x7fc91241f719
[   11.027377] Code: 08 89 e8 5b 5d c3 66 2e 0f 1f 84 00 00 00 00 00 90 48 89 
f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 
f0 ff ff 73 01 c3 48 8b 0d b7 06 0d 00 f7 d8 64 89 01 48
[   11.027379] RSP: 002b:7fffc491bc48 EFLAGS: 0246 ORIG_RAX: 
0139
[   11.027380] RAX: ffda RBX: 55a3eb64ff10 RCX: 7fc91241f719
[   11.027381] RDX:  RSI: 7fc9125b2efd RDI: 0018
[   11.027382] RBP: 7fc9125b2efd R08:  R09: 55a3eb54d730
[   11.027383] R10: 0018 R11: 0246 R12: 0002
[   11.027384] R13:  R14: 55a3eb64c470 R15: 55a3d0094ec1
[   11.027385]  
[   11.027386] ---[ end trace  ]---

Full dmesg: 
https://tg.st/u/9c7ed52e84c5a1fa8aa0943139b47f7312c66b70f6dec0deb409ead1a635c8c5.txt

Cheers,
    Thomas

Re: Batik cannot render bar charts generated by XChart

[Thomas DeWeese]

FYI I just saw your attempted fix in the bug thread.

I personally think that is a terrible idea to add hacks/work arounds to
partially fix the invalid content.  It is helpful to tell people their
content is invalid and ideally where and why - doing partial work arounds
for invalid content IMO does no-one any favors - it's adding complexity and
still going to lead to failures in other areas that are likely going to be
harder to find/debug/explain.

  If you feel that single precision float is too limiting it would be much
better to try and migrate everything to double precision - but I suspect
that would be a long road.

On Fri, Jun 7, 2024 at 9:12 AM Thomas DeWeese 
wrote:

> Any content that uses values outside of the range specified to be
> supported by the standard is relying on undefined behavior so from a
> compliance perspective the renderer is free to do whatever is convenient
> for it.  I agree that someone should notify XChart that their generated SVG
> is not spec compliant (at least with 1.1).
>
> As for what it would be nice for an implementation to do, it would be nice
> if it gave clear warnings/errors that the content is not compliant with the
> specification and thus may render incorrectly.
>
> Batik does it's own number parsing (it was substantially faster than the
> built in float parsers at the time) so that might not even be that hard to
> do.
>
> On Fri, Jun 7, 2024 at 7:13 AM Peter Hull  wrote:
>
>> On Wed, 5 Jun 2024 at 23:30, Thomas DeWeese 
>> wrote:
>> > Unless stated otherwise for a particular attribute or property, a
>>  has the capacity for at least a single-precision floating point
>> number and has a range (at a minimum) of -3.4e+38F to +3.4e+38F.
>>
>> What's your feeling on what should happen for a number outside this
>> range? Ideally I suppose every implementation should give the actual
>> range it supports and what happens to out-of-range values. Which seems
>> unlikely to happen.
>>
>> This clause from the standard would be useful to tell XChart that
>> their code generates SVG that is not guaranteed to be handled by every
>> standard-compliant implementation.
>>
>> Peter
>>
>> -
>> To unsubscribe, e-mail: batik-users-unsubscr...@xmlgraphics.apache.org
>> For additional commands, e-mail: batik-users-h...@xmlgraphics.apache.org
>>
>>

Re: Batik cannot render bar charts generated by XChart

[Thomas DeWeese]

Any content that uses values outside of the range specified to be supported
by the standard is relying on undefined behavior so from a compliance
perspective the renderer is free to do whatever is convenient for it.  I
agree that someone should notify XChart that their generated SVG is not
spec compliant (at least with 1.1).

As for what it would be nice for an implementation to do, it would be nice
if it gave clear warnings/errors that the content is not compliant with the
specification and thus may render incorrectly.

Batik does it's own number parsing (it was substantially faster than the
built in float parsers at the time) so that might not even be that hard to
do.

On Fri, Jun 7, 2024 at 7:13 AM Peter Hull  wrote:

> On Wed, 5 Jun 2024 at 23:30, Thomas DeWeese 
> wrote:
> > Unless stated otherwise for a particular attribute or property, a
>  has the capacity for at least a single-precision floating point
> number and has a range (at a minimum) of -3.4e+38F to +3.4e+38F.
>
> What's your feeling on what should happen for a number outside this
> range? Ideally I suppose every implementation should give the actual
> range it supports and what happens to out-of-range values. Which seems
> unlikely to happen.
>
> This clause from the standard would be useful to tell XChart that
> their code generates SVG that is not guaranteed to be handled by every
> standard-compliant implementation.
>
> Peter
>
> -
> To unsubscribe, e-mail: batik-users-unsubscr...@xmlgraphics.apache.org
> For additional commands, e-mail: batik-users-h...@xmlgraphics.apache.org
>
>

Re: Problem with a certain domain

[Thomas Barth via bind-users]

Am 2024-06-06 18:35, schrieb Matus UHLAR - fantomas:
if the problem happens again, you can call 'rndc dumpdb' to dump 
named's cache and see all records your named remembers about 
mallorcazeitung.es and epi.es

perhaps they can help to explain why named can't resolve anything.



Yes, it always happens when the mail is checked against the DNS block 
list. In the journal I can read:


Jun 07 14:30:26 mx1 named[118262]: success resolving 
'mallorcazeitung.es.multi.uribl.com/A' after disabling qname 
minimization due to 'ncache nxdomain'
Jun 07 14:30:26 mx1 named[118262]: success resolving 
'212.132.135.159.dnsbl.sorbs.net/A' after disabling qname minimization 
due to 'ncache nxdomain'
Jun 07 14:30:28 mx1 named[118262]: success resolving 
'www-cdn-lb-tf.gslb.prensaiberica.net/A' after disabling qname 
minimization due to 'ncache nxdomain'
Jun 07 14:30:28 mx1 named[118262]: success resolving 
'caching.c354.edge2befaster.net/A' after disabling qname minimization 
due to 'ncache nxdomain'
Jun 07 14:30:28 mx1 named[118262]: success resolving 
'aec01.euc.edgetcdn.net/A' after disabling qname minimization due to 
'ncache nxdomain'
Jun 07 14:30:28 mx1 named[118262]: success resolving 
'aec01.eug.edgetcdn.net/A' after disabling qname minimization due to 
'ncache nxdomain'
Jun 07 14:30:28 mx1 named[118262]: success resolving 
'161.237.127.79.zen.spamhaus.org/A' after disabling qname minimization 
due to 'ncache nxdomain'
Jun 07 14:30:28 mx1 named[118262]: success resolving 
'129.211.127.79.zen.spamhaus.org/A' after disabling qname minimization 
due to 'ncache nxdomain'
Jun 07 14:30:28 mx1 named[118262]: success resolving 
'209.44.199.138.zen.spamhaus.org/A' after disabling qname minimization 
due to 'ncache nxdomain'
Jun 07 14:30:40 mx1 named[118262]: shut down hung fetch while resolving 
's1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es/TXT'
Jun 07 14:30:43 mx1 named[118262]: shut down hung fetch while resolving 
'_adsp._domainkey.newsletter.mallorcazeitung.es/TXT'

[...]
Jun 07 14:32:05 mx1 postfix/smtpd[193761]: warning: timeout talking to 
proxy localhost:10024
Jun 07 14:32:05 mx1 postfix/smtpd[193761]: proxy-reject: END-OF-MESSAGE: 
451 4.3.0 Error: queue file write error; from=

[...]
Jun 07 14:32:05 mx1 postfix/cleanup[193820]: 77BB2202612: 
message-id=
Jun 07 14:32:05 mx1 opendkim[691]: 77BB2202612: no signing table match 
for 'schlagzei...@newsletter.mallorcazeitung.es'
Jun 07 14:32:10 mx1 opendkim[691]: 77BB2202612: key retrieval failed 
(s=s1, d=mg-esp-prod-eu-eu.mallorcazeitung.es): 
's1._domainkey.mg-esp-prod-eu-eu.mallorcazeitung.es' query timed out


A found an explanation for "shut down hung fetch" in your list archiv

"This usually means there's a circular dependency somewhere in the
resolution or validation process. For example, we can't resolve a name
without looking up the address of a name server, but that lookup can't
succeed until the original name is resolved. The two lookups will wait 
on
each other for ten seconds, and then the whole query times out and 
issues

that log message."

I'm trying to work around the problem by whitelisting the address in 
Spamassassin so it doesn't check against the DNS blocklists. But 
unfortunately that doesn't work at the moment.


nano /etc/spamassassin/local.cf
whitelist_from_rcvd schlagzei...@newsletter.mallorcazeitung.es  piano.io

Spamassassin Doc
"Use this (whitelist_from_rcvd) to supplement the whitelist_from 
addresses with a check against the Received headers. The first parameter 
is the address to whitelist, and the second is a string to match the 
relay's rDNS. "


In the header of the mail I find
Received: from mgptr-132-188.piano.io (mgptr-132-188.piano.io 
[159.135.132.188])

[...]
From: Mallorca Zeitung 

--
Visit https://lists.isc.org/mailman/listinfo/bind-users to unsubscribe from 
this list

ISC funds the development of this software with paid support subscriptions. 
Contact us at https://www.isc.org/contact/ for more information.


bind-users mailing list
bind-users@lists.isc.org
https://lists.isc.org/mailman/listinfo/bind-users

Re: Question on updating Turbine core

[Thomas Vandahl]

Hi Jeff,

> Am 05.06.2024 um 20:32 schrieb Jeffery Painter :
> 
> Hi Turbine devs,
> 
> I setup a new Ubuntu 24.0 server the other day for some testing, and realized 
> my apps would not load since by default, they have switched the packages from 
> Tomcat 9.x to Tomcat 10.x. Should we plan to update the Turbine servlet 
> packages to move to the jakarta.* packages instead of javax.servlet ?
> 
+1 to going for Jakarta. After all, this is where we came from :-)

> I'm not sure what other components might be affected (fulcrum or torque) and 
> also require some updates.
> 
At least all components which fulfill web tasks (parser, intake, localization?) 
Torque should not be affected AFAICT.

Bye, Thomas 
-
To unsubscribe, e-mail: dev-unsubscr...@turbine.apache.org
For additional commands, e-mail: dev-h...@turbine.apache.org

Bug#1072746: bullseye-pu: package pyroute2/0.5.14-2

[Thomas Goirand]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pyrou...@packages.debian.org
Control: affects -1 + src:pyroute2

Hi team!

[ Reason ]

Since the last (security) update of the Linux kernel, Bullseye
is affected by this bug:

https://bugs.launchpad.net/nova/+bug/2048097

Concretly, if one tries to (cold) migrate an OpenStack VM from
one compute node to another, Nova fails to unplug the VM's port
bridge(s) after the cold migration, when doing:

"openstack resize confirm "

This is due to this Kernel patch:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a6cec0bcd34264be8887791594be793b3f12719f

This was patch later in pyroute2 upstream with this patch:
https://github.com/svinota/pyroute2/commit/1eb08312de30a083bcfddfaa9c1d5e124b6368df#diff-e412e6093798df68279c3c7a0887cd91baef4d17a58c2bcfe10263f1e1c29ef0R803

that I have backported to pyroute2 0.5.14 (see attachment).

[ Impact ]
If one tries to migrate an OpenStack VM, it fails, and the
OpenStack compute node falls into a very bad state that is
hardly recoverable: one needs to upgrade to the version
of pyroute2 that I'm hereby proposing, manually delete all qbr
bridges and TAP interface manually (otherwise, nova-compute
refuses to start). This is very hard to find out, as nova
doesn't produce any log in this situation.

[ Tests ]
We've put the new version of pyroute2 that I'm proposing in
production, and we've been able to do (cold) migrations.

[ Risks ]
I have to admit I don't really understand what's going on
bellow, though we're back to a working production system,
so I believe the fix is working.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
Backport of the upstream fix as per attachment.

Since the kernel is already available, and our users
may upgrade to it and fall into this bad situation, it's
IMO important that we proceed with this fix ASAP.

Cheers,

Thomas Goirand (zigo)
diff -Nru pyroute2-0.5.14/debian/changelog pyroute2-0.5.14/debian/changelog
--- pyroute2-0.5.14/debian/changelog2020-10-13 14:31:06.0 +0200
+++ pyroute2-0.5.14/debian/changelog2024-06-07 12:06:04.0 +0200
@@ -1,3 +1,9 @@
+pyroute2 (0.5.14-2+deb11u1) bullseye; urgency=medium
+
+  * Add iproute-linux_try-to-improve-flags-when-sending-del-messages.patch.
+
+ -- Thomas Goirand   Fri, 07 Jun 2024 12:06:04 +0200
+
 pyroute2 (0.5.14-2) unstable; urgency=medium
 
   * Uploading to unstable.
diff -Nru 
pyroute2-0.5.14/debian/patches/iproute-linux_try-to-improve-flags-when-sending-del-messages.patch
 
pyroute2-0.5.14/debian/patches/iproute-linux_try-to-improve-flags-when-sending-del-messages.patch
--- 
pyroute2-0.5.14/debian/patches/iproute-linux_try-to-improve-flags-when-sending-del-messages.patch
   1970-01-01 01:00:00.0 +0100
+++ 
pyroute2-0.5.14/debian/patches/iproute-linux_try-to-improve-flags-when-sending-del-messages.patch
   2024-06-07 12:06:04.0 +0200
@@ -0,0 +1,116 @@
+Description: iproute/linux: try to improve flags when sending del messages 
+ This is a backport of this patch:
+  
https://github.com/svinota/pyroute2/commit/1eb08312de30a083bcfddfaa9c1d5e124b6368df#diff-e412e6093798df68279c3c7a0887cd91baef4d17a58c2bcfe10263f1e1c29ef0R803
+ to version 0.5.14 of pyroute2.
+Author: Thomas Goirand 
+Origin: upstream, 
https://github.com/svinota/pyroute2/commit/1eb08312de30a083bcfddfaa9c1d5e124b6368df#diff-e412e6093798df68279c3c7a0887cd91baef4d17a58c2bcfe10263f1e1c29ef0R803
+Last-Update: 2024-06-07
+
+--- pyroute2-0.5.14.orig/pyroute2/iproute/linux.py
 pyroute2-0.5.14/pyroute2/iproute/linux.py
+@@ -561,7 +561,7 @@ class RTNL_API(object):
+ # flush all addresses with IFA_LABEL='eth0':
+ ipr.flush_addr(label='eth0')
+ '''
+-flags = NLM_F_CREATE | NLM_F_EXCL | NLM_F_REQUEST
++flags = NLM_F_CREATE | NLM_F_REQUEST
+ ret = []
+ for addr in self.get_addr(*argv, **kwarg):
+ self.put(addr, msg_type=RTM_DELADDR, msg_flags=flags)
+@@ -582,7 +582,7 @@ class RTNL_API(object):
+ # flush all IPv6 rules that point to table 250:
+ ipr.flush_rules(family=socket.AF_INET6, table=250)
+ '''
+-flags = NLM_F_CREATE | NLM_F_EXCL | NLM_F_REQUEST
++flags = NLM_F_CREATE | NLM_F_REQUEST
+ ret = []
+ for rule in self.get_rules(*argv, **kwarg):
+ self.put(rule, msg_type=RTM_DELRULE, msg_flags=flags)
+@@ -936,9 +936,9 @@ class RTNL_API(object):
+ 'set': (RTM_NEWNEIGH, flags_replace),
+ 'replace': (RTM_NEWNEIGH, flags_replace),
+ 'change': (RTM_NEWNEIGH, flags_change),
+-'del': (RTM_DELNEIGH, flags_make),
+- 

Bug#1072746: bullseye-pu: package pyroute2/0.5.14-2

[Thomas Goirand]

Package: release.debian.org
Severity: normal
Tags: bullseye
User: release.debian@packages.debian.org
Usertags: pu
X-Debbugs-Cc: pyrou...@packages.debian.org
Control: affects -1 + src:pyroute2

Hi team!

[ Reason ]

Since the last (security) update of the Linux kernel, Bullseye
is affected by this bug:

https://bugs.launchpad.net/nova/+bug/2048097

Concretly, if one tries to (cold) migrate an OpenStack VM from
one compute node to another, Nova fails to unplug the VM's port
bridge(s) after the cold migration, when doing:

"openstack resize confirm "

This is due to this Kernel patch:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=a6cec0bcd34264be8887791594be793b3f12719f

This was patch later in pyroute2 upstream with this patch:
https://github.com/svinota/pyroute2/commit/1eb08312de30a083bcfddfaa9c1d5e124b6368df#diff-e412e6093798df68279c3c7a0887cd91baef4d17a58c2bcfe10263f1e1c29ef0R803

that I have backported to pyroute2 0.5.14 (see attachment).

[ Impact ]
If one tries to migrate an OpenStack VM, it fails, and the
OpenStack compute node falls into a very bad state that is
hardly recoverable: one needs to upgrade to the version
of pyroute2 that I'm hereby proposing, manually delete all qbr
bridges and TAP interface manually (otherwise, nova-compute
refuses to start). This is very hard to find out, as nova
doesn't produce any log in this situation.

[ Tests ]
We've put the new version of pyroute2 that I'm proposing in
production, and we've been able to do (cold) migrations.

[ Risks ]
I have to admit I don't really understand what's going on
bellow, though we're back to a working production system,
so I believe the fix is working.

[ Checklist ]
  [x] *all* changes are documented in the d/changelog
  [x] I reviewed all changes and I approve them
  [x] attach debdiff against the package in (old)stable
  [x] the issue is verified as fixed in unstable

[ Changes ]
Backport of the upstream fix as per attachment.

Since the kernel is already available, and our users
may upgrade to it and fall into this bad situation, it's
IMO important that we proceed with this fix ASAP.

Cheers,

Thomas Goirand (zigo)
diff -Nru pyroute2-0.5.14/debian/changelog pyroute2-0.5.14/debian/changelog
--- pyroute2-0.5.14/debian/changelog2020-10-13 14:31:06.0 +0200
+++ pyroute2-0.5.14/debian/changelog2024-06-07 12:06:04.0 +0200
@@ -1,3 +1,9 @@
+pyroute2 (0.5.14-2+deb11u1) bullseye; urgency=medium
+
+  * Add iproute-linux_try-to-improve-flags-when-sending-del-messages.patch.
+
+ -- Thomas Goirand   Fri, 07 Jun 2024 12:06:04 +0200
+
 pyroute2 (0.5.14-2) unstable; urgency=medium
 
   * Uploading to unstable.
diff -Nru 
pyroute2-0.5.14/debian/patches/iproute-linux_try-to-improve-flags-when-sending-del-messages.patch
 
pyroute2-0.5.14/debian/patches/iproute-linux_try-to-improve-flags-when-sending-del-messages.patch
--- 
pyroute2-0.5.14/debian/patches/iproute-linux_try-to-improve-flags-when-sending-del-messages.patch
   1970-01-01 01:00:00.0 +0100
+++ 
pyroute2-0.5.14/debian/patches/iproute-linux_try-to-improve-flags-when-sending-del-messages.patch
   2024-06-07 12:06:04.0 +0200
@@ -0,0 +1,116 @@
+Description: iproute/linux: try to improve flags when sending del messages 
+ This is a backport of this patch:
+  
https://github.com/svinota/pyroute2/commit/1eb08312de30a083bcfddfaa9c1d5e124b6368df#diff-e412e6093798df68279c3c7a0887cd91baef4d17a58c2bcfe10263f1e1c29ef0R803
+ to version 0.5.14 of pyroute2.
+Author: Thomas Goirand 
+Origin: upstream, 
https://github.com/svinota/pyroute2/commit/1eb08312de30a083bcfddfaa9c1d5e124b6368df#diff-e412e6093798df68279c3c7a0887cd91baef4d17a58c2bcfe10263f1e1c29ef0R803
+Last-Update: 2024-06-07
+
+--- pyroute2-0.5.14.orig/pyroute2/iproute/linux.py
 pyroute2-0.5.14/pyroute2/iproute/linux.py
+@@ -561,7 +561,7 @@ class RTNL_API(object):
+ # flush all addresses with IFA_LABEL='eth0':
+ ipr.flush_addr(label='eth0')
+ '''
+-flags = NLM_F_CREATE | NLM_F_EXCL | NLM_F_REQUEST
++flags = NLM_F_CREATE | NLM_F_REQUEST
+ ret = []
+ for addr in self.get_addr(*argv, **kwarg):
+ self.put(addr, msg_type=RTM_DELADDR, msg_flags=flags)
+@@ -582,7 +582,7 @@ class RTNL_API(object):
+ # flush all IPv6 rules that point to table 250:
+ ipr.flush_rules(family=socket.AF_INET6, table=250)
+ '''
+-flags = NLM_F_CREATE | NLM_F_EXCL | NLM_F_REQUEST
++flags = NLM_F_CREATE | NLM_F_REQUEST
+ ret = []
+ for rule in self.get_rules(*argv, **kwarg):
+ self.put(rule, msg_type=RTM_DELRULE, msg_flags=flags)
+@@ -936,9 +936,9 @@ class RTNL_API(object):
+ 'set': (RTM_NEWNEIGH, flags_replace),
+ 'replace': (RTM_NEWNEIGH, flags_replace),
+ 'change': (RTM_NEWNEIGH, flags_change),
+-'del': (RTM_DELNEIGH, flags_make),
+- 

Notes from Tomcat security day

[Mark Thomas]

Hi all,

I have added the notes from yesterday's security day to the wiki.

https://cwiki.apache.org/confluence/display/TOMCAT/Security+Day+EU+2024

We discussed lots of things and while there are quite a few things the 
folks present agreed would be worth doing, all the actaul decisions need 
to go through dev@ so expect some more threads like the ones Chris has 
already started.


I think I have transferred the notes correctly but feel free to edit the 
notes if I missed soemthing or got the notes wrong.


Cheers,

Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Implement additional security checks in SecurityLifecycleListener

[Mark Thomas]

On 06/06/2024 18:13, Konstantin Kolinko wrote:

чт, 6 июн. 2024 г. в 17:49, Christopher Schultz :


All,

Tomcat's SecurityLifecycleListener currently checks the current working
user's name, the umask and not much else at the moment.

I'd like to add "administrator" as another username to look for. (The
documentation says that "root" is the only current username checked.)

I would also like to add several items from the DISA STIG document found
here:
https://www.stigviewer.com/stig/apache_tomcat_application_sever_9/2021-12-27/

I haven't decided exactly which items to implement, but I will probably
do this as a PR with separate commits for each item.

Are there any objections to be starting this work?


1. Generally, the checks (including the 3 already implemented) are of
an "audit" kind.

An "audit" is something that produces a report.

I wonder whether a listener that operates on a "before init" event is
a good technology for those checks.

Whether it is a good entry point, whether it produces a visible
report, whether it can be run regularly.

Whether it is worth delaying start time to make those checks.

In the case of an "umask" check we already depend on a "3rd party": on
a feature of our startup scripts.

2. Requirements and implementation details depend on an operating system.


This got me wondering if we might want general checks and OS specific 
checks and whether that had any impact on implementation.


Mark

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Tomcat 10: Remove CGI Servlet

[Mark Thomas]

On 06/06/2024 16:39, Christopher Schultz wrote:

All,

Resurrecting this thread from 2019.

I will be proceeding with this 4.5-year-old plan to extract the CGI 
servlet to a separate JAR file to make it easy to "remove" from Tomcat 
if operators would prefer to do such things.


I think I'll also move the configuration from conf/web.xml to 
webapps/docs/cgi-howto.html while I'm at it so those vestiges are gone.


+1

Mark




Thanks,
-chris

On 10/28/19 09:55, Christopher Schultz wrote:

All,

Note: this was not a vote.

There was very little feedback, and responses were mixed. We got
exactly one response on the users@ list about real-world usage of CGI,
so we cannot draw any conclusions about real-world uses.

Otherwise, the consensus seems to be that CGIs should stay a part of
the main Tomcat distribution, but that perhaps separating it out into
a distinct JAR file and/or separate distribution might be advantageous.

It appears that the CGIServlet is completely self-contained. It makes
use of the following internal(ish) Tomcat APIs:

org.apache.catalina.util.IOTools
org.apache.juli.logging.Log
org.apache.juli.logging.LogFactory
org.apache.tomcat.util.compat.JrePlatform
org.apache.tomcat.util.res.StringManager

All of these could be replaced if necessary to make a standalone,
container-agnostic package.

It looks like it would be fairly easy to separate-out the CGIServlet
into a separate JAR file packaging if there's utility in that. For
example, security-conscious environments may want to remove that JAR
file entirely from the Tomcat deployment to be absolutely sure that
Runtime.exec() isn't available in the deployed Java code (from the
container; yet I realize that SSIServlet/SSIFilter has this, too).

I'd like to go ahead and move the CGIServlet from the general
catalina.jar file into catalina-cgi.jar. That should only require a
small change to the build.xml script.

Any objections?

-chris

On 10/7/19 10:59, Christopher Schultz wrote:

All,



I recently gave a presentation on locking-down Apache Tomcat[1] and
I briefly discussed the "sharp edges" present in Tomcat. Some of
them are unnecessarily sharp and may be actually unnecessary. I'm
going to make a few proposals to remove functions from Tomcat.



Proposal: Remove CGI Servlet



Justification:



The CGIServlet is another component, like server-side-includes,
which is a remote-code execution (RCE) vulnerability as a feature.
It is very easy to misconfigure. It is arguably not possible to
secure it on Windows[2]. There are better solutions if you want to
run Perl, Python, PHP, or whatever on your server in the form of
the many fine web-server products out there.



-chris




[1]
http://tomcat.apache.org/presentations.html#latest-locking-down-tomc



at

[2]
https://blogs.msdn.microsoft.com/twistylittlepassagesallalike/2011/04/

23


/everyone-quotes-command-line-arguments-the-wrong-way/



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

Re: [PROPOSAL] Tomcat 10: Remove Server-Side Includes (SSI)

[Mark Thomas]

On 06/06/2024 16:30, Christopher Schultz wrote:

All,

Resurrecting this thread from 2019.

I'd like to remove the SSI configuration from conf/web.xml and put it 
into webapps/docs/ssi-howto.html.


Are there any objections?


None here.

Do we want to go further and consider removing it entirely for Tomcat 12 
onwards. Maybe a question for the users list?


Mark



Thanks,
-chris

On 10/29/19 05:05, Konstantin Kolinko wrote:
пн, 28 окт. 2019 г. в 16:34, Christopher Schultz 
:


[...]

The stock conf/web.xml contains a sample configuration for the SSI
servlet. We will have to decide what to do with that. I can think of
at least two options:

   a. Remove it from the stock conf/web.xml entirely
   b. Add comments to conf/web.xml indicating that the SSI component is
a separate download

I think I like #2 better.


The correct way to enable this feature is to copy those fragments into
one's own WEB-INF/web.xml.  Uncommenting them in the default web.xml
file will have [un]expected consequences.

Thus I am in favor of moving those configuration fragments to 
documentation.


Best regards,
Konstantin Kolinko

-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org



-
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org

[gentoo-commits] repo/gentoo:master commit in: media-radio/gpredict/

[Thomas Beierlein]

commit: bc59cfeb155f1279badf3be5cfe8451627e6720a
Author: Thomas Beierlein  gentoo  org>
AuthorDate: Fri Jun  7 07:27:57 2024 +
Commit:     Thomas Beierlein  gentoo  org>
CommitDate: Fri Jun  7 07:30:03 2024 +
URL:https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=bc59cfeb

media-radio/gpredict: add 2.3_p20231224, 

Signed-off-by: Thomas Beierlein  gentoo.org>

 media-radio/gpredict/Manifest  |  1 +
 media-radio/gpredict/gpredict-2.3_p20231224.ebuild | 49 ++
 media-radio/gpredict/gpredict-.ebuild  | 49 ++
 3 files changed, 99 insertions(+)

diff --git a/media-radio/gpredict/Manifest b/media-radio/gpredict/Manifest
index a2caf4e561f8..91ae4a91c101 100644
--- a/media-radio/gpredict/Manifest
+++ b/media-radio/gpredict/Manifest
@@ -1 +1,2 @@
 DIST gpredict-2.3.tar.gz 7742902 BLAKE2B 
1ff567871838b062c59ab0076330a354afee082506044f5ce2ae1c7553e7f3462770f7134d13e3b603f7966476d13b365dd3575cc6c7e32d23865ba29b602cc9
 SHA512 
d7434aff482c943951a79cb607c91f118cfbde8209b4b370d0d2147766244fab2839b5c712864c2c521635f31c484ef2bfd3c771371e946f5a3561801ab474b5
+DIST gpredict-2.3_p20231224.tar.gz 7719540 BLAKE2B 
3febc18a5e69075b8345b695f4286cefb5ee56ae14fee53ff0a3add729e7f03a42626b94bb51d09a8f792c7a8da46a697f0e9f98f6f5cd12a8080369bf2a131d
 SHA512 
e4299eb1b23629f08945a6b0ddfac2d6e78d3588297db441d0440ef714c4daf044fbacfb071c3b9c7f66227053ec27ae94f770f73ee3b352f820c959e657bb6a

diff --git a/media-radio/gpredict/gpredict-2.3_p20231224.ebuild 
b/media-radio/gpredict/gpredict-2.3_p20231224.ebuild
new file mode 100644
index ..2d7252dff97a
--- /dev/null
+++ b/media-radio/gpredict/gpredict-2.3_p20231224.ebuild
@@ -0,0 +1,49 @@
+# Copyright 1999-2024 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=8
+
+inherit autotools
+
+DESCRIPTION="Real-time satellite tracking and orbit prediction application"
+HOMEPAGE="http://gpredict.oz9aec.net;
+
+if [[ ${PV} = "" ]]; then
+   inherit git-r3
+   EGIT_REPO_URI="https://github.com/csete/gpredict.git;
+else
+   COMMIT="098e3768240c7f5a169930a2660a23c9f42b37d6"
+   SRC_URI="https://github.com/csete/gpredict/archive/${COMMIT}.tar.gz -> 
${P}.tar.gz"
+   S="${WORKDIR}/${PN}-${COMMIT}"
+   KEYWORDS="~amd64 ~ppc ~x86"
+fi
+
+LICENSE="GPL-2"
+SLOT="0"
+
+RDEPEND="dev-libs/glib:2
+   x11-libs/gdk-pixbuf[jpeg]
+   x11-libs/gtk+:3
+   x11-libs/goocanvas:2.0
+   net-misc/curl"
+DEPEND="${RDEPEND}"
+BDEPEND="dev-util/intltool
+   sys-devel/gettext
+   virtual/pkgconfig"
+
+DOCS=( AUTHORS NEWS README )
+
+PATCHES=(
+   # remove wrong doc location
+   "${FILESDIR}/${PN}-2.3-doc.patch"
+   "${FILESDIR}/${PN}-2.3-gethostbyname.patch"
+)
+
+src_prepare() {
+   default
+   # prepare Version info
+   if [[ ${PV} != "" ]]; then
+   echo "${PV}" > "${S}"/.tarball-version
+   fi
+   eautoreconf
+}

diff --git a/media-radio/gpredict/gpredict-.ebuild 
b/media-radio/gpredict/gpredict-.ebuild
new file mode 100644
index ..2d7252dff97a
--- /dev/null
+++ b/media-radio/gpredict/gpredict-.ebuild
@@ -0,0 +1,49 @@
+# Copyright 1999-2024 Gentoo Authors
+# Distributed under the terms of the GNU General Public License v2
+
+EAPI=8
+
+inherit autotools
+
+DESCRIPTION="Real-time satellite tracking and orbit prediction application"
+HOMEPAGE="http://gpredict.oz9aec.net;
+
+if [[ ${PV} = "" ]]; then
+   inherit git-r3
+   EGIT_REPO_URI="https://github.com/csete/gpredict.git;
+else
+   COMMIT="098e3768240c7f5a169930a2660a23c9f42b37d6"
+   SRC_URI="https://github.com/csete/gpredict/archive/${COMMIT}.tar.gz -> 
${P}.tar.gz"
+   S="${WORKDIR}/${PN}-${COMMIT}"
+   KEYWORDS="~amd64 ~ppc ~x86"
+fi
+
+LICENSE="GPL-2"
+SLOT="0"
+
+RDEPEND="dev-libs/glib:2
+   x11-libs/gdk-pixbuf[jpeg]
+   x11-libs/gtk+:3
+   x11-libs/goocanvas:2.0
+   net-misc/curl"
+DEPEND="${RDEPEND}"
+BDEPEND="dev-util/intltool
+   sys-devel/gettext
+   virtual/pkgconfig"
+
+DOCS=( AUTHORS NEWS README )
+
+PATCHES=(
+   # remove wrong doc location
+   "${FILESDIR}/${PN}-2.3-doc.patch"
+   "${FILESDIR}/${PN}-2.3-gethostbyname.patch"
+)
+
+src_prepare() {
+   default
+   # prepare Version info
+   if [[ ${PV} != "" ]]; then
+   echo "${PV}" > "${S}"/.tarball-version
+   fi
+   eautoreconf
+}

Re: [Patch, Fortran/90068] Add finalizer creation to array constructor for functions of derived type.

[Paul Richard Thomas]

Hi Andre,

I had been working in exactly the same area to correct the implementation
of finalization of function results in array constructors. However, I
couldn't see a light way of having the finalization occur at the correct
time; "If an executable construct references a nonpointer function, the
result is finalized after execution of the innermost executable construct
containing the reference." This caused all manner of difficulty with
assignment. I'll come back to this.

In the meantime, preventing memory leaks should take priority. This is fine
for mainline.

Thanks

Paul


On Wed, 5 Jun 2024 at 10:47, Andre Vehreschild  wrote:

> Hi Fortraneers,
>
> another patch to fix a memory leak. This time temporaries created during an
> array construction did not have their finalizers called. I.e. allocated
> memory
> was not freed. The attached patch addresses this issue.
>
> Regtested ok on x86_64/Fedora 39. Ok for trunk?
>
> Regards,
> Andre
> --
> Andre Vehreschild * Email: vehre ad gmx dot de
>

Re: [Patch, Fortran/90068] Add finalizer creation to array constructor for functions of derived type.

[Paul Richard Thomas]

Hi Andre,

I had been working in exactly the same area to correct the implementation
of finalization of function results in array constructors. However, I
couldn't see a light way of having the finalization occur at the correct
time; "If an executable construct references a nonpointer function, the
result is finalized after execution of the innermost executable construct
containing the reference." This caused all manner of difficulty with
assignment. I'll come back to this.

In the meantime, preventing memory leaks should take priority. This is fine
for mainline.

Thanks

Paul


On Wed, 5 Jun 2024 at 10:47, Andre Vehreschild  wrote:

> Hi Fortraneers,
>
> another patch to fix a memory leak. This time temporaries created during an
> array construction did not have their finalizers called. I.e. allocated
> memory
> was not freed. The attached patch addresses this issue.
>
> Regtested ok on x86_64/Fedora 39. Ok for trunk?
>
> Regards,
> Andre
> --
> Andre Vehreschild * Email: vehre ad gmx dot de
>

Re: [Patch, PR Fortran/90072] Polymorphic Dispatch to Polymophic Return Type Memory Leak

[Paul Richard Thomas]

Hi Andre,

I apologise for the slow response. It's been something of a heavy week...

This is good for mainline.

Thanks

Paul

PS That's good news about the funding. Maybe we will get to see "built in"
coarrays soon?


On Tue, 4 Jun 2024 at 11:25, Andre Vehreschild  wrote:

> Hi all,
>
> attached patch fixes a memory leak when a user-defined function returns a
> polymorphic type/class. The issue was, that the polymorphic type was not
> detected correctly and therefore the len-field was not transferred
> correctly.
>
> Regtests ok x86_64-linux/Fedora 39. Ok for master?
>
> Regards,
> Andre
> --
> Andre Vehreschild * Email: vehre ad gmx dot de
>

Re: [Patch, PR Fortran/90072] Polymorphic Dispatch to Polymophic Return Type Memory Leak

[Paul Richard Thomas]

Hi Andre,

I apologise for the slow response. It's been something of a heavy week...

This is good for mainline.

Thanks

Paul

PS That's good news about the funding. Maybe we will get to see "built in"
coarrays soon?


On Tue, 4 Jun 2024 at 11:25, Andre Vehreschild  wrote:

> Hi all,
>
> attached patch fixes a memory leak when a user-defined function returns a
> polymorphic type/class. The issue was, that the polymorphic type was not
> detected correctly and therefore the len-field was not transferred
> correctly.
>
> Regtests ok x86_64-linux/Fedora 39. Ok for master?
>
> Regards,
> Andre
> --
> Andre Vehreschild * Email: vehre ad gmx dot de
>

Re: [PATCH 0/5] s390x: Add Full Boot Order Support

[Thomas Huth]

On 06/06/2024 21.22, Jared Rossi wrote:



On 6/5/24 4:02 AM, Thomas Huth wrote:

On 29/05/2024 17.43, jro...@linux.ibm.com wrote:

From: Jared Rossi 

This patch set primarily adds support for the specification of multiple boot
devices, allowing for the guest to automatically use an alternative 
device on
a failed boot without needing to be reconfigured. It additionally 
provides the

ability to define the loadparm attribute on a per-device bases, which allows
boot devices to use different loadparm values if needed.

In brief, an IPLB is generated for each designated boot device (up to a 
maximum
of 8) and stored in guest memory immediately before BIOS. If a device 
fails to

boot, the next IPLB is retrieved and we jump back to the start of BIOS.

Devices can be specified using the standard qemu device tag "bootindex" 
as with
other architectures. Lower number indices are tried first, with 
"bootindex=0"

indicating the first device to try.


Is this supposed with multiple scsi-hd devices, too? I tried to boot a 
guest with two scsi disks (attached to a single virtio-scsi-ccw adapter) 
where only the second disk had a bootable installation, but that failed...?


 Thomas




Hi Thomas,

Yes, I would expect that to work. I tried to reproduce this using a 
non-bootable scsi disk as the first boot device and then a known-good 
bootable scsi disk as the second boot device, with one controller.  In my 
instance the BIOS was not able to identify the first disk as bootable and so 
that device failed to IPL, but it did move on to the next disk after that, 
and the guest successfully IPL'd from the second device.


When you say it failed, do you mean the first disk failed to boot (as 
expected), but then the guest died without attempting to boot from the 
second disk?  Or did something else happen? I am either not understanding 
your configuration or I am not understanding your error.


I did this:

 $ ./qemu-system-s390x -bios pc-bios/s390-ccw/s390-ccw.img -accel kvm \
   -device virtio-scsi-ccw  -drive if=none,id=d2,file=/tmp/bad.qcow2 \
   -device scsi-hd,drive=d2,bootindex=2 \
   -drive if=none,id=d8,file=/tmp/good.qcow2 \
   -device scsi-hd,drive=d8,bootindex=3 -m 4G -nographic
 LOADPARM=[]
 Using virtio-scsi.
 Using guessed DASD geometry.
 Using ECKD scheme (block size   512), CDL
 No zIPL section in IPL2 record.
 zIPL load failed.

 Trying next boot device...
 LOADPARM=[]
 Using virtio-scsi.
 Using guessed DASD geometry.
 Using ECKD scheme (block size   512), CDL
 No zIPL section in IPL2 record.
 zIPL load failed.

So it claims to try to load from the second disk, but it fails.
If I change the "bootindex=3" of the second disk to "bootindex=1", it boots 
perfectly fine, so I'm sure that the installation on good.qcow2 is working fine.


 Thomas

Re: [PATCH 3/5] s390x: Build IPLB chain for multiple boot devices

[Thomas Huth]

On 05/06/2024 22.01, Jared Rossi wrote:


On 6/4/24 2:26 PM, Thomas Huth wrote:

On 29/05/2024 17.43, jro...@linux.ibm.com wrote:

From: Jared Rossi 

Write a chain of IPLBs into memory for future use.

The IPLB chain is placed immediately before the BIOS in memory at the 
highest
unused page boundary providing sufficient space to fit the chain. Because 
this
is not a fixed address, the location of the next IPLB and number of 
remaining

boot devices is stored in the QIPL global variable for later access.

At this stage the IPLB chain is not accessed by the guest during IPL.

Signed-off-by: Jared Rossi 
---
  hw/s390x/ipl.h  |   1 +
  include/hw/s390x/ipl/qipl.h |   4 +-
  hw/s390x/ipl.c  | 129 +++-
  3 files changed, 103 insertions(+), 31 deletions(-)

diff --git a/hw/s390x/ipl.h b/hw/s390x/ipl.h
index 1dcb8984bb..4f098d3a81 100644
--- a/hw/s390x/ipl.h
+++ b/hw/s390x/ipl.h
@@ -20,6 +20,7 @@
  #include "qom/object.h"
    #define DIAG308_FLAGS_LP_VALID 0x80
+#define MAX_IPLB_CHAIN 7
    void s390_ipl_set_loadparm(char *ascii_lp, uint8_t *ebcdic_lp);
  void s390_ipl_fmt_loadparm(uint8_t *loadparm, char *str, Error **errp);
diff --git a/include/hw/s390x/ipl/qipl.h b/include/hw/s390x/ipl/qipl.h
index a6ce6ddfe3..481c459a53 100644
--- a/include/hw/s390x/ipl/qipl.h
+++ b/include/hw/s390x/ipl/qipl.h
@@ -34,7 +34,9 @@ struct QemuIplParameters {
  uint8_t  reserved1[3];
  uint64_t netboot_start_addr;
  uint32_t boot_menu_timeout;
-    uint8_t  reserved2[12];
+    uint8_t  reserved2[2];
+    uint16_t num_iplbs;
+    uint64_t next_iplb;
  }  QEMU_PACKED;
  typedef struct QemuIplParameters QemuIplParameters;
  diff --git a/hw/s390x/ipl.c b/hw/s390x/ipl.c
index 2d4f5152b3..79429acabd 100644
--- a/hw/s390x/ipl.c
+++ b/hw/s390x/ipl.c
@@ -55,6 +55,13 @@ static bool iplb_extended_needed(void *opaque)
  return ipl->iplbext_migration;
  }
  +/* Start IPLB chain from the boundary of the first unused page before 
BIOS */


I'd maybe say "upper boundary" to make it clear that this is at the end of 
the page, not at the beginning?


The chain does start at the beginning of a page.  That being said, the 
comment still needs to be reworded, I'm just not sure exactly how. "Start 
the IPLB chain from the nearest page boundary providing sufficient space 
before BIOS?"  Basically because each IPLB is 4K, the chain will occupy the 
N unused pages before the start of BIOS, where N is the number of chained 
IPLBS (assuming 4K pages).


Ah, right, I missed that sizeof(IplParameterBlock) == 4096 (I guess I was 
looking at the old version in pc-bios/s390-ccw/iplb.h that does not seem to 
have the padding), sorry for the confusion! It's really good that you now 
unify the headers in your first patch!


 Thomas

Re: RFR: 8332400: isspace argument should be a valid unsigned char

[Thomas Stuefe]

On Thu, 6 Jun 2024 21:21:23 GMT, David Holmes  wrote:

>> ### Summary
>> This change ensures we don't get undefined behavior when 
>> calling[`isspace`](https://pubs.opengroup.org/onlinepubs/007904975/functions/isspace.html).
>>   `isspace` accepts an `int` argument that "the application shall ensure is 
>> a character representable as an unsigned char or equal to the value of the 
>> macro EOF.". 
>> 
>> Previously, there was no checking of the values passed to `isspace`. I've 
>> replaced direct calls with a new wrapper `os::is_space` that performs a 
>> range check and prevents the possibility of undefined behavior from 
>> happening. For instances outside of Hotspot, I've added casts to `unsigned 
>> char`. 
>> 
>> **Testing**
>> - Added a new test in `test/hotspot/gtest/runtime/test_os.cpp` to check 
>> `os::is_space` is working correctly.
>> - tier1
>
> Sorry I think this is well-intentioned but unnecessary in nearly all cases. 
> If you pass a char there is no potential problem. Only passing an actual int 
> could be a problem.

@dholmes-ora 

> Sorry I think this is well-intentioned but unnecessary in nearly all cases. 
> If you pass a char there is no potential problem. Only passing an actual int 
> could be a problem.

Note that the issue was motivated by an Oracle engineer complaining about me 
using isspace on a char. That caused me to look up its behavior. Recently, we 
seem intent on eliminating UB, so why not.

That said, I agree that we probably don't need the wrapper. And casting to int 
feels awkward. I propose
- input from trusted sources, e.g. proc fs, don't need casting
- input from other sources should be casted to unsigned char (see 
recommendation here: https://en.cppreference.com/w/cpp/string/byte/isspace "To 
use these functions safely with plain chars (or signed chars), the argument 
should first be converted to unsigned char")

-

PR Comment: https://git.openjdk.org/jdk/pull/19567#issuecomment-2154146793