[Issue 8 drafts 0001800]: be*toh() have no entries

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been UPDATED. 
== 
https://austingroupbugs.net/view.php?id=1800 
== 
Reported By:steffen
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1800
Category:   Base Definitions and Headers
Type:   Error
Severity:   Editorial
Priority:   normal
Status: New
Name:   steffen 
Organization:
User Reference:  
Section:system interfaces 
Page Number: 
Line Number: 
Final Accepted Text: 
== 
Date Submitted: 2024-01-23 22:36 UTC
Last Modified:  2024-01-26 09:56 UTC
== 
Summary:be*toh() have no entries
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-01-23 22:36 steffenNew Issue
2024-01-23 22:36 steffenName  => steffen 
2024-01-23 22:36 steffenSection   => system interfaces
2024-01-25 10:06 geoffclare Note Added: 0006639  
2024-01-25 21:29 steffenNote Added: 0006640  
2024-01-25 21:34 steffenNote Added: 0006641  
2024-01-26 09:54 geoffclare Note Added: 0006644  
2024-01-26 09:55 geoffclare Note Edited: 0006644 
2024-01-26 09:56 geoffclare version   => Draft 4 
==

[Issue 8 drafts 0001800]: be*toh() have no entries

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1800 
== 
Reported By:steffen
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1800
Category:   Base Definitions and Headers
Type:   Error
Severity:   Editorial
Priority:   normal
Status: New
Name:   steffen 
Organization:
User Reference:  
Section:system interfaces 
Page Number: 
Line Number: 
Final Accepted Text: 
== 
Date Submitted: 2024-01-23 22:36 UTC
Last Modified:  2024-01-26 09:54 UTC
== 
Summary:be*toh() have no entries
== 

-- 
 (0006644) geoffclare (manager) - 2024-01-26 09:54
 https://austingroupbugs.net/view.php?id=1800#c6644 
-- 
Suggested changes...

On page 660 line 23128-23139 section be16toh() SYNOPSIS, re-sort the lines
into alphabetic order (to match the NAME section), grouped as follows:

be*toh()
blank line
htobe*()
blank line
htole*()
blank line
le*toh()

Cross-volume changes to XBD...

On page 240 line 8454-8465 section , re-sort the lines containing
function prototypes into the same order and grouping as above.

Since these are purely editorial changes they can probably be made in Issue
8 despite not meeting the narrowing-down rules for draft 4 review. (The
alternative being to wait for TC1.) 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-01-23 22:36 steffenNew Issue
2024-01-23 22:36 steffenName  => steffen 
2024-01-23 22:36 steffenSection   => system interfaces
2024-01-25 10:06 geoffclare Note Added: 0006639  
2024-01-25 21:29 steffenNote Added: 0006640  
2024-01-25 21:34 steffenNote Added: 0006641  
2024-01-26 09:54 geoffclare Note Added: 0006644  
==

[Online Pubs 0001803]: Many non-ASCII characters display incorrectly

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://www.austingroupbugs.net/view.php?id=1803 
== 
Reported By:larryv
Assigned To:
== 
Project:Online Pubs
Issue ID:   1803
Category:   Frontmatter
Type:   Error
Severity:   Editorial
Priority:   normal
Status: New
Name:   Lawrence Velázquez 
Organization:
User Reference:  
URL:   
https://pubs.opengroup.org/onlinepubs/9699919799/frontmatter/participants.html 
Section:Participants 
== 
Date Submitted: 2024-01-26 02:12 UTC
Last Modified:  2024-01-26 04:15 UTC
== 
Summary:Many non-ASCII characters display incorrectly
== 

-- 
 (0006643) larryv (reporter) - 2024-01-26 04:15
 https://www.austingroupbugs.net/view.php?id=1803#c6643 
-- 
Sorry again, I missed one instance that only appears on the 2016 page:

Change all instances of:Paul
Houz�to:Paul Houzé 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-01-26 02:12 larryv New Issue
2024-01-26 02:12 larryv Name  => Lawrence Velázquez
2024-01-26 02:12 larryv URL   =>
https://pubs.opengroup.org/onlinepubs/9699919799/frontmatter/participants.html
2024-01-26 02:12 larryv Section   => Participants
2024-01-26 02:20 larryv Note Added: 0006642  
2024-01-26 02:21 larryv Note Edited: 0006642 
2024-01-26 04:15 larryv Note Added: 0006643  
==

[Online Pubs 0001803]: Many non-ASCII characters display incorrectly

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been SUBMITTED. 
== 
https://www.austingroupbugs.net/view.php?id=1803 
== 
Reported By:larryv
Assigned To:
== 
Project:Online Pubs
Issue ID:   1803
Category:   Frontmatter
Type:   Error
Severity:   Editorial
Priority:   normal
Status: New
Name:   Lawrence Velázquez 
Organization:
User Reference:  
URL:   
https://pubs.opengroup.org/onlinepubs/9699919799/frontmatter/participants.html 
Section:Participants 
== 
Date Submitted: 2024-01-26 02:12 UTC
Last Modified:  2024-01-26 02:12 UTC
== 
Summary:Many non-ASCII characters display incorrectly
Description: 
Many (but not all) non-ASCII characters are rendered as "" (in the
browsers I am using, at least).  These seem to be encoded as ISO 8859 and
included in the HTML literally, rather than expressed with entity
references.

This issue also appears in the 2016 edition
(https://pubs.opengroup.org/onlinepubs/9699919799.2016edition/frontmatter/participants.html;)
but not the 2008
(https://pubs.opengroup.org/onlinepubs/9699919799.2008edition/frontmatter/participants.html;)
or 2013
(https://pubs.opengroup.org/onlinepubs/9699919799.2013edition/frontmatter/participants.html;)
editions.
Desired Action: 
Change all instances of:Pdraig
Bradyto:Pdraig Brady

Change all instances of:Vincent
Lefvreto:Vincent
Lefvre

Change all instances of:Vladimir Tmara
Patioto:Vladimir Tmara
Patio

Change all instances of:Martin
ehkto:Martin
ehk

Change all instances of:Jrg
Schillingto:Jrg Schilling

Change all instances of:Jrg
Wunschto:Jrg Wunsch

Change all instances of:Andr
Zepezauerto:Andr Zepezauer
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-01-26 02:12 larryv New Issue
2024-01-26 02:12 larryv Name  => Lawrence Velázquez
2024-01-26 02:12 larryv URL   =>
https://pubs.opengroup.org/onlinepubs/9699919799/frontmatter/participants.html
2024-01-26 02:12 larryv Section   => Participants
==

Re: Nginx-tests stream_ssl_conf_command.t test hanging indefinitely

[Mayerhofer, Austin via nginx-devel]

Hey Maxim,

Thanks, I installed homebrew’s Perl and all these tests are passing now, woohoo!

However a few others are failing now including ssl_ocsp.t and 
ssl_verify_depth.t, failing 13/17 and 3/11 tests respectively with the same 
error:

```
#   Failed test 'verify depth 2 - end'
#   at ssl_verify_depth.t line 169.
#   'HTTP/1.1 400 Bad Request
# Server: nginx/1.24.0
# Date: Fri, 26 Jan 2024 01:08:10 GMT
# Content-Type: text/html
# Content-Length: 215
# Connection: close
# X-Client: CN=end
# X-Verify: FAILED:unsuitable certificate purpose
#
# 
# 400 The SSL certificate error
# 
# 400 Bad Request
# The SSL certificate error
# nginx/1.24.0
# 
# 
# '
# doesn't match '(?^:SUCCESS)'
```

Originally the SSL tests were being skipped due to the absence of “socket_ssl”, 
so I had to manually install IO::Socket::SSL using cpan:

```
"Module" IO::Socket::SSL
*   "installed into:
/opt/homebrew/Cellar/perl/5.38.2_1/lib/perl5/site_perl/5.38"

*   "LINKTYPE: dynamic"

*   "VERSION: 2.085"

*   "EXE_FILES: "
```

Could the error above be another perl issue?


From: Mayerhofer, Austin 
Date: Thursday, January 25, 2024 at 10:24 AM
To: Sergey Kandaurov , nginx-devel@nginx.org 

Subject: Re: [EXTERNAL] Re: Nginx-tests stream_ssl_conf_command.t test hanging 
indefinitely
Hey Sergey,

Thanks for the help. I tried installing perl via homebrew but I ran into some 
dependency issues setting it up, and by the time I did set it up, it was 
skipping due to “# SKIP no http_ssl available”.

Is there a set of instructions or documentation for setting up a Mac 
environment for nginx-tests? I might be setting up perl wrong.

From: Sergey Kandaurov 
Date: Wednesday, January 24, 2024 at 2:59 PM
To: nginx-devel@nginx.org 
Cc: Mayerhofer, Austin 
Subject: [EXTERNAL] Re: Nginx-tests stream_ssl_conf_command.t test hanging 
indefinitely

> On 25 Jan 2024, at 01:15, Mayerhofer, Austin via nginx-devel 
>  wrote:
>
> Hi all,
>  Apologies if I sent this twice, I don’t think the first one went through 
> because I wasn’t subscribed to the list.
>  nginx-tests’ stream_ssl_conf_command.t is hanging for me and not running to 
> completion, I’m using the following configuration:
>  OS: MacOS 12.6.3
> Chip: Apple M1 Max
> NGINX: 1.24.0 built from source code with ./configure --with-debug 
> --with-http_ssl_module --with-http_stub_status_module --with-http_v2_module 
> --without-http_auth_basic_module --without-http_autoindex_module 
> --without-http_browser_module --without-http-cache 
> --without-http_charset_module --without-http_empty_gif_module 
> --without-http_fastcgi_module --without-http_grpc_module 
> --without-http_limit_conn_module --without-http_limit_req_module 
> --without-http_memcached_module --without-http_referer_module 
> --without-http_scgi_module --without-http_split_clients_module 
> --without-http_ssi_module --without-http_upstream_hash_module 
> --without-http_upstream_ip_hash_module 
> --without-http_upstream_least_conn_module --without-http_userid_module 
> --without-http_uwsgi_module --with-stream --with-stream_ssl_module 
> --with-stream_ssl_preread_module --without-stream_limit_conn_module 
> --without-stream_set_module --without-stream_split_clients_module 
> --without-stream_upstream_hash_module 
> --without-stream_upstream_least_conn_module 
> --without-stream_upstream_zone_module nginx-tests: 
> https://github.com/nginx/nginx-tests/tree/4c2ad8093952706f327d04887c5546bad91b75a6
>  When I run:
>  ```
> TEST_NGINX_BINARY=/usr/local/nginx/sbin/nginx prove -v 
> stream_ssl_conf_command.t
> ```
>  The output is:
>  ```
> stream_ssl_conf_command.t ..
> 1..5
> ok 1 - Certificate
> ok 2 - SessionTicket
> ok 3 – ServerPreference
> ```
>  And it hangs there.

Perl from macOS base system (/usr/bin/perl) is known to be buggy
for some unknown reason.  This is expressed in various hangs when
running nginx-tests.  I saw similar reports since at least macOS
12.3.1, and this is not caused by a particular Perl version (same
version from macports works for me).  You can try Perl from homebrew
or macports collections, it should work just fine.

--
Sergey Kandaurov


This message has been scanned for malware by Forcepoint. www.forcepoint.com
___
nginx-devel mailing list
nginx-devel@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-devel

[Issue 8 drafts 0001802]: Note missing paragraph break

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been SUBMITTED. 
== 
https://www.austingroupbugs.net/view.php?id=1802 
== 
Reported By:Don Cragun
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1802
Category:   System Interfaces
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: New
Name:   Don Cragun 
Organization:
User Reference:  
Section:be16toh 
Page Number:658 
Line Number:23123 
Final Accepted Text: 
== 
Date Submitted: 2024-01-26 00:13 UTC
Last Modified:  2024-01-26 00:13 UTC
== 
Summary:Note missing paragraph break
Description: 
The Note that appears on P658, L23123 is missing the normal paragraph break
and runs into the text on the line above.

This same problem appears on D4, P660, L23148.  Since there was no change
to this section between D3 and D4, a comment on this issue is inappropriate
in the ballots on D4.
Desired Action: 
Add a paragraph break between P658 L23122 and L23123.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-01-26 00:13 Don Cragun New Issue
2024-01-26 00:13 Don Cragun Name  => Don Cragun  
2024-01-26 00:13 Don Cragun Section   => be16toh 
2024-01-26 00:13 Don Cragun Page Number   => 658 
2024-01-26 00:13 Don Cragun Line Number   => 23123   
==

Re: nginx-tests SSL tests failing out of the box?

[Mayerhofer, Austin via nginx-devel]

Hey Andrey,

Thanks for the help. I rebuilt NGINX with OpenSSL 3.0.8 sources, but the same 
tests still fail. Here is the output of nginx configuration:

nginx version: nginx/1.24.0
built by clang 14.0.0 (clang-1400.0.29.202)
built with OpenSSL 3.0.8 7 Feb 2023
TLS SNI support enabled
configure arguments: --with-debug --with-http_ssl_module 
--with-openssl=

Are these SSL tests supposed to be failing with these configure arguments?

From: Andrey Kulikov 
Date: Thursday, January 25, 2024 at 11:53 AM
To: nginx-devel@nginx.org 
Cc: Mayerhofer, Austin 
Subject: [EXTERNAL] Re: nginx-tests SSL tests failing out of the box?
Hello,

Don't think your issue is specific to OpenSSL 3.2.0 or ARM64 arch.
If you specify just --with-http_ssl_module flag, nginx will be compiled with 
system OpenSSL.
What might be not what you expect (OpenSSL: 3.2.0) on MacOS.

Try to specify --with-openssl= on nginx 
configure stage.
Like --with-openssl=./../openssl-3.2.0/ for example.

On Thu, Jan 25, 2024 at 10:00 PM Mayerhofer, Austin via nginx-devel 
mailto:nginx-devel@nginx.org>> wrote:
Hi all,

I have not made any changes to NGINX. Vanilla NGINX (./configure with no flags) 
passes all tests that run, but when compiling with SSL, not all SSL tests are 
passing. Is this expected, or do I need to configure nginx further aside from 
adding the --with-http_ssl_module flag? Do each of the failing tests below 
require separate fixes, or is there a one-size-fits-all solution for all of 
them?

OS: MacOS 12.6.3
Chip: Apple M1 Max
NGINX: 1.24.0 built from source code with ./configure --with-debug 
--with-http_ssl_module
Nginx-tests: 
https://github.com/nginx/nginx-tests/tree/4c2ad8093952706f327d04887c5546bad91b75a6
OpenSSL: 3.2.0 (/opt/homebrew/bin/openssl)
Perl: 5.30.3 (/usr/bin/perl)

When I run

```
TEST_NGINX_BINARY=/usr/local/nginx/sbin/nginx prove -v ssl.t
```

I see

```
not ok 2 - session reused

#   Failed test 'session reused'
#   at ssl.t line 187.
#   'HTTP/1.1 200 OK
# Server: nginx/1.24.0
# Date: Thu, 25 Jan 2024 18:50:10 GMT
# Content-Type: text/plain
# Content-Length: 6
# Connection: close
#
# body .'
# doesn't match '(?^m:^body r$)'
```



Thanks,
Austin


This message has been scanned for malware by Forcepoint. 
www.forcepoint.com<http://www.forcepoint.com/>
___
nginx-devel mailing list
nginx-devel@nginx.org<mailto:nginx-devel@nginx.org>
https://mailman.nginx.org/mailman/listinfo/nginx-devel


Click 
here<https://www.mailcontrol.com/sr/YRBN2jCkrXjGX2PQPOmvUgdxg59Y6Zac_2YUVZSk-fhKfM2P3Uu6Ex30fRJKDtbxj02zfFOBliH3KeH4_zzvzA==>
 to report this email as spam.
___
nginx-devel mailing list
nginx-devel@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: [Issue 8 drafts 0001800]: be*toh() have no entries

[Steffen Nurpmeso via austin-group-l at The Open Group]

 |https://austingroupbugs.net/view.php?id=1800 
 ...
 |Summary:be*toh() have no entries
 ...
 | (0006640) steffen (reporter) - 2024-01-25 21:29
 | https://austingroupbugs.net/view.php?id=1800#c6640 
 |-- 
 |No it should not.
 |There is the very same thing for the le*toh() series, please see draft 4,
 |page 1327.  I am only asking for the very same thing for the be*toh()
 |series. 

Because Mantis did not submit it to the ML, i had posted

  You are right. The entry on page 660 actually *is* the
  description for the be*toh() series, even though it starts with
  htobe16() and appears like an endian.h overview as such, but
  that in turn is on page 240.

  So that is a false issue that i withdraw. (I would resort the
  functions alphabetically at least, with an empty line in between
  the series even.

in a successive message.

Yep, rapid searching in less(1) on a PDF-to-text conversion of
draft 4 it was, hit "n" twice in a row and you are on page 660 not
240; *but* i personally would resort the function order on page
660 for sure.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[Issue 8 drafts 0001801]: xargs: add -P option

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been SUBMITTED. 
== 
https://www.austingroupbugs.net/view.php?id=1801 
== 
Reported By:mohd_akram
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1801
Category:   Shell and Utilities
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: New
Name:   Mohamed Akram 
Organization:
User Reference:  
Section:xargs 
Page Number:3600-3601 
Line Number:123162, 123252 
Final Accepted Text: 
== 
Date Submitted: 2024-01-25 21:39 UTC
Last Modified:  2024-01-25 21:39 UTC
== 
Summary:xargs: add -P option
Description: 
The `-P maxprocs` option is widely supported in xargs implementations to
allow running commands in parallel. It is available in GNU, FreeBSD,
NetBSD, OpenBSD, macOS, and possibly other xargs implementations.
Desired Action: 
Change line 123162 from:

[-s size] [utility [argument...]]

to:

[-s size] [-P maxprocs] [utility [argument...]]

Add at line 123252:

-P maxprocs Parallel mode: run at most maxprocs invocations of utility at
once. If the value of maxprocs is non-positive, the behavior is
unspecified.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-01-25 21:39 mohd_akram New Issue
2024-01-25 21:39 mohd_akram Name  => Mohamed Akram   
2024-01-25 21:39 mohd_akram Section   => xargs   
2024-01-25 21:39 mohd_akram Page Number   => 3600-3601   
2024-01-25 21:39 mohd_akram Line Number   => 123162, 123252  
==

[Issue 8 drafts 0001800]: be*toh() have no entries

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1800 
== 
Reported By:steffen
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1800
Category:   Base Definitions and Headers
Type:   Error
Severity:   Editorial
Priority:   normal
Status: New
Name:   steffen 
Organization:
User Reference:  
Section:system interfaces 
Page Number: 
Line Number: 
Final Accepted Text: 
== 
Date Submitted: 2024-01-23 22:36 UTC
Last Modified:  2024-01-25 21:29 UTC
== 
Summary:be*toh() have no entries
== 

-- 
 (0006640) steffen (reporter) - 2024-01-25 21:29
 https://austingroupbugs.net/view.php?id=1800#c6640 
-- 
No it should not.
There is the very same thing for the le*toh() series, please see draft 4,
page 1327.  I am only asking for the very same thing for the be*toh()
series. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-01-23 22:36 steffenNew Issue
2024-01-23 22:36 steffenName  => steffen 
2024-01-23 22:36 steffenSection   => system interfaces
2024-01-25 10:06 geoffclare Note Added: 0006639  
2024-01-25 21:29 steffenNote Added: 0006640  
==

nginx-tests SSL tests failing out of the box?

[Mayerhofer, Austin via nginx-devel]

Hi all,

I have not made any changes to NGINX. Vanilla NGINX (./configure with no flags) 
passes all tests that run, but when compiling with SSL, not all SSL tests are 
passing. Is this expected, or do I need to configure nginx further aside from 
adding the --with-http_ssl_module flag? Do each of the failing tests below 
require separate fixes, or is there a one-size-fits-all solution for all of 
them?

OS: MacOS 12.6.3
Chip: Apple M1 Max
NGINX: 1.24.0 built from source code with ./configure --with-debug 
--with-http_ssl_module
Nginx-tests: 
https://github.com/nginx/nginx-tests/tree/4c2ad8093952706f327d04887c5546bad91b75a6
OpenSSL: 3.2.0 (/opt/homebrew/bin/openssl)
Perl: 5.30.3 (/usr/bin/perl)

When I run

```
TEST_NGINX_BINARY=/usr/local/nginx/sbin/nginx prove -v ssl.t
```

I see

```
not ok 2 - session reused

#   Failed test 'session reused'
#   at ssl.t line 187.
#   'HTTP/1.1 200 OK
# Server: nginx/1.24.0
# Date: Thu, 25 Jan 2024 18:50:10 GMT
# Content-Type: text/plain
# Content-Length: 6
# Connection: close
#
# body .'
# doesn't match '(?^m:^body r$)'
```

When I run

```
TEST_NGINX_BINARY=/usr/local/nginx/sbin/nginx prove -v ssl_certificate.t
```

I see

```
not ok 9 - session id context match

#   Failed test 'session id context match'
#   at ssl_certificate.t line 183.
#   'HTTP/1.1 200 OK
# Server: nginx/1.24.0
# Date: Thu, 25 Jan 2024 18:52:11 GMT
# Content-Type: text/html
# Content-Length: 0
# Last-Modified: Thu, 25 Jan 2024 18:52:11 GMT
# Connection: close
# ETag: "65b2addb-0"
# X-SSL: default:.
# X-SSL-Protocol: TLSv1.3
# Accept-Ranges: bytes
#
# '
# doesn't match '(?^:default:r)'
```

And finally running

```
TEST_NGINX_BINARY=/usr/local/nginx/sbin/nginx prove -v ssl_crl.t
```

Yields

```
not ok 1 - crl - no revoked certs

#   Failed test 'crl - no revoked certs'
#   at ssl_crl.t line 157.
#   'HTTP/1.1 400 Bad Request
# Server: nginx/1.24.0
# Date: Thu, 25 Jan 2024 18:53:50 GMT
# Content-Type: text/html
# Content-Length: 215
# Connection: close
# X-Verify: FAILED:unsupported certificate purpose
#
# 
# 400 The SSL certificate error
# 
# 400 Bad Request
# The SSL certificate error
# nginx/1.24.0
# 
# 
# '
# doesn't match '(?^:SUCCESS)'
```

Thanks,
Austin


This message has been scanned for malware by Forcepoint. www.forcepoint.com
___
nginx-devel mailing list
nginx-devel@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-devel

Re: [EXTERNAL] Re: Nginx-tests stream_ssl_conf_command.t test hanging indefinitely

[Mayerhofer, Austin via nginx-devel]

Hey Sergey,

Thanks for the help. I tried installing perl via homebrew but I ran into some 
dependency issues setting it up, and by the time I did set it up, it was 
skipping due to “# SKIP no http_ssl available”.

Is there a set of instructions or documentation for setting up a Mac 
environment for nginx-tests? I might be setting up perl wrong.

From: Sergey Kandaurov 
Date: Wednesday, January 24, 2024 at 2:59 PM
To: nginx-devel@nginx.org 
Cc: Mayerhofer, Austin 
Subject: [EXTERNAL] Re: Nginx-tests stream_ssl_conf_command.t test hanging 
indefinitely

> On 25 Jan 2024, at 01:15, Mayerhofer, Austin via nginx-devel 
>  wrote:
>
> Hi all,
>  Apologies if I sent this twice, I don’t think the first one went through 
> because I wasn’t subscribed to the list.
>  nginx-tests’ stream_ssl_conf_command.t is hanging for me and not running to 
> completion, I’m using the following configuration:
>  OS: MacOS 12.6.3
> Chip: Apple M1 Max
> NGINX: 1.24.0 built from source code with ./configure --with-debug 
> --with-http_ssl_module --with-http_stub_status_module --with-http_v2_module 
> --without-http_auth_basic_module --without-http_autoindex_module 
> --without-http_browser_module --without-http-cache 
> --without-http_charset_module --without-http_empty_gif_module 
> --without-http_fastcgi_module --without-http_grpc_module 
> --without-http_limit_conn_module --without-http_limit_req_module 
> --without-http_memcached_module --without-http_referer_module 
> --without-http_scgi_module --without-http_split_clients_module 
> --without-http_ssi_module --without-http_upstream_hash_module 
> --without-http_upstream_ip_hash_module 
> --without-http_upstream_least_conn_module --without-http_userid_module 
> --without-http_uwsgi_module --with-stream --with-stream_ssl_module 
> --with-stream_ssl_preread_module --without-stream_limit_conn_module 
> --without-stream_set_module --without-stream_split_clients_module 
> --without-stream_upstream_hash_module 
> --without-stream_upstream_least_conn_module 
> --without-stream_upstream_zone_module nginx-tests: 
> https://github.com/nginx/nginx-tests/tree/4c2ad8093952706f327d04887c5546bad91b75a6
>  When I run:
>  ```
> TEST_NGINX_BINARY=/usr/local/nginx/sbin/nginx prove -v 
> stream_ssl_conf_command.t
> ```
>  The output is:
>  ```
> stream_ssl_conf_command.t ..
> 1..5
> ok 1 - Certificate
> ok 2 - SessionTicket
> ok 3 – ServerPreference
> ```
>  And it hangs there.

Perl from macOS base system (/usr/bin/perl) is known to be buggy
for some unknown reason.  This is expressed in various hangs when
running nginx-tests.  I saw similar reports since at least macOS
12.3.1, and this is not caused by a particular Perl version (same
version from macports works for me).  You can try Perl from homebrew
or macports collections, it should work just fine.

--
Sergey Kandaurov


This message has been scanned for malware by Forcepoint. www.forcepoint.com
___
nginx-devel mailing list
nginx-devel@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-devel

Reminder: Review of 202x Draft 4 review draft closing soon

[Andrew Josey via austin-group-l at The Open Group]

Dear all

A gentle reminder that the review period for draft 4 closes next week
(on January 31 2024).

regards
Andrew


> On 19 Dec 2023, at 14:29, Andrew Josey via austin-group-l at The Open Group 
>  wrote:
> 
> 
> hi all,
> 
> I'm pleased to announce the availability of the fourth draft of the 202x 
> revision of the standard. 
> 
> The draft can be obtained from the login page of the Austin Group at:
> 
> https://www.opengroup.org/austin/login.html
> 
> The Mantis project for reporting bugs for this draft has been setup and is 
> “Issue 8 drafts”,
> select Product Version “Draft 4”.
> 
> We have started The Open Group Company Review on this draft, and will be 
> starting the IEEE recirculation ballot on this draft shortly.  The 
> review/ballot will close on January 31 2024.
> 
> 
> I enclose the reviewers notes below.
> regards
> Andrew
> 
> 
> 202x Draft 4 Reviewers Notes = Please Read
> 
> These reviewers' notes accompany 202x Draft 4 dated December 2023.
> 
> 202x Draft 4 is the second ballot draft of the POSIX.1-202x Revision (aka 
> IEEE P1003.1 Draft), and will be submitted for DIS ballot for ISO/IEC 9945. 
> This draft is also being submitted for The Open Group Company Review as The 
> Open Group Base Specifications, Issue 8 Draft. These notes should be read 
> prior to reviewing the document.
> 
> IEEE, ISO/IEC balloting,The Open Group Company Review, and review by the 
> Austin Group Technical Reviewers will take place on this draft. This draft is 
> considered feature complete and is a release candidate for the final standard.
> 
> The draft for the Austin Group and IEEE review has change markings to show 
> the changes applied since draft 3.
> 
> All interested parties are invited to review these comments and submit 
> comments directly to the Austin Group. Please use the Mantis bug tracker at 
> https://austingroupbugs.net. The project in Mantis is "Issue 8 drafts". 
> Select "Draft 4". Further information on bugreporting against these documents 
> can be found at https://www.opengroup.org/austin/Mantis_Reporting_Help.html.
> 
> In order to submit comments, you need to have a Mantis account. If you do not 
> have a Mantis account you will need to request one by contacting Andrew Josey 
> for assistance.
> 
> Since this is a recirculation draft, narrowing down rules apply and you may 
> only comment on sections of the document that have changed as a result of the 
> comments made against draft 3. Changes are marked with change bars.
> 
> A separate report is available in the Austin Group document register 
> (Austin/1371) detailing the bug reports leading to changes in Draft 4.
> 
> Background information on the Issue 8 Project
> 
> Please see the following documents from the Document register 
> (http:/www.opengroup.org/austin/docreg.html) for details of the Issue 8 
> project.
> 
>   • Austin/936 (PDF) — PAR for P1003.1-202x Revision (Submitted June 21 
> 2019) , revised November 2023, see Austin/1360
>   • Austin/937r1 — Final PASC PMC Criteria for P1003.1-202x Revision
> 
> 
> 


Andrew JoseyThe Open Group
Austin Group Chair  
Email: a.jo...@opengroup.org 
Apex Plaza, Forbury Road,Reading,Berks.RG1 1AX,England

To learn how we maintain your privacy, please review The Open Group Privacy 
Statement at http://www.opengroup.org/privacy.
To unsubscribe/opt-out from this mailing list login to The Open Group 
collaboration portal at
https://collaboration.opengroup.org/operational/portal.php?action=unsub=2481

[Issue 8 drafts 0001800]: be*toh() have no entries

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1800 
== 
Reported By:steffen
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1800
Category:   Base Definitions and Headers
Type:   Error
Severity:   Editorial
Priority:   normal
Status: New
Name:   steffen 
Organization:
User Reference:  
Section:system interfaces 
Page Number: 
Line Number: 
Final Accepted Text: 
== 
Date Submitted: 2024-01-23 22:36 UTC
Last Modified:  2024-01-25 10:06 UTC
== 
Summary:be*toh() have no entries
== 

-- 
 (0006639) geoffclare (manager) - 2024-01-25 10:06
 https://austingroupbugs.net/view.php?id=1800#c6639 
-- 
The requested change makes no sense. The be16toh() page is where all of
these functions are described. There are "pointer" pages for htobe16() and
le16toh() to allow finding those descriptions when looking alphabetically
for the htobe*() and le*toh() functions.

Pointer pages to pointer pages are never used.

This request should either be withdrawn (if the submitter agrees to it) or
be rejected. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-01-23 22:36 steffenNew Issue
2024-01-23 22:36 steffenName  => steffen 
2024-01-23 22:36 steffenSection   => system interfaces
2024-01-25 10:06 geoffclare Note Added: 0006639  
==

Nginx-tests stream_ssl_conf_command.t test hanging indefinitely

[Mayerhofer, Austin via nginx-devel]

Hi all,

Apologies if I sent this twice, I don’t think the first one went through 
because I wasn’t subscribed to the list.

nginx-tests’ stream_ssl_conf_command.t is hanging for me and not running to 
completion, I’m using the following configuration:

OS: MacOS 12.6.3
Chip: Apple M1 Max
NGINX: 1.24.0 built from source code with ./configure --with-debug 
--with-http_ssl_module --with-http_stub_status_module --with-http_v2_module 
--without-http_auth_basic_module --without-http_autoindex_module 
--without-http_browser_module --without-http-cache 
--without-http_charset_module --without-http_empty_gif_module 
--without-http_fastcgi_module --without-http_grpc_module 
--without-http_limit_conn_module --without-http_limit_req_module 
--without-http_memcached_module --without-http_referer_module 
--without-http_scgi_module --without-http_split_clients_module 
--without-http_ssi_module --without-http_upstream_hash_module 
--without-http_upstream_ip_hash_module 
--without-http_upstream_least_conn_module --without-http_userid_module 
--without-http_uwsgi_module --with-stream --with-stream_ssl_module 
--with-stream_ssl_preread_module --without-stream_limit_conn_module 
--without-stream_set_module --without-stream_split_clients_module 
--without-stream_upstream_hash_module 
--without-stream_upstream_least_conn_module 
--without-stream_upstream_zone_module
nginx-tests: 
https://github.com/nginx/nginx-tests/tree/4c2ad8093952706f327d04887c5546bad91b75a6

When I run:

```
TEST_NGINX_BINARY=/usr/local/nginx/sbin/nginx prove -v stream_ssl_conf_command.t
```

The output is:

```
stream_ssl_conf_command.t ..
1..5
ok 1 - Certificate
ok 2 - SessionTicket
ok 3 – ServerPreference
```

And it hangs there. It seems to be something with the ServerPreference test, as 
if I remove this code, it does run to completion:

```
$s = stream(
PeerAddr => '127.0.0.1:' . port(8443),
SSL => 1,
SSL_cipher_list =>
'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384'
);
is($s->socket()->get_cipher(),
'ECDHE-RSA-AES128-GCM-SHA256', 'ServerPreference');
```

These are the last 20 lines of error.log, but I didn’t notice anything out of 
the ordinary in the ~200 total lines in the file, just that it’s hanging.

2024/01/24 11:38:08 [debug] 98386#0: *2 reusable connection: 0
2024/01/24 11:38:08 [debug] 98386#0: *2 free: 00011CE04080, unused: 0
2024/01/24 11:38:08 [debug] 98386#0: *2 free: 00011CE04180, unused: 0
2024/01/24 11:38:08 [debug] 98386#0: *2 free: 00011CE04280, unused: 32
2024/01/24 11:38:08 [debug] 98386#0: timer delta: 0
2024/01/24 11:38:08 [debug] 98386#0: worker cycle
2024/01/24 11:38:08 [debug] 98386#0: kevent timer: 3000, changes: 0
2024/01/24 11:38:08 [debug] 98386#0: kevent events: 1
2024/01/24 11:38:08 [debug] 98386#0: kevent: 3: ft:-1 fl:0025 ff: d:31 
ud:0001200280D1
2024/01/24 11:38:08 [debug] 98386#0: *3 SSL shutdown handler
2024/01/24 11:38:08 [debug] 98386#0: *3 SSL_shutdown: 1
2024/01/24 11:38:08 [debug] 98386#0: *3 close stream connection: 3
2024/01/24 11:38:08 [debug] 98386#0: *3 event timer del: 3: 422265465
2024/01/24 11:38:08 [debug] 98386#0: *3 reusable connection: 0
2024/01/24 11:38:08 [debug] 98386#0: *3 free: 00011CE04A20, unused: 0
2024/01/24 11:38:08 [debug] 98386#0: *3 free: 00011CE04B20, unused: 0
2024/01/24 11:38:08 [debug] 98386#0: *3 free: 00011CE04CC0, unused: 32
2024/01/24 11:38:08 [debug] 98386#0: timer delta: 0
2024/01/24 11:38:08 [debug] 98386#0: worker cycle
2024/01/24 11:38:08 [debug] 98386#0: kevent timer: -1, changes: 0

Has anyone else run into this problem? I searched the nginx and nginx-devel 
mailing lists and didn’t see anything.

Thank you for any help!



This message has been scanned for malware by Forcepoint. www.forcepoint.com
___
nginx-devel mailing list
nginx-devel@nginx.org
https://mailman.nginx.org/mailman/listinfo/nginx-devel

Minutes of the 22nd January 2024 Teleconference

[Andrew Josey via austin-group-l at The Open Group]

All
Enclosed are the minutes of the Monday meeting this week
regards
Andrew
---
Minutes of the 22nd January 2024 TeleconferenceAustin-1378 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 24th January 2024

Attendees:
Don Cragun, IEEE SA OR
Nick Stoughton, Logitech/USENIX, ISO/IEC JTC 1/SC 22 OR
Mark Ziegast, SHware Systems Dev.
Eric Ackermann 
Andrew Josey, The Open Group
Eric Blake, Red Hat, The Open Group OR
Levon Tumanyan
Tom Thompson, IEEE

Apologies
Geoff Clare, The Open Group

* General news

Draft 4 is still in review at The Open Group and IEEE, with the
review closing on January 31 2024. No comments have been received
as yet.

* Current Business

Bug 1789: if command name contains slash, it cannot be arg0 for execl() 
Accepted as Marked
https://austingroupbugs.net/view.php?id=1789

We revisited this based on comments received.
Note: 0006621 has been updated as suggested by Note: 0006631


Bug 1791: tr: clarify encdings of non-characters bytes and proper encodings of 
the NUL byte and Rejected
https://austingroupbugs.net/bug_view_page.php?bug_id=1791

Rejected, closed.
NUL is not a special case; NUL is a character in every locale. The
standard says that the strings specified by string1 and string2
contain characters. A single character in those strings may be
represented by one or more adjacent octal sequences that represent
individual bytes of a multi-byte character. The notes in the
APPLICATION USAGE and in the RATIONALE specify that tr -d
'\000' must remove NUL characters from the input stream. This
would also work with tr -d '\0' and tr -d '\00'.
But if one wanted to remove NUL characters and the character '1',
one would have to use tr -d '\0001' (or put the '1' before
the octal escape sequence for the NUL character, e.g. tr -d
'1\0'); not tr -d '\01' or tr -d '\001'.
Therefore, this bug is rejected.

We started on this item and will continue on the next call.

Bug 1792: Example 7 needs to use find's -H option Accepted as Marked
https://austingroupbugs.net/bug_view_page.php?bug_id=1792

This item is tagged for TC1-2024.

Make the changes suggested, including the addition of "provided both file1 and 
file2 are accessible" (add after example). 


Bug 1793: Streamline US-ASCII character set name OPEN
https://austingroupbugs.net/bug_view_page.php?bug_id=1793

We will start on this item next time.


Next Steps
--
  
The next call is on:
  Thu 2024-01-25 (Zoom meeting - general bugs)
  Mon 2024-01-29 (Zoom meeting - general bugs)

The calls are for 90 minutes

Calls are anchored on US time. (8am Pacific)

Please check the calendar invites for dial in details.

Bugs are at:
https://austingroupbugs.net

An etherpad is usually up for the meeting, with a URL using the date format as 
below:

https://posix.rhansen.org/p/20xx-mm-dd

(For write access this uses The Open Group single sign on,
for those individuals with gitlab.opengroup.org accounts.
Please contact Andrew if you need to be setup)


Andrew JoseyThe Open Group
Austin Group Chair  
Email: a.jo...@opengroup.org 
Apex Plaza, Forbury Road,Reading,Berks.RG1 1AX,England

To learn how we maintain your privacy, please review The Open Group Privacy 
Statement at http://www.opengroup.org/privacy.
To unsubscribe/opt-out from this mailing list login to The Open Group 
collaboration portal at
https://collaboration.opengroup.org/operational/portal.php?action=unsub=2481

Re: [Issue 8 drafts 0001799]: endian.h unconditionally requires 64-bit integers

[Steffen Nurpmeso via austin-group-l at The Open Group]

  ...
 |https://austingroupbugs.net/view.php?id=1799 
 ...
 |Summary:endian.h unconditionally requires 64-bit \
 |integers
 ...

Mantis did not post the follow-up message, neither to me nor to

  https://www.mail-archive.com/austin-group-l@opengroup.org/

Something is wrong with it.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[Issue 8 drafts 0001800]: be*toh() have no entries

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been SUBMITTED. 
== 
https://austingroupbugs.net/view.php?id=1800 
== 
Reported By:steffen
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1800
Category:   Base Definitions and Headers
Type:   Error
Severity:   Editorial
Priority:   normal
Status: New
Name:   steffen 
Organization:
User Reference:  
Section:system interfaces 
Page Number: 
Line Number: 
Final Accepted Text: 
== 
Date Submitted: 2024-01-23 22:36 UTC
Last Modified:  2024-01-23 22:36 UTC
== 
Summary:be*toh() have no entries
Description: 
Whereas there is

  le16toh, le32toh, le64toh — convert values between host and specified
byte order

on page 1327, no such section exists for the big indian series.

P.S.:
This is a main master miss, as not all indians are litte, white black
gender politically very delicate, and the traffic light has all the rights
of the world to turn yellow red.  Imho.
Desired Action: 
Please add an entry

NAME
be16toh, be32toh, be64toh — convert values between host and specified
byte order
SYNOPSIS
#include 
uint16_t be16toh(uint16_t big_endian_16bits);
uint32_t be32toh(uint32_t big_endian_32bits);
option  uint64_t be64toh(uint64_t big_endian_64bits);
DESCRIPTION
Refer to le16toh( ).

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-01-23 22:36 steffenNew Issue
2024-01-23 22:36 steffenName  => steffen 
2024-01-23 22:36 steffenSection   => system interfaces
==

[Issue 8 drafts 0001799]: endian.h unconditionally requires 64-bit integers

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been SUBMITTED. 
== 
https://austingroupbugs.net/view.php?id=1799 
== 
Reported By:steffen
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1799
Category:   Base Definitions and Headers
Type:   Error
Severity:   Editorial
Priority:   normal
Status: New
Name:   steffen 
Organization:
User Reference:  
Section:endian.h 
Page Number:240, 661 
Line Number:8462-8467, 23136-23139, 23151 
Final Accepted Text: 
== 
Date Submitted: 2024-01-23 22:25 UTC
Last Modified:  2024-01-23 22:25 UTC
== 
Summary:endian.h unconditionally requires 64-bit integers
Description: 
Optional for stdint.h, but not endian.h.
Desired Action: 
At the very location, change

  8462   uint64_t htobe64(uint64_t);
  8463   uint64_t htole64(uint64_t);
  8464   uint64_t be64toh(uint64_t);
  8465   uint64_t le64toh(uint64_t);
  8466   The  header shall define the uint16_t, uint32_t,
and  uint64_t types as described in
  8467   .

accordingly.  (Ie refer to "Integer types" of stdint.h.)

On page 661, lines 23136-23139, change

  23136   uint64_t htobe64(uint64_t host_64bits);
  23137   uint64_t htole64(uint64_t host_64bits);
  23138   uint64_t be64toh(uint64_t big_endian_64bits);
  23139   uint64_t le64toh(uint64_t little_endian_64bits);

in the same way, and on line 23151, change

  For each of the sizes 16, 32 and 64

to

  For each of the sizes 16 and 32, and if supported 64
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-01-23 22:25 steffenNew Issue
2024-01-23 22:25 steffenName  => steffen 
2024-01-23 22:25 steffenSection   => endian.h
2024-01-23 22:25 steffenPage Number   => 240, 661
2024-01-23 22:25 steffenLine Number   => 8462-8467,
23136-23139, 23151
==

Re: 64-bit integer types?

[Geoff Clare via austin-group-l at The Open Group]

Steffen Nurpmeso wrote, on 22 Jan 2024:
> 
> I just read Paul Eggert on the IANA TZ list saying that POSIX does
> not require 64-bit integer times,

That is true for the current standard, but Issue 8 will require that
time_t has a width of at least 64 bits.  (It is already required to
be an integer type.)

This change came in through https://austingroupbugs.net/view.php?id=1462

> and when i look into that i see
> (for stdint.h):
> 
>   12961If an implementation provides integer types with width 64 
> that meet these requirements,
>   12962then the following types are required:
>   12963int64_t
>   12964uint64_t

These types are optional because they are exactly 64 bits, and
therefore depend on the programming environment supporting those
exact types; the int_least64_t and uint_least64_t types are required.

> But from a quick search this is the only such optional occurrence.
> The standard imposes the presence of the typedefs at other places,
> for example endian.h, with words like "For each of the sizes 16,
> 32 and 64,", which rather implies 64-bit being non-optional.
> 
> Shall i open an issue, or what is to be done.

There does seem to be a conflict between  and :

The  header shall define the uint16_t, uint32_t, and
uint64_t types as described in .

This presupposes that uint64_t is always defined in ,
whereas actually its definition there is conditional.

-- 
Geoff Clare 
The Open Group, Apex Plaza, Forbury Road, Reading, RG1 1AX, England

[1003.1(2016/18)/Issue7+TC2 0001793]: Streamline US-ASCII character set name

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1793 
== 
Reported By:steffen
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1793
Category:   Front Matter
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: New
Name:   steffen 
Organization:
User Reference:  
Section:many 
Page Number:many 
Line Number:many 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2023-12-19 02:02 UTC
Last Modified:  2024-01-23 00:12 UTC
== 
Summary:Streamline US-ASCII character set name
== 

-- 
 (0006637) steffen (reporter) - 2024-01-23 00:12
 https://austingroupbugs.net/view.php?id=1793#c6637 
-- 
(I have no opinion on that.  I am in strong favour of readding the ASCII
alias that got lost to the IANA database.  This issue is because later ones
may stumble over the ASCII as IANA is the "official thing", and it has its
opinion that i do not understand.) 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-12-19 02:02 steffenNew Issue
2023-12-19 02:02 steffenName  => steffen 
2023-12-19 02:02 steffenSection   => many
2023-12-19 02:02 steffenPage Number   => many
2023-12-19 02:02 steffenLine Number   => many
2024-01-04 16:05 shware_systems Note Added: 0006613  
2024-01-04 22:02 steffenNote Added: 0006615  
2024-01-22 17:44 shware_systems Note Added: 0006636  
2024-01-22 17:45 shware_systems Note Edited: 0006636 
2024-01-23 00:12 steffenNote Added: 0006637  
==

64-bit integer types?

[Steffen Nurpmeso via austin-group-l at The Open Group]

Hello.

I just read Paul Eggert on the IANA TZ list saying that POSIX does
not require 64-bit integer times, and when i look into that i see
(for stdint.h):

  12961If an implementation provides integer types with width 64 
that meet these requirements,
  12962then the following types are required:
  12963int64_t
  12964uint64_t

But from a quick search this is the only such optional occurrence.
The standard imposes the presence of the typedefs at other places,
for example endian.h, with words like "For each of the sizes 16,
32 and 64,", which rather implies 64-bit being non-optional.

Shall i open an issue, or what is to be done.
I mean, i used 64-bit integers with gcc __extension__ 25 years
ago, the Microsoft world had them (from reading), and JAVA had
them by then, too.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[1003.1(2016/18)/Issue7+TC2 0001793]: Streamline US-ASCII character set name

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1793 
== 
Reported By:steffen
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1793
Category:   Front Matter
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: New
Name:   steffen 
Organization:
User Reference:  
Section:many 
Page Number:many 
Line Number:many 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2023-12-19 02:02 UTC
Last Modified:  2024-01-22 17:44 UTC
== 
Summary:Streamline US-ASCII character set name
== 

-- 
 (0006636) shware_systems (reporter) - 2024-01-22 17:44
 https://austingroupbugs.net/view.php?id=1793#c6636 
-- 
Re: 6615

Agreed, there still might be confusion. An alternative is changing all
those instances to "PSX-ASCII", or "POSIX-ASCII", and add to XBD3 a
definition that specifies how C overloaded  and  as string
terminator and end-of-line, along with making , , and  as
having no defined function. This could even be a new IANA registration, I
suspect, outside the range r4eserved to ISO-IR registrations. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-12-19 02:02 steffenNew Issue
2023-12-19 02:02 steffenName  => steffen 
2023-12-19 02:02 steffenSection   => many
2023-12-19 02:02 steffenPage Number   => many
2023-12-19 02:02 steffenLine Number   => many
2024-01-04 16:05 shware_systems Note Added: 0006613  
2024-01-04 22:02 steffenNote Added: 0006615  
2024-01-22 17:44 shware_systems Note Added: 0006636  
==

[Issue 8 drafts 0001792]: Example 7 needs to use find's -H option

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been RESOLVED. 
== 
https://austingroupbugs.net/view.php?id=1792 
== 
Reported By:Don Cragun
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1792
Category:   Shell and Utilities
Type:   Clarification Requested
Severity:   Comment
Priority:   normal
Status: Resolved
Name:   Don Cragun 
Organization:
User Reference:  
Section:find utility example 7 
Page Number:2924 
Line Number:97746-97749 
Final Accepted Text:see
https://austingroupbugs.net/view.php?id=1792#c6635 
Resolution: Accepted As Marked
Fixed in Version:   
== 
Date Submitted: 2023-12-18 18:40 UTC
Last Modified:  2024-01-22 17:16 UTC
== 
Summary:Example 7 needs to use find's -H option
==
Relationships   ID  Summary
--
child of0001776 find -newer any symlinks
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-12-18 18:40 Don Cragun New Issue
2023-12-18 18:40 Don Cragun Name  => Don Cragun  
2023-12-18 18:40 Don Cragun Section   => find utility
example 7
2023-12-18 18:40 Don Cragun Page Number   => 2924
2023-12-18 18:40 Don Cragun Line Number   => 97746-97749 
2023-12-18 18:45 Don Cragun Relationship added   child of 0001776
2024-01-22 17:15 nick   Note Added: 0006635  
2024-01-22 17:16 nick   Final Accepted Text   => see
https://austingroupbugs.net/view.php?id=1792#c6635
2024-01-22 17:16 nick   Status   New => Resolved 
2024-01-22 17:16 nick   Resolution   Open => Accepted As
Marked
==

[Issue 8 drafts 0001792]: Example 7 needs to use find's -H option

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1792 
== 
Reported By:Don Cragun
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1792
Category:   Shell and Utilities
Type:   Clarification Requested
Severity:   Comment
Priority:   normal
Status: New
Name:   Don Cragun 
Organization:
User Reference:  
Section:find utility example 7 
Page Number:2924 
Line Number:97746-97749 
Final Accepted Text: 
== 
Date Submitted: 2023-12-18 18:40 UTC
Last Modified:  2024-01-22 17:15 UTC
== 
Summary:Example 7 needs to use find's -H option
==
Relationships   ID  Summary
--
child of0001776 find -newer any symlinks
== 

-- 
 (0006635) nick (manager) - 2024-01-22 17:15
 https://austingroupbugs.net/view.php?id=1792#c6635 
-- 
Make the changes suggested, including the addition of "provided both file1
and file2 are accessible" (add after example). 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-12-18 18:40 Don Cragun New Issue
2023-12-18 18:40 Don Cragun Name  => Don Cragun  
2023-12-18 18:40 Don Cragun Section   => find utility
example 7
2023-12-18 18:40 Don Cragun Page Number   => 2924
2023-12-18 18:40 Don Cragun Line Number   => 97746-97749 
2023-12-18 18:45 Don Cragun Relationship added   child of 0001776
2024-01-22 17:15 nick   Note Added: 0006635  
==

[Issue 8 drafts 0001791]: tr: clarify encdings of non-characters bytes and proper encodings of the NUL byte and

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been CLOSED. 
== 
https://www.austingroupbugs.net/view.php?id=1791 
== 
Reported By:calestyo
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1791
Category:   Shell and Utilities
Type:   Clarification Requested
Severity:   Editorial
Priority:   normal
Status: Closed
Name:   Christoph Anton Mitterer 
Organization:
User Reference:  
Section:Shells and Utilities 
Page Number:3427, ff. 
Line Number:116995, ff. 
Final Accepted Text: 
Resolution: Rejected
Fixed in Version:   
== 
Date Submitted: 2023-12-07 04:34 UTC
Last Modified:  2024-01-22 17:06 UTC
== 
Summary:tr: clarify encdings of non-characters bytes and
proper encodings of the NUL byte and
== 

-- 
 (0006634) Don Cragun (manager) - 2024-01-22 17:06
 https://www.austingroupbugs.net/view.php?id=1791#c6634 
-- 
NUL is not a special case; NUL is a character in every locale. 
The standard says that the strings specified by string1 and
string2 contain characters.  A single character in those strings may
be represented by one or more adjacent octal sequences that represent
individual bytes of a multi-byte character. The notes in the APPLICATION
USAGE and in the RATIONALE specify that tr -d '\000' must remove
NUL characters from the input stream.  This would also work with tr -d
'\0' and tr -d '\00'.  But if one wanted to remove NUL
characters and the character '1', one would have to use tr -d
'\0001' (or put the '1' before the octal escape sequence for the NUL
character, e.g. tr -d '1\0'); not tr -d '\01' or tr
-d '\001'.
Therefore, this bug is rejected. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-12-07 04:34 calestyo   New Issue
2023-12-07 04:34 calestyo   Name  => Christoph Anton
Mitterer
2023-12-07 04:34 calestyo   Section   => Shells and
Utilities
2023-12-07 04:34 calestyo   Page Number   => 3427, ff.   
2023-12-07 04:34 calestyo   Line Number   => 116995, ff. 
2024-01-22 17:06 Don Cragun Note Added: 0006634  
2024-01-22 17:06 Don Cragun Status   New => Closed   
2024-01-22 17:06 Don Cragun Resolution   Open => Rejected
==

Austin Group teleconference +1 888 974 9888 PIN 618 156 403

[Single UNIX Specification via austin-group-l at The Open Group]

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//opengroup.org//NONSGML kigkonsult.se iCalcreator 2.22.1//
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:America/New_York
X-LIC-LOCATION:America/New_York
BEGIN:DAYLIGHT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
DTSTART:20120311T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
DTSTART:20121104T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:65ae953879...@opengroup.org
DTSTAMP:20240122T161800Z
ATTENDEE;ROLE=CHAIR:MAILTO:a.jo...@opengroup.org
CREATED:20240122T00Z
DESCRIPTION:Web/Project: Single UNIX Specification\nTitle: Austin Group tel
 econference +1 888 974 9888 PIN 618 156 403\nDate/Time: 29-Jan-2024 at 11:
 00 America/New_York\nDuration: 1.50 hours\nURL: https://collaboration.open
 group.org/platform/single_unix_specification/events.php\n\nAll calls are a
 nchored on US time\n\nTopic: Austin Group teleconference\n
 ---\nAudio conference information\n---
 \n\nYou are invited to
  a Zoom meeting.\n\nMeeting ID: 618 156 403\n\nJoin from PC\, Mac\, iOS or
  Android: https://logitech.zoom.us/j/618156403\n \nor join by phone:\nUS: 
 888 974 9888\nUK: 800 031 5717\nDE: 800 724 3138\nFR: 805 082 588\n\nOther
  international numbers available here:\nhttps://zoom.us/u/adlvrb8ILj\n \n 
Meeting ID: 618 156 403\n\nor join from a H.323/SIP Device:\nDial: 
 162.255.37.11 (US West) or 162.255.36.11 (US East)\nMeeting ID: 618 15
 6 403\n\nShare from a PC or MAC: https://zoom.us/share/618156403\n\nOr iPh
 one one-tap (US Toll):  +16699006833\,618156403# or +16465588656\,61815640
 3#\n\nPassword for zoom call  ends with x\n\nAll Austin Group participants
  are most welcome to join the call.\nThe call will last for 90 minutes.\n
 \n\nAn etherpad is usually up for a meeting\, with a URL using the date fo
 rmat as below:\n\nhttps://posix.rhansen.org/p/202x-mm-dd\n\nLOGIN REQUIRED
  to write to the ETHERPAD (Use your gitlab.opengroup.org login.)\n\n \n\nB
 ug reports are available at:\nhttps://www.austingroupbugs.net\n
DTSTART;TZID=America/New_York:20240129T11
DURATION:PT1H30M0S
LAST-MODIFIED:20240122T111800Z
ORGANIZER;CN=Single UNIX Specification:MAILTO:do-not-re...@opengroup.org
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Austin Group teleconference +1 888 974 9888 PIN 618 156 403
TRANSP:OPAQUE
URL:https://collaboration.opengroup.org/platform/single_unix_specification/
 events.php
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-VISIBILITY:40
X-JOINBEFORE:5
X-CATEGORY:Teleconference
X-PLATO-SITE:Single UNIX Specification
X-PLATO-SITEID:136
END:VEVENT
END:VCALENDAR


meeting.ics
Description: application/ics

[Issue 8 drafts 0001789]: if command name contains slash, it cannot be arg0 for execl()

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1789 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1789
Category:   Shell and Utilities
Type:   Error
Severity:   Objection
Priority:   normal
Status: Resolved
Name:   Mark Galeck 
Organization:
User Reference:  
Section:Volume 2, Chapter 3 
Page Number:865, 2487 
Line Number:80936, 29495 
Final Accepted Text:see
https://austingroupbugs.net/view.php?id=1789#c6621 
Resolution: Accepted As Marked
Fixed in Version:   
== 
Date Submitted: 2023-11-22 02:24 UTC
Last Modified:  2024-01-22 16:15 UTC
== 
Summary:if command name contains slash, it cannot be arg0
for execl()
==
Relationships   ID  Summary
--
related to  0001645 execvp( ) requirements on arg0 are too ...
== 

-- 
 (0006633) nick (manager) - 2024-01-22 16:15
 https://austingroupbugs.net/view.php?id=1789#c6633 
-- 
Bugnote:6621 has been updated as suggested by
https://austingroupbugs.net/view.php?id=1789#c6631 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-11-22 02:24 Mark_GaleckNew Issue
2023-11-22 02:24 Mark_GaleckName  => Mark Galeck 
2023-11-22 02:24 Mark_GaleckSection   => Volume 2, Chapter 3
2023-11-22 02:24 Mark_GaleckPage Number   => 865, 2487   
2023-11-22 02:24 Mark_GaleckLine Number   => 80936, 29495
2023-11-22 06:20 larryv Note Added: 0006579  
2023-11-22 07:18 Don Cragun Note Added: 0006580  
2023-11-22 07:19 Don Cragun Project 
1003.1(2016/18)/Issue7+TC2 => Issue 8 drafts
2023-11-22 07:21 Don Cragun version   => Draft 3 
2023-11-22 09:42 Guy Harris Note Added: 0006581  
2023-11-22 09:57 Guy Harris Note Added: 0006582  
2023-12-11 14:58 geoffclare Note Added: 0006596  
2024-01-15 16:40 nick   Relationship added   related to 0001645  
2024-01-15 17:28 nick   Note Added: 0006621  
2024-01-15 17:29 nick   Final Accepted Text   => see
https://austingroupbugs.net/view.php?id=1789#c6621
2024-01-15 17:29 nick   Status   New => Resolved 
2024-01-15 17:29 nick   Resolution   Open => Accepted As
Marked
2024-01-15 17:30 nick   Tag Attached: tc1-2024   
2024-01-15 17:31 nick   Note Edited: 0006621 
2024-01-17 17:43 gbrandenrobinsonNote Added: 0006626  
2024-01-18 16:08 nick   Note Edited: 0006621 
2024-01-18 16:08 nick   Note Added: 0006627  
2024-01-18 16:09 nick   Note Added: 0006628  
2024-01-18 16:10 nick   Note Deleted: 0006628
2024-01-18 16:44 eblake Note Edited: 0006621 
2024-01-19 19:31 larryv Note Added: 0006631  
2024-01-22 16:14 nick   Note Edited: 0006621 
2024-01-22 16:15 nick   Note Added: 0006633  
==

[Issue 8 drafts 0001798]: Must posix_getdents remember file offsets across exec?

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1798 
== 
Reported By:eblake
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1798
Category:   System Interfaces
Type:   Clarification Requested
Severity:   Objection
Priority:   normal
Status: New
Name:   Eric Blake 
Organization:   Red Hat 
User Reference: ebb.posix_getdents 
Section:XSH posix_getdents 
Page Number:1567 
Line Number:52609 
Final Accepted Text: 
== 
Date Submitted: 2024-01-22 15:13 UTC
Last Modified:  2024-01-22 15:30 UTC
== 
Summary:Must posix_getdents remember file offsets across
exec?
== 

-- 
 (0006632) eblake (manager) - 2024-01-22 15:30
 https://austingroupbugs.net/view.php?id=1798#c6632 
-- 
Correction - I'm told that the attempted Cygwin implementation also has
problems after dup(); it is unclear whether the states should be linked
(reading an entry on one fd, grabbing its offset, then using the other fd
to read entries, it is unclear whether the second fd starts reading from
the point where the fd was at the time of dup() or at the shared point
reached by the first fd, and whether the second fd can safely lseek() to
the offset read by the first fd).  Easiest would be to state that dup() has
the same limitations as fork()/exec - namely, that any mid-stream directory
traversal in either side of the split is unspecified, and the only portable
thing is to start a new traversal by lseek'ing back to 0 (at which point,
the implementation no longer has to worry about sharing a half-read DIR*
across fd copies or processes). 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-01-22 15:13 eblake New Issue
2024-01-22 15:13 eblake Name  => Eric Blake  
2024-01-22 15:13 eblake Organization  => Red Hat 
2024-01-22 15:13 eblake User Reference=> ebb.posix_getdents
2024-01-22 15:13 eblake Section   => XSH posix_getdents
2024-01-22 15:13 eblake Page Number   => 1567
2024-01-22 15:13 eblake Line Number   => 52609   
2024-01-22 15:30 eblake Note Added: 0006632  
==

[Issue 8 drafts 0001798]: Must posix_getdents remember file offsets across exec?

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been SUBMITTED. 
== 
https://austingroupbugs.net/view.php?id=1798 
== 
Reported By:eblake
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1798
Category:   System Interfaces
Type:   Clarification Requested
Severity:   Objection
Priority:   normal
Status: New
Name:   Eric Blake 
Organization:   Red Hat 
User Reference: ebb.posix_getdents 
Section:XSH posix_getdents 
Page Number:1567 
Line Number:52609 
Final Accepted Text: 
== 
Date Submitted: 2024-01-22 15:13 UTC
Last Modified:  2024-01-22 15:13 UTC
== 
Summary:Must posix_getdents remember file offsets across
exec?
Description: 
The RATIONALE for fdopendir( ) (page 922) states that POSIX imposes
no constraints on what may happen for "the use or referencing of a
dirp value or a dirent structure value ... after a
fork( ) or one of the exec function calls."  Issue 8 added
the posix_getdents( ) interface, and one of our goals was to allow
it to be implemented on top of a hidden DIR* object for implementations
where readdir( ) and friends already track file types as an
extension.

In trying to implement posix_getdents( ) for Cygwin, the choice was made to
use a hidden DIR* object, opened on the first call to posix_getdents() for
any fd , and where subsequent lseek() of the fd map to telldir()/seekdir()
of the underlying DIR*.  This works even for the case of dup() within a
single process; but for fork() without exec, it is prohibitive to keep
synchronization of the offset between the two copies, and after exec the
underlying DIR* state is no longer available on the newly-exec'd process. 
It seems like most portable uses of getdent() were limited to a single
process; it might help if the standard explicitly calls out the
non-portability of exepcting directory offsets to be preserved across
fork() and exec(), so that an implementation that uses an underlying DIR*
is not hitting hard walls about the synchronized use of that DIR* across
fork.
Desired Action: 
(Draft 4 locations)
On page 1567, line 52616 (posix_getdents DESCRIPTION),
change:The behavior is unspecified if lseek( ) is used
to set the file offset to a value other than zero or a value returned by a
previous call to lseek( ) on the same open file
description.to:The behavior is unspecified if
lseek( ) is used to set the file offset to a value other than zero
or a value returned by a previous call to lseek( ) on the same open
file description; likewise, the behavior is unspecified if attempting to
use posix_getdents( ) on a file descriptor after an exec call
or in the child process of a fork( ) or _Fork( ) call if the
file descriptor was at a non-zero offset before the call, without first
using lseek( ) to set the file offset back to zero.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-01-22 15:13 eblake New Issue
2024-01-22 15:13 eblake Name  => Eric Blake  
2024-01-22 15:13 eblake Organization  => Red Hat 
2024-01-22 15:13 eblake User Reference=> ebb.posix_getdents
2024-01-22 15:13 eblake Section   => XSH posix_getdents
2024-01-22 15:13 eblake Page Number   => 1567
2024-01-22 15:13 eblake Line Number   => 52609   
==

[Issue 8 drafts 0001789]: if command name contains slash, it cannot be arg0 for execl()

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1789 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1789
Category:   Shell and Utilities
Type:   Error
Severity:   Objection
Priority:   normal
Status: Resolved
Name:   Mark Galeck 
Organization:
User Reference:  
Section:Volume 2, Chapter 3 
Page Number:865, 2487 
Line Number:80936, 29495 
Final Accepted Text:see
https://austingroupbugs.net/view.php?id=1789#c6621 
Resolution: Accepted As Marked
Fixed in Version:   
== 
Date Submitted: 2023-11-22 02:24 UTC
Last Modified:  2024-01-19 19:31 UTC
== 
Summary:if command name contains slash, it cannot be arg0
for execl()
==
Relationships   ID  Summary
--
related to  0001645 execvp( ) requirements on arg0 are too ...
== 

-- 
 (0006631) larryv (reporter) - 2024-01-19 19:31
 https://austingroupbugs.net/view.php?id=1789#c6631 
-- 
Re: https://austingroupbugs.net/view.php?id=1789#c6621:The string in
arg0 or argv[0] is
typically the basename of the path of the file being executed. However,
there is no requirement in this standard that this is so, and the program
executed will see this string in the first element of the argv[]
array passed to its main() function, and may alter its functionality
based on this.Minor copyediting nit, but the first clause of
the second sentence seems more closely related to the first sentence than
to the rest of the second sentence. Suggestion:The string in
arg0 or argv[0] is typically the basename of the path of the
file being executed, but this standard does not require it to be so. The
program executed will see this string in the first element of the
argv[] array passed to its main() function and may alter its
functionality based on it. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-11-22 02:24 Mark_GaleckNew Issue
2023-11-22 02:24 Mark_GaleckName  => Mark Galeck 
2023-11-22 02:24 Mark_GaleckSection   => Volume 2, Chapter 3
2023-11-22 02:24 Mark_GaleckPage Number   => 865, 2487   
2023-11-22 02:24 Mark_GaleckLine Number   => 80936, 29495
2023-11-22 06:20 larryv Note Added: 0006579  
2023-11-22 07:18 Don Cragun Note Added: 0006580  
2023-11-22 07:19 Don Cragun Project 
1003.1(2016/18)/Issue7+TC2 => Issue 8 drafts
2023-11-22 07:21 Don Cragun version   => Draft 3 
2023-11-22 09:42 Guy Harris Note Added: 0006581  
2023-11-22 09:57 Guy Harris Note Added: 0006582  
2023-12-11 14:58 geoffclare Note Added: 0006596  
2024-01-15 16:40 nick   Relationship added   related to 0001645  
2024-01-15 17:28 nick   Note Added: 0006621  
2024-01-15 17:29 nick   Final Accepted Text   => see
https://austingroupbugs.net/view.php?id=1789#c6621
2024-01-15 17:29 nick   Status   New => Resolved 
2024-01-15 17:29 nick   Resolution   Open => Accepted As
Marked
2024-01-15 17:30 nick   Tag Attached: tc1-2024   
2024-01-15 17:31 nick   Note Edited: 0006621 
2024-01-17 17:43 gbrandenrobinsonNote Added: 0006626  
2024-01-18 16:08 nick   Note Edited: 0006621 
2024-01-18 16:08 nick   Note Added: 0006627  
2024-01-18 16:09 nick   Note Added: 0006628  
2024-01-18 16:10 nick   Note Deleted: 0006628
2024-01-18 16:44 eblake Note Edited: 0006621 
2024-01-19 19:31 larryv 

Minutes of the 18th January 2024 Teleconference

[Andrew Josey via austin-group-l at The Open Group]

All
Enclosed are the minutes of yesterday’s meeting
regards
Andrew
-

Minutes of the 18th January 2024 TeleconferenceAustin-1377 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 19th January 2024

Attendees:
Don Cragun, IEEE SA OR
Nick Stoughton, Logitech/USENIX, ISO/IEC JTC 1/SC 22 OR
Mark Ziegast, SHware Systems Dev.
Eric Ackermann 
Andrew Josey, The Open Group
Eric Blake, Red Hat, The Open Group OR

Apologies
Tom Thompson, IEEE
Geoff Clare, The Open Group

* General news

Draft 4 is still in review at The Open Group and IEEE, with the
review closing on January 31 2024. No comments have been received
as yet.

* Current Business

Bug 1789: if command name contains slash, it cannot be arg0 for execl() 
Accepted as Marked
https://austingroupbugs.net/view.php?id=1789

We revisited this based on comments received.
Note: 0006621 has been updated to break the run-on sentence as suggested. 



Bug 1790: More info on *ALT* constants Accepted as Marked
https://austingroupbugs.net/bug_view_page.php?bug_id=1790

This item is tagged for TC1-2024

(D4 page and line numbers.)
Add to Application Usage, page 277 after line 9645:


For languages having both a genitive (when used with a day
number) and a nominative (no day number) case, the "alternative"
month names described here are for use when a nominative case
is required, see XREF 7.3.5.1 LC_TIME Locale Definition.

Bug 1791: tr: clarify encdings of non-characters bytes and proper encodings of 
the NUL byte and OPEN
https://austingroupbugs.net/bug_view_page.php?bug_id=1791

We started on this item and will continue on the next call.

Next Steps
--
  
The next call is on:
  Mon 2024-01-22 (Zoom meeting - general bugs)
  Thu 2024-01-25 (Zoom meeting - general bugs)

The calls are for 90 minutes

Calls are anchored on US time. (8am Pacific)

Apologies in Advance:
Geoff Clare, 2024-01-22 

Please check the calendar invites for dial in details.

Bugs are at:
https://austingroupbugs.net

An etherpad is usually up for the meeting, with a URL using the date format as 
below:

https://posix.rhansen.org/p/20xx-mm-dd

(For write access this uses The Open Group single sign on,
for those individuals with gitlab.opengroup.org accounts.
Please contact Andrew if you need to be setup)


Andrew JoseyThe Open Group
Austin Group Chair  
Email: a.jo...@opengroup.org 
Apex Plaza, Forbury Road,Reading,Berks.RG1 1AX,England

To learn how we maintain your privacy, please review The Open Group Privacy 
Statement at http://www.opengroup.org/privacy.
To unsubscribe/opt-out from this mailing list login to The Open Group 
collaboration portal at
https://collaboration.opengroup.org/operational/portal.php?action=unsub=2481

[1003.1(2016/18)/Issue7+TC2 0001790]: More info on *ALT* constants

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been RESOLVED. 
== 
https://austingroupbugs.net/view.php?id=1790 
== 
Reported By:steffen
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1790
Category:   Base Definitions and Headers
Type:   Clarification Requested
Severity:   Editorial
Priority:   normal
Status: Resolved
Name:   steffen 
Organization:
User Reference:  
Section:langinfo.h 
Page Number:276 
Line Number:9587 pp, 9611 pp 
Interp Status:  --- 
Final Accepted Text:See
https://austingroupbugs.net/view.php?id=1790#c6630 
Resolution: Accepted As Marked
Fixed in Version:   
== 
Date Submitted: 2023-12-01 21:00 UTC
Last Modified:  2024-01-18 17:12 UTC
== 
Summary:More info on *ALT* constants
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-12-01 21:00 steffenNew Issue
2023-12-01 21:00 steffenName  => steffen 
2023-12-01 21:00 steffenSection   => langinfo.h  
2023-12-01 21:00 steffenPage Number   => 276 
2023-12-01 21:00 steffenLine Number   => 9587 pp, 9611 pp
2024-01-15 18:33 shware_systems Note Added: 0006622  
2024-01-17 00:00 steffenNote Added: 0006625  
2024-01-18 17:08 shware_systems Note Added: 0006629  
2024-01-18 17:11 nick   Note Added: 0006630  
2024-01-18 17:12 nick   Interp Status => --- 
2024-01-18 17:12 nick   Final Accepted Text   => See
https://austingroupbugs.net/view.php?id=1790#c6630
2024-01-18 17:12 nick   Status   New => Resolved 
2024-01-18 17:12 nick   Resolution   Open => Accepted As
Marked
==

[1003.1(2016/18)/Issue7+TC2 0001790]: More info on *ALT* constants

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1790 
== 
Reported By:steffen
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1790
Category:   Base Definitions and Headers
Type:   Clarification Requested
Severity:   Editorial
Priority:   normal
Status: New
Name:   steffen 
Organization:
User Reference:  
Section:langinfo.h 
Page Number:276 
Line Number:9587 pp, 9611 pp 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2023-12-01 21:00 UTC
Last Modified:  2024-01-18 17:11 UTC
== 
Summary:More info on *ALT* constants
== 

-- 
 (0006630) nick (manager) - 2024-01-18 17:11
 https://austingroupbugs.net/view.php?id=1790#c6630 
-- 
D4 page and line numbers.
Add to Application Usage, page 277 after line 9645:
For languages having both a genitive (when used with a day
number) and a nominative (no day number) case, the "alternative" month
names described here are for use when a nominative case is required, see
XREF 7.3.5.1 LC_TIME Locale Definition. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-12-01 21:00 steffenNew Issue
2023-12-01 21:00 steffenName  => steffen 
2023-12-01 21:00 steffenSection   => langinfo.h  
2023-12-01 21:00 steffenPage Number   => 276 
2023-12-01 21:00 steffenLine Number   => 9587 pp, 9611 pp
2024-01-15 18:33 shware_systems Note Added: 0006622  
2024-01-17 00:00 steffenNote Added: 0006625  
2024-01-18 17:08 shware_systems Note Added: 0006629  
2024-01-18 17:11 nick   Note Added: 0006630  
==

[1003.1(2016/18)/Issue7+TC2 0001790]: More info on *ALT* constants

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1790 
== 
Reported By:steffen
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1790
Category:   Base Definitions and Headers
Type:   Clarification Requested
Severity:   Editorial
Priority:   normal
Status: New
Name:   steffen 
Organization:
User Reference:  
Section:langinfo.h 
Page Number:276 
Line Number:9587 pp, 9611 pp 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2023-12-01 21:00 UTC
Last Modified:  2024-01-18 17:08 UTC
== 
Summary:More info on *ALT* constants
== 

-- 
 (0006629) shware_systems (reporter) - 2024-01-18 17:08
 https://austingroupbugs.net/view.php?id=1790#c6629 
-- 
Apologies, I was confusing the ALT and ERA constants, and it is ERA that
represents other calendars. XBD 7 is explicit ALT strings are for the
nominitive case, if a language has one, and no ALT is for the genitive
case. The standard doesn't address additional cases like partitive so
perhaps a proposal for that is warranted. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-12-01 21:00 steffenNew Issue
2023-12-01 21:00 steffenName  => steffen 
2023-12-01 21:00 steffenSection   => langinfo.h  
2023-12-01 21:00 steffenPage Number   => 276 
2023-12-01 21:00 steffenLine Number   => 9587 pp, 9611 pp
2024-01-15 18:33 shware_systems Note Added: 0006622  
2024-01-17 00:00 steffenNote Added: 0006625  
2024-01-18 17:08 shware_systems Note Added: 0006629  
==

Austin Group teleconference +1 888 974 9888 PIN 618 156 403

[Single UNIX Specification via austin-group-l at The Open Group]

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//opengroup.org//NONSGML kigkonsult.se iCalcreator 2.22.1//
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:America/New_York
X-LIC-LOCATION:America/New_York
BEGIN:DAYLIGHT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
DTSTART:20120311T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
DTSTART:20121104T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:65a94f1569...@opengroup.org
DTSTAMP:20240118T161725Z
ATTENDEE;ROLE=CHAIR:MAILTO:a.jo...@opengroup.org
CREATED:20240118T00Z
DESCRIPTION:Web/Project: Single UNIX Specification\nTitle: Austin Group tel
 econference +1 888 974 9888 PIN 618 156 403\nDate/Time: 25-Jan-2024 at 11:
 00 America/New_York\nDuration: 1.50 hours\nURL: https://collaboration.open
 group.org/platform/single_unix_specification/events.php\n\nAll calls are a
 nchored on US time\n\nTopic: Austin Group teleconference\n
 ---\nAudio conference information\n---
 \n\nYou are invited to
  a Zoom meeting.\n\nMeeting ID: 618 156 403\n\nJoin from PC\, Mac\, iOS or
  Android: https://logitech.zoom.us/j/618156403\n \nor join by phone:\nUS: 
 888 974 9888\nUK: 800 031 5717\nDE: 800 724 3138\nFR: 805 082 588\n\nOther
  international numbers available here:\nhttps://zoom.us/u/adlvrb8ILj\n \n 
Meeting ID: 618 156 403\n\nor join from a H.323/SIP Device:\nDial: 
 162.255.37.11 (US West) or 162.255.36.11 (US East)\nMeeting ID: 618 15
 6 403\n\nShare from a PC or MAC: https://zoom.us/share/618156403\n\nOr iPh
 one one-tap (US Toll):  +16699006833\,618156403# or +16465588656\,61815640
 3#\n\nPassword for zoom call  ends with x\n\nAll Austin Group participants
  are most welcome to join the call.\nThe call will last for 90 minutes.\n
 \n\nAn etherpad is usually up for a meeting\, with a URL using the date fo
 rmat as below:\n\nhttps://posix.rhansen.org/p/202x-mm-dd\n\nLOGIN REQUIRED
  to write to the ETHERPAD (Use your gitlab.opengroup.org login.)\n\n \n\nB
 ug reports are available at:\nhttps://www.austingroupbugs.net\n
DTSTART;TZID=America/New_York:20240125T11
DURATION:PT1H30M0S
LAST-MODIFIED:20240118T111725Z
ORGANIZER;CN=Single UNIX Specification:MAILTO:do-not-re...@opengroup.org
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Austin Group teleconference +1 888 974 9888 PIN 618 156 403
TRANSP:OPAQUE
URL:https://collaboration.opengroup.org/platform/single_unix_specification/
 events.php
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-VISIBILITY:40
X-JOINBEFORE:5
X-CATEGORY:Teleconference
X-PLATO-SITE:Single UNIX Specification
X-PLATO-SITEID:136
END:VEVENT
END:VCALENDAR


meeting.ics
Description: application/ics

[Issue 8 drafts 0001789]: if command name contains slash, it cannot be arg0 for execl()

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1789 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1789
Category:   Shell and Utilities
Type:   Error
Severity:   Objection
Priority:   normal
Status: Resolved
Name:   Mark Galeck 
Organization:
User Reference:  
Section:Volume 2, Chapter 3 
Page Number:865, 2487 
Line Number:80936, 29495 
Final Accepted Text:see
https://austingroupbugs.net/view.php?id=1789#c6621 
Resolution: Accepted As Marked
Fixed in Version:   
== 
Date Submitted: 2023-11-22 02:24 UTC
Last Modified:  2024-01-18 16:09 UTC
== 
Summary:if command name contains slash, it cannot be arg0
for execl()
==
Relationships   ID  Summary
--
related to  0001645 execvp( ) requirements on arg0 are too ...
== 

-- 
 (0006628) nick (manager) - 2024-01-18 16:09
 https://austingroupbugs.net/view.php?id=1789#c6628 
-- 
https://austingroupbugs.net/view.php?id=1789#c6621 has been updated to break the
run-on sentence as suggested. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-11-22 02:24 Mark_GaleckNew Issue
2023-11-22 02:24 Mark_GaleckName  => Mark Galeck 
2023-11-22 02:24 Mark_GaleckSection   => Volume 2, Chapter 3
2023-11-22 02:24 Mark_GaleckPage Number   => 865, 2487   
2023-11-22 02:24 Mark_GaleckLine Number   => 80936, 29495
2023-11-22 06:20 larryv Note Added: 0006579  
2023-11-22 07:18 Don Cragun Note Added: 0006580  
2023-11-22 07:19 Don Cragun Project 
1003.1(2016/18)/Issue7+TC2 => Issue 8 drafts
2023-11-22 07:21 Don Cragun version   => Draft 3 
2023-11-22 09:42 Guy Harris Note Added: 0006581  
2023-11-22 09:57 Guy Harris Note Added: 0006582  
2023-12-11 14:58 geoffclare Note Added: 0006596  
2024-01-15 16:40 nick   Relationship added   related to 0001645  
2024-01-15 17:28 nick   Note Added: 0006621  
2024-01-15 17:29 nick   Final Accepted Text   => see
https://austingroupbugs.net/view.php?id=1789#c6621
2024-01-15 17:29 nick   Status   New => Resolved 
2024-01-15 17:29 nick   Resolution   Open => Accepted As
Marked
2024-01-15 17:30 nick   Tag Attached: tc1-2024   
2024-01-15 17:31 nick   Note Edited: 0006621 
2024-01-17 17:43 gbrandenrobinsonNote Added: 0006626  
2024-01-18 16:08 nick   Note Edited: 0006621 
2024-01-18 16:08 nick   Note Added: 0006627  
2024-01-18 16:09 nick   Note Added: 0006628  
==

Re: [AI] does all smart watch and fitband have android?

[Austin Pinto]

or you can go for the samsung galaxy watch 6 but 1 thing to consider,
ware os watches cant work with apple phone as the ware os watches
require respected apps to be installed on the phone like the pixel
watch requires the pixel watch app and the fitbit app on the phone,
the samsung galaxy watch requires galaxy wareable and samsung health
moniter app but correct me if i am wrong ios users, iphone doesnt have
pixel watch app or galaxy wareable watch or health moniter app for
apple. so ware os watches will only work properly on android phone and
apple watch os will only work properly on iphones

On 1/18/24, Satguru Rathi  wrote:
> Hi,
> If you want to invest in smart watch, specially an android based one,
> make sure that it runs the WearOs 3 or above as assistant support is not
> available on the lower versions of WearOs. Check out Mobvoi Tic watch 5
> pro or similar watches which support both Android and Ios. If you want
> to start with the more affordable watches, Mobvoi Ticwatch E3 can be a
> good option as a beginner which is available for around 1 and
> supports WearOs3.
>
> With best regards,
>
> Satguru Rathi
>
> Assistant Manager
>
> Baroda UP Bank <https://www.barodaupbank.in/>
>
> Main Branch - Bareilly
>
> Contact: +919871489945
>
> "SAVE PAPER – THINK BEFORE YOU PRINT"
>
> Disclaimer:*
>
> This email (including any attachments) is intended for the sole use of
> the intended recipient/s and may contain material that is CONFIDENTIAL
> AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or
> copying or distribution or forwarding of any or all of the contents in
> this message is STRICTLY PROHIBITED. If you are not the intended
> recipient, please contact the sender <mailto:satgurura...@gmail.com>and
> delete all copies. Your cooperation in this regard is appreciated.
>
> ***
>
> On 1/18/2024 3:47 PM, UDIT Pandey wrote:
>> so,
>> if I can find a watch which has where os in it. And, can be pared with
>> Boath apple and android, I can purchase as it is accessible?
>>
>> On Thu, 18 Jan 2024 at 15:12, Austin Pinto
>>  wrote:
>>
>> smart watch doesnt have a full thing called android it doesnt support
>> all the apps that work on your phone, but it has ware os which is a
>> slimmed down version of android and there are some apps made for it.
>> talkback works on ware os.
>> to be sure, pixel watches, samsung galaxy watch 4 and newer, some
>> garmen and fossel watches have ware os.
>> but fitness bands dont have them because they are extremely low
>> powered.
>> so if you see a smart watch with ware os or apple watch os it is
>> accessable.
>> but some or most of the smart watch work only with the phone of
>> the manufacturer
>> like, apple watch will only work with ios. samsung galaxy watch will
>> work with other android phones but for blood oxygen and ecg you will
>> only need it to be used with a samsung phone, how ever there are ways
>> to go around this by installed a moded apk of samsung health on the
>> phone and watch
>> pixel watches only work with pixel phones, they may work on other
>> android phones but with limited features.
>>
>> On 1/18/24, UDIT Pandey  wrote:
>> > hi all,
>> > I was just thinking if a watch have an android os. Can we use
>> talkback in
>> > it? is possible?
>> >
>> > --
>> > Disclaimer:
>> > 1. Contents of the mails, factual, or otherwise, reflect the
>> thinking of the
>> > person sending the mail and AI in no way relates itself to its
>> veracity;
>> >
>> > 2. AI cannot be held liable for any commission/omission based on
>> the mails
>> > sent through this mailing list..
>> >
>> >
>> > Search for old postings at:
>> > http://www.mail-archive.com/accessindia@accessindia.org.in/
>> > ---
>> > You received this message because you are subscribed to the
>> Google Groups
>> > "AccessIndia" group.
>> > To unsubscribe from this group and stop receiving emails from
>> it, send an
>> > email to accessindia+unsubscr...@accessindia.org.in
>> <mailto:accessindia%2bunsubscr...@accessindia.org.in>.
>> > To view this discus

Re: [AI] does all smart watch and fitband have android?

[Austin Pinto]

smart watch doesnt have a full thing called android it doesnt support
all the apps that work on your phone, but it has ware os which is a
slimmed down version of android and there are some apps made for it.
talkback works on ware os.
to be sure, pixel watches, samsung galaxy watch 4 and newer, some
garmen and fossel watches have ware os.
but fitness bands dont have them because they are extremely low powered.
so if you see a smart watch with ware os or apple watch os it is accessable.
but some or most of the smart watch work only with the phone of the manufacturer
like, apple watch will only work with ios. samsung galaxy watch will
work with other android phones but for blood oxygen and ecg you will
only need it to be used with a samsung phone, how ever there are ways
to go around this by installed a moded apk of samsung health on the
phone and watch
pixel watches only work with pixel phones, they may work on other
android phones but with limited features.

On 1/18/24, UDIT Pandey  wrote:
> hi all,
> I was just thinking if a watch have an android os. Can we use talkback in
> it? is possible?
>
> --
> Disclaimer:
> 1. Contents of the mails, factual, or otherwise, reflect the thinking of the
> person sending the mail and AI in no way relates itself to its veracity;
>
> 2. AI cannot be held liable for any commission/omission based on the mails
> sent through this mailing list..
>
>
> Search for old postings at:
> http://www.mail-archive.com/accessindia@accessindia.org.in/
> ---
> You received this message because you are subscribed to the Google Groups
> "AccessIndia" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to accessindia+unsubscr...@accessindia.org.in.
> To view this discussion on the web visit
> https://groups.google.com/a/accessindia.org.in/d/msgid/accessindia/CAJZg8feCw3-h367YNOJG0J%2B3KZKBQHMUszx7Sipgz0aCJEoYfA%40mail.gmail.com.
>


-- 
to listen to the Blind Android Users Podcast visit.
www.blindandroidusers.com
To join our mailing list, send those “join requests” to:
blindandroidusers+subscr...@groups.io
You may follow us on twitter using our handle:
@BlindDroidUsers
https://twitter.com/@BlindDroidUsers
We do have a Telegram group that you can join and share stories or
whatever with our members at:
https://t.me/ANATAD

-- 
Disclaimer:
1. Contents of the mails, factual, or otherwise, reflect the thinking of the 
person sending the mail and AI in no way relates itself to its veracity;

2. AI cannot be held liable for any commission/omission based on the mails sent 
through this mailing list..


Search for old postings at:
http://www.mail-archive.com/accessindia@accessindia.org.in/
--- 
You received this message because you are subscribed to the Google Groups 
"AccessIndia" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to accessindia+unsubscr...@accessindia.org.in.
To view this discussion on the web visit 
https://groups.google.com/a/accessindia.org.in/d/msgid/accessindia/CAPeFyi_J7n9YU3zHM4KxdTyGH8g5CwT8aotG0uc1Gt1e1eWG4w%40mail.gmail.com.

Re: [1003.1(2008)/Issue 7 0001219]: snprintf reequirement to fail when n > INT_MAX conflicts with C

[Robert Elz via austin-group-l at The Open Group]

Actually, apologies - forget my previous reply - the change to the
fwprintf() page (for swprintf()) did happen as the resolution of that
bug specified.

No idea how I looked at that (I had the page still open when I went
back to it just now) and failed to see that the text had been changed.
But I did.

What made you believe that nothing had been done there?

kre

Re: [1003.1(2008)/Issue 7 0001219]: snprintf reequirement to fail when n > INT_MAX conflicts with C

[Robert Elz via austin-group-l at The Open Group]

Date:Wed, 17 Jan 2024 17:54:23 -0500
From:"Rich Felker via austin-group-l at The Open Group" 

Message-ID:  <20240117225423.gb24...@brightrain.aerifal.cx>

  | I went to apply the resolution of this issue to musl libc and noticed
  | that the corresponding issue in swprintf was never brought up or
  | addressed. Should I open a new issue for it or can it be fixed along
  | with this?

Actually, I think it was, the accepted resolution contains:

Change page 990 line 33924 in D2.1 from:

The value of n is greater than {INT_MAX}.

to:

The number of wide characters requested to be written was n or more.

Page 990 is in the fwprintf() page in D2.1, and line 990, is the one which
says the "from" above in the paragraph:

   The swprintf( ) shall fail if:
CX [EOVERFLOW] The value of n is greater than {INT_MAX}.

So, I think it was intended that the change be applied, and it
simply didn't happen.   Now it has been pointed out, no more
action should be required - that one should simply get fixed.

The change for snprintf() simply deleted that whole error, that is
the:
Delete lines 30917-30918 in D2.1 (page 904).

part of Note 5895 in that mantis issue.   That one happened.

kre

Re: [1003.1(2008)/Issue 7 0001219]: snprintf reequirement to fail when n > INT_MAX conflicts with C

[Rich Felker via austin-group-l at The Open Group]

On Mon, Jul 18, 2022 at 03:49:11PM +, Austin Group Bug Tracker via 
austin-group-l at The Open Group wrote:
> 
> The following issue has been RESOLVED. 
> == 
> https://austingroupbugs.net/view.php?id=1219 
> == 
> Reported By:sebor
> Assigned To:ajosey
> == 
> Project:1003.1(2008)/Issue 7
> Issue ID:   1219
> Category:   System Interfaces
> Type:   Error
> Severity:   Objection
> Priority:   normal
> Status: Resolved
> Name:   Martin Sebor 
> Organization:
> User Reference:  
> Section:snprintf 
> Page Number:906 
> Line Number:30447 
> Interp Status:  --- 
> Final Accepted Text: 
> Resolution: Accepted As Marked
> Fixed in Version:   
> == 
> Date Submitted: 2018-12-12 17:29 UTC
> Last Modified:  2022-07-18 15:49 UTC
> == 
> Summary:snprintf reequirement to fail when n > INT_MAX
> conflicts with C
> ==
> Relationships   ID  Summary
> --
> related to  761 Requirement of error for snprintf with ...
> == 
> 
> -- 
>  (0005895) Don Cragun (manager) - 2022-07-18 15:49
>  https://austingroupbugs.net/view.php?id=1219#c5895 
> -- 
> Delete lines 30917-30918 in D2.1 (page 904).
> 
> Change page 990 line 33924 in D2.1 from:The value of n
> is greater than {INT_MAX}.to:The number of wide
> characters requested to be written was n or more. 
> 
> Issue History 
> Date ModifiedUsername   FieldChange   
> == 
> 2018-12-12 17:29 sebor  New Issue
> 2018-12-12 17:29 sebor  Status   New => Under Review 
> 2018-12-12 17:29 sebor  Assigned To   => ajosey  
> 2018-12-12 17:29 sebor  Name  => Martin Sebor
> 2018-12-12 17:29 sebor  Section   => snprintf
> 2018-12-12 17:29 sebor  Page Number   => 906 
> 2018-12-12 17:29 sebor  Line Number   => 30447   
> 2018-12-12 17:48 sebor  Note Added: 0004182  
> 2018-12-12 20:29 sebor  Note Added: 0004183  
> 2018-12-12 21:06 eblake Relationship added   related to 761  
> 2022-07-18 15:49 Don Cragun Interp Status => --- 
> 2022-07-18 15:49 Don Cragun Note Added: 0005895  
> 2022-07-18 15:49 Don Cragun Status   Under Review =>
> Resolved
> 2022-07-18 15:49 Don Cragun Resolution   Open => Accepted As
> Marked
> ==
> 

I went to apply the resolution of this issue to musl libc and noticed
that the corresponding issue in swprintf was never brought up or
addressed. Should I open a new issue for it or can it be fixed along
with this?

Rich

[Issue 8 drafts 0001789]: if command name contains slash, it cannot be arg0 for execl()

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1789 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1789
Category:   Shell and Utilities
Type:   Error
Severity:   Objection
Priority:   normal
Status: Resolved
Name:   Mark Galeck 
Organization:
User Reference:  
Section:Volume 2, Chapter 3 
Page Number:865, 2487 
Line Number:80936, 29495 
Final Accepted Text:see
https://austingroupbugs.net/view.php?id=1789#c6621 
Resolution: Accepted As Marked
Fixed in Version:   
== 
Date Submitted: 2023-11-22 02:24 UTC
Last Modified:  2024-01-17 17:43 UTC
== 
Summary:if command name contains slash, it cannot be arg0
for execl()
==
Relationships   ID  Summary
--
related to  0001645 execvp( ) requirements on arg0 are too ...
== 

-- 
 (0006626) gbrandenrobinson (reporter) - 2024-01-17 17:43
 https://austingroupbugs.net/view.php?id=1789#c6626 
-- 
"Most applications pass a filename string or a pathname string, a filename
string is more generally useful, since the common usage of argv[0] is in
printing diagnostics."

This is a run-on sentence.  I would resolve it by changing the first comma
to a period and updating subsequent *roff spacing (if necessary) and
capitalization afterwards.

Other solutions are possible, of course. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-11-22 02:24 Mark_GaleckNew Issue
2023-11-22 02:24 Mark_GaleckName  => Mark Galeck 
2023-11-22 02:24 Mark_GaleckSection   => Volume 2, Chapter 3
2023-11-22 02:24 Mark_GaleckPage Number   => 865, 2487   
2023-11-22 02:24 Mark_GaleckLine Number   => 80936, 29495
2023-11-22 06:20 larryv Note Added: 0006579  
2023-11-22 07:18 Don Cragun Note Added: 0006580  
2023-11-22 07:19 Don Cragun Project 
1003.1(2016/18)/Issue7+TC2 => Issue 8 drafts
2023-11-22 07:21 Don Cragun version   => Draft 3 
2023-11-22 09:42 Guy Harris Note Added: 0006581  
2023-11-22 09:57 Guy Harris Note Added: 0006582  
2023-12-11 14:58 geoffclare Note Added: 0006596  
2024-01-15 16:40 nick   Relationship added   related to 0001645  
2024-01-15 17:28 nick   Note Added: 0006621  
2024-01-15 17:29 nick   Final Accepted Text   => see
https://austingroupbugs.net/view.php?id=1789#c6621
2024-01-15 17:29 nick   Status   New => Resolved 
2024-01-15 17:29 nick   Resolution   Open => Accepted As
Marked
2024-01-15 17:30 nick   Tag Attached: tc1-2024   
2024-01-15 17:31 nick   Note Edited: 0006621 
2024-01-17 17:43 gbrandenrobinsonNote Added: 0006626  
==

Minutes of the 15th January 2024 Teleconference

[Andrew Josey via austin-group-l at The Open Group]

All
Enclosed are the minutes of the Monday call this week
regards
Andrew
--
Minutes of the 15th January 2024 TeleconferenceAustin-1376 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 17th January 2024

Attendees:
Don Cragun, IEEE SA OR
Nick Stoughton, Logitech/USENIX, ISO/IEC JTC 1/SC 22 OR
Mark Ziegast, SHware Systems Dev.
Eric Ackermann 
Andrew Josey, The Open Group
Eric Blake, Red Hat, The Open Group OR
Levon Tumanyan

Apologies
Tom Thompson, IEEE
Geoff Clare, The Open Group

* General news

Draft 4 is still in review at The Open Group and IEEE,
with the review closing on January 31 2024. No comments
have been received as yet.

We discussed when the ISO/IEC draft is due to go to ballot.
Andrew and Nick noted that is expected to be after the 
ballot on approving the use of line numbers concludes and that they would
check with Bill Ash.


* Current Business

Bug 1789: if command name contains slash, it cannot be arg0 for execl() 
Accepted as Marked
https://austingroupbugs.net/view.php?id=1789


On page 865 line 29495, 29499 change: (D4 p877 line 29519)
... should point to a filename string that is associated with
the process being started by one of the exec functions.
to:
... should point to a string that is associated with the with
the filename of the process being started by one of the exec
functions.

and add to Application Usage, page 872 after line 29773: (D4 p874 line 29796)
The string in arg0 or argv[0] is typically the basename of the
path of the file being executed. However, there is no requirement
in this standard that this is so, and the program executed will
see this string in the first element of the argv[] array passed
to its main() function, and may alter its functionality based
on this.

On page 872 Rationale, line 29785, change (D4 p874 line 29808)
... the first argument be a filename string associated with the
process being started. Although some existing applications pass
a pathname rather than a filename string in some circumstances,
a filename string is more generally useful, since the common
usage of argv[0] is in printing diagnostics. In some cases the
filename passed is not the actual filename of the file; for
example, many implementations of the login utility use a
convention of prefixing a  ('-') to the actual
filename, which indicates to the command interpreter being
invoked that it is a ``login shell’’.
to:
... the first argument be simply a string associated with the
filename of the process being started. Most applications pass
a filename string or a pathname string, a filename string is
more generally useful, since the common usage of argv[0] is in
printing diagnostics. In some cases the filename in the string
passed is not the actual filename of the file; for example,
many implementations of the login utility use a convention of
prefixing a  ('-') to the actual filename, which
indicates to the command interpreter being invoked that it is
a ``login shell’’.


Bug 1790: More info on *ALT* constants
https://austingroupbugs.net/bug_view_page.php?bug_id=1790

We will continue on this item on the next call.

Next Steps
--
  
The next call is on:
  Thu 2024-01-18 (Zoom meeting - general bugs)
  Mon 2024-01-22 (Zoom meeting - general bugs)

The calls are for 90 minutes

Calls are anchored on US time. (8am Pacific)

Apologies in Advance:
Geoff Clare, 2024-01-15 to 2024-01-22 inclusive

Please check the calendar invites for dial in details.

Bugs are at:
https://austingroupbugs.net

An etherpad is usually up for the meeting, with a URL using the date format as 
below:

https://posix.rhansen.org/p/20xx-mm-dd

(For write access this uses The Open Group single sign on,
for those individuals with gitlab.opengroup.org accounts.
Please contact Andrew if you need to be setup)


Andrew JoseyThe Open Group
Austin Group Chair  
Email: a.jo...@opengroup.org 
Apex Plaza, Forbury Road,Reading,Berks.RG1 1AX,England

To learn how we maintain your privacy, please review The Open Group Privacy 
Statement at http://www.opengroup.org/privacy.
To unsubscribe/opt-out from this mailing list login to The Open Group 
collaboration portal at
https://collaboration.opengroup.org/operational/portal.php?action=unsub=2481

Austin Group teleconference +1 888 974 9888 PIN 618 156 403

[Single UNIX Specification via austin-group-l at The Open Group]

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//opengroup.org//NONSGML kigkonsult.se iCalcreator 2.22.1//
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:America/New_York
X-LIC-LOCATION:America/New_York
BEGIN:DAYLIGHT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
DTSTART:20120311T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
DTSTART:20121104T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:65a7edcfd7...@opengroup.org
DTSTAMP:20240117T151008Z
ATTENDEE;ROLE=CHAIR:MAILTO:a.jo...@opengroup.org
CREATED:20240117T00Z
DESCRIPTION:Web/Project: Single UNIX Specification\nTitle: Austin Group tel
 econference +1 888 974 9888 PIN 618 156 403\nDate/Time: 22-Jan-2024 at 11:
 00 America/New_York\nDuration: 1.50 hours\nURL: https://collaboration.open
 group.org/platform/single_unix_specification/events.php\n\nAll calls are a
 nchored on US time\n\nTopic: Austin Group teleconference\n
 ---\nAudio conference information\n---
 \n\nYou are invited to
  a Zoom meeting.\n\nMeeting ID: 618 156 403\n\nJoin from PC\, Mac\, iOS or
  Android: https://logitech.zoom.us/j/618156403\n \nor join by phone:\nUS: 
 888 974 9888\nUK: 800 031 5717\nDE: 800 724 3138\nFR: 805 082 588\n\nOther
  international numbers available here:\nhttps://zoom.us/u/adlvrb8ILj\n \n 
Meeting ID: 618 156 403\n\nor join from a H.323/SIP Device:\nDial: 
 162.255.37.11 (US West) or 162.255.36.11 (US East)\nMeeting ID: 618 15
 6 403\n\nShare from a PC or MAC: https://zoom.us/share/618156403\n\nOr iPh
 one one-tap (US Toll):  +16699006833\,618156403# or +16465588656\,61815640
 3#\n\nPassword for zoom call  ends with x\n\nAll Austin Group participants
  are most welcome to join the call.\nThe call will last for 90 minutes.\n
 \n\nAn etherpad is usually up for a meeting\, with a URL using the date fo
 rmat as below:\n\nhttps://posix.rhansen.org/p/202x-mm-dd\n\nLOGIN REQUIRED
  to write to the ETHERPAD (Use your gitlab.opengroup.org login.)\n\n \n\nB
 ug reports are available at:\nhttps://www.austingroupbugs.net\n
DTSTART;TZID=America/New_York:20240122T11
DURATION:PT1H30M0S
LAST-MODIFIED:20240117T101008Z
ORGANIZER;CN=Single UNIX Specification:MAILTO:do-not-re...@opengroup.org
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Austin Group teleconference +1 888 974 9888 PIN 618 156 403
TRANSP:OPAQUE
URL:https://collaboration.opengroup.org/platform/single_unix_specification/
 events.php
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-VISIBILITY:40
X-JOINBEFORE:5
X-CATEGORY:Teleconference
X-PLATO-SITE:Single UNIX Specification
X-PLATO-SITEID:136
END:VEVENT
END:VCALENDAR


meeting.ics
Description: application/ics

Is there a Java takesocket method?

[Steve Austin]

I have an assembler program using ‘givesocket’ to give a socket to another
address space running a REXX using ‘takesocket’; this works fine. I’d like
to replace the REXX with a Java app, but I’ve not yet found a Java
takesocket method. My Java app is currently using java.net.ServerSocket and
java.net.Socket. Do I need to make a native call via the JNI for this? If
so, having taken the socket in the JNI how do I give it to the Java app? Is
there an example somewhere?

Thanks Steve

-- 
This e-mail message has been scanned and cleared by Google Message Security 
and the UNICOM Global security systems. This message is for the named 
person's use only. If you receive this message in error, please delete it 
and notify the sender. 

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

Re: [AI] Inquiry Regarding Accessible Laptops for the Visually Impaired

[Austin Pinto]

Shreyas chromebooks are accessable as the only thing you use is the
chrome browser.
it has its own screen reader but you cant use any windows apps or
software in it.
you will constently require active internet connection without it you
can only start the laptop and keep.
it has the best battery life but a low end cpu as it doesnt need high end.
you use apps like google drive for storage, google docks, for word
google sheets for excel
so for light work like browsing, or using online apps you can try it.

On 1/17/24, Shreyas Nagaraj reddy  wrote:
> Dear list..
> after a long time I get an opportunity to mail on this mailing list.
> Wish to ask your valuable feedback and opinion on how accessible r chrome
> book laptops for the visually impaired.
> Let me know kindly.
> Thanks in advance
>
> --
> Disclaimer:
> 1. Contents of the mails, factual, or otherwise, reflect the thinking of the
> person sending the mail and AI in no way relates itself to its veracity;
>
> 2. AI cannot be held liable for any commission/omission based on the mails
> sent through this mailing list..
>
>
> Search for old postings at:
> http://www.mail-archive.com/accessindia@accessindia.org.in/
> ---
> You received this message because you are subscribed to the Google Groups
> "AccessIndia" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to accessindia+unsubscr...@accessindia.org.in.
> To view this discussion on the web visit
> https://groups.google.com/a/accessindia.org.in/d/msgid/accessindia/CE05E20E-C45F-44B5-A1D9-F8621FED33F6%40gmail.com.
>


-- 
to listen to the Blind Android Users Podcast visit.
www.blindandroidusers.com
To join our mailing list, send those “join requests” to:
blindandroidusers+subscr...@groups.io
You may follow us on twitter using our handle:
@BlindDroidUsers
https://twitter.com/@BlindDroidUsers
We do have a Telegram group that you can join and share stories or
whatever with our members at:
https://t.me/ANATAD

-- 
Disclaimer:
1. Contents of the mails, factual, or otherwise, reflect the thinking of the 
person sending the mail and AI in no way relates itself to its veracity;

2. AI cannot be held liable for any commission/omission based on the mails sent 
through this mailing list..


Search for old postings at:
http://www.mail-archive.com/accessindia@accessindia.org.in/
--- 
You received this message because you are subscribed to the Google Groups 
"AccessIndia" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to accessindia+unsubscr...@accessindia.org.in.
To view this discussion on the web visit 
https://groups.google.com/a/accessindia.org.in/d/msgid/accessindia/CAPeFyi8%2B3dHBzxAUYA8YXRSzSmmQQfoQfCtaCXm4jps26JV1NQ%40mail.gmail.com.

[ovirt-users] Re: Cannot restart ovirt after massive failure.

[Austin Coppock]

Thanks Gilboa, Your comment here about performing a dd to clear the meta data 
just saved me having to rebuild a new Engine.  Much appreciated.

Austin
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/JBDPMZLVJCUNPDFGMD77PMGNAOSICEEG/

[1003.1(2016/18)/Issue7+TC2 0001790]: More info on *ALT* constants

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1790 
== 
Reported By:steffen
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1790
Category:   Base Definitions and Headers
Type:   Clarification Requested
Severity:   Editorial
Priority:   normal
Status: New
Name:   steffen 
Organization:
User Reference:  
Section:langinfo.h 
Page Number:276 
Line Number:9587 pp, 9611 pp 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2023-12-01 21:00 UTC
Last Modified:  2024-01-17 00:00 UTC
== 
Summary:More info on *ALT* constants
== 

-- 
 (0006625) steffen (reporter) - 2024-01-17 00:00
 https://austingroupbugs.net/view.php?id=1790#c6625 
-- 
I do not think so.  (I would not have thought that ALT does the great to
handle entire calendar systems?) 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-12-01 21:00 steffenNew Issue
2023-12-01 21:00 steffenName  => steffen 
2023-12-01 21:00 steffenSection   => langinfo.h  
2023-12-01 21:00 steffenPage Number   => 276 
2023-12-01 21:00 steffenLine Number   => 9587 pp, 9611 pp
2024-01-15 18:33 shware_systems Note Added: 0006622  
2024-01-17 00:00 steffenNote Added: 0006625  
==

Re: mantis does not email-emit my web edits?

[Steffen Nurpmeso via austin-group-l at The Open Group]

Steffen Nurpmeso via austin-group-l at The Open Group wrote in
 <20240108212050.2X5aptGT@steffen%sdaoden.eu>:
 |It seems Mantis did record, but not actually post my web edits of
 |this year, including the opened issue on tzalloc etc.
 |It would be nice if these would come :)

It seems

  https://austingroupbugs.net/view.php?id=1794

  0001794: Please add tzalloc/tzfree and localtime_rz, mktime_z interfaces 

from 2024-01-06 has still not been posted to the ML says the
mail-archive.
Just so that it is known that this issue has been created.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[Issue 8 drafts 0001797]: strftime "%s" should be able to examine tm_gmtoff

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://www.austingroupbugs.net/view.php?id=1797 
== 
Reported By:eggert
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1797
Category:   System Interfaces
Type:   Error
Severity:   Objection
Priority:   normal
Status: New
Name:   Paul Eggert 
Organization:   UCLA Computer Science Dept. 
User Reference: strftime-%s 
Section:strftime 
Page Number:2136 
Line Number:69836-69837 
Final Accepted Text: 
== 
Date Submitted: 2024-01-15 23:56 UTC
Last Modified:  2024-01-16 01:42 UTC
== 
Summary:strftime "%s" should be able to examine tm_gmtoff
== 

-- 
 (0006624) steffen (reporter) - 2024-01-16 01:42
 https://www.austingroupbugs.net/view.php?id=1797#c6624 
-- 
Wait, i see what is meant. I delete my note. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-01-15 23:56 eggert New Issue
2024-01-15 23:56 eggert Name  => Paul Eggert 
2024-01-15 23:56 eggert Organization  => UCLA Computer
Science Dept.
2024-01-15 23:56 eggert User Reference=> strftime-%s 
2024-01-15 23:56 eggert Section   => strftime
2024-01-15 23:56 eggert Page Number   => 2136
2024-01-15 23:56 eggert Line Number   => 69836-69837 
2024-01-16 01:29 steffenNote Added: 0006623  
2024-01-16 01:42 steffenNote Added: 0006624  
==

[Issue 8 drafts 0001797]: strftime "%s" should be able to examine tm_gmtoff

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://www.austingroupbugs.net/view.php?id=1797 
== 
Reported By:eggert
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1797
Category:   System Interfaces
Type:   Error
Severity:   Objection
Priority:   normal
Status: New
Name:   Paul Eggert 
Organization:   UCLA Computer Science Dept. 
User Reference: strftime-%s 
Section:strftime 
Page Number:2136 
Line Number:69836-69837 
Final Accepted Text: 
== 
Date Submitted: 2024-01-15 23:56 UTC
Last Modified:  2024-01-16 01:29 UTC
== 
Summary:strftime "%s" should be able to examine tm_gmtoff
== 

-- 
 (0006623) steffen (reporter) - 2024-01-16 01:29
 https://www.austingroupbugs.net/view.php?id=1797#c6623 
-- 
I must have misunderstood something.
POSIX says %s acts "as if mktime is called".
Now if i modify your program

  #include 
  #include 
  #include 

  int
  main ()
  {
char buf[100];
time_t t = 1197184500, t2;
struct tm *tmp;

setenv ("TZ", "America/Caracas", 1);
strftime (buf, sizeof buf, "%s = %Y-%m-%d %H:%M:%S %z (%Z) in Caracas",
tmp = localtime ());

t2 = mktime(tmp);
printf ("%lld prints as %s, mktime=%lld\n", (long long) t, buf, (long
long)t2);
if (atoll (buf) != t)
  puts ("time_t mismatch!");
  }

and run it i get

  1197184500 prints as 1197182700 = 2007-12-09 02:45:00 -0430 (-0430) in
Caracas, mktime=1197182700
  time_t mismatch!

So it worked as desired?  Or?
I mean i do agree the behaviour is odd, but it is definetely the behaviour
that exists in current implementations!
It is documented that way for strftime(3) on my GNU libc box. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-01-15 23:56 eggert New Issue
2024-01-15 23:56 eggert Name  => Paul Eggert 
2024-01-15 23:56 eggert Organization  => UCLA Computer
Science Dept.
2024-01-15 23:56 eggert User Reference=> strftime-%s 
2024-01-15 23:56 eggert Section   => strftime
2024-01-15 23:56 eggert Page Number   => 2136
2024-01-15 23:56 eggert Line Number   => 69836-69837 
2024-01-16 01:29 steffenNote Added: 0006623  
==

[Issue 8 drafts 0001797]: strftime "%s" should be able to examine tm_gmtoff

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been SUBMITTED. 
== 
https://www.austingroupbugs.net/view.php?id=1797 
== 
Reported By:eggert
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1797
Category:   System Interfaces
Type:   Error
Severity:   Objection
Priority:   normal
Status: New
Name:   Paul Eggert 
Organization:   UCLA Computer Science Dept. 
User Reference: strftime-%s 
Section:strftime 
Page Number:2136 
Line Number:69836-69837 
Final Accepted Text: 
== 
Date Submitted: 2024-01-15 23:56 UTC
Last Modified:  2024-01-15 23:56 UTC
== 
Summary:strftime "%s" should be able to examine tm_gmtoff
Description: 
strftime’s %s conversion specification is intended to be the inverse of
localtime. That is, if strftime(buf, sizeof buf, "%s", localtime())
succeeds, buf should contain the decimal representation of t.

Unfortunately when TZ is set to a geographic location, this does not work
on many POSIX platforms in some unusual cases.  It has even been argued
that POSIX 202x/D4 requires cases like these to not work. If that argument
is correct, this is a regression from POSIX 2017 and should be corrected.
This correction can be made without invalidating existing POSIX platforms.

Here is an example of the problem, set in Caracas:

  #include 
  #include 
  #include 

  int
  main ()
  {
char buf[100];
time_t t = 1197184500;
setenv ("TZ", "America/Caracas", 1);
strftime (buf, sizeof buf, "%s = %Y-%m-%d %H:%M:%S %z (%Z) in
Caracas",
  localtime ());
printf ("%lld prints as %s\n", (long long) t, buf);
if (atoll (buf) != t)
  puts ("time_t mismatch!");
  }

On Ubuntu 23.10, this outputs:

  1197184500 prints as 1197182700 = 2007-12-09 02:45:00 -0430 (-0430) in
Caracas
  time_t mismatch!

In response to Dag-Erling Smørgrav’s bug report[1] against TZDB’s
strftime implementation, I recently fixed[2] TZDB strftime to use tm_gmtoff
when converting %s, so that the Caracas example is guaranteed to output
this:

  1197184500 prints as 1197184500 = 2007-12-09 02:45:00 -0430 (-0430) in
Caracas

This is what users would invariably expect from strftime.

However, on the TZ mailing list Robert Elz objected[3] that the fix does
not conform to POSIX 202x/D4, because POSIX requires that strftime %s must
work by calling the equivalent of mktime() and thereby ignoring tm_gmtoff,
something that would inevitably result in "time_t mismatch!" output in some
situations like this. (Although the original bug report was against
gmtime+strftime, a similar bug can occur with localtime+strftime as in the
Caracas example.)

If POSIX 202x/D4 actually requires the "time_t mismatch!" output in cases
like [1] or like the Caracas example, this is a bug in 202x/D4 that was not
present in POSIX 2017. Even if many implementations have this bug, POSIX
should not require strftime %s to be incompatible with localtime, and it
should allow the TZDB fix.

Here is a bit more explanation about why Ubuntu 23.10 and many other
platforms misbehave on the Caracas example. When TZ="America/Caracas", the
two timestamps 1197182700 and 1197184500 convert via localtime into struct
tm values with identical tm_year, tm_mon, tm_mday, tm_hour, tm_min, tm_sec,
and tm_isdst members. This happens because Venezuela changed standard time
by moving its clock back 30 minutes on 2007-12-09 at 03:00, and tm_isdst is
therefore zero for both timestamps. This can be observed via the following
shell transcript run on Ubuntu 23.10, using TZDB’s zdump utility:

  $ zdump -V -c 2007,2008 America/Caracas
  America/Caracas  Sun Dec  9 06:59:59 2007 UT = Sun Dec  9 02:59:59 2007
-04 isdst=0 gmtoff=-14400
  America/Caracas  Sun Dec  9 07:00:00 2007 UT = Sun Dec  9 02:30:00 2007
-0430 isdst=0 gmtoff=-16200

With the fix[2], TZDB strftime examines tm_gmtoff when converting %s; this
lets strftime disambiguate struct tm values in cases like these. However,
POSIX 202x/D4 does not list tm_gmtoff as one of the struct tm members that
strftime can examine, and that is the basis for the objection[3] that POSIX
prohibits the fix.

[1]: https://mm.icann.org/pipermail/tz/2024-January/033488.html
[2]:
https://github.com/eggert/tz/commit/a707253f0c3c8cfd7b66fc5ca46cfb0a01e41dee
[3]: https://mm.icann.org/pipermail/tz/2024-January/033549.html

Desired Action: 
In section strftime() DESCRIPTION conversion specifier ‘s’, page 2136
lines 69836-69837, 

[1003.1(2016/18)/Issue7+TC2 0001790]: More info on *ALT* constants

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1790 
== 
Reported By:steffen
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1790
Category:   Base Definitions and Headers
Type:   Clarification Requested
Severity:   Editorial
Priority:   normal
Status: New
Name:   steffen 
Organization:
User Reference:  
Section:langinfo.h 
Page Number:276 
Line Number:9587 pp, 9611 pp 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2023-12-01 21:00 UTC
Last Modified:  2024-01-15 18:33 UTC
== 
Summary:More info on *ALT* constants
== 

-- 
 (0006622) shware_systems (reporter) - 2024-01-15 18:33
 https://austingroupbugs.net/view.php?id=1790#c6622 
-- 
I thought the primary names were how locales represented the Gregorian
calendar in a particular language, and ALT names were for how they might
represent an alternate calendar like Chinese, Hebrew or even Mayan, each in
a single grammar form.

Handling multiple grammar cases is way more an unspecified extension that
would likely need a formal proposal modifying XBD 7 to add to the standard,
not simply modifying this header arbitrarily. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-12-01 21:00 steffenNew Issue
2023-12-01 21:00 steffenName  => steffen 
2023-12-01 21:00 steffenSection   => langinfo.h  
2023-12-01 21:00 steffenPage Number   => 276 
2023-12-01 21:00 steffenLine Number   => 9587 pp, 9611 pp
2024-01-15 18:33 shware_systems Note Added: 0006622  
==

Re: sh: set -o pipefail by default

[Daniel Santos via austin-group-l at The Open Group]

On 1/15/24 06:23, Robert Elz wrote:

I agree with what you say, but beware:

   | Otherwise, I myfn() { local shell_restore=$(set +o | grep 'pipefail$');
   | set -o pipefail; ; eval "$shell_restore"; }

that needless optimisation attempt is n9t guaranteed to work.
'set +o' generates an implementation defined string which when
executed will restore any options altered between the set, and
executing the output from it, to their values at the time the
set was executed.   That's what you want there.


Ah hah! Thank you, Robert!

Daniel

[Issue 8 drafts 0001789]: if command name contains slash, it cannot be arg0 for execl()

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been RESOLVED. 
== 
https://austingroupbugs.net/view.php?id=1789 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1789
Category:   Shell and Utilities
Type:   Error
Severity:   Objection
Priority:   normal
Status: Resolved
Name:   Mark Galeck 
Organization:
User Reference:  
Section:Volume 2, Chapter 3 
Page Number:865, 2487 
Line Number:80936, 29495 
Final Accepted Text:see
https://austingroupbugs.net/view.php?id=1789#c6621 
Resolution: Accepted As Marked
Fixed in Version:   
== 
Date Submitted: 2023-11-22 02:24 UTC
Last Modified:  2024-01-15 17:29 UTC
== 
Summary:if command name contains slash, it cannot be arg0
for execl()
==
Relationships   ID  Summary
--
related to  0001645 execvp( ) requirements on arg0 are too ...
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-11-22 02:24 Mark_GaleckNew Issue
2023-11-22 02:24 Mark_GaleckName  => Mark Galeck 
2023-11-22 02:24 Mark_GaleckSection   => Volume 2, Chapter 3
2023-11-22 02:24 Mark_GaleckPage Number   => 865, 2487   
2023-11-22 02:24 Mark_GaleckLine Number   => 80936, 29495
2023-11-22 06:20 larryv Note Added: 0006579  
2023-11-22 07:18 Don Cragun Note Added: 0006580  
2023-11-22 07:19 Don Cragun Project 
1003.1(2016/18)/Issue7+TC2 => Issue 8 drafts
2023-11-22 07:21 Don Cragun version   => Draft 3 
2023-11-22 09:42 Guy Harris Note Added: 0006581  
2023-11-22 09:57 Guy Harris Note Added: 0006582  
2023-12-11 14:58 geoffclare Note Added: 0006596  
2024-01-15 16:40 nick   Relationship added   related to 0001645  
2024-01-15 17:28 nick   Note Added: 0006621  
2024-01-15 17:29 nick   Final Accepted Text   => see
https://austingroupbugs.net/view.php?id=1789#c6621
2024-01-15 17:29 nick   Status   New => Resolved 
2024-01-15 17:29 nick   Resolution   Open => Accepted As
Marked
==

[1003.1(2016/18)/Issue7+TC2 0001788]: The meaning of "Daylight Saving Time" should be clarified

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1788 
== 
Reported By:Guy Harris
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1788
Category:   Base Definitions and Headers
Type:   Clarification Requested
Severity:   Comment
Priority:   normal
Status: Resolved
Name:   Guy Harris 
Organization:
User Reference:  
Section:N/A 
Page Number:N/A 
Line Number:N/A 
Interp Status:  --- 
Final Accepted Text:https://austingroupbugs.net/view.php?id=1788#c6619 
Resolution: Accepted As Marked
Fixed in Version:   
== 
Date Submitted: 2023-11-18 00:16 UTC
Last Modified:  2024-01-11 16:53 UTC
== 
Summary:The meaning of "Daylight Saving Time" should be
clarified
==
Relationships   ID  Summary
--
related to  0001253 clarify that alternative time
== 

-- 
 (0006620) geoffclare (manager) - 2024-01-11 16:53
 https://austingroupbugs.net/view.php?id=1788#c6620 
-- 
In the January 11, 2024 teleconference it was decided that the resolution
of this bug should just address the missing definitions.  Any additional
changes related to tzname[] etc. should be the subject of a separate bug. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-11-18 00:16 Guy Harris New Issue
2023-11-18 00:16 Guy Harris Name  => Guy Harris  
2023-11-18 00:16 Guy Harris Section   => N/A 
2023-11-18 00:16 Guy Harris Page Number   => N/A 
2023-11-18 00:16 Guy Harris Line Number   => N/A 
2023-11-20 01:03 Don Cragun Note Added: 0006573  
2023-11-20 01:04 Don Cragun Relationship added   related to 0001253  
2023-11-20 17:10 kreNote Added: 0006576  
2023-11-22 19:40 Guy Harris Note Added: 0006583  
2023-11-22 20:12 Guy Harris Note Added: 0006584  
2023-11-22 20:35 steffenNote Added: 0006585  
2023-11-22 20:37 steffenNote Added: 0006586  
2023-11-22 21:07 Guy Harris Note Added: 0006587  
2023-11-23 23:19 steffenNote Added: 0006588  
2023-11-23 23:21 steffenFile Added: grep-over-bsds.txt  
 
2023-11-24 02:46 Guy Harris Note Added: 0006589  
2023-11-25 21:28 steffenNote Added: 0006590  
2023-11-30 16:17 nick   Relationship added   parent of 0001779   
2023-11-30 16:19 nick   Relationship deleted parent of 0001779   
2023-11-30 22:57 steffenNote Added: 0006594  
2024-01-08 17:50 geoffclare Note Added: 0006617  
2024-01-08 19:55 steffenNote Added: 0006618  
2024-01-11 16:44 geoffclare Note Added: 0006619  
2024-01-11 16:45 geoffclare Interp Status => --- 
2024-01-11 16:45 geoffclare Final Accepted Text   =>
https://austingroupbugs.net/view.php?id=1788#c6619
2024-01-11 16:45 geoffclare Status   New => Resolved 
2024-01-11 16:45 geoffclare Resolution   Open => Accepted As
Marked
2024-01-11 16:46 geoffclare Tag Attached: tc1-2024   
2024-01-11 16:53 geoffclare Note Added: 0006620  
==

[1003.1(2016/18)/Issue7+TC2 0001645]: execvp( ) requirements on arg0 are too strict

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been set as RELATED TO issue 0001789. 
== 
https://austingroupbugs.net/view.php?id=1645 
== 
Reported By:eblake
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1645
Category:   System Interfaces
Type:   Clarification Requested
Severity:   Objection
Priority:   normal
Status: Applied
Name:   Eric Blake 
Organization:   Red Hat 
User Reference: ebb.execvp 
Section:XSH exec 
Page Number:784 
Line Number:26548 
Interp Status:  Approved 
Final Accepted Text:https://austingroupbugs.net/view.php?id=1645#c6281 
Resolution: Accepted As Marked
Fixed in Version:   
== 
Date Submitted: 2023-03-22 19:47 UTC
Last Modified:  2023-08-17 10:53 UTC
== 
Summary:execvp( ) requirements on arg0 are too strict
==
Relationships   ID  Summary
--
related to  953 Alias expansion is under-specified
related to  0001674 may posix_spawnp() fail with ENOEXEC?
related to  0001789 if command name contains slash, it cann...
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-03-22 19:47 eblake New Issue
2023-03-22 19:47 eblake Name  => Eric Blake  
2023-03-22 19:47 eblake Organization  => Red Hat 
2023-03-22 19:47 eblake User Reference=> ebb.execvp  
2023-03-22 19:47 eblake Section   => XSH exec
2023-03-22 19:47 eblake Page Number   => 784 
2023-03-22 19:47 eblake Line Number   => 26548   
2023-03-22 19:47 eblake Interp Status => --- 
2023-03-22 19:55 eblake Description Updated  
2023-03-22 20:05 eblake Relationship added   related to 953  
2023-03-22 20:35 eblake Note Added: 0006226  
2023-03-22 21:19 eblake Description Updated  
2023-03-23 08:11 lacos  Note Added: 0006228  
2023-03-23 10:53 bastienIssue Monitored: bastien 
2023-03-23 10:53 bastienNote Added: 0006231  
2023-03-23 11:11 lacos  Issue Monitored: lacos   
2023-04-19 17:26 eblake Relationship added   related to 0001674  
2023-05-11 16:05 geoffclare Note Added: 0006281  
2023-05-11 16:07 geoffclare Interp Status--- => Pending  
2023-05-11 16:07 geoffclare Final Accepted Text   =>
https://austingroupbugs.net/view.php?id=1645#c6281
2023-05-11 16:07 geoffclare Status   New => Interpretation
Required
2023-05-11 16:07 geoffclare Resolution   Open => Accepted As
Marked
2023-05-11 16:07 geoffclare Tag Attached: tc3-2008   
2023-05-12 08:30 ajosey Interp StatusPending => Proposed 
2023-05-12 08:30 ajosey Note Added: 0006284  
2023-06-20 10:55 ajosey Interp StatusProposed => Approved
2023-06-20 10:55 ajosey Note Added: 0006340  
2023-08-17 10:53 geoffclare Status   Interpretation Required
=> Applied
2023-08-17 10:54 geoffclare Tag Attached: applied_after_i8d3
   
2024-01-15 16:40 nick   Relationship added   related to 0001789  
==

[Issue 8 drafts 0001789]: if command name contains slash, it cannot be arg0 for execl()

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been set as RELATED TO issue 0001645. 
== 
https://austingroupbugs.net/view.php?id=1789 
== 
Reported By:Mark_Galeck
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1789
Category:   Shell and Utilities
Type:   Error
Severity:   Objection
Priority:   normal
Status: New
Name:   Mark Galeck 
Organization:
User Reference:  
Section:Volume 2, Chapter 3 
Page Number:865, 2487 
Line Number:80936, 29495 
Final Accepted Text: 
== 
Date Submitted: 2023-11-22 02:24 UTC
Last Modified:  2024-01-15 16:40 UTC
== 
Summary:if command name contains slash, it cannot be arg0
for execl()
==
Relationships   ID  Summary
--
related to  0001645 execvp( ) requirements on arg0 are too ...
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-11-22 02:24 Mark_GaleckNew Issue
2023-11-22 02:24 Mark_GaleckName  => Mark Galeck 
2023-11-22 02:24 Mark_GaleckSection   => Volume 2, Chapter 3
2023-11-22 02:24 Mark_GaleckPage Number   => 865, 2487   
2023-11-22 02:24 Mark_GaleckLine Number   => 80936, 29495
2023-11-22 06:20 larryv Note Added: 0006579  
2023-11-22 07:18 Don Cragun Note Added: 0006580  
2023-11-22 07:19 Don Cragun Project 
1003.1(2016/18)/Issue7+TC2 => Issue 8 drafts
2023-11-22 07:21 Don Cragun version   => Draft 3 
2023-11-22 09:42 Guy Harris Note Added: 0006581  
2023-11-22 09:57 Guy Harris Note Added: 0006582  
2023-12-11 14:58 geoffclare Note Added: 0006596  
2024-01-15 16:40 nick   Relationship added   related to 0001645  
==

Re: sh: set -o pipefail by default

[Robert Elz via austin-group-l at The Open Group]

Date:Mon, 15 Jan 2024 00:13:47 -0600
From:"Daniel Santos via austin-group-l at The Open Group" 

Message-ID:  <08afc6b7-e88f-698a-c9ad-5bdce60a7...@pobox.com>

I agree with what you say, but beware:

  | Otherwise, I myfn() { local shell_restore=$(set +o | grep 'pipefail$'); 
  | set -o pipefail; ; eval "$shell_restore"; }

that needless optimisation attempt is n9t guaranteed to work.
'set +o' generates an implementation defined string which when
executed will restore any options altered between the set, and
executing the output from it, to their values at the time the
set was executed.   That's what you want there.

However nothing guarantees that you can extract a line from
that output string, and execute that - in fact the shell might
just output one long set command with lots of +o and -o options
in it (and -x or +x for any which have n0 long names, or just
any which have a 1 letter equiv, just to make the string shorter.

Or all kinds of other techniques.   The NetBSD shell does it
like this...

$ set +o
set -o default -o promptcmds -o vi -o xlock -o xtrace
$ set -o pipefail
$ set +o
set -o default -o pipefail -o promptcmds -o vi -o xlock -o xtrace

eval'ing tbe output from the first set +o would restore
things to how they were before, that's the magic "set -o default"
which returns all options to their shell startup values.
(There's a spec for what that means, but it isn't relevant
here).

But if you grep for pipefail you won't find it, so your eval
would end up executing nothing.   So forget that attemmpted
optimisation and just save, and then eval, the entire output
from set +o - thhat's what is specified to work, what isn't
specified is how.

If your plan is to allow some other option to be changed by
 and persist to the caller, then yoou simply have to
change that option after the eval (perhaps again, if the 
also needs the effect of the change).   That's rare however.

If you don't care about portability, then some shells offer
simpler mechanisms that are much easier to use, and have
the same effect.   But definit;ly not standard mechanisms.

kre

[valgrind] [Bug 477044] Valgrind complains about wld_mmap being in Text segment

[Austin English]

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

Austin English  changed:

   What|Removed |Added

 CC||austinengl...@gmail.com

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

Re: sh: set -o pipefail by default

[Daniel Santos via austin-group-l at The Open Group]

On 1/11/24 09:01, Lawrence Velázquez via austin-group-l at The Open 
Group wrote:

On Thu, Jan 11, 2024, at 3:53 AM, Andrew Pennebaker via austin-group-l at The 
Open Group wrote:

With sh gaining set -o pipefail, I am curious about having sh require
(or encourage) enabling this option by default. it would help to catch
a lot of false negatives in deceptively simple scripts.

Same question for make.

This would be unacceptable. It would break many perfectly correct scripts and 
makefiles.

https://mywiki.wooledge.org/BashPitfalls#pipefail

In any case, no implementation enables pipefail by default, so the standard 
should not prescribe it.


Additionally, pipefail is not always desirable. I might have a command 
whose stderr I redirect to stdout and I don't care about the exit code, 
only stdout. If I need pipefail in a sh library function where forking 
is acceptable, I define it myfn() ( set -o pipefail; ; ). 
Otherwise, I myfn() { local shell_restore=$(set +o | grep 'pipefail$'); 
set -o pipefail; ; eval "$shell_restore"; }


Daniel

[ovirt-users] Re: Migrating from a self hosted engine to standalone

[Austin Coppock]

Hi Strahil , Thanks.  Just an update on my original post, I made a mistake, I 
am upgrading from 4.4 to 4.5, and not 4.3 to 4.4.

Since I posted my original message, I have done a couple of more test. Using 
Ansible I am able to kickstart a RHEL8.8 server and have a standalone engine up 
and running in about 15 mins. My Current plan now is to, perform a backup just 
in case. However I will turn off all non-essential VMs, so I can shutdown half 
the hypervisors. While the essential VMs are still running, I will kickstart 
the removed hypervisors and add them to the new standalone engine. I will then 
schedule an outage, shutdown the remaining VMs, detach the data storage from 
the old environment, and import the storage domain to the new engine. I can 
then import the VMs from the storage to the new environment. 

Hopefully this will work. 
___
Users mailing list -- users@ovirt.org
To unsubscribe send an email to users-le...@ovirt.org
Privacy Statement: https://www.ovirt.org/privacy-policy.html
oVirt Code of Conduct: 
https://www.ovirt.org/community/about/community-guidelines/
List Archives: 
https://lists.ovirt.org/archives/list/users@ovirt.org/message/OWJB4G4MIZAHXC4C2XKU7IZWK3D4YXMT/

Re: Re: Re: [VOTE] Accept Flink CDC into Apache Flink

[Austin Bennett]

+1 (non-binding)

On Fri, Jan 12, 2024 at 5:44 PM Becket Qin  wrote:

> +1 (binding)
>
> Thanks,
>
> Jiangjie (Becket) Qin
>
> On Fri, Jan 12, 2024 at 5:58 AM Zhijiang  .invalid>
> wrote:
>
> > +1 (binding)
> > Best,
> > Zhijiang
> > --
> > From:Kurt Yang 
> > Send Time:2024年1月12日(星期五) 15:31
> > To:dev
> > Subject:Re: Re: Re: [VOTE] Accept Flink CDC into Apache Flink
> > +1 (binding)
> > Best,
> > Kurt
> > On Fri, Jan 12, 2024 at 2:21 PM Hequn Cheng  wrote:
> > > +1 (binding)
> > >
> > > Thanks,
> > > Hequn
> > >
> > > On Fri, Jan 12, 2024 at 2:19 PM godfrey he 
> wrote:
> > >
> > > > +1 (binding)
> > > >
> > > > Thanks,
> > > > Godfrey
> > > >
> > > > Zhu Zhu  于2024年1月12日周五 14:10写道：
> > > > >
> > > > > +1 (binding)
> > > > >
> > > > > Thanks,
> > > > > Zhu
> > > > >
> > > > > Hangxiang Yu  于2024年1月11日周四 14:26写道：
> > > > >
> > > > > > +1 (non-binding)
> > > > > >
> > > > > > On Thu, Jan 11, 2024 at 11:19 AM Xuannan Su <
> suxuanna...@gmail.com
> > >
> > > > wrote:
> > > > > >
> > > > > > > +1 (non-binding)
> > > > > > >
> > > > > > > Best,
> > > > > > > Xuannan
> > > > > > >
> > > > > > > On Thu, Jan 11, 2024 at 10:28 AM Xuyang 
> > > wrote:
> > > > > > > >
> > > > > > > > +1 (non-binding)--
> > > > > > > >
> > > > > > > > Best！
> > > > > > > > Xuyang
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > > > 在 2024-01-11 10:00:11，"Yang Wang" 
> > 写道：
> > > > > > > > >+1 (binding)
> > > > > > > > >
> > > > > > > > >
> > > > > > > > >Best,
> > > > > > > > >Yang
> > > > > > > > >
> > > > > > > > >On Thu, Jan 11, 2024 at 9:53 AM liu ron  >
> > > > wrote:
> > > > > > > > >
> > > > > > > > >> +1 non-binding
> > > > > > > > >>
> > > > > > > > >> Best
> > > > > > > > >> Ron
> > > > > > > > >>
> > > > > > > > >> Matthias Pohl 
> > 于2024年1月10日周三
> > > > > > 23:05写道：
> > > > > > > > >>
> > > > > > > > >> > +1 (binding)
> > > > > > > > >> >
> > > > > > > > >> > On Wed, Jan 10, 2024 at 3:35 PM ConradJam <
> > > > jam.gz...@gmail.com>
> > > > > > > wrote:
> > > > > > > > >> >
> > > > > > > > >> > > +1 non-binding
> > > > > > > > >> > >
> > > > > > > > >> > > Dawid Wysakowicz 
> 于2024年1月10日周三
> > > > > > 21:06写道：
> > > > > > > > >> > >
> > > > > > > > >> > > > +1 (binding)
> > > > > > > > >> > > > Best,
> > > > > > > > >> > > > Dawid
> > > > > > > > >> > > >
> > > > > > > > >> > > > On Wed, 10 Jan 2024 at 11:54, Piotr Nowojski <
> > > > > > > pnowoj...@apache.org>
> > > > > > > > >> > > wrote:
> > > > > > > > >> > > >
> > > > > > > > >> > > > > +1 (binding)
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > śr., 10 sty 2024 o 11:25 Martijn Visser <
> > > > > > > martijnvis...@apache.org>
> > > > > > > > >> > > > > napisał(a):
> > > > > > > > >> > > > >
> > > > > > > > >> > > > > > +1 (binding)
> > > > > > > > >> > > > > >
> > > > > > > > >> > > > > > On Wed, Jan 10, 2024 at 4:43 AM Xingbo Huang <
> > > > > > > hxbks...@gmail.com
> > > > > > > > >> >
> > > > > > > > >> > > > wrote:
> > > > > > > > >> > > > > > >
> > > > > > > > >> > > > > > > +1 (binding)
> > > > > > > > >> > > > > > >
> > > > > > > > >> > > > > > > Best,
> > > > > > > > >> > > > > > > Xingbo
> > > > > > > > >> > > > > > >
> > > > > > > > >> > > > > > > Dian Fu  于2024年1月10日周三
> > > > 11:35写道：
> > > > > > > > >> > > > > > >
> > > > > > > > >> > > > > > > > +1 (binding)
> > > > > > > > >> > > > > > > >
> > > > > > > > >> > > > > > > > Regards,
> > > > > > > > >> > > > > > > > Dian
> > > > > > > > >> > > > > > > >
> > > > > > > > >> > > > > > > > On Wed, Jan 10, 2024 at 5:09 AM Sharath <
> > > > > > > > >> dsaishar...@gmail.com
> > > > > > > > >> > >
> > > > > > > > >> > > > > wrote:
> > > > > > > > >> > > > > > > > >
> > > > > > > > >> > > > > > > > > +1 (non-binding)
> > > > > > > > >> > > > > > > > >
> > > > > > > > >> > > > > > > > > Best,
> > > > > > > > >> > > > > > > > > Sharath
> > > > > > > > >> > > > > > > > >
> > > > > > > > >> > > > > > > > > On Tue, Jan 9, 2024 at 1:02 PM Venkata
> > Sanath
> > > > > > > Muppalla <
> > > > > > > > >> > > > > > > > sanath...@gmail.com>
> > > > > > > > >> > > > > > > > > wrote:
> > > > > > > > >> > > > > > > > >
> > > > > > > > >> > > > > > > > > > +1 (non-binding)
> > > > > > > > >> > > > > > > > > >
> > > > > > > > >> > > > > > > > > > Thanks,
> > > > > > > > >> > > > > > > > > > Sanath
> > > > > > > > >> > > > > > > > > >
> > > > > > > > >> > > > > > > > > > On Tue, Jan 9, 2024 at 11:16 AM Peter
> > Huang
> > > <
> > > > > > > > >> > > > > > > > huangzhenqiu0...@gmail.com>
> > > > > > > > >> > > > > > > > > > wrote:
> > > > > > > > >> > > > > > > > > >
> > > > > > > > >> > > > > > > > > > > +1 (non-binding)
> > > > > > > > >> > > > > > > > > > >
> > > > > > > > >> > > > > > > > > > >
> > > > > > > > >> > > > > > > > > > > Best Regards
> > > > > > > > >> > > > > > > > > > > Peter Huang
> > > > > > > > >> > > > > > > > > > >
> > > > > > > > >> > > > > > > > > > >
> > > > > > > > >> > > > > > > > > > > On Tue, 

Minutes of the 11th January 2024 Teleconference

[Andrew Josey via austin-group-l at The Open Group]

All
Enclosed are the minutes from the thursday meeting this week
regards
Andrew
--

Minutes of the 11th January 2024 TeleconferenceAustin-1375 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 12th January 2024

Attendees:
Don Cragun, IEEE SA OR
Nick Stoughton, Logitech/USENIX, ISO/IEC JTC 1/SC 22 OR
Mark Ziegast, SHware Systems Dev.
Geoff Clare, The Open Group
Eric Ackermann 
Andrew Josey, The Open Group
Eric Blake, Red Hat, The Open Group OR
Levon Tumanyan

Apologies
Tom Thompson, IEEE


* General news

Draft 4 is still in review at The Open Group and IEEE,
with the review closing on January 31 2024. No comments
have been received as yet.

Andrew and Don reported they had attended the quarterly IEEE MSC meeting,
and that it had confirmed Don as the IEEE SA OR.

* Current Business


Bug 1788: The meaning of "Daylight Saving Time" should be clarified Accepted as 
Marked
https://austingroupbugs.net/view.php?id=1788

This item is marked for TC1-2024.
It was noted that the resolution of this bug should just address
the missing definitions. Any additional changes related to tzname[]
etc. should be the subject of a separate bug.


Add the following to the definitions in XBD chapter 3 putting them in 
alphabetical order and renumbering moved definitions.
3.xxx Daylight Saving Time (DST)

The time according to a location's law or practice, when
adjusted as necessary from standard time. The adjustment
can be positive or negative, and the amount of adjustment
can vary depending on the date and time; the adjustment can
even be zero, although this is not common practice.

Note: timezone information can be supplied via the
TZ environment variable, which is defined in detail in [xref
to XBD 8.3].

See also [xref to 3.yyy Standard Time].


3.yyy Standard Time

The time according to a location's law or practice, unadjusted
for Daylight Saving Time.

Note: timezone information can be supplied via the
TZ environment variable, which is defined in detail in [xref
to XBD 8.3].

See also [xref to 3.xxx Daylight Saving Time].



Bug 1789: if command name contains slash, it cannot be arg0 for execl() OPEN
https://austingroupbugs.net/view.php?id=1789

We started this item and notes are in the etherpad.
We will continue on this on the next call.

Next Steps
--
  
The next call is on:
  Mon 2024-01-15 (Zoom meeting - general bugs)
  Thu 2024-01-18 (Zoom meeting - general bugs)

The calls are for 90 minutes

Calls are anchored on US time. (8am Pacific)

Apologies in Advance:
Geoff Clare, 2024-01-15 to 2024-01-22 inclusive

Please check the calendar invites for dial in details.

Bugs are at:
https://austingroupbugs.net

An etherpad is usually up for the meeting, with a URL using the date format as 
below:

https://posix.rhansen.org/p/20xx-mm-dd

(For write access this uses The Open Group single sign on,
for those individuals with gitlab.opengroup.org accounts.
Please contact Andrew if you need to be setup)


Andrew JoseyThe Open Group
Austin Group Chair  
Email: a.jo...@opengroup.org 
Apex Plaza, Forbury Road,Reading,Berks.RG1 1AX,England

To learn how we maintain your privacy, please review The Open Group Privacy 
Statement at http://www.opengroup.org/privacy.
To unsubscribe/opt-out from this mailing list login to The Open Group 
collaboration portal at
https://collaboration.opengroup.org/operational/portal.php?action=unsub=2481

Re: "org.apache.thrift.transport.TTransportException: Invalid status -128" errors when SASL is enabled

[Austin Hackett]

For the benefit of anyone who comes across this error in future, it was solved 
by adding hive.metastore.sasl.enabled and hive.metastore.kerberos.principal to 
hive-site.xml on the client side, e.g. $SPARK_HOME/conf


> On 8 Jan 2024, at 16:18, Austin Hackett  wrote:
> 
> Hi List
>  
> I'm having an issue where Hive Metastore operations (e.g. show databases) are 
> failing with "org.apache.thrift.transport.TTransportException: Invalid status 
> -128" errors when I enable SASL.
>  
> I am a bit stuck on how to go about troubleshooting this further, and any 
> pointers would be greatly apprecicated...
>  
> Full details as follows:
>  
> - Ubuntu 22.04 & OpenJDK 8u342
> - Unpacked Hive 3.1.3 binary release 
> (https://dlcdn.apache.org/hive/hive-3.1.3/apache-hive-3.1.3-bin.tar.gz) to 
> /opt/hive
> - Unpacked Hadoop 3.1.0 binary release 
> (https://archive.apache.org/dist/hadoop/common/hadoop-3.1.0/hadoop-3.1.0.tar.gz)
>  to /opt/hadoop
> - Created /opt/hive/conf/metastore-site.xml (see below for contents) and 
> copied hdfs-site.xml and core-site.xml from the target HDFS cluster to 
> /opt/hive/conf
> - export HADOOP_HOME=/opt/hadoop
> - export HIVE_HOME=/opt/hive
> - Successfully started the metastore, i.e. hive --service metastore
> - Use a Hive Metastore client to "show databases" and get an error (see below 
> for the associated errors in the HMS log). I get the same error with 
> spark-shell running in local mode and the Python hive-metastore-client 
> (https://pypi.org/project/hive-metastore-client/)
>  
>  
> metastore-site.xml
> ==
> 
>   
> metastore.warehouse.dir
> /user/hive/warehouse
>   
>   
> javax.jdo.option.ConnectionDriverName
> org.postgresql.Driver
>   
>   
> javax.jdo.option.ConnectionURL
> jdbc:postgresql://postgres.example.net:5432/metastore_db 
> 
>   
>   
> javax.jdo.option.ConnectionUserName
> hive
>   
>   
> javax.jdo.option.ConnectionPassword
> password
>   
>   
> metastore.kerberos.principal
> hive/_h...@example.net <mailto:hive/_h...@example.net%3c/value>>
>   
>   
> metastore.kerberos.keytab.file
> /etc/security/keytabs/hive.keytab
>   
>   
> hive.metastore.sasl.enabled
> true
>   
> 
> ==
>  
> HMS log shows that it is able to authenticate using the specified keytab and 
> principle (and I have also checked this manually via kinit command):
>  
> 
> 2024-01-08T13:12:33,463  WARN [main] security.HadoopThriftAuthBridge: 
> Client-facing principal not set. Using server-side setting: 
> hive/_h...@example.net <mailto:hive/_h...@example.net>
> 2024-01-08T13:12:33,464  INFO [main] security.HadoopThriftAuthBridge: Logging 
> in via CLIENT based principal
> 2024-01-08T13:12:33,471 DEBUG [main] security.UserGroupInformation: Hadoop 
> login
> 2024-01-08T13:12:33,472 DEBUG [main] security.UserGroupInformation: hadoop 
> login commit
> 2024-01-08T13:12:33,472 DEBUG [main] security.UserGroupInformation: Using 
> kerberos user: hive/metstore.example@example.net 
> <mailto:hive/metstore.example@example.net>
> 2024-01-08T13:12:33,472 DEBUG [main] security.UserGroupInformation: Using 
> user: "hive/metstore.example@example.net 
> <mailto:hive/metstore.example@example.net>" with name: 
> hive/metstore.example@example.net 
> <mailto:hive/metstore.example@example.net>
> 2024-01-08T13:12:33,472 DEBUG [main] security.UserGroupInformation: User 
> entry: "hive/metstore.example@example.net 
> <mailto:hive/metstore.example@example.net>"
> 2024-01-08T13:12:33,472  INFO [main] security.UserGroupInformation: Login 
> successful for user hive/metstore.example@example.net 
> <mailto:hive/metstore.example@example.net> using keytab file hive.keytab. 
> Keytab auto renewal enabled : false
> 2024-01-08T13:12:33,472  INFO [main] security.HadoopThriftAuthBridge: Logging 
> in via SERVER based principal
> 2024-01-08T13:12:33,480 DEBUG [main] security.UserGroupInformation: Hadoop 
> login
> 2024-01-08T13:12:33,480 DEBUG [main] security.UserGroupInformation: hadoop 
> login commit
> 2024-01-08T13:12:33,480 DEBUG [main] security.UserGroupInformation: Using 
> kerberos user: hive/metstore.example@example.net 
> <mailto:hive/metstore.example@example.net>
> 2024-01-08T13:12:33,480 DEBUG [main] security.UserGroupInformation: Using 
> user: "hive/metstore.example@example.net 
> <mailto:hive/metstore.example@example.net>" with name: 
> hive/metstore.example@example.net 
> <mailto:hive/metstore.exa

Austin Group teleconference +1 888 974 9888 PIN 618 156 403

[Single UNIX Specification via austin-group-l at The Open Group]

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//opengroup.org//NONSGML kigkonsult.se iCalcreator 2.22.1//
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:America/New_York
X-LIC-LOCATION:America/New_York
BEGIN:DAYLIGHT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
DTSTART:20120311T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
DTSTART:20121104T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:65a030a557...@opengroup.org
DTSTAMP:20240111T181709Z
ATTENDEE;ROLE=CHAIR:MAILTO:a.jo...@opengroup.org
CREATED:20240111T00Z
DESCRIPTION:Web/Project: Single UNIX Specification\nTitle: Austin Group tel
 econference +1 888 974 9888 PIN 618 156 403\nDate/Time: 18-Jan-2024 at 11:
 00 America/New_York\nDuration: 1.50 hours\nURL: https://collaboration.open
 group.org/platform/single_unix_specification/events.php\n\nAll calls are a
 nchored on US time\n\nTopic: Austin Group teleconference\n
 ---\nAudio conference information\n---
 \n\nYou are invited to
  a Zoom meeting.\n\nMeeting ID: 618 156 403\n\nJoin from PC\, Mac\, iOS or
  Android: https://logitech.zoom.us/j/618156403\n \nor join by phone:\nUS: 
 888 974 9888\nUK: 800 031 5717\nDE: 800 724 3138\nFR: 805 082 588\n\nOther
  international numbers available here:\nhttps://zoom.us/u/adlvrb8ILj\n \n 
Meeting ID: 618 156 403\n\nor join from a H.323/SIP Device:\nDial: 
 162.255.37.11 (US West) or 162.255.36.11 (US East)\nMeeting ID: 618 15
 6 403\n\nShare from a PC or MAC: https://zoom.us/share/618156403\n\nOr iPh
 one one-tap (US Toll):  +16699006833\,618156403# or +16465588656\,61815640
 3#\n\nPassword for zoom call  ends with x\n\nAll Austin Group participants
  are most welcome to join the call.\nThe call will last for 90 minutes.\n
 \n\nAn etherpad is usually up for a meeting\, with a URL using the date fo
 rmat as below:\n\nhttps://posix.rhansen.org/p/202x-mm-dd\n\nLOGIN REQUIRED
  to write to the ETHERPAD (Use your gitlab.opengroup.org login.)\n\n \n\nB
 ug reports are available at:\nhttps://www.austingroupbugs.net\n
DTSTART;TZID=America/New_York:20240118T11
DURATION:PT1H30M0S
LAST-MODIFIED:20240111T131709Z
ORGANIZER;CN=Single UNIX Specification:MAILTO:do-not-re...@opengroup.org
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Austin Group teleconference +1 888 974 9888 PIN 618 156 403
TRANSP:OPAQUE
URL:https://collaboration.opengroup.org/platform/single_unix_specification/
 events.php
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-VISIBILITY:40
X-JOINBEFORE:5
X-CATEGORY:Teleconference
X-PLATO-SITE:Single UNIX Specification
X-PLATO-SITEID:136
END:VEVENT
END:VCALENDAR


meeting.ics
Description: application/ics

[1003.1(2016/18)/Issue7+TC2 0001788]: The meaning of "Daylight Saving Time" should be clarified

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1788 
== 
Reported By:Guy Harris
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1788
Category:   Base Definitions and Headers
Type:   Clarification Requested
Severity:   Comment
Priority:   normal
Status: Resolved
Name:   Guy Harris 
Organization:
User Reference:  
Section:N/A 
Page Number:N/A 
Line Number:N/A 
Interp Status:  --- 
Final Accepted Text:https://austingroupbugs.net/view.php?id=1788#c6619 
Resolution: Accepted As Marked
Fixed in Version:   
== 
Date Submitted: 2023-11-18 00:16 UTC
Last Modified:  2024-01-11 16:53 UTC
== 
Summary:The meaning of "Daylight Saving Time" should be
clarified
==
Relationships   ID  Summary
--
related to  0001253 clarify that alternative time
== 

-- 
 (0006620) geoffclare (manager) - 2024-01-11 16:53
 https://austingroupbugs.net/view.php?id=1788#c6620 
-- 
In the January 11, 2024 teleconference it was decided that the resolution
of this bug should just address the missing definitions.  Any additional
changes related to tzname[] etc. should be the subject of a separate bug. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-11-18 00:16 Guy Harris New Issue
2023-11-18 00:16 Guy Harris Name  => Guy Harris  
2023-11-18 00:16 Guy Harris Section   => N/A 
2023-11-18 00:16 Guy Harris Page Number   => N/A 
2023-11-18 00:16 Guy Harris Line Number   => N/A 
2023-11-20 01:03 Don Cragun Note Added: 0006573  
2023-11-20 01:04 Don Cragun Relationship added   related to 0001253  
2023-11-20 17:10 kreNote Added: 0006576  
2023-11-22 19:40 Guy Harris Note Added: 0006583  
2023-11-22 20:12 Guy Harris Note Added: 0006584  
2023-11-22 20:35 steffenNote Added: 0006585  
2023-11-22 20:37 steffenNote Added: 0006586  
2023-11-22 21:07 Guy Harris Note Added: 0006587  
2023-11-23 23:19 steffenNote Added: 0006588  
2023-11-23 23:21 steffenFile Added: grep-over-bsds.txt  
 
2023-11-24 02:46 Guy Harris Note Added: 0006589  
2023-11-25 21:28 steffenNote Added: 0006590  
2023-11-30 16:17 nick   Relationship added   parent of 0001779   
2023-11-30 16:19 nick   Relationship deleted parent of 0001779   
2023-11-30 22:57 steffenNote Added: 0006594  
2024-01-08 17:50 geoffclare Note Added: 0006617  
2024-01-08 19:55 steffenNote Added: 0006618  
2024-01-11 16:44 geoffclare Note Added: 0006619  
2024-01-11 16:45 geoffclare Interp Status => --- 
2024-01-11 16:45 geoffclare Final Accepted Text   =>
https://austingroupbugs.net/view.php?id=1788#c6619
2024-01-11 16:45 geoffclare Status   New => Resolved 
2024-01-11 16:45 geoffclare Resolution   Open => Accepted As
Marked
2024-01-11 16:46 geoffclare Tag Attached: tc1-2024   
2024-01-11 16:53 geoffclare Note Added: 0006620  
==

[1003.1(2016/18)/Issue7+TC2 0001788]: The meaning of "Daylight Saving Time" should be clarified

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been RESOLVED. 
== 
https://austingroupbugs.net/view.php?id=1788 
== 
Reported By:Guy Harris
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1788
Category:   Base Definitions and Headers
Type:   Clarification Requested
Severity:   Comment
Priority:   normal
Status: Resolved
Name:   Guy Harris 
Organization:
User Reference:  
Section:N/A 
Page Number:N/A 
Line Number:N/A 
Interp Status:  --- 
Final Accepted Text:https://austingroupbugs.net/view.php?id=1788#c6619 
Resolution: Accepted As Marked
Fixed in Version:   
== 
Date Submitted: 2023-11-18 00:16 UTC
Last Modified:  2024-01-11 16:45 UTC
== 
Summary:The meaning of "Daylight Saving Time" should be
clarified
==
Relationships   ID  Summary
--
related to  0001253 clarify that alternative time
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-11-18 00:16 Guy Harris New Issue
2023-11-18 00:16 Guy Harris Name  => Guy Harris  
2023-11-18 00:16 Guy Harris Section   => N/A 
2023-11-18 00:16 Guy Harris Page Number   => N/A 
2023-11-18 00:16 Guy Harris Line Number   => N/A 
2023-11-20 01:03 Don Cragun Note Added: 0006573  
2023-11-20 01:04 Don Cragun Relationship added   related to 0001253  
2023-11-20 17:10 kreNote Added: 0006576  
2023-11-22 19:40 Guy Harris Note Added: 0006583  
2023-11-22 20:12 Guy Harris Note Added: 0006584  
2023-11-22 20:35 steffenNote Added: 0006585  
2023-11-22 20:37 steffenNote Added: 0006586  
2023-11-22 21:07 Guy Harris Note Added: 0006587  
2023-11-23 23:19 steffenNote Added: 0006588  
2023-11-23 23:21 steffenFile Added: grep-over-bsds.txt  
 
2023-11-24 02:46 Guy Harris Note Added: 0006589  
2023-11-25 21:28 steffenNote Added: 0006590  
2023-11-30 16:17 nick   Relationship added   parent of 0001779   
2023-11-30 16:19 nick   Relationship deleted parent of 0001779   
2023-11-30 22:57 steffenNote Added: 0006594  
2024-01-08 17:50 geoffclare Note Added: 0006617  
2024-01-08 19:55 steffenNote Added: 0006618  
2024-01-11 16:44 geoffclare Note Added: 0006619  
2024-01-11 16:45 geoffclare Interp Status => --- 
2024-01-11 16:45 geoffclare Final Accepted Text   =>
https://austingroupbugs.net/view.php?id=1788#c6619
2024-01-11 16:45 geoffclare Status   New => Resolved 
2024-01-11 16:45 geoffclare Resolution   Open => Accepted As
Marked
==

[1003.1(2016/18)/Issue7+TC2 0001788]: The meaning of "Daylight Saving Time" should be clarified

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1788 
== 
Reported By:Guy Harris
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1788
Category:   Base Definitions and Headers
Type:   Clarification Requested
Severity:   Comment
Priority:   normal
Status: New
Name:   Guy Harris 
Organization:
User Reference:  
Section:N/A 
Page Number:N/A 
Line Number:N/A 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2023-11-18 00:16 UTC
Last Modified:  2024-01-11 16:44 UTC
== 
Summary:The meaning of "Daylight Saving Time" should be
clarified
==
Relationships   ID  Summary
--
related to  0001253 clarify that alternative time
== 

-- 
 (0006619) geoffclare (manager) - 2024-01-11 16:44
 https://austingroupbugs.net/view.php?id=1788#c6619 
-- 
Add the following to the definitions in XBD chapter 3 putting them in
alphabetical order and renumbering moved definitions.

3.xxx Daylight Saving Time (DST)
The time according to a location's law or practice, when
adjusted as necessary from standard time. The adjustment can be positive or
negative, and the amount of adjustment can vary depending on the date and
time; the adjustment can even be zero, although this is not common
practice.

Note: timezone information can be supplied via the TZ
environment variable, which is defined in detail in [xref to XBD
8.3].

See also [xref to 3.yyy Standard Time].
3.yyy Standard Time
The time according to a location's law or practice, unadjusted
for Daylight Saving Time.

Note: timezone information can be supplied via the TZ
environment variable, which is defined in detail in [xref to XBD
8.3].

See also [xref to 3.xxx Daylight Saving Time]. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-11-18 00:16 Guy Harris New Issue
2023-11-18 00:16 Guy Harris Name  => Guy Harris  
2023-11-18 00:16 Guy Harris Section   => N/A 
2023-11-18 00:16 Guy Harris Page Number   => N/A 
2023-11-18 00:16 Guy Harris Line Number   => N/A 
2023-11-20 01:03 Don Cragun Note Added: 0006573  
2023-11-20 01:04 Don Cragun Relationship added   related to 0001253  
2023-11-20 17:10 kreNote Added: 0006576  
2023-11-22 19:40 Guy Harris Note Added: 0006583  
2023-11-22 20:12 Guy Harris Note Added: 0006584  
2023-11-22 20:35 steffenNote Added: 0006585  
2023-11-22 20:37 steffenNote Added: 0006586  
2023-11-22 21:07 Guy Harris Note Added: 0006587  
2023-11-23 23:19 steffenNote Added: 0006588  
2023-11-23 23:21 steffenFile Added: grep-over-bsds.txt  
 
2023-11-24 02:46 Guy Harris Note Added: 0006589  
2023-11-25 21:28 steffenNote Added: 0006590  
2023-11-30 16:17 nick   Relationship added   parent of 0001779   
2023-11-30 16:19 nick   Relationship deleted parent of 0001779   
2023-11-30 22:57 steffenNote Added: 0006594  
2024-01-08 17:50 geoffclare Note Added: 0006617  
2024-01-08 19:55 steffenNote Added: 0006618  
2024-01-11 16:44 geoffclare Note Added: 0006619  
==

[Issue 8 drafts 0001796]: Table rendering problem

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been SUBMITTED. 
== 
https://austingroupbugs.net/view.php?id=1796 
== 
Reported By:geoffclare
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1796
Category:   Shell and Utilities
Type:   Error
Severity:   Editorial
Priority:   normal
Status: New
Name:   Geoff Clare 
Organization:   The Open Group 
User Reference:  
Section:2.6.2 Parameter Expansion 
Page Number:2486 
Line Number:80693-80702 
Final Accepted Text: 
== 
Date Submitted: 2024-01-11 15:35 UTC
Last Modified:  2024-01-11 15:35 UTC
== 
Summary:Table rendering problem
Description: 
The table at the bottom page 2486 is missing its vertical bars; they have
been rendered at the top of the next page instead.

This appears to be a side-effect of earlier additions causing the table to
move down so that it is the last thing on the page.

Desired Action: 
Move the whole table to the start of the next page.
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-01-11 15:35 geoffclare New Issue
2024-01-11 15:35 geoffclare Name  => Geoff Clare 
2024-01-11 15:35 geoffclare Organization  => The Open Group  
2024-01-11 15:35 geoffclare Section   => 2.6.2 Parameter
Expansion
2024-01-11 15:35 geoffclare Page Number   => 2486
2024-01-11 15:35 geoffclare Line Number   => 80693-80702 
==

Re: sh: set -o pipefail by default

[Chet Ramey via austin-group-l at The Open Group]

On 1/11/24 3:53 AM, Andrew Pennebaker via austin-group-l at The Open Group 
wrote:
With sh gaining set -o pipefail, I am curious about having sh require (or 
encourage) enabling this option by default. it would help to catch a lot of 
false negatives in deceptively simple scripts.


No. This would break a large body of existing scripts, and it's not the
purpose of the standard. Any implementation can choose to default it to
enabled, of course.

--
``The lyf so short, the craft so long to lerne.'' - Chaucer
 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/



OpenPGP_signature.asc
Description: OpenPGP digital signature

[Issue 8 drafts 0001795]: Field splitting rationale refers to non-existing rule number

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been SUBMITTED. 
== 
https://austingroupbugs.net/view.php?id=1795 
== 
Reported By:geoffclare
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1795
Category:   Rationale
Type:   Error
Severity:   Comment
Priority:   normal
Status: New
Name:   Geoff Clare 
Organization:   The Open Group 
User Reference:  
Section:C.2.6.5 
Page Number:3889 
Line Number:134981 
Final Accepted Text: 
== 
Date Submitted: 2024-01-11 15:17 UTC
Last Modified:  2024-01-11 15:17 UTC
== 
Summary:Field splitting rationale refers to non-existing
rule number
Description: 
The XRAT entry for field splitting in C.2.6.5 refers to "Rule (3)" which
no longer exists in the normative text.

Desired Action: 
Change:Rule (3) can be summarized as a
pseudo-EREto:The different handling of white space
and non-white-space characters in IFS can be summarized as a
pseudo-ERE

== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2024-01-11 15:17 geoffclare New Issue
2024-01-11 15:17 geoffclare Name  => Geoff Clare 
2024-01-11 15:17 geoffclare Organization  => The Open Group  
2024-01-11 15:17 geoffclare Section   => C.2.6.5 
2024-01-11 15:17 geoffclare Page Number   => 3889
2024-01-11 15:17 geoffclare Line Number   => 134981  
==

Re: sh: set -o pipefail by default

[Lawrence Velázquez via austin-group-l at The Open Group]

On Thu, Jan 11, 2024, at 3:53 AM, Andrew Pennebaker via austin-group-l at The 
Open Group wrote:
> With sh gaining set -o pipefail, I am curious about having sh require 
> (or encourage) enabling this option by default. it would help to catch 
> a lot of false negatives in deceptively simple scripts.
>
> Same question for make.

This would be unacceptable. It would break many perfectly correct scripts and 
makefiles.

https://mywiki.wooledge.org/BashPitfalls#pipefail

In any case, no implementation enables pipefail by default, so the standard 
should not prescribe it.

-- 
vq

sh: set -o pipefail by default

[Andrew Pennebaker via austin-group-l at The Open Group]

With sh gaining set -o pipefail, I am curious about having sh require (or
encourage) enabling this option by default. it would help to catch a lot of
false negatives in deceptively simple scripts.

Same question for make.

-- 
Cheers,
Andrew

Minutes of the 8th January 2024 Teleconference

[Andrew Josey via austin-group-l at The Open Group]

All
Enclosed are the minutes from the Monday meeting this week
regards
Andrew


Minutes of the 8th January 2024 TeleconferenceAustin-1374 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 8th January 2024

Attendees:
Don Cragun, IEEE PASC OR
Nick Stoughton, Logitech/USENIX, ISO/IEC JTC 1/SC 22 OR
Mark Ziegast, SHware Systems Dev.
Andrew Josey, The Open Group
Geoff Clare, The Open Group
Eric Blake, Red Hat, The Open Group OR

Apologies
Eric Ackermann
Tom Thompson, IEEE


* General news

Draft 4 is currently in review at The Open Group and IEEE,
with the review closing on January 31 2024. No comments
have been received as yet.

An updated draft has been submitted to ISO/IEC addressing minor editorial 
comments received.

* Current Business


Bug 1788: The meaning of "Daylight Saving Time" should be clarified OPEN
https://austingroupbugs.net/view.php?id=1788

We continued this item and notes are in the etherpad.
We will continue on this on the next call.

Next Steps
--
  
The next call is on:
  Thu 2024-01-11 (Zoom meeting - general bugs)
  Mon 2024-01-15 (Zoom meeting - general bugs)

The calls are for 90 minutes

Calls are anchored on US time. (8am Pacific)

Apologies in Advance:
Geoff Clare, 2024-01-15 to 2024-01-22 inclusive

Please check the calendar invites for dial in details.

Bugs are at:
https://austingroupbugs.net

An etherpad is usually up for the meeting, with a URL using the date format as 
below:

https://posix.rhansen.org/p/20xx-mm-dd

(For write access this uses The Open Group single sign on,
for those individuals with gitlab.opengroup.org accounts.
Please contact Andrew if you need to be setup)


Andrew JoseyThe Open Group
Austin Group Chair  
Email: a.jo...@opengroup.org 
Apex Plaza, Forbury Road,Reading,Berks.RG1 1AX,England

To learn how we maintain your privacy, please review The Open Group Privacy 
Statement at http://www.opengroup.org/privacy.
To unsubscribe/opt-out from this mailing list login to The Open Group 
collaboration portal at
https://collaboration.opengroup.org/operational/portal.php?action=unsub=2481

Re: IANA TZ / NerBSD TZ: tzalloc/tzfree and localtime_rz, mktime_z

[Steffen Nurpmeso via austin-group-l at The Open Group]

Andrew Josey via austin-group-l at The Open Group wrote in
 <36c65d39-81c9-4852-9b1d-43533395d...@opengroup.org>:
 |> On 5 Jan 2024, at 05:12, Robert Elz via austin-group-l at The Open \
 |> Group  wrote:
 |> 
 |>Date:Thu, 04 Jan 2024 23:24:26 +0100
 |>From:Steffen Nurpmeso 
 |>Message-ID:  <20240104222426.ai7_3Mvo@steffen%sdaoden.eu>
 |> 
 |>| I was hoping for the draft; the selection list does not offer
 |>| anything but ..TC2 and it.
 |> 
 |> If you want, you can submit a bug now, using any base standard
 |> that is in some way still current.   It just won't get processed
 |> at all (beyond random notes being added) until the next standard
 |> is being worked on, so submitting now is kind of pointless.
 |
 |Not necessarily, Austin/SD6 (https://www.opengroup.org/austin/docs/austi\
 |n_sd6.txt) lays out the Committee Maintenance Procedures for the Approved \
 |Standard, and there is a section on new work items.
 |
 |So a proposal could advance that way, and lead to a separate standard \
 |adopted by one of the sponsoring organizations, and later adopted to \
 |issue 9. 
 | 
 |Over the years we have progressed a number of new API sets this way, \
 |before they went into the main standard ( the Extended API Sets Parts \
 |1..4, and the Additional APIs for the Base Specifications Issue 8 Parts \
 |1 and 2).

This interface is a good candidate for such a sponsor and
inclusion for sure.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

(beam) branch master updated: [YAML] - Kafka Proto String schema (#29835)

[austin]

This is an automated email from the ASF dual-hosted git repository.

austin pushed a commit to branch master
in repository https://gitbox.apache.org/repos/asf/beam.git


The following commit(s) were added to refs/heads/master by this push:
 new 6066af3dbd5 [YAML] - Kafka Proto String schema (#29835)
6066af3dbd5 is described below

commit 6066af3dbd5a549cfd0424fe9efa1b2b545bd7ea
Author: Ferran Fernández Garrido 
AuthorDate: Tue Jan 9 22:58:57 2024 +0100

[YAML] - Kafka Proto String schema (#29835)

* [YAML] - Kafka Proto String schema
---
 sdks/java/extensions/protobuf/build.gradle |   2 +
 .../sdk/extensions/protobuf/ProtoByteUtils.java|  85 +++
 .../extensions/protobuf/ProtoByteUtilsTest.java|  49 +++
 sdks/java/io/kafka/build.gradle|   1 +
 .../KafkaReadSchemaTransformConfiguration.java |  23 +++
 .../io/kafka/KafkaReadSchemaTransformProvider.java | 157 +
 .../kafka/KafkaWriteSchemaTransformProvider.java   |  94 
 .../KafkaReadSchemaTransformProviderTest.java  |  64 +
 .../KafkaWriteSchemaTransformProviderTest.java |  22 ++-
 sdks/python/apache_beam/yaml/standard_io.yaml  |   1 +
 10 files changed, 373 insertions(+), 125 deletions(-)

diff --git a/sdks/java/extensions/protobuf/build.gradle 
b/sdks/java/extensions/protobuf/build.gradle
index 568d4f22086..1582492c293 100644
--- a/sdks/java/extensions/protobuf/build.gradle
+++ b/sdks/java/extensions/protobuf/build.gradle
@@ -39,6 +39,8 @@ dependencies {
   implementation library.java.slf4j_api
   implementation project(path: ":sdks:java:core", configuration: "shadow")
   implementation library.java.protobuf_java
+  implementation("com.squareup.wire:wire-schema-jvm:4.9.3")
+  
implementation("io.apicurio:apicurio-registry-protobuf-schema-utilities:3.0.0.M2")
   testImplementation project(path: ":sdks:java:core", configuration: 
"shadowTest")
   testImplementation library.java.junit
   testRuntimeOnly library.java.slf4j_jdk14
diff --git 
a/sdks/java/extensions/protobuf/src/main/java/org/apache/beam/sdk/extensions/protobuf/ProtoByteUtils.java
 
b/sdks/java/extensions/protobuf/src/main/java/org/apache/beam/sdk/extensions/protobuf/ProtoByteUtils.java
index f156fed0f38..02419ec0f61 100644
--- 
a/sdks/java/extensions/protobuf/src/main/java/org/apache/beam/sdk/extensions/protobuf/ProtoByteUtils.java
+++ 
b/sdks/java/extensions/protobuf/src/main/java/org/apache/beam/sdk/extensions/protobuf/ProtoByteUtils.java
@@ -24,6 +24,10 @@ import com.google.protobuf.DescriptorProtos;
 import com.google.protobuf.Descriptors;
 import com.google.protobuf.DynamicMessage;
 import com.google.protobuf.InvalidProtocolBufferException;
+import com.squareup.wire.schema.Location;
+import com.squareup.wire.schema.internal.parser.ProtoFileElement;
+import com.squareup.wire.schema.internal.parser.ProtoParser;
+import io.apicurio.registry.utils.protobuf.schema.FileDescriptorUtils;
 import java.io.IOException;
 import java.io.InputStream;
 import java.io.Serializable;
@@ -55,6 +59,8 @@ public class ProtoByteUtils {
 
   private static final Logger LOG = 
LoggerFactory.getLogger(ProtoByteUtils.class);
 
+  private static final Location LOCATION = Location.get("");
+
   /**
* Retrieves a Beam Schema from a Protocol Buffer message.
*
@@ -68,6 +74,68 @@ public class ProtoByteUtils {
 return ProtoDynamicMessageSchema.forDescriptor(protoDomain, 
messageName).getSchema();
   }
 
+  /**
+   * Parses the given Protocol Buffers schema string, retrieves the Descriptor 
for the specified
+   * message name, and constructs a Beam Schema from it.
+   *
+   * @param schemaString The Protocol Buffers schema string.
+   * @param messageName The name of the message type for which the Beam Schema 
is desired.
+   * @return The Beam Schema constructed from the specified Protocol Buffers 
schema.
+   * @throws RuntimeException If there is an error during parsing, descriptor 
retrieval, or schema
+   * construction.
+   */
+  public static Schema getBeamSchemaFromProtoSchema(String schemaString, 
String messageName) {
+Descriptors.Descriptor descriptor = 
getDescriptorFromProtoSchema(schemaString, messageName);
+return 
ProtoDynamicMessageSchema.forDescriptor(ProtoDomain.buildFrom(descriptor), 
descriptor)
+.getSchema();
+  }
+
+  /**
+   * Parses the given Protocol Buffers schema string, retrieves the 
FileDescriptor, and returns the
+   * Descriptor for the specified message name.
+   *
+   * @param schemaString The Protocol Buffers schema string.
+   * @param messageName The name of the message type for which the descriptor 
is desired.
+   * @return The Descriptor for the specified message name.
+   * @throws RuntimeException If there is an error during parsing or 
descriptor validation.
+   */
+  private static Descriptors.Descriptor getDescriptorFromProtoSchema(
+  final String 

Austin Group teleconference +1 888 974 9888 PIN 618 156 403

[Single UNIX Specification via austin-group-l at The Open Group]

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//opengroup.org//NONSGML kigkonsult.se iCalcreator 2.22.1//
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:America/New_York
X-LIC-LOCATION:America/New_York
BEGIN:DAYLIGHT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
DTSTART:20120311T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
DTSTART:20121104T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:659da25292...@opengroup.org
DTSTAMP:20240109T194522Z
ATTENDEE;ROLE=CHAIR:MAILTO:a.jo...@opengroup.org
CREATED:20240109T00Z
DESCRIPTION:Web/Project: Single UNIX Specification\nTitle: Austin Group tel
 econference +1 888 974 9888 PIN 618 156 403\nDate/Time: 15-Jan-2024 at 11:
 00 America/New_York\nDuration: 1.50 hours\nURL: https://collaboration.open
 group.org/platform/single_unix_specification/events.php\n\n 	\n\nAll calls 
 are anchored on US time\n\nTopic: Austin Group teleconference\n---
 \nAudio conference information
 \n---\n\nYou are invit
 ed to a Zoom meeting.\n\nMeeting ID: 618 156 403\n\nJoin from PC\, Mac\, i
 OS or Android: https://logitech.zoom.us/j/618156403\n \nor join by phone:
 \nUS: 888 974 9888\nUK: 800 031 5717\nDE: 800 724 3138\nFR: 805 082 588\n
 \nOther international numbers available here:\nhttps://zoom.us/u/adlvrb8IL
 j\n \nMeeting ID: 618 156 403\n\nor join from a H.323/SIP Device:\n   
  Dial: 162.255.37.11 (US West) or 162.255.36.11 (US East)\nMeeting ID:
  618 156 403\n\nShare from a PC or MAC: https://zoom.us/share/618156403\n
 \nOr iPhone one-tap (US Toll):  +16699006833\,618156403# or +16465588656\,
 618156403#\n\nPassword for zoom call  ends with x\n\nAll Austin Group part
 icipants are most welcome to join the call.\nThe call will last for 90 min
 utes.\n\n\nAn etherpad is usually up for a meeting\, with a URL using the 
 date format as below:\n\nhttps://posix.rhansen.org/p/202x-mm-dd\n\nLOGIN R
 EQUIRED to write to the ETHERPAD (Use your gitlab.opengroup.org login.)\n
 \n \n\nBug reports are available at:\nhttps://www.austingroupbugs.net\n
DTSTART;TZID=America/New_York:20240115T11
DURATION:PT1H30M0S
LAST-MODIFIED:20240109T144522Z
ORGANIZER;CN=Single UNIX Specification:MAILTO:do-not-re...@opengroup.org
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Austin Group teleconference +1 888 974 9888 PIN 618 156 403
TRANSP:OPAQUE
URL:https://collaboration.opengroup.org/platform/single_unix_specification/
 events.php
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-VISIBILITY:40
X-JOINBEFORE:5
X-CATEGORY:Teleconference
X-PLATO-SITE:Single UNIX Specification
X-PLATO-SITEID:136
END:VEVENT
END:VCALENDAR


meeting.ics
Description: application/ics

Austin Group teleconference +1 888 974 9888 PIN 618 156 403

[Single UNIX Specification via austin-group-l at The Open Group]

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//opengroup.org//NONSGML kigkonsult.se iCalcreator 2.22.1//
CALSCALE:GREGORIAN
METHOD:REQUEST
BEGIN:VTIMEZONE
TZID:America/New_York
X-LIC-LOCATION:America/New_York
BEGIN:DAYLIGHT
TZOFFSETFROM:-0500
TZOFFSETTO:-0400
TZNAME:EDT
DTSTART:20120311T02
RRULE:FREQ=YEARLY;BYMONTH=3;BYDAY=2SU
END:DAYLIGHT
BEGIN:STANDARD
TZOFFSETFROM:-0400
TZOFFSETTO:-0500
TZNAME:EST
DTSTART:20121104T02
RRULE:FREQ=YEARLY;BYMONTH=11;BYDAY=1SU
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:659da20668...@opengroup.org
DTSTAMP:20240109T194407Z
ATTENDEE;ROLE=CHAIR:MAILTO:a.jo...@opengroup.org
CREATED:20240109T00Z
DESCRIPTION:Web/Project: Single UNIX Specification\nTitle: Austin Group tel
 econference +1 888 974 9888 PIN 618 156 403\nDate/Time: 11-Jan-2024 at 11:
 00 America/New_York\nDuration: 1.50 hours\nURL: https://collaboration.open
 group.org/platform/single_unix_specification/events.php\n\n 	\n\nAll calls 
 are anchored on US time\n\nTopic: Austin Group teleconference\n---
 \nAudio conference information
 \n---\n\nYou are invit
 ed to a Zoom meeting.\n\nMeeting ID: 618 156 403\n\nJoin from PC\, Mac\, i
 OS or Android: https://logitech.zoom.us/j/618156403\n \nor join by phone:
 \nUS: 888 974 9888\nUK: 800 031 5717\nDE: 800 724 3138\nFR: 805 082 588\n
 \nOther international numbers available here:\nhttps://zoom.us/u/adlvrb8IL
 j\n \nMeeting ID: 618 156 403\n\nor join from a H.323/SIP Device:\n   
  Dial: 162.255.37.11 (US West) or 162.255.36.11 (US East)\nMeeting ID:
  618 156 403\n\nShare from a PC or MAC: https://zoom.us/share/618156403\n
 \nOr iPhone one-tap (US Toll):  +16699006833\,618156403# or +16465588656\,
 618156403#\n\nPassword for zoom call  ends with x\n\nAll Austin Group part
 icipants are most welcome to join the call.\nThe call will last for 90 min
 utes.\n\n\nAn etherpad is usually up for a meeting\, with a URL using the 
 date format as below:\n\nhttps://posix.rhansen.org/p/202x-mm-dd\n\nLOGIN R
 EQUIRED to write to the ETHERPAD (Use your gitlab.opengroup.org login.)\n
 \n \n\nBug reports are available at:\nhttps://www.austingroupbugs.net\n
DTSTART;TZID=America/New_York:20240111T11
DURATION:PT1H30M0S
LAST-MODIFIED:20240109T144407Z
ORGANIZER;CN=Single UNIX Specification:MAILTO:do-not-re...@opengroup.org
SEQUENCE:0
STATUS:CONFIRMED
SUMMARY:Austin Group teleconference +1 888 974 9888 PIN 618 156 403
TRANSP:OPAQUE
URL:https://collaboration.opengroup.org/platform/single_unix_specification/
 events.php
X-MICROSOFT-CDO-ALLDAYEVENT:FALSE
X-VISIBILITY:40
X-JOINBEFORE:5
X-CATEGORY:Teleconference
X-PLATO-SITE:Single UNIX Specification
X-PLATO-SITEID:136
END:VEVENT
END:VCALENDAR


meeting.ics
Description: application/ics

Re: IANA TZ / NerBSD TZ: tzalloc/tzfree and localtime_rz, mktime_z

[Andrew Josey via austin-group-l at The Open Group]

> On 5 Jan 2024, at 05:12, Robert Elz via austin-group-l at The Open Group 
>  wrote:
> 
>Date:Thu, 04 Jan 2024 23:24:26 +0100
>From:Steffen Nurpmeso 
>Message-ID:  <20240104222426.ai7_3Mvo@steffen%sdaoden.eu>
> 
>  | I was hoping for the draft; the selection list does not offer
>  | anything but ..TC2 and it.
> 
> If you want, you can submit a bug now, using any base standard
> that is in some way still current.   It just won't get processed
> at all (beyond random notes being added) until the next standard
> is being worked on, so submitting now is kind of pointless.
> 

Not necessarily, Austin/SD6 
(https://www.opengroup.org/austin/docs/austin_sd6.txt) lays out the Committee 
Maintenance Procedures for the Approved Standard, and there is a section on new 
work items.

So a proposal could advance that way, and lead to a separate standard adopted 
by one of the sponsoring organizations, and later adopted to issue 9. 
 
Over the years we have progressed a number of new API sets this way, before 
they went into the main standard ( the Extended API Sets Parts 1..4, and the 
Additional APIs for the Base Specifications Issue 8 Parts 1 and 2).
regards
Andrew
----
Andrew JoseyThe Open Group
Austin Group Chair  
Email: a.jo...@opengroup.org 
Apex Plaza, Forbury Road,Reading,Berks.RG1 1AX,England

To learn how we maintain your privacy, please review The Open Group Privacy 
Statement at http://www.opengroup.org/privacy.
To unsubscribe/opt-out from this mailing list login to The Open Group 
collaboration portal at
https://collaboration.opengroup.org/operational/portal.php?action=unsub=2481

Re: [AI] advice about an accessible, affordable smart watch

[Austin Pinto]

and regarding making calls on bluetooth watchs you can make and answer
call on a bluetooth smart watch if your phone and watch are in range
or if your phone and watch are connected on the same wifi and volte is
supported by your phone which as of now is supported on 3 4 year old
4g phone and newer

On 1/9/24, Austin Pinto  wrote:
> lte watches are there in both apple and samsung but you should not
> expect a lot from them as they have a small screen so there is very
> limited things on what you can do.
> but yes, if the app is supported by wareos or apples watch os then you
> can download and use.
>
> On 1/9/24, UDIT Pandey  wrote:
>> hi sorav,
>> Yes, I think, and, know also. As some watches have this functionality to
>> make and answer calls even by connected with bluetooth.
>> but, I have a question, if I have a lte watch can I download apps in it?
>> like, some daily to do apps. like, apps to make payment or the cab
>> booking
>> apps.
>> does apple watches support lte?
>>
>> --
>> Disclaimer:
>> 1. Contents of the mails, factual, or otherwise, reflect the thinking of
>> the
>> person sending the mail and AI in no way relates itself to its veracity;
>>
>> 2. AI cannot be held liable for any commission/omission based on the
>> mails
>> sent through this mailing list..
>>
>>
>> Search for old postings at:
>> http://www.mail-archive.com/accessindia@accessindia.org.in/
>> ---
>> You received this message because you are subscribed to the Google Groups
>> "AccessIndia" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to accessindia+unsubscr...@accessindia.org.in.
>> To view this discussion on the web visit
>> https://groups.google.com/a/accessindia.org.in/d/msgid/accessindia/CAJZg8fcVLY2mdMaX4qP%3DFab_JO7-8rRuVOxB-i-VqJgxrmzGmA%40mail.gmail.com.
>>
>
>
> --
> to listen to the Blind Android Users Podcast visit.
> www.blindandroidusers.com
> To join our mailing list, send those “join requests” to:
> blindandroidusers+subscr...@groups.io
> You may follow us on twitter using our handle:
> @BlindDroidUsers
> https://twitter.com/@BlindDroidUsers
> We do have a Telegram group that you can join and share stories or
> whatever with our members at:
> https://t.me/ANATAD
>


-- 
to listen to the Blind Android Users Podcast visit.
www.blindandroidusers.com
To join our mailing list, send those “join requests” to:
blindandroidusers+subscr...@groups.io
You may follow us on twitter using our handle:
@BlindDroidUsers
https://twitter.com/@BlindDroidUsers
We do have a Telegram group that you can join and share stories or
whatever with our members at:
https://t.me/ANATAD

-- 
Disclaimer:
1. Contents of the mails, factual, or otherwise, reflect the thinking of the 
person sending the mail and AI in no way relates itself to its veracity;

2. AI cannot be held liable for any commission/omission based on the mails sent 
through this mailing list..


Search for old postings at:
http://www.mail-archive.com/accessindia@accessindia.org.in/
--- 
You received this message because you are subscribed to the Google Groups 
"AccessIndia" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to accessindia+unsubscr...@accessindia.org.in.
To view this discussion on the web visit 
https://groups.google.com/a/accessindia.org.in/d/msgid/accessindia/CAPeFyi-mYNN5nYWe%3DHcX4h7%2BWFodkwEJbg0DLuOygd8icQb0eA%40mail.gmail.com.

Re: [AI] advice about an accessible, affordable smart watch

[Austin Pinto]

lte watches are there in both apple and samsung but you should not
expect a lot from them as they have a small screen so there is very
limited things on what you can do.
but yes, if the app is supported by wareos or apples watch os then you
can download and use.

On 1/9/24, UDIT Pandey  wrote:
> hi sorav,
> Yes, I think, and, know also. As some watches have this functionality to
> make and answer calls even by connected with bluetooth.
> but, I have a question, if I have a lte watch can I download apps in it?
> like, some daily to do apps. like, apps to make payment or the cab booking
> apps.
> does apple watches support lte?
>
> --
> Disclaimer:
> 1. Contents of the mails, factual, or otherwise, reflect the thinking of the
> person sending the mail and AI in no way relates itself to its veracity;
>
> 2. AI cannot be held liable for any commission/omission based on the mails
> sent through this mailing list..
>
>
> Search for old postings at:
> http://www.mail-archive.com/accessindia@accessindia.org.in/
> ---
> You received this message because you are subscribed to the Google Groups
> "AccessIndia" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to accessindia+unsubscr...@accessindia.org.in.
> To view this discussion on the web visit
> https://groups.google.com/a/accessindia.org.in/d/msgid/accessindia/CAJZg8fcVLY2mdMaX4qP%3DFab_JO7-8rRuVOxB-i-VqJgxrmzGmA%40mail.gmail.com.
>


-- 
to listen to the Blind Android Users Podcast visit.
www.blindandroidusers.com
To join our mailing list, send those “join requests” to:
blindandroidusers+subscr...@groups.io
You may follow us on twitter using our handle:
@BlindDroidUsers
https://twitter.com/@BlindDroidUsers
We do have a Telegram group that you can join and share stories or
whatever with our members at:
https://t.me/ANATAD

-- 
Disclaimer:
1. Contents of the mails, factual, or otherwise, reflect the thinking of the 
person sending the mail and AI in no way relates itself to its veracity;

2. AI cannot be held liable for any commission/omission based on the mails sent 
through this mailing list..


Search for old postings at:
http://www.mail-archive.com/accessindia@accessindia.org.in/
--- 
You received this message because you are subscribed to the Google Groups 
"AccessIndia" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to accessindia+unsubscr...@accessindia.org.in.
To view this discussion on the web visit 
https://groups.google.com/a/accessindia.org.in/d/msgid/accessindia/CAPeFyi-2e%3DBGUwHKhT2tZkbwGx6UVELFcjkb9SNstos%2Bs7Wxxg%40mail.gmail.com.

Re: [AI] advice about an accessible, affordable smart watch

[Austin Pinto]

yes. if you dont add an esim to an lte watch its the same as bluetooth.
but if you add the esim you can make and receive calls and sms
directly from your watch no need of taking the phone with you.

On 1/9/24, Mohib Anwar Rafay  wrote:
> However, let me concede that i didn't find my galaxy watch4 LTE model
> very useful in day to day life. It doesn't enhance utility of the
> phone drastically, it doesn't bring anything new except tracking your
> fitness related things. Like, it can count your steps, heart rate,
> sleep, snoring and work out.
>
> On 1/9/24, Mohib Anwar Rafay  wrote:
>> Hi Saurav, LTE watches have the capability of activating E-Sim in them
>> while bluetooth watch will be simply able to connect it to the phone
>> via bluetooth mode. It mean, if the watch isn't in the range of
>> paired phone, LTE watch will have incoming calls, outgoing calls, all
>> sms and its own network to do the things online, while bluetooth watch
>> will be dependent on the connected phone, if its in the range, it will
>> notify you regarding the calls etc otherwise it will be simply
>> disconnected from the world of internet and will be completely
>> offline. Its better to go for celluler or LTE model if you can stretch
>> your budget by few thousands more.
>>
>> On 1/9/24, Mohib Anwar Rafay  wrote:
>>> @Sandeep, Galaxy watch won't work with iPhone. Fossile Gen5 and Gen6
>>> watches are not great, they are very poor in terms of battery. Gen6
>>> comes along with 4100 chip on wear OS, but i heard its compatible with
>>> IOS.
>>> My recommendation would be, don't go for Fossile if the intented use
>>> is with iPhone. Look some other watch. If any of the apple watches
>>> fits in her budget, it will be the easiest and most logical
>>> investment.
>>>
>>> On 1/8/24, Saurav Hegde  wrote:
 Hi,
 I have a question, not directly related to accessibility.
 What is the difference between LTE and bluetooth watch?
 How does it affect the functionality of the watch?

 Thanks,
 Saurav
 Student at Brihan Maharashtra College of Commerce, Pune


 On Thu, Jan 4, 2024 at 6:40 PM adarsh nair
 
 wrote:

> Hello..
> Galaxy watch 4 is a good option with in this budget.   And it's
> accessible.
>
> Regards.
>  Adarsh Nair Nandanam music.
>
> On Thu, 4 Jan 2024, 18:32 Aravind R, 
> wrote:
>
>> apple is the most accessible one. but doubtful whether it comes under
>> 1 and user should have IOS mobile. Check for samsung if her
>> husband is not IOS user.
>>
>> On 04/01/2024, minar singh  wrote:
>> > Apple's smart watch
>> >
>> > On Thu, Jan 4, 2024 at 6:12 PM Sandeep Singh
>> > > >
>> > wrote:
>> >
>> >> Hello friends
>> >> First of all, New Year wishes to you and your dear ones! Have a
>> >> wonderful year ahead!
>> >> As the subjectline suggests, pls suggest some good accessible male
>> >> smart watch in the range of 5-10 thousand. A friend wishes to gift
>> >> her
>> >> husband with this, a little urgent pls.
>> >>
>> >> Looking forward in anticipation!
>> >>
>> >> --
>> >> Warm Regards
>> >> Sandeep Singh
>> >>
>> >> --
>> >> Disclaimer:
>> >> 1. Contents of the mails, factual, or otherwise, reflect the
>> >> thinking
>> of
>> >> the person sending the mail and AI in no way relates itself to its
>> >> veracity;
>> >>
>> >> 2. AI cannot be held liable for any commission/omission based on
>> >> the
>> >> mails
>> >> sent through this mailing list..
>> >>
>> >>
>> >> Search for old postings at:
>> >> http://www.mail-archive.com/accessindia@accessindia.org.in/
>> >> ---
>> >> You received this message because you are subscribed to the Google
>> Groups
>> >> "AccessIndia" group.
>> >> To unsubscribe from this group and stop receiving emails from it,
>> >> send
>> an
>> >> email to accessindia+unsubscr...@accessindia.org.in.
>> >> To view this discussion on the web visit
>> >>
>> https://groups.google.com/a/accessindia.org.in/d/msgid/accessindia/CAD4A2BQc%3DzVpeSe-2XgCMpNe%2B_e3sp8XE2oc5FZ4RcGMCy%3DYjg%40mail.gmail.com
>> >> .
>> >>
>> >
>> >
>> > --
>> > Future Grow Real Estate PVT LTD. "Web Designing Company"
>> > Mob: +91-9883380333, 9874740695 "For Technical Help"
>> >
>> > --
>> > Disclaimer:
>> > 1. Contents of the mails, factual, or otherwise, reflect the
>> > thinking
>> of the
>> > person sending the mail and AI in no way relates itself to its
>> > veracity;
>> >
>> > 2. AI cannot be held liable for any commission/omission based on
>> > the
>> mails
>> > sent through this mailing list..
>> >
>> >
>> > Search for old postings at:
>> > http://www.mail-archive.com/accessindia@accessindia.org.in/
>> > ---
>> > You received this 

mantis does not email-emit my web edits?

[Steffen Nurpmeso via austin-group-l at The Open Group]

Hello.

It seems Mantis did record, but not actually post my web edits of
this year, including the opened issue on tzalloc etc.
It would be nice if these would come :)

Ciao -- and a good and healthy 2024 everybody, if at all possible!

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[1003.1(2016/18)/Issue7+TC2 0001788]: The meaning of "Daylight Saving Time" should be clarified

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1788 
== 
Reported By:Guy Harris
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1788
Category:   Base Definitions and Headers
Type:   Clarification Requested
Severity:   Comment
Priority:   normal
Status: New
Name:   Guy Harris 
Organization:
User Reference:  
Section:N/A 
Page Number:N/A 
Line Number:N/A 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2023-11-18 00:16 UTC
Last Modified:  2024-01-08 17:50 UTC
== 
Summary:The meaning of "Daylight Saving Time" should be
clarified
==
Relationships   ID  Summary
--
related to  0001253 clarify that alternative time
== 

-- 
 (0006617) geoffclare (manager) - 2024-01-08 17:50
 https://austingroupbugs.net/view.php?id=1788#c6617 
-- 
The discussions in teleconferences are leaning towards adding the
definitions from RFC 8536 (as per
https://austingroupbugs.net/view.php?id=1788#c6584), suitably adapted for
POSIX. However, the question has also arisen of whether further changes
should be made to acknowledge the limitation of the historical tzname[] and
tm_isdst interfaces to cater for more than two timezone names.

One suggestion is to mark the tzname[] array obsolescent (in Issue 8 TC1)
and advise applications to obtain timezone names from either the tm_zone
structure member or the strftime() %Z conversion instead.

Another suggestion is that the standard could allow tzname[] to have more
than 2 entries, but the question arose as to whether this is something that
any implementation would want to do (or even has done already). Code from
before the C standard used the tm_isdst returned by localtime() as an index
for tzname[], and such code would "work" with more than two zone names.
Later code is unlikely to have done this because the C standard said any
positive tm_isdst value means DST is in effect (and thus in the context of
POSIX, the zone name would be tzname[1]). So it is not clear how much
benefit to applications there would be if an implementation were to make
that change. The only thing stopping it at the moment is the definition as
"extern char *tzname[2]" given on the tzset() page; the minimum change
needed would be just to remove that "2".

We would welcome any feedback on these suggestions. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-11-18 00:16 Guy Harris New Issue
2023-11-18 00:16 Guy Harris Name  => Guy Harris  
2023-11-18 00:16 Guy Harris Section   => N/A 
2023-11-18 00:16 Guy Harris Page Number   => N/A 
2023-11-18 00:16 Guy Harris Line Number   => N/A 
2023-11-20 01:03 Don Cragun Note Added: 0006573  
2023-11-20 01:04 Don Cragun Relationship added   related to 0001253  
2023-11-20 17:10 kreNote Added: 0006576  
2023-11-22 19:40 Guy Harris Note Added: 0006583  
2023-11-22 20:12 Guy Harris Note Added: 0006584  
2023-11-22 20:35 steffenNote Added: 0006585  
2023-11-22 20:37 steffenNote Added: 0006586  
2023-11-22 21:07 Guy Harris Note Added: 0006587  
2023-11-23 23:19 steffenNote Added: 0006588  
2023-11-23 23:21 steffenFile Added: grep-over-bsds.txt  
 
2023-11-24 02:46 Guy Harris Note Added: 0006589  
2023-11-25 21:28 steffenNote Added: 0006590  
2023-11-30 16:17 nick   Relationship added   parent of 0001779   
2023-11-30 16:19 nick   Relationship deleted parent of 0001779   
2023-11-30 22:57 steffen

"org.apache.thrift.transport.TTransportException: Invalid status -128" errors when SASL is enabled

[Austin Hackett]

Hi List
 
I'm having an issue where Hive Metastore operations (e.g. show databases) are 
failing with "org.apache.thrift.transport.TTransportException: Invalid status 
-128" errors when I enable SASL.
 
I am a bit stuck on how to go about troubleshooting this further, and any 
pointers would be greatly apprecicated...
 
Full details as follows:
 
- Ubuntu 22.04 & OpenJDK 8u342
- Unpacked Hive 3.1.3 binary release 
(https://dlcdn.apache.org/hive/hive-3.1.3/apache-hive-3.1.3-bin.tar.gz) to 
/opt/hive
- Unpacked Hadoop 3.1.0 binary release 
(https://archive.apache.org/dist/hadoop/common/hadoop-3.1.0/hadoop-3.1.0.tar.gz)
 to /opt/hadoop
- Created /opt/hive/conf/metastore-site.xml (see below for contents) and copied 
hdfs-site.xml and core-site.xml from the target HDFS cluster to /opt/hive/conf
- export HADOOP_HOME=/opt/hadoop
- export HIVE_HOME=/opt/hive
- Successfully started the metastore, i.e. hive --service metastore
- Use a Hive Metastore client to "show databases" and get an error (see below 
for the associated errors in the HMS log). I get the same error with 
spark-shell running in local mode and the Python hive-metastore-client 
(https://pypi.org/project/hive-metastore-client/)
 
 
metastore-site.xml
==

  
metastore.warehouse.dir
/user/hive/warehouse
  
  
javax.jdo.option.ConnectionDriverName
org.postgresql.Driver
  
  
javax.jdo.option.ConnectionURL
jdbc:postgresql://postgres.example.net:5432/metastore_db 

  
  
javax.jdo.option.ConnectionUserName
hive
  
  
javax.jdo.option.ConnectionPassword
password
  
  
metastore.kerberos.principal
hive/_h...@example.netmailto:hive/_h...@example.net%3c/value>>
  
  
metastore.kerberos.keytab.file
/etc/security/keytabs/hive.keytab
  
  
hive.metastore.sasl.enabled
true
  

==
 
HMS log shows that it is able to authenticate using the specified keytab and 
principle (and I have also checked this manually via kinit command):
 

2024-01-08T13:12:33,463  WARN [main] security.HadoopThriftAuthBridge: 
Client-facing principal not set. Using server-side setting: 
hive/_h...@example.net 
2024-01-08T13:12:33,464  INFO [main] security.HadoopThriftAuthBridge: Logging 
in via CLIENT based principal
2024-01-08T13:12:33,471 DEBUG [main] security.UserGroupInformation: Hadoop login
2024-01-08T13:12:33,472 DEBUG [main] security.UserGroupInformation: hadoop 
login commit
2024-01-08T13:12:33,472 DEBUG [main] security.UserGroupInformation: Using 
kerberos user: hive/metstore.example@example.net 

2024-01-08T13:12:33,472 DEBUG [main] security.UserGroupInformation: Using user: 
"hive/metstore.example@example.net 
" with name: 
hive/metstore.example@example.net 

2024-01-08T13:12:33,472 DEBUG [main] security.UserGroupInformation: User entry: 
"hive/metstore.example@example.net 
"
2024-01-08T13:12:33,472  INFO [main] security.UserGroupInformation: Login 
successful for user hive/metstore.example@example.net 
 using keytab file hive.keytab. 
Keytab auto renewal enabled : false
2024-01-08T13:12:33,472  INFO [main] security.HadoopThriftAuthBridge: Logging 
in via SERVER based principal
2024-01-08T13:12:33,480 DEBUG [main] security.UserGroupInformation: Hadoop login
2024-01-08T13:12:33,480 DEBUG [main] security.UserGroupInformation: hadoop 
login commit
2024-01-08T13:12:33,480 DEBUG [main] security.UserGroupInformation: Using 
kerberos user: hive/metstore.example@example.net 

2024-01-08T13:12:33,480 DEBUG [main] security.UserGroupInformation: Using user: 
"hive/metstore.example@example.net 
" with name: 
hive/metstore.example@example.net 

2024-01-08T13:12:33,480 DEBUG [main] security.UserGroupInformation: User entry: 
"hive/metstore.example@example.net 
"
2024-01-08T13:12:33,480  INFO [main] security.UserGroupInformation: Login 
successful for user hive/metstore.example@example.net 
 using keytab file hive.keytab. 
Keytab auto renewal enabled : false

 
However, when i attempt to "show databases":
 

2024-01-08T13:59:08,068 DEBUG [pool-6-thread-1] security.UserGroupInformation: 
PrivilegedAction [as: hive/metstore.example@example.net 
 
(auth:KERBEROS)][action:org.apache.hadoop.hive.metastore.security.HadoopThriftAuthBridge$Server$TUGIAssumingTransportFactory$1@1e655c9
 
]
java.lang.Exception: 

Re: [AI] How blind-friendly is your Mumbai and what about water sports?

[Austin Pinto]

for the train, big stations have beeps for handicapt but the
compartment may be a bit this side or that side of the beep.
they have tactile marking which you walk on the platform you will no,
but they are a bit to the edge so take care.
some busses have announcements for stops but most atleast on the cst
gateway root dont.
regarding does or donts, its the same for all big cities.
take care of valuables, dont stand with mobile near the train or buss
door and keep attentions on your pockets.

On 1/8/24, Kanchan Pamnani  wrote:
> Don’t know anything about Water Sports.
>
> Mumbai is not accessible but helpful.
>
> If you are coming to Gateway to go to Elephanta then I can help you get on
> the Boat.  From Gateway you can get a BEST bus for Rs. 6/- to CST station
> which will then allow you to get a train for Panvel direct.
>
> Haji ali is not possible. You will go out of the route and you will find it
> very difficult to get to Panvel.
>
> If you have 2 days then Haji Ali can be done.
>
> Let me know when you are planning to come.
>
> K
>
>
>
> From: accessindia@accessindia.org.in [mailto:accessindia@accessindia.org.in]
> On Behalf Of Shadab Husain
> Sent: 08 January 2024 13:41
> To: accessindia
> Subject: [AI] How blind-friendly is your Mumbai and what about water
> sports?
>
>
>
> Hi friends,
>
>
>
> I’m visiting Mumbai in some time and would be glad to know how friendly
> public transportation is there for the totally blind.
>
>
>
> I have less than 24 hours to see the Gateway of India and take a ferry to
> the Elephanta Caves. I intend to also see the Haji Ali Dargah from where
> I’ll ride to Panvel Railway Station.
>
>
>
> Additionally, I want to parasail and scuba dive. Goa guys denied me
> parasailing after knowing my blindness and said that they’ll get their
> license cancelled if they allow me. I only managed to take a jet ski there,
> and this happened when I quietly handed money to them and took full
> responsibility.
>
>
>
> Kindly also let me know if there’re any special dos or don’ts for a blind
> travelling alone to Mumbai.
>
>
>
> Awaiting responses.
>
>
>
> Thanks,
>
>
>
> Shadab
>
>
>
> --
>
> http://husainjournal.blogspot.com/
>
> --
> Disclaimer:
> 1. Contents of the mails, factual, or otherwise, reflect the thinking of the
> person sending the mail and AI in no way relates itself to its veracity;
>
> 2. AI cannot be held liable for any commission/omission based on the mails
> sent through this mailing list..
>
>
> Search for old postings at:
> http://www.mail-archive.com/accessindia@accessindia.org.in/
> ---
> You received this message because you are subscribed to the Google Groups
> "AccessIndia" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to accessindia+unsubscr...@accessindia.org.in
>  .
> To view this discussion on the web visit
> https://groups.google.com/a/accessindia.org.in/d/msgid/accessindia/CAFd_ntn3vj%2BBDOs03zzsjvZ%3DDnwJ8jaoLs-6261BdSgEY3N-wA%40mail.gmail.com
> 
> .
>
> --
> Disclaimer:
> 1. Contents of the mails, factual, or otherwise, reflect the thinking of the
> person sending the mail and AI in no way relates itself to its veracity;
>
> 2. AI cannot be held liable for any commission/omission based on the mails
> sent through this mailing list..
>
>
> Search for old postings at:
> http://www.mail-archive.com/accessindia@accessindia.org.in/
> ---
> You received this message because you are subscribed to the Google Groups
> "AccessIndia" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to accessindia+unsubscr...@accessindia.org.in.
> To view this discussion on the web visit
> https://groups.google.com/a/accessindia.org.in/d/msgid/accessindia/003b01da4241%2415cf8540%24416e8fc0%24%40gmail.com.
>


-- 
to listen to the Blind Android Users Podcast visit.
www.blindandroidusers.com
To join our mailing list, send those “join requests” to:
blindandroidusers+subscr...@groups.io
You may follow us on twitter using our handle:
@BlindDroidUsers
https://twitter.com/@BlindDroidUsers
We do have a Telegram group that you can join and share stories or
whatever with our members at:
https://t.me/ANATAD

-- 
Disclaimer:
1. Contents of the mails, factual, or otherwise, reflect the thinking of the 
person sending the mail and AI in no way relates itself to its veracity;

2. AI cannot be held liable for any commission/omission based on the mails sent 
through this mailing list..


Search for old postings at:
http://www.mail-archive.com/accessindia@accessindia.org.in/
--- 
You received this message because you are subscribed to the Google Groups 
"AccessIndia" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to 

Re: IVY-1576 still exist in 2.5.2

[Austin Zhang]

Thanks Stefan,
After removing ~/.ivy2, I
successfully downloaded org.tensorflow_tensorflow-core-api-0.5.0.jar and
org.bytedeco_javacpp-1.5.8.jar.

But as you mentioned, if I download using 2.5.1 previously, then even If I
upgrade to 2.5.2, it still won't download them.

So I think the tips for folks bumping into this issue is to clean the ivy
cache.

Thanks again for helping out
Austin

On Sun, Jan 7, 2024 at 5:37 AM Stefan Bodewig  wrote:

> On 2023-12-13, Austin Zhang wrote:
>
> > java -jar apache-ivy-2.5.2/ivy-2.5.2.jar -dependency "org.tensorflow"
> > "tensorflow-core-platform-gpu" "0.5.0" -retrieve
> > "ivy/[organization]_[artifact]-[revision](-[classifier]).[ext]" -confs
> > "runtime" -debug
>
> > files in ivy folder are:
> > com.google.protobuf_protobuf-java-3.19.4.jar
> > org.bytedeco_javacpp-1.5.8-windows-x86_64.jar
> > org.bytedeco_javacpp-1.5.8-linux-x86_64.jar
> > org.tensorflow_tensorflow-core-api-0.5.0-linux-x86_64-gpu.jar
> > org.tensorflow_tensorflow-core-api-0.5.0-windows-x86_64-gpu.jar
> > org.tensorflow_ndarray-0.4.0.jar
>
> > Both org.bytedeco_javacpp-1.5.8.jar and
> > org.tensorflow_tensorflow-core-api-0.5.0.jar
> > are missing.
>
> Running this with a freshly downloaded ivy-2.5.2.jar results in
>
> $ ls ivy
> com.google.protobuf_protobuf-java-3.19.4.jar
> org.bytedeco_javacpp-1.5.8.jar
> org.bytedeco_javacpp-1.5.8-linux-x86_64.jar
> org.bytedeco_javacpp-1.5.8-windows-x86_64.jar
> org.tensorflow_ndarray-0.4.0.jar
> org.tensorflow_tensorflow-core-api-0.5.0.jar
> org.tensorflow_tensorflow-core-api-0.5.0-linux-x86_64-gpu.jar
> org.tensorflow_tensorflow-core-api-0.5.0-windows-x86_64-gpu.jar
>
> for me. It seems as if I do get the expected results.
>
> If you have tried to download things with an earlier version of Ivy
> before you may be using cached ivy descriptors created from the Maven
> POMs with the older version.
>
> I don't think you are hitting IVY-1576 - which is not the only bug in
> translating POMs. In 2.5.2 we fixed IVY-1642 (which looks more like the
> problem you have) which in turn is a more complete fix of IVY-1580.
>
> Please remove your cached artifacts of everythng and try again with Ivy
> 2.5.2.
>
> Stefan
>
> -
> To unsubscribe, e-mail: dev-unsubscr...@ant.apache.org
> For additional commands, e-mail: dev-h...@ant.apache.org
>
>

Re: IANA TZ / NerBSD TZ: tzalloc/tzfree and localtime_rz, mktime_z

[Steffen Nurpmeso via austin-group-l at The Open Group]

Hello.

Robert Elz wrote in
 <2506.1704431...@jacaranda.noi.kre.to>:
 |Date:Thu, 04 Jan 2024 23:24:26 +0100
 |From:Steffen Nurpmeso 
 |Message-ID:  <20240104222426.ai7_3Mvo@steffen%sdaoden.eu>
 |
 || I was hoping for the draft; the selection list does not offer
 || anything but ..TC2 and it.
 |
 |If you want, you can submit a bug now, using any base standard
 |that is in some way still current.   It just won't get processed
 |at all (beyond random notes being added) until the next standard
 |is being worked on, so submitting now is kind of pointless.

Yes i will open one soon.  I will not add much more than in the
email i wrote, so page numbers and such are no problem.
tzalloc/tzfree are completely new anyway, and the other two
functions get a paragraph added where they belong.

 |On the other hand, delaying may lead to a much better proposal.
 |I in particular would like to see "struct tm" given a complete
 |overhaul - resulting in a struct with a different name of
 |course.   And then, naturally, the interface routines that
 |manipulate it all need redesigning (and renaming).
 |
 |That would be the perfect opportunity to make all the new ones
 |thread safe, and just allow what is there now to wither away.
 |
 |Of course, this is not the place to do that design (and implementation)
 |that needs to happen elsewhere, and then be spread amongst the
 |various systems first - only then should anything happen in the
 |standards universe.

Mostly "everyone i know" was doing some kind of "datetime" object.
If a the native C library would make that fast and thread-safe out
of the box, i would expect many scripting languages (and simple
C or C++ wrappers) to be very happy about it.
Actually having such an API as such would be even better ... but
i can hardly imagine this to happen.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Minutes of the 4th January 2024 Teleconference

[Andrew Josey via austin-group-l at The Open Group]

hi All
Happy New Year! Attached are the minutes of our first meeting of the year
regards
Andrew
-
Minutes of the 4th January 2024 TeleconferenceAustin-1373 Page 1 of 1
Submitted by Andrew Josey, The Open Group. 5th January 2024

Attendees:
Don Cragun, IEEE PASC OR
Nick Stoughton, Logitech/USENIX, ISO/IEC JTC 1/SC 22 OR
Andrew Josey, The Open Group
Geoff Clare, The Open Group
Mark Ziegast, SHware Systems Dev.
Eric Blake, Red Hat, The Open Group OR

Apologies
Tom Thompson, IEEE

* General news

Draft 4 is now in review at The Open Group and IEEE,
with the review closing on January 31 2024. No comments
have been received as yet.

The draft was submitted to ISO/IEC, and after the meeting
some comments have been received from the ISO editors that need to be
addressed, to set the document on A4 (from US Letter),
also to remove any reviewers notes (there is on in §1.6 Terminology).

Andrew completed the action to issue a status report (Austin/1372).

Andrew reported he has been added to the IEEE CS MSC mailing list
(the successor to the PASC). A meeting is scheduled for January 9th.
An item for the meeting is to confirm that Don will continue
as the IEEE SA representative to the Austin Group.


* Current Business


Bug 1785: Conflict in specification of processing of declaration utilities 
Accepted as Marked
https://austingroupbugs.net/view.php?id=1785

This item is tagged for TC1-2024.

On page 2483 line 80766 section 2.9.1.1, change:

The first word (if any) that is not a variable assignment or
redirection shall be expanded. If any fields remain following
its expansion, the first field shall be considered the command
name. If no fields remain, the next word (if any) shall be
expanded, and so on, until a command name is found or no words
remain. If there is a command name and it is recognized as a
declaration utility, then any remaining words after the word
that expanded to produce the command name, that would be
recognized as a variable assignment in isolation, shall be
expanded as a variable assignment (tilde expansion after the
first  and after any unquoted , parameter
expansion, command substitution, arithmetic expansion, and quote
removal, but no field splitting or pathname expansion); while
remaining words that would not be a variable assignment in
isolation shall be subject to regular expansion (tilde expansion
for only a leading , parameter expansion, command
substitution, arithmetic expansion, field splitting, pathname
expansion, and quote removal). For all other command names,
words after the word that produced the command name shall be
subject only to regular expansion. All fields resulting from
the expansion of the word that produced the command name and
the subsequent words, except for the field containing the command
name, shall be the arguments for the command.

to:

The first word (if any) that is not a variable assignment or
redirection, and any subsequent words, shall be processed as
follows:


The first word may be matched lexically against the names
of declaration utilities.

The first word shall be expanded.

If any fields remain following expansion of the first word,
the first field shall be considered the command name. If
no fields remain, the next word (if any) shall be expanded,
and so on, until a command name is found or no words remain.

If the above optional matching against the names of declaration
utilities was not performed and there is a command name,
the command name shall be matched lexically against the
names of declaration utilities.

If whichever of the matching operations that was performed
produced a successful match, any remaining words after the
word that expanded to produce the command name, that would
be recognized as a variable assignment in isolation, shall
be expanded as a variable assignment (tilde expansion after
the first  and after any unquoted ,
parameter expansion, command substitution, arithmetic
expansion, and quote removal, but no field splitting or
pathname expansion); while remaining words that would not
be a variable assignment in isolation shall be subject to
regular expansion (tilde expansion for only a leading
, parameter expansion, command substitution, arithmetic
expansion, field splitting, pathname expansion, and quote
removal). If the matching operation did not produce a
successful match, words after the word that produced the
command name shall be subject only to regular expansion.

All fields resulting from the expansion of the word that
produced the command name and the subsequent words, except
for the field containing the command name, shall

Re: IANA TZ / NerBSD TZ: tzalloc/tzfree and localtime_rz, mktime_z

[Robert Elz via austin-group-l at The Open Group]

Date:Thu, 04 Jan 2024 23:24:26 +0100
From:Steffen Nurpmeso 
Message-ID:  <20240104222426.ai7_3Mvo@steffen%sdaoden.eu>

  | I was hoping for the draft; the selection list does not offer
  | anything but ..TC2 and it.

If you want, you can submit a bug now, using any base standard
that is in some way still current.   It just won't get processed
at all (beyond random notes being added) until the next standard
is being worked on, so submitting now is kind of pointless.

On the other hand, delaying may lead to a much better proposal.
I in particular would like to see "struct tm" given a complete
overhaul - resulting in a struct with a different name of
course.   And then, naturally, the interface routines that
manipulate it all need redesigning (and renaming).

That would be the perfect opportunity to make all the new ones
thread safe, and just allow what is there now to wither away.

Of course, this is not the place to do that design (and implementation)
that needs to happen elsewhere, and then be spread amongst the
various systems first - only then should anything happen in the
standards universe.

kre

Re: IANA TZ / NerBSD TZ: tzalloc/tzfree and localtime_rz, mktime_z

[enh via austin-group-l at The Open Group]

On Thu, Jan 4, 2024 at 2:25 PM Steffen Nurpmeso  wrote:
>
> enh wrote in
>  :
>  |for other precedent, bionic [Android] has tzalloc()/tzfree(),
>  |mktime_z(), localtime_rz(), and the timezone_t type since API level
>  |35:
>  |
>  |https://android.googlesource.com/platform/bionic/+/main/libc/include/time.h
>
> Not yet released?  "Vanilla ice cream".

yeah, it's in AOSP right now, but in terms of "phones in regular
people's pockets", it'll be in this year's release.

> It really is the better interface.

indeed. i regret not exposing this years ago.

i don't think the rust people realized their thread-safe house was
built on the sand of a shared global, but at least this gives them an
alternative going forward (for Android and NetBSD, anyway).

> --steffen
> |
> |Der Kragenbaer,The moon bear,
> |der holt sich munter   he cheerfully and one by one
> |einen nach dem anderen runter  wa.ks himself off
> |(By Robert Gernhardt)

Re: IANA TZ / NerBSD TZ: tzalloc/tzfree and localtime_rz, mktime_z

[Steffen Nurpmeso via austin-group-l at The Open Group]

enh wrote in
 :
 |for other precedent, bionic [Android] has tzalloc()/tzfree(),
 |mktime_z(), localtime_rz(), and the timezone_t type since API level
 |35:
 |
 |https://android.googlesource.com/platform/bionic/+/main/libc/include/time.h

Not yet released?  "Vanilla ice cream".
It really is the better interface.

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

Re: IANA TZ / NerBSD TZ: tzalloc/tzfree and localtime_rz, mktime_z

[Steffen Nurpmeso via austin-group-l at The Open Group]

Robert Elz wrote in
 <25502.1704337...@jacaranda.noi.kre.to>:
 |Date:Thu, 04 Jan 2024 00:21:45 +0100
 |From:"Steffen Nurpmeso via austin-group-l at The Open Group" \
 |
 |Message-ID:  <20240103232145.6dAnvvQf@steffen%sdaoden.eu>
 |
 || My question: against which standard should an issue be opened?
 |
 |The next one, after it is issued (ie: just wait, and send in the
 |request after the next standard is published, which is probably
 |this year sometime) - it is far too late for new interfaces in the
 |one currently being developed (the cutoff for those was back in
 |August or something like that).

Sad.  Very sad.

 |The means, issue 9 is the earliest any new interfaces can be added.

I was hoping for the draft; the selection list does not offer
anything but ..TC2 and it.

 |kre
 --End of <25502.1704337...@jacaranda.noi.kre.to>

--steffen
|
|Der Kragenbaer,The moon bear,
|der holt sich munter   he cheerfully and one by one
|einen nach dem anderen runter  wa.ks himself off
|(By Robert Gernhardt)

[1003.1(2016/18)/Issue7+TC2 0001793]: Streamline US-ASCII character set name

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1793 
== 
Reported By:steffen
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1793
Category:   Front Matter
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: New
Name:   steffen 
Organization:
User Reference:  
Section:many 
Page Number:many 
Line Number:many 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2023-12-19 02:02 UTC
Last Modified:  2024-01-04 22:02 UTC
== 
Summary:Streamline US-ASCII character set name
== 

-- 
 (0006615) steffen (reporter) - 2024-01-04 22:02
 https://austingroupbugs.net/view.php?id=1793#c6615 
-- 
Ooooh, careful with that axe -- greetings to the big apple!!!
I quote art(at)ietf.org and John C. Klensin, he will excuse this.
(And point out that _i_ do not follow him.)

Starting with IANA and copying the charsets list, as Martin
suggests, is almost certainly a good step at this stage (I'm
copying IANS on this note to avoid possible confusion).
However, to fill in the historical blank: the omission was
almost certainly deliberate (I vaguely recall being part of the
discussion).  While I found the idea of "US-ASCII" obnoxious
(and still do -- after all, the "A" in ASCII does not stand for
"Antarctic" or a variety of other options), it was very common
practice in the 1990s to use the term "ASCII" to refer to a
variety of character sets that used the high order bit of an
octet (including ISO 8859 -- the omission of "-1" is deliberate)
and even used "ASCII" to refer to assorted national language
variations and national variations on ISO 646.  So "ASCII" was
avoided because it was seriously ambiguous.   There is evidence
that the confusion continues: the definition of IBM CP 367
("IBM367" and "cp367" in the IANA registry) [1] as a synonym for
"US-ASCII" is incorrect or at least sketchy because it lists
iso-646.irv:1983 as another synonym and ISO 646 IRV did not
match ASCII until 1991 [2] because, prior to that, the
"international currency symbol" was used instead of ASCII's
dollar sign.  That isn't proof but does suggest that the
confusion we say in the 1990s has not completely disappeared.

So, coming back to Steffen's suggestion, I strongly recommend
against adding "ASCII" to the alias list without an explanation
and warning about the ambiguity.  And the current registry
arrangement does not allow for that sort of note although maybe
it should. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-12-19 02:02 steffenNew Issue
2023-12-19 02:02 steffenName  => steffen 
2023-12-19 02:02 steffenSection   => many
2023-12-19 02:02 steffenPage Number   => many
2023-12-19 02:02 steffenLine Number   => many
2024-01-04 16:05 shware_systems Note Added: 0006613  
2024-01-04 22:02 steffenNote Added: 0006615  
==

[Issue 8 drafts 0001785]: Conflict in specification of processing of declaration utilities

[Austin Group Bug Tracker via austin-group-l at The Open Group]

The following issue has been RESOLVED. 
== 
https://austingroupbugs.net/view.php?id=1785 
== 
Reported By:kre
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1785
Category:   Shell and Utilities
Type:   Error
Severity:   Objection
Priority:   normal
Status: Resolved
Name:   Robert Elz 
Organization:
User Reference:  
Section:XCU 2.9.1.1 
Page Number:2483 
Line Number:80766-80778, 80790-80792 
Final Accepted Text:https://austingroupbugs.net/view.php?id=1785#c6614 
Resolution: Accepted As Marked
Fixed in Version:   
== 
Date Submitted: 2023-10-28 04:09 UTC
Last Modified:  2024-01-04 16:56 UTC
== 
Summary:Conflict in specification of processing of
declaration utilities
==
Relationships   ID  Summary
--
related to  0001535 Poor description of declaration (all re...
related to  0001393 'command' should not be treated as a de...
related to  351 certain shell special built-ins should ...
== 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-10-28 04:09 kreNew Issue
2023-10-28 04:09 kreName  => Robert Elz  
2023-10-28 04:09 kreSection   => XCU 2.9.1.1 
2023-10-28 04:09 krePage Number   => 2483
2023-10-28 04:09 kreLine Number   => 80766-80778,
80790-80792
2023-10-28 05:48 kreNote Added: 0006557  
2023-10-28 06:27 Don Cragun Relationship added   related to 0001535  
2023-10-28 06:28 Don Cragun Relationship added   related to 0001393  
2023-10-28 06:30 Don Cragun Relationship added   related to 351  
2023-10-30 14:07 chet_ramey Note Added: 0006559  
2023-12-11 15:37 geoffclare Note Added: 0006597  
2023-12-11 23:19 kreNote Added: 0006601  
2023-12-18 16:54 shware_systems Note Added: 0006612  
2024-01-04 16:54 geoffclare Note Added: 0006614  
2024-01-04 16:56 geoffclare Final Accepted Text   =>
https://austingroupbugs.net/view.php?id=1785#c6614
2024-01-04 16:56 geoffclare Status   New => Resolved 
2024-01-04 16:56 geoffclare Resolution   Open => Accepted As
Marked
==

[Issue 8 drafts 0001785]: Conflict in specification of processing of declaration utilities

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1785 
== 
Reported By:kre
Assigned To:
== 
Project:Issue 8 drafts
Issue ID:   1785
Category:   Shell and Utilities
Type:   Error
Severity:   Objection
Priority:   normal
Status: New
Name:   Robert Elz 
Organization:
User Reference:  
Section:XCU 2.9.1.1 
Page Number:2483 
Line Number:80766-80778, 80790-80792 
Final Accepted Text: 
== 
Date Submitted: 2023-10-28 04:09 UTC
Last Modified:  2024-01-04 16:54 UTC
== 
Summary:Conflict in specification of processing of
declaration utilities
==
Relationships   ID  Summary
--
related to  0001535 Poor description of declaration (all re...
related to  0001393 'command' should not be treated as a de...
related to  351 certain shell special built-ins should ...
== 

-- 
 (0006614) geoffclare (manager) - 2024-01-04 16:54
 https://austingroupbugs.net/view.php?id=1785#c6614 
-- 
On page 2483 line 80766 section 2.9.1.1, change:The first word
(if any) that is not a variable assignment or redirection shall be
expanded. If any fields remain following its expansion, the first field
shall be considered the command name. If no fields remain, the next word
(if any) shall be expanded, and so on, until a command name is found or no
words remain. If there is a command name and it is recognized as a
declaration utility, then any remaining words after the word that expanded
to produce the command name, that would be recognized as a variable
assignment in isolation, shall be expanded as a variable assignment (tilde
expansion after the first  and after any unquoted ,
parameter expansion, command substitution, arithmetic expansion, and quote
removal, but no field splitting or pathname expansion); while remaining
words that would not be a variable assignment in isolation shall be subject
to regular expansion (tilde expansion for only a leading , parameter
expansion, command substitution, arithmetic expansion, field splitting,
pathname expansion, and quote removal). For all other command names, words
after the word that produced the command name shall be subject only to
regular expansion. All fields resulting from the expansion of the word that
produced the command name and the subsequent words, except for the field
containing the command name, shall be the arguments for the
command.to:The first word (if any) that is not a
variable assignment or redirection, and any subsequent words, shall be
processed as follows:
The first word may be matched lexically against the names of
declaration utilities.
The first word shall be expanded.
If any fields remain following expansion of the first word, the first
field shall be considered the command name. If no fields remain, the next
word (if any) shall be expanded, and so on, until a command name is found
or no words remain.
If the above optional matching against the names of declaration
utilities was not performed and there is a command name, the command name
shall be matched lexically against the names of declaration
utilities.
If whichever of the matching operations that was performed produced a
successful match, any remaining words after the word that expanded to
produce the command name, that would be recognized as a variable assignment
in isolation, shall be expanded as a variable assignment (tilde expansion
after the first  and after any unquoted , parameter
expansion, command substitution, arithmetic expansion, and quote removal,
but no field splitting or pathname expansion); while remaining words that
would not be a variable assignment in isolation shall be subject to regular
expansion (tilde expansion for only a leading , parameter expansion,
command substitution, arithmetic expansion, field splitting, pathname
expansion, and quote removal). If the matching operation did not produce a
successful match, words after the word that produced the command name shall
be subject only to regular expansion.
All fields resulting from the expansion of the word that 

[1003.1(2016/18)/Issue7+TC2 0001793]: Streamline US-ASCII character set name

[Austin Group Bug Tracker via austin-group-l at The Open Group]

A NOTE has been added to this issue. 
== 
https://austingroupbugs.net/view.php?id=1793 
== 
Reported By:steffen
Assigned To:
== 
Project:1003.1(2016/18)/Issue7+TC2
Issue ID:   1793
Category:   Front Matter
Type:   Enhancement Request
Severity:   Editorial
Priority:   normal
Status: New
Name:   steffen 
Organization:
User Reference:  
Section:many 
Page Number:many 
Line Number:many 
Interp Status:  --- 
Final Accepted Text: 
== 
Date Submitted: 2023-12-19 02:02 UTC
Last Modified:  2024-01-04 16:05 UTC
== 
Summary:Streamline US-ASCII character set name
== 

-- 
 (0006613) shware_systems (reporter) - 2024-01-04 16:05
 https://austingroupbugs.net/view.php?id=1793#c6613 
-- 
The standard references ASCII in its pre-ISO-2021 versions of the 1960s, as
overridden by the C standard. Afaik US-ASCII is a synonym for the current
version of ISO-646, which defers to ISO-2021, not POSIX or C, for how
control codes are expected to function. As such references to US-ASCII
should probably be shortened to just ASCII. 

Issue History 
Date ModifiedUsername   FieldChange   
== 
2023-12-19 02:02 steffenNew Issue
2023-12-19 02:02 steffenName  => steffen 
2023-12-19 02:02 steffenSection   => many
2023-12-19 02:02 steffenPage Number   => many
2023-12-19 02:02 steffenLine Number   => many
2024-01-04 16:05 shware_systems Note Added: 0006613  
==

Re: IANA TZ / NerBSD TZ: tzalloc/tzfree and localtime_rz, mktime_z

[Robert Elz via austin-group-l at The Open Group]

Date:Thu, 04 Jan 2024 00:21:45 +0100
From:"Steffen Nurpmeso via austin-group-l at The Open Group" 

Message-ID:  <20240103232145.6dAnvvQf@steffen%sdaoden.eu>

  | My question: against which standard should an issue be opened?

The next one, after it is issued (ie: just wait, and send in the
request after the next standard is published, which is probably
this year sometime) - it is far too late for new interfaces in the
one currently being developed (the cutoff for those was back in
August or something like that).

The means, issue 9 is the earliest any new interfaces can be added.

kre