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: [Bug] setup regression #2

[Corinna Vinschen]

On Nov 21 13:39, ASSI wrote:
> Corinna Vinschen writes:
> > The idea is that the installation tree has POSIXy permissions and
> > administrative users have the right to change stuff.  The administrators
> > group is part of the user's token if the process has been started
> > elevated, so, to me, this looks like a natural choice.
> 
> As I said, I haven't thought through the implications of doing that.  We
> certainly haven't done a security audit or anything like that
> w.r.t. group ownership of the Cygwin tree and permission of the
> installed files.
> 
> > The other advantage is that the administrators group has a fixed SID on
> > all systems, while other groups depend on the environment.  That goes
> > for the local group "None" just as well as for the "Domain Users"
> > group, etc.
> 
> Yeah, a local non-domain installation currently installs as "None"
> ("Kein" in german Windows) and domain ones will have "Domain Users"

...both groups using the same RID is no accident @ MSFT :)


Corinna

Re: RE: Cygwin x86 end-of-life

[Corinna Vinschen]

On Nov 18 12:30, Brian Inglis wrote:
> On Fri, 18 Nov 2022 15:51:34 +, Jon Turney wrote:
> > On 14/11/2022 21:29, Jason Pyeron wrote:
> > > Can I throw resources at a solution? If so what?
> 
> > Sure, if that's what you want to do.
> > According surveys, 32-bit Windows has a fraction of 1% market share, and
> > declining. Our own (limited) metrics are in accord with that, so I
> > basically see any time I spend on this as wasted.
> > So, the first resource you'll need provide is manpower.
> 
> The decision makes sense with those numbers.
> Do we have numbers to say what the situation is with Windows mingw64-i686 
> crosses?
> Should we also be dropping those at the same time, if there is only 1% use
> of that platform?
> In which case, we should announce that, and add that to the EoL notices.

A cygwin -> i686-w64-mingw32 cross is an entirely different beast.
It's kind of like a cygwin -> sparc-sun-sunos4 cross, or a cygwin ->
riscv-*-* cross.  Either of them is a perfectly valid toolchain, hosted
on Cygwin, targeting some foreign CPU/machine combination.

As long as the cross toolchain has a maintainer, it's ok, isn't it?


Corinna

Re: [Bug] setup regression #2

[Corinna Vinschen]

On Nov 20 20:05, Achim Gratz wrote:
> Jon Turney writes:
> > I believe that the intent of the code in setup is that there should
> > only be two modes:
> >
> > USER: install "for me", with the users primary group
> 
> As I understand it, the intention here was that the user can have a
> "single user installation" in a place that they have access to (say,
> their home directory) while they have no permission in one of the usual
> places.  In a setup where that place is a certain type of share the user
> will not be able to change the group the files are owned by anyway
> (standard NetApp CIFS shares are set up this way) and it may not be the
> users primary group.
> 
> > SYSTEM: install "for everyone", with the administrators primary group
> > (only permitted if you are an administrator)
> 
> I don't see why the fact the installation is meant to be used by
> multiple users means that the install must be owned by group
> Administrators.  I'm not sure this is a good idea on Windows anyway, at
> least when you don't put extra (inheritable) DACL on the install
> folder.

The idea is that the installation tree has POSIXy permissions and
administrative users have the right to change stuff.  The administrators
group is part of the user's token if the process has been started
elevated, so, to me, this looks like a natural choice.

The other advantage is that the administrators group has a fixed SID on
all systems, while other groups depend on the environment.  That goes
for the local group "None" just as well as for the "Domain Users"
group, etc.

I'm not adamant about this, it was just what was looking like being the
right thing to do at the time.  Especially I was not hot to make the
permission set more complicated than necessary for a POSIX-like system.


Corinna

Re: Cygwin x86 end-of-life

[Corinna Vinschen]

On Nov 13 17:07, Jon Turney wrote:
> On 12/11/2022 16:58, Thomas Wolff wrote:
> > Am 12.11.2022 um 17:08 schrieb Jon Turney:
> > > On 11/11/2022 20:02, Thomas Wolff wrote:
> > > > Am 11.11.2022 um 20:50 schrieb Achim Gratz:
> > > > > Thomas Wolff writes:
> > > > > > > I plan to pause package uploads this coming Monday (2022-11-14),
> > > > > > > before starting the re-organization of the package repository to
> > > > > > > make this archive.
> > > > > > Although expected for a while, the exact date is now a very 
> > > > > > short-time
> > > > > > announcement. Can we have a moratorium for a short while?
> > > 
> > > So, if not now, when?
> > Well, first, I think it's not a good idea to change and over-interpret a
> > plan in this way. The announcement for a year or so has been "cygwin 3.4
> > will not support 32 bit anymore". This does not imply that the
> > repository will be closed so any other package would not be allowed
> > anymore to provide updates. What about security updates? Basic
> > functionality?
> 
> Security is a complete red-herring here. We are not good at making timely
> updates for that purpose, generally.  To suggest that x86 will be receiving
> security updates, when we've also said x86 is deprecated, and some
> maintainers aren't updating it at all, makes no sense at all.
> 
> The message needs to be: If you care about security, at the very least,
> don't use x86 Cygwin. This is one of the reasons why I want to archive x86.
> 
> If you think there is some broken "basic functionality" in the current
> package set, please say what it is.  If something critical is discovered
> after the freeze, I am not totally ruling out permitting an exceptional
> upload (although the case for criticality would have to be well made, as,
> again this involves yet more work for me, to benefit a small percentage of
> installations, and one would think that such critical problems would be
> evident currently).

Well said.


Corinna

Re: [ANNOUNCEMENT] Test: grep 3.8 - promotion to current stable

[Corinna Vinschen]

On Nov  4 13:07, Brian Inglis wrote:
> On Thu, 03 Nov 2022 19:31:27 +0100, Achim Gratz wrote:
> > Brian Inglis writes:
> > > Suggest that I could come up with a package grep-nowarn which can only
> > > suppress the [ef]grep warnings, where the package would install
> > > [ef]grep-nowarn, and the postinstall script could rename the
> > > distributed shell scripts to [ef]grep-warn, and install alternatives
> > > with -warn priority 10, -nowarn priority 20; preremove would reverse
> > > the process.
> > > 
> > > Suggestions to accommodate -nowarn from grep package postinstall?
> > > I could supply the same postinstall and preremove as -nowarn to check
> > > for -nowarn and install or uninstall the alternative.
> > > 
> > > Sequence or timing issues to watch out for during postinstall/preremove?
> 
> > As Corinna already said, why GNU suddenly cares so much about strict
> > POSIX conformance in this case is puzzling.  If anything they should
> > have left the decision to packagers and IMNHO the warning should only be
> > presented when POSIXLY_CORRECT is set in the environment, if at all.
> > The patch to the wrapper script(s) in question is trivial and several
> > Linux distributions have removed the warning already (if you do this,
> > also change the interpreter from bash to dash).  Just skip any
> > extra packages and do the same.
> 
> The issue does not appear to be about POSIX compliance, but that [ef]grep
> were dropped from POSIX before 2008 and declared obsolescent, so the
> maintainers appear to be looking to drop those commands/scripts.

This is a usability issue.  If upstream thinks they have to do such a
potentially destructive and backward-incompatible change for no other
reason than "is not in POSIX", they can do so, but there's no good
reason the distros who *care* for usability have to do this either.

> 
> You could perhaps reach out to Eric Blake or Jim Meyering who are in the GNU
> grep contributor lists for rationale.
> 
> While Debian and OpenSuSE have reverted that change, Fedora has not in main
> or rawhide.

Right, Debian and OpenSuSE revert the change and the BSDs will not break
e/fgrep either, obviously.  I doubt Ubuntu will do that.  Fedora often
values progress, for a given value of "progress", higher than usability.
They will probably see lots of Bugzillas and user requests in other
forums due to this change and then ignore them.  But that doesn't mean
we have to do it.

Again: Egrep and fgrep are used in lots of scripts around the world.  A
change like this will have a massive impact for years to come.

So, again, in the name of usability, let's follow Debian and OpenSuSE
here, not Fedora, please.


Corinna

Re: [ANNOUNCEMENT] Test: grep 3.8 - promotion to current stable

[Corinna Vinschen]

On Nov  3 19:31, Achim Gratz wrote:
> Brian Inglis writes:
> > Suggest that I could come up with a package grep-nowarn which can only
> > suppress the [ef]grep warnings, where the package would install
> > [ef]grep-nowarn, and the postinstall script could rename the
> > distributed shell scripts to [ef]grep-warn, and install alternatives
> > with -warn priority 10, -nowarn priority 20; preremove would reverse
> > the process.
> >
> > Suggestions to accommodate -nowarn from grep package postinstall?
> > I could supply the same postinstall and preremove as -nowarn to check
> > for -nowarn and install or uninstall the alternative.
> >
> > Sequence or timing issues to watch out for during postinstall/preremove?
> 
> As Corinna already said, why GNU suddenly cares so much about strict
> POSIX conformance in this case is puzzling.  If anything they should
> have left the decision to packagers and IMNHO the warning should only be
> presented when POSIXLY_CORRECT is set in the environment, if at all.
> The patch to the wrapper script(s) in question is trivial and several
> Linux distributions have removed the warning already (if you do this,
> also change the interpreter from bash to dash).  Just skip any
> extra packages and do the same.

+1


Corinna

Re: [ANNOUNCEMENT] Test: grep 3.8 - promotion to current stable

[Corinna Vinschen]

On Oct 28 08:40, gs-cygwin@gluelogic.com wrote:
> On Fri, Oct 28, 2022 at 12:49:37AM -0600, Brian Inglis wrote:
> > On Thu, 27 Oct 2022 18:25:45 +0200, Corinna Vinschen wrote
> > > On Sep 29 12:55, Brian Inglis wrote:
> > > > >   /usr/share/doc/grep/ChangeLog
> > > > >   https://git.sv.gnu.org/gitweb/?p=grep.git;a=log;h=refs/tags/v3.8
> > > > > > The change note below states that egrep and fgrep are deprecated
> > > > > obsolescent commands, will be dropped in future, and from this release
> > > > > until then, every use will show a stderr warning message, reminding 
> > > > > you
> > > > > how to change your commands and scripts:
> > > > > > $ egrep ...
> > > > >   egrep: warning: egrep is obsolescent; using grep -E
> > > > >   ...
> > > > >   $ fgrep ...
> > > > >   fgrep: warning: fgrep is obsolescent; using grep -F
> > > > >   ...
> > 
> > > Please do everyone a favor and remove those warnings.  egrep and fgrep
> > > are used abundantly in existing scripts and the user often has no choice
> > > or no knowledge how to fix this.  If this is an upstream change, it's a
> > > bad one, breaking backward compatibility.  Please fix this at least for
> > > our distro.
> > 
> > This was released as test at the start of September, reiterated at the end
> > of September on this list, then promoted to current stable and announced
> > early October:
> 
> Planning for the future, could the grep package provide egrep and fgrep
> in /etc/alternatives?  Then a new (optional) package, say "grepfe" could
> provide /etc/alternative shell scripts (or binaries) which called
> grep -F and grep -E.

That would be a feasible workaround.


Corinna

Re: [ANNOUNCEMENT] Test: grep 3.8 - promotion to current stable

[Corinna Vinschen]

On Oct 28 10:13, Corinna Vinschen wrote:
> On Oct 28 00:49, Brian Inglis wrote:
> > On Thu, 27 Oct 2022 18:25:45 +0200, Corinna Vinschen wrote
> > > On Sep 29 12:55, Brian Inglis wrote:
> > > > >   /usr/share/doc/grep/ChangeLog
> > > > >   https://git.sv.gnu.org/gitweb/?p=grep.git;a=log;h=refs/tags/v3.8
> > > > > > The change note below states that egrep and fgrep are deprecated
> > > > > obsolescent commands, will be dropped in future, and from this release
> > > > > until then, every use will show a stderr warning message, reminding 
> > > > > you
> > > > > how to change your commands and scripts:
> > > > > > $ egrep ...
> > > > >   egrep: warning: egrep is obsolescent; using grep -E
> > > > >   ...
> > > > >   $ fgrep ...
> > > > >   fgrep: warning: fgrep is obsolescent; using grep -F
> > > > >   ...
> > 
> > > Please do everyone a favor and remove those warnings.  egrep and fgrep
> > > are used abundantly in existing scripts and the user often has no choice
> > > or no knowledge how to fix this.  If this is an upstream change, it's a
> > > bad one, breaking backward compatibility.  Please fix this at least for
> > > our distro.
> > 
> > This was released as test at the start of September, reiterated at the end
> > of September on this list, then promoted to current stable and announced
> > early October:
> > 
> > https://lists.gnu.org/archive/html/info-gnu/2022-09/msg1.html
> 
> I was AFK from mid-September until mid-October, so I only niticed this
> on my return.
> 
> > I received no feedback to these notices on the announce, cygwin and apps
> > lists from users, maintainers, or developers.
> > 
> > This release is in Fedora Rawhide unpatched and targeted for Fedora 38.
> > 
> > Please note that these warnings are giving notice that egrep and fgrep have
> > been deprecated as obsolescent for 15 years and will be dropped as commands
> > as they have never been in POSIX, GREP_COLOR is obsolescent and treated like
> > GREP_COLORS, unspecified or invalid regular expression warning diagnostics
> > are now being issued on stderr as they will be treated as errors in future
> > releases, "binary file matches" messages on stderr may no longer be
> > suppressed, and invalid bracket expressions are now being treated as errors,
> > with appropriate diagnostics and exit codes.
> 
> I'm aware of that, but upstream is obviously missing the fact that
> egrep and fgrep have been part of the history for so long that they
> are part of the UNIX gene pool.  As I said there are scripts out
> there using egrep and fgrep.  I, for one, can easily tweak the
> scripts, but not every user will be able to do so, missing the
> knowledge or admin privileges.
> 
> There are also the old (and I mean old) users out there who have an
> ingrained habit to use egrep and fgrep since it was *always* part
> of UNIX.  The warnings are really just a PITA.

Oh, and the BSDs will very certainly keep egrep and fgrep forever,
without the dreaded warnings...

I don't even understand why they are so "bad" that they have to be
removed.  What a weird idea.


Corinna

Re: [ANNOUNCEMENT] Test: grep 3.8 - promotion to current stable

[Corinna Vinschen]

On Oct 28 00:49, Brian Inglis wrote:
> On Thu, 27 Oct 2022 18:25:45 +0200, Corinna Vinschen wrote
> > On Sep 29 12:55, Brian Inglis wrote:
> > > > /usr/share/doc/grep/ChangeLog
> > > > https://git.sv.gnu.org/gitweb/?p=grep.git;a=log;h=refs/tags/v3.8
> > > > > The change note below states that egrep and fgrep are deprecated
> > > > obsolescent commands, will be dropped in future, and from this release
> > > > until then, every use will show a stderr warning message, reminding you
> > > > how to change your commands and scripts:
> > > > >   $ egrep ...
> > > > egrep: warning: egrep is obsolescent; using grep -E
> > > > ...
> > > > $ fgrep ...
> > > > fgrep: warning: fgrep is obsolescent; using grep -F
> > > > ...
> 
> > Please do everyone a favor and remove those warnings.  egrep and fgrep
> > are used abundantly in existing scripts and the user often has no choice
> > or no knowledge how to fix this.  If this is an upstream change, it's a
> > bad one, breaking backward compatibility.  Please fix this at least for
> > our distro.
> 
> This was released as test at the start of September, reiterated at the end
> of September on this list, then promoted to current stable and announced
> early October:
> 
> https://lists.gnu.org/archive/html/info-gnu/2022-09/msg1.html

I was AFK from mid-September until mid-October, so I only niticed this
on my return.

> I received no feedback to these notices on the announce, cygwin and apps
> lists from users, maintainers, or developers.
> 
> This release is in Fedora Rawhide unpatched and targeted for Fedora 38.
> 
> Please note that these warnings are giving notice that egrep and fgrep have
> been deprecated as obsolescent for 15 years and will be dropped as commands
> as they have never been in POSIX, GREP_COLOR is obsolescent and treated like
> GREP_COLORS, unspecified or invalid regular expression warning diagnostics
> are now being issued on stderr as they will be treated as errors in future
> releases, "binary file matches" messages on stderr may no longer be
> suppressed, and invalid bracket expressions are now being treated as errors,
> with appropriate diagnostics and exit codes.

I'm aware of that, but upstream is obviously missing the fact that
egrep and fgrep have been part of the history for so long that they
are part of the UNIX gene pool.  As I said there are scripts out
there using egrep and fgrep.  I, for one, can easily tweak the
scripts, but not every user will be able to do so, missing the
knowledge or admin privileges.

There are also the old (and I mean old) users out there who have an
ingrained habit to use egrep and fgrep since it was *always* part
of UNIX.  The warnings are really just a PITA.


Corinna

Re: [ANNOUNCEMENT] Test: grep 3.8 - promotion to current stable

[Corinna Vinschen]

Hi Brian,

On Sep 29 12:55, Brian Inglis wrote:
> Hi folks, [Please Reply All as ISP blocking Cygwin lists]
> [...]
> > /usr/share/doc/grep/ChangeLog
> > https://git.sv.gnu.org/gitweb/?p=grep.git;a=log;h=refs/tags/v3.8
> > 
> > The change note below states that egrep and fgrep are deprecated
> > obsolescent commands, will be dropped in future, and from this release
> > until then, every use will show a stderr warning message, reminding you
> > how to change your commands and scripts:
> > 
> > $ egrep ...
> > egrep: warning: egrep is obsolescent; using grep -E
> > ...
> > $ fgrep ...
> > fgrep: warning: fgrep is obsolescent; using grep -F
> > ...

Please do everyone a favor and remove those warnings.  egrep and fgrep
are used abundantly in existing scripts and the user often has no choice
or no knowledge how to fix this.  If this is an upstream change, it's a
bad one, breaking backward compatibility.  Please fix this at least for
our distro.


Thanks,
Corinna

Re: [ITA] ocaml 4.14.0

[Corinna Vinschen]

On Aug 24 09:28, David Allsopp wrote:
> Corinna Vinschen wrote:
> > On Aug 23 20:00, David Allsopp wrote:
> > > Jon Turney wrote:
> > > > I'm confused here: /usr/lib/ocaml/camlheaderd[di] look like
> > > > executables (according to file etc.)
> > > >
> > > > If they genuinely aren't, then perhaps they shouldn't have execute
> > > > permission (which is I think what is causing them to be caught by
> > > > that piece of code in cygport...)
> > >
> > > ocamlc won't care about the executable bit, but these files are _data_
> > > and so it will care if they end up with a .exe extension, because they
> > > are open'd not exec'd.
> > >
> > > The files themselves form the start of executables produced by ocamlc.
> > > For both Cygwin and native Windows, it's a tiny C program responsible
> > > for locating ocamlrun (on Unix, it's just a shebang line) and the
> > > bytecode itself gets appended.
> > 
> > Why is ocaml for Cygwin not produing shebang files as well?  After all,
> > we're trying to be as Unix-compatible as possible.
> 
> I'm not 100% that this is the correct history, but I think it's down
> to being able to start the programs from outside a Cygwin bash prompt
> - i.e. the programs emitted want to have a .exe by default and it's
> strange to have ".exe" files with a shebang header (at least from
> outside Cygwin).
> 
> This part of OCaml is actually old enough (late nineties) that this
> executable was also used on "real" Unix systems where shebang didn't
> work properly :)
> 
> It is possible to configure Cygwin OCaml to use shebang headers
> (although at the moment only by changing Makefile.config after running
> configure)

That would be nice, actually, together with dropping the .exe suffix,
perhaps.  Dunno about others, but I'd prefer to have ocaml scripts w/o
exe prefix and working OOTB on other Unixoid systems in the first place.


Thanks,
Corinna

Re: [ITA] ocaml 4.14.0

[Corinna Vinschen]

On Aug 23 20:00, David Allsopp wrote:
> Jon Turney wrote:
> > I'm confused here: /usr/lib/ocaml/camlheaderd[di] look like executables
> > (according to file etc.)
> > 
> > If they genuinely aren't, then perhaps they shouldn't have execute
> > permission (which is I think what is causing them to be caught by that
> > piece of code in cygport...)
> 
> ocamlc won't care about the executable bit, but these files are _data_
> and so it will care if they end up with a .exe extension, because they
> are open'd not exec'd.
> 
> The files themselves form the start of executables produced by ocamlc.
> For both Cygwin and native Windows, it's a tiny C program responsible
> for locating ocamlrun (on Unix, it's just a shebang line) and the
> bytecode itself gets appended.

Why is ocaml for Cygwin not produing shebang files as well?  After all,
we're trying to be as Unix-compatible as possible.


Corinna

Re: resolv.conf and gnupg2

[Corinna Vinschen]

On Aug  8 21:13, Yasuhiro Kimura wrote:
> From: Corinna Vinschen 
> Subject: Re: resolv.conf and gnupg2
> Date: Mon, 8 Aug 2022 09:30:47 +0200
> 
> > I can't believe (but may be wrong, of course) that gnupg2 tries to
> > access /etc/resolv.conf by itself.  I would rather guess that gnupg2
> > is linked against one or more libs provided by the bind package,
> > and thus uses the resolver from the bind package.  However, Cygwin
> > provides its own resolver entry points, and those don't need
> > /etc/resolv.conf, because they utilize the OS resolver.
> > 
> > Is there a build option to avoid building against the bind lib?
> > Alternatively it might be possible to inject an autoconf variable
> > from cygport...?
> > 
> > 
> > Corinna
> 
> Unfortunately it seems gnupg2 accesses /etc/resolv.conf in some way.
> 
> (Cygwin64)yasu@rolling[1007]% pwd
> /cygdrive/c/Users/yasu/Work/gnupg
> (Cygwin64)yasu@rolling[1008]% git grep -F resolv.conf
> NEWS:  * dirmngr: Make reading resolv.conf more robust.  [T5657]
> NEWS:  * dirmngr: Now detects a changed /etc/resolv.conf.
> dirmngr/dns-stuff.c:#define RESOLV_CONF_NAME "/etc/resolv.conf"
> dirmngr/dns-stuff.c:  /* Force a reload if resolv.conf has changed.  */
> dirmngr/dns-stuff.c:log_debug ("dns: resolv.conf changed - forcing 
> reload\n");
> dirmngr/dns.c:  if ((error = dns_resconf_loadpath(resconf, 
> "/etc/resolv.conf"))) {
> dirmngr/dns.c:   * /etc/resolv.conf, defaulting to a nameserver of
> dirmngr/dns.c:/** ugly hack to support specifying ports other than 53 in 
> resolv.conf. */
> dirmngr/dns.c:   * is the intersection of the /etc/resolv.conf 
> families and
> dirmngr/dns.c:   * /etc/resolv.conf has "family inet4" and .ai_type
> dirmngr/dns.c:  MAIN.resconf.path[MAIN.resconf.count++] = 
> "/etc/resolv.conf";
> dirmngr/dns.c:  { "show-resconf",   _resconf,  "show 
> resolv.conf data" },
> dirmngr/dns.c:  "  -c PATH   Path to resolv.conf\n"
> (Cygwin64)yasu@rolling[1009]%

IIUC, that should be fixable by configuring gnupg with --disable-libdns.


Corinna

Re: resolv.conf and gnupg2

[Corinna Vinschen]

On Aug  8 09:30, Corinna Vinschen wrote:
> On Aug  7 16:34, Marco Atzeri wrote:
> > Hi,
> > 
> > currently as default Gnupg 2.x is unable to contact keyservers and recover
> > any key. Gnupg 1.x has not such problem
> > 
> > $  /usr/bin/gpg2 --keyserver pgp.mit.edu --recv-keys 5981E818 gpg: keyserver
> > receive failed: No such file or directory
> > 
> > The cryptic message is due to the absence of a /etc/resolv.conf
> > as adding a simple one with a public DNS server overcomes the issue
> > 
> > $ cat /etc/resolv.conf
> > ; /etc/resolv.conf file for dnsmaster
> > ;
> > domain   .com
> > nameserver   0.0.0.0
> > nameserver   8.8.8.8
> > 
> > 
> > $  /usr/bin/gpg2 --keyserver pgp.mit.edu --recv-keys 5981E818
> > gpg: key D17BF2305981E818: 1 duplicate signature removed
> > gpg: key D17BF2305981E818: "Andrew Makhorin " not chan
> > gpg: Total number processed: 1
> > gpg:  unchanged: 1
> > 
> > 
> > I would expect BIND to be a package that creates/manages resolv.conf as
> > it provides a library to parser it, but I do not see any place where this is
> > done.
> > 
> > $ cygcheck -p resolv.conf
> > Found 7 matches for resolv.conf
> > ..
> > libirs161-9.11.9-1 - libirs161: BIND resolv.conf parser library
> > man-pages-linux-5.13-1 - man-pages-linux: Linux manual pages
> > 
> > Any suggestion on how to solve the absence of /etc/resolv.conf ?
> > I doubt  gnupg2 is the proper package to do so.
> 
> I can't believe (but may be wrong, of course) that gnupg2 tries to
> access /etc/resolv.conf by itself.  I would rather guess that gnupg2
> is linked against one or more libs provided by the bind package,
> and thus uses the resolver from the bind package.  However, Cygwin
> provides its own resolver entry points, and those don't need
> /etc/resolv.conf, because they utilize the OS resolver.
> 
> Is there a build option to avoid building against the bind lib?
> Alternatively it might be possible to inject an autoconf variable
> from cygport...?

Having said that, Cygwin provides libresolv.a by itself anyway.
How gets gnupg2 around that?  How does it resolve?


Corinna

Re: resolv.conf and gnupg2

[Corinna Vinschen]

On Aug  8 11:15, ASSI wrote:
> Mark Geisert writes:
> > Could Cygwin itself provide a minimal /etc/resolv.conf pointing to
> > public DNS server(s)?  Some users might object to Google's public DNS
> > (e.g. 8.8.8.8) though.
> 
> No, this would be the job for any software that configures the DNS
> resolver.  However, I'd prefer if no resolver libraries ever looked at
> /etc/resolv.conf as it doesn't really make sense for Cygwin to muck
> about with the DNS configuration independently of what Windows provides.

I agree, actually.

Right now, Cygwin's resolver checks for /etc/resolv.conf, too, but uses
the OS stuff if /etc/resolv.conf isn't available.

So I wonder, just as you do, if we shouldn't drop support for
/etc/resolv.conf and let this be handled by the OS only.

In theory, we have two scenarios:
- Either a user is also admin and can change the OS settings anyway,
- or the user is not admin and the admins very likely don't like the
  user to change the resolver settings on the company machine...


Corinna

Re: resolv.conf and gnupg2

[Corinna Vinschen]

On Aug  7 16:34, Marco Atzeri wrote:
> Hi,
> 
> currently as default Gnupg 2.x is unable to contact keyservers and recover
> any key. Gnupg 1.x has not such problem
> 
> $  /usr/bin/gpg2 --keyserver pgp.mit.edu --recv-keys 5981E818 gpg: keyserver
> receive failed: No such file or directory
> 
> The cryptic message is due to the absence of a /etc/resolv.conf
> as adding a simple one with a public DNS server overcomes the issue
> 
> $ cat /etc/resolv.conf
> ; /etc/resolv.conf file for dnsmaster
> ;
> domain   .com
> nameserver   0.0.0.0
> nameserver   8.8.8.8
> 
> 
> $  /usr/bin/gpg2 --keyserver pgp.mit.edu --recv-keys 5981E818
> gpg: key D17BF2305981E818: 1 duplicate signature removed
> gpg: key D17BF2305981E818: "Andrew Makhorin " not chan
> gpg: Total number processed: 1
> gpg:  unchanged: 1
> 
> 
> I would expect BIND to be a package that creates/manages resolv.conf as
> it provides a library to parser it, but I do not see any place where this is
> done.
> 
> $ cygcheck -p resolv.conf
> Found 7 matches for resolv.conf
> ..
> libirs161-9.11.9-1 - libirs161: BIND resolv.conf parser library
> man-pages-linux-5.13-1 - man-pages-linux: Linux manual pages
> 
> Any suggestion on how to solve the absence of /etc/resolv.conf ?
> I doubt  gnupg2 is the proper package to do so.

I can't believe (but may be wrong, of course) that gnupg2 tries to
access /etc/resolv.conf by itself.  I would rather guess that gnupg2
is linked against one or more libs provided by the bind package,
and thus uses the resolver from the bind package.  However, Cygwin
provides its own resolver entry points, and those don't need
/etc/resolv.conf, because they utilize the OS resolver.

Is there a build option to avoid building against the bind lib?
Alternatively it might be possible to inject an autoconf variable
from cygport...?


Corinna

Re: [PATCH rebase] Fix documentation .pdf link

[Corinna Vinschen]

Hi Jon,

On Jul 22 15:46, Jon Bailey wrote:
> * README (Background): Link changed from Coral CDN to Wayback Machine
> 
> ---
>  README | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/README b/README
> index 372de2d..03afdb2 100644
> --- a/README
> +++ b/README
> @@ -77,7 +77,7 @@ problem:
>  memory where the DLL is being mapped. When the same DLL
>  is loaded in another process, its section object is reused
>  and it is mapped at the same virtual addresses.
> -http://taossa.com.nyud.net:8080/archive/bh08sotirovdowd.pdf
> +
> https://web.archive.org/web/20080913064223/http%3A%2F%2Ftaossa.com%2Farchive%2Fbh08sotirovdowd.pdf

Pushed, thanks!


Corinna

Re: [PATCH rebase] Make rebaseall a wrapper around the autorebase postinstall, script

[Corinna Vinschen]

On Jul 21 09:50, Ken Brown wrote:
> On 7/21/2022 5:09 AM, Corinna Vinschen wrote:
> > We're using the "?p=" URLs on the cygin-apps website, too.  Maybe it's
> > just me, but to me it looks better if we change this to the 2nd form
> > where possible.  What do you think?
> 
> I agree that it looks better without the ?p=.  I have no idea why the latter
> is used on the cygwin-apps website.
> 
> > Just a style issue, but the two functions should stay first in the file.
> > Please move this code just right before the trap call.
> > 
> > Other than that, LGTM.
> 
> I've made all the changes you suggested and pushed it.

Great, I pushed a patch to simplify the URLs and added a link from
the Cygwin homepage to the cygwin apps homepage.


Thanks,
Corinna

Re: [PATCH rebase] Make rebaseall a wrapper around the autorebase postinstall, script

[Corinna Vinschen]

Hi Ken,

On Jul 20 16:14, Ken Brown wrote:
> Patch attached.

> From bcbc7f9768854a6e6aaf1a450cdaabc61241ea9d Mon Sep 17 00:00:00 2001
>  Homepage:
>  
> 
>  The primary rebase web site is:
>  
> -http://www.tishler.net/jason/software/rebase/
> +https://cygwin.com/git/?p=cygwin-apps/rebase.git

Shouldn't that be https://sourceware.org/cygwin-apps/ ?

I mean, it's the only real web page apart from git access.

Also

  https://cygwin.com/git/?p=cygwin-apps/rebase.git

vs.

  https://cygwin.com/git/cygwin-apps/rebase.git

Both work but the 2nd URL avoids that ugly ?p=.

We're using the "?p=" URLs on the cygin-apps website, too.  Maybe it's
just me, but to me it looks better if we change this to the 2nd form
where possible.  What do you think?


>  Download:
>  
> 
> -The primary rebase download site is:
> -
> -http://www.tishler.net/jason/software/rebase/
> -
> -Access to the CVS development sources is available:
> +Access to the git development sources is available:
>  
> -cvs -d:pserver:anon...@cygwin.com:/cvs/cygwin-apps co rebase
> +git clone git://cygwin.com/git/cygwin-apps/rebase.git

Better use https here, rather than git.

>  DefaultFileList=
>  DefaultSuffixes='dll|so|oct'
>  
> +# Determine platform
> +Platform=`uname -s`
> +case $Platform in
> + *MINGW*  | *mingw*  ) Platform=mingw  ;;
> + *CYGWIN* | *cygwin* ) Platform=cygwin ;;
> + *MSYS*   | *msys*   ) Platform=msys   ;;
> + * )
> +echo "Unsupported platform: $Platform" 1>&2
> +exit 1
> +;;
> +esac
> +
> +# On Cygwin, just call the _autorebase postinstall script
> +case $Platform in
> +  cygwin)
> +if [ "$#" -gt 0 ]
> +then
> +  echo "usage: ${ProgramName}"
> +  exit 1
> +fi
> +exec /etc/postinstall/0p_000_autorebase.dash
> +;;
> +  *)
> +;;
> +esac
> +
>  # Define functions
>  usage()
>  {

Just a style issue, but the two functions should stay first in the file.
Please move this code just right before the trap call.

Other than that, LGTM.


Thanks,
Corinna

Re: [PATCH rebase] Print list of DLLs which still overlap after rebasing + Fix index ...

[Corinna Vinschen]

On Jul 19 11:07, Christian Franke wrote:
> Corinna Vinschen wrote:
> > ...
> > Pushed.  Do you have a few more changes in the loop?  When you're
> > finished, I'll release a new rebase.
> 
> The attached 0001-*.patch is the last one in the loop - I guessed. But
> during testing this I found the long standing bug fixed in 0002-*.patch.
> 
> That's all for now.

Great, thanks!  I pushed the stuff and upload a new rebase release soon.


Corinna

Re: [PATCH rebase] Fix handling of newly added non-rebaseable DLLs

[Corinna Vinschen]

On Jul 18 17:09, Christian Franke wrote:
> Revised version which also handles the --oblivious case.
> 
> -- 
> Regards,
> Christian
> 

> Reset needs_rebasing flag to avoid that such a DLL is later removed
> from the list due to rebase failure.  Add related verbose messages.

Pushed.  Do you have a few more changes in the loop?  When you're
finished, I'll release a new rebase.


Thanks,
Corinna

Re: [PATCH rebase] Ensure that no rebaseable DLL overlaps a non-rebaseable DLL

[Corinna Vinschen]

On Jul 16 18:01, Christian Franke wrote:
> The current check for overlapping non-rebaseable DLLs uses a possible
> outdated base address. It also could not detect multiple overlaps by one
> non-rebaseable DLL.
> 
> Patch size may be misleading due to indentation change.

Yeah, I diff'ed -b it for a better view :)

LGTM, pushed.


Thanks,
Corinna

Re: [ITCoM] coreutils

[Corinna Vinschen]

On May  2 23:15, Brian Inglis wrote:
> Hi folks,
> 
> Eric Blake no longer seems to have free time available for Cygwin package
> upgrades, so I would like to offer to co-maintain coreutils and provide
> upgrades as they are now five years old.
> 
> I would like to provide an upgrade to the final version 8 release 8.32,
> initially as a TEST release, before working on the latest release 9.1.
> 
> Package sources and archives are available online at:
> 
> https://drive.google.com/drive/folders/1z_giKv3QIUbYvSNOiTtMMr644v-wOG_k
> 
> and builds in playground from:
> 
> https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=shortlog;h=refs/heads/playground
> 
> https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=playground==Brian+Inglis=4119
> 
> https://github.com/cygwin/scallywag/actions/runs/2239985902
> 
> The jobs appear to fail because some checks fail and return non-zero status.
> Comparing checks between ciurrent and proposed releases and across
> x86/_64/CI jobs, there appear to be fewer failures despite more tests.
> 
> All feedback is encouraged and gratefully received.

Thanks for picking up coreutils, which is not only by name a core
package.

I think this is at least worthy of a pink hippo ;)


Corinna

Re: tcsh /etc/default files

[Corinna Vinschen]

On Feb  5 08:02, Achim Gratz wrote:
> 
> I'm not certain if I ever discussed this before, but the recent tcsh
> update reminded me that I think the defaults should be changed a little
> bit.  First off, running the scripts in profile.d should IMHO be done in
> csh.login to ensure it's only done once.  Secondly the (optional)
> cleaning up of the PATH variable already introduced for all POSIX shells
> in base-files years ago should be replicated for tcsh.  Lastly, since
> /usr/bin/ and /bin are the same thing on Cygwin, one of them is
> redundant and placement of /usr/local/bin should be left at the
> discretion of the user since tha directory does not exist by default on
> Cygwin.

Fine with me, but these files are not part of the distro package
only.  They are part of the upstream tcsh package and just copied
into the right place by a cygwin-specific postinstall step, also
part of the upstream Makefile.

I'm going to send the patch upstream, with a very minor tweak it
applies cleanly.


Thanks,
Corinna

Re: Go or Rust Packages?

[Corinna Vinschen]

On Feb  4 00:14, Mark Geisert wrote:
> Brian Inglis wrote:
> > On 2022-02-02 02:44, Corinna Vinschen wrote:
> > > On Feb  1 21:22, Adam Dinwoodie wrote:
> > > > The upstream fzf package moved from Ruby to Go some time ago.  I had
> > > > vague but noble intetions to try to maintain a fork on the basis of the
> > > > last version of the Ruby code, but never managed anything useful.  In
> > > > that context, I expect it's time that I officially throw in the towel,
> > > > and mark fzf as orphaned.
> > > > 
> > > > The existing build still works, and I don't think there's likely to be
> > > > any crass security problems or anything like that.  But there's no
> > > > longer any upstream support, and I clearly don't have the capacity to
> > > > properly maintain it solo.
> > > > 
> > > > I'm not quite sure what the process is here, but I suspect it's just a
> > > > case of someone with the appropriate access making an update to
> > > > https://cygwin.com/cygwin-pkg-maint
> > 
> > Anyone know of anyone trying to build Go or Rust on Cygwin?
> I made some progress with Go on Cygwin a couple years ago, but had to give
> up because it required more time than I could give it.  I got about 1/3 of
> the way through it.  The last straw was its need for syscall?() and Cygwin
> not having those functions (or a need for them).  It was a lot of looking
> for "#ifdef Windows" and usually adding "&& !defined(__CYGWIN__)".  The goal
> still tantalizes though...

You might be better off writing a syscall layer which translates the
expected syscalls into standard POSIX API calls.  Cygwin could even
provide that in the long run.

Ages ago we discussed converting cygwin1.dll to cygwin2.dll and only
export a syscall interface with any arbitrary libc on top (e. g. glibc),
but that would have been a near full re-implementation of Cygwin, so we
buried the idea.  However, providing a syscall layer on top might be a
nice extension.


Corinna

Re: Orphaning fzf

[Corinna Vinschen]

On Feb  1 21:22, Adam Dinwoodie wrote:
> The upstream fzf package moved from Ruby to Go some time ago.  I had
> vague but noble intetions to try to maintain a fork on the basis of the
> last version of the Ruby code, but never managed anything useful.  In
> that context, I expect it's time that I officially throw in the towel,
> and mark fzf as orphaned.
> 
> The existing build still works, and I don't think there's likely to be
> any crass security problems or anything like that.  But there's no
> longer any upstream support, and I clearly don't have the capacity to
> properly maintain it solo.
> 
> I'm not quite sure what the process is here, but I suspect it's just a
> case of someone with the appropriate access making an update to
> https://cygwin.com/cygwin-pkg-maint

Done.


Thanks,
Corinna

Re: [PATCH cygport 1/2] postinst: Never remove an existing .gnu_debuglink

[Corinna Vinschen]

On Feb  1 20:33, Jon Turney wrote:
> On 01/02/2022 19:22, Corinna Vinschen wrote:
> > Hi Jon,
> > 
> > On Feb  1 17:25, Jon Turney wrote:
> > > Be more careful not to remove an existing .gnu_debuglink, even if we
> > > think this package has no useful debug symbols.
> > > 
> > > (Some versions of 'llvm-objdump -l' fail to find line number info even
> > > though it's there.  Don't break a package which manages it's own debug
> > > symbols (e.g. cygwin) when that happens.)
> > > ---
> > >   lib/src_postinst.cygpart | 28 ++--
> > >   1 file changed, 18 insertions(+), 10 deletions(-)
> > > 
> > > diff --git a/lib/src_postinst.cygpart b/lib/src_postinst.cygpart
> > > index d8bb226..e29b2cb 100644
> > > --- a/lib/src_postinst.cygpart
> > > +++ b/lib/src_postinst.cygpart
> > > @@ -1051,23 +1051,31 @@ __prepstrip() {
> > >   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 | wc -l);
> > 
> > Shouldn't lines be computed *after* the new check for .gnu_deb?  After
> > all, it's still pretty time-consuming and if the .gnu_deb check kicks in
> > it's never tested...
> 
> The objdump invocation has the side effect of creating ${T}/.dbgsrc.out,
> which is later used to determine what source files to put into the debuginfo
> package.

Ah, that explains it☝️

Re: [PATCH cygport 1/2] postinst: Never remove an existing .gnu_debuglink

[Corinna Vinschen]

Hi Jon,

On Feb  1 17:25, Jon Turney wrote:
> Be more careful not to remove an existing .gnu_debuglink, even if we
> think this package has no useful debug symbols.
> 
> (Some versions of 'llvm-objdump -l' fail to find line number info even
> though it's there.  Don't break a package which manages it's own debug
> symbols (e.g. cygwin) when that happens.)
> ---
>  lib/src_postinst.cygpart | 28 ++--
>  1 file changed, 18 insertions(+), 10 deletions(-)
> 
> diff --git a/lib/src_postinst.cygpart b/lib/src_postinst.cygpart
> index d8bb226..e29b2cb 100644
> --- a/lib/src_postinst.cygpart
> +++ b/lib/src_postinst.cygpart
> @@ -1051,23 +1051,31 @@ __prepstrip() {
>  
>   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 | wc -l);

Shouldn't lines be computed *after* the new check for .gnu_deb?  After
all, it's still pretty time-consuming and if the .gnu_deb check kicks in
it's never tested...

>  
> - if (( lines == 0 ))
> + # we expect --add-gnu-debuglink to fail if a
> + # .gnu_debuglink section already exists (e.g. binutils,
> + # which uses hardlinks, or cygwin which creates a custom
> + # .dbg file), but leave it alone to make sure we don't
> + # mess it up.
> + if ${objdump} -h "${exe}" | grep -q '\.gnu_deb'
>   then
> - ${objcopy} --strip-all "${exe}";
>   continue;
>   fi
>  
> - # --add-gnu-debuglink will fail if .gnu_debuglink 
> section
> - # already exists, e.g. binutils, which uses hardlinks,
> - # or cygwin which creates a custom .dbg file
> - if ! ${objdump} -h "${exe}" | grep -q '\.gnu_deb'
> + # only create split debuginfo if it's going to contain
> + # some symbols for which this package has the
> + # corresponding source files
> + if (( lines == 0 ))
>   then
> - dodir "${dbg%/*}";
> - ${objcopy} --long-section-names enable 
> --add-gnu-debuglink=/dev/null --only-keep-debug "${exe}" "${D}${dbg}";
> - chmod 0644 "${D}${dbg}";
>   ${objcopy} --strip-all "${exe}";
> - ${objcopy} --long-section-names enable 
> --add-gnu-debuglink="${D}${dbg}" "${exe}" 2>/dev/null;
> + continue;
>   fi
> +
> + dodir "${dbg%/*}";
> + ${objcopy} --long-section-names enable 
> --add-gnu-debuglink=/dev/null --only-keep-debug "${exe}" "${D}${dbg}";
> + chmod 0644 "${D}${dbg}";
> + ${objcopy} --strip-all "${exe}";
> + ${objcopy} --long-section-names enable 
> --add-gnu-debuglink="${D}${dbg}" "${exe}" 2>/dev/null;
> +
>   fi
>   done
>  }
> -- 
> 2.34.1

Re: [PATCH setup] Show a MessageBox warning if running on a deprecated Windows version

[Corinna Vinschen]

On Jan 16 17:55, Hamish McIntyre-Bhatty wrote:
> This reminds me: It's probably useful for me to support 32-bit even after
> Cygwin no longer does for my commercial project(s). Which probably means I
> should release said package soon (I couldn't get the rebase to work on
> 32-bit before, will ask another question soon. Are all the 32-bit packages
> going offline after support ends or will it remain as a kind of graveyard?

This hasn't been decided yet.  I *guess* we keep the 32 bit packages
around for a while.


Corinna

Re: [PATCH setup] Show a MessageBox warning if running on a deprecated Windows version

[Corinna Vinschen]

On Jan 14 10:54, Adam Dinwoodie wrote:
> On Fri, 14 Jan 2022 at 09:05, Corinna Vinschen wrote:
> > On Jan 13 15:13, Jon Turney wrote:
> > > Show a MessageBox warning if we are running on a Windows version which
> > > we have deprecated Cygwin support for:
> > >
> > > - Windows 6.0 (Windows Vista, Windows Server 2008)
> > > - 32-bit Windows
> > >
> > > This warning can be disabled with '--allow-unsupported-windows'.
> > > ---
> > >
> > > Notes:
> > > Not sure if this is needed, or maybe this is just annoying to the ~3% 
> > > of
> > > users who are running effected OSes.  But maybe we want to annoy them
> > > into doing something about it?
> >
> > Question is, how often should setup show this message?  Every time might
> > really be a bit annoying.  Some kind of "I saw it, now leave me alone,
> > at least for a while" kind of function would be great.
> 
> Eh. The installer tries to add icons to my desktop every time I run it
> unless I provide a command-line argument every time. This behaviour
> seems no more or less annoying to me, and I think having users see
> that warning is much more important than adding a desktop icon.

Point.


Corinna

Re: [PATCH setup] Show a MessageBox warning if running on a deprecated Windows version

[Corinna Vinschen]

On Jan 13 15:13, Jon Turney wrote:
> Show a MessageBox warning if we are running on a Windows version which
> we have deprecated Cygwin support for:
> 
> - Windows 6.0 (Windows Vista, Windows Server 2008)
> - 32-bit Windows
> 
> This warning can be disabled with '--allow-unsupported-windows'.
> ---
> 
> Notes:
> Not sure if this is needed, or maybe this is just annoying to the ~3% of
> users who are running effected OSes.  But maybe we want to annoy them
> into doing something about it?

Question is, how often should setup show this message?  Every time might
really be a bit annoying.  Some kind of "I saw it, now leave me alone,
at least for a while" kind of function would be great.

Other than that, for people not visiting the home page or subscribing
to the mailing lists that may turn out to be an important info, so I'm
for it.


Corinna

Re: [ITP] autoconf2.7

[Corinna Vinschen]

On Dec  8 19:46, Achim Gratz wrote:
> Achim Gratz writes:
> > +   case "${WANT_AUTOCONF}" in
> > +   2.5|'')
> > +   WANT_AUTOCONF=2.5
> > +   case $(autoconf --version 2> /dev/null | head -n 1) in
> > autoconf*2.[56]?) ;;
> > *)  error "autoconf2.5 is required to build this 
> > package" ;;
> > +   esac
> > +   ;;
> > +   2.7)
> > +   WANT_AUTOCONF=2.7
> 
> If anybody prefers cygport to default to 2.7, then the "|''" part of the
> above patch needs to be moved to the pattern clause for 2.7.

We should do that, IMHO.


Thanks,
Corinna

[GOLDSTAR] Re: [ITP] autoconf2.7

[Corinna Vinschen]

On Dec  3 14:42, ASSI wrote:
> Corinna Vinschen writes:
> > Since Fedora did basically the same, as Ken pointed out, maybe we're
> > a bit meticulous if we create a new package for 2.7x?
> 
> Well, if we don't, we're SOL if we hit an incompatibility that the Linux
> folks don't need to care about…  that was why I originally suggested to
> wait it out a bit.
> 
> > I don't know how  the experience is in the various environments, but
> > nobody appears to care...
> 
> If I look at the changes, many are for "fringe" platforms, so how far
> out in the fringes is Cygwin?

No idea.  I cringe at the idea of calling Cygwin a fringe platform.
Now, if you call Cygwin a Gringe platform OTOH :)

Nah, in fact, given we already have the autoconf versioning in place,
it probably doesn't hurt to do it right.

Btw., goldstar request for Achim here!


Corinna

Re: [ITP] autoconf2.7

[Corinna Vinschen]

On Dec  3 11:22, ASSI wrote:
> Ken Brown writes:
> > You should probably also adopt and update the autoconf package, which
> > provides the ac-wrapper script.  The latest upstream version is at
> >
> >
> > https://gitweb.gentoo.org/repo/gentoo.git/plain/sys-devel/autoconf-wrapper/files/ac-wrapper-15.sh
> 
> Hmm.  That looks wrong, the Gentoo folks rolled both 2.70 and 2.71 into
> the WANT_AUTOCONF=2.5 category (which likely works for them).  So yay,
> I'll have to patch that.

Since Fedora did basically the same, as Ken pointed out, maybe we're
a bit meticulous if we create a new package for 2.7x?

I don't know how  the experience is in the various environments, but
nobody appears to care...


Corinna

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

Re: Happy TwentyFifth (25th) Birthday Cygwin!

[Corinna Vinschen]

On Oct 18 09:31, Brian Inglis wrote:
> ...and many more until Windows runs on a POSIX compatible kernel!
> 
> Thanks to all the contributors, documentors, testers, and especially users, 
> who
> keep us honest, and without which we would have little encouragement to 
> continue!

Great talk, thanks for taking over this task :)


Corinna

Re: [PATCH] doc: Various fixes to makedocbook for python3.8

[Corinna Vinschen]

On Aug 24 12:31, Marco Atzeri via Cygwin-apps wrote:
> On 24.08.2020 12:02, Corinna Vinschen via Newlib wrote:
> > On Aug 23 16:49, Brian Inglis wrote:
> > > On 2020-08-23 13:41, Jon Turney wrote:
> > > > On 23/08/2020 16:23, Ken Brown wrote:
> > > > > On 8/22/2020 2:45 PM, Jon Turney wrote:
> > > > > > ---
> > > > > >    newlib/doc/makedocbook.py | 8 +---
> > > > > >    1 file changed, 5 insertions(+), 3 deletions(-)
> > > > > > 
> > > > > > diff --git a/newlib/doc/makedocbook.py b/newlib/doc/makedocbook.py
> > > > > > index 92d0f279d..3fab26f1a 100755
> > > > > > --- a/newlib/doc/makedocbook.py
> > > > > > +++ b/newlib/doc/makedocbook.py
> > > > [...]
> > > > > Would it make sense to also change the shebang line so that 
> > > > > makedocbook.py
> > > > > uses python3?  Currently the build of Cygwin on Fedora uses python3, 
> > > > > but the
> > > > > build of Cygwin on Cygwin uses python2.  This is of no great 
> > > > > importance, but a
> > > > > recent IRC discussion shows that it can be confusing.
> > > > 
> > > > Yeah, I guess that would make some sense, given that python2 is now EOL.
> > > > 
> > > > Otoh, making it gratuitously not work with python2 seems a bit harsh.
> > > > 
> > > > On the gripping hand, reading PEP 0394, I see it doesn't actually 
> > > > require that
> > > > 'python' exist at all, so I guess changing the shebang as you suggest 
> > > > is the
> > > > right thing to do.
> > > 
> > > Is it not perhaps time to switch python from EOL python2 to python3, as 
> > > there
> > > are only 183 python2, 125 python27 to 199 python3, 129 python37 packages.
> > 
> > This discussion actually belongs on cygwin-apps, not on newlib ¯\_(ツ)_/¯
> > 
> > 
> > Thanks,
> > Corinna
> > 
> 
> follow up from newlib
> 
> python2 will be dead end of 2020.
> https://python3statement.org/
> 
> 
> most of python2 and python3 packages are obsolete placeholders,
> currently python3 points to python3.6 or python3.8, but I am seriously
> considering to use alternatives to cover also python37 as already
> done for sphinx and to prepare for the next python3.9.
> 
> python38 has already 85 packages and I am working on another dozen,
> if you need some specific package, let me know.
> 
> Following the
> https://www.python.org/dev/peps/pep-0394/
> 
> --
> Distributors may choose to set the behavior of the python command as
> follows:
> 
>   -  python2,
>   -  python3,
>   -  not provide python command,
>   -  allow python to be configurable by an end user
>  or a system administrator.
> 
> --
> 
>  we are currently setting python as python2=python2.7
> 
> Question before I update the three python3.x
> 
> - should I leave python as it is, or change to one of the
>   other settings ?
> 
> Any preference ? For the last option I will use alternatives

It should default to python3.  Fedora performs this via an extra package
python-unversioned-command, containing just a symlink /usr/bin/python ->
./python3 as well as a man page symlink /usr/share/man/man1/python.1.gz
-> ./python3.1.gz.  We could just do the same, no?


Corinna

Re: [ITA] tzcode tzdata

[Corinna Vinschen]

On Jun 20 14:07, Brian Inglis wrote:
> I would like to offer to adopt packages tzdata and tzcode:
> 
>   Time Zone Database and utilities
> 
> The Time Zone Database (often called tz, tzdb, or zoneinfo) contains
> data that represents the history of local time for most locations around
> the world, and supports conversion of UTC time to local time at those
> locations to allow display of those local times. It is updated
> periodically to reflect changes made by political bodies to daylight
> saving (summer time) rules, UTC offsets, and time zone boundaries.
> 
> Unless Corinna or Yaakov would like to retain maintenance of them; I already
> asked Mark Geisert, who made recent updates to base Cygwin tzcode on
> cygwin-patches, and he expressed no interest in the packages.
> 
> I have been a subscriber to the tz and tz-announce MLs for years, originally
> checking for new releases daily, to download and apply to my JVMs with the
> tzupdater; now, with my other packages, weekly, just for interest and to keep 
> my
> archives complete.
> 
> Source and binary packages are available for testing on Gdrive:
> 
> tzcode
> https://drive.google.com/open?id=19gibjLtiy8uSTEo6Qb9wgUwGvhvFYPNk
> 
> tzdata
> https://drive.google.com/open?id=16A9TgDbKaGuFv-pY9zEwveov9kzSj0eQ
> 
> I have added some more HTML and text docs and the version file, and moved 
> zdump
> from /usr/sbin/ to /usr/bin/ to better reflect what other distros do, and 
> allow
> users to more easily check whether rules have been updated.

ACKing adoption.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer

Re: rpmconf-like tool for Cygwin

[Corinna Vinschen]

On Apr  7 21:05, Yaakov Selkowitz wrote:
> I put together an initial draft of a tool meant to fill the role of
> rpmconf on RPM-based systems:
> 
> https://github.com/yselkowitz/cygetcconf
> 
> It definitely needs more work (and maybe a better name) before

rpm -> cygport
rpmconf -> cygportconf?

> inclusion anywhere, but in the spirit of "early and often", it's a
> start.

Great idea!


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature

Re: Putting packages up for adoption

[Corinna Vinschen]

On Apr  1 16:58, Yaakov Selkowitz wrote:
> On Tue, 2020-03-24 at 16:19 -0400, Andrew Schulman wrote:
> > > On Mar 19 23:47, Yaakov Selkowitz wrote:
> > > > Hello Cygwin package maintainers,
> >  
> > > > To that end, in the best interest of the community, please consider my
> > > > packages up for adoption. 
> > 
> > > > Yaakov
> > > 
> > > There's no number of goldstars or plush hippos which would do justice to
> > > what you did for Cygwin, Yaakov.  If there's something like the ULTIMATE
> > > PLUSH HIPPO REPLACING EVRY OTHER PLUSH HIPPO, you should get it.
> > 
> > Well that's what I get for not checking the list for a week.
> > 
> > I'm happy to oblige, and I have sort of a picture in my head of what that
> > might look like, but I'm not skilled at rendering it. If anyone has any
> > recommendations, please send to me directly by email.
> 
> While I appreciate the thought, please don't trouble yourself over
> this.  A nicely polished "gold watch" will do just fine. :-)

Or a Pink plush watch, perhaps?


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature

Re: Quick query about Windows versions

[Corinna Vinschen]

On Apr  1 14:14, Thomas Wolff wrote:
> Am 01.04.2020 um 11:36 schrieb Corinna Vinschen:
> > On Mar 31 18:58, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
> > > On 31/03/2020 17:24, ASSI wrote:
> > > > Hamish McIntyre-Bhatty via Cygwin-apps writes:
> > > > > Just thought I should ask: is there a perferred version of Windows to
> > > > > build packages on, or does it not matter?
> > > > Whatever supported version of Windows you use, I'd say.
> > > > 
> > > > > I currently build on Windows 7, following the tradition of building on
> > > > > the oldest supported platform, but I have no idea if this is needed 
> > > > > with
> > > > > Cygwin.
> > > > No Windows 7 system should still have the ability to connect to the
> > > > internet… so no, I don't think you should even try to build there.
> > > > 
> > > > 
> > > > Regards,
> > > > Achim.
> > > Yep, that's why I asked. I'll upgrade the VM to Windows 10 then, if it
> > > makes no difference to Cygwin.
> > None at all.  Right now we still support all versions since Windows
> > Vista, so any breakage building stuff on these systems is the fault
> > of the Cygwin core.  Other than that, Achim is right, of course :)
> Unless your package would use w32api and explicitly detect the build system
> version to include more or less features depending on it...

You have a point there.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature

Re: Quick query about Windows versions

[Corinna Vinschen]

On Mar 31 18:58, Hamish McIntyre-Bhatty via Cygwin-apps wrote:
> On 31/03/2020 17:24, ASSI wrote:
> > Hamish McIntyre-Bhatty via Cygwin-apps writes:
> >> Just thought I should ask: is there a perferred version of Windows to
> >> build packages on, or does it not matter?
> > Whatever supported version of Windows you use, I'd say.
> >
> >> I currently build on Windows 7, following the tradition of building on
> >> the oldest supported platform, but I have no idea if this is needed with
> >> Cygwin.
> > No Windows 7 system should still have the ability to connect to the
> > internet… so no, I don't think you should even try to build there.
> >
> >
> > Regards,
> > Achim.
> 
> Yep, that's why I asked. I'll upgrade the VM to Windows 10 then, if it
> makes no difference to Cygwin.

None at all.  Right now we still support all versions since Windows
Vista, so any breakage building stuff on these systems is the fault
of the Cygwin core.  Other than that, Achim is right, of course :)


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature

Re: Putting packages up for adoption

[Corinna Vinschen]

On Mar 20 06:04, Marco Atzeri via Cygwin-apps wrote:
> Am 20.03.2020 um 04:47 schrieb Yaakov Selkowitz:
> > Hello Cygwin package maintainers,
> > [...]
> > To that end, in the best interest of the community, please consider my
> > packages up for adoption.  I don't expect that any one person will take
> > all of them; some are obsolete and due for removal anyway, some should
> > be picked up as soon as possible, and others might just end up
> > bitrotting if nobody is interested in them.  However, in whatever there
> > is interest (or need), hopefully what is there now will serve as a
> > strong foundation to on which to continue to build.
> > [...]
> > Yaakov
> > 
> 
> Hi Yaakov,
> thanks of letting us know.
> I guess that most of us clearly understood that work took over
> and as you have clearly a talent to make stuff work together
> I am not surprised that Redhat is using that to full speed.
> 
> So Long, and Thanks for All the Fish
> Marco
> 
> PS for all the others:
> "Houston we have a problem.."

The understatement of the year :}


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer


signature.asc
Description: PGP signature