[UPDATE] xcb-proto and libxcb 1.14

2020-03-22 Thread Matthieu Herrb
Hi,

the patch below updates XCB (xcb-proto and libxcb) to version 1.14.0.

I've been running this on amd64 for a while. Comments ? ok ?

Note that it goes together with an update to the x11/py-xcbgen port
that I'm sending to ports@ at the same time.

Index: dist/libxcb/ChangeLog
===
RCS file: /cvs/OpenBSD/xenocara/dist/libxcb/ChangeLog,v
retrieving revision 1.3
diff -u -p -u -r1.3 ChangeLog
--- dist/libxcb/ChangeLog   4 Oct 2018 20:17:48 -   1.3
+++ dist/libxcb/ChangeLog   8 Mar 2020 17:55:27 -
@@ -1,3 +1,141 @@
+commit 4b40b44cb6d088b6ffa2fb5cf3ad8f12da588cef
+Author: Matt Turner 
+Date:   Sat Feb 22 12:10:53 2020 -0800
+
+Release libxcb 1.14
+
+Signed-off-by: Matt Turner 
+
+commit 78c492deaa7ae3aad0b0eeb4b126bb291cc637a7
+Author: Matt Turner 
+Date:   Sat Feb 22 12:19:58 2020 -0800
+
+Build xz tarballs instead of bzip2
+
+Signed-off-by: Matt Turner 
+
+commit 8f7e4c4e9fc6ee6b5b5498a7d8af79150be0d26a
+Author: Matt Turner 
+Date:   Sat Feb 22 11:24:11 2020 -0800
+
+configure.ac: Depend on pthread-stubs only on not-Linux
+
+Signed-off-by: Matt Turner 
+
+commit f9f4b00aad69ff36e81c63089b1b16660eaca900
+Author: Sam Varshavchik 
+Date:   Sat Jan 4 10:43:59 2020 -0500
+
+Implement xcb_total_read() and xcb_total_written().
+
+Returns raw byte counts that have been read or written to the
+xcb_connection_t.
+
+I found it very useful when developing a high level widget toolkit, to
+track down inefficient/sub-optimum code that generates a lot of X
+protocol traffic.
+
+Signed-off-by: Sam Varshavchik 
+
+commit 59e271e15bcecf0c461cd5c6c59081fb86b96c22
+Author: A. Wilcox 
+Date:   Mon Dec 23 21:49:29 2019 -0600
+
+tests: Support Check 0.13.0 API
+
+[mattst88]: Keep compatibility  with old API via preprocessor
+
+Fixes: #43
+
+commit 21324989b7e121c008a2c4fdf98547541cbf7b83
+Author: Martin Dørum 
+Date:   Sun May 19 16:05:08 2019 +0200
+
+Handle EINTR from recvmsg in _xcb_in_read
+
+I have a GTK application which occasionally crashes with an "interrupted
+system call" g_message from gdk. After a lot of debugging, I've found
+that the call to recvmsg in _xcb_in_read occasionally fails with EINTR,
+and instead of retrying the system call, xcb would just shut down the
+connection.
+
+This change makes _xcb_in_read treat EINTR the same as it would treat
+EAGAIN; it returns 1 and libX11 ends up calling xcb_poll_for_event
+again (from what I have understood).
+
+I have spoken with a few people who think recvmsg failing with EINTR in
+this case shouldn't ever happen, and I don't know enough to agree or
+disagree with that. In case anyone wants to dig further and try to
+figure out why the recvmsg call sometimes fails with EINTR, here's the
+backtrace from inside of _xcb_in_read where that happened:
+
+Thread 1 "beanbar" hit Breakpoint 1, _xcb_in_read 
(c=c@entry=0x55ecbe4aba80) at xcb_in.c:1059
+1059fprintf(stderr, "Hello World am %s:%i, errno is %s\n", 
__FILE__, __LINE__, strerror(errno));
+(gdb) bt
+0  0x7fa48fa48639 in _xcb_in_read (c=c@entry=0x55ecbe4aba80) at 
xcb_in.c:1059
+1  0x7fa48fa489d8 in poll_for_next_event (c=0x55ecbe4aba80, 
queued=queued@entry=0) at xcb_in.c:352
+2  0x7fa48fa48a3d in poll_for_next_event (queued=0, c=) 
at xcb_in.c:722
+3  0x7fa48fa48a3d in xcb_poll_for_event (c=) at 
xcb_in.c:722
+4  0x7fa4908d1b7e in poll_for_event (dpy=dpy@entry=0x55ecbe4a9730, 
queued_only=queued_only@entry=0) at xcb_io.c:245
+5  0x7fa4908d1cf0 in poll_for_response (dpy=dpy@entry=0x55ecbe4a9730) 
at xcb_io.c:303
+6  0x7fa4908d1fed in _XEventsQueued (mode=2, dpy=0x55ecbe4a9730) at 
xcb_io.c:363
+7  0x7fa4908d1fed in _XEventsQueued (dpy=dpy@entry=0x55ecbe4a9730, 
mode=mode@entry=2) at xcb_io.c:344
+8  0x7fa4908c3d47 in XPending (dpy=0x55ecbe4a9730) at Pending.c:55
+9  0x7fa493cadbc7 in  () at /usr/lib/libgdk-3.so.0
+10 0x7fa49234d08a in g_main_context_prepare () at 
/usr/lib/libglib-2.0.so.0
+11 0x7fa49234d6e6 in  () at /usr/lib/libglib-2.0.so.0
+12 0x7fa49234d8ae in g_main_context_iteration () at 
/usr/lib/libglib-2.0.so.0
+13 0x7fa4938b920e in g_application_run () at /usr/lib/libgio-2.0.so.0
+14 0x55ecbc820af4 in main (argc=1, argv=0x7ffd06238098) at 
src/main.c:190
+
+Signed-off-by: Martin Dørum 
+
+commit 656c08c5429a3cf53e7abd7fc56cd3c3a79c0f64
+Author: Jon Turney 
+Date:   Sun Sep 14 00:05:27 2014 +0100
+
+Include time.h before using time()
+
+Signed-off-by: Jon Turney 
+
+commit be1745c8eb00defcb31d336ccc142de056e92bd8
+Author: Alan Coopersmith 
+Date:   Sun Feb 17 12:06:10 2019 -0800
+
+Add README.md to EXTRA_DIST
+
+Signed-off-by: Alan Coopersmith 
+
+commit 58f37377c851960cbf21fac1caf38ab

Re: tar confused error messages

2020-03-22 Thread Marc Espie
On Sun, Mar 22, 2020 at 01:09:17PM +0100, Denis Fondras wrote:
> On Sun, Mar 22, 2020 at 11:41:55AM +0100, Marc Espie wrote:
> > If tar can't create intermediate directories due to permission
> > issues, the resulting message is confusing:
> > 
> > ./tar xf gcc.tar gcc-8.3.0/include/obstack.h 
> > tar: Unable to create gcc-8.3.0/include/obstack.h: No such file or directory
> > 
> > (here I have gcc-8.3.0 owned by root and no permissions)
> > 
> > The following patch changes this to:
> > 
> > ./tar xf gcc.tar gcc-8.3.0/include/obstack.h 
> > tar: Unable to create gcc-8.3.0/include: Permission denied
> > tar: Unable to create gcc-8.3.0/include/obstack.h: No such file or directory
> > 
> 
> Why not use errno on line 106 of file_subs.c ?
> That would yield "Permission denied" on obstack.h and would avoid having 2 
> error
> messages.

... except that the error is not on obstack.h, but on a specific directory 
creation.



Re: tar confused error messages

2020-03-22 Thread Andrew Grillet
I would prefer that the name of the directory that cannot be created is
given in the error message. If you are going to
resolve the problem, "permission denied" is of no help at all.

"Creating directory 'path/to/problem' - permission denied" makes it trivial
to fix.


On Sun, 22 Mar 2020 at 12:22, Denis Fondras  wrote:

> On Sun, Mar 22, 2020 at 11:41:55AM +0100, Marc Espie wrote:
> > If tar can't create intermediate directories due to permission
> > issues, the resulting message is confusing:
> >
> > ./tar xf gcc.tar gcc-8.3.0/include/obstack.h
> > tar: Unable to create gcc-8.3.0/include/obstack.h: No such file or
> directory
> >
> > (here I have gcc-8.3.0 owned by root and no permissions)
> >
> > The following patch changes this to:
> >
> > ./tar xf gcc.tar gcc-8.3.0/include/obstack.h
> > tar: Unable to create gcc-8.3.0/include: Permission denied
> > tar: Unable to create gcc-8.3.0/include/obstack.h: No such file or
> directory
> >
>
> Why not use errno on line 106 of file_subs.c ?
> That would yield "Permission denied" on obstack.h and would avoid having 2
> error
> messages.
>
> > okay ? or a better way to do this ?
> >
> > Index: extern.h
> > ===
> > RCS file: /cvs/src/bin/pax/extern.h,v
> > retrieving revision 1.59
> > diff -u -p -r1.59 extern.h
> > --- extern.h  13 Sep 2018 12:33:43 -  1.59
> > +++ extern.h  22 Mar 2020 10:39:53 -
> > @@ -128,7 +128,7 @@ int cross_lnk(ARCHD *);
> >  int chk_same(ARCHD *);
> >  int node_creat(ARCHD *);
> >  int unlnk_exist(char *, int);
> > -int chk_path(char *, uid_t, gid_t);
> > +int chk_path(char *, uid_t, gid_t, int);
> >  void set_ftime(const char *, const struct timespec *,
> >  const struct timespec *, int);
> >  void fset_ftime(const char *, int, const struct timespec *,
> > Index: file_subs.c
> > ===
> > RCS file: /cvs/src/bin/pax/file_subs.c,v
> > retrieving revision 1.54
> > diff -u -p -r1.54 file_subs.c
> > --- file_subs.c   28 Jun 2019 13:34:59 -  1.54
> > +++ file_subs.c   22 Mar 2020 10:39:53 -
> > @@ -102,7 +102,7 @@ file_creat(ARCHD *arcn)
> >   file_mode)) >= 0)
> >   break;
> >   oerrno = errno;
> > - if (nodirs ||
> chk_path(arcn->name,arcn->sb.st_uid,arcn->sb.st_gid) < 0) {
> > + if (nodirs ||
> chk_path(arcn->name,arcn->sb.st_uid,arcn->sb.st_gid, 0) < 0) {
> >   syswarn(1, oerrno, "Unable to create %s",
> arcn->name);
> >   return(-1);
> >   }
> > @@ -316,7 +316,7 @@ mk_link(char *to, struct stat *to_sb, ch
> >   if (linkat(AT_FDCWD, to, AT_FDCWD, from, 0) == 0)
> >   break;
> >   oerrno = errno;
> > - if (!nodirs && chk_path(from, to_sb->st_uid,
> to_sb->st_gid) == 0)
> > + if (!nodirs && chk_path(from, to_sb->st_uid,
> to_sb->st_gid, ign) == 0)
> >   continue;
> >   if (!ign) {
> >   syswarn(1, oerrno, "Could not link to %s from %s",
> to,
> > @@ -458,7 +458,7 @@ badlink:
> >   if (++pass <= 1)
> >   continue;
> >
> > - if (nodirs || chk_path(nm,arcn->sb.st_uid,arcn->sb.st_gid)
> < 0) {
> > + if (nodirs || chk_path(nm,arcn->sb.st_uid,arcn->sb.st_gid,
> 0) < 0) {
> >   syswarn(1, oerrno, "Could not create: %s", nm);
> >   return(-1);
> >   }
> > @@ -590,7 +590,7 @@ unlnk_exist(char *name, int type)
> >   */
> >
> >  int
> > -chk_path(char *name, uid_t st_uid, gid_t st_gid)
> > +chk_path(char *name, uid_t st_uid, gid_t st_gid, int ign)
> >  {
> >   char *spt = name;
> >   char *next;
> > @@ -643,6 +643,8 @@ chk_path(char *name, uid_t st_uid, gid_t
> >* needed directory and continue on
> >*/
> >   if (mkdir(name, S_IRWXU | S_IRWXG | S_IRWXO) == -1) {
> > + if (!ign)
> > + syswarn(1, errno, "Unable to create %s",
> name);
> >   *spt = '/';
> >   retval = -1;
> >   break;
> >
>
>


Re: tar confused error messages

2020-03-22 Thread Denis Fondras
On Sun, Mar 22, 2020 at 11:41:55AM +0100, Marc Espie wrote:
> If tar can't create intermediate directories due to permission
> issues, the resulting message is confusing:
> 
> ./tar xf gcc.tar gcc-8.3.0/include/obstack.h 
> tar: Unable to create gcc-8.3.0/include/obstack.h: No such file or directory
> 
> (here I have gcc-8.3.0 owned by root and no permissions)
> 
> The following patch changes this to:
> 
> ./tar xf gcc.tar gcc-8.3.0/include/obstack.h 
> tar: Unable to create gcc-8.3.0/include: Permission denied
> tar: Unable to create gcc-8.3.0/include/obstack.h: No such file or directory
> 

Why not use errno on line 106 of file_subs.c ?
That would yield "Permission denied" on obstack.h and would avoid having 2 error
messages.

> okay ? or a better way to do this ?
> 
> Index: extern.h
> ===
> RCS file: /cvs/src/bin/pax/extern.h,v
> retrieving revision 1.59
> diff -u -p -r1.59 extern.h
> --- extern.h  13 Sep 2018 12:33:43 -  1.59
> +++ extern.h  22 Mar 2020 10:39:53 -
> @@ -128,7 +128,7 @@ int cross_lnk(ARCHD *);
>  int chk_same(ARCHD *);
>  int node_creat(ARCHD *);
>  int unlnk_exist(char *, int);
> -int chk_path(char *, uid_t, gid_t);
> +int chk_path(char *, uid_t, gid_t, int);
>  void set_ftime(const char *, const struct timespec *,
>  const struct timespec *, int);
>  void fset_ftime(const char *, int, const struct timespec *,
> Index: file_subs.c
> ===
> RCS file: /cvs/src/bin/pax/file_subs.c,v
> retrieving revision 1.54
> diff -u -p -r1.54 file_subs.c
> --- file_subs.c   28 Jun 2019 13:34:59 -  1.54
> +++ file_subs.c   22 Mar 2020 10:39:53 -
> @@ -102,7 +102,7 @@ file_creat(ARCHD *arcn)
>   file_mode)) >= 0)
>   break;
>   oerrno = errno;
> - if (nodirs || 
> chk_path(arcn->name,arcn->sb.st_uid,arcn->sb.st_gid) < 0) {
> + if (nodirs || 
> chk_path(arcn->name,arcn->sb.st_uid,arcn->sb.st_gid, 0) < 0) {
>   syswarn(1, oerrno, "Unable to create %s", arcn->name);
>   return(-1);
>   }
> @@ -316,7 +316,7 @@ mk_link(char *to, struct stat *to_sb, ch
>   if (linkat(AT_FDCWD, to, AT_FDCWD, from, 0) == 0)
>   break;
>   oerrno = errno;
> - if (!nodirs && chk_path(from, to_sb->st_uid, to_sb->st_gid) == 
> 0)
> + if (!nodirs && chk_path(from, to_sb->st_uid, to_sb->st_gid, 
> ign) == 0)
>   continue;
>   if (!ign) {
>   syswarn(1, oerrno, "Could not link to %s from %s", to,
> @@ -458,7 +458,7 @@ badlink:
>   if (++pass <= 1)
>   continue;
>  
> - if (nodirs || chk_path(nm,arcn->sb.st_uid,arcn->sb.st_gid) < 0) 
> {
> + if (nodirs || chk_path(nm,arcn->sb.st_uid,arcn->sb.st_gid, 0) < 
> 0) {
>   syswarn(1, oerrno, "Could not create: %s", nm);
>   return(-1);
>   }
> @@ -590,7 +590,7 @@ unlnk_exist(char *name, int type)
>   */
>  
>  int
> -chk_path(char *name, uid_t st_uid, gid_t st_gid)
> +chk_path(char *name, uid_t st_uid, gid_t st_gid, int ign)
>  {
>   char *spt = name;
>   char *next;
> @@ -643,6 +643,8 @@ chk_path(char *name, uid_t st_uid, gid_t
>* needed directory and continue on
>*/
>   if (mkdir(name, S_IRWXU | S_IRWXG | S_IRWXO) == -1) {
> + if (!ign)
> + syswarn(1, errno, "Unable to create %s", name); 
>   *spt = '/';
>   retval = -1;
>   break;
> 



tar confused error messages

2020-03-22 Thread Marc Espie
If tar can't create intermediate directories due to permission
issues, the resulting message is confusing:

./tar xf gcc.tar gcc-8.3.0/include/obstack.h 
tar: Unable to create gcc-8.3.0/include/obstack.h: No such file or directory

(here I have gcc-8.3.0 owned by root and no permissions)

The following patch changes this to:

./tar xf gcc.tar gcc-8.3.0/include/obstack.h 
tar: Unable to create gcc-8.3.0/include: Permission denied
tar: Unable to create gcc-8.3.0/include/obstack.h: No such file or directory

okay ? or a better way to do this ?

Index: extern.h
===
RCS file: /cvs/src/bin/pax/extern.h,v
retrieving revision 1.59
diff -u -p -r1.59 extern.h
--- extern.h13 Sep 2018 12:33:43 -  1.59
+++ extern.h22 Mar 2020 10:39:53 -
@@ -128,7 +128,7 @@ int cross_lnk(ARCHD *);
 int chk_same(ARCHD *);
 int node_creat(ARCHD *);
 int unlnk_exist(char *, int);
-int chk_path(char *, uid_t, gid_t);
+int chk_path(char *, uid_t, gid_t, int);
 void set_ftime(const char *, const struct timespec *,
 const struct timespec *, int);
 void fset_ftime(const char *, int, const struct timespec *,
Index: file_subs.c
===
RCS file: /cvs/src/bin/pax/file_subs.c,v
retrieving revision 1.54
diff -u -p -r1.54 file_subs.c
--- file_subs.c 28 Jun 2019 13:34:59 -  1.54
+++ file_subs.c 22 Mar 2020 10:39:53 -
@@ -102,7 +102,7 @@ file_creat(ARCHD *arcn)
file_mode)) >= 0)
break;
oerrno = errno;
-   if (nodirs || 
chk_path(arcn->name,arcn->sb.st_uid,arcn->sb.st_gid) < 0) {
+   if (nodirs || 
chk_path(arcn->name,arcn->sb.st_uid,arcn->sb.st_gid, 0) < 0) {
syswarn(1, oerrno, "Unable to create %s", arcn->name);
return(-1);
}
@@ -316,7 +316,7 @@ mk_link(char *to, struct stat *to_sb, ch
if (linkat(AT_FDCWD, to, AT_FDCWD, from, 0) == 0)
break;
oerrno = errno;
-   if (!nodirs && chk_path(from, to_sb->st_uid, to_sb->st_gid) == 
0)
+   if (!nodirs && chk_path(from, to_sb->st_uid, to_sb->st_gid, 
ign) == 0)
continue;
if (!ign) {
syswarn(1, oerrno, "Could not link to %s from %s", to,
@@ -458,7 +458,7 @@ badlink:
if (++pass <= 1)
continue;
 
-   if (nodirs || chk_path(nm,arcn->sb.st_uid,arcn->sb.st_gid) < 0) 
{
+   if (nodirs || chk_path(nm,arcn->sb.st_uid,arcn->sb.st_gid, 0) < 
0) {
syswarn(1, oerrno, "Could not create: %s", nm);
return(-1);
}
@@ -590,7 +590,7 @@ unlnk_exist(char *name, int type)
  */
 
 int
-chk_path(char *name, uid_t st_uid, gid_t st_gid)
+chk_path(char *name, uid_t st_uid, gid_t st_gid, int ign)
 {
char *spt = name;
char *next;
@@ -643,6 +643,8 @@ chk_path(char *name, uid_t st_uid, gid_t
 * needed directory and continue on
 */
if (mkdir(name, S_IRWXU | S_IRWXG | S_IRWXO) == -1) {
+   if (!ign)
+   syswarn(1, errno, "Unable to create %s", name); 
*spt = '/';
retval = -1;
break;



Re: Fix tsleep(9) during execve(2)

2020-03-22 Thread Claudio Jeker
On Sun, Mar 22, 2020 at 04:58:47AM +, Visa Hankala wrote:
> The recent change of initializing sls_sig = 0 in sleep_setup()
> (r1.164 of kern_synch.c) has introduced a regression with execve(2).
> execve(2) sets the current process in single thread mode for replacing
> the program image. In this mode, sleep_setup_signal() cancels a sleep,
> making tsleep(9) with PCATCH return immediately. Previously, when
> sls_sig was initialized with value 1, tsleep() with PCATCH returned
> EINTR during exec. Now it returns zero.
> 
> The previous behaviour was not exactly right but did not seem to cause
> apparent harm. The current situation is different. For example, the
> call chain shown below can hang. The sleep does not actually happen so
> vwaitforio() can spin because the pending I/O does not get finished.
> 
> tsleep
> vwaitforio
> nfs_flush
> nfs_close
> VOP_CLOSE
> vn_closefile
> fdrop
> closef
> fdcloseexec
> sys_execve
> 
> The hang was reported and offending commit located by Pavel Korovin.
> 
> I think the proper way to fix the problem is to tighten the conditions
> when sleep_setup_signal() cancels the sleep. Instead of checking
> p->p_p->ps_single != NULL, which affects the whole process, the thread
> should determine if P_SUSPSINGLE is set in p->p_flag. This limits the
> cancelling to the threads that have been suspended for single thread
> mode. The thread that runs execve(2) does not have the flag set.
> 
> OK?

OK claudio@. The P_SUSPSINGLE check is also used in userret to enter
single_thread_check() so this makes this code behave the same way.
 
> Index: kern/kern_synch.c
> ===
> RCS file: src/sys/kern/kern_synch.c,v
> retrieving revision 1.166
> diff -u -p -r1.166 kern_synch.c
> --- kern/kern_synch.c 20 Mar 2020 17:13:51 -  1.166
> +++ kern/kern_synch.c 22 Mar 2020 04:25:32 -
> @@ -480,7 +480,7 @@ sleep_setup_signal(struct sleep_state *s
>* stopped, p->p_wchan will be 0 upon return from CURSIG.
>*/
>   atomic_setbits_int(&p->p_flag, P_SINTR);
> - if (p->p_p->ps_single != NULL || (sls->sls_sig = CURSIG(p)) != 0) {
> + if ((p->p_flag & P_SUSPSINGLE) || (sls->sls_sig = CURSIG(p)) != 0) {
>   unsleep(p);
>   p->p_stat = SONPROC;
>   sls->sls_do_sleep = 0;
> 

-- 
:wq Claudio