Re: Native symlinks and setup.exe

2016-10-03 Thread Gene Pavlovsky 
That makes sense but it would be a LOT of work for many people (well,
a lot of small work for many people).

How about this kind of modification for the setup program: extract tar
archives into temp dir, after that search that temp dir for symlinks,
if they don't match the current winsymlinks option, recreate them
appropriately?

I just remembered what I did when I first discovered the winsymlinks
option (already having a 32-bit Cygwin set up for a couple of years).
I tarred my entire cygwin directory, copied it over to my Linux
server, untarred it there - which created all the symlinks, including
Cygwin's symlinks, as proper symlinks, then tarred it back, copied
back to the Windows box, untarred - voila, all symlinks are created as
native. I wonder how are Cygwin vs native symlinks stored inside tar
archive - tar knows they are symlinks but also knows which ones are
native vs Cygwin's. That's a whole lot of bother, though, and now that
I know that some further package update down the line might replace
native links with Cygwin links again (didn't expect that), I wouldn't
be willing to go to that trouble.

It should work out of the box automatically, in my opinion. Cygwin
symlinks are a kluge (e.g. I can't edit them in Far manager, the way I
can adjust a native symlink), and if using Cygwin exclusively on NTFS
filesystems, supporting symlinks, I can't see any reason to have any
on my system. The proposed solution is sensible, but it spreads
responsibility among all the package maintainers, and it will take a
long time to reach.

On 3 October 2016 at 15:08, Thorsten Kampe  wrote:
> * Gene Pavlovsky (Mon, 3 Oct 2016 00:46:54 +0300)
>>
>> So, when installing, the type of symlinks doesn't honor the CYGWIN
>> option since they are just unpacked by tar as is.
>>
>> The question I'm proposing now - should `tar` be modified to honor the
>> CYGWIN option and automatically convert symlinks when extracting, if
>> necessary?
>
> Tar's task is to unpack what's in the archive. So converting is out
> of question. You can ask the maintainer of the affected packages to
> create the symlinks in the postinstall script.
>
> Thorsten
>
>
> --
> Problem reports:   http://cygwin.com/problems.html
> FAQ:   http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple
>

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

Re: [ANNOUNCEMENT] Updated: svn_load_dirs-1.9.2-2

2016-10-03 Thread David Stacey 

On 02/10/16 19:46, David Rothenberger wrote:

CYGWIN CHANGES:
===
Fix compatibility with svn 1.9 as described

   https://cygwin.com/ml/cygwin/2016-09/msg00205.html

Thanks to David Stacey for the information.


Much appreciated; thank you.

Dave.


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

Re: Native symlinks and setup.exe

2016-10-03 Thread Thorsten Kampe 
* Gene Pavlovsky (Mon, 3 Oct 2016 00:46:54 +0300)
> 
> So, when installing, the type of symlinks doesn't honor the CYGWIN
> option since they are just unpacked by tar as is.
> 
> The question I'm proposing now - should `tar` be modified to honor the
> CYGWIN option and automatically convert symlinks when extracting, if
> necessary?

Tar's task is to unpack what's in the archive. So converting is out 
of question. You can ask the maintainer of the affected packages to 
create the symlinks in the postinstall script.

Thorsten


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

[ITP] Perl distributions

2016-10-03 Thread Achim Gratz 

perl-Archive-Extract (as requested by D. Stacey)
perl-ExtUtilsHelpers (an indirect build dependency of perl-Readonly)

I also would like to get co-maintainership for

perl-MIME-tools
perl-MailTools

which are behind their latest releases and currently maintained by
Yaakov.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf microQ V2.22R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: Advice for debugging heap mismatches? (Win10 Insider build 14926)

2016-10-03 Thread Tim Prince 

On 10/3/2016 2:39 AM, Mark Geisert wrote:

Tony Kelman wrote:




I see what you've been saying about different insider builds of Windows
10 but I don't think anybody here is beating up on these releases.

Win10 anniversary with a single cygwin64 installation is sufficiently 
difficult for me.  Unscheduled Microsoft update reboots, inability to 
bootstrap gcc (where it works on win8.1)...


--
Tim Prince

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

Re: Advice for debugging heap mismatches? (Win10 Insider build 14926)

2016-10-03 Thread Tony Kelman 
> No, that looks like I'd expect it to.  You need to look at the process
> map when you have fork problems, since the problem seems to be
> intermittent.

How so? Something like

for i in `seq 1000`; do
  cat /proc/self/maps > procselfmaps_`date +%s.%N`.txt;
done &

before running the problematic command? It does take a variable amount
of time to trigger, and sometimes exhibits as a complete freeze instead
of an error. What should I be looking for here?

> Have you tried to play around with the virus scanner settings?

I already have a Windows Defender exclusion for my Cygwin installs.
Turning off real-time protection temporarily didn't help.


> One sure-fire way to make sure your 32-bit E: installation is not causing 
> havoc
> with your 64-bit C: installation is to temporarily rename E:\cygwin32 to
> E:\somethingelse and retry your build.  This should not be necessary but I 
> don't
> know what else to suggest.

Good idea. Tried it, didn't help.

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

Re: Advice for debugging heap mismatches? (Win10 Insider build 14926)

2016-10-03 Thread Mark Geisert 

Tony Kelman wrote:

You've got two different cygwin1.dll somewhere on your PATH.


For more information, I have one cygwin64 installation on C:, one
cygwin32 installation on E:, and they're never both on my path at
the same time. I'm not sure where that orphan registry entry that was
showing up in cygcheck.out came from, but I removed it and it made no
difference.


With only one Cygwin installation on C: I can only come up with wild guesses. 
Are you somehow alternating between the C: and E: Cygwin versions, or running 
them simultaneously from separate windows, or accidentally running 32-bit Cygwin 
commands from a 64-bit Cygwin terminal window?  Unusual stuff like that?


One sure-fire way to make sure your 32-bit E: installation is not causing havoc 
with your 64-bit C: installation is to temporarily rename E:\cygwin32 to 
E:\somethingelse and retry your build.  This should not be necessary but I don't 
know what else to suggest.


I have in the past run 32-bit and 64-bit Cygwin installations simultaneously on 
the same machine, in order to build 32-bit and 64-bit Cygwin DLLs at the same 
time.  Never had a problem.  But that was Windows 7 so probably not applicable.



This is absolutely due to a change in Windows itself. 3 updates in
a row now, 14926, 14931, and now 14936, it's 100% reproducible just
from updating Windows. Downgrading to build 14915 gets everything back
working again, but that build is now expired so the only way for me to
get back to a supported build of Windows where cygwin works properly
is by totally reinstalling Windows. I haven't done that yet, but if
we can't identify the problem and a solution soon, I will have to.


I see what you've been saying about different insider builds of Windows 10 but I 
don't think anybody here is beating up on these releases.


..mark

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

Re: Advice for debugging heap mismatches? (Win10 Insider build 14926)

2016-10-03 Thread Achim Gratz 
Tony Kelman writes:
>> Something occupies the heap area for Cygwin, based on the low address.
>> What does /proc/self/maps tell you?
>
> $ cat /proc/self/maps
[…]
>
> Hopefully you know what you're looking at there. Anything meaningful in that?

No, that looks like I'd expect it to.  You need to look at the process
map when you have fork problems, since the problem seems to be
intermittent.  Have you tried to play around with the virus scanner
settings?


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

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