Re: Cygwin making files inaccessible?
Hi... I have seen similar problems on my side, but could not knock them down 100% reproducable to get a good recipe for debugging it. I got this best reproduceable if I generate a tar on linux with eg a windows .exe inside. and than untar it on cygwin. Afterwards ACLs were broken. Not every time but frequently. When using windows Explorer I got a message like "Permissions are not sorted in the correct way" (in german) when I tried to see permissions. And afterwards they have been quite strange and files where not accessable / executable. I have it with 3.x up to 3.3.4. Roland "Cygwin" wrote on 07.02.2022 08:01:33: > From: "Andrey Repin" > To: "Jay K" , cygwin@cygwin.com > Date: 07.02.2022 08:05 > Subject: Re: Cygwin making files inaccessible? > Sent by: "Cygwin" > > Greetings, Jay K! > > > I looked at this a while. I tried various recent cygwin1.dlls as > there were two ACL changes recently. > > I tried building cygwin1.dll with those changes reverted, but > failed to build it. > > For one thing it took me a while to find shilka..it is in cocom, > but that wasn't the entire problem. > > > Eventually.. I noticed the behavior was not the same for every > > file/directory/volume. Sometimes it worked ok. > > Though I think the ACLs still get changed quite a bit: "full" > expands to "many". > > Of course it has worked plenty for me and everyone else. > > > Eventually I tried chmod -R 777 * and this seems to have worked. > > > I speculate that some "bad" Cygwin ACLs got created at some point. > > And maybe cacls wasn't deleting them?? That parts seems wierd. > Maybe on directories? > > Possibly due to those two recent changes, or maybe user error, I don't know. > > This may happen outside Cygwin tree, when initial ACL's are set in some > interesting way. > One possible solution is to tweak /cygdrive mount point to include "noacl" > flag, deferring all ACL modifications to Windows. > > (Please bottom post in this list. Thank you.) > > > > From: Jay K > > Sent: Saturday, February 5, 2022 12:16 PM > > To: cygwin@cygwin.com > > Subject: Cygwin making files inaccessible? > > > > Cygwin making files inaccessible? > > i.e. when Cygwin copies or writes to them, not random files. > > > C:\t>dir /s/b/a > > > C:\t>dir /q . > > > 02/05/2022 04:11 AM BUILTIN\Administrators . > > 02/05/2022 04:11 AM NT SERVICE\TrustedInsta.. > > > C:\t>cacls . > > C:\t Everyone:(OI)(CI)F > > > C:\t>echo > 1.txt > > > C:\t>cacls 1.txt > > C:\t\1.txt Everyone:F > > > C:\t>copy 1.txt 2.txt > > 1 file(s) copied. > > > C:\t>cacls 2.txt > > C:\t\2.txt Everyone:F > > > C:\t>del 2.txt > > > C:\t>uname -a > > CYGWIN_NT-10.0-WOW DESKTOP-BCFUMJ4 3.3.4(0.341/5/3) 2022-01-31 19: > 31 i686 Cygwin > > > C:\t>cp 1.txt 2.txt > > > C:\t>which cp > > /usr/bin/cp > > > C:\t>cacls 2.txt > > C:\t\2.txt NULL SID:(DENY)(special access:) > > READ_CONTROL > > > DESKTOP-BCFUMJ4\jay:(DENY)(special access:) > > FILE_READ_DATA > > FILE_READ_EA > > FILE_EXECUTE > > > DESKTOP-BCFUMJ4\jay:(special access:) > > STANDARD_RIGHTS_ALL > > DELETE > > READ_CONTROL > > WRITE_DAC > > WRITE_OWNER > > SYNCHRONIZE > > STANDARD_RIGHTS_REQUIRED > > FILE_READ_ATTRIBUTES > > FILE_WRITE_ATTRIBUTES > > > DESKTOP-BCFUMJ4\None:R > > Everyone:R > > > > C:\t>more 1.txt > > ECHO is on. > > > C:\t>more 2.txt > > Cannot access file C:\t\2.txt > > > Same behavior from cygwin64. > > > C:\t>\cygwin64\bin\uname -a > > CYGWIN_NT-10.0 DESKTOP-BCFUMJ4 3.3.3(0.341/5/3) 2021-12-03 16:35 > x86_64 Cygwin > > > Huh? > > > I would hope Cygwin could/would just copy the ACLs asis. > > I am guessing there is some failed attempt to translate them > > to an internal form and then back to NT form. > > > My real scenario was open/write/read, not cp.exe. > > > - Jay > > > > -- > With best regards, > Andrey Repin > Monday, February 7, 2022 9:59:12 > > Sorry for my terrible english... > > -- > Problem reports: https://cygwin.com/problems.html > FAQ: https://cygwin.com/faq/ > Documentation:https://cygwin.com/docs.html > Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple > -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin making files inaccessible?
Greetings, Jay K! > I looked at this a while. I tried various recent cygwin1.dlls as there were > two ACL changes recently. > I tried building cygwin1.dll with those changes reverted, but failed to build > it. > For one thing it took me a while to find shilka..it is in cocom, but that > wasn't the entire problem. > Eventually.. I noticed the behavior was not the same for every > file/directory/volume. Sometimes it worked ok. > Though I think the ACLs still get changed quite a bit: "full" expands to > "many". > Of course it has worked plenty for me and everyone else. > Eventually I tried chmod -R 777 * and this seems to have worked. > I speculate that some "bad" Cygwin ACLs got created at some point. > And maybe cacls wasn't deleting them?? That parts seems wierd. Maybe on > directories? > Possibly due to those two recent changes, or maybe user error, I don't know. This may happen outside Cygwin tree, when initial ACL's are set in some interesting way. One possible solution is to tweak /cygdrive mount point to include "noacl" flag, deferring all ACL modifications to Windows. (Please bottom post in this list. Thank you.) > From: Jay K > Sent: Saturday, February 5, 2022 12:16 PM > To: cygwin@cygwin.com > Subject: Cygwin making files inaccessible? > > Cygwin making files inaccessible? > i.e. when Cygwin copies or writes to them, not random files. > C:\t>dir /s/b/a > C:\t>dir /q . > 02/05/2022 04:11 AM BUILTIN\Administrators . > 02/05/2022 04:11 AM NT SERVICE\TrustedInsta.. > C:\t>cacls . > C:\t Everyone:(OI)(CI)F > C:\t>echo > 1.txt > C:\t>cacls 1.txt > C:\t\1.txt Everyone:F > C:\t>copy 1.txt 2.txt > 1 file(s) copied. > C:\t>cacls 2.txt > C:\t\2.txt Everyone:F > C:\t>del 2.txt > C:\t>uname -a > CYGWIN_NT-10.0-WOW DESKTOP-BCFUMJ4 3.3.4(0.341/5/3) 2022-01-31 19:31 i686 > Cygwin > C:\t>cp 1.txt 2.txt > C:\t>which cp > /usr/bin/cp > C:\t>cacls 2.txt > C:\t\2.txt NULL SID:(DENY)(special access:) > READ_CONTROL > DESKTOP-BCFUMJ4\jay:(DENY)(special access:) > FILE_READ_DATA > FILE_READ_EA > FILE_EXECUTE > DESKTOP-BCFUMJ4\jay:(special access:) > STANDARD_RIGHTS_ALL > DELETE > READ_CONTROL > WRITE_DAC > WRITE_OWNER > SYNCHRONIZE > STANDARD_RIGHTS_REQUIRED > FILE_READ_ATTRIBUTES > FILE_WRITE_ATTRIBUTES > DESKTOP-BCFUMJ4\None:R > Everyone:R > C:\t>more 1.txt > ECHO is on. > C:\t>more 2.txt > Cannot access file C:\t\2.txt > Same behavior from cygwin64. > C:\t>\cygwin64\bin\uname -a > CYGWIN_NT-10.0 DESKTOP-BCFUMJ4 3.3.3(0.341/5/3) 2021-12-03 16:35 x86_64 Cygwin > Huh? > I would hope Cygwin could/would just copy the ACLs asis. > I am guessing there is some failed attempt to translate them > to an internal form and then back to NT form. > My real scenario was open/write/read, not cp.exe. > - Jay -- With best regards, Andrey Repin Monday, February 7, 2022 9:59:12 Sorry for my terrible english... -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: Cygwin making files inaccessible?
I looked at this a while. I tried various recent cygwin1.dlls as there were two ACL changes recently. I tried building cygwin1.dll with those changes reverted, but failed to build it. For one thing it took me a while to find shilka..it is in cocom, but that wasn't the entire problem. Eventually.. I noticed the behavior was not the same for every file/directory/volume. Sometimes it worked ok. Though I think the ACLs still get changed quite a bit: "full" expands to "many". Of course it has worked plenty for me and everyone else. Eventually I tried chmod -R 777 * and this seems to have worked. I speculate that some "bad" Cygwin ACLs got created at some point. And maybe cacls wasn't deleting them?? That parts seems wierd. Maybe on directories? Possibly due to those two recent changes, or maybe user error, I don't know. - Jay From: Jay K Sent: Saturday, February 5, 2022 12:16 PM To: cygwin@cygwin.com Subject: Cygwin making files inaccessible? Cygwin making files inaccessible? i.e. when Cygwin copies or writes to them, not random files. C:\t>dir /s/b/a C:\t>dir /q . 02/05/2022 04:11 AM BUILTIN\Administrators . 02/05/2022 04:11 AM NT SERVICE\TrustedInsta.. C:\t>cacls . C:\t Everyone:(OI)(CI)F C:\t>echo > 1.txt C:\t>cacls 1.txt C:\t\1.txt Everyone:F C:\t>copy 1.txt 2.txt 1 file(s) copied. C:\t>cacls 2.txt C:\t\2.txt Everyone:F C:\t>del 2.txt C:\t>uname -a CYGWIN_NT-10.0-WOW DESKTOP-BCFUMJ4 3.3.4(0.341/5/3) 2022-01-31 19:31 i686 Cygwin C:\t>cp 1.txt 2.txt C:\t>which cp /usr/bin/cp C:\t>cacls 2.txt C:\t\2.txt NULL SID:(DENY)(special access:) READ_CONTROL DESKTOP-BCFUMJ4\jay:(DENY)(special access:) FILE_READ_DATA FILE_READ_EA FILE_EXECUTE DESKTOP-BCFUMJ4\jay:(special access:) STANDARD_RIGHTS_ALL DELETE READ_CONTROL WRITE_DAC WRITE_OWNER SYNCHRONIZE STANDARD_RIGHTS_REQUIRED FILE_READ_ATTRIBUTES FILE_WRITE_ATTRIBUTES DESKTOP-BCFUMJ4\None:R Everyone:R C:\t>more 1.txt ECHO is on. C:\t>more 2.txt Cannot access file C:\t\2.txt Same behavior from cygwin64. C:\t>\cygwin64\bin\uname -a CYGWIN_NT-10.0 DESKTOP-BCFUMJ4 3.3.3(0.341/5/3) 2021-12-03 16:35 x86_64 Cygwin Huh? I would hope Cygwin could/would just copy the ACLs asis. I am guessing there is some failed attempt to translate them to an internal form and then back to NT form. My real scenario was open/write/read, not cp.exe. - Jay -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
RE: python-cryptography >= 3.4.0 and Rust
> -Original Message- > From: Cygwin-apps > On Behalf Of Marco Atzeri > Sent: Friday, February 4, 2022 4:28 PM > To: cygwin-apps@cygwin.com > Subject: Re: python-cryptography >= 3.4.0 and Rust > > On 04.02.2022 16:28, Allen Hewes wrote: > >> -Original Message- > > >>> > >>> Welp, then the wheels came off. I am assuming that Cygwin's python- > >> cryptography is still at 3.3.2 b/c of this Rust issue? > >>> > >> > >> Hi Allen, > >> it is correct. I released the last version that was still on C > >> > > > > It's still on C but the authors have been adding new features in Rust. They > are using the Python Rust API bridge for the integration between the two. > > > > It seems not an optional feature, without a Rust compiler it can not be built > Or perhaps the build process could be changed to exclude the Rust bits? I don't know if this possible or not or what it would mean to exclude them. Just thinking out loud. > >>> Rust is making more in-roads into software I use frequently or like > >>> to use. Is > >> there any efforts or discussions about getting Rust able to target Cygwin? > >> > >> Not that I aware of. > >> We have already problem to update clang that is already behind. > >> > > > > Many of the shiny new sysadmin/sysutils are written in Rust or Go. > > > > The reason why I brought up python cryptography and Cygwin is that the > current version of python cryptography doesn't support OpenSSL 3 (AFAIK). > Only the most recent cryptography does. At some point in the future, this > will have to be addressed, wouldn't it (IMHO)? Python cryptography is > fundamental in the Python ecosystem. Pythonistas who use Cygwin will > need an update to cryptography. How can this happen? > >"Somebody Has To Do It" https://cygwin.com/acronyms/#SHTDI > > but I do not volounteer ... > No suggestion to you or others to work on it was intended. I was asking more rhetorically to start a conversation about what the effort might look like b/c maybe I could contribute. If the only acceptable effort for Cygwin is to port Rust, I can't contribute in a meaningful way. But if there are other ideas (even crazy ones), I might be able to contribute. > >> Rust and Go are purely wish, they both requires specific expertize and > time. > >> > > > > ...except for then those languages make in-roads into the bits/ecosystem > that Cygwin has packaged/supported (for a long time in some cases). From > what I can tell, these ecosystems think WSL/WSL2 is their "best effort" for > Linux-y (or POSIX) on Windows. > > > >> Feel free to work on it > > > > Based on the conversation in rigrep (a Rust grepper), it sounds like it's a > large amount of work that would not be accepted/entertained by upstream: > > https://github.com/BurntSushi/ripgrep/issues/269 > > in the old past we had some discussion on cmake but finally upstream > accepted our efforts. > Did Cygwin maintain their own set of patchsets for cmake? If so, for how long and for how many version upgrades (until upstream accepted them)? /allen Disclaimer Confidentiality Notice: This e-mail, and any attachments and/or documents linked to this email, are intended for the addressee and may contain information that is privileged, confidential, proprietary, or otherwise protected by law. Any dissemination, distribution, or copying is prohibited. This notice serves as a confidentiality marking for the purpose of any confidentiality or nondisclosure agreement. If you have received this communication in error, please contact the original sender.
[ANNOUNCEMENT] lcms2 2.13-1
The following packages have been uploaded to the Cygwin distribution: * lcms2-2.13-1 * liblcms2_2-2.13-1 * liblcms2-devel-2.13-1 Little CMS intends to be an Open Source small-footprint color management engine, with special focus on accuracy and performance. It uses the International Color Consortium standard (ICC), which is the modern standard regarding color management. The ICC specification is widely used and is referred to in many International and other de-facto standards. This is an update to the latest upstream release. See https://littlecms.com/blog/2022/01/28/lcms2-2.13/ for a list of changes since the previous release. Ken Brown Cygwin's lcms2 maintainer -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
lcms2 2.13-1
The following packages have been uploaded to the Cygwin distribution: * lcms2-2.13-1 * liblcms2_2-2.13-1 * liblcms2-devel-2.13-1 Little CMS intends to be an Open Source small-footprint color management engine, with special focus on accuracy and performance. It uses the International Color Consortium standard (ICC), which is the modern standard regarding color management. The ICC specification is widely used and is referred to in many International and other de-facto standards. This is an update to the latest upstream release. See https://littlecms.com/blog/2022/01/28/lcms2-2.13/ for a list of changes since the previous release. Ken Brown Cygwin's lcms2 maintainer
[ANNOUNCEMENT] Updated: man-db-2.10.0-1
The man-db package is updated to the latest upstream version 2.10.0. Man-db is an implementation of the standard Unix documentation system accessed using the man command. It uses a Berkeley DB database in place of the traditional flat-text whatis databases. This release includes a performance enhancement that significantly speeds up the creation of the database. Cygwin Notes The man-db package includes a conditional perpetual postinstall script that keeps the database updated each time setup is run if (and only if) the database exists. This update now runs in the background by default, so setup is no longer waiting for the update to complete. This can be changed if needed, see below. The diagnostic output from the update is stored at /var/log/mandb-index.log, so you can check if there were problems on the last update. This release works around a Windows bug that causes creation of a spurious directory %SystemDrive% in the Cygwin installation root. In order to create the database directly via setup, please install the man-db-create-index package. The removal of this package will not remove an existing database, this still needs to be done manually if required. If your installation procedure requires that setup waits for the index update to complete, install the man-db-index-synchronously package instead. The creation of a new database can take several minutes to over an hour depending on how many manual pages are installed and how fast your filesystem is. Removal of this package will leave an existing database in place, but switches the system back to do background updates. If you install "everything" that means both the above mentioned helper packages get installed and the first installation will take a long time as setup will wait for the newly created index to be complete. -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Updated: man-db-2.10.0-1
The man-db package is updated to the latest upstream version 2.10.0. Man-db is an implementation of the standard Unix documentation system accessed using the man command. It uses a Berkeley DB database in place of the traditional flat-text whatis databases. This release includes a performance enhancement that significantly speeds up the creation of the database. Cygwin Notes The man-db package includes a conditional perpetual postinstall script that keeps the database updated each time setup is run if (and only if) the database exists. This update now runs in the background by default, so setup is no longer waiting for the update to complete. This can be changed if needed, see below. The diagnostic output from the update is stored at /var/log/mandb-index.log, so you can check if there were problems on the last update. This release works around a Windows bug that causes creation of a spurious directory %SystemDrive% in the Cygwin installation root. In order to create the database directly via setup, please install the man-db-create-index package. The removal of this package will not remove an existing database, this still needs to be done manually if required. If your installation procedure requires that setup waits for the index update to complete, install the man-db-index-synchronously package instead. The creation of a new database can take several minutes to over an hour depending on how many manual pages are installed and how fast your filesystem is. Removal of this package will leave an existing database in place, but switches the system back to do background updates. If you install "everything" that means both the above mentioned helper packages get installed and the first installation will take a long time as setup will wait for the newly created index to be complete. -- *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL.
Running mypy on .py file with known problems in Cygwin term produces no output. Running same command on same file in DOS window produces expected output.
I have attached cygcheck.out. Following are some details, to
elaborate upon the subject line.
Contents of the file junk_ano.py:
# begin code listing
def greeting(name: str) -> str:
return 'Hello ' + name
if __name__ == "__main__":
greeting('Bob', 'Eve')
greeting(3)
greeting(b'Alice')
# end code listing
Output when running in a DOS (cmd) window is what I expected:
C:\bjk\tmp>mypy junk_ano.py
junk_ano.py:5: error: Too many arguments for "greeting"
junk_ano.py:6: error: Argument 1 to "greeting" has incompatible type
"int"; expected "str"
junk_ano.py:7: error: Argument 1 to "greeting" has incompatible type
"bytes"; expected "str"
Found 3 errors in 1 file (checked 1 source file)
When I run the same command on the same file in a Cygwin terminal
window, there is no output. (Same lack of results if I use the -v or
--strict flags.) There is a noticeable span of time (~0.5 sec) before
the next command prompt appears, so it seems to me like something is
being run in response to the command.
On a probably related note, running in DOS window causes creation of a
directory named .mypy_cache. No such directory is created when running
in a Cygwin terminal.
Anyone got any ideas? Thanks in advance.
P.S. Running on Win10, Python 3.9.6 as downloaded from python.org (for
Windows). Version of mypy: 0.931, obtained via python -m pip install
mypy.
cygcheck.out
Description: Binary data
--
Problem reports: https://cygwin.com/problems.html
FAQ: https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: python-numpy (1.22.0-1) can't be imported
On Sat, Jan 22 2022, Masamichi Hosoda wrote: >> It is something like that, but "-Wl,--export-all-symbols" >> is not used on 1.21.4 and is not needed for most of the other >> modules on 1.22.x >> >> so I am looking for a less extreme action. >> Also to understand how it can impact other python subpackages > > If I understand correctly, I've found the root cause of the issue. > I've sent a pull request to numpy. > https://github.com/numpy/numpy/pull/20874 Based on that pull request, it looks like it's related to the patches used to avoid python C-extension modules with only one exported function mentioned a year ago: https://cygwin.com/pipermail/cygwin/2021-January/247211.html https://cygwin.com/pipermail/cygwin/2021-January/247216.html >From a glance at the Python C API docs, it looks like Python C extension modules are supposed to have only one exported function: https://docs.python.org/3/extending/extending.html#the-module-s-method-table-and-initialization-function https://docs.python.org/3/extending/extending.html#providing-a-c-api-for-an-extension-module The NumPy CFFI tests seem to want to use a few C extension modules as normal shared libraries, which requires that the functions the tests want to use to be exported from the DLL, but this seems to be a somewhat unusual case. I tend to compile my own versions of Cython (without patches), which may have been picked up when I compiled the new version of NumPy. -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: makedepend does not honor UNC path for -I and -Y
On 02/02/2022 17:02, Ronald Hoogenboom wrote: cygwin makedepend collapses the double-slash UNC path prefix to one single slash. It fails to find headers via such search paths. Cygwin 3.2.0-1 on windows server 2012 R2 makedepend 1.0.6 Thanks for reporting this. I suspect that this is an upstream bug in makedepend, in that it does some canonicalization on paths, and assumes that '//' is the same as '/' everywhere in a path, which isn't true for an initial '//' (but happens to work on Linux, etc.) See SUSv4 Base specifications, section 4.13 "Pathname Resolution" ([1], registration required): "If a pathname begins with two successive characters, the first component following the leading characters may be interpreted in an implementation-defined manner, although more than two leading characters shall be treated as a single character." Unfortunately, you're probably going to have to fix this yourself, if it's causing you problems. Fortunately, makedepend is relatively small (See [2]). [1] https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap04.html#tag_04_13 [2] https://gitlab.freedesktop.org/xorg/util/makedepend -- Problem reports: https://cygwin.com/problems.html FAQ: https://cygwin.com/faq/ Documentation:https://cygwin.com/docs.html Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple
Re: setup-*.exe --help default explanation re -D/-L options [Was: [ANNOUNCEMENT] Updated: setup (2.917)]
On 01/02/2022 21:46, Adam Dinwoodie wrote: On Tue, Feb 01, 2022 at 04:53:47PM +, Jon Turney wrote: [...] Note that I tweaked the behaviour of this a bit in [1] [1] https://cygwin.com/git/?p=cygwin-apps/setup.git;a=commit;h=147fc15d0222e050779b18a209991c258d85944f I think that makes the current help text accurately describe non-interactive mode. There are some cases in interactive mode which are obscure (e.g. '-M' without '-D' or '-L' gets you whatever mode you used last time without showing you what it was, but I'm not sure if that needs to be here. Ah, okay. I think I hit this with `-M` and assumed -- evidently incorrectly -- that the same behaviour would exist for `-q`. I agree the current text is entirely accurate for the fully non-interactive mode. [...]> I definitely see no harm in that approach, and I agreed that'd make things clearer again. But, as above, I think the key thing from my perspective would be for `-M` and `-q` to have consistent behaviour. Yes, on reflection, I think that change isn't quite right, and '-M' should be handled the same as '-q' there (i.e. '-D' & '-L' is the default, unless explicitly specified otherwise)
Re: CI Jobs Not Being Submitted to Github Actions
On 06/02/2022 08:45, Marco Atzeri wrote: On 06.02.2022 00:46, Brian Inglis wrote: https://cygwin.com/cgi-bin2/jobs.cgi or is it just me? ;^> As far as I can tell, the REST API request to start the workflow succeeded, but no workflow run started. This looks like something transient which happened inside github (their status page shows an incident at around that time) sometime happens, I saw same on job 3740 I guess the platform has some glitch, maybe for update or load, and forgot the pending jobs This case is different, in that the workflow ran to completion, but when the 'completed' webhook fired, trying to fetch the build metadata artefact failed 404 (which seems to happen occasionally) (which means we can't find the associated job to update the status of to reflect that). In both cases, the solution is probably to make scallywag an asynchronous process, rather than a daisy-chain of hooks, so it can retry these things if they don't go to plan. Probably not happening this week, though :)
Re: Go or Rust Packages?
Achim Gratz writes: > Pulling out this and another stop successfully configures and actually > builds a gccgo executable sometime later. If any of this actually works > remains to be seen. The compiler itself seems to be working (for some definition of working), but the compilation of libgo fails at some point: --8<---cut here---start->8--- make[4]: Entering directory '/mnt/share/packages/gcc/gcc.x86_64/build/x86_64-pc-cygwin/libgo' /usr/bin/mkdir -p os/signal/internal; files=`echo | sed -e 's/[^ ]*\.gox//g' -e 's/[^ ]*\.dep//'`; /bin/sh ./libtool --tag GO --mode=compile /mnt/share/packages/gcc/gcc.x86_64/build/./gcc/gccgo -B/mnt/share/packages/gcc/gcc.x86_64/build/./gcc/ -B/usr/x86_64-pc-cygwin/bin/ -B/usr/x86_64-pc-cygwin/lib/ -isystem /usr/x86_64-pc-cygwin/include -isystem /usr/x86_64-pc-cygwin/sys-include -fchecking=1 -minline-all-stringops -O2 -g -I . -c -fgo-pkgpath=`echo os/signal/internal/pty.lo | sed -e 's/.lo$//'` -o os/signal/internal/pty.lo $files libtool: compile: /mnt/share/packages/gcc/gcc.x86_64/build/./gcc/gccgo -B/mnt/share/packages/gcc/gcc.x86_64/build/./gcc/ -B/usr/x86_64-pc-cygwin/bin/ -B/usr/x86_64-pc-cygwin/lib/ -isystem /usr/x86_64-pc-cygwin/include -isystem /usr/x86_64-pc-cygwin/sys-include -fchecking=1 -minline-all-stringops -O2 -g -I . -c -fgo-pkgpath=os/signal/internal/pty -DDLL_EXPORT -o os/signal/internal/.libs/pty.o gccgo: fatal error: no input files compilation terminated. make[4]: *** [Makefile:3001: os/signal/internal/pty.lo] Error 1 --8<---cut here---end--->8--- Since this is in the os subtree my guess is that this happens due to the non-recognition of Cygwin somewhere else. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: CI Jobs Not Being Submitted to Github Actions
On 06.02.2022 00:46, Brian Inglis wrote: https://cygwin.com/cgi-bin2/jobs.cgi or is it just me? ;^> sometime happens, I saw same on job 3740 I guess the platform has some glitch, maybe for update or load, and forgot the pending jobs Regards Marco
