Re: [ANNOUNCEMENT] Updated: setup (2.917)

[Samuel Lelièvre]

2022-01-31 06:43 UTC, © Fxzx mic:
>
> Marco Atzeri, 2022年1月31日 14:25:
>
> > On 31.01.2022 06:36, © Fxzx mic wrote:
> > > Hello,
> > > I want to know how to change the default value of [...]
> >
> > Hi,
> >
> > bottom posting on this mailing list, please. [...]
>
> Hello,
> Sorry, I just want to ask the author first. I don't know this rule. Sorry.

See this explanation of posting styles:

https://en.wikipedia.org/wiki/Posting_style

-- 
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: [ANNOUNCEMENT] cygwin 3.3.3-1 [with DEPRECATION NOTES]

[Corinna Vinschen]

On Jan 28 11:41, Andrey Repin wrote:
> Greetings, Corinna Vinschen!
> 
> > Hi Andrey,
> 
> > On Jan 26 19:34, Andrey Repin wrote:
> >> Greetings, Corinna Vinschen via Cygwin-announce!
> >> [...]
> >> $ /usr/bin/d2u ./Localization.lua
> >> dos2unix: Failed to change the permissions of temporary output file 
> >> ./d2utmpEBELkH: Permission denied
> >> dos2unix: problems converting file ./Localization.lua
> 
> > I could easily reproduce your problem, which I introduced myself into
> > Cygwin 3.3.2.  At the time I was wrestling with a new Samba version and
> > thought I have seen a problem with permissions.  However, I don't know
> > how to reproduce the problem because it just doesn't show up anymore.
> 
> I could arrange a debug session, if you need.

As I wrote, I could reproduce your problem easily.  What I can't
reproduce is the original problem I thought I have seen back when I
pushed the patch breaking your scenario.

> > So I just reverted the patch.  It worked this way for years.
> 
> > I also created new developer snapshots for testing.  I guess it's
> > about time for a 3.3.4 release...
> 
> Simple retry completed without an error on the snapshot Cygwin DLL.

Thanks for testing,
Corinna

-- 
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

[ANNOUNCEMENT] cygwin 3.3.4-1

[Corinna Vinschen via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* cygwin-3.3.4-1
* cygwin-devel-3.3.4-1
* cygwin-doc-3.3.4-1

==
   IMPORTANT DEPRECATION NOTES
==

- Cygwin 3.3 is the LAST major version supporting

  - Windows Vista
  - Windows Server 2008

- Cygwin 3.3 is the LAST major version supporting 32 bit installations.

  If you're using 32 bit Cygwin in WOW64 on 64 bit machines, consider
  to move to a real 64 bit Cygwin installation in the next couple of
  months.

  If you're using 32 bit Cygwin on real 32 bit hardware or on WOW64 on
  ARM64, don't be alarmed.  The current installations including all
  Cygwin 3.3.x versions will continue to run on your system.  You just
  wont get any more updates starting with Cygwin 3.4.0.

- Cygwin 3.4, which will probably be release at some point in 2022,
  will be the LAST version supporting

  - Windows 7
  - Windows Server 2008 R2
  - Windows 8
  - Windows Server 2012

There are no plans to deprecate support for 64 bit systems starting with
Windows 8.1 / Windows Server 2012 R2 any time soon.

==

Bug Fixes
-

- Fix a bug in fhandler_dev_clipboard::read() that the second read
  fails with 'Bad address'.
  Addresses: https://cygwin.com/pipermail/cygwin/2021-December/250141.html

- Convert UNC path prefix back to drive letter in symlink_info::check().
  This solves the following issues:
  Addresses: https://cygwin.com/pipermail/cygwin/2021-November/250087.html
 https://cygwin.com/pipermail/cygwin/2021-December/250103.html

- Fix a bug in pty code that input is wrongly sent to io_handle_nat
  rather than io_handle while neither read() nor select() is called
  after the cygwin app is started from non-cygwin app.
  Addresses: https://cygwin.com/pipermail/cygwin-patches/2021q4/011587.html

- Avoid a crash when NtQueryInformationProcess returns invalid handle data.
  Addresses: https://cygwin.com/pipermail/cygwin-patches/2021q4/011611.html

- Ignore INHERIT ACEs when reading the DACL of non-directory files.
  Addresses: https://cygwin.com/pipermail/cygwin/2022-January/250363.html

- Fix an "Invalid argument" problem in posix_spawn on i686.
  Addresses: https://cygwin.com/pipermail/cygwin/2022-January/250453.html

- Fix handling of  records in Cygwin resolver code using native
  windows calls.  Also fix various bugs in the resolver.

- Fix a problem creating a dir "foo", if a file (but not a Cygwin symlink)
  "foo.lnk" already exists.
  Addresses: https://github.com/msys2/msys2-runtime/issues/81

- Fix double free for archetype, which is caused when open() fails.
  Addresses: https://cygwin.com/pipermail/cygwin/2022-January/250518.html

- Fix a permission problem when writing DOS attributes on Samba.
  Addresses: https://cygwin.com/pipermail/cygwin/2022-January/250629.html


-- 
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: git/cygwin-packages package repo http URLs incorrect and fail

[Corinna Vinschen]

On Jan 31 00:55, Brian Inglis wrote:
> In the URLs shown for git/cygwin-packages repo access:
> 
> URL   git://cygwin.com/git/cygwin-packages/PKG.git
>   http://cygwin.com/git/cygwin-packages/PKG.git
>   ssh://cygwin@cygwin.com/git/cygwin-packages/PKG.git
> 
> the web URL fails and should be:
> 
>   https://cygwin.com/git/?p=git/cygwin-packages/PKG.git
> 
> as in the PKG links in the git/cygwin-packages list.
> 
> Can't find a ref in the ...htdocs... or I would submit a patch.

Apps have their own htdocs for historical reasons:
https://cygwin.com/git/cygwin-apps/htdocs.git


Thanks,
Corinna

-- 
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: [ANNOUNCEMENT] Updated: setup (2.917)

[Jon Turney]

On 31.01.2022 06:36, © Fxzx mic wrote:

Hello,
I want to know how to change the default value of the check boxes when creating 
a program shortcut after installation so that it is no longer checked by 
default.
Which part of the program needs to be changed?


[...]>

Can you please clarify with an example ?
Which shortcut do you mean ?

Maybe you should look on the Command Line options for already available
options :

$ ./setup-x86_64.exe --help
Cygwin setup 2.917

Command Line Options:

...
   -d --no-desktop   Disable creation of desktop shortcut
...


On 31/01/2022 06:43, © Fxzx mic wrote:
>
> After installing (or updating) through the GUI, the program will
> finally have two check boxes to choose whether to create shortcuts,
> and the default status of these two check boxes is checked. I just
> want to know how to cancel this default behavior. I want to know
> where this behavior is written in the setup program source code.

If you search for that option text in the source code you'll end up 
looking at:


https://cygwin.com/git/?p=cygwin-apps/setup.git;a=blob;f=desktop.cc

Note that a patch to simply reverse the default setting of that option 
(i.e. make it unset by default, and require the user to click that 
checkbox to create the shortcuts (meaning that most users will have to 
do that) would not be acceptable.


Probably what's wanted is to remember the state of those checkboxes, if 
this isn't the first time setup has been run?


--
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: git/cygwin-packages package repo http URLs incorrect and fail

[Jon Turney]

On 31/01/2022 07:55, Brian Inglis wrote:

In the URLs shown for git/cygwin-packages repo access:

URL    git://cygwin.com/git/cygwin-packages/PKG.git
 http://cygwin.com/git/cygwin-packages/PKG.git
 ssh://cygwin@cygwin.com/git/cygwin-packages/PKG.git

the web URL fails and should be:

 https://cygwin.com/git/?p=git/cygwin-packages/PKG.git

as in the PKG links in the git/cygwin-packages list.


No.  Between the URL for git access with git transport and the URL for 
git access with ssh transport, is the URL for git access with http 
transport, not the URL of the page you are looking at.



Can't find a ref in the ...htdocs... or I would submit a patch.


This URL comes from the gitweb configuration, which isn't checked into 
that repo (for no good reason, so I'll see what I can do about that...)


--
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

GitHub Action Error

[© Fxzx mic]

I am installing these packages with cygwin/cygwin-install-action@master:



cmake make gdb mingw64-x86_64-gcc-g++



on Github Action. However, the following error occurred:



Changing gid back to original

running: C:\cygwin\bin\dash.exe "/etc/postinstall/0p_000_autorebase.dash"

abnormal exit: exit code=-1073741701

running: C:\cygwin\bin\dash.exe "/etc/postinstall/0p_update-info-dir.dash"

abnormal exit: exit code=-1073741701

running: C:\cygwin\bin\bash.exe --norc --noprofile 
"/etc/postinstall/000-cygwin-post-install.sh"

abnormal exit: exit code=-1073741701

running: C:\cygwin\bin\bash.exe --norc --noprofile 
"/etc/postinstall/coreutils.sh"

abnormal exit: exit code=-1073741701

running: C:\cygwin\bin\bash.exe --norc --noprofile "/etc/postinstall/bash.sh"

abnormal exit: exit code=-1073741701

running: C:\cygwin\bin\bash.exe --norc --noprofile 
"/etc/postinstall/base-files-mketc.sh"

abnormal exit: exit code=-1073741701

running: C:\cygwin\bin\bash.exe --norc --noprofile 
"/etc/postinstall/base-files-profile.sh"

abnormal exit: exit code=-1073741701

running: C:\cygwin\bin\bash.exe --norc --noprofile "/etc/postinstall/p11-kit.sh"

abnormal exit: exit code=-1073741701

running: C:\cygwin\bin\bash.exe --norc --noprofile 
"/etc/postinstall/ca-certificates.sh"

abnormal exit: exit code=-1073741701

running: C:\cygwin\bin\bash.exe --norc --noprofile 
"/etc/postinstall/crypto-policies.sh"

abnormal exit: exit code=-1073741701

running: C:\cygwin\bin\dash.exe "/etc/postinstall/openssl.dash"

abnormal exit: exit code=-1073741701

running: C:\cygwin\bin\bash.exe --norc --noprofile "/etc/postinstall/libxml2.sh"

abnormal exit: exit code=-1073741701

running: C:\cygwin\bin\bash.exe --norc --noprofile 
"/etc/postinstall/libsasl2_3.sh"

abnormal exit: exit code=-1073741701

running: C:\cygwin\bin\bash.exe --norc --noprofile 
"/etc/postinstall/python38-pip.sh"

abnormal exit: exit code=-1073741701

running: C:\cygwin\bin\bash.exe --norc --noprofile 
"/etc/postinstall/python38.sh"

abnormal exit: exit code=-1073741701

running: C:\cygwin\bin\dash.exe "/etc/postinstall/man-db.dash"

abnormal exit: exit code=-1073741701

running: C:\cygwin\bin\bash.exe --norc --noprofile "/etc/postinstall/mintty.sh"

abnormal exit: exit code=-1073741701

running: C:\cygwin\bin\dash.exe "/etc/postinstall/zp_man-db-update-index.dash"

abnormal exit: exit code=-1073741701

Changing gid to Administrators

Ending cygwin install

I don't know why. Can anyone help me?
Although the installed packages are different, my other Github Action is 
similar to this one, but that Github Action has no problem.
---
From:
Fxzx mic
fxzx...@outlook.com
---


-- 
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: GitHub Action Error

[marco atzeri]

On Mon, Jan 31, 2022 at 3:16 PM © Fxzx mic  wrote:
>
> I am installing these packages with cygwin/cygwin-install-action@master:
>
> cmake make gdb mingw64-x86_64-gcc-g++
> on Github Action. However, the following error occurred:
>
> Changing gid back to original
> running: C:\cygwin\bin\dash.exe "/etc/postinstall/0p_000_autorebase.dash"
> abnormal exit: exit code=-1073741701

-1073741701 is also 0X   C000 007B

so the error means:
The Application was Unable to Start Correctly (0xc07b)

> I don't know why. Can anyone help me?
> Although the installed packages are different, my other Github Action is 
> similar to this one, but that Github Action has no problem.

I would guess you need to install also the needed packages required by
those packages
or there is something interfering with Cygwin

Have you tested to install only the Base category ?


Regards
Marco

-- 
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

Renaming (with 'mv') very large files is SLOW

[cygwin]

I tried renaming some very large files (20-40 GB) using:
   mv  
without changing the directory of course.

The process took about 10-20 minutes with Task Manager showing disk
activity of 100+ MB/s.

Is there something about such large 'renaming' that actually results
in the file being really moved (aka copied) rather than just renamed?

-- 
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: Renaming (with 'mv') very large files is SLOW

[Eliot Moss]

On 1/31/2022 9:52 AM, cyg...@kosowsky.org wrote:
> I tried renaming some very large files (20-40 GB) using:
> mv  
> without changing the directory of course.
>
> The process took about 10-20 minutes with Task Manager showing disk
> activity of 100+ MB/s.
>
> Is there something about such large 'renaming' that actually results
> in the file being really moved (aka copied) rather than just renamed?

The two places are probably on different volumes (loosely, different disks).
That requires a physical move, even under Linux.  Your volumes seem a bit slow
to access - is one perhaps across a slow network?  The rates you cite suggest
movement of 50Mb/s (50Mb read + 50Mb write = 100Mb overall).  For 40 Gb that
should take 40Gb / 50Mb = about 820 secs = a little under 14 mins.

(When I say your volumes are slow, I speak from the luxury of having a 2Tb
solid state drive!  Actually, those speeds may be reasonable depending on the
nature of your system.)

If the two locations are on different drives, there's no real avoiding this.

Regards - Eliot Moss

--
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: Renaming (with 'mv') very large files is SLOW

[René Berber]

On 1/31/2022 8:59 AM, Eliot Moss wrote:


On 1/31/2022 9:52 AM, cyg...@kosowsky.org wrote:



I tried renaming some very large files (20-40 GB) using: mv
  without changing the directory of course.

The process took about 10-20 minutes with Task Manager showing
disk activity of 100+ MB/s.

Is there something about such large 'renaming' that actually
results in the file being really moved (aka copied) rather than
just renamed?


The two places are probably on different volumes (loosely, different
 disks). That requires a physical move, even under Linux.  Your
volumes seem a bit slow to access - is one perhaps across a slow
network?  The rates you cite suggest movement of 50Mb/s (50Mb read +
50Mb write = 100Mb overall).  For 40 Gb that should take 40Gb / 50Mb
= about 820 secs = a little under 14 mins.

(When I say your volumes are slow, I speak from the luxury of having
a 2Tb solid state drive!  Actually, those speeds may be reasonable
depending on the nature of your system.)

If the two locations are on different drives, there's no real
avoiding this.


Nope, I've also complained about this (long ago), if the two locations
are the same remote drive... Cygwin moves the entire file over the network.

I ended up writing my own Samba mv command.
--
R. Berber

--
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: Renaming (with 'mv') very large files is SLOW

[cygwin]

Eliot Moss wrote at about 09:59:17 -0500 on Monday, January 31, 2022:
 > On 1/31/2022 9:52 AM, cyg...@kosowsky.org wrote:
 >  > I tried renaming some very large files (20-40 GB) using:
 >  > mv  
 >  > without changing the directory of course.
 >  >
 >  > The process took about 10-20 minutes with Task Manager showing disk
 >  > activity of 100+ MB/s.
 >  >
 >  > Is there something about such large 'renaming' that actually results
 >  > in the file being really moved (aka copied) rather than just renamed?
 > 
 > The two places are probably on different volumes (loosely, different disks).
 > That requires a physical move, even under Linux.

No my point is I am just *renaming*, not physically moving the file!!
i.e., I am not changing the directory location of the file, let alone
the volume/disk location.
(I am well aware that 'mv' does a copy when changing volumes/disks).

I literally am typing something like:
  mv foo bar

In Linux, that just edits the file system table & inode...

UPDATE...
I just tried a second 'mv' and it was near instantaneous.
(and similarly with subsequent renaming of the same file)
So perhaps not a 'Cygwin' thing but something going on within Windows.

Could it be that the first 'mv' triggered an anti-virus read of the file since
perhaps it detects it as a new/changed file?

But if so, would 'mv' (under Task Manager) be showing the 100+ MB/s disk 
activity?

-- 
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: Renaming (with 'mv') very large files is SLOW

[cygwin]

René Berber wrote at about 09:13:59 -0600 on Monday, January 31, 2022:
 > On 1/31/2022 8:59 AM, Eliot Moss wrote:
 > 
 > > On 1/31/2022 9:52 AM, cyg...@kosowsky.org wrote:
 > 
 > >> I tried renaming some very large files (20-40 GB) using: mv
 > >>   without changing the directory of course.
 > >> 
 > >> The process took about 10-20 minutes with Task Manager showing
 > >> disk activity of 100+ MB/s.
 > >> 
 > >> Is there something about such large 'renaming' that actually
 > >> results in the file being really moved (aka copied) rather than
 > >> just renamed?
 > > 
 > > The two places are probably on different volumes (loosely, different
 > >  disks). That requires a physical move, even under Linux.  Your
 > > volumes seem a bit slow to access - is one perhaps across a slow
 > > network?  The rates you cite suggest movement of 50Mb/s (50Mb read +
 > > 50Mb write = 100Mb overall).  For 40 Gb that should take 40Gb / 50Mb
 > > = about 820 secs = a little under 14 mins.
 > > 
 > > (When I say your volumes are slow, I speak from the luxury of having
 > > a 2Tb solid state drive!  Actually, those speeds may be reasonable
 > > depending on the nature of your system.)
 > > 
 > > If the two locations are on different drives, there's no real
 > > avoiding this.
 > 
 > Nope, I've also complained about this (long ago), if the two locations
 > are the same remote drive... Cygwin moves the entire file over the network.
 > 
 > I ended up writing my own Samba mv command.
 > -- 

In my case the directory (where I renamed the file) is on my C-drive.

-- 
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

EXPAT 2.4.4 released with fixed CMake support for CYGWIN

[Carlo B.]

Hello,
with reference with this message:

https://cygwin.com/pipermail/cygwin/2022-January/250572.html

I would like to report that EXPAT 2.4.4 has been released with fixed
CMake support for CYGWIN:

https://github.com/libexpat/libexpat/blob/R_2_4_4/expat/Changes

Will it be possible to release an updated package?
Thank you very much for your time.

Sincerely,

Carlo Bramini.

-- 
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: GitHub Action Error

[Lemures Lemniscati]

On Mon, 31 Jan 2022 14:15:41 +, © Fxzx mic
> I am installing these packages with cygwin/cygwin-install-action@master:
> 
> 
> 
> cmake make gdb mingw64-x86_64-gcc-g++
> 
> 
> 
> on Github Action. However, the following error occurred:
> 
> 
> 
> Changing gid back to original
> 
> running: C:\cygwin\bin\dash.exe "/etc/postinstall/0p_000_autorebase.dash"
> 
> abnormal exit: exit code=-1073741701
> 
> running: C:\cygwin\bin\dash.exe "/etc/postinstall/0p_update-info-dir.dash"
> 
> abnormal exit: exit code=-1073741701
> 
> running: C:\cygwin\bin\bash.exe --norc --noprofile 
> "/etc/postinstall/000-cygwin-post-install.sh"
> 
> abnormal exit: exit code=-1073741701
> 
> running: C:\cygwin\bin\bash.exe --norc --noprofile 
> "/etc/postinstall/coreutils.sh"
> 
> abnormal exit: exit code=-1073741701
> 
> running: C:\cygwin\bin\bash.exe --norc --noprofile "/etc/postinstall/bash.sh"
> 
> abnormal exit: exit code=-1073741701
> 
> running: C:\cygwin\bin\bash.exe --norc --noprofile 
> "/etc/postinstall/base-files-mketc.sh"
> 
> abnormal exit: exit code=-1073741701
> 
> running: C:\cygwin\bin\bash.exe --norc --noprofile 
> "/etc/postinstall/base-files-profile.sh"
> 
> abnormal exit: exit code=-1073741701
> 
> running: C:\cygwin\bin\bash.exe --norc --noprofile 
> "/etc/postinstall/p11-kit.sh"
> 
> abnormal exit: exit code=-1073741701
> 
> running: C:\cygwin\bin\bash.exe --norc --noprofile 
> "/etc/postinstall/ca-certificates.sh"
> 
> abnormal exit: exit code=-1073741701
> 
> running: C:\cygwin\bin\bash.exe --norc --noprofile 
> "/etc/postinstall/crypto-policies.sh"
> 
> abnormal exit: exit code=-1073741701
> 
> running: C:\cygwin\bin\dash.exe "/etc/postinstall/openssl.dash"
> 
> abnormal exit: exit code=-1073741701
> 
> running: C:\cygwin\bin\bash.exe --norc --noprofile 
> "/etc/postinstall/libxml2.sh"
> 
> abnormal exit: exit code=-1073741701
> 
> running: C:\cygwin\bin\bash.exe --norc --noprofile 
> "/etc/postinstall/libsasl2_3.sh"
> 
> abnormal exit: exit code=-1073741701
> 
> running: C:\cygwin\bin\bash.exe --norc --noprofile 
> "/etc/postinstall/python38-pip.sh"
> 
> abnormal exit: exit code=-1073741701
> 
> running: C:\cygwin\bin\bash.exe --norc --noprofile 
> "/etc/postinstall/python38.sh"
> 
> abnormal exit: exit code=-1073741701
> 
> running: C:\cygwin\bin\dash.exe "/etc/postinstall/man-db.dash"
> 
> abnormal exit: exit code=-1073741701
> 
> running: C:\cygwin\bin\bash.exe --norc --noprofile 
> "/etc/postinstall/mintty.sh"
> 
> abnormal exit: exit code=-1073741701
> 
> running: C:\cygwin\bin\dash.exe "/etc/postinstall/zp_man-db-update-index.dash"
> 
> abnormal exit: exit code=-1073741701
> 
> Changing gid to Administrators
> 
> Ending cygwin install
> 
> I don't know why. Can anyone help me?
> Although the installed packages are different, my other Github Action is 
> similar to this one, but that Github Action has no problem.

I've got similar experience:
  https://github.com/cygwin/scallywag/runs/5007960186?check_suite_focus=true

This worked well on 2022-01-22:
  https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=libdeflate&status=&id=3754


I wonder cygwin-3.3.4-1 might have an issue.
When I updated to cygwin-3.3.4-1, an error occurred with cygwin1.dll.
And then I downgraded to cygwin-3.3.3-1, it worked again.

Lem

-- 
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: [ANNOUNCEMENT] Updated: setup (2.917)

[Andrey Repin]

Greetings, Jon Turney!

> Probably what's wanted is to remember the state of those checkboxes, if
> this isn't the first time setup has been run?

That's a feature silently longed for for a loong time. :) But this is such a
low priority, very few people actually mentioned it in the past years.


-- 
With best regards,
Andrey Repin
Monday, January 31, 2022 18:45:55

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: [EXTERNAL] Re: Renaming (with 'mv') very large files is SLOW

[Lavrentiev, Anton (NIH/NLM/NCBI) [C] via Cygwin]

> 
> In my case the directory (where I renamed the file) is on my C-drive.
>

If the file is currently open for access, the move can turn out to be a copy, 
actually.

Check open files to make sure whatever you are moving is not being opened / 
accessed from any other program.

Anton Lavrentiev
Contractor NIH/NLM/NCBI


-- 
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: [ANNOUNCEMENT] cygwin 3.3.4-1

[Jim Reisert AD1C]

> The following packages have been uploaded to the Cygwin distribution:
>
> * cygwin-3.3.4-1
> * cygwin-devel-3.3.4-1
> * cygwin-doc-3.3.4-1

I've tried two mirrors, both with the same result:

dash.exe - Bad Image

C:\Cygwin64\bin\cygwin1.dll is either not designed to run on
Windows or it contains an errorError status 0xc07b.

I'm running Windows 11 Pro (21H2), OS Build 22000.469

The previous version has been working just fine.

-- 
Jim Reisert AD1C, , https://www.ad1c.us

-- 
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: [ANNOUNCEMENT] cygwin 3.3.4-1

[David Rothenberger]

On 1/31/2022 10:34 AM, Jim Reisert AD1C wrote:

The following packages have been uploaded to the Cygwin distribution:

* cygwin-3.3.4-1
* cygwin-devel-3.3.4-1
* cygwin-doc-3.3.4-1


I've tried two mirrors, both with the same result:

 dash.exe - Bad Image

 C:\Cygwin64\bin\cygwin1.dll is either not designed to run on
Windows or it contains an errorError status 0xc07b.

I'm running Windows 11 Pro (21H2), OS Build 22000.469

The previous version has been working just fine.


I saw the same errors this morning with Windows 10 Pro for Workstations 
(10.0.19044). I also tried two mirrors. I ended up rolling back to the 
previous version as well.


--
David Rothenberger    daver...@acm.org

Doubt is not a pleasant condition, but certainty is absurd.
-- Voltaire

--
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: [ANNOUNCEMENT] cygwin 3.3.4-1

[Allen Hewes]

> From: Cygwin  On Behalf
> Of David Rothenberger
> Sent: Monday, January 31, 2022 1:39 PM
> To: cygwin@cygwin.com
> Subject: Re: [ANNOUNCEMENT] cygwin 3.3.4-1
>
> On 1/31/2022 10:34 AM, Jim Reisert AD1C wrote:
> >> The following packages have been uploaded to the Cygwin distribution:
> >>
> >> * cygwin-3.3.4-1
> >> * cygwin-devel-3.3.4-1
> >> * cygwin-doc-3.3.4-1
> >
> > I've tried two mirrors, both with the same result:
> >
> >  dash.exe - Bad Image
> >
> >  C:\Cygwin64\bin\cygwin1.dll is either not designed to run on
> > Windows or it contains an errorError status 0xc07b.
> >
> > I'm running Windows 11 Pro (21H2), OS Build 22000.469
> >
> > The previous version has been working just fine.
>
> I saw the same errors this morning with Windows 10 Pro for Workstations
> (10.0.19044). I also tried two mirrors. I ended up rolling back to the 
> previous
> version as well.

Same here. There's something amiss with 3.3.4-1, IMHO. I grabbed the XZ's 
manually from mirrors.dotsrc.org.

Windows 10 Pro
Microsoft Windows [Version 10.0.19044.1503]

Working Cygwin:
CYGWIN_NT-10.0-19044 FOUREYES 3.3.3-341.x86_64 2021-12-03 16:35 UTC x86_64 
Cygwin

/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.

-- 
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

[ANNOUNCEMENT] cygwin 3.3.4-2

[Corinna Vinschen via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* cygwin-3.3.4-2
* cygwin-devel-3.3.4-2
* cygwin-doc-3.3.4-2

This is a replacement for the broken 3.3.4-1 release, which stumbled
over an installation glitch in the latest cygport release.

   IMPORTANT DEPRECATION NOTES
==

- Cygwin 3.3 is the LAST major version supporting

  - Windows Vista
  - Windows Server 2008

- Cygwin 3.3 is the LAST major version supporting 32 bit installations.

  If you're using 32 bit Cygwin in WOW64 on 64 bit machines, consider
  to move to a real 64 bit Cygwin installation in the next couple of
  months.

  If you're using 32 bit Cygwin on real 32 bit hardware or on WOW64 on
  ARM64, don't be alarmed.  The current installations including all
  Cygwin 3.3.x versions will continue to run on your system.  You just
  wont get any more updates starting with Cygwin 3.4.0.

- Cygwin 3.4, which will probably be release at some point in 2022,
  will be the LAST version supporting

  - Windows 7
  - Windows Server 2008 R2
  - Windows 8
  - Windows Server 2012

There are no plans to deprecate support for 64 bit systems starting with
Windows 8.1 / Windows Server 2012 R2 any time soon.

==

Bug Fixes
-

- Fix a bug in fhandler_dev_clipboard::read() that the second read
  fails with 'Bad address'.
  Addresses: https://cygwin.com/pipermail/cygwin/2021-December/250141.html

- Convert UNC path prefix back to drive letter in symlink_info::check().
  This solves the following issues:
  Addresses: https://cygwin.com/pipermail/cygwin/2021-November/250087.html
 https://cygwin.com/pipermail/cygwin/2021-December/250103.html

- Fix a bug in pty code that input is wrongly sent to io_handle_nat
  rather than io_handle while neither read() nor select() is called
  after the cygwin app is started from non-cygwin app.
  Addresses: https://cygwin.com/pipermail/cygwin-patches/2021q4/011587.html

- Avoid a crash when NtQueryInformationProcess returns invalid handle data.
  Addresses: https://cygwin.com/pipermail/cygwin-patches/2021q4/011611.html

- Ignore INHERIT ACEs when reading the DACL of non-directory files.
  Addresses: https://cygwin.com/pipermail/cygwin/2022-January/250363.html

- Fix an "Invalid argument" problem in posix_spawn on i686.
  Addresses: https://cygwin.com/pipermail/cygwin/2022-January/250453.html

- Fix handling of  records in Cygwin resolver code using native
  windows calls.  Also fix various bugs in the resolver.

- Fix a problem creating a dir "foo", if a file (but not a Cygwin symlink)
  "foo.lnk" already exists.
  Addresses: https://github.com/msys2/msys2-runtime/issues/81

- Fix double free for archetype, which is caused when open() fails.
  Addresses: https://cygwin.com/pipermail/cygwin/2022-January/250518.html

- Fix a permission problem when writing DOS attributes on Samba.
  Addresses: https://cygwin.com/pipermail/cygwin/2022-January/250629.html


-- 
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: [ANNOUNCEMENT] Updated: setup (2.917)

[Brian Inglis]

On 2022-01-31 08:46, Andrey Repin wrote:

Greetings, Jon Turney!


Probably what's wanted is to remember the state of those checkboxes, if
this isn't the first time setup has been run?


That's a feature silently longed for for a loong time. :) But this is such a
low priority, very few people actually mentioned it in the past years.


It could usefully be added similarly to last-action:

$ fgrep -A1 action /etc/setup/setup.rc
last-action
Download,Install

last-shortcut:
Desktop|StartMenu|none,...

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

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

--
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

gnu gcc search path

[Sam Darwin]

Hi,

Regarding https://cygwin.com/packages/summary/gcc-g++.html  This is a
(perhaps) esoteric question about how gnu gcc should operate.  It says at
https://gcc.gnu.org/onlinedocs/cpp/Search-Path.html  "By default, the
preprocessor looks for header files included by the quote form of the
directive #include "file" first relative to the directory of the current
file," When building boost C++ libraries on an earlier version of cygwin
this used to work fine.  Now, updating to a newer cygwin version on
Appveyor, "APPVEYOR_BUILD_WORKER_IMAGE: Visual Studio 2019"  , it has
broken..

Errors appear such as

"fatal error: zutil.h: No such file or directory 8 | #include "zutil.h"
compilation terminated."

"No such file or directory."

What do you think? It can't find the header file, which happens to be in
the same directory, the current directory.It seems like a bug, however,
if it's intended behavior, and the current directory has been removed from
the search path, then could a command-line flag be provided to optionally
re-enable the previous functionality?

-- 
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: git/cygwin-packages package repo http URLs incorrect and fail

[Brian Inglis]

On 2022-01-31 05:18, Jon Turney wrote:

On 31/01/2022 07:55, Brian Inglis wrote:

In the URLs shown for git/cygwin-packages repo access:

URL    git://cygwin.com/git/cygwin-packages/PKG.git
 http://cygwin.com/git/cygwin-packages/PKG.git
 ssh://cygwin@cygwin.com/git/cygwin-packages/PKG.git

the web URL fails and should be:

 https://cygwin.com/git/?p=git/cygwin-packages/PKG.git

as in the PKG links in the git/cygwin-packages list.


No.  Between the URL for git access with git transport and the URL for 
git access with ssh transport, is the URL for git access with http 
transport, not the URL of the page you are looking at.


Thanks, that explains my difficulty checking if repos exist using 
commands, to avoid the load on the server of pulling up the project 
list, the long delay waiting for it to populate, then manually ^F to 
Find the package!


I guess we just have to remember with gitweb to copy the git portion and 
insert '?p=' between the occurrences.



Can't find a ref in the ...htdocs... or I would submit a patch.


This URL comes from the gitweb configuration, which isn't checked into 
that repo (for no good reason, so I'll see what I can do about that...)


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

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.
[Data in binary units and prefixes, physical quantities in SI.]

--
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: Renaming (with 'mv') very large files is SLOW

[Adam Dinwoodie]

On Mon, Jan 31, 2022 at 10:17:59AM -0500, cyg...@kosowsky.org wrote:
> Eliot Moss wrote at about 09:59:17 -0500 on Monday, January 31, 2022:
>  > On 1/31/2022 9:52 AM, cyg...@kosowsky.org wrote:
>  >  > I tried renaming some very large files (20-40 GB) using:
>  >  > mv  
>  >  > without changing the directory of course.
>  >  >
>  >  > The process took about 10-20 minutes with Task Manager showing disk
>  >  > activity of 100+ MB/s.
>  >  >
>  >  > Is there something about such large 'renaming' that actually results
>  >  > in the file being really moved (aka copied) rather than just renamed?
>  > 
>  > The two places are probably on different volumes (loosely, different 
> disks).
>  > That requires a physical move, even under Linux.
> 
> No my point is I am just *renaming*, not physically moving the file!!
> i.e., I am not changing the directory location of the file, let alone
> the volume/disk location.
> (I am well aware that 'mv' does a copy when changing volumes/disks).
> 
> I literally am typing something like:
>   mv foo bar
> 
> In Linux, that just edits the file system table & inode...
> 
> UPDATE...
> I just tried a second 'mv' and it was near instantaneous.
> (and similarly with subsequent renaming of the same file)
> So perhaps not a 'Cygwin' thing but something going on within Windows.
> 
> Could it be that the first 'mv' triggered an anti-virus read of the file since
> perhaps it detects it as a new/changed file?
> 
> But if so, would 'mv' (under Task Manager) be showing the 100+ MB/s disk 
> activity?

That definitely seems plausible; there's a reason a significant number
of the applications that are known to interfere with Cygwin operation
(see [0]) are antivirus applications.  But what would trigger your
antivirus to want to scan a file, and how much work is required to do
that, is something you'll need to take up with your antivirus vendor,
I'm afraid.

[0]: https://cygwin.com/faq/faq.html#faq.using.bloda

-- 
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

setup-*.exe --help default explanation re -D/-L options [Was: [ANNOUNCEMENT] Updated: setup (2.917)]

[Adam Dinwoodie]

On  Mon, 31 Jan 2022 12:56:13 -0700, Brian Inglis wrote:
> On 2022-01-31 08:46, Andrey Repin wrote:
> > Greetings, Jon Turney!
> > 
> > > Probably what's wanted is to remember the state of those checkboxes, if
> > > this isn't the first time setup has been run?
> > 
> > That's a feature silently longed for for a loong time. :) But this is such a
> > low priority, very few people actually mentioned it in the past years.
> 
> It could usefully be added similarly to last-action:
> 
>   $ fgrep -A1 action /etc/setup/setup.rc
>   last-action
>   Download,Install
> 
> last-shortcut:
>   Desktop|StartMenu|none,...

This reminded me of a bug report I've been meaning to properly
characterise and report for a while, and also pointed me at a
workaround...

Currently, running `setup-*.exe --help` produces output that includes
the following:

-D --download   Download packages from internet only
-L --local-install  Install packages from local directory only

The default is to both download and install packages, unless either
--download or --local-install is specified.

I think the descriptions for the `-D` and `-L` options are misleading,
at least in combination with that final line, which is definitely wrong.
As I understand it, the actual behaviour would be better described by
something like the below:

-D --download   Download packages from internet only, unless -L
is also specified
-L --local-install  Install packages from local directory only,
unless -D is also specified

If neither --download nor --local-install is specified, the default
is to repeat the same action as from the previous run.  If no
previous run can be found, the default is to perform both actions,
and both actions can be explicitly requested by specifying both
--download and --local-install.

In particular, the fact that the two options currently say they will
"only" do their action, and that the default is to perform both, lead me
to believe (a) the options were mutually exclusive and one would
presumably override the other, (b) this was probably a legacy from
before setup.rc stored the previous action, and therefore (c) if I was
running setup with `-q` or `-M`, there was no way to get the supposedly
default "do both" behaviour; I'd instead need to go through the full
GUI.

Having now seen how this setting is stored, I've realised I can just
call setup with `-DL` and it'll perform both actions again.  But I think
my assumption that "default" was supposed to mean "default always" not
"default only on first run" wasn't *entirely* PEBCAK (even if it mostly
was), so that help text would definitely benefit from being made a bit
more explicit.

(I'm aware my suggestion above is decidedly wordy; it's not intended to
be exactly what I think is required, only a first pass at clarifying the
key details I think are missing.)

-- 
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: GitHub Action Error

[Adam Dinwoodie]

On Tue, Feb 01, 2022 at 12:34:45AM +0900, Lemures Lemniscati wrote:
> On Mon, 31 Jan 2022 14:15:41 +, © Fxzx mic
> > 
> > running: C:\cygwin\bin\dash.exe "/etc/postinstall/0p_000_autorebase.dash"
> > 
> > abnormal exit: exit code=-1073741701
> > 
> >  > 
> > I don't know why. Can anyone help me?
> > Although the installed packages are different, my other Github Action is 
> > similar to this one, but that Github Action has no problem.
> 
> I've got similar experience:
>   https://github.com/cygwin/scallywag/runs/5007960186?check_suite_focus=true
> 
> This worked well on 2022-01-22:
>   https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=libdeflate&status=&id=3754
> 
> 
> I wonder cygwin-3.3.4-1 might have an issue.
> When I updated to cygwin-3.3.4-1, an error occurred with cygwin1.dll.
> And then I downgraded to cygwin-3.3.3-1, it worked again.

Replying here to close the loop on this thread: I suspect this is now
fixed in the 3.3.4-2 release:

https://cygwin.com/pipermail/cygwin-announce/2022-January/010439.html

-- 
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: [ANNOUNCEMENT] cygwin 3.3.4-1

[Adam Dinwoodie]

On Mon, Jan 31, 2022 at 06:49:01PM +, Allen Hewes wrote:
> > From: Cygwin  On Behalf
> > Of David Rothenberger
> > Sent: Monday, January 31, 2022 1:39 PM
> > To: cygwin@cygwin.com
> > Subject: Re: [ANNOUNCEMENT] cygwin 3.3.4-1
> >
> > On 1/31/2022 10:34 AM, Jim Reisert AD1C wrote:
> > >> The following packages have been uploaded to the Cygwin distribution:
> > >>
> > >> * cygwin-3.3.4-1
> > >> * cygwin-devel-3.3.4-1
> > >> * cygwin-doc-3.3.4-1
> > >
> > > I've tried two mirrors, both with the same result:
> > >
> > >  dash.exe - Bad Image
> > >
> > >  C:\Cygwin64\bin\cygwin1.dll is either not designed to run on
> > > Windows or it contains an errorError status 0xc07b.
> > >
> > > I'm running Windows 11 Pro (21H2), OS Build 22000.469
> > >
> > > The previous version has been working just fine.
> >
> > I saw the same errors this morning with Windows 10 Pro for Workstations
> > (10.0.19044). I also tried two mirrors. I ended up rolling back to the 
> > previous
> > version as well.
> 
> Same here. There's something amiss with 3.3.4-1, IMHO. I grabbed the XZ's 
> manually from mirrors.dotsrc.org.
> 
> Windows 10 Pro
> Microsoft Windows [Version 10.0.19044.1503]
> 
> Working Cygwin:
> CYGWIN_NT-10.0-19044 FOUREYES 3.3.3-341.x86_64 2021-12-03 16:35 UTC x86_64 
> Cygwin

Replying here to close the loop on this thread: I suspect this is now
fixed in the 3.3.4-2 release:

https://cygwin.com/pipermail/cygwin-announce/2022-January/010439.html

-- 
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

Install seems broken

[tpi.slings...@outlook.com]

I was running Cygwin 3.3.1 on a windows 10 pc.

When I update to 3.3.4, I couldn’t run Cygwin on this hardware anymore.

The installer says “cygwin1.dll” can’t run on this hardware.

I had to find a mirror that hadn’t updated to 3.3.4 to get Cygwin  back.

-dwd

Sent from Mail for Windows


-- 
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: Install seems broken

[Adam Dinwoodie]

On Mon, Jan 31, 2022 at 10:54:19PM +, TPI.Slingshot wrote:
> I was running Cygwin 3.3.1 on a windows 10 pc.
> 
> When I update to 3.3.4, I couldn’t run Cygwin on this hardware anymore.
> 
> The installer says “cygwin1.dll” can’t run on this hardware.

This sounds like the known problem with 3.3.4-1, discussed several times
on this list today already.

Please try the new 3.3.4-2 release, discussed at
.
If your normal mirror hasn't picked that release up yet, you'll need to
either find a more up-to-date mirror, or wait until your current mirror
has picked up that release.

> I had to find a mirror that hadn’t updated to 3.3.4 to get Cygwin  back.

This shouldn't be necessary, at least if you were using one of the
mirrors offered by default by the installer: I believe all the official
mirrors are required to keep full copies of previous releases, so you
should have been able to select 3.3.3-1 (or indeed any of several older
releases) by selecting the version you wanted from the drop-down in the
installer.

-- 
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: [ANNOUNCEMENT] cygwin 3.3.4-1

[David Schuler]

For those of us who are experiencing this problem, what is the actual 
method of resolving this problem?  It's not obvious to me.


THANKS
David Schuler

On 1/31/2022 5:20 PM, Adam Dinwoodie wrote:

On Mon, Jan 31, 2022 at 06:49:01PM +, Allen Hewes wrote:

From: Cygwin  On Behalf
Of David Rothenberger
Sent: Monday, January 31, 2022 1:39 PM
To: cygwin@cygwin.com
Subject: Re: [ANNOUNCEMENT] cygwin 3.3.4-1

On 1/31/2022 10:34 AM, Jim Reisert AD1C wrote:

The following packages have been uploaded to the Cygwin distribution:

* cygwin-3.3.4-1
* cygwin-devel-3.3.4-1
* cygwin-doc-3.3.4-1

I've tried two mirrors, both with the same result:

  dash.exe - Bad Image

  C:\Cygwin64\bin\cygwin1.dll is either not designed to run on
Windows or it contains an errorError status 0xc07b.

I'm running Windows 11 Pro (21H2), OS Build 22000.469

The previous version has been working just fine.

I saw the same errors this morning with Windows 10 Pro for Workstations
(10.0.19044). I also tried two mirrors. I ended up rolling back to the previous
version as well.

Same here. There's something amiss with 3.3.4-1, IMHO. I grabbed the XZ's 
manually from mirrors.dotsrc.org.

Windows 10 Pro
Microsoft Windows [Version 10.0.19044.1503]

Working Cygwin:
CYGWIN_NT-10.0-19044 FOUREYES 3.3.3-341.x86_64 2021-12-03 16:35 UTC x86_64 
Cygwin

Replying here to close the loop on this thread: I suspect this is now
fixed in the 3.3.4-2 release:

https://cygwin.com/pipermail/cygwin-announce/2022-January/010439.html




--
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: [ANNOUNCEMENT] cygwin 3.3.4-1

[Allen Hewes]

> -Original Message-
> From: Cygwin  On Behalf
> Of David Schuler
> Sent: Monday, January 31, 2022 7:04 PM
> To: cygwin@cygwin.com
> Subject: Re: [ANNOUNCEMENT] cygwin 3.3.4-1
>
> For those of us who are experiencing this problem, what is the actual
> method of resolving this problem?  It's not obvious to me.
>

I manually downloaded the XZ package from a mirror. Then decompressed it. Then 
replaced the cygwin1.dll in my Cygwin install directory (C:\Cygwin64).
http://mirrors.dotsrc.org/cygwin/x86_64/release/cygwin/cygwin-3.3.3-1.tar.xz

Then re-run Setup and choose the prior version in the drop down menu for the 
cygwin-* package(s).

Setup can run without Cygwin. It's the post-install bits/jobs/tasks that 
require a functioning Cygwin install. Which means you should be able to start 
Setup, then change it to "All" (from "Pending") on the "Select Packages" 
dialog. Then find your installed "cygwin-"  packages, then to the right is a 
drop down. Choose the previous version 3.3.3-1 (from 3.3.4-1).

Of course you can wait till the just released update lands on your mirror or 
pick-n-choose mirrors until you find one with the 3.3.4-2 version on it.

/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.

-- 
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

[ANNOUNCEMENT] Updated: octave forge packages

[Marco Atzeri via Cygwin-announce]

New versions of

x86/x86_64 arch

  octave-communications-1.2.4-1
  octave-control-3.4.0-1
  octave-fits-1.0.8-0.2
  octave-instrument-control-0.7.1-1
  octave-interval-3.2.1-1

for Octave 6.4 are available in the Cygwin distribution:

ADVISE
To load any package before usage run
 "pkg load "

see "help pkg" for details.

CHANGES
last upstream version.

DESCRIPTION
The octave-forge project contains contributed functions
for GNU Octave which are not in the main distribution.

HOMEPAGE
https://octave.sourceforge.io

Full documentation and FAQ are available at:
https://octave.sourceforge.io/docs.php
https://octave.sourceforge.io/packages.php

Regards
Marco Atzeri

If you have questions or comments, please send them to the
cygwin mailing list at: cygwin (at) cygwin (dot) com .

--
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