Re: chattr makes cygport slow

2023-07-06 Thread Andrew Schulman via Cygwin-apps
> Recently I noticed that `cygport finish` has become really slow on some of my
> package source trees. After I run for example
> 
> cygport libargp.cygport finish
> 
> it waits for about 5 minutes without any message to the console, before the
> first "Removing work directory" message appears.
> 
> pstree shows that during this time cygport is waiting for chattr. In
> /usr/bin/cygport I see:
> 
> if [ $OSTYPE = "cygwin" ]
> then
> chattr -fR +C ${workdir} >/dev/null 2>&1 || true
> fi
> 
> which is trying to make the workdir case-sensitive.
> 
> Whatever the advantages of that are, it can take a long time. Would it be
> possible to skip it at least in the case of "finish"? It seems silly to spend
> all that time fixing up a directory tree that we then turn around and remove
> with rm -rf.

And/or, maybe add a switch to suppress it. I've commented it out of my
/usr/bin/cygport for now, because it makes me wait an extra 5 minutes before
every cygport command, at least on this particular source tree with 12K files in
it.



Re: chattr makes cygport slow

2023-07-06 Thread Brian Inglis via Cygwin-apps

On 2023-07-06 06:19, Andrew Schulman via Cygwin-apps wrote:

Recently I noticed that `cygport finish` has become really slow on some of my
package source trees. After I run for example

cygport libargp.cygport finish

it waits for about 5 minutes without any message to the console, before the
first "Removing work directory" message appears.

pstree shows that during this time cygport is waiting for chattr. In
/usr/bin/cygport I see:

if [ $OSTYPE = "cygwin" ]
then
 chattr -fR +C ${workdir} >/dev/null 2>&1 || true
fi

which is trying to make the workdir case-sensitive.

Whatever the advantages of that are, it can take a long time. Would it be
possible to skip it at least in the case of "finish"? It seems silly to spend
all that time fixing up a directory tree that we then turn around and remove
with rm -rf.


The attribute does not appear to be inheritable, so will not be applied to 
subdirectories created by make, or in cygport xargs commands, unless supported 
in cygwin1.dll, perhaps why it is open coded in cygport?


Perhaps it could be moved below case prep, into src_prep `__mkdirs`, or globally 
define `mkdir_p()` which applies it to each directory in those paths?

Could this also be defined in MKDIR_P for make or are those limited to binaries?

All cygport scripts appear to consistently use `mkdir -p` including after `xargs 
-r` (`--no-run-if-empty`) except:


/usr/share/cygport/cygclass/fossil.cygclass:mkdir ${FOSSIL_MODULE}

--
Take care. Thanks, Brian Inglis  Calgary, Alberta, Canada

La perfection est atteinte   Perfection is achieved
non pas lorsqu'il n'y a plus rien à ajouter  not when there is no more to add
mais lorsqu'il n'y a plus rien à retirer but when there is no more to cut
-- Antoine de Saint-Exupéry


chattr makes cygport slow

2023-07-06 Thread Andrew Schulman via Cygwin-apps
Recently I noticed that `cygport finish` has become really slow on some of my
package source trees. After I run for example

cygport libargp.cygport finish

it waits for about 5 minutes without any message to the console, before the
first "Removing work directory" message appears.

pstree shows that during this time cygport is waiting for chattr. In
/usr/bin/cygport I see:

if [ $OSTYPE = "cygwin" ]
then
chattr -fR +C ${workdir} >/dev/null 2>&1 || true
fi

which is trying to make the workdir case-sensitive.

Whatever the advantages of that are, it can take a long time. Would it be
possible to skip it at least in the case of "finish"? It seems silly to spend
all that time fixing up a directory tree that we then turn around and remove
with rm -rf.

Thanks,
Andrew



Re: [ITA] ruby-gdk_pixbuf2

2023-07-06 Thread Jon Turney via Cygwin-apps

On 03/07/2023 12:55, Daisuke Fujimura via Cygwin-apps wrote:

Hello,



Cygportfile:
- https://cygwin.com/cgit/cygwin-packages/playground/tree/?h=ruby-gdk_pixbuf2

Packages, logs:
- https://github.com/cygwin/scallywag/actions/runs/5443915435


Done. Thanks!