Re: Why python > 36 so many dependencies?

[Jon Turney via Cygwin]

On 25/04/2024 18:46, gs-cygwin.com--- via Cygwin wrote:

On Thu, Apr 25, 2024 at 10:19:05AM -0400, Peter Lai via Cygwin wrote:

Why does installing python > py36 result in bringing in so many
dependencies like libXdmcp etc, when the intent is to just run python
interpreter from cli? Is this because of the way it's built for cygwin? I
build python all the time in NetBSD using pkgsrc and in FreeBSD ports,
without needing all of those deps. I don't know much about how cygport
works, is there a repo of cygport files I can look at?


The load at https://cygwin.com/git/ is too high at the moment
and I get "503 - The load average on the server is too high"


https://cygwin.com/cgit/ may behave better.


Take a look at some mirrors.

For cygport code:
https://github.com/cygwin/cygport


This is just a mirror of https://cygwin.com/cgit/cygwin-apps/cygport/

You should probably take a look at the cygport manual () before reading 
the source code.



Lots of individual repositories under here with cygport projects
https://github.com/cygwinports/


No, don't look there!

Those repositories haven't been updated for some time, and really should 
really be archived, but the owner is too busy.



e.g.
https://github.com/cygwinports/python36


https://cygwin.com/cgit/cygwin-packages/python36/


--
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: native symlinks and non-existent targets

[Jon Turney via Cygwin]

On 24/04/2024 23:36, Christopher Layne via Cygwin wrote:

On Wed, Apr 24, 2024 at 10:11:52PM +, Christopher Layne via Cygwin wrote:

Based on past threads I've read I believe the issue is actually with
windows not allowing a symlink to be created with a non-existent target,
but I do know windows does not care if you break a link after the fact.


Actually, after referring to some microsoft documentation, is this even
true?


No.

However, native symlinks do record the type (file or directory) of the 
destination, and (absent special knowledge) this cannot be determined if 
the destination doesn't exist (yet).


If I recall correctly, Cygwin doesn't care if the type recorded in the 
symlink is incorrect, but some parts of Windows do...



If it isn't true then this seems trivial to fix.


This assertion is trivially disproven by the lack of a patch attached. :)


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

Fwd: Howto request an upgrade for keychain package

[Jon Turney via Cygwin-apps]

Hi Jari,

There do seem to be some incompatibilities between our current keychain 
package and current gpg/gpg2.


Is it possible to get an update of keychain? Or let me know if you want 
to orphan that package.


TIA.

 Forwarded Message 
Subject: Howto request an upgrade for keychain package
Date: Thu, 18 Apr 2024 20:10:43 +0200
From: J M via Cygwin 
Reply-To: J M 
To: cyg...@cygwin.com
Newsgroups: gmane.os.cygwin

Hi,

I'm having some problems (gpg2, and some for ssh management) with keychain
package: https://www.cygwin.com/packages/summary/keychain.html

It version is 2.7.1, can be upgraded to, by example the last 2.8.5?

It is here: https://github.com/funtoo/keychain/tree/2.8.5

Regards

ninja 1.12.0-1

[Jon Turney via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* ninja-1.12.0-1
* ninja-debuginfo-1.12.0-1

Ninja is yet another build system. It takes as input the interdependencies of 
files (typically source code and output executables) and
orchestrates building them, quickly.



-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

Re: Let's Encrypt Dropping Cross-Signed Root and Intermediates; Issuing New Intermediates; New Cert Chains

[Jon Turney via Cygwin-apps]

On 17/04/2024 04:48, Brian Inglis via Cygwin-apps wrote:

Hi folks,


Is this FYI, or are you suggesting there is some specific action we need 
to take?



https://letsencrypt.org/2023/07/10/cross-sign-expiration
Shortening the Let's Encrypt Chain of Trust
"On Thursday, Feb 8th, 2024, we stopped providing the cross-sign by 
default in requests made to our /acme/certificate API endpoint.
On Thursday, June 6th, 2024, we will stop providing the longer 
cross-signed chain entirely.

On Monday, September 30th, 2024, the cross-signed certificate will expire."

https://letsencrypt.org/2024/03/19/new-intermediate-certificates
New Intermediate Certificates
"Let’s Encrypt generated 10 new Intermediate CA Key Pairs, and issued 15 
new Intermediate CA Certificates containing the new public keys."


https://letsencrypt.org/2024/04/12/changes-to-issuance-chains
Deploying Let's Encrypt's New Issuance Chains
"On Thursday, June 6th, 2024, we will be switching issuance to use our 
new intermediate certificates. Simultaneously, we are removing the DST 
Root CA X3 cross-sign from our API, aligning with our strategy to 
shorten the Let’s Encrypt chain of trust. We will begin issuing ECDSA 
end-entity certificates from a default chain that just contains a single 
ECDSA intermediate, removing a second intermediate and the option to 
issue an ECDSA end-entity certificate from an RSA intermediate."

Re: Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages)

[Jon Turney via Cygwin-apps]

On 18/04/2024 07:01, Ake Rehnman wrote:

Den tors 28 mars 2024 kl 18:50 skrev Jon Turney :


On 24/03/2024 17:46, Jon Turney via Cygwin-apps wrote:

On 24/03/2024 17:31, Marco Atzeri via Cygwin-apps wrote:

On 24/03/2024 15:07, Jon Turney wrote:

On 24/09/2023 13:32, Jon Turney via Cygwin-apps wrote:

I assume you are OK with the removal of python 3.5 (EOL Sept 2020)
and 3.6 (EOL Dec 2021)?

(I'm still dealing with cleaning up the final pieces of python27
detritus, but these should hopefully be much smaller tasks)


nothing should depend from 3.5
not sure for 3.6


I've automated some of the analysis I was doing for python2 packages and
the results are now available at [1].

So yeah, it looks like nothing uses 3.5.

There are just a couple of packages using 3.6, I guess I'll ping the
maintainers about those.

[1] https://cygwin.com/packages/reports/python_rebuilds.html


Ake,


Hi Jon, sorry for the late reply.


No problem.


Is it possible to update/rebuild libftdi1, which only publishes python
bindings for the soon-to-be removed python36?


I am not sure, I have not looked at it for so many years, I have not
even used cygwin since I don't remember...


(Or indicate that you are no longer interested in maintaining this
package, which will probably lead to it's removal).


Do you have any stats on how many installs it was last year?


I'm afraid we don't collect that information.

If you are not using it anymore, it seems like the logical thing to do 
is orphan this package (and libconfuse, it's dependency, your only other 
package).


Thanks for your work in the past.

Re: calm: ERROR: Upload failed: cd: Access failed: No such file (/x86_64/release)

[Jon Turney via Cygwin-apps]

On 17/04/2024 20:26, Brian Inglis via Cygwin-apps wrote:

Hi folks,

Fairly straightforward upgrade of packages.
Is anything demented about my setup:

$ cygport GeoIP.cygport upload
 >>> Uploading GeoIP-1.7.0-1.x86_64
 >>> Running lftp sftp://cygwin:@cygwin.com
cd: Access failed: No such file (/x86_64/release)
*** ERROR: Upload failed


Thanks for reporting this.

When I connect using `lftp sftp://cygwin` I now seem to be logged in to 
the sftp *root* instead of /home/Brian\ Inglis!


But in future, if you are ever reporting "I think I have access to stuff 
on sourceware I shouldn't have access to", you may, exceptionally in 
that situation only, send me a private mail.


Or is this just a way to allow my GeoIP... updates to be fixed up before 
I can do anything more?


This was the result of a sshd configuration error which has been 
rectified by sourceware overseers.

Re: [ITA] GeoIP, GeoIP-database, geoipupdate

[Jon Turney via Cygwin-apps]

On 17/04/2024 00:39, Brian Inglis via Cygwin-apps wrote:

On 2024-04-16 13:31, Jon Turney via Cygwin-apps wrote:

On 13/04/2024 14:09, Brian Inglis via Cygwin-apps wrote:
I would like to adopt and revive the above packages with the last 
("unofficial") version of the legacy code committed noted in the 
ChangeLog as 1.7.0, and a new upstream source for legacy format free 
databases converted when the official current upstream databases are 
updated.


My very limited, vague understanding was that GeoIP is obsolete and 
users should move to something newer? What packages do we have that 
actually depend on this? Are there other ways to update them?


$ cygcheck-dep -nqS libGeoIP1 libmaxminddb0
  libGeoIP1: is needed for ( GeoIP libdns1104 libdns1105 libdns166 
libdns169 libGeoIP-devel )
  libmaxminddb0: is needed for ( bind libdns1106 libmaxminddb-devel 
lighttpd-mod_maxminddb )


Looks like older bind used free legacy GeoIP databases, "current" bind 
uses current library and current GeoIP2 databases which require free 
registration to get an API key with limits.
The new upstream source for free legacy GeoIP databases converts 
upstream GeoIP2 databases and makes them available under its CC-by-4.0 
licence.


The most recent bind package was built with '--without-geoip'.  Does 
this need to change back again?


$ cpm-sum libdns1{6{6,9},10{4,5,6}} | grep 
'dns\|bind\|maxmind\|GeoIP\|depends:\|ackage:$'

Package: libdns166
    depends:
    cygwin, libGeoIP1, libgssapi_krb5_2, libisc160, libjson-c2, libkrb5_3,
    rdepends:
    dnsperf, libbind9_160, libirs160, libisccfg160
    source package:
    bind


I guess there's another thread to pull on here.

The code which looks for "old soversions we don't need to keep anymore" 
isn't smart enough currently to realize that it can get rid of all of 
these old libdns soversions.


Assuming that gets fixed (...), do we still have users?

Re: calm: ERROR: package 'geoipupdate' is at paths geoipupdate and GeoIP-database/geoipupdate

[Jon Turney via Cygwin-apps]

On 17/04/2024 15:17, Brian Inglis via Cygwin-apps wrote:
On 2024-04-17 07:08, 
cygwin-no-reply-rdbxbdvo6bxqt0dzr+a...@public.gmane.org wrote:
ERROR: package 'geoipupdate' is at paths geoipupdate and 
GeoIP-database/geoipupdate


This is the "change things to that the geoipupdate package belongs to 
GeoIP-database source" I previously mentioned.


I've done that, and the upload seems to have succeeded.

I also fixed a typo I noticed in the geoipupdate DESCRIPTION:

- THe geoipupdate database updater script downloads the latest available
+ The geoipupdate database updater script downloads the latest available

Re: [ITA] GeoIP, GeoIP-database, geoipupdate

[Jon Turney via Cygwin-apps]

On 13/04/2024 14:09, Brian Inglis via Cygwin-apps wrote:
I would like to adopt and revive the above packages with the last 
("unofficial") version of the legacy code committed noted in the 
ChangeLog as 1.7.0, and a new upstream source for legacy format free 
databases converted when the official current upstream databases are 
updated.


My very limited, vague understanding was that GeoIP is obsolete and 
users should move to something newer? What packages do we have that 
actually depend on this? Are there other ways to update them?



Is there any easy way of overridding package version from
ac_init_version without patching configure.ac?


Generally, no.

As part of this upgrade, the geoipupdate source and databases are no 
longer available, so the new upstream database source update script 
becomes a new database subpackage and script geoipupdate, and the old 
geoipupdate source, binary, and debuginfo packages should become obsolete.


Is there anything special required to replace a source package and 
binaries with a binary subpackage?


Uh... I had to reread that several times (and compare with the cygport) 
before it this question made sense.


So: when you come to upload, I'll need to change things to that the 
geoipupdate package belongs to GeoIP-database source.


geoipupdate should probably obsolete geoipupdate-debuginfo, if it's now 
empty.


Reviewing the cygports, everything looks OK.

I'd make the comment that the text about scheduling geoipupdate to run 
should be in geoipupdate_DESCRIPTION, rather than in GeopIP-database's 
description.


I added GeoIP and GeoIP-database to your packages.

Re: Use Microsoft YaHei UI as UI font for Chinese language

[Jon Turney via Cygwin]

On 11/04/2024 13:42, Jon Turney via Cygwin wrote:

On 03/04/2024 14:19, Yang Yu Lin via Cygwin wrote:
For Chinese language, the app’s default UI font is Microsoft YaHei UI. 
Using MS Shell Dlg makes the UI become annoying.

Here are my changes:
diff --git a/res/zh_Hans/res.rc b/res/zh_Hans/res.rc
index 9f67a5a..da9d6e8 100644
--- a/res/zh_Hans/res.rc
+++ b/res/zh_Hans/res.rc
@@ -8,7 +8,7 @@ LANGUAGE LANG_CHINESE, SUBLANG_CHINESE_SIMPLIFIED
  IDD_SOURCE DIALOG 0, 0, SETUP_STANDARD_DIALOG_DIMS
  STYLE DS_MODALFRAME | DS_CENTER | WS_CHILD | WS_CAPTION | WS_SYSMENU
  CAPTION "Cygwin 安装程序 - 选择安装类型"
-FONT 8, "MS Shell Dlg"
+FONT 9, "Microsoft YaHei UI"


Thanks very much for this patch!

So, this isn't applicable as is, because the localized res.rc files are 
generated from a template res.rc file and the language .po file (using 
po2rc from Translate Toolkit [1][2]).  See section starting after "rules 
for translation maintenance" in Makefile.am


However, this seems like it would be straightforward to do via a 
post-processing step there.


I added this.

It seems this makes the whole dialog bigger (presumably since it's sized 
in DLU, which are based on the font metrics, which are different for 
this font).


I'll take your word over the aesthetics of the font choice, but I do 
have a question about what versions of Windows we can assume that font 
is available on (in theory at least, one might be using a current setup 
executable to install Cygwin from the CTM on OSs back to Windows XP3)


I've build an updated setup with these changes [1].  Please give this a 
try and see if it looks better to you.


[1] https://cygwin.com/setup/setup-2.932.x86_64.exe


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

xorg-server-21.1.12-1

[Jon Turney]

The following packages have been uploaded to the Cygwin distribution:

* xorg-server-21.1.12-1
* xorg-server-common-21.1.12-1
* xorg-server-debuginfo-21.1.12-1
* xorg-server-devel-21.1.12-1
* xorg-server-extra-21.1.12-1
* xorg-server-xorg-21.1.12-1
* xwinclip-21.1.12-1

These packages contain XWin and the other X.Org X11 servers.

In addition to upstream fixes [1][2][3], the following cygwin-specific 
changes have been made since 21.1.9-1:


* Fix a buffer overflow detected when compiling with _FORTIFY_SOURCE=3

[1] https://lists.x.org/archives/xorg-announce/2023-December/003436.html
[2] https://lists.x.org/archives/xorg-announce/2024-January/003442.html
[3] https://lists.x.org/archives/xorg-announce/2024-April/003499.html
--
 *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

Re: package uploads not being processed again - calm failed or stuck?

[Jon Turney via Cygwin-apps]

On 14/04/2024 22:01, Brian Inglis via Cygwin-apps wrote:

On 2024-04-14 13:53, Brian Inglis via Cygwin-apps wrote:
Not seeing any progress hours after package upload - master setup.ini 
not updated and no calm emails received - has calm failed or is it stuck?


`ssh` commands /help/, /alive/, /info/ work okay - could do with a 
/status/ command to show us what calm is doing!


Sorry, this isn't going to happen for various reasons.

Achim - none of your announced releases appear to have been processed 
yet!


Thanks to whoever got the process going again a half hour ago!
I could see from curl -I the setup.ini last-modified date updated.


No problem.  sourceware overseers have re-arranged things so it won't be 
automatically killed by systemd for lols, and I am assured it should 
carry on running now...


Some emails reporting uploads that had been processed have been lost 
during the confusion.


We apologize for the inconvenience.

Re: package uploads not being processed - calm failed or stuck?

[Jon Turney via Cygwin-apps]

On 13/04/2024 21:12, Brian Inglis via Cygwin-apps wrote:

Hi folks,

Not seeing any progress hours after package upload - master setup.ini 
not updated and no calm emails received - has calm failed or is it stuck?


Thanks for the report.

Not sure what went wrong there, but I've restarted it and it seems to 
have processed all the pending uploads.

Re: Use Microsoft YaHei UI as UI font for Chinese language

[Jon Turney via Cygwin]

On 03/04/2024 14:19, Yang Yu Lin via Cygwin wrote:

For Chinese language, the app’s default UI font is Microsoft YaHei UI. Using MS 
Shell Dlg makes the UI become annoying.
Here are my changes:
diff --git a/res/zh_Hans/res.rc b/res/zh_Hans/res.rc
index 9f67a5a..da9d6e8 100644
--- a/res/zh_Hans/res.rc
+++ b/res/zh_Hans/res.rc
@@ -8,7 +8,7 @@ LANGUAGE LANG_CHINESE, SUBLANG_CHINESE_SIMPLIFIED
  IDD_SOURCE DIALOG 0, 0, SETUP_STANDARD_DIALOG_DIMS
  STYLE DS_MODALFRAME | DS_CENTER | WS_CHILD | WS_CAPTION | WS_SYSMENU
  CAPTION "Cygwin 安装程序 - 选择安装类型"
-FONT 8, "MS Shell Dlg"
+FONT 9, "Microsoft YaHei UI"


Thanks very much for this patch!

So, this isn't applicable as is, because the localized res.rc files are 
generated from a template res.rc file and the language .po file (using 
po2rc from Translate Toolkit [1][2]).  See section starting after "rules 
for translation maintenance" in Makefile.am


However, this seems like it would be straightforward to do via a 
post-processing step there.


I'll take your word over the aesthetics of the font choice, but I do 
have a question about what versions of Windows we can assume that font 
is available on (in theory at least, one might be using a current setup 
executable to install Cygwin from the CTM on OSs back to Windows XP3)


I wonder if we ought to be using "MS Shell Dlg 2" and/or DS_SHELLFONT, 
but the documentation about those is incomprehensible.




If you have any future patches to setup, please send them to the 
cygwin-apps mailing list



[1] https://github.com/translate/translate
[2] (Although there may be some patches needed which have yet to make it 
upstream, so this might not work for you, yet)



--
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: python2 removal

[Jon Turney via Cygwin-apps]

On 10/04/2024 20:19, Hamish McIntyre-Bhatty via Cygwin-apps wrote:

On 19/01/2024 18:23, Hamish McIntyre-Bhatty via Cygwin-apps wrote:

On 18/01/2024 19:40, Jon Turney wrote:

On 18/01/2024 19:31, Jon Turney via Cygwin-apps wrote:
[...]
python-wx-devel    wxWidgets C++ application framework (Python 
bindings)

[...]


python-wx-devel is the last remnant of python2 bindings for wx (the 
python3 binding comes from a different, irregularly named source 
package python3-wx), so can also be removed.


Cc:ing Hamish as a note that if/when python3-wx is updated, we should 
see if it's now possible to rename the source package to python-wx.



[...]


Okay, I'd be happy to try renaming the package to python-wx the next 
time I update python3-wx.



[...]


I realise I forgot to ask, but how could I go about renaming python3-wx 
to python-wx when I update? I also maintained python-wx, so I shouldn't 
need any extra permissions I don't think.


Uh, yeah, this is made more complex as we had a 'python-wx' source 
package (for the python2 bindings, now removed), and a separate 
'python3-wx' source package (for python3 bindings).


I guess what wants to happen is:

* (If you care about such things) Merge the python3-wx history into the 
python-wx packaging git repo (git merge --allow-unrelated-histories 
seems like it might be the right voodoo runes).


* Rename python3-wx.cygport to python-wx.cygport and update version or 
bump release.
 * When it comes to uploading the rebuilt packages, there's 
unfortunately (currently) a manual step involved (for me to) adjust the 
"allegiance" of the 'python3n-wx' install packages from the 'python3-wx' 
source package to 'python-wx', but I'll do that when needed (or maybe 
even get around to automating it this time...)

Re: Where have svt-av1 1.8.0-2 gone?

[Jon Turney via Cygwin-apps]

On 17/03/2024 01:43, Takashi Yano via Cygwin-apps wrote:

On Sun, 17 Mar 2024 10:06:31 +0900
Takashi Yano wrote:

On Sat, 16 Mar 2024 17:49:30 +
Jon Turney wrote:

On 16/03/2024 00:48, Takashi Yano via Cygwin-apps wrote:

On Sat, 16 Mar 2024 09:39:33 +0900
Takashi Yano wrote:

[...]


This expected:
1.8.0-1 -> 1.8.0-2 -> 2.0.0-1
libsvtav1(1.8.0-1) -> libsvtav1enc1(1.8.0-2) + libsvtav1dec0(1.8.0-2)
-> libsvt1enc1(1.8.0-2) + libsvtav1dec0(2.0.0-2)

However, this does not seem to work as I expected.


What unexpected thing happens?

I guess you only get one of libsvtav1enc1 or libsvtav1dec0 (since if
these both are marked "obsoletes: libsvtav1", to the dependency solver
that mean that either of can replace libsvtav1, and provides everything
that it provides.

So maybe the best solution is:

libsvtav1dec0_OBSOLETES=libsvtav1
libsvtav1dec0_REQUIRES=libsvtav1enc1

So libsvtav1 is replaced by both libsvtav1dec0 and libsvtav1enc1


Looks great!


My expectation was that both libsvtav1enc1(1.8.0-2) and libsvtav1dec0(1.8.0-2)
are installed for upgrading libsvtav1(1.8.0-1).

Instead, I found

1.8.0-2:
libsvtav1_CATEGORY="_obsolete"
libsvtav1_REQUIRES="libsvtav1enc1 libsvtav1dec0"
libsvtav1enc1_CONTENTS="usr/bin/cygSvtAv1Enc-1.dll"
libsvtav1dec0_CONTENTS="usr/bin/cygSvtAv1Dec-0.dll"


Yeah, this should work, but is not longer preferred because you end up
with an empty libsvtav1 hanging around forever...


works as expected.
Is it possible to change it like this now?


I've tweaked the existing dependencies based on my reasoning above.
Please let me know if this still isn't working right.


Thanks you very much!

Could you please also remove:
libsvtav1enc1_OBSOLETES=libsvtav1
because it seems that this conflicts with
libsvtav1dec0_OBSOLETES=libsvtav1
?


Oops. I obviously needed to do that, but forget. Then I did it, and 
forget to tell you that I'd done it.


Hopefully, that resolves the misbehavior you describe below.



I noticed that the following happen even with obove if
the package which requires libsvtav1 is installed.
At the first upgrade,
Uninstall libsvt1v1 1.8.0-1
Install libsvtav1dec0 1.8.0-2
Install libsvtav1enc1 1.8.0-2
that is as expected except for libsvtav1dec0 is not latest.

However, at the next upgrade (just run setup again),
Uninstall libsvtav1dec0 1.8.0-2
Install libsvtav1 1.8.0-1
Install libsvtav1dec0 2.0.0-1
happens. This causes conflict:
$ cygcheck -f /usr/bin/cygSvtAv1Dec-0.dll
libsvtav1-1.8.0-1
libsvtav1dec0-2.0.0-1

Im not sure why this happens.

Contrary to your idea,
libsvtav1enc1_OBSOLETES="libsvtav1"
libsvtav1enc1_REQUIRES="libsvtav1dec0"
the followings happen as expected.
Uninstall libsvtav1 1.8.0-1
Install libsvtav1dec0 2.0.0-1
Install libsvtav1enc1 1.8.0-2

Of cource,
libsvtav1dec0_OBSOLETES=libsvtav1
should be removed in this case.

What do you think?

Re: Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages)

[Jon Turney via Cygwin-apps]

On 02/04/2024 15:58, Takashi Yano via Cygwin-apps wrote:

On Tue, 2 Apr 2024 15:38:25 +0100
Jon Turney wrote:

On 01/04/2024 18:16, David Rothenberger via Cygwin-apps wrote:

On 3/30/2024 8:25 AM, Jon Turney wrote:

On 29/03/2024 18:32, David Rothenberger via Cygwin-apps wrote:

On 3/28/2024 10:50 AM, Jon Turney via Cygwin-apps wrote:

[...]

David,

Is it possible to update/rebuild rdiff-backup, which replies upon
the soon-to-be removed python36?

(Or indicate that you are no longer interested in maintaining this
package, which will probably lead to it's removal).


Please remove me as the maintainer from that package. I no longer use
it, and no longer have an environment for building packages for Cygwin.


No problem. Thanks for maintaining it in the past.

Is the same true for your other packages?

$ grep Rothenberger cygwin-pkg-maint | grep -v ORPHANED
cyrus-sasl   David Rothenberger
flac David Rothenberger
libao    David Rothenberger
libapr1  David Rothenberger
libaprutil1  David Rothenberger
libkate  David Rothenberger
libogg   David Rothenberger
librsync David Rothenberger
libtheora    David Rothenberger
libvorbis    David Rothenberger
rdiff-backup David Rothenberger
speex    David Rothenberger
speexdsp David Rothenberger
vorbis-tools David Rothenberger
which    David Rothenberger
whois    David Rothenberger


Yes, I'm afraid it is.


Done.  Thanks for all your work on these in the past.


Hi, I would like to take over the maintenance of:

flac David Rothenberger
libao    David Rothenberger
libogg   David Rothenberger
libtheora    David Rothenberger
libvorbis    David Rothenberger
speex    David Rothenberger
speexdsp David Rothenberger
vorbis-tools David Rothenberger

if anyone would not.



Thanks. I added these to your packages.

I generated missing packaging history repos for some of these from the 
CTM history.  Please let me know if there's any errors or if you'd like 
those removed.


I didn't check, but if any of these are no longer carried by recent 
linux distros, maybe think about if it's actually useful to keep on 
having a package for it...

Re: Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages)

[Jon Turney via Cygwin-apps]

On 01/04/2024 18:16, David Rothenberger via Cygwin-apps wrote:

On 3/30/2024 8:25 AM, Jon Turney wrote:

On 29/03/2024 18:32, David Rothenberger via Cygwin-apps wrote:

On 3/28/2024 10:50 AM, Jon Turney via Cygwin-apps wrote:

[...]

David,

Is it possible to update/rebuild rdiff-backup, which replies upon 
the soon-to-be removed python36?


(Or indicate that you are no longer interested in maintaining this 
package, which will probably lead to it's removal).


Please remove me as the maintainer from that package. I no longer use 
it, and no longer have an environment for building packages for Cygwin.


No problem. Thanks for maintaining it in the past.

Is the same true for your other packages?

$ grep Rothenberger cygwin-pkg-maint | grep -v ORPHANED
cyrus-sasl   David Rothenberger
flac David Rothenberger
libao    David Rothenberger
libapr1  David Rothenberger
libaprutil1  David Rothenberger
libkate  David Rothenberger
libogg   David Rothenberger
librsync David Rothenberger
libtheora    David Rothenberger
libvorbis    David Rothenberger
rdiff-backup David Rothenberger
speex    David Rothenberger
speexdsp David Rothenberger
vorbis-tools David Rothenberger
which    David Rothenberger
whois    David Rothenberger


Yes, I'm afraid it is.


Done.  Thanks for all your work on these in the past.

Please accept this virtual gold-plated solid 1/10th-scale pocket watch 
as a token of our appreciation!

Re: calm now runs on-demand

[Jon Turney via Cygwin-apps]

On 01/07/2017 15:22, Jon Turney wrote:

On 01/07/2017 15:14, Marco Atzeri wrote:

On 01/07/2017 15:54, Jon Turney wrote:

On 01/07/2017 06:18, Marco Atzeri wrote:

On 17/04/2017 13:34, Jon Turney wrote:


If you have shell access on sourceware, and make such changes, you can
force calm to run with '~cygwin-admin/bin/calm 
scan-(uploads|relarea)'.


calm now (finally) detects when changes have been made in the relarea 
via inotify, so this manual step is no longer required.


So, if you have shell access, and you make changes directly in the 
relarea, calm should now notice, reread it, and update the setup.ini 
package manifest automatically, without you needing to explicitly 
request that (or wait until the next scheduled rescan, if you can't 
request it due to the permission problem identified below...)



Jon,
I have shell access but I do not find calm anywhere.
I assume "~cygwin-admin" is more restricted than shell access.

As I did change to the relarea for gcc test, how to force the
update of setup.ini's ?


I think I have fixed the permissions, so this should work for you now.

Thanks for pointing out this problem.


May be I misunderstood how I should use it

matzeri@sourceware ~
$  /home/cygwin/bin/calm scan-relarea
/home/cygwin/bin/calm: line 13: kill: (14958) - Operation not permitted


No, that's me being dumb.  I guess I need to think some more about how 
to make this work for other users...

Re: RE: libxml2 and python not happy... solution downgrade libxml2

[Jon Turney via Cygwin]

On 20/05/2023 17:30, Jon Turney via Cygwin wrote:

On 10/05/2023 15:20, Jason Pyeron via Cygwin wrote:
I guess I will have to adopt the virt-manager package... please put it 
on my plate :(


Well, that wasn't quite the response I was expecting, but thanks very 
much for helping!


I have added 'virt-manager' to your packages.


So, cleaning up the final python2 bits, I got around back to looking at 
this again.  I've made minor updates to python-libvirt and virt-manager, 
which gets something which runs.


But it just sits there, apparently trying to connect to a local QEMU 
hypervisor I don't have, but that's what the previous, python2 version 
does as well...


I'm guessing that perhaps the only sensible way to run this on Cygwin is 
with the '--connect' option to a remote hypervisior.  Or maybe it's 
totally broken.



[...]

-Original Message-
From: Jon Turney 
Sent: Wednesday, May 10, 2023 10:05 AM
To: Jason Pyeron ; The Cygwin Mailing List 


Subject: Re: libxml2 and python not happy... solution downgrade libxml2

On 09/05/2023 23:33, Jason Pyeron via Cygwin wrote:

$ virt-manager
Traceback (most recent call last):
    File "/usr/share/virt-manager/virt-manager", line 35, in 
  from virtinst import util as util
    File "/usr/share/virt-manager/virtinst/__init__.py", line 18, in 


  from virtcli import CLIConfig as _CLIConfig
    File "/usr/share/virt-manager/virtcli/__init__.py", line 3, in 


  from .cliconfig import CLIConfig
    File "/usr/share/virt-manager/virtcli/cliconfig.py", line 24, in 


  import ConfigParser
ModuleNotFoundError: No module named 'ConfigParser'


[...]


#downgrade libxml2...

$ cygcheck -c libxml2 python27-libxml2
Cygwin Package Information
Package  Version    Status
libxml2  2.9.10-2   OK
python27-libxml2 2.9.10-2   OK

jpyeron@blackfat ~
$ ./test.py

jpyeron@blackfat ~
$ virt-manager


Right.  The real problem here is that virt-manager is still using
python2, which long past EOL, and is planned to be removed.

The current plan, per [1] is for virt-manager to become uninstallable
after this, and see if anyone complains.

If virt-manager is important to you, perhaps you could help us bring it
up to date?

[1] https://cygwin.com/pipermail/cygwin-apps/2023-April/042778.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: Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages)

[Jon Turney via Cygwin-apps]

On 24/03/2024 17:46, Jon Turney via Cygwin-apps wrote:

On 24/03/2024 17:31, Marco Atzeri via Cygwin-apps wrote:

On 24/03/2024 15:07, Jon Turney wrote:

On 24/09/2023 13:32, Jon Turney via Cygwin-apps wrote:

I assume you are OK with the removal of python 3.5 (EOL Sept 2020) 
and 3.6 (EOL Dec 2021)?


(I'm still dealing with cleaning up the final pieces of python27 
detritus, but these should hopefully be much smaller tasks)




nothing should depend from 3.5
not sure for 3.6


I've automated some of the analysis I was doing for python2 packages and 
the results are now available at [1].


So yeah, it looks like nothing uses 3.5.


I've removed some 3.4 detritus, and 3.5

Perhaps you can clarify the situation with python-pip: python-pip 
19.0.3-1, 19.1.1-1 and 19.2.3-1 are not evaluated are being removable, 
despite python35-pip being not needed anymore, as that source also 
produces python-pip-wheel, which is depended upon by 
python3{6,7,8,9}-virtualenv.


A similar situation exists with python-setuptools, python35-setuptools 
and python-setuptools-wheel.


(virtualenv also depends on python-wheel-wheel, but that tracks the 
latest version)


There are just a couple of packages using 3.6, I guess I'll ping the 
maintainers about those.


[1] https://cygwin.com/packages/reports/python_rebuilds.html


It looks like the situation with 3.6 is a bit more complex, as some 
things have a generic python3 dependency, rather than python36 as they 
should, so that report isn't complete.


I have some tools to correct those dependencies, so the situation should 
become clearer after I run those...

Re: Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages)

[Jon Turney via Cygwin-apps]

On 29/03/2024 18:32, David Rothenberger via Cygwin-apps wrote:

On 3/28/2024 10:50 AM, Jon Turney via Cygwin-apps wrote:

[...]

David,

Is it possible to update/rebuild rdiff-backup, which replies upon the 
soon-to-be removed python36?


(Or indicate that you are no longer interested in maintaining this 
package, which will probably lead to it's removal).


Please remove me as the maintainer from that package. I no longer use 
it, and no longer have an environment for building packages for Cygwin.


No problem. Thanks for maintaining it in the past.

Is the same true for your other packages?

$ grep Rothenberger cygwin-pkg-maint | grep -v ORPHANED
cyrus-sasl   David Rothenberger
flac David Rothenberger
libaoDavid Rothenberger
libapr1  David Rothenberger
libaprutil1  David Rothenberger
libkate  David Rothenberger
libogg   David Rothenberger
librsync David Rothenberger
libtheoraDavid Rothenberger
libvorbisDavid Rothenberger
rdiff-backup David Rothenberger
speexDavid Rothenberger
speexdsp David Rothenberger
vorbis-tools David Rothenberger
whichDavid Rothenberger
whoisDavid Rothenberger

Re: [PATCH setup] Fix Chinese Help Message fall in dead loop .

[Jon Turney via Cygwin-apps]

On 29/03/2024 01:40, 赵伟 via Cygwin-apps wrote:

---
  libgetopt++/include/getopt++/DefaultFormatter.h | 1 +
  1 file changed, 1 insertion(+)

diff --git a/libgetopt++/include/getopt++/DefaultFormatter.h 
b/libgetopt++/include/getopt++/DefaultFormatter.h
index ee2397f5..43c253a5 100644
--- a/libgetopt++/include/getopt++/DefaultFormatter.h
+++ b/libgetopt++/include/getopt++/DefaultFormatter.h
@@ -64,6 +64,7 @@ class DefaultFormatter {
 {
   // TODO: consider using a line breaking strategy here.
   int pos = helpmsg.substr(0,h_len).find_last_of(" ");
+ if(!pos)break; /*In Chinese Helpmsg,may has no space,so pos ==0,and 
code will fall in dead loop here*/
   theStream  helpmsg.substr(0,pos)
  std::endl  std::string (o_len, ' ');
   helpmsg.erase (0,pos+1);
--
2.43.0


Thanks very much for bug report, and the patch!

Did you actually try this?  When I tested this it didn't help, as 
std::string::substr() returns std::string::npos (numerically, -1), not 0 
when it cannot find a match.


So, I applied a slightly modified version of the patch.

Please try https://cygwin.com/setup/setup-2.931-1-g0ee13c.x86_64.exe

Re: Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages)

[Jon Turney via Cygwin-apps]

On 24/03/2024 17:46, Jon Turney via Cygwin-apps wrote:

On 24/03/2024 17:31, Marco Atzeri via Cygwin-apps wrote:

On 24/03/2024 15:07, Jon Turney wrote:

On 24/09/2023 13:32, Jon Turney via Cygwin-apps wrote:

I assume you are OK with the removal of python 3.5 (EOL Sept 2020) 
and 3.6 (EOL Dec 2021)?


(I'm still dealing with cleaning up the final pieces of python27 
detritus, but these should hopefully be much smaller tasks)



nothing should depend from 3.5
not sure for 3.6


I've automated some of the analysis I was doing for python2 packages and 
the results are now available at [1].


So yeah, it looks like nothing uses 3.5.

There are just a couple of packages using 3.6, I guess I'll ping the 
maintainers about those.


[1] https://cygwin.com/packages/reports/python_rebuilds.html

David,

Is it possible to update/rebuild rdiff-backup, which replies upon the 
soon-to-be removed python36?


(Or indicate that you are no longer interested in maintaining this 
package, which will probably lead to it's removal).


Thanks.

Re: Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages)

[Jon Turney via Cygwin-apps]

On 24/03/2024 17:46, Jon Turney via Cygwin-apps wrote:

On 24/03/2024 17:31, Marco Atzeri via Cygwin-apps wrote:

On 24/03/2024 15:07, Jon Turney wrote:

On 24/09/2023 13:32, Jon Turney via Cygwin-apps wrote:

I assume you are OK with the removal of python 3.5 (EOL Sept 2020) 
and 3.6 (EOL Dec 2021)?


(I'm still dealing with cleaning up the final pieces of python27 
detritus, but these should hopefully be much smaller tasks)



nothing should depend from 3.5
not sure for 3.6


I've automated some of the analysis I was doing for python2 packages and 
the results are now available at [1].


So yeah, it looks like nothing uses 3.5.

There are just a couple of packages using 3.6, I guess I'll ping the 
maintainers about those.


[1] https://cygwin.com/packages/reports/python_rebuilds.html


Ake,

Is it possible to update/rebuild libftdi1, which only publishes python 
bindings for the soon-to-be removed python36?


(Or indicate that you are no longer interested in maintaining this 
package, which will probably lead to it's removal).


Thanks.

Re: Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages)

[Jon Turney via Cygwin-apps]

On 27/03/2024 21:18, Brian Inglis via Cygwin-apps wrote:

On 2024-03-27 14:07, Jon Turney via Cygwin-apps wrote:

On 24/03/2024 18:51, Brian Inglis via Cygwin-apps wrote:

On 2024-03-24 11:46, Jon Turney via Cygwin-apps wrote:

On 24/03/2024 17:31, Marco Atzeri via Cygwin-apps wrote:

On 24/03/2024 15:07, Jon Turney wrote:

On 24/09/2023 13:32, Jon Turney via Cygwin-apps wrote:

[...]


Are they supposed to migrate to some alternate bindings maybe 
available from a separate repo? Or are they just out of luck?


SOL! Dropped them in 1.52, probably why 1.31.0..1.51.0 are hanging around.


Nice :S

Feel free to purge as appropriate, or tell me what to add to cygport, 
hints, etc!


So, the long list of source versions will hopefully be reduced in the 
fullness of time...


Could I just add to nghttp2.cygport that nghttp2 obsoletes 
python{2{,7},3{,6,7,8,9}}-nghttp2?
Does this have to remain in the cygport forever to avoid keeping nghttp2 
vx.x.x around?


You could, but that's probably not the correct thing to do unless you 
really, really want to forcibly uninstall those packages for anyone who 
has installed them, which seems like unnecessary breakage.


I don't think you have to do anything.  There's nothing "wrong" here.

If it really offends your sense of aesthetics, I suggest you just expire 
some subset of the old versions using the vault command [1].


[1] https://cygwin.com/package-upload.html#deleting

Re: Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages)

[Jon Turney via Cygwin-apps]

On 24/03/2024 18:51, Brian Inglis via Cygwin-apps wrote:

On 2024-03-24 11:46, Jon Turney via Cygwin-apps wrote:

On 24/03/2024 17:31, Marco Atzeri via Cygwin-apps wrote:

On 24/03/2024 15:07, Jon Turney wrote:

On 24/09/2023 13:32, Jon Turney via Cygwin-apps wrote:


[...]


Not sure why my source package nghttp2 shows python install packages, 
when they were dropped after 1.43 IIRC: build deps no longer include 
python/-devel?


If you haven't taken any specific action to retire the python-3x-nghttp2 
packages, the existing ones will continue to be available indefinitely.


Firstly, it seems there's a question here about what are upstream's 
plans for the users of the python bindings for this library.


Are they supposed to migrate to some alternate bindings maybe available 
from a separate repo? Or are they just out of luck?


And why does that nghttp2 source package show a dozen archived source 
versions, when its installed packages have only three?


The simple answer to that is we retain the source package for all 
available install packages.  This seems essential for an open-source 
project.


Now, as to why there are so many installable packages, this is the 
intersection of a couple of unfortunate issues.


1. 'python3-nghttp2' is an "old-style" obsoletion package, where the 
package exists, but is of category _obsolete, and requires the 
replacement package.


These are terrible, because we can't remove the obsolete package because 
that's what records the fact of obsoletion.


I actually have some code for calm to internally convert that to a 
"new-style" obsoletion, where the replacement package itself records the 
obsoletion (i.e. python36-nghttp2 obsoletes: python3-nghttp2), which it 
continues to remember about even after the package which contains that 
obsoleting is expired.


Once that's done, all those "old-style" obsoletion packages lingering in 
our package repository can be removed (along with their corresponding 
source).


But I still need to do some testing before that can be deployed.

(However, all that's probably not what's actually wanted with python 
packages: it's preferable to have python3-foo be a virtual package which 
pulls in python3x-foo, where python3x is the current python, so that 
scripted installs can be written which ask for python3 and python3-foo 
and continue to work while x changes...)


2. We haven't purged old python versions for a long time, so e.g the 
python36 binding packages are still lingering.


As you can see, I'm just now getting around to looking at expiring 
python36, which eventually should lead to python36-nghttp2 being expired 
(insert some observations about how it doesn't have to be me doing these 
things here)...


Feel free to purge as appropriate, or tell me what to add to cygport, 
hints, etc!


So, the long list of source versions will hopefully be reduced in the 
fullness of time...

Re: Mirror announcement

[Jon Turney via Cygwin]

On 26/03/2024 14:10, Christopher Meng via Cygwin wrote:
Hi, This mirror is actually behind CDN which is "global", so I'm not 
sure if you can handle such of mirror on your end for redirect.


OK, I'll leave the location unspecified.

I gave it a brief test with our setup program and things seem to work 
correctly (which shouldn't be surprising since it just uses the wininet

API to fetch files).

However, it seem our mirror checking script seems to get told "403 
Forbidden" when it tries to check if you are up to date.


Can you tell me (privately, if you like) what User-Agent: it should 
present? Or suggest another mechanism to allow it access?



--
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: Mirror announcement

[Jon Turney via Cygwin]

On 26/03/2024 04:59, Christopher Meng via Cygwin wrote:
Hi, I have a Cygwin mirror available at: Contact: i...@cicku.me Mirror URL: 
https://mirrors.cicku.me/cygwin Please consider this as an official 
request to add to the mirror list. Thank you!


Thanks for providing a mirror.

Can you give the approximate geographical location in a similar format 
to our existing list [1]?


[1] https://cygwin.com/mirrors.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: Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages)

[Jon Turney via Cygwin-apps]

On 24/03/2024 17:31, Marco Atzeri via Cygwin-apps wrote:

On 24/03/2024 15:07, Jon Turney wrote:

On 24/09/2023 13:32, Jon Turney via Cygwin-apps wrote:

I assume you are OK with the removal of python 3.5 (EOL Sept 2020) and 
3.6 (EOL Dec 2021)?


(I'm still dealing with cleaning up the final pieces of python27 
detritus, but these should hopefully be much smaller tasks)




nothing should depend from 3.5
not sure for 3.6


I've automated some of the analysis I was doing for python2 packages and 
the results are now available at [1].


So yeah, it looks like nothing uses 3.5.

There are just a couple of packages using 3.6, I guess I'll ping the 
maintainers about those.


[1] https://cygwin.com/packages/reports/python_rebuilds.html

Python 3.5 and 3.6 removal (was Re: Bonfire of the Packages)

[Jon Turney via Cygwin-apps]

On 24/09/2023 13:32, Jon Turney via Cygwin-apps wrote:


Generally, we have a large number of old, unmaintained packages.

The policy [1] has always been "Packages without an active maintainer 
may be pulled from the distribution.", but not actively enforced (in 
fact prior to 2022, this used to say "are pulled", but I moderated the 
statement, just to reflect reality).


I guess this needs to also mention upstream EOL status as a criteria.

[...]


Here's my personal list:

* python

After python27 (the last python2 version, which has been sun-setted 
since 2020), both python36 and python37 should be removed (after 
rebuilding any python-* package which don't currently provide 3.8, 3.9 
versions)

 Marco,

I assume you are OK with the removal of python 3.5 (EOL Sept 2020) and 
3.6 (EOL Dec 2021)?


(I'm still dealing with cleaning up the final pieces of python27 
detritus, but these should hopefully be much smaller tasks)

Re: Fwd: Updating cygwin "libnfs" package ?

[Jon Turney via Cygwin-apps]

On 22/03/2024 16:08, Roland Mainz via Cygwin-apps wrote:

Hi!



I'd like to take ownership of the Cygwin "libnfs" package (see email
below, the package is old and has bugs related to NFSv4.*) ...
... how do we proceed ? Should I send a patch here, or what do I have to do ?


[1] should explain this (could probably be improved).

A patch against the packaging repo would be a good place to start.

[1] https://cygwin.com/packaging-contributors-guide.html#adopt

Re: [ITP] afflib 3.7.20-1

[Jon Turney via Cygwin-apps]

On 21/03/2024 09:04, Christian Franke via Cygwin-apps wrote:

On Wed, 6 Mar 2024 23:26:05 +0100, Christian Franke wrote:

Jon Turney wrote:
...


be added only when needed for new not backward compatible releases. 
The upstream afflib project is mostly idling, so I don't expect any 
new major lib versions in the near future.


If course, I could rename it to libafflib0 if desired.


As far as I know, there is no cost for doing this, and it saves grief 
if upstream ever bumps the soversion.


Also, it's probably best to explicitly list the filename with 
soversion in the CONTENTS, so that if upstream ever does change the 
soversion, it will be detected as a packaging failure, rather than 
producing a package with a mismatch between the soversion in it's 
name and in it's contents.


Good point, new cygport file is attached.


Any further issues with this ITP?


Seems good.

I added this to your packages.

gcab 1.6-1

[Jon Turney via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* gcab-1.6-1
* gcab-debuginfo-1.6-1
* girepository-gcab1.0-1.6-1
* libgcab-devel-1.6-1
* libgcab-doc-1.6-1
* libgcab1.0_0-1.6-1
* vala-gcab1.0-1.6-1

A GObject library to create cabinet files



-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

Re: Cannot downgrade gcc 13 or 12 to 11.4.0-1

[Jon Turney via Cygwin]

On 14/03/2024 18:34, Thomas Hedden via Cygwin wrote:
I installed a test version of gcc and cannot revert to an earlier, 
non-test version. Here are the latest versions listed in the setup routine:


11.4.0-1
12.3.1+20240202-0.1 (Test)
13.2.1+20240203-0.1 (Test)

(there are some even older ones, but I want 11.4.0-1.)

$ gcc --version
gcc (GCC) 13.2.1 20240203

[...]

$ gcc -o hello.exe hello.c
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: 
cannot find -lintl: No such file or directory
/usr/lib/gcc/x86_64-pc-cygwin/13/../../../../x86_64-pc-cygwin/bin/ld: 
cannot find -liconv: No such file or directory

collect2: error: ld returned 1 exit status


This seems like a problem with this test version of gcc.  I guess maybe 
it now links with intl and iconv by default in the specsfile, which will 
require the corresponding devel packages to be installed, but it doesn't 
depend on them.


This seems like a mistake. (I think libstdc++ will now require these, 
but they shouldn't be needed just for c compilation.)


So, I can't compile anything. I don't need the test version to work, I 
just want to downgrade to 11.4.0-1. However, if I uninstall the test 
version, and then try to install 11.4.0-1, I get the following message:


Problem 1/1
package gcc-g++-11.4.0-1 requires gcc11, but none of the providers can 
be installed

Solution 1/2
   - allow replacement of gcc-core-13.2.1+20240203-0.1 with 
gcc-core-11.4.0-1

Solution 2/2 (default)
   - do not ask to lock gcc-g++-11.4.0-1

What should I do?


Sorry that this message isn't very clear, and this situation is not 
handled well by setup.


You need to downgrade all the various gcc packages in step.

Which you can do manually, but perhaps the easiest way to do this is to 
select the 'Sync' option at the top-right, which will downgrade all test 
packages.



--
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: Where have svt-av1 1.8.0-2 gone?

[Jon Turney via Cygwin-apps]

On 16/03/2024 00:48, Takashi Yano via Cygwin-apps wrote:

On Sat, 16 Mar 2024 09:39:33 +0900
Takashi Yano wrote:

[...]


This expected:
1.8.0-1 -> 1.8.0-2 -> 2.0.0-1
libsvtav1(1.8.0-1) -> libsvtav1enc1(1.8.0-2) + libsvtav1dec0(1.8.0-2)
-> libsvt1enc1(1.8.0-2) + libsvtav1dec0(2.0.0-2)

However, this does not seem to work as I expected.


What unexpected thing happens?

I guess you only get one of libsvtav1enc1 or libsvtav1dec0 (since if 
these both are marked "obsoletes: libsvtav1", to the dependency solver 
that mean that either of can replace libsvtav1, and provides everything 
that it provides.


So maybe the best solution is:

libsvtav1dec0_OBSOLETES=libsvtav1
libsvtav1dec0_REQUIRES=libsvtav1enc1

So libsvtav1 is replaced by both libsvtav1dec0 and libsvtav1enc1


My expectation was that both libsvtav1enc1(1.8.0-2) and libsvtav1dec0(1.8.0-2)
are installed for upgrading libsvtav1(1.8.0-1).

Instead, I found

1.8.0-2:
libsvtav1_CATEGORY="_obsolete"
libsvtav1_REQUIRES="libsvtav1enc1 libsvtav1dec0"
libsvtav1enc1_CONTENTS="usr/bin/cygSvtAv1Enc-1.dll"
libsvtav1dec0_CONTENTS="usr/bin/cygSvtAv1Dec-0.dll"


Yeah, this should work, but is not longer preferred because you end up 
with an empty libsvtav1 hanging around forever...



works as expected.
Is it possible to change it like this now?


I've tweaked the existing dependencies based on my reasoning above. 
Please let me know if this still isn't working right.

Re: Where have svt-av1 1.8.0-2 gone?

[Jon Turney via Cygwin-apps]

On 15/03/2024 13:31, Takashi Yano via Cygwin-apps wrote:

On Fri, 15 Mar 2024 13:14:49 +
Jon Turney wrote:

On 15/03/2024 09:15, Takashi Yano via Cygwin-apps wrote:

I uploaded svt-av1 1.8.0-2 few hours ago, however
it does not appear on the mirror servers so far.

Was anything wrong?


Sorry, things will be a little slower than usual (uploads may take up to
4 hours to get processed) until I get around to fixing up things for
some changes made on sourceware to provide better isolation.

I see that this upload was declined because svt-av1 2.0.0 already exists.

I guess you really want to upload it, as it provides a different set of
shared libraries to 2.0.0. Please let me know.


1.8.0-2 is necessary for changing packaging.


I see. I configured the necessary exception, sot his should be all 
uploaded now.



1.8.0-1: cygSvtAv1Enc-1.dll and cygSvtAv1Dec-0.dll are in libsvtav1,
However,
2.0.0-1: cygSvtAv1Enc-2.dll and cygSvtAv1Dec-0.dll are built.
So, I made
1.8.0-2: cygSvtAv1Enc-1.dll is in libsvtav1enc1 and cygSvtAv1Dec-0 is in 
libsvtav1dec0
  both obsolete libsvtav1
for migration.


Hmm... maybe your thinking here is not quite clear.

You cannot assume that an installation is upgraded often enough that it 
receives every version of every package.


(And in this case, where 1.8.0-2 appears in the repository after 2.0.0 
does, it's not going to get automatically installed anywhere)


So, as a principle, every version of a package must contain complete 
instructions for upgrading to it.



In this particular case, that means the cygport should contain

libsvtav1dec0_OBSOLETES=libsvtav1

for as long as the package produces libsvtav1dec0.


(In fact, I think this all happens to work as desired because libsvtav1 
is also obsoleted by the non-longer produced libsvtav1enc1, but I just 
point this out for completeness)



The first step I did was wrong, i.e. I should not have package which
includes dlls whose versions are different. Sorry.


No problem.  Mistakes happen.

Re: Unable to 'git push' to /git/cygwin-packages/*

[Jon Turney via Cygwin-apps]

On 15/03/2024 09:00, Mark Geisert via Cygwin-apps wrote:

On 3/14/2024 9:07 AM, Jon Turney via Cygwin-apps wrote:

On 14/03/2024 15:39, Mark Geisert via Cygwin-apps wrote:

On 3/14/2024 2:42 AM, Jon Turney via Cygwin-apps wrote:

On 14/03/2024 05:45, Mark Geisert via Cygwin-apps wrote:

Hi folks,
I'm getting the error:

fatal: remote error: service not enabled: /git/cygwin-packages/sshfs

when I attempt 'git push' to that repository.  The same happens 
with all the repositories for my packages.  It's been this way for 
a couple days at least.


Have I forgotten some step in the connection at my end?  I'm 
running ssh-agent.



[...]

What is the repository URL you are trying to push to (git remote -v)?


/usr/src/upstaging/sshfs git remote -v
origin git://cygwin.com/git/cygwin-packages/sshfs (fetch)
origin git://cygwin.com/git/cygwin-packages/sshfs (push)


This maybe looks like pilot error.

We don't allow pushing using the git:// protocol (since this protocol 
doesn't do any authorization, pushes with a it are very rarely enabled)



I suggest you need to do

   git push 
ssh://cygwin-rdbxbdvo6bxqt0dzr+a...@public.gmane.org:git/cygwin-packages/sshfs


to push successfully.

If that works, I suggest you memorialize that by doing

   git remote set-url origin --push 
ssh://cygwin-rdbxbdvo6bxqt0dzr+a...@public.gmane.org:git/cygwin-packages/sshfs


which will cause git to automatically use the ssh URL with a simple 
'git push'.


With a minor correction ("/git" instead of "git" in the URL) this works 
fine.  I've made the git config change for all my projects.


Oops. Yes. Of course that's right, my mistake.

Glad to hear that things are working again for you!

Re: Where have svt-av1 1.8.0-2 gone?

[Jon Turney via Cygwin-apps]

On 15/03/2024 09:15, Takashi Yano via Cygwin-apps wrote:

I uploaded svt-av1 1.8.0-2 few hours ago, however
it does not appear on the mirror servers so far.

Was anything wrong?


Sorry, things will be a little slower than usual (uploads may take up to 
4 hours to get processed) until I get around to fixing up things for 
some changes made on sourceware to provide better isolation.


I see that this upload was declined because svt-av1 2.0.0 already exists.

I guess you really want to upload it, as it provides a different set of 
shared libraries to 2.0.0. Please let me know.

Re: Unable to 'git push' to /git/cygwin-packages/*

[Jon Turney via Cygwin-apps]

On 14/03/2024 15:39, Mark Geisert via Cygwin-apps wrote:

On 3/14/2024 2:42 AM, Jon Turney via Cygwin-apps wrote:

On 14/03/2024 05:45, Mark Geisert via Cygwin-apps wrote:

Hi folks,
I'm getting the error:

fatal: remote error: service not enabled: /git/cygwin-packages/sshfs

when I attempt 'git push' to that repository.  The same happens with 
all the repositories for my packages.  It's been this way for a 
couple days at least.


Have I forgotten some step in the connection at my end?  I'm running 
ssh-agent.


This is probably due to some recent changes made on sourceware. 
Apologies for the inconvenience.


I forget to ask when was the last time this worked for you, so maybe 
assuming this is related is premature.



What is the repository URL you are trying to push to (git remote -v)?


/usr/src/upstaging/sshfs git remote -v
origin git://cygwin.com/git/cygwin-packages/sshfs (fetch)
origin git://cygwin.com/git/cygwin-packages/sshfs (push)


This maybe looks like pilot error.

We don't allow pushing using the git:// protocol (since this protocol 
doesn't do any authorization, pushes with a it are very rarely enabled)



I suggest you need to do

  git push ssh://cyg...@cygwin.com:git/cygwin-packages/sshfs

to push successfully.

If that works, I suggest you memorialize that by doing

  git remote set-url origin --push 
ssh://cyg...@cygwin.com:git/cygwin-packages/sshfs


which will cause git to automatically use the ssh URL with a simple 'git 
push'.




You might like to review the last time we discussed this at [1]

(Note that's slightly different, as to push to cygwin-apps repositories 
you must present the key as yourusern...@cygwin.com, whereas for 
cygwin-packages repositories, you can present the key as 
cyg...@cygwin.com. There are just different due to historical reasons.)


[1] https://cygwin.com/pipermail/cygwin-apps/2021-September/041539.html

Re: Unable to 'git push' to /git/cygwin-packages/*

[Jon Turney via Cygwin-apps]

On 14/03/2024 05:45, Mark Geisert via Cygwin-apps wrote:

Hi folks,
I'm getting the error:

fatal: remote error: service not enabled: /git/cygwin-packages/sshfs

when I attempt 'git push' to that repository.  The same happens with all 
the repositories for my packages.  It's been this way for a couple days 
at least.


Have I forgotten some step in the connection at my end?  I'm running 
ssh-agent.


This is probably due to some recent changes made on sourceware. 
Apologies for the inconvenience.


What is the repository URL you are trying to push to (git remote -v)?

osslsigncode 2.8-1

[Jon Turney via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* osslsigncode-2.8-1
* osslsigncode-debuginfo-2.8-1

Platform-independent tool for Authenticode signing of
PE(EXE/SYS/DLL/etc), CAB and MSI files - uses OpenSSL and libcurl.
It also supports timestamping (Authenticode and RFC3161).



-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

Re: [cygport] enabling a replacement for "objdump -d -l"

[Jon Turney via Cygwin-apps]

On 11/03/2024 19:35, ASSI via Cygwin-apps wrote:

Jon Turney via Cygwin-apps writes:

[...]



Fifty lines of perl with no comments! This is just line noise to me
unless I spend lots of time staring at it :)


That's what you get from an experiment that went rather more well than
planned.


Seriously, this should at least say "I'm running objdump -Wl to dump
out the .debug_line section containing DWARF XYZ information.

Then maybe some comments about what assumptions it's making about the
human-readable output it's parsing.


So you're asking for a manpage, really.  Should be doable with enough
round tuits.


Well, that would be nice too, but there is is difference between 
describing what it does and describing how it does what it does.


But I'm not being oblique here. I really do want comments.

I'm not sure what's so astounding about the suggestion that a fifty line 
script should have some comments in it that you can't believe I mean 
that literally...


[...]

What this line is doing is obvious, the rest of this block, not so much.


Nothing to see here, move along… :-P


...

[...]

Since the helper script will be installed, it could be made a boolean.


Out of habit grown over decades, I always keep an escape hatch for using
local (modified) copies in such scripts.


Well, OK.  This is less useful to people who actually want to use it, 
though, requiring them to know that 
"DWARF_PARSE=/usr/share/cygport/tools/dwarf-parse.pl" is the right 
incantation.


Perhaps "DWARF_PARSE=1" could be a shorthand for that?

Re: [PATCH cygport] Use correct wording if only one package is announced

[Jon Turney via Cygwin-apps]

On 23/02/2024 11:16, Christian Franke via Cygwin-apps wrote:

Brian Inglis via Cygwin-apps wrote:

On 2024-02-21 07:25, Christian Franke via Cygwin-apps wrote:

Change variable name from $s to $has or $s_have as variable $s usually 
implies only the plural letter s or nothing; e.g.

...
+    local has="s have"
+
+    [ $pkg_count != 1 ] || has=" has"
...
+The following package${has} been uploaded to the Cygwin distribution:
...


Agree - new patch attached.


Applied. Thanks!

Re: [PATCH cygport] Fix variable expansion in error message of embedded SMTP perl script

[Jon Turney via Cygwin-apps]

On 23/02/2024 12:09, Christian Franke via Cygwin-apps wrote:

Harmless bug ...



Applied. Thanks.

Re: [PATCH cygport] Add repro-check command

[Jon Turney via Cygwin-apps]

On 01/03/2024 19:16, Christian Franke via Cygwin-apps wrote:

Christian Franke wrote:
This could be used to check whether a package is possibly 
reproducible. Then it could make sense to add a reasonable 
SOURCE_DATE_EPOCH value to the cygport file.



[...]


An enhanced version of the patch is attached. The build and diff could 
now be run also individually and the diff report includes individual 
files from the packages.


As a side effect, this enables another use case: Check whether changes 
to cygport only change the expected files.


$ cygport project.cygport all repro-check
...
*** Info: Rebuild produced identical packages



Applied. Thanks!

Re: [PATCH cygport] dodoc: Skip a file if a compressed version already exists

[Jon Turney via Cygwin-apps]

On 01/03/2024 13:13, Christian Franke via Cygwin-apps wrote:
It IMO makes sense to compress large and rarely viewed doc files like 
change logs. This seems to be common practice on Debian etc.


With current cygport, the following results in ChangeLog and 
ChangeLog.gz in the docdir:


src_install()
{
   ...
   dodoc ChangeLog
   gzip -9 -n "${D}/usr/share/doc/${PN}/ChangeLog"
}


Uh, I don't quite see how this patch will change the behavior of this 
fragment.


Even more confusing, why isn't this already doing what you want? Unless 
you specify -k/--keep to gzip, the input file is removed, right?



The attached patch fixes this and also adds some missing documentation.


I applied the documentation change as that is obviously needed.

Re: [PATCH cygport] Modify origsrc timestamp in patch files if SOURCE_DATE_EPOCH is used

[Jon Turney via Cygwin-apps]

On 28/02/2024 15:54, Christian Franke via Cygwin-apps wrote:
Found during testing of 'repro-check' patch with getent-2.18.90-5 source 
package.


This patch also removes the requirement to set TZ=UTC before patches are 
generated.




Applied, but the commentary could stand to be clearer about the issue.

I guess this we now fix both the orig file and modified file timestamps 
in the patch file, as the orig timestamp may also vary.

Re: [PATCH cygport] Add customization support for announce command

[Jon Turney via Cygwin-apps]

On 23/02/2024 11:23, Christian Franke via Cygwin-apps wrote:

Christian Franke wrote:
The email generated by the cygport announce command is useful, but 
actual use cases are somewhat limited due to the hard-coded email 
submission.


The attached patch adds more flexibility. The patch is on top of the 
"Use correct wording if only one package is announced" patch.


Slightly changed patch attached. Also adjusted to new version of "Use 
correct wording if only one package is announced" patch.




[...]

Thanks for this.


Possible (better?) alternative names for the new settings:
ANNOUNCEMENT_EDITOR
ANNOUNCEMENT_MAILER


Hmmm... I think "ANNOUNCE_EDITOR" and "ANNOUNCE_MAILER" would be
the best for clarity and conciseness.


-From: ${SMTP_SENDER}
-To: cygwin-annou...@cygwin.com
+${SMTP_SENDER:+From: ${SMTP_SENDER}
+}To: cygwin-annou...@cygwin.com
 Date: $(date -R --date=${msgat})
-Message-Id: <$(date "+%Y%m%d%H%M%S.$$" --date=${msgat})-1-$(echo ${SMTP_SENDER} | sed 
's|.*<\(.*\)>.*|\1|')>
+Message-Id: <$(date "+%Y%m%d%H%M%S.$$" --date=${msgat})-1-$(echo 
${SMTP_SENDER:-cygport} | sed 's|.*<\(.*\)>.*|\1|')>
 Subject: ${NAME} ${PVR}


Can you also explain what this is doing in the commit message, since 
it's not immediately apparent.

Re: [PATCH cygport] Add more checks of SOURCE_DATE_EPOCH

[Jon Turney via Cygwin-apps]

On 26/02/2024 19:53, Christian Franke via Cygwin-apps wrote:



Would it not make more sense to just re-export it if set?


If the cygport file decides to set but not export it, there is possibly 
no need to do it. An example is smartmontools.cygport which passes the 
unexported variable as a parameter to configure.


Ok, but exporting it is harmless there, right?

(so that commands like "SOURCE_DATE_EPOCH=something cygport foo" work 
as expected?)




Would make no difference as the 'VAR=val CMD...' syntax already exports 
the variable to the CMD:


$ unset FOO; FOO=bar sh -c 'sh -c "sh -c printenv\ FOO"'
bar


Ah, right.

So you seem to be saying that the only situation where it's set but not 
exported is where it's set in the cygport.


So we're just making people (need to remember to) explicitly write 
"export SOURCE_DATE_EPOCH" in their cygport where needed?

Re: [PATCH cygport] pkg_info.cygpart: Do not detect dependencies on itself in ruby package

[Jon Turney via Cygwin-apps]

On 16/02/2024 12:51, Daisuke Fujimura via Cygwin-apps wrote:

Attempting to create a package for ruby-3.3, but it fails when trying
to detect a dependency on itself.


Thanks for this patch.

Can you clarify what the "failure" is here?


To avoid this, skip them if the target is `ruby`.


The second hunk seems like a removes the dependency on ruby_xy for the 
ruby package, which also provides ruby_xy.


Historically, we've allowed self-dependencies like this, because they 
seem to be benign, although it seems like we could do with some generic 
code to suppress them


(e.g. cygport also ends up generating cygwin-debuginfo with a dependency 
on itself, which is harmless but could be suppressed)

Re: Problem with git on cygwin.com?

[Jon Turney via Cygwin-apps]

On 09/03/2024 16:15, Marco Atzeri via Cygwin-apps wrote:

On 09/03/2024 17:10, Jon Turney wrote:

On 09/03/2024 15:55, Marco Atzeri via Cygwin-announce wrote:

I start to see

$ git pull
cygwin-rdbxbdvo6bxqt0dzr+a...@public.gmane.org: Permission denied 
(publickey).

fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.


Has the configuration been modified ?


Probably.

What is the repository URL you are trying to fetch from (git remote -v)



last one
ssh://cygwin-rdbxbdvo6bxqt0dzr+a...@public.gmane.org/git/cygwin-packages/xxhash.git


Thanks.

Overseers have fixed this issue. Thanks for reporting it!

Re: Problem with git on cygwin.com?

[Jon Turney via Cygwin-apps]

On 09/03/2024 15:55, Marco Atzeri via Cygwin-announce wrote:

I start to see

$ git pull
cyg...@cygwin.com: Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.


Has the configuration been modified ?


Probably.

What is the repository URL you are trying to fetch from (git remote -v)

Updated: setup (2.931)

[Jon Turney via Cygwin]

A new version of Setup (2.931) has been uploaded to:

 https://cygwin.com/setup-x86_64.exe  (64 bit version)
 https://cygwin.com/setup-x86.exe (32 bit version)

Changes compared to 2.930:

- Fix inability of 32-bit setup to retrieve anything from the Internet. 
Oops. (a regression in 2.930)

  Addresses: https://cygwin.com/pipermail/cygwin/2024-February/255373.html

- Updated translations


Replies to this message are not the place for setup feature requests.

For instructions on obtaining and building the source code for setup, 
see https://sourceware.org/cygwin-apps/setup.html


Please send bug reports, as usual, to the public mailing list 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

Updated: setup (2.931)

[Jon Turney]

A new version of Setup (2.931) has been uploaded to:

 https://cygwin.com/setup-x86_64.exe  (64 bit version)
 https://cygwin.com/setup-x86.exe (32 bit version)

Changes compared to 2.930:

- Fix inability of 32-bit setup to retrieve anything from the Internet. 
Oops. (a regression in 2.930)

  Addresses: https://cygwin.com/pipermail/cygwin/2024-February/255373.html

- Updated translations


Replies to this message are not the place for setup feature requests.

For instructions on obtaining and building the source code for setup, 
see https://sourceware.org/cygwin-apps/setup.html


Please send bug reports, as usual, to the public mailing list cygwin AT 
cygwin DOT com.

--
 *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

Re: Signature files missing

[Jon Turney via Cygwin]

On 09/03/2024 00:32, dave--- via Cygwin wrote:



.sig files seem to have gone missing from (at least some) mirrors.

e.g. https://mirrors.kernel.org/sourceware/cygwin/x86_64/



Thanks for reporting this.

This was unfortunately broken as a consequence of some changes on 
sourceware.  This is fixed now, so the signatures should appear on 
mirrors again when they next update.


Sorry for the inconvenience.


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

[PATCH setup 16/16] Add beginnings of a command line installation tool

[Jon Turney via Cygwin-apps]

At the moment, all this can do is retrieve setup.ini from a selected
mirror and parse it.
---
 Makefile.am|  22 +-
 cli/cyclops.cc | 186 +
 2 files changed, 207 insertions(+), 1 deletion(-)
 create mode 100644 cli/cyclops.cc

diff --git a/Makefile.am b/Makefile.am
index 6ae5dd6..5813e1a 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -35,7 +35,10 @@ AM_CPPFLAGS = -D__USE_MINGW_ANSI_STDIO=1 
-D_FILE_OFFSET_BITS=64 -DLZMA_API_STATI
 inilex_CXXFLAGS:=-Wno-sign-compare
 iniparse_CXXFLAGS:=-Wno-free-nonheap-object
 
-noinst_PROGRAMS = @SETUP@$(EXEEXT) inilint
+noinst_PROGRAMS = \
+   @SETUP@$(EXEEXT) \
+   inilint \
+   cyclops
 
 noinst_LTLIBRARIES = \
libsetupcore.la
@@ -214,6 +217,23 @@ IOSTREAM_PROVIDERS = \
io_stream_file.cc \
io_stream_file.h
 
+cyclops_SOURCES = \
+   $(IOSTREAM_PROVIDERS) \
+   cli/CliParseFeedback.cc \
+   cli/CliGetNetAuth.cc \
+   cli/CliGetUrlFeedback.cc \
+   cli/CliHashCheckFeedback.cc \
+   cli/CliFeedback.h \
+   cli/cyclops.cc \
+   res.rc
+
+cyclops_LDADD = \
+   libsetupcore.la \
+   libgetopt++/libgetopt++.la \
+   $(WININET)
+
+cyclops_LDFLAGS = -mconsole -Wc,-static -static-libtool-libs
+
 @SETUP@_LDADD = \
libsetupcore.la \
libgetopt++/libgetopt++.la \
diff --git a/cli/cyclops.cc b/cli/cyclops.cc
new file mode 100644
index 000..549b65a
--- /dev/null
+++ b/cli/cyclops.cc
@@ -0,0 +1,186 @@
+/*
+ * Copyright (c) 2020 Jon Turney
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * A copy of the GNU General Public License can be found at
+ * http://www.gnu.org/
+ *
+ */
+
+/*
+ * The one-eyed hippo sees all!
+ */
+
+#include "CliGetNetAuth.h"
+#include "CliFeedback.h"
+#include "ini.h"
+#include "LogFile.h"
+#include "resource.h"
+#include "setup_version.h"
+#include "state.h"
+
+#include "ConnectionSetting.h"
+#include "KeysSetting.h"
+#include "SiteSetting.h"
+#include "UserSettings.h"
+#include "netio.h"
+
+#include "getopt++/GetOption.h"
+#include "getopt++/BoolOption.h"
+
+BoolOption UnsupportedOption (false, '\0', "allow-unsupported-windows", 
IDS_HELPTEXT_ALLOW_UNSUPPORTED_WINDOWS);
+static BoolOption HelpOption (false, 'h', "help", IDS_HELPTEXT_HELP);
+
+static void
+main_cli ()
+{
+  // installation RootDir is already established by read_mounts()
+  ConnectionSetting ConnectionSettings;
+  ExtraKeysSetting ExtraKeys;
+  SiteSetting ChosenSites;
+
+  // check windows version and abort if too low unless UnsupportedOption
+
+  // announce myself
+  std::cout << "cyclops " << setup_version << std::endl;
+
+  // mode of operation
+  // XXX: probably only support download and install mode
+  source = IDC_SOURCE_NETINST;
+
+  // XXX: local package cache dir (from options or setup.rc)
+  // (fetched setp.ini is stored here)
+  char cwd[MAX_PATH];
+  GetCurrentDirectory (MAX_PATH, cwd);
+  local_dir = std::string (cwd);
+
+  // proxy
+
+  // interactive network auth getter
+  NetIO::auth_getter = new CliGetNetAuth();
+
+  // mirror site
+
+  // fetch and parse ini file(s)
+  CliFeedback feedback;
+  bool succeeded = do_ini_thread(feedback);
+  Log (LOG_PLAIN) << "do_ini_thread: " << succeeded << endLog;
+}
+
+static void
+main_wrap ()
+{
+  UserSettings Settings;
+  Settings.load (std::string());
+  main_cli ();
+  Settings.save (); // Clean exit. save user options.
+}
+
+int
+main (int argc, char **argv)
+{
+  LogSingleton::SetInstance (*LogFile::createLogFile ());
+
+  bool help_option = false;
+  bool invalid_option = false;
+
+  if (!GetOption::GetInstance ().Process (argc, argv, NULL))
+  help_option = invalid_option = true;
+else if (HelpOption)
+  help_option = true;
+
+  if (help_option)
+{
+  if (invalid_option)
+Log (LOG_PLAIN) << "\n" << LoadStringUtf8(IDS_HELPTEXT_ERROR) << "\n" 
<< endLog;
+
+  Log (LOG_PLAIN) << "\n" << LoadStringUtf8(IDS_HELPTEXT_HEADER) << "\n" 
<< endLog;
+  GetOption::GetInstance ().ParameterUsage (Log (LOG_PLAIN), 
LoadStringUtf8);
+
+  Logger ().exit (invalid_option ? 1 : 0, false);
+  return 1;
+}
+
+  LogSingleton::SetInstance (*LogFile::createLogFile ());
+
+  main_wrap();
+
+  return 0;
+}
+
+/* --- */
+
+#include 
+#include "String++.h"
+
+int
+mbox (HWND owner, const char *buf, const char *name, int type)
+{
+  Log (LOG_PLAIN) << "mbox " << name << ": " &

[PATCH setup 15/16] Put various shared subcomponents into a convenience library

[Jon Turney via Cygwin-apps]

* logging, settings, netio, iostream, decompressors, packagedb,
csu_util, hashes, signature checking, URL fetching, Exception class, ini
fetching and parsing, global state, version
---
 Makefile.am | 246 +++-
 1 file changed, 126 insertions(+), 120 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index def20a4..6ae5dd6 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -37,6 +37,9 @@ iniparse_CXXFLAGS:=-Wno-free-nonheap-object
 
 noinst_PROGRAMS = @SETUP@$(EXEEXT) inilint
 
+noinst_LTLIBRARIES = \
+   libsetupcore.la
+
 EXTRA_DIST = \
CHANGES \
CONTRIBUTORS \
@@ -59,35 +62,15 @@ BUILT_SOURCES = \
 CLEANFILES = setup_version.c
 
 inilint_LDADD = \
-   libgetopt++/libgetopt++.la \
-   -lntdll -luuid
+   libsetupcore.la \
+   libgetopt++/libgetopt++.la
 
 inilint_SOURCES = \
-   filemanip.cc \
-   filemanip.h \
cli/CliParseFeedback.cc \
cli/CliGetUrlFeedback.cc \
cli/CliHashCheckFeedback.cc \
cli/CliFeedback.h \
-   LogSingleton.cc \
-   LogSingleton.h \
-   IniDBBuilder.h \
-   inilintmain.cc \
-   inilex.ll \
-   iniparse.yy \
-   io_stream.cc \
-   io_stream.h \
-   io_stream_file.cc \
-   io_stream_file.h \
-   mkdir.cc \
-   mkdir.h \
-   mklink2.cc \
-   mklink2.h \
-   PackageTrust.h \
-   String++.cc \
-   String++.h \
-   win32.cc \
-   win32.h
+   inilintmain.cc
 
 # Do not link directly with wininet, as it's vulnerable to sideloading/dll
 # hijacking. Instead we make and link with a delay-loading stub lib, so it's
@@ -116,19 +99,134 @@ WININET=wininet-delaylib.a
 EXTRA_@SETUP@_DEPENDENCIES=wininet-delaylib.a
 endif
 
-@SETUP@_LDADD = \
-   libgetopt++/libgetopt++.la \
+libsetupcore_la_SOURCES = \
+   ConnectionSetting.cc \
+   ConnectionSetting.h \
+   Exception.cc \
+   Exception.h \
+   IniDBBuilder.h \
+   IniDBBuilderPackage.cc \
+   IniDBBuilderPackage.h \
+   KeysSetting.cc \
+   KeysSetting.h \
+   LogFile.cc \
+   LogFile.h \
+   LogSingleton.cc \
+   LogSingleton.h \
+   PackageSpecification.cc \
+   PackageSpecification.h \
+   PackageTrust.h \
+   SiteSetting.cc \
+   SiteSetting.h \
+   SourceSetting.cc \
+   SourceSetting.h \
+   String++.cc \
+   String++.h \
+   UserSettings.cc \
+   UserSettings.h \
+   compactos.cc \
+   compactos.h \
+   compress.cc \
+   compress.h \
+   compress_bz.cc \
+   compress_bz.h \
+   compress_gz.cc \
+   compress_gz.h \
+   compress_xz.cc \
+   compress_xz.h \
+   compress_zstd.cc \
+   compress_zstd.h \
+   crypto.cc \
+   crypto.h \
+   csu_util/MD5Sum.cc \
+   csu_util/MD5Sum.h \
+   csu_util/rfc1738.cc \
+   csu_util/rfc1738.h \
+   csu_util/version_compare.cc \
+   csu_util/version_compare.h \
+   filemanip.cc \
+   filemanip.h \
+   geturl.cc \
+   geturl.h \
+   gpg-packet.cc \
+   gpg-packet.h \
+   ini.cc \
+   ini.h \
+   inilex.ll \
+   iniparse.yy \
+   io_stream.cc \
+   io_stream.h \
+   io_stream_memory.cc \
+   io_stream_memory.h \
+   libsolv.cc \
+   libsolv.h \
+   mkdir.cc \
+   mkdir.h \
+   mklink2.cc \
+   mklink2.h \
+   mount.cc \
+   netio.cc \
+   netio.h \
+   nio-ie5.cc \
+   nio-ie5.h \
+   package_db.cc \
+   package_db.h \
+   package_depends.cc \
+   package_depends.h \
+   package_meta.cc \
+   package_meta.h \
+   package_source.cc \
+   package_source.h \
+   package_version.h \
+   setup_version.c \
+   setup_version.h \
+   sha2.c \
+   sha2.h \
+   state.cc \
+   state.h \
+   win32.cc \
+   win32.h
+
+# warning: always link with mingwex (which gcc specs will cause us to link with
+# anyhow) before ntdll, to ensure we don't link with CRT functions (avaliable 
in
+# some versions of) the ntdll import lib which aren't available on XP.
+libsetupcore_la_LDFLAGS = \
$(LIBGCRYPT_LIBS) \
$(ZSTD_LIBS) \
$(LZMA_LIBS) \
$(BZ2_LIBS) \
$(ZLIB_LIBS) \
-   $(LIBSOLV_LIBS) -lregex \
+   $(LIBSOLV_LIBS) \
+   -lregex \
-lmingwex \
-   -lshlwapi -lcomctl32 -lole32 -lpsapi -luuid -lntdll $(WININET) -lws2_32 
\
+   -lshlwapi \
+   -luuid \
+   -lntdll \
+   -lws2_32
+
+# because of a totally unnecessary "private registration" by static
+# constructors, these sources are completely unsuitable for putting in a 
library
+# (as the providers are not referenced and so aren't included in the final
+# link), so everything with needs them must include these objects
+IOSTREAM_PROVIDERS = \
+   io_stream_cygfile.cc \
+   io_stream_cygfile.h \
+   io_stream_file.cc \
+   io_stream_file.h
+
+@SETUP@_LDADD = \

[PATCH setup 14/16] Push check_for_cached into package_source

[Jon Turney via Cygwin-apps]

This is kind of half-right. It helps make the package database code
self-contained (since that needs to use check_for_cached as part of
ScanDownloadedFiles), but also pulls apart the 'cache checking' and
'download file and put it in the cache'.  There's probably some scope
for an package_source interface for "where is the package cache download
location for this package from that site."
---
 download.cc   | 104 ++
 download.h|   6 ---
 package_meta.cc   |   3 +-
 package_source.cc |  95 ++
 package_source.h  |   4 ++
 5 files changed, 103 insertions(+), 109 deletions(-)

diff --git a/download.cc b/download.cc
index fbe36e5..4aba83e 100644
--- a/download.cc
+++ b/download.cc
@@ -19,7 +19,7 @@
 #include "csu_util/rfc1738.h"
 
 #include "download.h"
-  
+
 #include "win32.h"
 
 #include 
@@ -28,7 +28,6 @@
 #include 
 
 #include "resource.h"
-#include "msg.h"
 #include "dialog.h"
 #include "geturl.h"
 #include "state.h"
@@ -48,110 +47,13 @@
 
 extern ThreeBarProgressPage Progress;
 
-// Return true if selected checks pass, false if they don't and the
-// user chooses to delete the file; otherwise throw an exception.
-static bool
-validateCachedPackage (const std::string& fullname, packagesource & pkgsource,
-   Feedback , bool check_hash, bool check_size)
-{
-  try
-{
-  if (check_size)
-   pkgsource.check_size_and_cache (fullname);
-  if (check_hash)
-   pkgsource.check_hash (feedback);
-  return true;
-}
-  catch (Exception *e)
-{
-  pkgsource.set_cached ("");
-  const char *filename = fullname.c_str ();
-  if (strncmp (filename, "file://", 7) == 0)
-   filename += 7;
-  if (e->errNo() == APPERR_CORRUPT_PACKAGE
- && yesno (feedback.owner(), IDS_QUERY_CORRUPT, filename) == IDYES)
-   remove (filename);
-  else
-   throw e;
-}
-  return false;
-}
-
-/* 0 if not cached; may throw exception if validation fails.
- */
-int
-check_for_cached (packagesource & pkgsource, Feedback ,
-  bool mirror_mode, bool check_hash)
-{
-  /* If the packagesource doesn't have a filename, it can't possibly be in the
- cache */
-  if (!pkgsource.Canonical())
-{
-  return 0;
-}
-
-  /* Note that the cache dir is represented by a mirror site of 
file://local_dir */
-  std::string prefix = "file://" + local_dir + "/";
-  std::string fullname = prefix + pkgsource.Canonical();
-
-  if (mirror_mode)
-{
-  /* Just assume correctness of mirror. */
-  if (!pkgsource.Cached())
-   pkgsource.set_cached (fullname);
-  return 1;
-}
-
-  // Already found one, which we can assume to have the right size.
-  if (pkgsource.Cached())
-{
-  if (validateCachedPackage (pkgsource.Cached(), pkgsource, feedback,
-check_hash, false))
-   return 1;
-  // If we get here, pkgsource.Cached() was corrupt and deleted.
-  pkgsource.set_cached ("");
-}
-
-  /*
- 1) is there a legacy version in the cache dir available.
-  */
-  if (io_stream::exists (fullname))
-{
-  if (validateCachedPackage (fullname, pkgsource, feedback, check_hash, 
true))
-   return 1;
-  // If we get here, fullname was corrupt and deleted, but it
-  // might have been cached.
-  pkgsource.set_cached ("");
-}
-
-  /*
- 2) is there a version from one of the selected mirror sites available ?
-  */
-  for (packagesource::sitestype::const_iterator n = pkgsource.sites.begin();
-   n != pkgsource.sites.end(); ++n)
-  {
-std::string fullname = prefix + rfc1738_escape_part (n->key) + "/" +
-  pkgsource.Canonical ();
-if (io_stream::exists(fullname))
-   {
- if (validateCachedPackage (fullname, pkgsource, feedback, check_hash,
-true))
-   return 1;
- // If we get here, fullname was corrupt and deleted, but it
- // might have been cached.
- pkgsource.set_cached ("");
-   }
-  }
-  return 0;
-}
-
 /* download a file from a mirror site to the local cache. */
 static int
 download_one (packagesource & pkgsource, Feedback )
 {
   try
 {
-  if (check_for_cached (pkgsource, feedback))
+  if (pkgsource.check_for_cached(feedback))
 return 0;
 }
   catch (Exception * e)
@@ -295,7 +197,7 @@ do_download_thread (HINSTANCE h, HWND owner)
 
   try
 {
-  if (!check_for_cached (*version.source(), feedback))
+  if (!(version.source()->check_for_cached(feedback)))
 total_download_bytes += version.source()->size;
 }
   catch (Exception * e)
diff --git a/download.h b/download.h
index 3f65153..e887c92 100644
--- a/download.h
+++ b/download.h
@@ -16,10 +16,4 @@
 #ifndef SETUP_DOWNLOAD_H
 #define SETUP_DOWNLOAD_H
 
-#include "Feedback.h"
-
-class packagesource;
-int check_for_cached (packagesource & pkgsource, Feedback ,

[PATCH setup 12/16] Spit out GetNetAuth from NetIO

[Jon Turney via Cygwin-apps]

There's still all kinds of janky stuff here: The network proxy
configuration fetched by ConnectionSetting is stored into static members
of the NetIO class, rather than held there and accessed.

Again, define a virtual class as the interface through which user
interaction takes place, and implement that for GUI and CLI clients.

While we're at it, we arrange for the GUI dialogs for network auth to be
properly parented.
---
 GetNetAuth.h |  30 ++
 Makefile.am  |   2 +
 cli/CliGetNetAuth.cc |  45 ++
 cli/CliGetNetAuth.h  |  32 ++
 gui/GuiGetNetAuth.cc | 138 +++
 gui/GuiGetNetAuth.h  |  38 
 net.cc   |   5 ++
 netio.cc | 125 +--
 netio.h  |  19 ++
 nio-ie5.cc   |   4 +-
 10 files changed, 298 insertions(+), 140 deletions(-)
 create mode 100644 GetNetAuth.h
 create mode 100644 cli/CliGetNetAuth.cc
 create mode 100644 cli/CliGetNetAuth.h
 create mode 100644 gui/GuiGetNetAuth.cc
 create mode 100644 gui/GuiGetNetAuth.h

diff --git a/GetNetAuth.h b/GetNetAuth.h
new file mode 100644
index 000..0a26e85
--- /dev/null
+++ b/GetNetAuth.h
@@ -0,0 +1,30 @@
+/*
+ * Copyright (c) 2000, Red Hat, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * A copy of the GNU General Public License can be found at
+ * http://www.gnu.org/
+ *
+ * Written by DJ Delorie 
+ *
+ */
+
+#ifndef SETUP_GETNETAUTH_H
+#define SETUP_GETNETAUTH_H
+
+class GetNetAuth
+{
+public:
+  /* Helper functions for http/ftp protocols.  Both return nonzero for
+ "cancel", zero for "ok".  They set net_proxy_user, etc, in
+ state.h */
+  virtual int get_auth () = 0;
+  virtual int get_proxy_auth () = 0;
+  virtual int get_ftp_auth () = 0;
+};
+
+#endif /* SETUP_GETNETAUTH_H */
diff --git a/Makefile.am b/Makefile.am
index de066b7..f257e3a 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -182,6 +182,8 @@ endif
gpg-packet.cc \
gpg-packet.h \
gui/GuiParseFeedback.cc \
+   gui/GuiGetNetAuth.cc \
+   gui/GuiGetNetAuth.h \
gui/GuiGetUrlFeedback.cc \
gui/GuiFeedback.h \
ini.cc \
diff --git a/cli/CliGetNetAuth.cc b/cli/CliGetNetAuth.cc
new file mode 100644
index 000..a1fde3b
--- /dev/null
+++ b/cli/CliGetNetAuth.cc
@@ -0,0 +1,45 @@
+/*
+ * Copyright (c) 2000, 2001, Red Hat, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * A copy of the GNU General Public License can be found at
+ * http://www.gnu.org/
+ *
+ */
+
+/* Query user for auth information required */
+
+#include "netio.h"
+#include "CliGetNetAuth.h"
+
+#include "LogFile.h"
+
+static int
+auth_common(const char *mode)
+{
+  Log (LOG_PLAIN) << mode << " not implemented" << endLog;
+  Logger ().exit (1);
+  return 1;
+}
+
+int
+CliGetNetAuth::get_auth ()
+{
+  return auth_common("get_auth");
+}
+
+int
+CliGetNetAuth::get_proxy_auth ()
+{
+  return auth_common("get_proxy_auth");
+}
+
+int
+CliGetNetAuth::get_ftp_auth ()
+{
+  return auth_common("get_ftp_auth");
+}
diff --git a/cli/CliGetNetAuth.h b/cli/CliGetNetAuth.h
new file mode 100644
index 000..7ff4520
--- /dev/null
+++ b/cli/CliGetNetAuth.h
@@ -0,0 +1,32 @@
+/*
+ * Copyright (c) 2000, Red Hat, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * A copy of the GNU General Public License can be found at
+ * http://www.gnu.org/
+ *
+ * Written by DJ Delorie 
+ *
+ */
+
+#ifndef SETUP_CLI_GETNETAUTH_H
+#define SETUP_CLI_GETNETAUTH_H
+
+#include "GetNetAuth.h"
+
+class CliGetNetAuth : public GetNetAuth
+{
+public:
+  /* Helper functions for http/ftp protocols.  Both return nonzero for
+ "cancel", zero for "ok".  They set net_proxy_user, etc, in
+ state.h */
+  int get_auth ();
+  int get_proxy_auth ();
+  int get_ftp_auth ();
+};
+
+#endif /* SETUP_CLI_GETNETAUTH_H */
diff --git a/gui/GuiGetNetAuth.cc b/gui/GuiGetNetAuth.cc
new file mode 100644
index 000..a6d4917
--- /dev/null
+++ b/gui/GuiGetNetAuth.cc
@@ -0,0 +1,138 @@
+/*
+ * Copyright (c) 2000, 2001, Red Hat, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of 

[PATCH setup 08/16] Instantiate found_ini_list in ini.cc

[Jon Turney via Cygwin-apps]

This is the list of ini files found by fromcwd.cc:do_from_local_dir().

Maybe that should be unkinked by actually doing that scan inside ini.cc,
where we could have some progress feedback?

This makes it possible to build ini.cc without fromcwd.cc
---
 fromcwd.cc | 2 --
 ini.cc | 1 +
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/fromcwd.cc b/fromcwd.cc
index f58e955..c53eede 100644
--- a/fromcwd.cc
+++ b/fromcwd.cc
@@ -105,8 +105,6 @@ private:
   std::vector found_ini;
 };
 
-IniList found_ini_list;
-
 bool
 do_from_local_dir (HINSTANCE h, HWND owner, std::string _dir)
 {
diff --git a/ini.cc b/ini.cc
index 09dda13..2b2da10 100644
--- a/ini.cc
+++ b/ini.cc
@@ -56,6 +56,7 @@ std::string ini_setup_version;
 static const std::string setup_exts[] = { "zst", "xz", "bz2", "ini" };
 IniList setup_ext_list (setup_exts,
setup_exts + (sizeof(setup_exts) / 
sizeof(*setup_exts)));
+IniList found_ini_list;
 
 static BoolOption NoVerifyOption (false, 'X', "no-verify", 
IDS_HELPTEXT_NO_VERIFY);
 static BoolOption NoVersionCheckOption (false, '\0', "no-version-check", 
IDS_HELPTEXT_NO_VERSION_CHECK);
-- 
2.43.0

[PATCH setup 13/16] Split out hash checking progress reporting

[Jon Turney via Cygwin-apps]

---
 Feedback.h  |  4 
 Makefile.am |  2 ++
 choose.cc   |  4 +++-
 cli/CliFeedback.h   |  5 +
 cli/CliHashCheckFeedback.cc | 30 ++
 download.cc | 24 
 download.h  |  6 +++---
 gui/GuiFeedback.h   |  5 +
 gui/GuiHashCheckFeedback.cc | 34 ++
 install.cc  |  4 +++-
 package_db.cc   |  6 +++---
 package_db.h|  3 ++-
 package_meta.cc | 10 +-
 package_meta.h  |  5 +++--
 package_source.cc   | 33 ++---
 package_source.h|  8 +---
 16 files changed, 129 insertions(+), 54 deletions(-)
 create mode 100644 cli/CliHashCheckFeedback.cc
 create mode 100644 gui/GuiHashCheckFeedback.cc

diff --git a/Feedback.h b/Feedback.h
index 8f603a6..4db7c4a 100644
--- a/Feedback.h
+++ b/Feedback.h
@@ -47,6 +47,10 @@ public:
   virtual void fetch_finish (int total_bytes) = 0;
   virtual void fetch_fatal (const char *filename, const char *err) = 0;
 
+  // hash checking
+  virtual void hash_init (const char *hashalg, const std::string ) = 0;
+  virtual void hash_progress (int bytes, int total_bytes) = 0;
+
   //
   virtual HWND owner () = 0;
 };
diff --git a/Makefile.am b/Makefile.am
index f257e3a..def20a4 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -67,6 +67,7 @@ inilint_SOURCES = \
filemanip.h \
cli/CliParseFeedback.cc \
cli/CliGetUrlFeedback.cc \
+   cli/CliHashCheckFeedback.cc \
cli/CliFeedback.h \
LogSingleton.cc \
LogSingleton.h \
@@ -186,6 +187,7 @@ endif
gui/GuiGetNetAuth.h \
gui/GuiGetUrlFeedback.cc \
gui/GuiFeedback.h \
+   gui/GuiHashCheckFeedback.cc \
ini.cc \
ini.h \
IniDBBuilder.h \
diff --git a/choose.cc b/choose.cc
index 8deab87..451b390 100644
--- a/choose.cc
+++ b/choose.cc
@@ -50,6 +50,7 @@
 #include "package_meta.h"
 
 #include "threebar.h"
+#include "gui/GuiFeedback.h"
 #include "Generic.h"
 #include "ControlAdjuster.h"
 #include "prereq.h"
@@ -317,9 +318,10 @@ void
 ChooserPage::OnActivate()
 {
   SetBusy();
+  GuiFeedback feedback(GetHWND());
 
   packagedb db;
-  db.prep();
+  db.prep(feedback);
 
   if (!activated)
 {
diff --git a/cli/CliFeedback.h b/cli/CliFeedback.h
index 3bcc23c..cb59650 100644
--- a/cli/CliFeedback.h
+++ b/cli/CliFeedback.h
@@ -48,6 +48,11 @@ private:
   unsigned int last_tics;
   unsigned int start_tics;
 
+  // hash checking
+public:
+  void hash_init (const char *hashalg, const std::string );
+  void hash_progress (int bytes, int total_bytes);
+
   // owner
 public:
   HWND owner () { return NULL; }
diff --git a/cli/CliHashCheckFeedback.cc b/cli/CliHashCheckFeedback.cc
new file mode 100644
index 000..f5df9fc
--- /dev/null
+++ b/cli/CliHashCheckFeedback.cc
@@ -0,0 +1,30 @@
+/*
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * A copy of the GNU General Public License can be found at
+ * http://www.gnu.org/
+ *
+ */
+
+#include "cli/CliFeedback.h"
+#include "resource.h"
+#include "String++.h"
+#include 
+
+void
+CliFeedback::hash_init(const char *hashalg, const std::string )
+{
+  std::wstring fmt = LoadStringW(IDS_PROGRESS_CHECKING_HASH);
+  std::wstring s = format(fmt, hashalg, shortname.c_str());
+  std::cout << wstring_to_string(s) << std::endl;
+}
+
+void
+CliFeedback::hash_progress(int bytes, int total_bytes)
+{
+  std::cout << bytes << "/" << total_bytes << "\r";
+}
diff --git a/download.cc b/download.cc
index 02fd484..fbe36e5 100644
--- a/download.cc
+++ b/download.cc
@@ -52,14 +52,14 @@ extern ThreeBarProgressPage Progress;
 // user chooses to delete the file; otherwise throw an exception.
 static bool
 validateCachedPackage (const std::string& fullname, packagesource & pkgsource,
-  HWND owner, bool check_hash, bool check_size)
+   Feedback , bool check_hash, bool check_size)
 {
   try
 {
   if (check_size)
pkgsource.check_size_and_cache (fullname);
   if (check_hash)
-   pkgsource.check_hash ();
+   pkgsource.check_hash (feedback);
   return true;
 }
   catch (Exception *e)
@@ -69,7 +69,7 @@ validateCachedPackage (const std::string& fullname, 
packagesource & pkgsource,
   if (strncmp (filename, "file://", 7) == 0)
filename += 7;
   if (e->errNo() == APPERR_CORRUPT_PACKAGE
- && yesno (owner, IDS_QUERY_CORRUPT, filename) == IDYES)
+ && yesno (feedback.owner(), IDS_QUERY_CORRUPT, filename) == IDYES)
remove (filename);
   else
throw e;
@@ -80,8 +80,8 @@ validateCachedPackage (const 

[PATCH setup 09/16] Move is_64bit to state

[Jon Turney via Cygwin-apps]

Note this controls what we will install, not indicating how we are
built, so it's use in splash is questionable, and is downright wrong in
the messages from IniDbBuilderPackage giving URLs for an updated
version of setup.

This controls stuff all over the place!
---
 ini.h |  1 -
 main.cc   | 34 ++
 splash.cc |  2 +-
 state.cc  |  6 ++
 state.h   |  2 ++
 5 files changed, 23 insertions(+), 22 deletions(-)

diff --git a/ini.h b/ini.h
index f1788e2..2ca4f5b 100644
--- a/ini.h
+++ b/ini.h
@@ -23,7 +23,6 @@
 typedef std::vector  IniList;
 extern IniList found_ini_list, setup_ext_list;
 
-extern bool is_64bit;
 extern bool is_new_install;
 extern std::string SetupArch;
 extern std::string SetupIniDir;
diff --git a/main.cc b/main.cc
index 2ce3b30..c359ba9 100644
--- a/main.cc
+++ b/main.cc
@@ -83,7 +83,6 @@
 extern char **_argv;
 #endif
 
-bool is_64bit;
 bool is_new_install = false;
 std::string SetupArch;
 std::string SetupIniDir;
@@ -263,26 +262,21 @@ WinMain (HINSTANCE h,
 else if (HelpOption)
   help_option = true;
 
-if (!((std::string) Arch).size ())
+if (((std::string) Arch).size ())
   {
-#ifdef __x86_64__
-   is_64bit = true;
-#else
-   is_64bit = false;
-#endif
-  }
-else if (((std::string) Arch).find ("64") != std::string::npos)
-  is_64bit = true;
-else if (((std::string) Arch).find ("32") != std::string::npos
-|| ((std::string) Arch).find ("x86") != std::string::npos)
-  is_64bit = false;
-else
-  {
-   char buff[80 + ((std::string) Arch).size ()];
-   sprintf (buff, "Invalid option for --arch:  \"%s\"",
-((std::string) Arch).c_str ());
-   fprintf (stderr, "*** %s\n", buff);
-   exit (1);
+if (((std::string) Arch).find ("64") != std::string::npos)
+  is_64bit = true;
+else if (((std::string) Arch).find ("32") != std::string::npos
+ || ((std::string) Arch).find ("x86") != std::string::npos)
+  is_64bit = false;
+else
+  {
+char buff[80 + ((std::string) Arch).size ()];
+sprintf (buff, "Invalid option for --arch:  \"%s\"",
+ ((std::string) Arch).c_str ());
+fprintf (stderr, "*** %s\n", buff);
+exit (1);
+  }
   }
 
 if (GuiLangOption.isPresent())
diff --git a/splash.cc b/splash.cc
index 40c1334..8b601db 100644
--- a/splash.cc
+++ b/splash.cc
@@ -19,7 +19,7 @@
 #include "setup_version.h"
 #include "resource.h"
 #include "splash.h"
-#include "ini.h"
+#include "state.h"
 
 #define SPLASH_URL "https://cygwin.com;
 #define SPLASH_COPYRIGHT "Copyright 2000-2023"
diff --git a/state.cc b/state.cc
index 111b890..ef14116 100644
--- a/state.cc
+++ b/state.cc
@@ -29,3 +29,9 @@ int root_menu;
 int root_desktop;
 
 LANGID langid;
+
+#ifdef __x86_64__
+bool is_64bit = true;
+#else
+bool is_64bit = false;
+#endif
diff --git a/state.h b/state.h
index b211de3..c4b88a4 100644
--- a/state.h
+++ b/state.h
@@ -48,4 +48,6 @@ extern int root_desktop;
 
 extern LANGID langid;
 
+extern bool is_64bit;
+
 #endif /* SETUP_STATE_H */
-- 
2.43.0

[PATCH setup 11/16] Drop hinstance global

[Jon Turney via Cygwin-apps]

We do not need to retain the hInstance value passed into WinMain(), as
it's always available as GetModuleHandle(NULL).

Note that DialogBox() accepts NULL meaning "the current executable" in
any case.

Future work: there's still some completely unnecessary storing it in
class Window and passing it around.
---
 dialog.h|  3 ---
 gui/SitePage.cc |  3 +--
 install.cc  |  2 +-
 main.cc |  5 +
 msg.cc  |  5 ++---
 netio.cc| 10 +-
 6 files changed, 10 insertions(+), 18 deletions(-)

diff --git a/dialog.h b/dialog.h
index 63c98ee..ebbf661 100644
--- a/dialog.h
+++ b/dialog.h
@@ -20,9 +20,6 @@
 
 #include "win32.h"
 
-/* global instance for the application; set in main.cc */
-extern HINSTANCE hinstance;
-
 /* used by main.cc to select the next do_* function */
 extern int next_dialog;
 
diff --git a/gui/SitePage.cc b/gui/SitePage.cc
index 1cdb1bf..9dacebc 100644
--- a/gui/SitePage.cc
+++ b/gui/SitePage.cc
@@ -367,8 +367,7 @@ int check_dropped_mirrors (HWND h)
 {
   if (unattended_mode)
return CACHE_ACCEPT_WARN;
-  return DialogBox (hinstance, MAKEINTRESOURCE (IDD_DROPPED), h,
-   drop_proc);
+  return DialogBox (NULL, MAKEINTRESOURCE (IDD_DROPPED), h, drop_proc);
 }
   return CACHE_ACCEPT_NOWARN;
 }
diff --git a/install.cc b/install.cc
index 628dbd0..001529b 100644
--- a/install.cc
+++ b/install.cc
@@ -660,7 +660,7 @@ Installer::_installOne (packagemeta ,
 dlg_data.processlist = plm.c_str ();
 dlg_data.iteration = iteration;
 
-rc = DialogBoxParam(hinstance, MAKEINTRESOURCE 
(IDD_FILE_INUSE), owner, FileInuseDlgProc, (LPARAM)_data);
+rc = DialogBoxParam(NULL, MAKEINTRESOURCE 
(IDD_FILE_INUSE), owner, FileInuseDlgProc, (LPARAM)_data);
   }
 else
   {
diff --git a/main.cc b/main.cc
index 4c391f5..8a68232 100644
--- a/main.cc
+++ b/main.cc
@@ -86,8 +86,6 @@ extern char **_argv;
 bool is_new_install = false;
 std::string SetupIniDir;
 
-HINSTANCE hinstance;
-
 static StringChoiceOption::StringChoices symlink_types({
 {"native", SymlinkTypeNative},
 {"lnk", SymlinkTypeShortcut},
@@ -176,7 +174,7 @@ main_display ()
 }
 
   // Init window class lib
-  Window::SetAppInstance (hinstance);
+  Window::SetAppInstance (GetModuleHandle(NULL));
 
   // Create pages
   Splash.Create ();
@@ -221,7 +219,6 @@ int WINAPI
 WinMain (HINSTANCE h,
 HINSTANCE hPrevInstance, LPSTR command_line, int cmd_show)
 {
-  hinstance = h;
 
   // Make sure Windows DLLs only delay-load further DLLs from System32
   typedef BOOL (WINAPI *PFNSETDEFAULTDLLDIRECTORIES)(DWORD);
diff --git a/msg.cc b/msg.cc
index 8e344ff..b53df86 100644
--- a/msg.cc
+++ b/msg.cc
@@ -23,7 +23,6 @@
 
 #include 
 #include 
-#include "dialog.h"
 #include "state.h"
 #include "String++.h"
 #include "resource.h"
@@ -66,7 +65,7 @@ mbox (HWND owner, const char *buf, const char *name, int type)
 }
 
   char caption[32];
-  LoadString (hinstance, IDS_MBOX_CAPTION, caption, sizeof (caption));
+  LoadString (GetModuleHandle(NULL), IDS_MBOX_CAPTION, caption, sizeof 
(caption));
 
   return MessageBox (owner, buf, caption, type);
 }
@@ -76,7 +75,7 @@ mbox (HWND owner, const char *name, int type, int id, va_list 
args)
 {
   char buf[1000], fmt[1000];
 
-  if (LoadString (hinstance, id, fmt, sizeof (fmt)) <= 0)
+  if (LoadString (GetModuleHandle(NULL), id, fmt, sizeof (fmt)) <= 0)
 ExitProcess (0);
 
   vsnprintf (buf, 1000, fmt, args);
diff --git a/netio.cc b/netio.cc
index 631532a..d6bfc24 100644
--- a/netio.cc
+++ b/netio.cc
@@ -185,9 +185,9 @@ auth_proc (HWND h, UINT message, WPARAM wParam, LPARAM 
lParam)
 }
 
 static int
-auth_common (HINSTANCE h, int id, HWND owner)
+auth_common (int id, HWND owner)
 {
-  return DialogBox (h, MAKEINTRESOURCE (id), owner, auth_proc);
+  return DialogBox (NULL, MAKEINTRESOURCE (id), owner, auth_proc);
 }
 
 int
@@ -195,7 +195,7 @@ NetIO::get_auth (HWND owner)
 {
   user = _user;
   passwd = _passwd;
-  return auth_common (hinstance, IDD_NET_AUTH, owner);
+  return auth_common (IDD_NET_AUTH, owner);
 }
 
 int
@@ -203,7 +203,7 @@ NetIO::get_proxy_auth (HWND owner)
 {
   user = _proxy_user;
   passwd = _proxy_passwd;
-  return auth_common (hinstance, IDD_PROXY_AUTH, owner);
+  return auth_common (IDD_PROXY_AUTH, owner);
 }
 
 int
@@ -221,7 +221,7 @@ NetIO::get_ftp_auth (HWND owner)
 }
   user = _ftp_user;
   passwd = _ftp_passwd;
-  return auth_common (hinstance, IDD_FTP_AUTH, owner);
+  return auth_common (IDD_FTP_AUTH, owner);
 }
 
 const char *
-- 
2.43.0

[PATCH setup 07/16] Split out URL fetching progress reporting

[Jon Turney via Cygwin-apps]

lderPackage.h b/IniDBBuilderPackage.h
index 3e3a9e4..0f59257 100644
--- a/IniDBBuilderPackage.h
+++ b/IniDBBuilderPackage.h
@@ -24,13 +24,13 @@
 #include "String++.h"
 #include "libsolv.h"
 
-class IniParseFeedback;
+class Feedback;
 class packagesource;
 
 class IniDBBuilderPackage:public IniDBBuilder
 {
 public:
-  IniDBBuilderPackage (IniParseFeedback const &);
+  IniDBBuilderPackage (Feedback const &);
   ~IniDBBuilderPackage ();
 
   void buildTimestamp (const std::string& );
@@ -88,7 +88,7 @@ private:
   SolverPool::addPackageData cbpv;
   std::set  replace_versions;
 
-  IniParseFeedback const &_feedback;
+  Feedback const &_feedback;
   bool minimum_version_checked;
 };
 
diff --git a/IniParseFeedback.h b/IniParseFeedback.h
deleted file mode 100644
index c3c7803..000
--- a/IniParseFeedback.h
+++ /dev/null
@@ -1,38 +0,0 @@
-/*
- * Copyright (c) 2002 Robert Collins.
- *
- * This program is free software; you can redistribute it and/or modify
- * it under the terms of the GNU General Public License as published by
- * the Free Software Foundation; either version 2 of the License, or
- * (at your option) any later version.
- *
- * A copy of the GNU General Public License can be found at
- * http://www.gnu.org/
- *
- * Written by Robert Collins 
- *
- */
-
-#ifndef SETUP_INIPARSEFEEDBACK_H
-#define SETUP_INIPARSEFEEDBACK_H
-
-
-#include 
-/* Strategy for feedback from IniParsing.
- * Used by the builder or parsing classes to send feedback that users need
- * but that should not interrupt parsing.
- * Fatal errors are thrown as exceptions.
- */
-class IniParseFeedback
-{
-public:
-  virtual void progress (unsigned long const, unsigned long const) = 0;
-  virtual void iniName (const std::string& ) = 0;
-  virtual void babble (const std::string& ) const = 0;
-  virtual void warning (const std::string& ) const = 0;
-  virtual void show_errors () const = 0;
-  virtual void note_error(int lineno, const std::string ) = 0;
-  virtual bool has_errors () const = 0;
-};
-
-#endif /* SETUP_INIPARSEFEEDBACK_H */
diff --git a/Makefile.am b/Makefile.am
index f753961..de066b7 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -65,8 +65,9 @@ inilint_LDADD = \
 inilint_SOURCES = \
filemanip.cc \
filemanip.h \
-   CliParseFeedback.cc \
-   CliParseFeedback.h \
+   cli/CliParseFeedback.cc \
+   cli/CliGetUrlFeedback.cc \
+   cli/CliFeedback.h \
LogSingleton.cc \
LogSingleton.h \
IniDBBuilder.h \
@@ -181,6 +182,8 @@ endif
gpg-packet.cc \
gpg-packet.h \
gui/GuiParseFeedback.cc \
+   gui/GuiGetUrlFeedback.cc \
+   gui/GuiFeedback.h \
ini.cc \
ini.h \
IniDBBuilder.h \
@@ -188,7 +191,7 @@ endif
IniDBBuilderPackage.h \
inilex.ll \
iniparse.yy \
-   IniParseFeedback.h \
+   Feedback.h \
install.cc \
io_stream.cc \
io_stream.h \
diff --git a/CliParseFeedback.h b/cli/CliFeedback.h
similarity index 52%
rename from CliParseFeedback.h
rename to cli/CliFeedback.h
index a19659e..3bcc23c 100644
--- a/CliParseFeedback.h
+++ b/cli/CliFeedback.h
@@ -11,11 +11,14 @@
  *
  */
 
-#include "IniParseFeedback.h"
+#include "Feedback.h"
 
-class CliParseFeedback : public IniParseFeedback
+class CliFeedback : public Feedback
 {
+  // ini parse
 public:
+  virtual void parse_init ();
+  virtual void parse_finish ();
   virtual void progress (unsigned long const pos, unsigned long const max);
   virtual void iniName (const std::string& name);
   virtual void babble (const std::string& message) const;
@@ -25,4 +28,28 @@ public:
   virtual bool has_errors () const;
 private:
   int error_count = 0;
+
+  // URL fetch
+public:
+  void fetch_progress_disable (bool);
+  void fetch_init (const std::string , int length);
+  void fetch_set_length(int length);
+  void fetch_set_total_length(long long int total_length);
+  void fetch_progress (int bytes);
+  void fetch_total_progress ();
+  void fetch_finish (int total_bytes);
+  void fetch_fatal (const char *filename, const char *err);
+
+private:
+  int max_bytes;
+  long long int total_download_bytes = 0; // meaning ???
+  long long int total_download_bytes_sofar = 0;
+
+  unsigned int last_tics;
+  unsigned int start_tics;
+
+  // owner
+public:
+  HWND owner () { return NULL; }
+
 };
diff --git a/cli/CliGetUrlFeedback.cc b/cli/CliGetUrlFeedback.cc
new file mode 100644
index 000..1256118
--- /dev/null
+++ b/cli/CliGetUrlFeedback.cc
@@ -0,0 +1,91 @@
+/*
+ * Copyright (c) 2024 Jon Turney
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * A copy of the GNU General Public License can be found 

[PATCH setup 06/16] Simplify invocation of UserSettings::open_settings()

[Jon Turney via Cygwin-apps]

Simplify how we check for a setup.rc settings file in the local cache
dir (Who knew that setup even did this?): pass the directory down to
UserSettings::open_settings() as a parameter, rather than by storing it
in an (otherwise unused) member.

Also: rename the 'cwd' parameter, because it's actually an arbitrary
directory, not the cwd.

(Archeology seems to indicate that at one stage we'd save settings in
the cwd if we needed to write them before the cygwin root was known, and
migrate that file to the cygwin root when it becomes known; then we
changed to keeping that file in the cache dir, then we forgot to migrate
it, so perhaps all this complexity isn't needed?)
---
 UserSettings.cc | 12 +++-
 UserSettings.h  |  4 +---
 2 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/UserSettings.cc b/UserSettings.cc
index c8ddd3d..3ec6798 100644
--- a/UserSettings.cc
+++ b/UserSettings.cc
@@ -65,14 +65,17 @@ UserSettings::extend_table (ssize_t i)
 }
 
 io_stream *
-UserSettings::open_settings (const char *filename, std::string )
+UserSettings::open_settings (const char *filename, std::string , 
std::string )
 {
+  // first look for a settings file in specified dir
   pathname = "file://";
-  pathname += cwd;
-  if (!isdirsep (cwd[cwd.size () - 1]) && !isdirsep (filename[0]))
+  pathname += dir;
+  if (!isdirsep (dir[dir.size () - 1]) && !isdirsep (filename[0]))
 pathname += "/";
   pathname += filename;
   io_stream *f = io_stream::open(pathname, "rt", 0);
+
+  // if not found, look in cygwin installation
   if (!f)
 {
   pathname = "cygfile:///etc/setup/";
@@ -92,8 +95,7 @@ UserSettings::UserSettings ()
 void
 UserSettings::load (std::string local_dir)
 {
-  cwd = local_dir;
-  io_stream *f = open_settings ("setup.rc", filename);
+  io_stream *f = open_settings ("setup.rc", local_dir, filename);
 
   if (!f)
 return;
diff --git a/UserSettings.h b/UserSettings.h
index 3de06e1..dc06ab2 100644
--- a/UserSettings.h
+++ b/UserSettings.h
@@ -27,7 +27,6 @@ private:
   ssize_t table_len;
 
   std::string filename;
-  std::string cwd;
 
 public:
   static class UserSettings *global;
@@ -44,8 +43,7 @@ public:
 
 private:
   void extend_table (ssize_t);
-  io_stream *open_settings (const char *, std::string&);
-
+  io_stream *open_settings (const char *, std::string &, std::string&);
 };
 
 #endif // SETUP_USERSETTINGS_H
-- 
2.43.0

[PATCH setup 10/16] Move setup.ini pathame components to ini.cc

[Jon Turney via Cygwin-apps]

Move SetupBaseNameOption to ini.cc
Eliminate SetupIniDir, it's just SetupArch + "/"
Change SetupArch() and SetupBaseName() into functions, to avoid having
to do global initialization at the right time.
---
 fromcwd.cc |  8 
 ini.cc | 22 +-
 ini.h  |  5 ++---
 main.cc|  8 
 4 files changed, 23 insertions(+), 20 deletions(-)

diff --git a/fromcwd.cc b/fromcwd.cc
index c53eede..b1f1021 100644
--- a/fromcwd.cc
+++ b/fromcwd.cc
@@ -52,7 +52,7 @@ public:
 ext != setup_ext_list.end ();
 ext++, fi++)
  {
-   if (!casecompare (SetupBaseName + "." + *ext,  theFile->cFileName))
+   if (!casecompare (SetupBaseName() + "." + *ext,  
theFile->cFileName))
  *fi = true;
  }
   }
@@ -62,7 +62,7 @@ public:
   {
 if (level <= 0)
   return;
-inidir = !casecompare (SetupArch, aDir->cFileName);
+inidir = !casecompare (SetupArch(), aDir->cFileName);
 if (level == 1 && !inidir)
   return;
 Find aFinder (basePath + aDir->cFileName);
@@ -74,8 +74,8 @@ public:
  {
if (*fi)
  {
-   found_ini_list.push_back (basePath + SetupArch + "/"
- + SetupBaseName + "." + *ext);
+   found_ini_list.push_back (basePath + SetupArch() + "/"
+ + SetupBaseName() + "." + *ext);
/* 
 * Terminate the search after the first setup file
 * found, which shadows any setup files with
diff --git a/ini.cc b/ini.cc
index 2b2da10..42df6a3 100644
--- a/ini.cc
+++ b/ini.cc
@@ -44,6 +44,7 @@
 #include "io_stream_memory.h"
 
 #include "getopt++/BoolOption.h"
+#include "getopt++/StringOption.h"
 #include "IniDBBuilderPackage.h"
 #include "compress.h"
 #include "msg.h"
@@ -58,10 +59,21 @@ IniList setup_ext_list (setup_exts,
setup_exts + (sizeof(setup_exts) / 
sizeof(*setup_exts)));
 IniList found_ini_list;
 
+static StringOption SetupBaseNameOption ("setup", 'i', "ini-basename", 
IDS_HELPTEXT_INI_BASENAME, false);
 static BoolOption NoVerifyOption (false, 'X', "no-verify", 
IDS_HELPTEXT_NO_VERIFY);
 static BoolOption NoVersionCheckOption (false, '\0', "no-version-check", 
IDS_HELPTEXT_NO_VERSION_CHECK);
 
 
+std::string SetupArch()
+{
+  return is_64bit ? "x86_64" : "x86";
+}
+
+std::string SetupBaseName()
+{
+  return SetupBaseNameOption;
+}
+
 static io_stream*
 decompress_ini (io_stream *ini_file, std::string _ini_name)
 {
@@ -170,7 +182,7 @@ do_local_ini (Feedback )
   if (!ini_file || sig_fail)
{
  // no setup found or signature invalid
- note (myFeedback.owner(), IDS_SETUPINI_MISSING, SetupBaseName.c_str 
(),
+ note (myFeedback.owner(), IDS_SETUPINI_MISSING, SetupBaseName().c_str 
(),
"localdir");
  ini_error = true;
}
@@ -180,7 +192,7 @@ do_local_ini (Feedback )
  myFeedback.babble ("Found ini file - " + current_ini_name);
  myFeedback.iniName (current_ini_name);
  int ldl = local_dir.length () + 1;
- int cap = current_ini_name.rfind ("/" + SetupArch);
+ int cap = current_ini_name.rfind ("/" + SetupArch());
  aBuilder.parse_mirror =
rfc1738_unescape (current_ini_name.substr (ldl, cap - ldl));
  ini_init (ini_file, , myFeedback);
@@ -225,7 +237,7 @@ do_remote_ini (Feedback )
   ext++)
{
  current_ini_ext = *ext;
- current_ini_name = n->url + SetupIniDir + SetupBaseName + "." + 
current_ini_ext;
+ current_ini_name = n->url + SetupArch() + "/" + SetupBaseName() + "." 
+ current_ini_ext;
  current_ini_sig_name = current_ini_name + ".sig";
  ini_sig_file = get_url_to_membuf (current_ini_sig_name, myFeedback);
  ini_file = get_url_to_membuf (current_ini_name, myFeedback);
@@ -240,7 +252,7 @@ do_remote_ini (Feedback )
   if (!ini_file || sig_fail)
{
  // no setup found or signature invalid
- note (myFeedback.owner(), IDS_SETUPINI_MISSING, SetupBaseName.c_str 
(), n->url.c_str ());
+ note (myFeedback.owner(), IDS_SETUPINI_MISSING, SetupBaseName().c_str 
(), n->url.c_str ());
  ini_error = true;
}
   else
@@ -260,7 +272,7 @@ do_remote_ini (Feedback )
  /* save known-good setup.ini locally */
  const std::string fp = "file://" + local_dir + "/" +
  rfc1738_escape_part (n->url) +
- "/" + SetupIniDir + SetupBaseName + 
".ini";
+ "/" + SetupArch() + "/" + SetupBaseName() 
+ ".ini";
  io_stream::mkpath_p (PATH_TO_FILE, fp, 0);
  if (io_stream *out = io_stream::open (fp, "wb", 0))
{
diff --git a/ini.h b/ini.h
index 2ca4f5b..05b31e0 100644
--- a/ini.h
+++ b/ini.h
@@ -24,9 +24,8 @@ typedef std::vector  IniList;

[PATCH setup 03/16] Split GuiParseFeedback out from ini fetcher

[Jon Turney via Cygwin-apps]

This will ultimately make it possible to fetch and parse an ini file
without having a GUI.
---
 Makefile.am |   1 +
 gui/GuiParseFeedback.cc | 139 
 ini.cc  | 134 ++
 ini.h   |   2 +
 4 files changed, 149 insertions(+), 127 deletions(-)
 create mode 100644 gui/GuiParseFeedback.cc

diff --git a/Makefile.am b/Makefile.am
index 8a50cb0..82efbd8 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -180,6 +180,7 @@ endif
geturl.h \
gpg-packet.cc \
gpg-packet.h \
+   gui/GuiParseFeedback.cc \
ini.cc \
ini.h \
IniDBBuilder.h \
diff --git a/gui/GuiParseFeedback.cc b/gui/GuiParseFeedback.cc
new file mode 100644
index 000..263fae1
--- /dev/null
+++ b/gui/GuiParseFeedback.cc
@@ -0,0 +1,139 @@
+/*
+ * Copyright (c) 2000,2007 Red Hat, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * A copy of the GNU General Public License can be found at
+ * http://www.gnu.org/
+ *
+ * Written by DJ Delorie 
+ *
+ */
+
+#include "Exception.h"
+#include "IniParseFeedback.h"
+#include "ini.h"
+#include "msg.h"
+#include "resource.h"
+#include "state.h"
+#include "threebar.h"
+
+extern ThreeBarProgressPage Progress;
+
+class GuiParseFeedback : public IniParseFeedback
+{
+public:
+  GuiParseFeedback () : lastpct (0)
+{
+  Progress.SetText1 (IDS_PROGRESS_PARSING);
+  Progress.SetText2 ("");
+  Progress.SetText3 ("");
+  Progress.SetText4 (IDS_PROGRESS_PROGRESS);
+
+  yyerror_count = 0;
+  yyerror_messages.clear ();
+}
+  virtual void progress (unsigned long const pos, unsigned long const max)
+{
+  if (!max)
+/* length not known or eof */
+return;
+  if (lastpct == 100)
+/* rounding down should mean this only ever fires once */
+lastpct = 0;
+  if (pos * 100 / max > lastpct)
+{
+  lastpct = pos * 100 / max;
+  /* Log (LOG_BABBLE) << lastpct << "% (" << pos << " of " << max
+<< " bytes of ini file read)" << endLog; */
+}
+  Progress.SetBar1 (pos, max);
+
+  static char buf[100];
+  sprintf (buf, "%d %%  (%ldk/%ldk)", lastpct, pos/1000, max/1000);
+  Progress.SetText3 (buf);
+}
+  virtual void iniName (const std::string& name)
+{
+  Progress.SetText2 (name.c_str ());
+  Progress.SetText3 ("");
+  filename = name;
+}
+  virtual void babble (const std::string& message)const
+{
+  Log (LOG_BABBLE) << message << endLog;
+}
+  virtual void warning (const std::string& message)const
+{
+  mbox (Progress.GetHWND(), message.c_str (), "Warning", 0);
+}
+  virtual void note_error(int lineno, const std::string )
+{
+  char tmp[16];
+  sprintf (tmp, "%d", lineno);
+
+  std::string e = filename + " line " + tmp + ": " + error;
+
+  if (!yyerror_messages.empty ())
+yyerror_messages += "\n";
+
+  yyerror_messages += e;
+  yyerror_count++;
+}
+  virtual bool has_errors () const
+{
+  return (yyerror_count > 0);
+}
+  virtual void show_errors () const
+{
+  mbox (Progress.GetHWND(), yyerror_messages.c_str (), "Parse Errors", 0);
+}
+  virtual ~ GuiParseFeedback ()
+{
+  Progress.SetText2 ("");
+  Progress.SetText3 ("");
+  Progress.SetText4 (IDS_PROGRESS_PACKAGE);
+  Progress.SetBar1 (0);
+}
+private:
+  unsigned int lastpct;
+  std::string filename;
+  std::string yyerror_messages;
+  int yyerror_count;
+};
+
+static DWORD WINAPI
+do_ini_thread_reflector (void* p)
+{
+  HANDLE *context;
+  context = (HANDLE*)p;
+
+  SetThreadUILanguage(langid);
+
+  try
+  {
+GuiParseFeedback feedback;
+bool succeeded = do_ini_thread ((HINSTANCE)context[0], (HWND)context[1], 
feedback);
+
+// Tell the progress page that we're done downloading
+Progress.PostMessageNow (WM_APP_SETUP_INI_DOWNLOAD_COMPLETE, 0, succeeded);
+  }
+  TOPLEVEL_CATCH ((HWND) context[1], "ini");
+
+  ExitThread (0);
+}
+
+static HANDLE context[2];
+
+void
+do_ini (HINSTANCE h, HWND owner)
+{
+  context[0] = h;
+  context[1] = owner;
+
+  DWORD threadID;
+  CreateThread (NULL, 0, do_ini_thread_reflector, context, 0, );
+}
diff --git a/ini.cc b/ini.cc
index 112a0ad..95c9964 100644
--- a/ini.cc
+++ b/ini.cc
@@ -33,7 +33,6 @@
 #include 
 
 #include "resource.h"
-#include "state.h"
 #include "geturl.h"
 #include "dialog.h"
 #include "mount.h"
@@ -44,17 +43,13 @@
 #include "io_stream.h"
 #include "io_stream_memory.h"
 
-#include "threebar.h"
-
 #include "getopt++/BoolOption.h"
 #include "IniDBBuilderPackage.h"
 #include "compress.h"
-#include "Exception.h"
+#include "msg.h"
 #include "crypto.h"
 #include 

[PATCH setup 04/16] Split out site into SiteSettings and SitePage

[Jon Turney via Cygwin-apps]

Again, this will ultimately make it possible to specify, or store and
retrieve from settings a site, without having a GUI.
---
 Makefile.am|   6 +-
 SiteSetting.cc | 193 +
 site.h => SiteSetting.h|  57 +++
 site.cc => gui/SitePage.cc | 169 +---
 gui/SitePage.h |  45 +
 ini.cc |   2 +-
 main.cc|   3 +-
 threebar.cc|   2 +-
 8 files changed, 264 insertions(+), 213 deletions(-)
 create mode 100644 SiteSetting.cc
 rename site.h => SiteSetting.h (74%)
 rename site.cc => gui/SitePage.cc (77%)
 create mode 100644 gui/SitePage.h

diff --git a/Makefile.am b/Makefile.am
index 82efbd8..f753961 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -266,8 +266,10 @@ endif
setup_version.c \
sha2.h \
sha2.c \
-   site.cc \
-   site.h \
+   gui/SitePage.cc \
+   gui/SitePage.h \
+   SiteSetting.cc \
+   SiteSetting.h \
source.cc \
source.h \
SourceSetting.cc \
diff --git a/SiteSetting.cc b/SiteSetting.cc
new file mode 100644
index 000..be5f5d8
--- /dev/null
+++ b/SiteSetting.cc
@@ -0,0 +1,193 @@
+/*
+ * Copyright (c) 2000, Red Hat, Inc.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * A copy of the GNU General Public License can be found at
+ * http://www.gnu.org/
+ *
+ * Written by DJ Delorie 
+ *
+ */
+
+#include "io_stream.h"
+#include "SiteSetting.h"
+#include "UserSettings.h"
+#include "getopt++/StringArrayOption.h"
+#include "getopt++/BoolOption.h"
+#include "resource.h"
+
+#include 
+#include 
+#include 
+#include 
+
+StringArrayOption SiteOption('s', "site", IDS_HELPTEXT_SITE);
+extern BoolOption UnsupportedOption;
+
+/* Selected sites */
+SiteList site_list;
+
+/* Fresh mirrors + selected sites */
+SiteList all_site_list;
+
+SiteSetting::SiteSetting (): saved (false)
+{
+  std::vector SiteOptionStrings = SiteOption;
+  if (SiteOptionStrings.size())
+{
+  for (std::vector::const_iterator n = 
SiteOptionStrings.begin ();
+   n != SiteOptionStrings.end (); ++n)
+registerSavedSite (n->c_str ());
+}
+  else
+getSavedSites ();
+}
+
+const char *
+SiteSetting::lastMirrorKey ()
+{
+  if (UnsupportedOption)
+return "last-mirror-unsupported";
+
+  return "last-mirror";
+}
+
+void
+SiteSetting::save()
+{
+  io_stream *f = UserSettings::instance().open (lastMirrorKey ());
+  if (f)
+{
+  for (SiteList::const_iterator n = site_list.begin ();
+   n != site_list.end (); ++n)
+*f << n->url;
+  delete f;
+}
+  saved = true;
+}
+
+SiteSetting::~SiteSetting ()
+{
+  if (!saved)
+save ();
+}
+
+/* List of machines that should not be used by default when saved
+   in "last-mirror". */
+#define NOSAVE1 "ftp://sourceware.org/;
+#define NOSAVE1_LEN (sizeof (NOSAVE2) - 1)
+#define NOSAVE2 "ftp://sources.redhat.com/;
+#define NOSAVE2_LEN (sizeof (NOSAVE1) - 1)
+#define NOSAVE3 "ftp://gcc.gnu.org/;
+#define NOSAVE3_LEN (sizeof (NOSAVE3) - 1)
+
+void
+SiteSetting::registerSavedSite (const char * site)
+{
+  site_list_type tempSite(site, "", "", "", false);
+
+  /* Don't default to certain machines if they suffer from bandwidth
+ limitations. */
+  if (strnicmp (site, NOSAVE1, NOSAVE1_LEN) == 0
+  || strnicmp (site, NOSAVE2, NOSAVE2_LEN) == 0
+  || strnicmp (site, NOSAVE3, NOSAVE3_LEN) == 0)
+return;
+
+  site_list_insert (all_site_list, tempSite);
+  site_list.push_back (tempSite);
+}
+
+void
+SiteSetting::getSavedSites ()
+{
+  const char *buf = UserSettings::instance().get (lastMirrorKey ());
+  if (!buf)
+return;
+  char *fg_ret = strdup (buf);
+  for (char *site = strtok (fg_ret, "\n"); site; site = strtok (NULL, "\n"))
+registerSavedSite (site);
+  free (fg_ret);
+}
+
+site_list_type::site_list_type (const std::string &_url,
+const std::string &_servername,
+const std::string &_area,
+const std::string &_location,
+bool _from_mirrors_lst,
+bool _noshow /* default: false */)
+{
+  url = _url;
+  servername = _servername;
+  area = _area;
+  location = _location;
+  from_mirrors_lst = _from_mirrors_lst;
+  noshow = _noshow;
+
+  /* Canonicalize URL to ensure it ends with a '/' */
+  if (url.at(url.length()-1) != '/')
+url.append("/");
+
+  /* displayed_url is protocol and site name part of url */
+  std::string::size_type path_offset = url.find ("/", url.find ("//") + 2);
+  displayed_url = url.substr(0, path_offset);
+
+  /* the sorting key is hostname components in reverse order (to sort by 

[PATCH setup 05/16] Don't call Antivirus::AtExit() directly from Logger::exit()

[Jon Turney via Cygwin-apps]

The call to Antivirus::AtExit() needs to be take place before we write
the log, so we see in the log if it failed. But calling it directly from
Logger::exit() is a horrible layering violation, which makes it
impossible to use the logger in other executables...

Add LogFile::atexit() method, which registers atexit handlers which are
run by LogFile::exit() before the log is closed.

The real solution here is probably not to exit via Logger::exit() all
over the place. And also perhaps to switch logfile writing from
"defered" to "immediate" once the root directory has been selected
(which establishes where the logfile should be written).

Also update a comment, out of date since 5fa64c3c.
---
 AntiVirus.cc |  4 ++--
 LogFile.cc   | 18 +-
 LogFile.h|  8 ++--
 3 files changed, 21 insertions(+), 9 deletions(-)

diff --git a/AntiVirus.cc b/AntiVirus.cc
index cc416cc..cb8e8ee 100644
--- a/AntiVirus.cc
+++ b/AntiVirus.cc
@@ -16,8 +16,7 @@
 #include "AntiVirus.h"
 
 #include "getopt++/BoolOption.h"
-
-#include "LogSingleton.h"
+#include "LogFile.h"
 
 #include "win32.h"
 #include 
@@ -77,6 +76,7 @@ bool
 AntiVirusPage::Create ()
 {
 detect();
+Logger().atexit(AntiVirus::AtExit);
 return PropertyPage::Create (NULL, dialog_cmd, IDD_VIRUS);
 }
 
diff --git a/LogFile.cc b/LogFile.cc
index ab2e3ec..0022eff 100644
--- a/LogFile.cc
+++ b/LogFile.cc
@@ -28,7 +28,6 @@
 #include 
 #include 
 #include 
-#include "AntiVirus.h"
 #include "filemanip.h"
 #include "String++.h"
 #include "getopt++/BoolOption.h"
@@ -115,12 +114,21 @@ LogFile::getFileName (int level) const
   return "";
 }
 
+void
+LogFile::atexit(void (*func)(void))
+{
+  exit_fns.push_back(func);
+}
+
 void
 LogFile::exit (int exit_code, bool show_end_install_msg)
 {
-  AntiVirus::AtExit();
+  /* Execute any functions we want to run at exit (we don't use stdlib atexit()
+ because we want to allow them to potentially write to the log) */
+  for (auto i = exit_fns.rbegin(); i != exit_fns.rend(); ++i)
+  (*i)();
+
   static int been_here = 0;
-  /* Exitcode -1 is special... */
   if (been_here)
 ::exit (exit_code);
   been_here = 1;
@@ -132,8 +140,8 @@ LogFile::exit (int exit_code, bool show_end_install_msg)
   Log (LOG_PLAIN) << "note: " << wstring_to_string(buf) << endLog;
 }
 
-  /* ... in that it skips the boring log messages.  Exit code -1 is used when
- just printing the help output and when we're self-elevating. */
+  /* Skip the log messages when just printing the help/version output, and when
+ we're self-elevating. */
   if (show_end_install_msg)
 Log (LOG_TIMESTAMP) << "Ending cygwin install" << endLog;
 
diff --git a/LogFile.h b/LogFile.h
index ddbc2dc..8efa1b0 100644
--- a/LogFile.h
+++ b/LogFile.h
@@ -18,6 +18,7 @@
 
 #include "LogSingleton.h"
 #include 
+#include 
 
 // Logging class. Default logging level is PLAIN.
 class LogFile : public LogSingleton {
@@ -36,18 +37,21 @@ public:
* but doesn't call generic C++ destructors
*/
   virtual void exit (int exit_code, bool show_end_install_msg = true)
- __attribute__ ((noreturn));
+  __attribute__ ((noreturn));
+  virtual void atexit( void (*func)(void));
+
   virtual void flushAll ();
   virtual ~LogFile();
   // get a specific verbosity stream.
   virtual std::ostream () (enum log_level level);
-  
+
 protected:
   LogFile(std::stringbuf *aStream);
   LogFile (LogFile const &); // no copy constructor
   LogFile  = (LogFile const&); // no assignment operator
   virtual void endEntry(); // the current in-progress entry is complete.
   static int exit_msg;
+  std::vector  exit_fns;
 private:
   void log_save (int babble, const std::string& filename, bool append);
 };
-- 
2.43.0

[PATCH setup 02/16] Move setup_exts[] to the only place it's used

[Jon Turney via Cygwin-apps]

---
 ini.cc | 1 +
 ini.h  | 2 +-
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/ini.cc b/ini.cc
index 3ef1311..112a0ad 100644
--- a/ini.cc
+++ b/ini.cc
@@ -58,6 +58,7 @@ extern ThreeBarProgressPage Progress;
 unsigned int setup_timestamp = 0;
 std::string ini_setup_version;
 // TODO: use C++11x initializer lists instead and drop the literal array
+static const std::string setup_exts[] = { "zst", "xz", "bz2", "ini" };
 IniList setup_ext_list (setup_exts,
setup_exts + (sizeof(setup_exts) / 
sizeof(*setup_exts)));
 
diff --git a/ini.h b/ini.h
index d4eaf87..4088968 100644
--- a/ini.h
+++ b/ini.h
@@ -21,7 +21,7 @@
 
 typedef std::vector  IniList;
 extern IniList found_ini_list, setup_ext_list;
-const std::string setup_exts[] = { "zst", "xz", "bz2", "ini" };
+
 extern bool is_64bit;
 extern bool is_new_install;
 extern std::string SetupArch;
-- 
2.43.0

[PATCH setup 01/16] Drop forward declaration of non-existent class IniState

[Jon Turney via Cygwin-apps]

Also: move forward declaration of class io_stream after includes with
other forward declarations.
---
 ini.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/ini.h b/ini.h
index ecc4b78..d4eaf87 100644
--- a/ini.h
+++ b/ini.h
@@ -16,7 +16,6 @@
 #ifndef SETUP_INI_H
 #define SETUP_INI_H
 
-class io_stream;
 #include 
 #include 
 
@@ -29,10 +28,11 @@ extern std::string SetupArch;
 extern std::string SetupIniDir;
 extern std::string SetupBaseName;
 
-class IniState;
+class io_stream;
 class IniDBBuilder;
 class IniParseFeedback;
 void ini_init (io_stream *, IniDBBuilder *, IniParseFeedback &);
+
 #define YYSTYPE char *
 
 /* When setup.ini is parsed, the information is stored according to
-- 
2.43.0

[PATCH setup 00/16] Groundwork for a GUI-less installation tool

[Jon Turney via Cygwin-apps]

This is patch sequence I started sometime in 2020, but only got around to
finishing off recently.

This includes various small tidy-ups, and then lays some groundwork for a
command line installation tool.

At the moment, all this can do is retrieve a (compressed) setup.ini from a
selected mirror and parse it. Package fetching and installation etc. remain
to be looked at.

Jon Turney (16):
  Drop forward declaration of non-existent class IniState
  Move setup_exts[] to the only place it's used
  Split GuiParseFeedback out from ini fetcher
  Split out site into SiteSettings and SitePage
  Don't call Antivirus::AtExit() directly from Logger::exit()
  Simplify invocation of UserSettings::open_settings()
  Split out URL fetching progress reporting
  Instantiate found_ini_list in ini.cc
  Move is_64bit to state
  Move setup.ini pathame components to ini.cc
  Drop hinstance global
  Spit out GetNetAuth from NetIO
  Split out hash checking progress reporting
  Push check_for_cached into package_source
  Put various shared subcomponents into a convenience library
  Add beginnings of a command line installation tool

 AntiVirus.cc  |   4 +-
 CliParseFeedback.h|  28 --
 Feedback.h|  58 
 GetNetAuth.h  |  30 ++
 IniDBBuilderPackage.cc|   4 +-
 IniDBBuilderPackage.h |   6 +-
 IniParseFeedback.h|  38 ---
 LogFile.cc|  18 +-
 LogFile.h |   8 +-
 Makefile.am   | 284 ++
 SiteSetting.cc| 193 
 site.h => SiteSetting.h   |  57 +---
 UserSettings.cc   |  12 +-
 UserSettings.h|   4 +-
 choose.cc |   4 +-
 cli/CliFeedback.h |  60 
 cli/CliGetNetAuth.cc  |  45 +++
 cli/CliGetNetAuth.h   |  32 ++
 cli/CliGetUrlFeedback.cc  |  91 ++
 cli/CliHashCheckFeedback.cc   |  30 ++
 .../CliParseFeedback.cc   |  28 +-
 cli/cyclops.cc| 186 
 crypto.cc |  18 +-
 crypto.h  |   9 +-
 dialog.h  |   3 -
 download.cc   | 121 +---
 download.h|   6 -
 fromcwd.cc|  11 +-
 geturl.cc | 130 ++--
 geturl.h  |  13 +-
 gui/GuiFeedback.h |  69 +
 gui/GuiGetNetAuth.cc  | 138 +
 gui/GuiGetNetAuth.h   |  38 +++
 gui/GuiGetUrlFeedback.cc  | 119 
 gui/GuiHashCheckFeedback.cc   |  34 +++
 gui/GuiParseFeedback.cc   | 149 +
 site.cc => gui/SitePage.cc| 191 +---
 gui/SitePage.h|  45 +++
 ini.cc| 178 +++
 ini.h |  19 +-
 inilex.ll |   6 +-
 inilintmain.cc|  10 +-
 install.cc|   6 +-
 main.cc   |  50 ++-
 msg.cc|   5 +-
 net.cc|   5 +
 netio.cc  | 125 +---
 netio.h   |  19 +-
 nio-ie5.cc|   4 +-
 package_db.cc |   6 +-
 package_db.h  |   3 +-
 package_meta.cc   |  11 +-
 package_meta.h|   5 +-
 package_source.cc | 126 ++--
 package_source.h  |  12 +-
 splash.cc |   2 +-
 state.cc  |   6 +
 state.h   |   2 +
 threebar.cc   |   2 +-
 59 files changed, 1853 insertions(+), 1063 deletions(-)
 delete mode 100644 CliParseFeedback.h
 create mode 100644 Feedback.h
 create mode 100644 GetNetAuth.h
 delete mode 100644 IniParseFeedback.h
 create mode 100644 SiteSetting.cc
 rename site.h => SiteSetting.h (74%)
 create mode 100644 cli/CliFeedback.h
 create mode 100644 cli/CliGetNetAuth.cc
 create mode 100644 cli/CliGetNetAuth.h
 create mode 100644 cli/CliGetUrlFeedback.cc
 create mo

Re: [ITP] afflib 3.7.20-1

[Jon Turney via Cygwin-apps]

On 06/03/2024 15:39, Christian Franke via Cygwin-apps wrote:

Jon Turney wrote:


Thanks!



libafflib_CONTENTS="
usr/bin/cygafflib-*.dll


Any reason why this package doesn't include the soversion, i.e. why 
not libafflib0?




Libtsk and libafflib are my first library packages, so I'm not sure what 
the policy is. My recent package libtsk has been accepted without 
soversion, so I omitted it also here. I assumed that the soversion will 


I'm going to suggest that was an oversight in the review.

be added only when needed for new not backward compatible releases. The 
upstream afflib project is mostly idling, so I don't expect any new 
major lib versions in the near future.


If course, I could rename it to libafflib0 if desired.


As far as I know, there is no cost for doing this, and it saves grief if 
upstream ever bumps the soversion.


Also, it's probably best to explicitly list the filename with soversion 
in the CONTENTS, so that if upstream ever does change the soversion, it 
will be detected as a packaging failure, rather than producing a package 
with a mismatch between the soversion in it's name and in it's contents.


(Cygport should perhaps and detect and warn about apparently soversioned 
libraries that aren't in appropriately named packages, but...)

Re: [ITP] afflib 3.7.20-1

[Jon Turney via Cygwin-apps]

Thanks!



libafflib_CONTENTS="
usr/bin/cygafflib-*.dll


Any reason why this package doesn't include the soversion, i.e. why not 
libafflib0?



rm -v usr/bin/affuse.exe usr/share/man/man1/affuse.1 # --disable-fuse


I guess this comment means something to someone.  But it doesn't tell me 
anything...

Re: mingw cross tests missing DLLs - CROSS_BINDIR not in PATH

[Jon Turney via Cygwin-apps]

On 04/03/2024 21:20, Brian Inglis via Cygwin-apps wrote:

On 2024-03-04 13:00, Jon Turney wrote:

On 03/03/2024 22:29, Brian Inglis via Cygwin-apps wrote:

On 2024-03-03 14:39, Jon Turney via Cygwin-apps wrote:

On 03/03/2024 16:48, Brian Inglis via Cygwin-apps wrote:
I am finding mingw package cross tests fail with missing DLLs - 
CROSS_BINDIR is not in the PATH.


I now have to define src_test to run cygtest adding CROSS_BINDIR in 
the PATH.


Is this likely to be upstream (e.g. gnulib) changes or cygport 
changes?


This is a shortcoming of cygport, in that you cannot just write "do 
the standard src_(compile|install|test), but do this extra thing 
first (like modifying PATH as you need in this case).


(One approach to this I've though about would be to have a hook 
function (or set of functions) which are called before each phase of 
operation, to allow this)


These test failures have been only in the latest upstream releases.
Previously no PATH fiddling was required.
For mingw64-x86_64-nghttp2 that was 2024-01-21.

Why I asked if anyone noticed any cross build changes as for example 
in autotools, gnulib, or cygport?


I assumed that you were talking about "PATH needs to be set so that 
dependencies of the built DLL can be loaded"


But, now I look, mingw64-x86_64-nghttp2 doesn't have any dependencies.

So, I'm not so sure. Maybe you just mean that the test harness can't 
locate the just built DLL? That could well be an upstream change.


Maybe you could show the actual error?


Sorry I was not clearer.
In previous release build checks there were no issues.


Have you tried rebuilding and running the tests for the previous release 
version of nghttp2? This might at least offer some clue as to if the 
change is in upstream, or in the toolchain or build environment?


In the latest release the test programs have a dependency on winpthreads 
and failed with popup dialogues:


I see.

Well, to reiterate, if the test genuinely depends on that DLL, this 
behavior is to be expected, because cygport (currently) lacks a feature 
to add CROSS_BINDIR to the PATH before running tests.



To me, the obvious theories to explore are that:

* the previous version of nghttp2 did not link it's tests with that DLL 
(e.g. an upstream change has been made to parallelize the tests, or add 
testing coverage for multithreaded use)


* the previous version of nghttp2 arranged to link it's tests statically 
with the required library, and no longer does so


* the MinGW cross winpthreads packages have stopped providing the static 
library (from a brief check, this does not seem to be the case)



Hope that's of some help.

Re: mingw cross tests missing DLLs - CROSS_BINDIR not in PATH

[Jon Turney via Cygwin-apps]

On 03/03/2024 22:29, Brian Inglis via Cygwin-apps wrote:

On 2024-03-03 14:39, Jon Turney via Cygwin-apps wrote:

On 03/03/2024 16:48, Brian Inglis via Cygwin-apps wrote:
I am finding mingw package cross tests fail with missing DLLs - 
CROSS_BINDIR is not in the PATH.


I now have to define src_test to run cygtest adding CROSS_BINDIR in 
the PATH.


Is this likely to be upstream (e.g. gnulib) changes or cygport changes?


This is a shortcoming of cygport, in that you cannot just write "do 
the standard src_(compile|install|test), but do this extra thing first 
(like modifying PATH as you need in this case).


(One approach to this I've though about would be to have a hook 
function (or set of functions) which are called before each phase of 
operation, to allow this)


These test failures have been only in the latest upstream releases.
Previously no PATH fiddling was required.
For mingw64-x86_64-nghttp2 that was 2024-01-21.

Why I asked if anyone noticed any cross build changes as for example in 
autotools, gnulib, or cygport?


I assumed that you were talking about "PATH needs to be set so that 
dependencies of the built DLL can be loaded"


But, now I look, mingw64-x86_64-nghttp2 doesn't have any dependencies.

So, I'm not so sure. Maybe you just mean that the test harness can't 
locate the just built DLL? That could well be an upstream change.


Maybe you could show the actual error?

gdb 14.2-1 (TEST)

[Jon Turney via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* gdb-14.2-1
* gdb-debuginfo-14.2-1
* gdb-multiarch-14.2-1

The GNU debugger, allows you to debug programs written in C, C++,
and other languages, by executing them in a controlled fashion
and printing their data.

This is an update to the latest upstream version:

https://sourceware.org/pipermail/gdb-announce/2024/000138.html

See the /usr/share/doc/gdb/NEWS file for a list of user-visible changes.

In addition, it contains the following patches carried forward from the 
previous Cygwin package:

* Teach the demangler to deal with '@'-decorated __stdcall functions
* (experimental) Teach gdb how to unwind frames for the Cygwin signal delivery 
wrapper functions _sigbe and sigdelayed
* Fix a memory leak which would occur in the case when the result of realpath() 
is greater than or equal to SO_NAME_MAX_PATH_SIZE (Corinna Vinschen)
* Simplify and improve handling of inferior context after a Cygwin signal
* Use cygwin pgid if inferior is a cygwin process (Takashi Yano)


-- 
  *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
.

Re: mingw cross tests missing DLLs - CROSS_BINDIR not in PATH

[Jon Turney via Cygwin-apps]

On 03/03/2024 16:48, Brian Inglis via Cygwin-apps wrote:

Hi folks,

I am finding mingw package cross tests fail with missing DLLs - 
CROSS_BINDIR is not in the PATH.


I now have to define src_test to run cygtest adding CROSS_BINDIR in the 
PATH.


Is this likely to be upstream (e.g. gnulib) changes or cygport changes?


This is a shortcoming of cygport, in that you cannot just write "do the 
standard src_(compile|install|test), but do this extra thing first (like 
modifying PATH as you need in this case).


(One approach to this I've though about would be to have a hook function 
(or set of functions) which are called before each phase of operation, 
to allow this)

Re: Setup 2.930: 'user_picked' flag not set for packages selected with -P option

[Jon Turney via Cygwin]

On 03/03/2024 14:42, Christian Franke via Cygwin wrote:
Setup 2.930 does not set the 'user_picked' flag in 
/etc/setup/installed.db if a package has been selected with the -P 
option instead of the chooser dialog.


An installation could be replicated by extracting a list of 
'user_picked' packages from installed.db and pass it via -P to setup. 
But in this new installation, all non-Base packages will appear in 
"Unneeded" view then.


I guess this is not a regression but longstanding behavior.


Hmm... I certainly envisioned it working that way when I added recording 
user_picked (See comments on [1], [2]), but I can believe it's got 
broken at some point...


[1] 
https://cygwin.com/cgit/cygwin-apps/setup/commit/?id=f6d6c600edffdb83a57ed13384e38a504fdc366b
[2] 
https://cygwin.com/cgit/cygwin-apps/setup/commit/?id=dbd295e75edfadd5fc6feebe11b482cd672575cf



No patch provided for now as I don't know the best way to change this.


But yes, this is definitely a bug!


--
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: scallyweg: ‘strcasecmp’ was not declared in this scope

[Jon Turney via Cygwin-apps]

On 02/03/2024 17:01, Marco Atzeri via Cygwin-apps wrote:

On 29/02/2024 17:58, Jon Turney wrote:

On 29/02/2024 06:21, Marco Atzeri via Cygwin-apps wrote:

Hi Jon,

I have a strange case with nco

https://github.com/cygwin/scallywag/actions/runs/8060036334/job/22015501908

While Scallyweg complains about ‘strcasecmp’ scope,
local build runs fine.
I saw the same also on previous build

Can you check ?


I can reproduce the build failure locally.

 From a brief inspection, this seems to make sense: strcasecmp is 
unconditionally defined by strings.h, which doesn't seem to be 
included anywhere in antlr.


(There's maybe some way it gets indirectly included, maybe via 
string.h if __BSD_VISIBLE, but perhaps that's due to some local flags 
settings?)




thanks for double checking


No problem.


The problem was subtle; the original and ancient

  https://www.antlr2.org/download/antlr-2.7.7.tar.gz

need patching to work with recent compiler.
I had a different version, with the same name, on my computer
but I forgot to update the SRC_URI, so me locally and scallyweg were 
working on different source packages.


Further info on:
https://nco.sourceforge.net/#Source


Aha! Two archives with the same name but different contents, always great.

There really ought to be a list of hashes for SRC_URI files associated 
with a .cygport file, and cygport should verify them after downloading 
(which would avoid this problem, and related ones), but we've needed 
that feature for a while...

Re: scallyweg: ‘strcasecmp’ was not declared in this scope

[Jon Turney via Cygwin-apps]

On 29/02/2024 06:21, Marco Atzeri via Cygwin-apps wrote:

Hi Jon,

I have a strange case with nco

https://github.com/cygwin/scallywag/actions/runs/8060036334/job/22015501908

While Scallyweg complains about ‘strcasecmp’ scope,
local build runs fine.
I saw the same also on previous build

Can you check ?


I can reproduce the build failure locally.

From a brief inspection, this seems to make sense: strcasecmp is 
unconditionally defined by strings.h, which doesn't seem to be included 
anywhere in antlr.


(There's maybe some way it gets indirectly included, maybe via string.h 
if __BSD_VISIBLE, but perhaps that's due to some local flags settings?)

Re: [PATCH cygport] Add more checks of SOURCE_DATE_EPOCH

[Jon Turney via Cygwin-apps]

On 16/02/2024 12:29, Christian Franke via Cygwin-apps wrote:
Fail if it is out of range. Warn if it lies in the future. Inform 
whether it is set or set but not exported.


What is the valid range here?

Would it not make more sense to just re-export it if set? (so that 
commands like "SOURCE_DATE_EPOCH=something cygport foo" work as expected?)

Re: [cygport] enabling a replacement for "objdump -d -l"

[Jon Turney via Cygwin-apps]

Thanks, this is great!

On 18/02/2024 19:51, ASSI via Cygwin-apps wrote:



[...]

dwarf-parse.-pl


There should be some build system changes which install this file, 
probably in /usr/share/cygport/tools/, which it can then be run from.



--8<---cut here---start->8---


Please, please make a patch with git format-patch, which I can then just 
apply.



#!perl -w


Fifty lines of perl with no comments! This is just line noise to me 
unless I spend lots of time staring at it :)


Seriously, this should at least say "I'm running objdump -Wl to dump out 
the .debug_line section containing DWARF XYZ information.


Then maybe some comments about what assumptions it's making about the 
human-readable output it's parsing.



use common::sense;
use List::Util qw( sum );

my $filter = shift @ARGV
 or die "not enough arguments";
my $obj = shift @ARGV
 or die "not enough arguments";
my @objdump = qw( /usr/bin/objdump -WNl );


cygport goes to some lengths to identify the correct objdump to use when 
cross-building, so it should probably should be used here (passed in as 
an arg?), rather than assuming it's /usr/bin/objdump.



open my $DWARF, "-|", @objdump, $obj
 or die "can't invoke objdump\n$!";

my ( @dirs, @files, %fn, %rn );
while (<$DWARF>) {
 if (/^ The Directory Table/../^$/) {
if (/^  \d+/) {

my ( $entry, $dir ) = m/^  (\d+)\t.+: (.+)$/;
$dir = "$dirs[0]/$dir" if ($dir =~ m:\A[^/]:);
push @dirs, $dir;
}
 }
 if (/^ The File Name Table/../^$/) {
if (/^  \d+/) {
my ( $idx, $fn, undef ) = m/^  \d+\t(\d+)\t.+: (.+)$/;
$rn{"$dirs[$idx]/$fn"}++;
push @files, "$dirs[$idx]/$fn";
}
 }
 if (my $rc = /^ Line Number Statements/../^  Offset:/) {
$fn{"$files[0]"}++ if ($rc == 1);
$fn{"$files[$1]"}++ if m/ Set File Name to entry (\d+) in the File Name 
Table/;


What this line is doing is obvious, the rest of this block, not so much.

You might also like to touch on why we bother looking at the line number 
information at all, rather than just producing a (filtered) list of all 
the pathnames mentioned?



@files = () if ($rc =~ m/E0$/);
@dirs  = () if ($rc =~ m/E0$/);
 }
 if (/^ No Line Number Statements./../^$/) {
@files = ();
@dirs  = ();
 }
}
foreach my $fn (grep m:^$filter:, sort keys %fn) {
 say sprintf "%s", $fn;
}
say STDERR sprintf "\tLNS: %6d (%6d locations) <=> FNT: %6d ( %6d locations)",
 0+grep( m:^$filter:, keys %fn ), sum( values %fn ),
 0+grep( m:^$filter:, keys %rn ), sum( values %rn )
 if (0);


If you're going to keep this (which you probably should), perhaps it 
should be under some 'if (DEBUG)' conditional.




close $DWARF
 or die "failed to close objdump\n$!";
--8<---cut here---end--->8---

Integration into cygport is made configurable via a variable to be set
in .cygportrc for instance in order to easily revert back to the
original objdump invocation if necessary.  I've been producing packages


DWARF_PARSE should be mentioned in the documentation for cygport.conf

Since the helper script will be installed, it could be made a boolean.


with that setup for a while now and have not noticed any errors.  In
principle the new parser actually produces more complete output as there
can be multiple line number statements and hence source files per
location, but objdump only lists one of them in the disassembly (at
least sometimes).  In practise I haven't found a package until now where
the final list (after filtering) is different.

--8<---cut here---start->8---
lib/src_postinst.cygpart: use DWARF_PARSE optionally instead of objdump -dl
---

diff --git a/lib/src_postinst.cygpart b/lib/src_postinst.cygpart
index f06004e4..3dd6e893 100644
--- a/lib/src_postinst.cygpart
+++ b/lib/src_postinst.cygpart
@@ -1096,7 +1096,12 @@ __prepstrip_one() {
else
dbg="/usr/lib/debug/${exe}.dbg";
  
-		lines=$(${objdump} -d -l "${exe}" 2>/dev/null | sed -ne "s|.*\(/usr/src/debug/${PF}/.*\):[0-9]*$|\1|gp" | sort -u | tee -a ${T}/.dbgsrc.out.${oxt} | wc -l);

+   if defined DWARF_PARSE
+   then
+   lines=$(${DWARF_PARSE} /usr/src/debug/${PF}/ "${exe}" | 
tee -a ${T}/.dbgsrc.out.${oxt} | wc -l);
+   else
+   lines=$(${objdump} -d -l "${exe}" 2>/dev/null | sed -ne 
"s|.*\(/usr/src/debug/${PF}/.*\):[0-9]*$|\1|gp" | sort -u | tee -a ${T}/.dbgsrc.out.${oxt} | 
wc -l);
+   fi
  
  		# we expect --add-gnu-debuglink to fail if a

# .gnu_debuglink section already exists (e.g. binutils,
--8<---cut here---end--->8---

Re: LXDE rears its ugly head :-)

[Jon Turney via Cygwin]

On 24/02/2024 23:31, sciguy via Cygwin wrote:

Hello

I am using Cygwin-X on Windows 10. It is a version from around 2020 or 
so. The window managers (I have a few that I have installed) seem to 
work, but it appears that LXDE likes to cover the toolbars and menubars, 
especially when GNOME is supposed to be running. Even if I "log off" of 
LXDE (which doesn't have any effect on GNOME), the LXDE toolbar, after a 
few minutes, covers the native GNOME toolbar.


Can you perhaps explain how you are starting the session where you see 
this problem?


It should only be possible to have one window manager running at a time 
on a given X display, so I'm not quite sure what you are describing here.


In fact, the GNOME toolbar can be exposed, but like a game of 
peek-a-boo, the LXDE toolbar reappears when my mouse moves close to it. 
It also shows up under KDE (which doesn't seem to have a working 
toolbar). If I run fluxbox, there is no LXDE running.


Is there supposed to be a reason why a LXDE toolbar has to appear in a 
non-LXDE window manager? Is there somewhere where I can turn off this 
setting (assuming that's all there is).


I assume this is something in the Xsession init scripts (which are 
unfortunately complex) which is launching the "toolbar" unconditionally.


Unless you want to dive into those, uninstalling the package which 
provides the unwanted program might be the way to go.



I'm afraid all the "Desktop Environments" we currently ship are rather 
old and unmaintained.  Somewhere in my vast backlog of stuff, I'd like 
to (a) remove the heavyweight ones i.e. GNOME and KDE, and (b) update 
the others which are actually used by someone.  But that seems 
increasingly unlikely to happen.



--
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: Fwd: calm: cygwin package report for Ken Brown

[Jon Turney via Cygwin-apps]

On 19/02/2024 18:59, Ken Brown via Cygwin-apps wrote:

On 3/20/2023 7:17 PM, Jon Turney wrote:

On 20/03/2023 22:17, Ken Brown via Cygwin-apps wrote:
It looks like my plan for having scallywag deploy all the TeX Live 
packages won't work (see below).  calm would have to be more 
permissive and allow deploying a package that requires something that 
will be provided by a future package.


In this case, I made asymptote require tl_2023, which will be 
provided by the next texlive release.  But I don't want to deploy the 
latter until all the other packages for TeX Live 2023 have been 
deployed.


Unless this is easy to fix, I'll just forget about using scallywag 
and go back to my old method of uploading everything manually.


This is trivially fixable.

calm already has a list of 'provides which don't exist (yet)', so I 
think I just need to add tl_2023 and tl_basic_2023 to that list


Future work: make these regexes so we don't have same problem again in 
a years time.


Jon,

In preparation for TeX Live 2024, please add tl_2024 and tl_basic_2024 
to the list of provides which don't exist yet (unless you've already 
done the regex future work).


These are controlled by regex now, so these should already be permitted, 
and I don't need to do anything (yay!):


'tl_\d+'
'tl_basic_\d+'

Re: [PATCH cygport] git.cygclass: Suppress the depth option

[Jon Turney via Cygwin-apps]

On 16/02/2024 11:59, Daisuke Fujimura via Cygwin-apps wrote:

Thank you for merging.

I have confirmed that this modification has resulted in the intended behaviour.


[...]


$ head -3 agbsum-15-1bl1.cygport
HOMEPAGE="https://mandelbrot.dk/${PN};
GIT_URI="https://mandelbrot.dk/${PN};
GIT_TAG="${PV}"

$ cygport agbsum-15-1bl1.cygport fetch
*** Info: Trying to enable case sensitivity on /tmp/agbsum/agbsum-15-1bl1.x86_64
git clone --depth 1 --branch 15 --no-checkout
https://mandelbrot.dk/agbsum agbsum
Cloning into 'agbsum'...
fatal: dumb http transport does not support shallow capabilities
*** Warning: git clone failed, retrying without --depth option
git clone --branch 15 --no-checkout https://mandelbrot.dk/agbsum agbsum
Cloning into 'agbsum'...
Fetching objects: 251, done.
git checkout tags/15
HEAD is now at bef1780 Rename source directory: 'src' => 'source';
Update naming convention; Update copyright holder name; Update code
style;

```


Thank you very much for testing!

Re: [ITA] libid3tag

[Jon Turney via Cygwin-apps]

On 17/02/2024 13:43, Marco Atzeri via Cygwin-apps wrote:

On 17/02/2024 04:18, Takashi Yano via Cygwin-apps wrote:

I would like to adopt libid3tag.




$ git diff | grep ^+
+++ b/cygwin-pkg-maint
+libid3tag    Takashi Yano
+libmad   Takashi Yano
+taglib   Takashi Yano
+taglib-extras    Takashi Yano
+utf8cpp  Takashi Yano

Thanks
Marco



FWIW, I took a look at these cygports and couldn't find anything to 
comment on. Good job!


Thanks for adopting these.

Re: Suggestion: [setup] Add an option to allow user to add "Open Cygwin Terminal Here" to Right-click menu

[Jon Turney via Cygwin]

On 13/02/2024 20:30, Dan Shelton via Cygwin wrote:

On Sat, 10 Feb 2024 at 05:21, Yang Yu Lin via Cygwin  wrote:


It would be convenient for users to open specific folder in terminal by just 
right-click it, like Git Bash and Windows Terminal.


[...]


Yes, please, it would be cool to have this as DEFAULT in the MS
Explorer right-click context menu for dirs


Yeah, this seems like a good idea. Someone should do that. :)


I think the place to start might be with improving the integration of 
the 'chere' package, so it has a postinstall/preremove script to 
create/remove a context menu entry to start bash under mintty.


(I don't understand quite why chere can't give you "the shell you 
currently have configured in /etc/passwd" (i.e. 'mintty -') rather than 
having all of them as options...)



Then the  next step would probably be adding the option/checkbox to 
setup and exposing it to that script via CYGWIN_SETUP_OPTIONS.



[1] https://cygwin.com/packaging-package-files.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: Tmux crashes on copy

[Jon Turney via Cygwin-apps]

On 14/02/2024 00:11, Yasuhiro Kimura via Cygwin-apps wrote:

Hello,

From: Jon Turney via Cygwin-apps 

Subject: Re: Tmux crashes on copy
Date: Wed, 31 Jan 2024 13:28:41 +


Thanks.

Since this is a crash bug, which renders the package more or less
useless, I made an NMU with these changes.


Michael,

Sorry about not pinging you before I made this change.

You don't seem to have been active for a few years. Are you still
interesting in maintaining this package?

IF so, do you want to get pinged if/when problems crop up?



Tmux 3.4 is released.

https://github.com/tmux/tmux/releases/tag/3.4

Just FYI.


Thanks.

I don't use tmux, so if I were to just bump the version, I'd just be 
deploying the updated package without any testing, which is something I 
try to avoid doing.


If an up-to-date and working tmux package is important to you, please 
consider if maybe you want to adopt it? (I'm assuming the existing 
maintainer has wandered off since he didn't reply, but our process 
requires me to wait a bit longer before that's assumed)


Even if you don't, maybe you would consider submitting an ssh key, so 
you can push to our package building playground, which would make it a 
bit less effort for me in future, if you submit other NMUs.

Re: cygport 0.36.8-1

[Jon Turney via Cygwin]

On 13/02/2024 13:02, Christian Franke via Cygwin wrote:

Jon Turney via Cygwin wrote:

On 12/02/2024 16:49, ASSI via Cygwin wrote:

Christian Franke via Cygwin writes:

This requires that always the same build directory is used.


Would that be solvable by using -ffile-prefix-map or is there more to
it?


That should now be used in 0.36.8, so something else leaking the local 
build directory into the package, perhaps


A closer look shows that (only) the pathnames of the assembly (*.S) 
files in cygwin1.dll.dbg now contain the build path instead of the 
mapped path:


$ strings cygwin1.dll.dbg | grep '^/.*bcopy\.S$' | uniq
/tmp/build/cygwin-3.5.0-1.x86_64/src/newlib-cygwin/winsup/cygwin/x86_64/bcopy.S

The paths in the released package are correct:

$ strings /usr/lib/debug/usr/bin/cygwin1.dll.dbg | grep '^/.*bcopy\.S$' 
| uniq

/usr/src/debug/cygwin-3.5.0-1/winsup/cygwin/x86_64/bcopy.S

The regression was introduced by cygport commit 9e82685 in conjunction 
with the fact that --file-prefix-map has no effect on *.S files:


Great.  I guess that means we need to use both options.



Also gcc builtin specs show that --file-prefix-map is not handled for asm:

$ gcc -dumpspecs | fgrep -A1 '*asm_debug:'
*asm_debug:
%{%:debug-level-gt(0):%{gstabs*:--gstabs;:%{g*:}}} 
%{fdebug-prefix-map=*:--debug-prefix-map %*}




This kind of seems like a bug.


--
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: Running setup-x86_64.exe from cmd does nothing but works from cygwin itself

[Jon Turney via Cygwin]

On 12/02/2024 21:37, matthew patton via Cygwin wrote:

If you really suspect some AV problems, it may help to try the>
uncompressed setup executable, available from [1]

Huh, when did this start? Nobody pays by BW anymore so what was the


Firstly, do not send me personal email.


I think we started providing setup as a UPX compressed executable in 
2002 or 2003.  In any case, long before my involvement.


Certainly there's an argument for *not* doing it these days, although 
your assertion that "nobody pays for BW" seems likely to be based on 
your personal perspective, rather than a survey of Cygwin users globally.


I've recently started providing the uncompressed executable *in addition 
to* the compressed one (because people occasionally have problems where 
their AV won't let them run *any* UPX compressed program).



rationale behind a "self altering" executable? No wonder it would
experience havoc in an A/V environment since the extracted temp file
may well be located on a non-executable location and or EXEC would
have been shimmed by AV and it doesn't correctly return control from
an ephemeral location.


You're making assumptions here about how the decompression stub works, 
which I don't think are accurate for UPX.



--
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: cygport 0.36.8-1

[Jon Turney via Cygwin]

On 12/02/2024 16:49, ASSI via Cygwin wrote:

Christian Franke via Cygwin writes:

This requires that always the same build directory is used.


Would that be solvable by using -ffile-prefix-map or is there more to
it?


That should now be used in 0.36.8, so something else leaking the local 
build directory into the package, perhaps.



--
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: Running setup-x86_64.exe from cmd does nothing but works from cygwin itself

[Jon Turney via Cygwin]

On 12/02/2024 01:05, wsnyder--- via Cygwin wrote:

I have a Windows Version 10.0.19044 Build 19044 system with Cygwin
installed a while ago.

Opening the cygwin terminal (which works fine), I see it is running:

CYGWIN_NT-10.0-19044 version 3.3.6-341.x86_64 (corinna@calimero) (gcc
version 11.2.0 20210728 (Fedora Cygwin 11.2.0-2) (GCC) ) 2022-09-05
11:15 UTC

I needed to install some packages so downloaded setup-x86_64.exe onto
my desktop. When I run it from the desktop I get the "busy" cursor
for a fraction of a second and nothing happens.  When I open the
native Windows cmd prompt as administrator, and run
"setup-x86_64.exe" or "setup-x86_64.exe -v" or "setup-x86_64.exe
--asdjasdjaskdhj", I just get the prompt back.

If, however I startup the cygwin terminal (vs cmd window) and run
setup-x86_64.exe, it starts correctly.  However I'm afraid to run it
this way as if it crashes I'll presumably never be able to run setup
again.


This seems highly speculative.


This is a work machine so while I have admin, it's completely
possible they've added some broken virus checker rule that is now
preventing it from running. But, I get no alert, which I normally
would doing something unusual, and that it works under cygwin itself
seems odd.

This is very odd behaviour.

If you really suspect some AV problems, it may help to try the 
uncompressed setup executable, available from [1]



[1] https://cygwin.com/setup/

--
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: [PATCH cygport] git.cygclass: Suppress the depth option

[Jon Turney via Cygwin-apps]

On 03/12/2023 21:53, Brian Inglis via Cygwin-apps wrote:

On 2023-12-03 13:34, Jon Turney via Cygwin-apps wrote:

On 30/11/2023 12:17, Daisuke Fujimura via Cygwin-apps wrote:

Implementations that conditionally branch on variables are simple.

The proposed retry implementation complicates git.cygclass, but I
think it reduces the maintainer's effort.

I have created a patch for a retry implementation.
Could you review it?




Thanks very much to Fujimura-san for all his work on this.


Attached is the patch after my edits.


I've applied a reheated version of this patch. Hopefully that works well 
enough, but obviously can be further refined if needed.


Looks like straight curl HEAD -I tells you about smart transport if you 
want a quick check rather than a dry run:


$ time curl -ILSs 
https://repo.or.cz/r/git.git/info/refs?service=git-upload-pack | grep 
-qi '^content-type:\sapplication/x-git-upload-pack'; echo $?


real    0m0.630s
user    0m0.077s
sys 0m0.123s
0
$ time curl -ILSs 
https://github.com/BrianInglis/apt-cyg.git/info/refs?service=git-upload-pack  | grep -qi '^content-type:\sapplication/x-git-upload-pack'; echo $?


real    0m0.440s
user    0m0.061s
sys 0m0.184s
1


Thanks for this.

Uh, but it seems like 'git clone --depth 1' works with both of these 
URLs, so... um... I'm not sure what's going on.

Re: [PATCH cygport] Increase _FORTIFY_SOURCE level from 2 to 3 in CFLAGS

[Jon Turney via Cygwin-apps]

On 04/02/2024 16:30, Christian Franke via Cygwin-apps wrote:

Jon Turney wrote:

On 02/02/2024 16:13, Christian Franke via Cygwin-apps wrote:
_FORTIFY_SOURCE=3 is supported by Cygwin 3.5.0 headers and Cygwin gcc 
13.2.1 test release.


Silently falls back to level 2 if level 3 is unsupported (older 
headers or gcc) or to level 0 if unsupported at all (C++, clang).


Thanks. I applied this.

I'm thinking I want to try to do another cygport release fairly 
soonish, so please feel free to remind me about any other patches by 
you (or others) which I need to look at before then.




Possibly some initial SOURCE_DATE_EPOCH support:
https://sourceware.org/pipermail/cygwin-apps/2023-August/043108.html


I've applied this (and I think I might have caught up on most of the 
pending patches...)


It would be nice to have some sort of test, since there's no coverage 
with SOURCE_DATE_EPOCH defined at the moment.


Even if we just verify that an existing test continues to build without 
problems with it defined, that would be a good start, let alone 
verifying that it actually sets timestamps as expected...

cygport 0.36.8-1

[Jon Turney]

The following packages have been uploaded to the Cygwin distribution:

* cygport-0.36.8-1

cygport is the standard method for building and maintaining packages for 
the Cygwin distribution.



Achim Gratz (1):
  Switch to gpg2

Christian Franke (2):
  Increase _FORTIFY_SOURCE level from 2 to 3 in CFLAGS
  Add initial support for SOURCE_DATE_EPOCH

Daisuke Fujimura (2):
  cmake.cygclass: Add a src_test which invokes the cmake test driver
  git.cygclass: Retry without the depth option

Jon Turney (4):
  testsuite: Fix pangomm1.4 build with latest pango
  pkg: Add coredump to list of unexpected files in a package
  Use file-prefix-map rather than debug-prefix-map
  Bump version to 0.36.8


--
 *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

The easiest way to unsubscribe is to visit 
<https://cygwin.com/mailman/options/cygwin-announce>, and click 'Unsubscribe'.

If you need more information on unsubscribing, start reading here: 
<https://sourceware.org/lists.html#unsubscribe>.

Re: cygport may not create debug info if top directory contains a symlink

[Jon Turney via Cygwin-apps]

On 30/10/2023 16:37, Christian Franke via Cygwin-apps wrote:

Jon Turney wrote:

On 20/09/2023 11:58, Christian Franke via Cygwin-apps wrote:

Brian Inglis wrote:

On 2023-09-18 04:41, Christian Franke via Cygwin-apps wrote:

Brian Inglis wrote:

On 2023-09-17 08:01, Jon Turney via Cygwin-apps wrote:

On 16/09/2023 15:17, Christian Franke via Cygwin wrote:

Found during tests of busybox package:
If the path of the top build directory contains a symlink and 
the project's build scripts normalize pathnames, no debug info 
is created by cygport.


This is because options like
  -fdebug-prefix-map=${B}=/usr/src/debug/${PF}
have no effect because ${B} contains a symlink but the compiler 
is run with the real source path.


I think that there was some historical bug with gcc where a 
relative path for the old path in this mapping wasn't correctly 
handled, which is why were using an absolute path here at all.


So changing it to something like [1] (if that works), might be 
better.


[1] 
https://github.com/jon-turney/cygport/commit/4175d456a9184c5cdebd8bfb4b5ba30583cedd66


Should bin/cygport.in:534: not have $B between the == as in line 531:

declare ${flags}+=" -fdebug-prefix-map=${B}=/usr/src/debug/${PF}"
...
declare ${flags}+=" -fdebug-prefix-map==/usr/src/debug/${PF}"

or be hoist above the condition if identical, unless that is some 
undocumented default for cwd?


I guess the == without ${B} is intentional because it makes the debug 
source path relative to ${B} as lines 535-536 also do.



[...]>
(It's unclear to me how gcc compares paths to apply this mapping. If 
it's a literal string prefix, rather than on some (semi-)canonicalized 
path, then we're maybe going to lose here sometimes, depending on the 
vagaries of the build-system, unless we list all of relative, 
absolute, and canonical absolute paths?)


(But then maybe we can push dealing with or indicating which of those 
is correct off onto the individual cygport?)




Adding this if "$(cd ${S} && pwd -P)" != "${S}" should IMO be safe:
   -fdebug-prefix-map=$(cd ${B} && pwd -P)=/usr/src/debug/${PF}
   -fdebug-prefix-map=$(cd ${S} && pwd -P)=/usr/src/debug/${PF}
(or use realpath)



So it seems there's a new flag '-fcanon-prefix-map' in GCC 13, which 
looks like it maybe solves this problem.

Re: Updated: setup (2.930)

[Jon Turney via Cygwin]

On 09/02/2024 14:05, Michael Soegtrop via Cygwin wrote:

Hi Jon,

 > A new version of Setup (2.930) has been uploaded to:
 >
 >   https://cygwin.com/setup-x86_64.exe  (64 bit version)
 >   https://cygwin.com/setup-x86.exe (32 bit version)

apparently this update broke the 32 bit install of cygwin. I am still 
having this in my nightly CI (Coq Platform) and it broke the night 7th 
to 8th. I checked locally and apparently the list of mirrors is empty 
and giving any mirror on the command line leads to an exit of setup 
without any error message. I tried e.g.:


Thanks for reporting this.

For the time being, I've reverted the URL to point to the previous 
32-bit build, while I investigate.



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