Mailing List Archive

"Christian Walde" <walde.christian@gmail.com> wrote:
:On Fri, 02 Oct 2020 19:30:54 +0200, Todd Rinaldo <toddr@cpanel.net> wrote:
[...]
:> Given how unstable it is, I think it is worth considering that we stop smoking cygwin as part of our github CI runs.
:
:We also found that this is down to something with the github VMs, not cygwin, as cygwin tests are perfectly reliable on various machines where it runs on the iron.
:
:And i gave you a PR to convert the first of these flaps into a consistent TODO failure: https://github.com/Perl/perl5/pull/18149 that was not found to have issues by various people.
:
:And i'm happy to make more of them.
:
:So imo switching cygwin testing off is a huge mistake that buys a little convenience in exchange for longterm damage.
:
:Let me actually fix this stuff instead of warnocking me and switching Cygwin off.

Well I think the current situation is dangerous: I'm being trained to ignore
CI failures, because every push I make results in a failure email.

For now I'm still trying to scan those to verify that cygwin is the only
failure (though the formatting makes that harder to do than it should be).
I've already stopped bothering to actually go check the Cygwin failures
though. It won't be long before I stop bothering to scan the email.

I think there would be value in turning it off until we have managed to
merge patches for the known issues: it is actively deleterious in the
current state.

Hugo

On Fri, 02 Oct 2020 19:30:54 +0200, Todd Rinaldo <toddr@cpanel.net> wrote:

> All,
>
> Not for the first time, I've opened a ticket about flapping tests on cygwin for our CI smokers.
>
> https://github.com/Perl/perl5/issues/18193
>
> On review of past commits that had CI runs, I determined that the 2 tests listed, while frequent, aren't the only >flapping tests. Additionally, cygwin smoker runs are the slowest platform of all of our CI runs.
>
> Just in the past month, we've spent a significant amount of time investigating failures, only to determine that the >problem is "maybe" in cygwin itself and not something we can fix.
>
> Given how unstable it is, I think it is worth considering that we stop smoking cygwin as part of our github CI runs. I >just don't see evidence that we're finding blockers for merge on this platform and if they exist, they're mostly >hidden by the large amount of noise we're seeing from this platform.
>
> This doesn't stop us from running and reporting to our other infrastructure. I'm only proposing that the noise >makes it not worth doing for CI. Does anyone think it is worth (their time) chasing down and addressing all of these >failures so we can have stable CI runs again or should we just remove the cygwin CI runs for now on?
>
> Thanks,
> Todd

We also found that this is down to something with the github VMs, not cygwin, as cygwin tests are perfectly reliable on various machines where it runs on the iron.

And i gave you a PR to convert the first of these flaps into a consistent TODO failure: https://github.com/Perl/perl5/pull/18149 that was not found to have issues by various people.

And i'm happy to make more of them.

So imo switching cygwin testing off is a huge mistake that buys a little convenience in exchange for longterm damage.

Let me actually fix this stuff instead of warnocking me and switching Cygwin off.

--
With regards,
Christian Walde

On Sat, 03 Oct 2020 13:27:07 +0200, <hv@crypt.org> wrote:

> "Christian Walde" <walde.christian@gmail.com> wrote:
> :On Fri, 02 Oct 2020 19:30:54 +0200, Todd Rinaldo <toddr@cpanel.net> wrote:
> [...]
> :> Given how unstable it is, I think it is worth considering that we stop smoking cygwin as part of our github CI runs.
> :
> :We also found that this is down to something with the github VMs, not cygwin, as cygwin tests are perfectly reliable on various machines where it runs on the iron.
> :
> :And i gave you a PR to convert the first of these flaps into a consistent TODO failure: https://github.com/Perl/perl5/pull/18149 that was not found to have issues by various people.
> :
> :And i'm happy to make more of them.
> :
> :So imo switching cygwin testing off is a huge mistake that buys a little convenience in exchange for longterm damage.
> :
> :Let me actually fix this stuff instead of warnocking me and switching Cygwin off.
>
> Well I think the current situation is dangerous: I'm being trained to ignore
> CI failures, because every push I make results in a failure email.
>
> For now I'm still trying to scan those to verify that cygwin is the only
> failure (though the formatting makes that harder to do than it should be).
> I've already stopped bothering to actually go check the Cygwin failures
> though. It won't be long before I stop bothering to scan the email.
>
> I think there would be value in turning it off until we have managed to
> merge patches for the known issues: it is actively deleterious in the
> current state.
>
> Hugo

I suggest reviewing and barring any issues, signing off on the pull request for the first flap: https://github.com/Perl/perl5/pull/18149

--
With regards,
Christian Walde

On Sat, 03 Oct 2020 14:22:36 +0200, Christian Walde <walde.christian@gmail.com> wrote:

> On Sat, 03 Oct 2020 13:27:07 +0200, <hv@crypt.org> wrote:
>
>> "Christian Walde" <walde.christian@gmail.com> wrote:
>> :On Fri, 02 Oct 2020 19:30:54 +0200, Todd Rinaldo <toddr@cpanel.net> wrote:
>> [...]
>> :> Given how unstable it is, I think it is worth considering that we stop smoking cygwin as part of our github CI runs.
>> :
>> :We also found that this is down to something with the github VMs, not cygwin, as cygwin tests are perfectly reliable on various machines where it runs on the iron.
>> :
>> :And i gave you a PR to convert the first of these flaps into a consistent TODO failure: https://github.com/Perl/perl5/pull/18149 that was not found to have issues by various people.
>> :
>> :And i'm happy to make more of them.
>> :
>> :So imo switching cygwin testing off is a huge mistake that buys a little convenience in exchange for longterm damage.
>> :
>> :Let me actually fix this stuff instead of warnocking me and switching Cygwin off.
>>
>> Well I think the current situation is dangerous: I'm being trained to ignore
>> CI failures, because every push I make results in a failure email.
>>
>> For now I'm still trying to scan those to verify that cygwin is the only
>> failure (though the formatting makes that harder to do than it should be).
>> I've already stopped bothering to actually go check the Cygwin failures
>> though. It won't be long before I stop bothering to scan the email.
>>
>> I think there would be value in turning it off until we have managed to
>> merge patches for the known issues: it is actively deleterious in the
>> current state.
>>
>> Hugo
>
> I suggest reviewing and barring any issues, signing off on the pull request for the first flap: https://github.com/Perl/perl5/pull/18149

To be more clear:

The other danger is that whatever followup pull requests are made will be warnocked forever and cygwin never be turned back on.

Are you willing to pledge yourself to keep this from happening?

--
With regards,
Christian Walde

"Christian Walde" <walde.christian@gmail.com> wrote:
:> I suggest reviewing and barring any issues, signing off on the pull request for the first flap: https://github.com/Perl/perl5/pull/18149

I've responded with concerns there.

:To be more clear:
:
:The other danger is that whatever followup pull requests are made will be warnocked forever and cygwin never be turned back on.
:
:Are you willing to pledge yourself to keep this from happening?

No, or only insofar as I accept it as a responsibility of the community
as a whole. I do my best to review PRs where I have some expertise, but
my availability and enthusiasm are limited resources that I try to use
wisely.

This is a volunteer project (mostly), and warnocking is always a risk
especially in areas where expertise is thin on the ground; it is rare
that that's "forever" though.

While I see value in having Cygwin as part of our CI pipeline, I do not
see it as vital. If the github VMs really are so different from real Cygwin
installations, that value is already much diminished (and the more so
if we do get regular smoke reports from real installations).

I think it would make a lot of sense to add Cygwin-specific TODOs to any
test that is failing there without signalling an actual problem with perl
*first*. If we can't do that simply, quickly and uncontroversially, we
should probably turn off the Cygwin CI until we can.

Hugo

On Sat, 03 Oct 2020 15:11:16 +0200, <hv@crypt.org> wrote:

> "Christian Walde" <walde.christian@gmail.com> wrote:
> :> I suggest reviewing and barring any issues, signing off on the pull request for the first flap: https://github.com/Perl/perl5/pull/18149
>
> I've responded with concerns there.

Cheers. :D

> :To be more clear:
> :
> :The other danger is that whatever followup pull requests are made will be warnocked forever and cygwin never be turned back on.
> :
> :Are you willing to pledge yourself to keep this from happening?
>
> No, or only insofar as I accept it as a responsibility of the community
> as a whole. I do my best to review PRs where I have some expertise, but
> my availability and enthusiasm are limited resources that I try to use
> wisely.
>
> This is a volunteer project (mostly), and warnocking is always a risk
> especially in areas where expertise is thin on the ground; it is rare
> that that's "forever" though.
>
> While I see value in having Cygwin as part of our CI pipeline, I do not
> see it as vital. If the github VMs really are so different from real Cygwin
> installations, that value is already much diminished (and the more so
> if we do get regular smoke reports from real installations).

It's not wildly different. So far it appears mostly that some threading-related things are iffy.

I don't know and can't currently check if we have any regular other smokers for that.

That said, some people have indicated they don't even look at anything but the github smokers, and the apparent lack of widespread concern about perl5.smoke-test.org being down leads to some pessimism and motivation for me to keep the github cygwin smoker up.

> I think it would make a lot of sense to add Cygwin-specific TODOs to any
> test that is failing there without signalling an actual problem with perl
> *first*. If we can't do that simply, quickly and uncontroversially, we
> should probably turn off the Cygwin CI until we can.

That's my intent and i'm happy to do the work, but given my lack of commit bit, without someone willing to help me do it, switching it off forever and switching it off "until fixed" are, i fear, identical.

--
With regards,
Christian Walde

On 10/3/20 8:25 AM, Christian Walde wrote:
>
>> I think it would make a lot of sense to add Cygwin-specific TODOs to any
>> test that is failing there without signalling an actual problem with perl
>> *first*. If we can't do that simply, quickly and uncontroversially, we
>> should probably turn off the Cygwin CI until we can.
>
> That's my intent and i'm happy to do the work, but given my lack of
> commit bit, without someone willing to help me do it, switching it off
> forever and switching it off "until fixed" are, i fear, identical.

I agree with this, and am willing to use my commit bit to help make it
happen.

On Sat, 03 Oct 2020 17:55:01 +0200, Karl Williamson <public@khwilliamson.com> wrote:

> On 10/3/20 8:25 AM, Christian Walde wrote:
>>
>>> I think it would make a lot of sense to add Cygwin-specific TODOs to any
>>> test that is failing there without signalling an actual problem with perl
>>> *first*. If we can't do that simply, quickly and uncontroversially, we
>>> should probably turn off the Cygwin CI until we can.
>>
>> That's my intent and i'm happy to do the work, but given my lack of
>> commit bit, without someone willing to help me do it, switching it off
>> forever and switching it off "until fixed" are, i fear, identical.
>
> I agree with this, and am willing to use my commit bit to help make it
> happen.

Thank you very much, i am very happy. :)

For a first step, looking at the PR i linked earlier would be good; and otherwise i'll see about having more TODOs wrapped around the other flaps i can see tomorrow.

--
With regards,
Christian Walde

On Sat, 3 Oct 2020, Christian Walde wrote:

> On Sat, 03 Oct 2020 15:11:16 +0200, <hv@crypt.org> wrote:
>
>> While I see value in having Cygwin as part of our CI pipeline, I do not
>> see it as vital. If the github VMs really are so different from real Cygwin
>> installations, that value is already much diminished (and the more so
>> if we do get regular smoke reports from real installations).
>
> It's not wildly different. So far it appears mostly that some
> threading-related things are iffy.
>
> I don't know and can't currently check if we have any regular other smokers
> for that.

I didn't think we needed any more Cygwin smokers but if it is useful I can
set one up on my Windows 10 notebook. Cygwin on Windows 2000 isn't
feasible. :)

> That said, some people have indicated they don't even look at anything but
> the github smokers, and the apparent lack of widespread concern about
> perl5.smoke-test.org being down leads to some pessimism and motivation for me
> to keep the github cygwin smoker up.

A thorough '-fsanitize=address' smoke run takes 5 days. Ain't nobody got
time for that to be a PR requirement, but works well as an after-the-fact
report.

There's some kind of intermittant failure in "../cpan/File-Path/t/Path.t"
on that configuration, in fact.


--
George Greer

On Sat, 03 Oct 2020 23:46:53 +0200, George Greer <perl@greerga.m-l.org> wrote:

> On Sat, 3 Oct 2020, Christian Walde wrote:
>
>> On Sat, 03 Oct 2020 15:11:16 +0200, <hv@crypt.org> wrote:
>>
>>> While I see value in having Cygwin as part of our CI pipeline, I do not
>>> see it as vital. If the github VMs really are so different from real Cygwin
>>> installations, that value is already much diminished (and the more so
>>> if we do get regular smoke reports from real installations).
>>
>> It's not wildly different. So far it appears mostly that some
>> threading-related things are iffy.
>>
>> I don't know and can't currently check if we have any regular other smokers
>> for that.
>
> I didn't think we needed any more Cygwin smokers but if it is useful I can
> set one up on my Windows 10 notebook. Cygwin on Windows 2000 isn't
> feasible. :)

If it's not too much of a bother that would be nice. Cygwin Perl is used quite a bit, and having more configurations to compare would be useful.

>> That said, some people have indicated they don't even look at anything but
>> the github smokers, and the apparent lack of widespread concern about
>> perl5.smoke-test.org being down leads to some pessimism and motivation for me
>> to keep the github cygwin smoker up.
>
> A thorough '-fsanitize=address' smoke run takes 5 days. Ain't nobody got
> time for that to be a PR requirement, but works well as an after-the-fact
> report.
>
> There's some kind of intermittant failure in "../cpan/File-Path/t/Path.t"
> on that configuration, in fact.

If it's that slow that's probably a timing issue i'm confident i'll be able to suss out eventually. Honestly not sure how that relates to the text you quoted from me. :)

--
With regards,
Christian Walde

On Fri, 02 Oct 2020 19:30:54 +0200, Todd Rinaldo <toddr@cpanel.net> wrote:

> Not for the first time, I've opened a ticket about flapping tests on cygwin for our CI smokers.
>
> https://github.com/Perl/perl5/issues/18193
>
> On review of past commits that had CI runs, I determined that the 2 tests listed, while frequent, aren't the only >flapping tests.

Reviewing that, the op/stat.t failure is not a flap, but a solid break, that happened between

Sep 24, 2020, 3:46 AM GMT+2 PASS 8f2cc613dd93c942f8161f52e47a4178c20e9f2e skip the failing dynamic vs static tests on Win32 https://github.com/Perl/perl5/actions/runs/269786053

and

Sep 24, 2020, 5:15 PM GMT+2 FAIL 98d7b5aeaad3d320d621e1a7888505217c33ef21 Update Unicode-Collate to CPAN version 1.28 https://github.com/Perl/perl5/actions/runs/270824893

From the delta between those i can't see anything that should affect op/stat.t, so that's likely something that changed on github's side, which the test was too fragile for. I'm investigating.

--
With regards,
Christian Walde

[Cygwin Perl maintainer here]

hv@crypt.org writes:
> For now I'm still trying to scan those to verify that cygwin is the only
> failure (though the formatting makes that harder to do than it should be).
> I've already stopped bothering to actually go check the Cygwin failures
> though. It won't be long before I stop bothering to scan the email.

If you are taking about Perl itself, there are only three tests expected
to fail, provided you run with administrative privileges. Two of them
test permissions that Perl can't take away from you when you're
administrator (more specifically when you have certain security
privileges). These would pass if you'd run the test via 'cygdrop -l',
but then another bunch of tests would fail because you are no longer
able to do things that these tests expect you to. There are a handful
of tests that seem to be sensititve to timing, which might be more
pronounced when moving to a VM setup that uses unknown scheduling
properties. I know that some alarm and timer tests sometimes fail, but
then work when you run them again.


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

Todd Rinaldo writes:
> On review of past commits that had CI runs, I determined that the 2
> tests listed, while frequent, aren't the only flapping
> tests.

File/stat and op/stat make assumptions about how permissions work that
aren't valid on Windows or more generally any system that has MAC
enabled.

As already noted in the ticket, some of the API (SHM in particular)
require you to run cygserver.

> Additionally, cygwin smoker runs are the slowest platform of
> all of our CI runs.

That's unfortunately expected, given that fork is very expensive on Cygwin.

> Just in the past month, we've spent a significant amount of time
> investigating failures, only to determine that the problem is "maybe"
> in cygwin itself and not something we can fix.

If that's the case it'd really help if you came with a reproducible
recipe to the Cygwin mailing list (or P5P). If you let it sit on Github
I can't even look at it for the most part since they insist that I'd
need to be signed in. Sorry, not going to happen.

> Given how unstable it is, I think it is worth considering that we stop
> smoking cygwin as part of our github CI runs. I just don't see
> evidence that we're finding blockers for merge on this platform and if
> they exist, they're mostly hidden by the large amount of noise we're
> seeing from this platform.

Maybe you'd start with getting the Cygwin patches integrated and if you
don't build with cygport get the necessary touch-ups integrated in your
build procedure? You won't have much luck with running the tests on
32bit if you didn't do an ephemeral rebase before starting them for
instance.

https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/perl.git;a=tree

If you'd rather want them in Git, I can either send you formatted
patches or push to a Git repo you can pull them from.

I build and test on full iron, so if there's noise from virtualization I
currently don't see it. However Cygwin now runs package builds on
AppVeyor, the last build of Perl did produce this:

https://ci.appveyor.com/project/cygwin/scallywag/builds/33366077

The two extra fails are most likely permissions problems again that
happen on certain (network) file system configurations. I don't have
these when testing locally. You can also see that we update Cygwin from
the default VM image before starting the build (but do not set up
cygserver, which we might add eventually). It isn't that difficult to
set things up correctly, but if you just cargo-cult some of the
Chocolatey nonsense that's floating around you'll most likely end up
with something that isn't quite the way you need it for Perl.


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

First off, thanks for getting involved, much appreciated, really.

> File/stat and op/stat make assumptions about how permissions work that
> aren't valid on Windows or more generally any system that has MAC
> enabled.

Those aren't actually an issue on the github cygwin smoke runs. For whatever reasons all the permissions-related tests run fine.

> If that's the case it'd really help if you came with a reproducible
> recipe to the Cygwin mailing list (or P5P). If you let it sit on Github
> I can't even look at it for the most part since they insist that I'd
> need to be signed in. Sorry, not going to happen.

There are three issues here:

1. The specific issue pointed out upthread in t/op/stat.t was only assumed to be a flap by OP and, as is obvious from the smoke logs, actually a hard failure. As xenu pointed out on IRC, it stems from a change in github's windows vm image, which also affects completely different projects.

(example: https://github.com/actions/virtual-environments/issues/1679 )

I had already seen it and was intending to investigate upon having the next thing merged, but didn't get around to it as the following thing was left to languish.

2. There is a stronger flap on the cygwin vm caused by alarm not firing correctly while a long regex operation is running. In a ticket that had not been given the time of the day until yesterday i provided a test that converted (via fairly basic perl means) that flap into a full fail on github cygwin.

You can view the diff here. (without needing to be logged in)

https://github.com/Perl/perl5/commit/d6049bebb5f7286958c894606abb2df210f104a3

You will also be able to see it in blead now, thanks to Karl.

3. There are further flaps that i've seen, and was intending to look at, in:

t/re/pat_thr.t
t/op/threads.t
t/op/alarm.t

Which have a ... fairly obvious common theme, and feel relevant to the flap from point 2.

> Maybe you'd start with getting the Cygwin patches integrated and if you
> don't build with cygport get the necessary touch-ups integrated in your
> build procedure? You won't have much luck with running the tests on
> 32bit if you didn't do an ephemeral rebase before starting them for
> instance.
>
> https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/perl.git;a=tree
>
> If you'd rather want them in Git, I can either send you formatted
> patches or push to a Git repo you can pull them from.

I'd be happy to work on that with you. Are you available to chat on any other platform? Maybe give me a list of preferred ones with contact details and i'll meet up with you.

As for the patches, in that repo they're without context and explanation, so maybe it would indeed be best if you convert them into commits with full messages that can be applied to the Perl repo. Happy to work with you on that.

And now that we have Karl Williamson and George Greer's attention, integration will hopefully happen in reasonable timeframes.

> I build and test on full iron, so if there's noise from virtualization I
> currently don't see it. However Cygwin now runs package builds on
> AppVeyor, the last build of Perl did produce this:
>
> https://ci.appveyor.com/project/cygwin/scallywag/builds/33366077
>
> The two extra fails are most likely permissions problems again that
> happen on certain (network) file system configurations. I don't have
> these when testing locally. You can also see that we update Cygwin from
> the default VM image before starting the build (but do not set up
> cygserver, which we might add eventually). It isn't that difficult to
> set things up correctly, but if you just cargo-cult some of the
> Chocolatey nonsense that's floating around you'll most likely end up
> with something that isn't quite the way you need it for Perl.

That link appears to be only the test output, can you link to your actual appveyor configuration?

Meanwhile, the current github script for testing on cygwin can be viewed here. (again, requiring no login)

https://github.com/Perl/perl5/blob/blead/.github/workflows/testsuite.yml#L364

--
With regards,
Christian Walde

"Christian Walde" writes:
>> File/stat and op/stat make assumptions about how permissions work
>> that aren't valid on Windows or more generally any system that has
>> MAC enabled.
>
> Those aren't actually an issue on the github cygwin smoke runs. For
> whatever reasons all the permissions-related tests run fine.

The Github (correctly) does not enable those security provileges, which
however will lead to some other test fails that would require them and
aren't properly guarded. The exact results to be expected depend on the
list of privileges that are still in effect.

If you run "cygdrop -v echo" you will see what privileges got
deactivated (and hence were previously available).

> 2. There is a stronger flap on the cygwin vm caused by alarm not
> firing correctly while a long regex operation is running. In a ticket
> that had not been given the time of the day until yesterday i provided
> a test that converted (via fairly basic perl means) that flap into a
> full fail on github cygwin.
>
> You can view the diff here. (without needing to be logged in)
>
> https://github.com/Perl/perl5/commit/d6049bebb5f7286958c894606abb2df210f104a3
>
> You will also be able to see it in blead now, thanks to Karl.

I might have seen that fail before, but on a much older Perl and a much
slower machine. If it's timing related then that would perhaps explain
it.

> 3. There are further flaps that i've seen, and was intending to look
> at, in:
>
> t/re/pat_thr.t t/op/threads.t t/op/alarm.t
>
> Which have a ... fairly obvious common theme, and feel relevant to the
> flap from point 2.

These were fairly common quite some time ago, but I haven't seen them in a
while. If they all depend on the same underlying issue (a signal not
delivered to the correct thread or just not at the right time) then it
may indeed be a Cygwin bug, although the current version should be much
better in that respect.

> As for the patches, in that repo they're without context and
> explanation, so maybe it would indeed be best if you convert them into
> commits with full messages that can be applied to the Perl repo. Happy
> to work with you on that.

OK, I'll put that on my TODO list. Not sure when I'll find time for
that, though. Here's a short explanation:

perl-5.30.3-cygwin_README.patch

Removes some verbiage about no longer supported Windows versions and
adds/modifies some other things that have been changed. Should actually
be updated again I think.


perl-5.30.3-cygwin-auto-image-base.patch

Forcing an image-base is a no-no, especially if it's the same for
everything.


perl-5.30.3-cygwin-Configure-libpth.patch

The original code was adding superfluous linker flags and/or picking up
the wrong libraries, I think. The patched code may or may not work on
other systems, I haven't tried.


perl-5.30.3-cygwin-Configure-libsearch.patch

I've presented this patch on this list some years ago I think. In a
nutshell, you also need to consider that import libs are a thing on
Windows for this part of configure to work correctly.


perl-5.30.3-cygwin-hints.patch

The obvious updates to support current Cygwin versions (and make sure
that things at least don't break knowingly on older ones, although I
don't test that).


perl-5.30.3-cygwin-patchlevel.patch

List the local patches in perl -V output.


perl-5.30.3-cygwin-Win32.patch

Patches what looks like a double encoding bug out of Win32 tests. I
believe I've shown that patch here before, but it hasn't received any
attention IIRC.


> That link appears to be only the test output, can you link to your
> actual appveyor configuration?

I'm not the person doing that, but I believe you'll find it here:
https://cygwin.com/git/?p=cygwin-apps/scallywag.git;a=summary

If you have questions about it, either ask on the cygwin-apps mailing
list or #cygwin-developers on Freenode.


> Meanwhile, the current github script for testing on cygwin can be
> viewed here. (again, requiring no login)
>
> https://github.com/Perl/perl5/blob/blead/.github/workflows/testsuite.yml#L364

As I suspected, cargo-culting. You'd probably be much better off if
you'd simply run setup for Cygwin directly and just specify which
packages you want on top of the base install (cyg-get does that under
the hood, from what I've seen). The way it's done now you run setup
needlessly twice and I have not been able to figure out conclusively
what arguments it'll get. You should be able to run cyg-get without
having to choco cygwin before if it wasn't for the fact that cyg-get
doesn't let you specify where to put the install.

Installing cygwin64-w32api-headers is completely useless if you haven't
also installed the cygwin64 cross-compilation toolchain, which itself is
useless on a 64bit Cygwin (which is the target for that compiler). The
native toolchain you installed never looks at those header files. You
either want w32api-headers or nothing at all. Any W32 API headers /
wrappers that Cygwin itself needs are delivered with the cygwin-devel
package.


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

On Sun, 04 Oct 2020 14:07:37 +0200, Achim Gratz <Stromeko@nexgo.de> wrote:

> "Christian Walde" writes:
>>> File/stat and op/stat make assumptions about how permissions work
>>> that aren't valid on Windows or more generally any system that has
>>> MAC enabled.
>>
>> Those aren't actually an issue on the github cygwin smoke runs. For
>> whatever reasons all the permissions-related tests run fine.
>
> The Github (correctly) does not enable those security provileges, which
> however will lead to some other test fails that would require them and
> aren't properly guarded. The exact results to be expected depend on the
> list of privileges that are still in effect.
>
> If you run "cygdrop -v echo" you will see what privileges got
> deactivated (and hence were previously available).

Whatever these issues might be, they don't seem to surface very reliably, as 3 commits since my patch was merged had no issues with cygwin: https://github.com/Perl/perl5/actions?query=workflow%3Atestsuite

Happy to investigate if you feel like describing them more clearly though. :)

> [...]

Also, thanks a lot for the massive amount of additional info. I have other priorities right now, but i intend to process it soon and maybe convert more of them into patches that get applied. :)

--
With regards,
Christian Walde

"Christian Walde" writes:
>> If you run "cygdrop -v echo" you will see what privileges got
>> deactivated (and hence were previously available).
>
> Whatever these issues might be, they don't seem to surface very
> reliably, as 3 commits since my patch was merged had no issues with
> cygwin:
> https://github.com/Perl/perl5/actions?query=workflow%3Atestsuite
>
> Happy to investigate if you feel like describing them more clearly
> though. :)

I should run the testsuite again with dropped privileges, which I
haven't done in a while. In a nutshell, some of the network and file
system tests previously required admin rights due to the way Windows
restricts the use of certain facilities. The tests may have been
reworked to either not test these or to ignore errors that are due to
unsufficient permissions.


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

SD adaptations for Waldorf Q V3.00R3 and Q+ V3.54R2:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Achim Gratz writes:
> I should run the testsuite again with dropped privileges, which I
> haven't done in a while.

So I had to do a new build since I updated gcc in the meantime… Here's
the result from the test run (on 64bit only, but I don't expect 32bit to
be different) with admin rights:

Failed 3 tests out of 2548, 99.88% okay.
../dist/Net-Ping/t/450_service.t
../lib/File/stat.t
op/stat.t

The ping test fail is suspected to be caused by the firewall settings on
this machine rather than something else. The stat tests that fail are
due to files being writable or readable that an inspection of the file
modes would declare non-readable or non-writable. I have removed all
DACL from the build directory, so this is due to the SeBackupPrivilege /
SeRestorePrivilege that the admin account has by default.

Running the checks again with almost all security privileges dropped
gets me this:

Failed 3 tests out of 2549, 99.88% okay.
../cpan/Win32/t/GetShortPathName.t
../cpan/Win32API-File/t/file.t
../dist/Net-Ping/t/450_service.t

So it runs one more test (I haven't checked which one) and fails two
tests that are not properly guarded against being run with insufficient
privileges. That's actually much better than what I've got the last
time I tried this.


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

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs