Re: [tz] Ubuntu drops old-style links - tzdata split test package

[Corinna Vinschen via Cygwin-apps]

On Mar 28 02:25, Brian Inglis via Cygwin-apps wrote:
> I have released and announced a test package of tzdata 2024a-2 split into
> three install packages: base tzdata, optional tzdata-right, and redundant
> tzdata-posix, each containing all the legacy zones so that tzset continues
> to work as before.
> 
> I could not reduce the base installed zones by many, because most were used
> by tzset, but I did drop a couple of large zone source files, produced by
> the build, that were previously included to allow users to see the source
> zones, rules, and links in effect, saving ~1MB, and dropping the overall
> default base installed file sizes by ~80% to ~20% of current, and download
> tar size by ~60% to ~40%; for all zones aggregate total installed file sizes
> are dropped by ~35% to ~65%, and download tar sizes by ~30% to ~70% of
> current:
> 
> install   tar   tzdata
>  721KB  172KB   base
>  984KB   78KB   right
>  669KB   74KB   posix
> 1367KB  444KB   source
> 3667KB  452KB   current
> 
> Please check out the announcement, cygwin list echo, source and install
> package summary web pages, cygport changes, setup entries, scallywag builds,
> and let me know if there is anything you see that could benefit from
> improvement.

Fedora Rawhide is not following this scheme.  For F40 and F41 it still
prepares single tzdata packages.  FWIW, OpenSuSE also only comes with a
single timezone package in Tumbleweed.

Comparing the Cygwin and the Fedora package, the only differences are:

 Cygwin comes with two files not in the Fedora package:

   /usr/share/zoneinfo/rearguard.zi
   /usr/share/zoneinfo/zonenow.tab

 Fedora comes with two files not in the Cygwin package:

   /usr/share/zoneinfo/leap-seconds.list
   /usr/share/zoneinfo/posixrules

That's all.  And given that space is not one of the major limiting
factors anymore...

  cyg$ du -sh /usr/share/zoneinfo
  6.6M/usr/share/zoneinfo

  fed$ du -sh /usr/share/zoneinfo
  4.6M  /usr/share/zoneinfo

...I do wonder a bit if this split is really necessary after all.


Corinna

Re: [tz] Ubuntu drops old-style links

[Corinna Vinschen via Cygwin-apps]

On Mar 23 10:38, Brian Inglis via Cygwin-apps wrote:
> It looks to me that tzset.c prioritizes the Windows label over the country,
> and it may be a better match prioritizing the country over the label, if the
> country is not 001/"", nor ZZ, which are the generic entries.

The Windows timezone is the relevant setting in the first place becasue
that's what indicvates the actual local time *as the user chose*.
The territory should only be a secondary hint to choose the right
POSIX entry.

For instance, I know people always using UTC, independently of their
territory setting. If the territory rules, this user choice would be
broken in Cygwin.

> It also is not clear what tzset should do when tzmap has a list of zones to
> choose from, for example:
> 
>   { L"Mountain Standard Time", L"CA", L"America/Edmonton
> America/Cambridge_Bay America/Inuvik" },
>   { L"Mountain Standard Time", L"US", L"America/Denver America/Boise" },
>   { L"US Mountain Standard Time", L"CA", L"America/Creston
> America/Dawson_Creek America/Fort_Nelson" },
> 
> it currently just prints the first, but perhaps it should print all relevant
> entries and the caller should handle the alternatives?

tzset is called from the shell default profile.  It has to use exactly
one, valid entry, so time works as desired without forcing interactivity.

If the user doesn't like it, the user can always override tzset's choice
in her own profile.


Corinna

Re: [tz] Ubuntu drops old-style links

[Corinna Vinschen via Cygwin-apps]

On Mar 22 10:02, Brian Inglis via Cygwin-apps wrote:
> On 2024-03-21 03:36, Corinna Vinschen via Cygwin-apps wrote:
> > We're generating the conversion from Windows to POSIX timezone via
> > the conversion table from unicode.org:
> > 
> > https://cygwin.com/cgit/newlib-cygwin/tree/winsup/utils/tzmap-from-unicode.org
> > 
> > Plus a few (7, actually) mappings the Unicode consortium missed in
> > the list (or maybe they are available in the meantime, needs checking).
> > This is the minimum list of timezone info we need in the tzdata DB.
> 
> I generated tzmap.h and generated differences since the last update cldr ~40.
> I also searched in the latest for matches for each field attached as first.
> 
> I do not know if they will be of help as I see you have already looked at 
> tzmap.
> 
> It looks as if the match might better prioritize country code over Windows 
> label.

Which match?  I'm not sure what you're trying to tell me.

Basically, we want to generate a POSIX timezone from the current user's
Windows timezone.  This boils down to four questions:

- Is the creation of tzmap.h from unicode.org via the
  tzmap-from-unicode.org script the right thing to do or not?

- If it's the wrong thing to do, what other source do you propose and do
  you have a script to perform the conversion from this source to a
  valid tzmap.h file?

- Otherwise, is the current tzmap-from-unicode.org right or wrong in
  adding these old extra timezone/territory settings, or is even
  some combination missing?

- If so, would you mind to send a patch to fix tzmap-from-unicode.org
  accordingly?


Corinna

Re: [tz] Ubuntu drops old-style links

[Corinna Vinschen via Cygwin-apps]

On Mar 20 14:59, Brian Inglis via Cygwin-apps wrote:
> On 2024-03-19 02:19, brian.ing...@systematicsw.ab.ca wrote:
> > On 2024-03-18 21:12, Matt Johnson-Pint via tz wrote:
> > > I just learned that Ubuntu Noble (24.04) decided to intentionally
> > > split the tzdata package.  Old-style links such as US/Eastern are no
> > > longer included by default, but are available in the tzdata-legacy
> > > package instead.
> > > 
> > > Just thought I'd share.  I wonder if other distributions / platforms
> > > / libraries will follow suit.  What do y'all think?
> > > 
> > > See:
> > > 
> > > 
> 
> > I've been looking at that to reduce Cygwin CI and embedded build server
> > setup overhead by limiting base install data to:
> > 
> > - only the zones in zonenow.tab;
> > - optionally those in zone1970.tab not in zonenow.tab;
> > - additionally those in zone.tab in backward, and/or backzone;
> > - possibly those not in zone.tab, only in backward, and/or backzone;
> > - additions those in posix subtree, or right subtree.
> 
> As tzdata maintainer, I would like to discuss on this list first, to take
> advantage of a wide variety of experience in different environments with
> different practices and requirements, before making more definite proposals
> on the public list.
> 
> Please see the attached log for prioritized subsets of tzdata for 
> consideration:
> [...]
> What would the impact on tzset conversion from Windows to Olson tzdb be?
> We would probably have to add all of these in to any minimal install.
> I think I looked at that somewhere, sometime, not too long ago.

We're generating the conversion from Windows to POSIX timezone via
the conversion table from unicode.org:

https://cygwin.com/cgit/newlib-cygwin/tree/winsup/utils/tzmap-from-unicode.org

Plus a few (7, actually) mappings the Unicode consortium missed in
the list (or maybe they are available in the meantime, needs checking).
This is the minimum list of timezone info we need in the tzdata DB.

Corinna

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

[Corinna Vinschen via Cygwin-apps]

On Mar 14 16:07, 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.
> > > 
> > > 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 may also want to use https:// rather than git:// for reading
the repository these days, given the insecurity of the git protocol.

Corinna

Re: [PATCH] In gcc 13, -Wall turns on -Woverloaded-virtual

[Corinna Vinschen via Cygwin-apps]

On Feb  8 16:07, Jon Turney via Cygwin-apps wrote:
> On 07/02/2024 10:46, Corinna Vinschen via Cygwin-apps wrote:
> > Also fix ambiguous method declaration by dropping a default parameter.
> > ---
> > Hi Jon,
> > 
> > I'm not sure removing virtual from all Create methods really fits the
> > bill in all cases, are you?
> > 
> > I had a go at fixing this while keeping the virtuality of the methods
> > intact.  While at it it also occured to me that there's a tricky problem
> > for the compiler to differentiate the method
> 
> This seems like overkill.
> 
> From auditing the code, as far as I can tell, we only ever instantiate
> PropPage-derived objects for each of the setup wizard pages, and one
> PropSheet object to contain them.
> 
> There are no instantiations of the Window class itself.
> 
> PropPage::Create() doesn't even call Window::Create(), so that method can
> actually be totally removed without problem...

I just thought it might be a good idea to keep virtuality, but your
assessment shows that was unnecessary.  No worries from my side.

Corinna

[PATCH] In gcc 13, -Wall turns on -Woverloaded-virtual

[Corinna Vinschen via Cygwin-apps]

Also fix ambiguous method declaration by dropping a default parameter.
---
Hi Jon,

I'm not sure removing virtual from all Create methods really fits the
bill in all cases, are you?

I had a go at fixing this while keeping the virtuality of the methods
intact.  While at it it also occured to me that there's a tricky problem
for the compiler to differentiate the method

  Create ();

from the method

  Create (Window * = NULL, DWORD = 42);

I fixed this ambiguity by making the Window parameter a non-default
parameter.

What do you think?


Corinna

 desktop.h| 2 +-
 main.cc  | 2 +-
 proppage.h   | 1 +
 propsheet.cc | 2 +-
 propsheet.h  | 2 +-
 window.h | 7 ++-
 6 files changed, 11 insertions(+), 5 deletions(-)

diff --git a/desktop.h b/desktop.h
index d4ce72def757..87b5ccee5302 100644
--- a/desktop.h
+++ b/desktop.h
@@ -33,7 +33,7 @@ public:
   {
   };

-  bool Create ();
+  virtual bool Create ();

   virtual void OnInit ();
   virtual void OnActivate ();
diff --git a/main.cc b/main.cc
index b570c6cb18ec..9035260972b3 100644
--- a/main.cc
+++ b/main.cc
@@ -213,7 +213,7 @@ main_display ()
   MainWindow.AddPage ();

   // Create the PropSheet main window
-  MainWindow.Create ();
+  MainWindow.Create (NULL);

   // Uninitalize COM
   if (sl)
diff --git a/proppage.h b/proppage.h
index 64f822b515be..5301a97a8221 100644
--- a/proppage.h
+++ b/proppage.h
@@ -115,6 +115,7 @@ public:
 IsLast = false;
   };

+  virtual bool Create () { return false; };
   virtual bool Create (int TemplateID);
   virtual bool Create (DLGPROC dlgproc, int TemplateID);
   virtual bool Create (DLGPROC dlgproc,
diff --git a/propsheet.cc b/propsheet.cc
index faf6583f0803..3563a388cd48 100644
--- a/propsheet.cc
+++ b/propsheet.cc
@@ -341,7 +341,7 @@ PropSheetProc (HWND hwndDlg, UINT uMsg, LPARAM lParam)
 }

 bool
-PropSheet::Create (const Window * Parent, DWORD Style)
+PropSheet::Create (Window * Parent, DWORD Style)
 {
   PROPSHEETHEADERW p;

diff --git a/propsheet.h b/propsheet.h
index b900e790c32f..870905cf9777 100644
--- a/propsheet.h
+++ b/propsheet.h
@@ -47,7 +47,7 @@ public:
   void SetHWNDFromPage (HWND h);
   void AdjustPageSize (HWND page);

-  virtual bool Create (const Window * Parent = NULL,
+  virtual bool Create (Window *Parent,
   DWORD Style =
   WS_OVERLAPPEDWINDOW | WS_VISIBLE | WS_CLIPCHILDREN);

diff --git a/window.h b/window.h
index 1dfb2a9f7514..bd3080e758fc 100644
--- a/window.h
+++ b/window.h
@@ -82,7 +82,12 @@ public:
   Window ();
   virtual ~ Window ();

-  virtual bool Create (Window * Parent = NULL,
+  virtual bool Create () { return false; };
+  virtual bool Create (int) { return false; };
+  virtual bool Create (DLGPROC, int) { return false; };
+  virtual bool Create (DLGPROC, BOOL (*) (HWND, int, HWND, UINT), int)
+  { return false; };
+  virtual bool Create (Window *Parent,
   DWORD Style =
   WS_OVERLAPPEDWINDOW | WS_VISIBLE | WS_CLIPCHILDREN);

--
2.43.0

[HEADSUP] any usage of cygwin_internal(CW_CMDLINE) in any maintained package?

[Corinna Vinschen via Cygwin-apps]

Hi guys,

is anybody of you maintaining a package (or is aware of any package in
the Cygwin distro) which is using the cygwin_internal(CW_CMDLINE) call?

If not, I will redefine the usage of this call in Cygwin 3.6.

The reason is that it's practically unusable, unless the caller only
fetches the first string from the output.  The call also returns its
content in allocated memory which is not free'able by the caller :(


Thanks,
Corinna

Re: cygwin 3.4.10-1

[Corinna Vinschen via Cygwin-apps]

On Jan 27 10:27, Marco Atzeri via Cygwin-apps wrote:
> On 29/11/2023 15:08, Corinna Vinschen via Cygwin-announce wrote:
> > The following packages have been uploaded to the Cygwin distribution:
> > 
> > * cygwin-3.4.10-1
> > * cygwin-devel-3.4.10-1
> > * cygwin-doc-3.4.10-1
> > 
> 
> just for me or the cygwin server still states 3.4.9 as last version ?

Yeah, I missed to change the website, sorry.  I fixed it, even if
only for a few days.


Corinna

Re: Automatic announcement generation by calm

[Corinna Vinschen via Cygwin-apps]

On Jan  7 16:12, Jon Turney via Cygwin-apps wrote:
> This is an experimental facility, currently only available for packages
> deployed from the build service [1] (that is, not for self-built packages
> uploaded with 'cygport up' via sftp)
> 
> When the token "announce" is present for a build job (in addition to
> "deploy"), after a successful deploy, calm will automatically generate and
> send an announce email.
> 
> The mail follows a similar format to that generated by "cygport announce",
> containing a list of packages and the description, with the following
> addition:
> 
> * If the cygport defines the variable "ANNOUNCE", it's evaluated contents
> will be appended to the generated mail.
> 
> * Otherwise, if the source package contains an ANNOUNCE file [2], it's
> contents will be appended.
> 
> * Otherwise, if the source package contains a README or ${PN}.README file,
> lines that look like part of a changelog, between one starting with '
> ${PVR}' and the next starting '', will be extracted and appended
> 
> (None of these seem like a particularly great way of doing things, but they
> match some historical patterns.  As always, suggestions about improvements
> are welcome.)
> 
> 
> In accordance with our long-standing policy of treating maintainer email
> addresses as private information, the mail is sent from cygwin-no-reply and
> bcc'ed to the uploader.
> 
> 
> For testing purposes, if the token "mock" (yes, I am running out of synonyms
> for "test"...) is also present, the mail will be only sent to the uploader,
> not the announce list.
> 
> 
> [1] https://cygwin.com/packaging/build.html
> [2] Note that this isn't currently part of the default value of CYGWIN_FILES
> [3], so needs to be explicitly listed there to be included in the source
> package
> [3] https://cygwin.github.io/cygport/src_prep_cygpart.html#CYGWIN_FILES

:+1:

Unfortunately I started the OpenSSH 9.6 build before reading this here,
but that's some great addition.

Corinna

Re: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8

[Corinna Vinschen via Cygwin-apps]

On Sep  1 03:28, Mark Geisert via Cygwin-apps wrote:
> Hi Corinna,
> 
> Corinna Vinschen via Cygwin-apps wrote:
> > On Aug 30 20:10, Corinna Vinschen via Cygwin-apps wrote:
> > > On Aug 30 12:04, Brian Inglis via Cygwin-apps wrote:
> > > > On 2023-08-30 06:17, Corinna Vinschen via Cygwin-apps wrote:
> > > > > On Aug 30 11:57, Corinna Vinschen via Cygwin-apps wrote:
> > > > > > On Aug 30 11:34, Corinna Vinschen via Cygwin-apps wrote:
> > > > > > >#define CPU_ZERO_S(siz, set) __cpuset_zero_s (siz, set)
> > > > > > > -static __inline void
> > > > > > > -__cpuset_zero_s (size_t siz, cpu_set_t *set)
> > > > > > > -{
> > > > > > > -  (void) memset (set, 0, siz);
> > > > > > > -}
> > > > > > > +void __cpuset_zero_s (size_t, cpu_set_t *);
> > > > > > >[...]
> > > > > > > +__cpuset_zero_s (size_t siz, cpu_set_t *set)
> > > > > > > +{
> > > > > > > +  (void) memset (set, 0, siz);
> > > > > > > +}
> > > > > > > +
> > > > > > >} /* extern C */
> > > > > > 
> > > > > > Also, we can avoid an external __cpuset_zero_s function by just 
> > > > > > using a
> > > > > > loop, kind of like this:
> > > > > 
> > > > > I attached a matching patch. Please give it a try.
> > > > 
> > > > Shouldn't cpuset.h #include  for size_t and  for 
> > > > pid_t?
> > > 
> > > It shouldn't need that. sys/cpuset.h is a non-standard header which is
> > > only included indirectly via sys/types.h.
> > > 
> > > We may want to change from size_t to __size_t and from pid_t to __pid_t.
> > > That should eliminate any further dependency.
> > 
> > Try this:
> 
> After applying both patches to my system I was able to build coreutils
> without issues.  After updating my local Cygwin tree's sched.cc and
> cygwin.din I rebuilt the Cygwin DLL without issues.
> 
> I then tried recompiling a CPU affinity test program of mine (that uses
> cpusets) but it could not link due to missing __cpuset_alloc and
> __cpuset_free.  I think this is likely a local issue of mine in copying
> newly-built stuff into place, though I've automated that process and do it
> frequently, so...  ?

You missed to copy libcygwin.a to /usr/lib.

> I believe those two patches you wrote are fine.  Ship when convenient, I say.
> Cheers & Regards,

Great, thanks for testing!


Corinna

Re: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8

[Corinna Vinschen via Cygwin-apps]

On Aug 30 20:10, Corinna Vinschen via Cygwin-apps wrote:
> On Aug 30 12:04, Brian Inglis via Cygwin-apps wrote:
> > On 2023-08-30 06:17, Corinna Vinschen via Cygwin-apps wrote:
> > > On Aug 30 11:57, Corinna Vinschen via Cygwin-apps wrote:
> > > > On Aug 30 11:34, Corinna Vinschen via Cygwin-apps wrote:
> > > > >   #define CPU_ZERO_S(siz, set) __cpuset_zero_s (siz, set)
> > > > > -static __inline void
> > > > > -__cpuset_zero_s (size_t siz, cpu_set_t *set)
> > > > > -{
> > > > > -  (void) memset (set, 0, siz);
> > > > > -}
> > > > > +void __cpuset_zero_s (size_t, cpu_set_t *);
> > > > >   [...]
> > > > > +__cpuset_zero_s (size_t siz, cpu_set_t *set)
> > > > > +{
> > > > > +  (void) memset (set, 0, siz);
> > > > > +}
> > > > > +
> > > > >   } /* extern C */
> > > > 
> > > > Also, we can avoid an external __cpuset_zero_s function by just using a
> > > > loop, kind of like this:
> > > 
> > > I attached a matching patch. Please give it a try.
> > 
> > Shouldn't cpuset.h #include  for size_t and  for 
> > pid_t?
> 
> It shouldn't need that. sys/cpuset.h is a non-standard header which is
> only included indirectly via sys/types.h.
> 
> We may want to change from size_t to __size_t and from pid_t to __pid_t.
> That should eliminate any further dependency.

Try this:

>From ecc6012b90ba226c7ce92d4d0a12e6b4824ee03a Mon Sep 17 00:00:00 2001
From: Corinna Vinschen 
Date: Wed, 30 Aug 2023 21:11:42 +0200
Subject: [PATCH] Cygwin: sys/cpuset.h: use internal base types

Use __size_t and __pid_t instead of size_t and pid_t to avoid
further dependencies to external headers.

Reported-by: Brian Inglis 
Signed-off-by: Corinna Vinschen 
---
 winsup/cygwin/include/sys/cpuset.h | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/winsup/cygwin/include/sys/cpuset.h 
b/winsup/cygwin/include/sys/cpuset.h
index 2ab2b95f0d65..a5a8fa81ef3d 100644
--- a/winsup/cygwin/include/sys/cpuset.h
+++ b/winsup/cygwin/include/sys/cpuset.h
@@ -29,15 +29,15 @@ typedef struct
 } cpu_set_t;
 
 #if __GNU_VISIBLE
-int __sched_getaffinity_sys (pid_t, size_t, cpu_set_t *);
+int __sched_getaffinity_sys (__pid_t, __size_t, cpu_set_t *);
 
 /* These macros alloc or free dynamically-sized cpu sets of size 'num' cpus.
Allocations are padded such that full-word operations can be done easily. */
 #define CPU_ALLOC_SIZE(num) __cpuset_alloc_size (num)
-static __inline size_t
+static __inline __size_t
 __cpuset_alloc_size (int num)
 {
-  return (size_t) (((num + __NCPUBITS - 1) / __NCPUBITS) * sizeof 
(__cpu_mask));
+  return (__size_t) (((num + __NCPUBITS - 1) / __NCPUBITS) * sizeof 
(__cpu_mask));
 }
 
 #define CPU_ALLOC(num) __cpuset_alloc (num)
@@ -49,7 +49,7 @@ void __cpuset_free (cpu_set_t *);
 /* These _S macros operate on dynamically-sized cpu sets of size 'siz' bytes */
 #define CPU_ZERO_S(siz, set) __cpuset_zero_s (siz, set)
 static __inline
-__cpuset_zero_s (size_t siz, cpu_set_t *set)
+__cpuset_zero_s (__size_t siz, cpu_set_t *set)
 {
 #if __GNUC_PREREQ (2, 91)
   __builtin_memset (set, 0, siz);
@@ -62,7 +62,7 @@ __cpuset_zero_s (size_t siz, cpu_set_t *set)
 
 #define CPU_SET_S(cpu, siz, set) __cpuset_set_s (cpu, siz, set)
 static __inline void
-__cpuset_set_s (int cpu, size_t siz, cpu_set_t *set)
+__cpuset_set_s (int cpu, __size_t siz, cpu_set_t *set)
 {
   if (cpu >= 0 && cpu < 8 * siz)
 (set)->__bits[__CPUELT(cpu)] |= __CPUMASK(cpu);
@@ -70,7 +70,7 @@ __cpuset_set_s (int cpu, size_t siz, cpu_set_t *set)
 
 #define CPU_CLR_S(cpu, siz, set) __cpuset_clr_s (cpu, siz, set)
 static __inline void
-__cpuset_clr_s (int cpu, size_t siz, cpu_set_t *set)
+__cpuset_clr_s (int cpu, __size_t siz, cpu_set_t *set)
 {
   if (cpu >= 0 && cpu < 8 * siz)
 (set)->__bits[__CPUELT(cpu)] &= ~(__CPUMASK(cpu));
@@ -78,7 +78,7 @@ __cpuset_clr_s (int cpu, size_t siz, cpu_set_t *set)
 
 #define CPU_ISSET_S(cpu, siz, set) __cpuset_isset_s (cpu, siz, set)
 static __inline int
-__cpuset_isset_s (int cpu, size_t siz, cpu_set_t *set)
+__cpuset_isset_s (int cpu, __size_t siz, cpu_set_t *set)
 {
   int res = 0;
   if (cpu >= 0 && cpu < 8 * siz)
@@ -88,7 +88,7 @@ __cpuset_isset_s (int cpu, size_t siz, cpu_set_t *set)
 
 #define CPU_COUNT_S(siz, set) __cpuset_count_s (siz, set)
 static __inline int
-__cpuset_count_s (size_t siz, cpu_set_t *set)
+__cpuset_count_s (__size_t siz, cpu_set_t *set)
 {
   int i, res = 0;
   for (i = 0; i < siz / sizeof (__cpu_mask); i++)
@@ -98,7 +98,7 @@ __cpuset_count_s (size_t siz, cpu_set_t *set)
 
 #define CPU_AND_S(siz, dst, src1, src2) __cpuset_and_s (siz, dst, src1, src2)
 static __inline void
-__cpuset_and_s (size

Re: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8

[Corinna Vinschen via Cygwin-apps]

On Aug 30 12:04, Brian Inglis via Cygwin-apps wrote:
> On 2023-08-30 06:17, Corinna Vinschen via Cygwin-apps wrote:
> > On Aug 30 11:57, Corinna Vinschen via Cygwin-apps wrote:
> > > On Aug 30 11:34, Corinna Vinschen via Cygwin-apps wrote:
> > > >   #define CPU_ZERO_S(siz, set) __cpuset_zero_s (siz, set)
> > > > -static __inline void
> > > > -__cpuset_zero_s (size_t siz, cpu_set_t *set)
> > > > -{
> > > > -  (void) memset (set, 0, siz);
> > > > -}
> > > > +void __cpuset_zero_s (size_t, cpu_set_t *);
> > > >   [...]
> > > > +__cpuset_zero_s (size_t siz, cpu_set_t *set)
> > > > +{
> > > > +  (void) memset (set, 0, siz);
> > > > +}
> > > > +
> > > >   } /* extern C */
> > > 
> > > Also, we can avoid an external __cpuset_zero_s function by just using a
> > > loop, kind of like this:
> > 
> > I attached a matching patch. Please give it a try.
> 
> Shouldn't cpuset.h #include  for size_t and  for pid_t?

It shouldn't need that. sys/cpuset.h is a non-standard header which is
only included indirectly via sys/types.h.

We may want to change from size_t to __size_t and from pid_t to __pid_t.
That should eliminate any further dependency.


Corinna

Re: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8

[Corinna Vinschen via Cygwin-apps]

On Aug 30 11:57, Corinna Vinschen via Cygwin-apps wrote:
> On Aug 30 11:34, Corinna Vinschen via Cygwin-apps wrote:
> >  #define CPU_ZERO_S(siz, set) __cpuset_zero_s (siz, set)
> > -static __inline void
> > -__cpuset_zero_s (size_t siz, cpu_set_t *set)
> > -{
> > -  (void) memset (set, 0, siz);
> > -}
> > +void __cpuset_zero_s (size_t, cpu_set_t *);
> >  [...]
> > +__cpuset_zero_s (size_t siz, cpu_set_t *set)
> > +{
> > +  (void) memset (set, 0, siz);
> > +}
> > +
> >  } /* extern C */
> 
> Also, we can avoid an external __cpuset_zero_s function by just using a
> loop, kind of like this:

I attached a matching patch. Please give it a try.

Thanks,
Corinna
>From a8b26a78ae600f471f54769c28b6d3542aabab06 Mon Sep 17 00:00:00 2001
From: Corinna Vinschen 
Date: Wed, 30 Aug 2023 11:32:02 +0200
Subject: [PATCH] Cygwin: sys/cpuset.h: add cpuset-specific external functions

The latest incarnation of sys/cpuset.h broke building coreutils.
The reason is the inclusion of stdlib.h and string.h and hence
premature requests for datatypes not yet defined in the include
chain.

Avoid this by defining __cpuset_alloc and __cpuset_free as external
functions, now defined in sched.cc.  Linux is doing this too, just
using different names for the functions. Redefine  __cpuset_zero_s
to use __builtin_memset only on compilers supporting it, otherwise
using a simple loop. Drop the stdlib.h and string.h includes.

Fixes: 3f2790e04439 ("Cygwin: Make gcc-specific code in  
compiler-agnostic")
Signed-off-by: Corinna Vinschen 
---
 winsup/cygwin/cygwin.din   |  2 ++
 winsup/cygwin/include/sys/cpuset.h | 25 +++--
 winsup/cygwin/sched.cc | 12 
 3 files changed, 25 insertions(+), 14 deletions(-)

diff --git a/winsup/cygwin/cygwin.din b/winsup/cygwin/cygwin.din
index ee646fddc862..3afadb7f3a77 100644
--- a/winsup/cygwin/cygwin.din
+++ b/winsup/cygwin/cygwin.din
@@ -49,6 +49,8 @@ __b64_ntop NOSIGFE
 __b64_pton NOSIGFE
 __bsd_qsort_r NOSIGFE
 __chk_fail SIGFE
+__cpuset_alloc SIGFE
+__cpuset_free SIGFE
 __cxa_atexit = cygwin__cxa_atexit SIGFE
 __cxa_finalize SIGFE
 __dn_comp SIGFE
diff --git a/winsup/cygwin/include/sys/cpuset.h 
b/winsup/cygwin/include/sys/cpuset.h
index 95c777cfbc6d..2ab2b95f0d65 100644
--- a/winsup/cygwin/include/sys/cpuset.h
+++ b/winsup/cygwin/include/sys/cpuset.h
@@ -9,8 +9,7 @@ details. */
 #ifndef _SYS_CPUSET_H_
 #define _SYS_CPUSET_H_
 
-#include 
-#include 
+#include 
 
 #ifdef __cplusplus
 extern "C" {
@@ -42,25 +41,23 @@ __cpuset_alloc_size (int num)
 }
 
 #define CPU_ALLOC(num) __cpuset_alloc (num)
-static __inline cpu_set_t *
-__cpuset_alloc (int num)
-{
-  return (cpu_set_t *) malloc (CPU_ALLOC_SIZE(num));
-}
+extern cpu_set_t * __cpuset_alloc (int);
 
 #define CPU_FREE(set) __cpuset_free (set)
-static __inline void
-__cpuset_free (cpu_set_t *set)
-{
-  free (set);
-}
+void __cpuset_free (cpu_set_t *);
 
 /* These _S macros operate on dynamically-sized cpu sets of size 'siz' bytes */
 #define CPU_ZERO_S(siz, set) __cpuset_zero_s (siz, set)
-static __inline void
+static __inline
 __cpuset_zero_s (size_t siz, cpu_set_t *set)
 {
-  (void) memset (set, 0, siz);
+#if __GNUC_PREREQ (2, 91)
+  __builtin_memset (set, 0, siz);
+#else
+  siz /= sizeof (__cpu_mask);
+  while (siz > 0)
+set->_bits[--siz] = 0;
+#endif
 }
 
 #define CPU_SET_S(cpu, siz, set) __cpuset_set_s (cpu, siz, set)
diff --git a/winsup/cygwin/sched.cc b/winsup/cygwin/sched.cc
index d7bad852765c..845fcef5702c 100644
--- a/winsup/cygwin/sched.cc
+++ b/winsup/cygwin/sched.cc
@@ -684,4 +684,16 @@ done:
   return 0;
 }
 
+cpu_set_t *
+__cpuset_alloc (int num)
+{
+  return (cpu_set_t *) malloc (CPU_ALLOC_SIZE(num));
+}
+
+void
+__cpuset_free (cpu_set_t *set)
+{
+  free (set);
+}
+
 } /* extern C */
-- 
2.41.0

Re: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8

[Corinna Vinschen via Cygwin-apps]

On Aug 30 11:34, Corinna Vinschen via Cygwin-apps wrote:
>  #define CPU_ZERO_S(siz, set) __cpuset_zero_s (siz, set)
> -static __inline void
> -__cpuset_zero_s (size_t siz, cpu_set_t *set)
> -{
> -  (void) memset (set, 0, siz);
> -}
> +void __cpuset_zero_s (size_t, cpu_set_t *);
>  [...]
> +__cpuset_zero_s (size_t siz, cpu_set_t *set)
> +{
> +  (void) memset (set, 0, siz);
> +}
> +
>  } /* extern C */

Also, we can avoid an external __cpuset_zero_s function by just using a
loop, kind of like this:

  #define CPU_ZERO_S(siz, set) __cpuset_zero_s (siz, set)
  static __inline
  __cpuset_zero_s (size_t siz, cpu_set_t *set)
  {
  #if __GNUC_PREREQ (2, 91)
__builtin_memset (set, 0, siz);
  #else
siz /= sizeof (__cpu_mask);
while (siz > 0)
  set->_bits[--siz] = 0;
  #endif
  }


Corinna

Re: can't compile coreutils-9.3 any more after upgrade to cygwin-3.4.8

[Corinna Vinschen via Cygwin-apps]

Hi Mark,

On Aug 30 00:29, Mark Geisert via Cygwin-apps wrote:
> [redirected from the main Cygwin ML]
> Corinna Vinschen via Cygwin wrote:
> > This is not what I meant.  A simple reproducer is ideally a piece of
> > C code which shows ;the problem with a minimum of code.  In this case,
> > a pice of C code with the #includes required to reproduce the compiler
> > failing is what I'm looking for.
> [...]
> From this I discovered that pthread_attr_t and pthread_t defs are missing
> because sys/_pthreadtypes.h includes sys/cpuset.h which starts a whole
> include chain ending up in sys/signal.h where the defs are needed.  Note
> they are defined in sys/_pthreadtypes.h where we started, but haven't been
> seen yet because sys/cpuset.h has gone off on this detour.
> 
> Similarly, the timestruc_t def is missing because sys/_pthreadtypes.h again
> starts an include chain that ends up in sys/stat.h where the def is needed.
> Note timestruc_t is defined in machine/types.h, which is included (by
> sys/types.h) after sys/_pthreadtypes.h, so the def hasn't been seen yet
> because of a similar detour.
> 
> The fix I'm considering is to
> (1) move sys/_pthreadtypes.h's "#include sys/cpuset.h" to just before its
> final #endif, and
> (2) exchange the positions of "#include " and "#include
> " within sys/types.h.
> I could submit for review a patch to do these things.
> 
> An alternative would be to somehow massage the coreutils build
> include-file-wrapping to accomplish the same end.  I personally don't have
> the time or skills to figure that out.

I have another solution, based on how Linux does it, see the attached patch.
What do you think?  If that's ok with you, I'll push it.


Thanks,
Corinna
>From 6cb039fdefb30522795861c47f3f1facf7d70eb2 Mon Sep 17 00:00:00 2001
From: Corinna Vinschen 
Date: Wed, 30 Aug 2023 11:32:02 +0200
Subject: [PATCH] Cygwin: sys/cpuset.h: add cpuset-specific external functions

The latest incarnation of sys/cpuset.h broke building coreutils.
The reason is the inclusion of stdlib.h and string.h and hence
premature requests for datatypes not yet defined in the include
chain.

Avoid this by defining __cpuset_alloc, __cpuset_free, and
__cpuset_zero_s as external functions, now defined in sched.cc.
Linux is doing this too, just using different names for the
functions.  Drop the includes entirely.

Fixes: 3f2790e04439 ("Cygwin: Make gcc-specific code in  
compiler-agnostic")
Signed-off-by: Corinna Vinschen 
---
 winsup/cygwin/cygwin.din   |  3 +++
 winsup/cygwin/include/sys/cpuset.h | 21 +++--
 winsup/cygwin/sched.cc | 18 ++
 3 files changed, 24 insertions(+), 18 deletions(-)

diff --git a/winsup/cygwin/cygwin.din b/winsup/cygwin/cygwin.din
index ee646fddc862..1fb7a880f9fb 100644
--- a/winsup/cygwin/cygwin.din
+++ b/winsup/cygwin/cygwin.din
@@ -49,6 +49,9 @@ __b64_ntop NOSIGFE
 __b64_pton NOSIGFE
 __bsd_qsort_r NOSIGFE
 __chk_fail SIGFE
+__cpuset_alloc SIGFE
+__cpuset_free SIGFE
+__cpuset_zero_s SIGFE
 __cxa_atexit = cygwin__cxa_atexit SIGFE
 __cxa_finalize SIGFE
 __dn_comp SIGFE
diff --git a/winsup/cygwin/include/sys/cpuset.h 
b/winsup/cygwin/include/sys/cpuset.h
index 95c777cfbc6d..371432931b48 100644
--- a/winsup/cygwin/include/sys/cpuset.h
+++ b/winsup/cygwin/include/sys/cpuset.h
@@ -9,9 +9,6 @@ details. */
 #ifndef _SYS_CPUSET_H_
 #define _SYS_CPUSET_H_
 
-#include 
-#include 
-
 #ifdef __cplusplus
 extern "C" {
 #endif
@@ -42,26 +39,14 @@ __cpuset_alloc_size (int num)
 }
 
 #define CPU_ALLOC(num) __cpuset_alloc (num)
-static __inline cpu_set_t *
-__cpuset_alloc (int num)
-{
-  return (cpu_set_t *) malloc (CPU_ALLOC_SIZE(num));
-}
+extern cpu_set_t * __cpuset_alloc (int);
 
 #define CPU_FREE(set) __cpuset_free (set)
-static __inline void
-__cpuset_free (cpu_set_t *set)
-{
-  free (set);
-}
+void __cpuset_free (cpu_set_t *);
 
 /* These _S macros operate on dynamically-sized cpu sets of size 'siz' bytes */
 #define CPU_ZERO_S(siz, set) __cpuset_zero_s (siz, set)
-static __inline void
-__cpuset_zero_s (size_t siz, cpu_set_t *set)
-{
-  (void) memset (set, 0, siz);
-}
+void __cpuset_zero_s (size_t, cpu_set_t *);
 
 #define CPU_SET_S(cpu, siz, set) __cpuset_set_s (cpu, siz, set)
 static __inline void
diff --git a/winsup/cygwin/sched.cc b/winsup/cygwin/sched.cc
index d7bad852765c..7e2d1cf783af 100644
--- a/winsup/cygwin/sched.cc
+++ b/winsup/cygwin/sched.cc
@@ -684,4 +684,22 @@ done:
   return 0;
 }
 
+cpu_set_t *
+__cpuset_alloc (int num)
+{
+  return (cpu_set_t *) malloc (CPU_ALLOC_SIZE(num));
+}
+
+void
+__cpuset_free (cpu_set_t *set)
+{
+  free (set);
+}
+
+void
+__cpuset_zero_s (size_t siz, cpu_set_t *set)
+{
+  (void) memset (set, 0, siz);
+}
+
 } /* extern C */
-- 
2.41.0

Re: [PATCH rebase 1/2] Always update the file checksum in the PE header

[Corinna Vinschen via Cygwin-apps]

On Aug 15 11:29, Christian Franke via Cygwin-apps wrote:
> Corinna Vinschen wrote:
> > On Aug 12 14:26, Christian Franke via Cygwin-apps wrote:
> > > This patch is still experimental, but tested with all /bin/cyg*.dll from 
> > > my
> > > installation.
> > Does that mean I shouldn't apply it for now, or do you want me to
> > apply it but not create a new release yet?
> > 
> 
> Meantime I did more tests, also a few with 32-bit DLLs, which all succeeded.
> So it should be safe to use.
> 
> In conjunction with the "Don't update the PE header timestamp unless -t is
> used" patch, rebase results are reproducible.

Pushed.  I've started deploying a rebase 4.6.6.


Thanks,
Corinna

Re: [PATCH rebase 1/2] Always update the file checksum in the PE header

[Corinna Vinschen via Cygwin-apps]

On Aug 12 14:26, Christian Franke via Cygwin-apps wrote:
> This patch is still experimental, but tested with all /bin/cyg*.dll from my
> installation.

Does that mean I shouldn't apply it for now, or do you want me to
apply it but not create a new release yet?


Thanks,
Corinna


> 
> -- 
> Regards,
> Christian
> 

> From 53663d46c2c989e665143b33c0614b416fd1c666 Mon Sep 17 00:00:00 2001
> From: Christian Franke 
> Date: Sat, 12 Aug 2023 14:13:43 +0200
> Subject: [PATCH] Always update the file checksum in the PE header
> 
> Both peflags and rebase now update the checksum without reading
> the whole file under the assumption that the original checksum
> was correct.  Calculation is done by new module
> 'imagehelper/pechecksum_update.c'.
> Slightly change the peflags -k, --checksum option accordingly.
> 
> Signed-off-by: Christian Franke 
> ---
>  Makefile.in |   6 +-
>  imagehelper/Makefile.in |   7 ++-
>  imagehelper/imagehelper.h   |   4 ++
>  imagehelper/objectfile.cc   |  62 +++---
>  imagehelper/objectfile.h|   7 +++
>  imagehelper/pechecksum_update.c |  56 +
>  imagehelper/pechecksum_update.h |  52 
>  imagehelper/rebaseimage.cc  |   4 ++
>  imagehelper/sections.cc |  20 +-
>  imagehelper/sections.h  |   8 ++-
>  peflags.c   | 107 +---
>  rebase.c|  39 
>  12 files changed, 305 insertions(+), 67 deletions(-)
>  create mode 100644 imagehelper/pechecksum_update.c
>  create mode 100644 imagehelper/pechecksum_update.h
> 
> diff --git a/Makefile.in b/Makefile.in
> index e7b7f6a..edc9eda 100644
> --- a/Makefile.in
> +++ b/Makefile.in
> @@ -81,7 +81,7 @@ REBASE_DUMP_OBJS = rebase-dump.$(O) rebase-db.$(O) 
> $(LIBOBJS)
>  REBASE_DUMP_LIBS =
>  
>  PEFLAGS_OBJS = peflags.$(O) pechecksum.$(O) $(LIBOBJS)
> -PEFLAGS_LIBS =
> +PEFLAGS_LIBS = $(LIBIMAGEHELPER)
>  
>  SRC_DISTFILES = configure.ac configure Makefile.in \
>   peflagsall.in rebaseall.in \
> @@ -109,8 +109,8 @@ rebase-dump$(EXEEXT): $(REBASE_DUMP_OBJS)
>  
>  rebase-dump.$(O):: rebase-dump.c rebase-db.h Makefile
>  
> -peflags$(EXEEXT): $(PEFLAGS_OBJS)
> - $(CC) $(CFLAGS) $(LDFLAGS) -o $@ $(PEFLAGS_OBJS)
> +peflags$(EXEEXT): $(PEFLAGS_OBJS) $(PEFLAGS_LIBS)
> + $(CXX) $(CXXFLAGS) $(LDFLAGS) $(CXX_LDFLAGS) -o $@ $(PEFLAGS_OBJS) 
> $(PEFLAGS_LIBS)
>  
>  peflags.$(O):: peflags.c pechecksum.h Makefile
>  
> diff --git a/imagehelper/Makefile.in b/imagehelper/Makefile.in
> index 0ed8e6c..a40cd8c 100755
> --- a/imagehelper/Makefile.in
> +++ b/imagehelper/Makefile.in
> @@ -75,11 +75,12 @@ LIB_TARGET=imagehelper
>  LIB_TARGET_FILE=libimagehelper.a
>  LIB_OBJS = objectfile.$(O) objectfilelist.$(O) sections.$(O) debug.$(O) \
>   rebaseimage.$(O) checkimage.$(O) fiximage.$(O) getimageinfos.$(O) \
> - bindimage.$(O)
> + bindimage.$(O) pechecksum_update.$(O)
>  LIB_SRCS = objectfile.cc objectfilelist.cc sections.cc debug.cc \
>   rebaseimage.cc checkimage.cc fiximage.cc getimageinfos.cc \
> - bindimage.cc
> -LIB_HDRS = objectfilelist.h imagehelper.h sections.h objectfile.h
> + bindimage.cc pechecksum_update.c
> +LIB_HDRS = objectfilelist.h imagehelper.h sections.h objectfile.h \
> + pechecksum_update.h
>  
>  #
>  # (obsolete) applications
> diff --git a/imagehelper/imagehelper.h b/imagehelper/imagehelper.h
> index bafc106..8535311 100755
> --- a/imagehelper/imagehelper.h
> +++ b/imagehelper/imagehelper.h
> @@ -33,6 +33,10 @@ extern BOOL ReBaseChangeFileTime;
>  /* Set to TRUE, if rebasing should also drop the /DYNAMICBASE flag
> from the PE flags. */
>  extern BOOL ReBaseDropDynamicbaseFlag;
> +/* Set to TRUE if ReBaseImage{64} should update the PE checksum.
> +   Cleared if the update failed due to inconsistent original
> +   checksum. */
> +extern BOOL ReBaseUpdateCheckSum;
>  
>  BOOL ReBaseImage64(
>LPCSTR CurrentImageName,
> diff --git a/imagehelper/objectfile.cc b/imagehelper/objectfile.cc
> index 4dafa6a..651fcce 100755
> --- a/imagehelper/objectfile.cc
> +++ b/imagehelper/objectfile.cc
> @@ -24,6 +24,7 @@
>  #include 
>  
>  #include "objectfile.h"
> +#include "pechecksum_update.h"
>  
>  // read a dll into the cache
>  
> @@ -109,6 +110,15 @@ ObjectFile::ObjectFile(const char *aFileName, bool 
> writeable)
>FileName = strdup(name);
>  }
>  
> +  LARGE_INTEGER fs;
> +  if (!GetFileSizeEx(hfile, ))
> +{
> +  CloseHandle(hfile);
> +  Error = 2;
> +  return;
> +}
> +  FileSize = fs.QuadPart;
> +
>hfilemapping = CreateFileMapping(hfile, NULL, writeable ? PAGE_READWRITE : 
> PAGE_READONLY , 0, 0,  NULL);
>if (hfilemapping == 0)
>  {
> @@ -139,8 +149,7 @@ ObjectFile::ObjectFile(const char *aFileName, bool 
> writeable)
>return;
>  }
>// filesize big enough to allow at least reading the NT header?
> -  if (GetFileSize (hfile, NULL)
> -  < (char *) ntheader - 

Re: [PATCH 0/4] Testsuite update

[Corinna Vinschen via Cygwin-apps]

On Aug  8 17:02, Jon Turney via Cygwin-apps wrote:
> On 07/08/2023 09:55, Corinna Vinschen wrote:
> > On Aug  4 13:47, Jon Turney wrote:
> > > This gets us down to no permanent failures in the testsuite in CI.
> 
> There is an intermittent failure in kill01, which I need to do something
> about before turning on taking notice of the testsuite result in CI.
> 
> Effectively, all this does is:
> 
>   pid = fork();
>   if (pid == 0) {
> pause();
>   } else {
> kill(pid, SIGKILL);
> waitpid(pid, , 0);
>   }
> 
> This is quite easy to demonstrate with 'winsup.api/ltp/kill01 -i 1000',
> which repeats the test, succeeding until it hangs.
> 
> Looking at the strace output, I would guess it's some race condition where a
> child process isn't yet in a position to receive a signal immediately after
> fork() returns in the parent (so the signal is dropped, and the parent
> blocks indefinitely in waitpid waiting for the child to terminate)
> 
> I'm not sure if that's fixable (or worth effort), so maybe just adding a
> small delay in the test is the thing to do... :)

It might be worth looking into it to make this more reliable, but the
patch is fine for the time being, of course.


Thanks,
Corinna

Re: [PATCH rebase] rebase: Add -c, --checksum option

[Corinna Vinschen via Cygwin-apps]

On Aug  8 12:10, Christian Franke via Cygwin-apps wrote:
> Last patch for now.
> 
> Left for later: ReBaseImage64() unconditionally updates the timestamp in the
> file header.
> 
> -- 
> Regards,
> Christian
> 

> From 3973a92cf11056521552d9d3f87efe8e721e8c31 Mon Sep 17 00:00:00 2001
> From: Christian Franke 
> Date: Tue, 8 Aug 2023 12:04:25 +0200
> Subject: [PATCH] rebase: Add -c, --checksum option
> 
> If specified, the file checksum in the PE header is updated after
> rebasing.
> 
> Signed-off-by: Christian Franke 
> ---
>  Makefile.in |  4 ++--
>  rebase.c| 50 ++
>  2 files changed, 48 insertions(+), 6 deletions(-)

Pushed.  Next release gets created right now.


Thanks,
Corinna

Re: [PATCH rebase] Add missing pechecksum.* to SRC_DISTFILES

[Corinna Vinschen via Cygwin-apps]

On Aug  8 10:54, Christian Franke via Cygwin-apps wrote:
> Missed yesterday, sorry.
> 
> -- 
> Regards,
> Christian
> 

> From 84065da466d9501d0522af8860ea829ee51c12f5 Mon Sep 17 00:00:00 2001
> From: Christian Franke 
> Date: Tue, 8 Aug 2023 10:52:14 +0200
> Subject: [PATCH] Add missing pechecksum.* to SRC_DISTFILES
> 
> Signed-off-by: Christian Franke 
> ---
>  Makefile.in | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
> 
> diff --git a/Makefile.in b/Makefile.in
> index 46df1d5..adb7972 100644
> --- a/Makefile.in
> +++ b/Makefile.in
> @@ -84,7 +84,8 @@ PEFLAGS_OBJS = peflags.$(O) pechecksum.$(O) $(LIBOBJS)
>  PEFLAGS_LIBS =
>  
>  SRC_DISTFILES = configure.ac configure Makefile.in \
> - peflagsall.in rebaseall.in peflags.c rebase.c \
> + peflagsall.in rebaseall.in \
> + pechecksum.c pechecksum.h peflags.c rebase.c \
>   build.sh ChangeLog COPYING NEWS README setup.hint Todo \
>   build-aux/config.guess build-aux/config.sub \
>   build-aux/install-sh getopt.h_ getopt_long.c \
> -- 
> 2.39.0
> 


Pushed.


Thanks,
Corinna

Re: [PATCH rebase] peflags: Fix ULONG range checks

[Corinna Vinschen via Cygwin-apps]

On Aug  8 10:40, Christian Franke via Cygwin-apps wrote:
> Corinna Vinschen wrote:
> > On Aug  8 10:06, Christian Franke via Cygwin-apps wrote:
> > > Corinna Vinschen via Cygwin-apps wrote:
> > > > Hi Christian,
> > > > 
> > > > On Aug  7 16:07, Christian Franke via Cygwin-apps wrote:
> > > > > Minor issue found during tests of the upcoming 'peflags --timestamp' 
> > > > > patch.
> > > > > 
> > > > > -- 
> > > > > Regards,
> > > > > Christian
> > > > > 
> > > > > ...
> > > > > diff --git a/peflags.c b/peflags.c
> > > > > index 93eaa0b..d98b121 100644
> > > > > --- a/peflags.c
> > > > > +++ b/peflags.c
> > > > > @@ -30,7 +30,6 @@
> > > > >#include 
> > > > >#include 
> > > > >#include 
> > > > > -#include 
> > > > >#if defined (__CYGWIN__) || defined (__MSYS__)
> > > > >#include 
> > > > >#endif
> > > > > @@ -598,7 +597,7 @@ handle_num_option (const char *option_name,
> > > > >  || sizeof_vals[option_index].value > 0xULL
> > > > >  /* Just a ULONG value */
> > > > >  || (sizeof_vals[option_index].is_ulong
> > > > > -&& sizeof_vals[option_index].value > ULONG_MAX))
> > > > > +&& sizeof_vals[option_index].value > 
> > > > > 0xULL))
> > > > What about using MAXDWORD or MAXULONG32 instead?
> > > Of course :-)
> > > 
> > > Christian
> > > 
> > Pushed.  I've started deploying a new release.
> 
> I'm currently working on 'rebase -c, --checksum' and found one minor issue:
> pechecksum.* are missing in SRC_DISTFILES.

Ok, I stopped the deployment.  Are you going to send fixes?


Corinna

Re: [PATCH rebase] peflags: Fix ULONG range checks

[Corinna Vinschen via Cygwin-apps]

On Aug  8 10:06, Christian Franke via Cygwin-apps wrote:
> Corinna Vinschen via Cygwin-apps wrote:
> > Hi Christian,
> > 
> > On Aug  7 16:07, Christian Franke via Cygwin-apps wrote:
> > > Minor issue found during tests of the upcoming 'peflags --timestamp' 
> > > patch.
> > > 
> > > -- 
> > > Regards,
> > > Christian
> > > 
> > > ...
> > > diff --git a/peflags.c b/peflags.c
> > > index 93eaa0b..d98b121 100644
> > > --- a/peflags.c
> > > +++ b/peflags.c
> > > @@ -30,7 +30,6 @@
> > >   #include 
> > >   #include 
> > >   #include 
> > > -#include 
> > >   #if defined (__CYGWIN__) || defined (__MSYS__)
> > >   #include 
> > >   #endif
> > > @@ -598,7 +597,7 @@ handle_num_option (const char *option_name,
> > >  || sizeof_vals[option_index].value > 0xULL
> > >  /* Just a ULONG value */
> > >  || (sizeof_vals[option_index].is_ulong
> > > -&& sizeof_vals[option_index].value > ULONG_MAX))
> > > +&& sizeof_vals[option_index].value > 0xULL))
> > What about using MAXDWORD or MAXULONG32 instead?
> 
> Of course :-)
> 
> Christian
> 

Pushed.  I've started deploying a new release.


Thanks!
Corinna

Re: [PATCH rebase 2/2] peflags: Add -k, --checksum option

[Corinna Vinschen via Cygwin-apps]

On Aug  7 16:26, Christian Franke via Cygwin-apps wrote:
> This patch is on top of the --timestamp patch. Could not be applied to
> current HEAD without conflicts.
> 
> -- 
> Regards,
> Christian
> 

> From 9ecaf86bff5d229bf5b2a1ba1ff4674526fc1b68 Mon Sep 17 00:00:00 2001
> From: Christian Franke 
> Date: Mon, 7 Aug 2023 15:52:14 +0200
> Subject: [PATCH] peflags: Add -k, --checksum option
> 
> This allows to fix the file checksum in the PE header.
> An invalid checksum may break reproducible builds or may
> increase the risk of false positive malware detections.
> The checksum calculation is done by a new self-contained module
> 'pechecksum.c' which could also be built as a stand-alone tool
> or later added to rebase.
> 
> Signed-off-by: Christian Franke 
> ---
>  Makefile.in  |   6 +-
>  pechecksum.c | 195 +++
>  pechecksum.h |  25 +++
>  peflags.c| 129 --
>  4 files changed, 347 insertions(+), 8 deletions(-)
>  create mode 100644 pechecksum.c
>  create mode 100644 pechecksum.h

Pushed.


Thanks,
Corinna

Re: [PATCH rebase 1/2] peflags: Add -p, --timestamp option

[Corinna Vinschen via Cygwin-apps]

On Aug  7 16:16, Christian Franke via Cygwin-apps wrote:
> Running 'peflags -p /bin/*.exe' with the patch applied suggests that
> objcopy/strip recently changed behavior and no longer set timestamps to 0.
> 
> Related: https://sourceware.org/bugzilla/show_bug.cgi?id=30702
> 
> -- 
> Regards,
> Christian
> 

> From 68d42574e4b7bbc0659708ce801b6cd25b88dc11 Mon Sep 17 00:00:00 2001
> From: Christian Franke 
> Date: Mon, 7 Aug 2023 14:02:12 +0200
> Subject: [PATCH] peflags: Add -p, --timestamp option
> 
> This allows to set the header timestamp to 0 or some other fixed
> value (SOURCE_DATE_EPOCH) to support reproducible builds.
> 
> Signed-off-by: Christian Franke 
> ---
>  peflags.c | 29 +
>  1 file changed, 25 insertions(+), 4 deletions(-)

Pushed.


Thanks,
Corinna

Re: [PATCH rebase] peflags: Fix ULONG range checks

[Corinna Vinschen via Cygwin-apps]

Hi Christian,

On Aug  7 16:07, Christian Franke via Cygwin-apps wrote:
> Minor issue found during tests of the upcoming 'peflags --timestamp' patch.
> 
> -- 
> Regards,
> Christian
> 

> From 9da405da78e92dc8263239e25365bee3167f185e Mon Sep 17 00:00:00 2001
> From: Christian Franke 
> Date: Mon, 7 Aug 2023 13:42:50 +0200
> Subject: [PATCH] peflags: Fix ULONG range checks
> 
> Don't use ULONG_MAX from  because ULONG is not necessarily
> 'unsigned long'.
> 
> Signed-off-by: Christian Franke 
> ---
>  peflags.c | 5 ++---
>  1 file changed, 2 insertions(+), 3 deletions(-)
> 
> diff --git a/peflags.c b/peflags.c
> index 93eaa0b..d98b121 100644
> --- a/peflags.c
> +++ b/peflags.c
> @@ -30,7 +30,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #if defined (__CYGWIN__) || defined (__MSYS__)
>  #include 
>  #endif
> @@ -598,7 +597,7 @@ handle_num_option (const char *option_name,
>  || sizeof_vals[option_index].value > 0xULL
>  /* Just a ULONG value */
>  || (sizeof_vals[option_index].is_ulong
> -&& sizeof_vals[option_index].value > ULONG_MAX))
> +&& sizeof_vals[option_index].value > 0xULL))

What about using MAXDWORD or MAXULONG32 instead?


Corinna

Re: cygwin-pkg-maint enhancements

[Corinna Vinschen via Cygwin-apps]

On Jun 18 12:06, Jon Turney via Cygwin-apps wrote:
> On 16/06/2023 10:47, Corinna Vinschen via Cygwin-apps wrote:
> > On Jun 11 19:01, Jon Turney via Cygwin-apps wrote:
> > > 
> > > I've deployed an update to calm which makes a few small improvements to 
> > > the
> > > way cygwin-pkg-maint is handled:
> > > 
> > > * Lines starting with a '#' are now ignored as a comment
> > > 
> > > * There's now a simple facility for grouping packages:
> > > 
> > > Define a group with a line starting with '@', e.g.:
> > > 
> > >  @upstream_project Maintainer1/Maintainer2
> > > 
> > > Then @upstream_project can used in a package's maintainer list, as a
> > > reference to that list of maintainers.
> > 
> > That's a great change. Thanks!
> > 
> > Would adding glob patterns help, too?  Kind of like
> > 
> >aspell
> >aspell-*
> > 
> 
> Well, maybe.
> 
> That's a more complex change, as the code just does a simple lookup by
> source package name at the moment.

Yeah, ok.  It would have to call the python glob function instead.
Assuming there is one, but I guess there is.

> It would also introduce the possibility for ambiguity. e.g. What is the
> following intended to mean?
> 
> aspell-* Aye Person
> aspell-gibberish Anne Other

True. I thought we could simply avoid that, given we maintain the file
manually anyway.

Assuming the file is searched lineary from top to bottom, the problem
could be simply fixed by switching the order:

  aspell-gibberish Anne Other
  aspell-* Aye Person

So, ordering from strict to fuzzy.

Anyway, it was just an idea.  We made it to here without globbing,
so it's not as if that would be necessary.


Corinna

Re: cygwin-pkg-maint enhancements

[Corinna Vinschen via Cygwin-apps]

On Jun 11 19:01, Jon Turney via Cygwin-apps wrote:
> 
> I've deployed an update to calm which makes a few small improvements to the
> way cygwin-pkg-maint is handled:
> 
> * Lines starting with a '#' are now ignored as a comment
> 
> * There's now a simple facility for grouping packages:
> 
> Define a group with a line starting with '@', e.g.:
> 
> @upstream_project Maintainer1/Maintainer2
> 
> Then @upstream_project can used in a package's maintainer list, as a
> reference to that list of maintainers.

That's a great change. Thanks!

Would adding glob patterns help, too?  Kind of like

  aspell
  aspell-* 

instead of having to mention every single language pack, or

  autoconf*
  automake*


Corinna

Re: Trusted maintainers (was: Re: How does a package become orphaned? (was Re: Attn maintainer: python-paramiko))

[Corinna Vinschen via Cygwin-apps]

On May 13 12:18, Marco Atzeri via Cygwin-apps wrote:
> On 11.05.2023 15:57, Andrew Schulman via Cygwin-apps wrote:
> > > Entrusted with these strange superpowers, the following god-like beings
> > > walk unknown amongst us:
> > > 
> > > Achim Gratz
> > > Corinna Vinschen
> > > Ken Brown
> > > Marco Atzeri
> > 
> > Hippos! https://cygwin.com/goldstars/
> > 
> 
> I have the impression that Jon is also in the list

Hehe.

> another Hippo please for all the work he is doing on the infrastructure
> of the Cygwin project.

I second that and it already occured, fortunately.

But here's a strange thought...

Would it make sense to document this somewhere, like, say, on
the cygwin website?  Or did this already happen?


Thanks,
Corinna

Re: [PATCH setup 0/2] Detect filename collisions between packages

[Corinna Vinschen via Cygwin-apps]

Hi Jon,

On Apr 23 15:43, Jon Turney via Cygwin-apps wrote:
> This is a woefully underoptimized implementation of detecting filename
> collisions between packages, so it's hidden behind the command line option
> '--collisions' to enable it.
> 
> A good implementation probably (i) collects the filenames at the same time
> as checksumming the archive, or has them attached to it somehow by the
> packaging process, and (ii) uses a libsolv string pool to hold the filenames
> (so we only need to compute the intersection and unions of sets of integers,
> which is hopefully much faster)
> 
> Nevertheless, this labouriously identifies some obvious collisions which I
> might bring to the attention of package maintainers when I have some time to
> do so...

Theoretically, wouldn't this be better handled in the upload process, i.
e. by calm, rather than during the download process?

Calm could create a database containing all the files from the tar
archives it uploads, and compare that against the newly uploaded files
on the fly.  So it could just refuse to upload packages with files
already present in another package.  I don't think such a database would
take too much space on sware.  This may be much less time consuming and
it would prevent the collisions before they even occur.

There's probably another problem in terms of different file lists in
different package versions, though...


Corinna

Re: [PATCH v2] peflags: add support for IMAGE_DLLCHARACTERISTICS_GUARD_CF

[Corinna Vinschen via Cygwin-apps]

Hi Christoph,

On Apr 17 20:40, Christoph Reiter via Cygwin-apps wrote:
> This allows for setting, clearing, and displaying the value of the
> "control flow guard" dll characteristics flag.
> 
> The flag for MSVC is called "/guard:cf" and the macro ends with "GUARD_CF".
> To keep things consistent, it would make sense to name the option "guard-cf".
> However, there's already "-c"/"control-flow-guard" in genpeimg for this flag,
> and genpeimg shares all other options with peflags so far.
> So, follow genpeimg and go with "-c" and "--control-flow-guard".
> 
> This is motivated by mingw-w64 and llvm v16 gaining support for
> CFG (Control Flow Guard).
> ---
> Renamed the option from -g/--guard-cf to -c/--control-flow-guard
> 
>  peflags.c | 12 ++--
>  1 file changed, 10 insertions(+), 2 deletions(-)

Pash pushed.  I new rebase 4.6.3 release with your patch is just
building.


Thanks,
Corinna

Re: [PATCH] peflags: add support for IMAGE_DLLCHARACTERISTICS_GUARD_CF

[Corinna Vinschen via Cygwin-apps]

Hi Christoph,

your patch looks good and I'm happy to merge it into peflags, but...

On Apr 17 09:48, Christoph Reiter via Cygwin-apps wrote:
> Jeremy noted that an option already exists in genpeimage [0] but with
> a different name, which I wasn't aware of: -c/control-flow-guard,
> instead of -g/guard-cf which I used here. I'm open to making them
> match.

yeah, given that peflags and genpeimg use the same single char
flags, it might be a good idea to follow suit.


Thanks,
Corinna

Re: pinfo build fails with undefined macro: AM_INTL_SUBDIR

[Corinna Vinschen via Cygwin-apps]

On Apr 11 09:21, Andrew Schulman via Cygwin-apps wrote:
> I'm trying to rebuild pinfo 0.6.13. That's the current version in Cygwin, so I
> know I was able to build it successfully a couple of years ago. But now when I
> try, the build fails with 
> 
> error: possibly undefined macro: AM_INTL_SUBDIR
> 
> I'm afraid my grasp of autotools is too weak for me to know what the problem 
> is
> here. At present I'm using the inherited src_complile() function from
> autotools.cygclass. In the past I used:
> 
> src_compile ()
> {
> cd "$S"
> gettextize -f   # needed to create tools/config.rpath
> cygautoreconf --install
> cd "$B"
> cygconf
> cygmake
> }
> 
> but that doesn't fix the AM_INTL_SUBDIR problem.

Check configure.ac which version of autotools is required.  There's a
good chance you need autoconf 2.69.  You can probably fix that problem
in the cygport file by adding

  WANT_AUTOCONF="2.5"


Corinna

Re: Fwd: calm: cygwin package report for Ken Brown

[Corinna Vinschen via Cygwin-apps]

On Mar 20 23:17, Jon Turney via Cygwin-apps 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.

Wouldn't it make sense to be able to define this in the cygport file
somehow?  Or does that open a can of worms?


Corinna

Re: grep rebuild?

[Corinna Vinschen via Cygwin-apps]

On Mar 17 10:03, Corinna Vinschen via Cygwin-apps wrote:
> On Mar 16 18:50, Brian Inglis via Cygwin-apps wrote:
> > On 2023-03-16 10:50, Brian Inglis via Cygwin-apps wrote:
> > > On 2023-03-16 06:08, Corinna Vinschen via Cygwin-apps wrote:
> > > > Hi Brian,
> > > > 
> > > > there's a problem with the grep package.  It uses the internally
> > > > provided GNULIB regex library.
> > > > 
> > > > Unfortunately, that's the default if the system doesn't provide a more
> > > > recent GLibc.  Which we'll never do.  The problem is this: Native
> > > > language support in GNULIB's regex is *only* available, if it's built as
> > > > part of GLibc.
> > > > 
> > > > I'd like to ask you to rebuild grep 3.9 with the
> > > > --without-included-regex option.
> > > > 
> > > > That will allow grep to use Cygwin's own regex, which already comes with
> > > > basic native language support, and which I'm working on to sbetter
> > > > support equivalence class and collation symbol expressions.
> > > 
> > > Hi Corinna,
> > > 
> > > We discussed this and I was going to release grep 3.8 test release 3,
> > > for testing with snapshots or when Cygwin 3.5.0 is released, then grep
> > > 3.9 came out, and I realized grep is updated every few months, so that
> > > went on the back burner. I can do a test release for 3.9-2 with that
> > > configuration change.
> > > 
> > > The current release passes all the class tests and works for me and 
> > > Andrey.
> > > Are there any other implications of language support affecting grep?
> > 
> > Config option --without-included-regex no longer seems to build with grep
> > 3.9 on Cygwin - may require glibc regex - or may now autoconfig depending on
> > [g]libc?
> > 
> > /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
> > dfasearch.o: in function `regex_compile':
> > /usr/src/debug/grep-3.9-2/src/dfasearch.c:159: undefined reference to
> > `re_set_syntax'
> 
> What a piece of crap!  So you either run a GLibc system, or you're
> forced to use GNULIB regex because grep uses non-standard functions
> in the generic code.
> 
> We should switch to FreeBSD grep, it still uses POSIX functions.
> What a laugh...

And just for kicks, FreeBSD grep is mostly option compatible with
GNU grep.  The missing options are:

  -P, --perl-regexp
  --no-ignore-case  (but --ignore-case exists)
  -y(obsolete anyway)
  -T, --initial-tab
  -Z(but --null exists)
  --group-separator
  --no-group-separator
  --exclude-from
  -I(but --binary-files exists)
  -R, --dereference-recursive

I wonder if I should create a freebsd-grep package, installing
its grep as 'bsdgrep' or something


Corinna

Re: grep rebuild?

[Corinna Vinschen via Cygwin-apps]

On Mar 16 18:50, Brian Inglis via Cygwin-apps wrote:
> On 2023-03-16 10:50, Brian Inglis via Cygwin-apps wrote:
> > On 2023-03-16 06:08, Corinna Vinschen via Cygwin-apps wrote:
> > > Hi Brian,
> > > 
> > > there's a problem with the grep package.  It uses the internally
> > > provided GNULIB regex library.
> > > 
> > > Unfortunately, that's the default if the system doesn't provide a more
> > > recent GLibc.  Which we'll never do.  The problem is this: Native
> > > language support in GNULIB's regex is *only* available, if it's built as
> > > part of GLibc.
> > > 
> > > I'd like to ask you to rebuild grep 3.9 with the
> > > --without-included-regex option.
> > > 
> > > That will allow grep to use Cygwin's own regex, which already comes with
> > > basic native language support, and which I'm working on to sbetter
> > > support equivalence class and collation symbol expressions.
> > 
> > Hi Corinna,
> > 
> > We discussed this and I was going to release grep 3.8 test release 3,
> > for testing with snapshots or when Cygwin 3.5.0 is released, then grep
> > 3.9 came out, and I realized grep is updated every few months, so that
> > went on the back burner. I can do a test release for 3.9-2 with that
> > configuration change.
> > 
> > The current release passes all the class tests and works for me and Andrey.
> > Are there any other implications of language support affecting grep?
> 
> Config option --without-included-regex no longer seems to build with grep
> 3.9 on Cygwin - may require glibc regex - or may now autoconfig depending on
> [g]libc?
> 
> /usr/lib/gcc/x86_64-pc-cygwin/11/../../../../x86_64-pc-cygwin/bin/ld:
> dfasearch.o: in function `regex_compile':
> /usr/src/debug/grep-3.9-2/src/dfasearch.c:159: undefined reference to
> `re_set_syntax'

What a piece of crap!  So you either run a GLibc system, or you're
forced to use GNULIB regex because grep uses non-standard functions
in the generic code.

We should switch to FreeBSD grep, it still uses POSIX functions.
What a laugh...


Not amused,
Corinna

Re: grep rebuild?

[Corinna Vinschen via Cygwin-apps]

On Mar 16 20:31, Corinna Vinschen via Cygwin-apps wrote:
> Please note that, right now, collating symbols and equivalence classes
> *only* work in the Cygwin main branch in glob(3) and fnmatch(3), but NOT
> YET in regex(3).  That's what I'm planning to add in the next couple of
> weeks (or months...)

And, just to be clear, that's what we *never* get with GNULIB's
regex(3).  The reason is that collating and equivalence are properties
which can only be handled correctly in that regex implementation, if the
code has access to the locale info files maintained by the Glibc code.


Corinna

Re: grep rebuild?

[Corinna Vinschen via Cygwin-apps]

On Mar 16 10:50, Brian Inglis via Cygwin-apps wrote:
> On 2023-03-16 06:08, Corinna Vinschen via Cygwin-apps wrote:
> > Hi Brian,
> > 
> > there's a problem with the grep package.  It uses the internally
> > provided GNULIB regex library.
> > 
> > Unfortunately, that's the default if the system doesn't provide a more
> > recent GLibc.  Which we'll never do.  The problem is this: Native
> > language support in GNULIB's regex is *only* available, if it's built as
> > part of GLibc.
> > 
> > I'd like to ask you to rebuild grep 3.9 with the
> > --without-included-regex option.
> > 
> > That will allow grep to use Cygwin's own regex, which already comes with
> > basic native language support, and which I'm working on to sbetter
> > support equivalence class and collation symbol expressions.
> 
> Hi Corinna,
> 
> We discussed this and I was going to release grep 3.8 test release 3, for
> testing with snapshots or when Cygwin 3.5.0 is released, then grep 3.9 came
> out, and I realized grep is updated every few months, so that went on the
> back burner. I can do a test release for 3.9-2 with that configuration
> change.
> 
> The current release passes all the class tests and works for me and Andrey.
> Are there any other implications of language support affecting grep?

As I wrote above, equivalence class and collation symbol expressions.
Character clasess are easy and basically always supported, they don't
really count.

Here's what I expect to work:

First an example with equivalence class. "./fnmatch" is a simple
application calling fnmatch, with 1st arg being the glob expression
and the 2nd arg being the search expression. Locale is simple
en_US.utf8.  Note the accented uppercase À!

  $ /fnmatch '[[=a=]]' 'a'
  fnmatch ([[=a=]], a, 0) = 0 (en_US.utf8)
  $ ./fnmatch '[[=a=]]' 'b'
  fnmatch ([[=a=]], b, 0) = 1 (en_US.utf8)
  $ ./fnmatch '[[=a=]]' 'À'
  fnmatch ([[=a=]], À, 0) = 0 (en_US.utf8)
  $ ./fnmatch '[[=À=]]' 'a'
  fnmatch ([[=À=]], a, 0) = 0 (en_US.utf8)

As you can see, the non-accented a and the accented À belong
to the same equivalence class.

Now let's try grep on Cygwin:

  $ echo 'a' | LC_COLLATE=en_US.utf8 grep '[[=a=]]'
  a
  $ echo 'b' | LC_COLLATE=en_US.utf8 grep '[[=a=]]'
  $ echo 'À' | LC_COLLATE=en_US.utf8 grep '[[=a=]]'
  $ echo 'a' | LC_COLLATE=en_US.utf8 grep '[[=À=]]'
  grep: Invalid collation character

The first two results are expected, but not the third and forth result.

Let's try the same on Linux:

  $ echo 'a' | LC_COLLATE=en_US.utf8 grep '[[=a=]]'
  a
  $ echo 'b' | LC_COLLATE=en_US.utf8 grep '[[=a=]]'
  $ echo 'À' | LC_COLLATE=en_US.utf8 grep '[[=a=]]'
  À
  $ echo 'a' | LC_COLLATE=en_US.utf8 grep '[[=À=]]'
  a

See the difference?

Next, let's try a collating element:

"./glob" is a simple test app calling glob and
setting the locale to the second argument.  There's a file called
"chakref" in the CWD:

There's no collating element "ch" in English:

  $ ./glob '[[.ch.]]*' en_US.utf8
  glob ([[.ch.]]*) = -3

But in Czech:

  $  ./glob '[[.ch.]]*' cs_CZ.utf8
  chakref

Try this with current grep:

  $ ls -1 | LC_COLLATE=en_US.utf8 grep '^[[.ch.]].*'
  grep: Invalid collation character

Ok.

  $ ls -1 | LC_COLLATE=cs_CZ.utf8 grep '^[[.ch.]].*'
  grep: Invalid collation character

Not ok.

On Linux:
  
  $ ls -1 | LC_COLLATE=en_US.utf8 grep '^[[.ch.]].*'
  grep: Invalid collation character

Ok.

  *[~]$ ls -1 | LC_COLLATE=cs_CZ.utf8 grep '^[[.ch.]].*'
  chakref

Ok.

Please note that, right now, collating symbols and equivalence classes
*only* work in the Cygwin main branch in glob(3) and fnmatch(3), but NOT
YET in regex(3).  That's what I'm planning to add in the next couple of
weeks (or months...)


Thanks,
Corinna

grep rebuild?

[Corinna Vinschen via Cygwin-apps]

Hi Brian,

there's a problem with the grep package.  It uses the internally
provided GNULIB regex library.

Unfortunately, that's the default if the system doesn't provide a more
recent GLibc.  Which we'll never do.  The problem is this: Native
language support in GNULIB's regex is *only* available, if it's built as
part of GLibc.

I'd like to ask you to rebuild grep 3.9 with the
--without-included-regex option.

That will allow grep to use Cygwin's own regex, which already comes with
basic native language support, and which I'm working on to sbetter
support equivalence class and collation symbol expressions.


Thanks,
Corinna

Re: scallywag

[Corinna Vinschen via Cygwin-apps]

On Mar 11 11:54, Ken Brown via Cygwin-apps wrote:
> On 3/11/2023 2:18 AM, Marco Atzeri via Cygwin-apps wrote:
> > may I propose another PLUSH HIPPO for Jon Turney for
> > implementating and maintaining scallywag ?
> 
> Seconded!

Thirded! :)


Corinna

Re: man-pages-linux needs case sensitive directories

[Corinna Vinschen via Cygwin-apps]

On Feb 15 00:11, Brian Inglis via Cygwin-apps wrote:
> Hi folks,
> 
> Linux man pages 6.03 has been released.
> I realized that some of the man pages are case sensitive e.g. _[Ee]xit.2,
> {NAN,nan}.3, perhaps others.
> I took care of my own system using commands like below, but would appreciate
> advice on whether there is any better portable or Cygwin specific approach,
> and what are the opinions on the best way to handle this in the cygport for
> download and install?
> Is this supported by Cygwin on Windows 10 versions >= [20]18-03 with the
> directory attribute set, are there likely to be any problems with git, or in
> general with POSIX<->Windows file names?
> 
> $ cd /usr/share/man/linux/
> $ for s in man?; do fsutil file setCaseSensitiveInfo $s; done

You can do this in Cygwin with the chattr(1) tool, see chattr --help.
The hint "WSL must be installed" appears to be outdated, at least on
Windows 11.  There are two approaches for case-sensitivity, see

  
https://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-casesensitive

  
https://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-casesensitivedirs

However, as part of the distro, the package must not rely on
case-sensitivity.  We have to assume that most users are using Windows
in default settings.  And we still support Windows versions prior to
Windows 10 1803.  But even then, I encountered serious trouble with
case-sensitive directories on remote shares, see

  https://github.com/microsoft/WSL/issues/3885

so you'd get into trouble if the Cygwin installation is on a share.

For colliding man pages, what you can do is to append a character to
the man page file, so you can install both.  For instance:

  exit.2
  Exit.2a

  nan.3
  NAN.3a

Kind of like that.


Corinna

Re: [PATCH 1/2 v2] Filter newlines from BUILD_REQUIRES

[Corinna Vinschen via Cygwin-apps]

On Dec  3 18:07, Jon Turney via Cygwin-apps wrote:
> On 03/12/2022 16:19, Corinna Vinschen via Cygwin-apps wrote:
> > From: Corinna Vinschen 
> > 
> > BUILD_REQUIRES is added verbatim to the build-depends: line in
> > the *-src.hint file.  If the cygport file defines BUILD_REQUIRES
> > with newlines, e. g.
> > 
> >BUILD_REQUIRES="
> >  a
> >  b
> >"
> > 
> > The -src.hint file is broken.  Avoid this by filtering out any
> > newline's from BUILD_REQUIRES before using it in the subsequent
> > expression building the -src.hint file.
> 
> Thanks.
> 
> Attached is a patch I wrote taking a slightly more general approach.

Yeah, that looks much better to me.


Thanks,
Corinna

[PATCH 1/2 v2] Filter newlines from BUILD_REQUIRES

[Corinna Vinschen via Cygwin-apps]

From: Corinna Vinschen 

BUILD_REQUIRES is added verbatim to the build-depends: line in
the *-src.hint file.  If the cygport file defines BUILD_REQUIRES
with newlines, e. g.

  BUILD_REQUIRES="
a
b
  "

The -src.hint file is broken.  Avoid this by filtering out any
newline's from BUILD_REQUIRES before using it in the subsequent
expression building the -src.hint file.

Signed-off-by: Corinna Vinschen 
---
 lib/pkg_pkg.cygpart | 4 
 1 file changed, 4 insertions(+)

diff --git a/lib/pkg_pkg.cygpart b/lib/pkg_pkg.cygpart
index 82112e1cfc79..eb06a08dd562 100644
--- a/lib/pkg_pkg.cygpart
+++ b/lib/pkg_pkg.cygpart
@@ -544,6 +544,10 @@ __pkg_srcpkg() {
elif [ -n "${!pkg_category_var:-${CATEGORY}}" \
-a -n 
"${!pkg_summary_var:-${SUMMARY}}${!pkg_description_var:-${DESCRIPTION}}" ]
then
+   # BUILD_REQUIRES is added to the build-depends: line
+   # in the hint file written below.  Convert LFs to
+   # spaces to make sure it's actually a single line.
+   BUILD_REQUIRES=$(echo -n "$BUILD_REQUIRES" | tr '\n' ' 
')
cat > ${distdir}/${PN}/${PN}-${PVR}-src.hint <<-_EOF
 category: ${!pkg_category_var:-${CATEGORY}}
 build-depends: cygport ${BUILD_REQUIRES}
-- 
2.38.1

[PATCH 2/2] Default to x86_64 build on non-Cygwin hosts

[Corinna Vinschen via Cygwin-apps]

From: Corinna Vinschen 

Given x86 has been deprecated, we only have a single target for
the time being.  Default to this target for now, basically to
safe my lazy ass when building on Linux.

Signed-off-by: Corinna Vinschen 
---
 NEWS  | 3 +++
 lib/compilers.cygpart | 2 +-
 2 files changed, 4 insertions(+), 1 deletion(-)

diff --git a/NEWS b/NEWS
index 976237d88d54..e3dc83c3f5a4 100644
--- a/NEWS
+++ b/NEWS
@@ -1,3 +1,6 @@
+0.35.5:
+   * Default to x86_64-pc-cygwin target on Linux.
+
 0.35.4:
* Replace 'egrep' with 'grep -E' throughout
* xorg: Default LICENSE to 'MIT'
diff --git a/lib/compilers.cygpart b/lib/compilers.cygpart
index f9b8c69532e2..35e6fe2886f9 100644
--- a/lib/compilers.cygpart
+++ b/lib/compilers.cygpart
@@ -213,7 +213,7 @@ case ${CBUILD} in
 # https://sourceware.org/legacy-ml/cygwin-developers/2013-02/msg00132.html
 x86_64-unknown-cygwin)  CBUILD="x86_64-pc-cygwin" ;&
 *-cygwin)  CHOST="${_host_arch:-${CBUILD%%-*}}-pc-cygwin" ;;
-*) defined _host_arch || error "Either --32 or --64 flags MUST be 
passed to cygport"
+*) defined _host_arch || _host_arch="x86_64"
CHOST="${_host_arch}-pc-cygwin" ;;
 esac
 unset _host_arch
-- 
2.38.1

[PATCH 1/2] Filter newlines from BUILD_REQUIRES

[Corinna Vinschen via Cygwin-apps]

From: Corinna Vinschen 

BUILD_REQUIRES is added verbatim to the build-depends: line in
the *-src.hint file.  If the cygport file defines BUILD_REQUIRES
with spaces, e. g.

  BUILD_REQUIRES="
a
b
  "

The -src.hint file is broken.  Avoid this by filtering out any
newline's from BUILD_REQUIRES before using it in the subsequent
expression building the -src.hint file.

Signed-off-by: Corinna Vinschen 
---
 lib/pkg_pkg.cygpart | 4 
 1 file changed, 4 insertions(+)

diff --git a/lib/pkg_pkg.cygpart b/lib/pkg_pkg.cygpart
index 82112e1cfc79..eb06a08dd562 100644
--- a/lib/pkg_pkg.cygpart
+++ b/lib/pkg_pkg.cygpart
@@ -544,6 +544,10 @@ __pkg_srcpkg() {
elif [ -n "${!pkg_category_var:-${CATEGORY}}" \
-a -n 
"${!pkg_summary_var:-${SUMMARY}}${!pkg_description_var:-${DESCRIPTION}}" ]
then
+   # BUILD_REQUIRES is added to the build-depends: line
+   # in the hint file written below.  Convert LFs to
+   # spaces to make sure it's actually a single line.
+   BUILD_REQUIRES=$(echo -n "$BUILD_REQUIRES" | tr '\n' ' 
')
cat > ${distdir}/${PN}/${PN}-${PVR}-src.hint <<-_EOF
 category: ${!pkg_category_var:-${CATEGORY}}
 build-depends: cygport ${BUILD_REQUIRES}
-- 
2.38.1

Re: autoconf

[Corinna Vinschen via Cygwin-apps]

On Dec  2 14:18, ASSI wrote:
> Jan Nijtmans via Cygwin-apps writes:
> > My 2c : Cygwin should - at least - allow people to install autoconf-2.71
> > and - as long as the packages are prepared for it - things shouldn't break.
> 
> As I said, I haven't looked at it in any detail, but it seems that
> autoconf is already multi-version, so I guess it would be possible to
> introduce an autoconf2.7 package in addition to the existing two.
> That's a slightly wonky way to do that when we expect to later on just
> replace 2.69 with 2.71, though.

Don't do that.  https://lwn.net/Articles/839395/

autoconf 2.70 and later are new, backward incompatible versions, so they
should go into a new-and-shiny-and-not-yet-existing autoconf2.7 package.


Corinna

Re: autoconf

[Corinna Vinschen via Cygwin-apps]

On Dec  2 11:15, Jan Nijtmans via Cygwin-apps wrote:

> Op do 2 dec. 2021 om 10:22 schreef Corinna Vinschen via Cygwin-apps:

Nope, I didn't.  Make that:

On Dec  2 08:23, ASSI wrote:

> > > Most distros still package 2.69 or even earlier and that includes some
> > > substantial rolling release distros.  As long as these guys don't use
> > > the newer version it seems unlikely that we would actually need it, plus
> > > I don't see us spending time and effort debugging things that aren't
> > > even Cygwin specific.
> 
> My 2c : Cygwin should - at least - allow people to install autoconf-2.71
> and - as long as the packages are prepared for it - things shouldn't break.
> 
> If I install autoconf-2.71 locally, and then compile Tcl 8.6.12, which
> contained in tcl.cygport:
> src_compile() {
> cd ${S}/unix
> cygautoreconf
> ...
> 
> $ cygport tcl.cygport compile
> >>> Compiling tcl-8.6.12-1.x86_64
> *** ERROR: autoconf2.5 is required to build this package
> 
> 
> My solution was, simply to remove the "cygautoreconf" line from the
> cygport file, then it works again.
> 
> Somewhere in cygport, a check is done for the autoconf version, please
> change this check to allow autoconf 2.71 (as well as 2.59 and 2.69).
> Then I can put back the "cygautoreconf" line in tcl.cygport.
> 
> Thanks!
>   Jan Nijtmans

Re: autoconf

[Corinna Vinschen via Cygwin-apps]

On Dec  2 08:23, ASSI wrote:
> Brian Inglis writes:
> >> How likely is it that they actually rely on that version already?
> >
> > Somewhat likely for some GNU packages and gnulib macros that specify
> > version prereqs: AC_PREREQ is used in 80 packages I have sources for.
> 
> Most distros still package 2.69 or even earlier and that includes some
> substantial rolling release distros.  As long as these guys don't use
> the newer version it seems unlikely that we would actually need it, plus
> I don't see us spending time and effort debugging things that aren't
> even Cygwin specific.
> 
> > After that version released in January, I've only had to patch one
> > package so far, which specified it in August, and they later reduced
> > it after discussion with distro package maintainers:
> >
> > $ grep 'AC_PREREQ(\[2\.[0-9]\+\])' */*.patch
> > bison/bison-3.7.90-revert-autoconf-upgrade.patch:-AC_PREREQ([2.71])
> > bison/bison-3.7.90-revert-autoconf-upgrade.patch:+AC_PREREQ([2.68])
> > wget2/configure-ac.upstream.patch:-AC_PREREQ([2.67])
> > wget2/configure-ac.upstream.patch:+AC_PREREQ([2.69])
> > Xcurses/x11-aclocal-m4-libtoolize.patch:+[AC_PREREQ([2.62])dnl We use
> > AC_PATH_PROGS_FEATURE_CHECK
> 
> That's called "jumping the gun" I think.  The distro package maintainers
> will be in their ears immediately and we can just sit back with the
> popcorn.

gawk has moved to AC_PREREQ([2.71]) and the maintainer does not want to
go back.  I had to patch that already for Cygwin's gawk 5.1.1-1.


Corinna

Re: [ATTN MAINTAINER] openssh

[Corinna Vinschen via Cygwin-apps]

On Nov 28 10:53, Achim Gratz wrote:
> Achim Gratz writes:
> > These patches work for 32bit also and I believe they are correct, but
> > that build should not be made available due to a bug in libfido2 that
> > crashes when trying to free the memory associated with the WebAuthn
> > payload returned.  Without these patches applied you can still use the
> > fallback to USB-HID when you are an administrator.
> 
> The call into WebAuthn completely messes up the stack apparently.  The
> returned object looks OK once you realize it is a version 1 and thus the
> extension fields are bogus, but the whole thing crashes if you do just
> one more call.  Gdb session:
> 
> https://paste.c-net.org/SerumLoser
> 
> Any ideas what that might be?

For the bystanders, on a hunch I created a libfido2 patch to change
the calling convention for the dynamically loaded windows functions.
Let's see if Achim's testing now succeeds on 32 bit...


Corinna

Re: Tcl/Tk 8.6.12

[Corinna Vinschen via Cygwin-apps]

On Nov 15 13:31, Jan Nijtmans via Cygwin-apps wrote:
> The following packages have been uploaded to the Cygwin distribution:
> 
> * tcl-8.6.12-1
> * tcl-devel-8.6.12-1
> * tcl-tk-8.6.12-1
> * tcl-tk-devel-8.6.12-1
> * tcl-itcl-4.2.2-1
> * tcl-itcl-devel-4.2.2-1
> * tcl-itk-4.2.2-1
> * tcl-itk-devel-4.2.2-1
> * tcl-iwidgets-4.1.1-1
> * mingw64-i686-tcl-8.6.12-1
> * mingw64-i686-tk-8.6.12-1
> * mingw64-x86_64-tcl-8.6.12-1
> * mingw64-x86_64-tk-8.6.12-1
> 
> This is an update and rebuild of the Tcl/Tk stack to the latest upstream
> releases.
> 
> Regards,
>  Jan Nijtmans

Was that supposed to go to cygwin-announce?

  cygport  announce

should do this for you.


Corinna

Re: OpenSSL package updates

[Corinna Vinschen via Cygwin-apps]

On Nov  6 20:59, Achim Gratz wrote:
> Corinna Vinschen via Cygwin-apps writes:
> > That started with OpenSSL 0.9.5 I think, I'm not sure anymore.  You
> > should be able to do this in a single step, as long as you craft the
> > dependencies so that an update of the openssl package pulls in the
> > openssl10 package with the old lib.  As soon as all dependent distro
> > packages are updated, you can just drop the dependency and then the old
> > package entirely.
> 
> I was hoping there was a precedent we could use for this.
> 
> The idea would be that the old openssl dependencies are all converted to
> point to mingw64-*-openssl10 instead and the old packages either renamed
> or removed before the (final?) update to mingw64-*-openssl-1.0.2u+za.
> Then drop in mingw64-*-openssl-1.1.1l openssl, which most packages that
> are still actively maintained would probably need anyway during one of
> their next updates.

You create a new mingw-openssl10 package set, or even just a single
package only providing the openssl 1.0 DLLs, i.e. mingw-libopenssl100.

Then you create the mingw-openssl packages with the new 1.1 version.
The mingw-libopenssl110 package gets an extra dependency to
mingw-libopenssl100.  That will work OOTB without having to fix the
dependent package hints.

The old openssl packages providing the previous 1.0 versions should
better get removed, I guess.

In a second step the dependencies in the below packages could be changed
to require the mingw-libopenssl100 package.  At least that would be
better for bookkeeping.  Does that require manual intervention on the
server?  I'm not sure, Jon would know this better.

Corinna


> 
> The packages that are affected:
> 
> mingw64-*-botan
> mingw64-*-curl
> mingw64-*-gnome-vfs
> mingw64-*-gstreamer
> mingw64-*-libevent
> mingw64-*-libgda
> mingw64-*-liboauth
> mingw64-*-libshout
> mingw64-*-libssl2
> mingw64-*-libzip
> mingw64-*-mariadb-connector
> mingw64-*-neon
> mingw64-*-nghttp
> mingw64-*-opusfile
> mingw64-*-postgresql
> mingw64-*-qca
> mingw64-*-qt4
> mingw64-*-qt5-base
> mingw64-*-glib2
> mingw64-*-unbound

Re: OpenSSL package updates

[Corinna Vinschen via Cygwin-apps]

On Nov  6 16:58, Achim Gratz wrote:
> Achim Gratz writes:
> > I have updated the recently released Cygwin packages with all upstream
> > patches from Fedora plus the patches for all CVE affecting version 1.0.2
> > since the last official version and changed the cygport files so they
> > build on AppVeyor.  The packages have been pushed to the respective
> > playground branches:
> >
> > https://cygwin.com/git-cygwin-packages?p=git/cygwin-packages/openssl10.git;a=shortlog;h=refs/heads/playground
> > https://cygwin.com/git-cygwin-packages?p=git/cygwin-packages/openssl.git;a=shortlog;h=refs/heads/playground
> 
> I've just updated the playground branches with the respective MinGW64
> OpenSSL packages integrated (I needed to drop two patches from Fedora
> for OpernSSL 1.0 because they were using an API not available on
> MinGW64.
> 
> > I have not yet looked at the MingW64 libraries and I will not have time
> > next week to do any further work.  I might do an ITA later on when I
> > have everything completed.  I'd appreciate if someone would take a look
> > and test these builds in the meantime.
> 
> So it turns out that there weren't any OpenSSL 1.1 packages for MinGW64
> existing and so the OpenSSL 1.0 packages are still named *-openssl
> instead of *-openssl10.  I haven't yet tried to build the 1.1 versdion
> for MinGW64, but I'd tend to do the rename first and then clobber the
> *-openssl name for the newer version.  How was that handled for the
> Cygwin packages?

That started with OpenSSL 0.9.5 I think, I'm not sure anymore.  You
should be able to do this in a single step, as long as you craft the
dependencies so that an update of the openssl package pulls in the
openssl10 package with the old lib.  As soon as all dependent distro
packages are updated, you can just drop the dependency and then the old
package entirely.


Corinna

Re: github password policy

[Corinna Vinschen via Cygwin-apps]

On Aug 16 14:13, Thomas Wolff wrote:
> github have changed their authentication policy not to allow passwords
> anymore.
> So they are asking maintainers to acquire another kind of password (a
> "token"), which I did a while ago.
> But they refuse to support users with the transition, there is no
> "plug-and-play" howto available, except for those who are willing to dive
> into details of authentication stuff and spend a few study hours on that
> useless policy change.
> As I cannot update mintty anymore right now from the git command line, is
> any maintainer here impacted by the same issue and can help out with some
> advice how to get rid of this nuisance?

ssh pubkey works nicely, afaik.


Corinna

Re: [PATCH setup 06/11] Enable SeCreateSymbolicLink privilege

[Corinna Vinschen via Cygwin-apps]

On Aug 10 18:02, Jon Turney wrote:
> I'm not sure if SeCreateSymbolicLink privilege can get removed by UAC
> filtering, but to make sure to enable it, if we can.

I'm not sure this is required.  This is one of the privileges which is
enabled automatically on usage if it's present in the token and not
marked as "deny only".  UAC removes the privilege entirely from the
token, so you can't enable it in that case.


Corinna

Re: [PATCH setup] Add new option '--compact-os'

[Corinna Vinschen via Cygwin-apps]

On May 13 16:42, Christian Franke wrote:
> Corinna Vinschen via Cygwin-apps wrote:
> > When running a shell script, certain executables (especially coreutils,
> > gawk, sed, grep, find) are not so very infrequently accessed.  Is this
> > compression really feasible for these binaries?  Did you compare shell
> > script performance with non-compressed, XPRESS16K and LZX compressed
> > /bin dir?
> 
> Good point. Now I did a test with a ./configure script run after reboot:
> There was significant difference with /bin/*.exe (only) uncompressed, NTFS-,
> XPRESS16K- or LZX-compressed. Time was always around 23s.
> 
> Here a read speed test with fast and slow storage and a 10+ years old
> i7-2600K (4C/8T). The 256MiB test file was generated by concatenating
> various EXE files. All file accesses were the first after reboot. AV
> (defender) was turned off:
> 
> 
>  Compression MiB  T1 T2   T3,T4
>  ==
>  None    256   0.69s  10.1s  <0.02s
>  NTFS    159   1.03s   8.1s  <0.02s
>  XPRESS4K    138   -
>  XPRESS8K    128   -
>  XPRESS16K   123   0.64s   5.4s  <0.02s
>  LZX  97   0.79s   4.8s  <0.02s
> 
> T1,T2: Read whole file: time dd if=FILE bs=FILESIZE of=/dev/null
> T3,T4: Read last byte: time dd if=FILE bs=1 skip=FILESIZE-1 of=/dev/null
> 
> T1,T3: SATA SSD, raw read speed with dd bs=1M: ~520MB/s
> T2,T4: USB3 flash drive via USB2, raw read speed: ~27MB/s
> 
> 
> As expected, compression helps to improve 'virtual' read speed on slow
> storage. Otherwise, it depends on storage speed, CPU speed, system load, ...
> As unexpected (for me), even LZX seems to be suitable for random reads which
> are done when EXE files are preloaded or paged-in.
> 
> If the files were already cached, all read times were similar: ~0.135s for
> the whole file.
> 
> For more flexibility, I will provide a new version of the patch with
> '--compact-os ALGORITHM' option.

Great, thanks!


Corinna

Re: [PATCH setup] Add new option '--compact-os'

[Corinna Vinschen via Cygwin-apps]

On May 12 16:14, Jon Turney wrote:
> On 08/05/2021 21:03, Christian Franke wrote:
> [...]
> > +bool io_stream_cygfile::compact_os_is_available = (OSMajorVersion () >= 
> > 10);
> 
> The documentation seems a bit vague, but are we really expecting this to
> work on Windows 10 1507?

I think this could even work under 8.1 from what I can see on MSDN.

> > +{
> > +  const char * const p = name.c_str();
> > +  if (!(!strncmp (p, "/bin/", 5) || !strncmp (p, "/sbin/", 6) || !strncmp 
> > (p, "/usr/", 5)))
> > +return true; /* File is not in R/O tree. */
> > +  const size_t len = name.size(); /* >= 5 */
> > +  if (!strcmp (p + (len - 4), ".dll") || !strcmp (p + (len - 3), ".so"))
> > +return true; /* Rebase will open file for writing which uncompresses 
> > the file. */
> > +  if (!strcmp (p + (len - 3), ".gz") || !strcmp (p + (len - 3), ".xz"))
> > +return true; /* File is already compressed. */
> 
> Is this an assertion that there are no .bz2, .lzma, .zst etc. files in the
> install?

Another question is this: FILE_PROVIDER_COMPRESSION_LZX
"This algorithm is designed to be highly compact, and provides for small
 footprint for infrequently accessed data."

When running a shell script, certain executables (especially coreutils,
gawk, sed, grep, find) are not so very infrequently accessed.  Is this
compression really feasible for these binaries?  Did you compare shell
script performance with non-compressed, XPRESS16K and LZX compressed
/bin dir?

You know how Cygwin is already slow...


Thanks,
Corinna

Re: man-pages-posix 2017 released

[Corinna Vinschen via Cygwin-apps]

On Mar  9 10:35, Brian Inglis wrote:
> On 2021-03-09 08:36, Corinna Vinschen via Cygwin-apps wrote:
> > On Mar  9 07:41, Brian Inglis wrote:> Michael Kerrisk released the 2017
> update in November, so would you care to > release the update, or
> delegate/share?> Tweaks required to cygport appended.
> > Please feel free to take over maintainership.  I'll change the
> > cygwin-pkg-maint file accordingly, so you can upload, ok?
> 
> I assume you meant to reply to my man-pages-posix update FYI,

Ah, didn't notice the difference, sorry.

> so I am happy to do so as suggested.

I pushed the change, so you're man-pages-posix maintainer now.


Thanks,
Corinna

Re: ITP man-pages-linux

[Corinna Vinschen via Cygwin-apps]

Hi Brian,

On Mar  9 07:44, Brian Inglis wrote:
> Hi folks,
> 
> Michael Kerrisk released Linux man-pages 5.10 update in December.
> Any interest in a man-pages-linux ITP?
> I'll be doing it for my own use anyway, just to save flipping to Linux if
> I'm working in Cygwin or Windows.

Please feel free to take over maintainership.  I'll change the
cygwin-pkg-maint file accordingly, so you can upload, ok?


Thanks,
Corinna