Re: [ITP] lesspipe 2.13 - less pager input file preprocessor

[Jon Turney via Cygwin-apps]

On 26/06/2024 05:49, Brian Inglis via Cygwin-apps wrote:

On 2024-06-23 14:12, Brian Inglis via Cygwin-apps wrote:

On 2024-06-23 08:01, Jon Turney via Cygwin-apps wrote:

On 15/06/2024 16:11, Brian Inglis via Cygwin-apps wrote:

[...]


Hi folks/Jon,

Inadvertently uploaded test instead of prod build of lesspipe.
Running untest promoted it from test to (only) current stable.
But package source and summary web pages still show the release as in test.
Looks like untest action should force a rebuild of the package source 
and summary web pages.


"should" but "does not" currently...

Re: package upload calm error

[Jon Turney via Cygwin-apps]

On 29/06/2024 10:33, Thomas Wolff via Cygwin-apps wrote:

Hi, I had uploaded mintty 3.7.3 with the following added to setup.hint:
curr: 3.7.3
prev: 3.7.1

This used to be the way to replace and skip the current version but calm
fails on it.


This used to work when all versions shared a single hint file, and new 
versions trampled all over previous versions, but we haven't done that 
for a while (because it was nuts...)



What's the way now?


The easiest way is:

i) Remove the 3.7.2 version by following the instructions at [1], e.g. 
'ssh cyg...@cygwin.com vault mintty-3.7.2-1'


ii) Upload 3.7.3

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

I did this for you.

Re: Sv: Issue regarding SFD_CLOEXEC. error: "''O_CLOEXEC' undeclared here (not in a function); did you mean 'FD_CLOEXEC'?"

[Jon Turney via Cygwin]

On 18/06/2024 23:15, christianon39--- via Cygwin wrote:

This is a test file I ran so that I didnt need to run the build every
time for wlroots. Compiled to exe file with "gcc -o checko test.c".
Needs to have a file just called testfile to work
Uh, is the claim that this file also produces the same error when 
compiled? Because that doesn't happen for me...




--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [ITP] python-license-expression and cygport PoC patch

[Jon Turney via Cygwin-apps]

On 06/06/2024 20:03, Brian Inglis via Cygwin-apps wrote:
I found github/nexB/license-expression Python package to do SPDX licence 
checks developed by the same team doing SPDX-toolkit for SPDX, using the 
same current data, by and working with Fedora folks et al.


Thanks for taking a look at this problem.

Having a package for this seems fine, but: this package is what calm 
uses, and still has the drawbacks I mentioned:


* embeds the SPDX license data, doesn't dynamically fetch it
* can't really handle LicenseRef reasonably



Successful attempt to package Python license-expression (without tests):

 https://cygwin.com/cgi-bin2/jobs.cgi?id=8210

log at:

 https://github.com/cygwin/scallywag/actions/runs/9293093201

cygport attached and at:

https://cygwin.com/cgit/cygwin-packages/playground/commit/?id=3626386b10c967f780547d1703ad23bd50f6331a

The package installs and runs using PoC attached in 
spdx-license-expression.py script hooked into 
/usr/share/cygport/lib/pkg_pkg.cygpart license hint addition patch 
attached.


I'm not super-keen on adding a cygport dependency on python, just to do 
this check.


It would probably be preferable to do this check initially after the 
.cygport is read, rather than only telling you about problems when you 
get around to doing to the package step.


I also ran a test of the Python script and module against all package 
source cygport files declaring licences which I maintain or ever looked 
at, including a git/cygwin-packages/*.cygport download from 2023-02, 
showing the results in the attached log.
I also attempted to trap the exceptions in the script, but that does not 
seem to work in any documented obvious manner, but I do not know enough 
Python to address this fully.


Yeah, the way validate() handles parse errors is bizarre and unhelpful.

What I ended up doing is calling parse() first to catch those errors, so 
something like:


try:
licensing.parse(expression)
errs = licensing.validate(expression).errors
except (ExpressionError, ExpressionParseError) as e:
print(e, file=sys.stderr)
return 2



If someone else who knows python cared to adopt and improve this in a 
more normal manner, and incorporate this more smoothly into cygport, we 
could all appreciate that.
Alternatively, some candid comments and frank feedback might allow me to 
do so! ;^>

Re: [ITP] lesspipe 2.13 - less pager input file preprocessor

[Jon Turney via Cygwin-apps]

On 15/06/2024 16:11, Brian Inglis via Cygwin-apps wrote:

[Forgot attachments]

On 2024-06-14 23:22, Brian Inglis via Cygwin-apps wrote:

I would like to provide a Cygwin package for lesspipe, to automatically
show archive contents or information about many file types, with
enhanced or coloured output, without having to remember which filter
commands are required to do so, as I have been using it for many years.


Thanks, I added this to your packages.


src_compile() {
cd $S
#   cygautoreconf


What value does this comment have?


lndirs
cd $B
#   cygconf


Ditto.


./configure --prefix=/usr
cygmake
}


src_install() {
cd $B
#   install -D "${srcdir}"/lesspipe.sh "${pkgdir}"/etc/profile.d/lesspipe.sh
#   verbose cp lesspipe.sh $C/profile.d.sh
# In bash, please preload the completion, dynamic invocation does not work
# . /usr/share/bash-completion/less_completion
# Or consider installing the file less_completion in /etc/bashcompletion.d [sic]
dodir   /etc/bash_completion.d
insinto /etc/bash_completion.d
doins   less_completion
cyginstall
verbose rm -f $D/usr/share/bash-completion/less_completion


It seems like this might be more clearly sequenced:

* do standard install
* comment about the following steps
* remove completion file from non-working location
* install completion file in working location

or could the completion file just be moved post-install, from ${D} 
/usr/share/bash-completion/ to ${D}/etc/bash_completion.d/ ?



}

Re: [ITA] esound

[Jon Turney via Cygwin-apps]

On 20/06/2024 04:37, Takashi Yano via Cygwin-apps wrote:

esound itself has not been changed, however, pulseaudio package
dropped pluseaudio-esound-compat in 15.0 and later.
Therefore, I would like esd (daemon) to comeback in esound
package.


Thanks. I added this to your packages.

Re: [ITA] ctags 6.1.0 - programming language source indexing and cross-reference tool

[Jon Turney via Cygwin-apps]

On 15/06/2024 16:10, Brian Inglis via Cygwin-apps wrote:

[Forgot attachments]

On 2024-06-14 23:20, Brian Inglis via Cygwin-apps wrote:

I would like to adopt ctags and update it to successor universal-ctags.


Thanks. I added this to your packages.


Description:
Generates an index (tag) file of language objects found in
source files.
The index makes it easy for text editors or other utilities to locate
the indexed items.
Ctags can also generate a cross reference file which lists information
about the various objects found in a set of language files in human
readable form.
Exuberant Ctags improves on ctags because it can find all types of


This should say "universal-ctags", right?


language tags, including macro definitions, enumerated values (values
inside enum{...}), function and method definitions, enum/struct/union
tags, external function prototypes, typedef names and variable
declarations.
Exuberant Ctags is far less likely to be fooled by code containing
preprocessor conditional constructs than ctags.
Exuberant ctags supports output of Emacs style TAGS files and can be
used to print out a list of selected objects found in source files.
Install ctags if you are going to use your system for C programming.

Re: Up for adoption: ctags and expat

[Jon Turney via Cygwin-apps]

On 17/06/2024 07:28, Frank Fesevur wrote:

Hi Jon,

Thanks for contacting me.

I'm sorry to say, but I haven't used Cygwin for years on my own pc,. So I
am not gonna make any packages anymore. It could very well be that my SSH
key has expired. If not, I don't mind if it would be deleted.


No problem.  Thanks for letting me know.

I will orphan your 'ctags' and 'shutdown' packages.

Re: Fwd: Howto request an upgrade for keychain package

[Jon Turney via Cygwin-apps]

On 24/04/2024 16:34, Jon Turney via Cygwin-apps wrote:


Hi Jari,

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


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


TIA.


Hi Jari,

In the absence of any response from you, I did an NMU using the cygport 
provided by another user asking for an update [1].


If that's not what you wanted to happen, or if you want to orphan this 
package, please let me know.


[1] https://cygwin.com/pipermail/cygwin/2024-May/255982.html

Re: Please update keychain to 2.8.5 (Updated .cygport file attached)

[Jon Turney via Cygwin]

On 05/06/2024 09:59, Ken Takata via Cygwin wrote:

Hi,

2024年5月23日(木) 21:05 Ken Takata :

Hi all,

Cygwin's keychain package is very old and doesn't work at all with the latest 
openssh.
I've updated keychain.cygport for the latest version of keychain.
Please find the attached file.
Could you include this in the cygwin package repository and release a new 
version?


How can we proceed to update keychain to 2.8.5?

There were several requests for updating it.
E.g.:
https://cygwin.com/pipermail/cygwin/2015-April/220951.html
https://cygwin.com/pipermail/cygwin/2017-November/235124.html
https://cygwin.com/pipermail/cygwin/2024-April/255862.html
https://cygwin.com/pipermail/cygwin/2024-April/255916.html


As I wrote in the previous mail, I've already confirmed that the following
"keychain.cygport" file can successfully build an updated package:


I did an NMU of this package using this cygport.

Thanks.


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

keychain 2.8.5-1

[Jon Turney via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* keychain-2.8.5-1

keychain is a manager for ssh-agent, typically run from
~/.bash_profile.  It allows your shells and cron jobs to share a single
ssh-agent process.  By default, the ssh-agent started by keychain is long-
running and will continue to run, even after you have logged out from the
system.



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

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

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

Re: [ITP] dav1d

[Jon Turney via Cygwin-apps]

On 07/06/2024 07:22, Takashi Yano via Cygwin-apps wrote:

dav1d is a decoder for AV1 video codec, which is faster
as twice as libaom.

This package is available also for fedora.
https://src.fedoraproject.org/rpms/dav1d

I'am planning to release ffmpeg where dav1d is enabled
as fedora.

Thanks in advance.


Looks good. I added this to your packages.

Thanks.

Re: New Mirror

[Jon Turney via Cygwin]

On 06/06/2024 15:59, mirrors neterra via Cygwin wrote:


Hello,

We would like to become your mirror.
On our side, everything is configured and you can check the content on the 
following links:

https://mirrors.neterra.net/cygwin/


We support http, https, ftp, rsync

We are located in Europe, Sofia City, Bulgaria.
20GBs global connectivity from most Tier1 providers

We'd love for you to add us to your lists.


I added this to our mirror list.

Thanks for providing a cygwin mirror!


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Up for adoption: ctags and expat

[Jon Turney via Cygwin-apps]

On 12/08/2016 20:41, Corinna Vinschen wrote:

On Aug 12 11:57, Warren Young wrote:

On Aug 12, 2016, at 7:57 AM, Corinna Vinschen 
 wrote:



Cool!  If you want to take over ctags and test universal ctags for
Cygwin, feel free if Warren agrees.  I'll change over maintainership
then.

Warren, does that sound good to you?

Doug, I hope you don't feel overlooked.  Expat is still yours if
Warren has no problems with that.


Sounds like a plan.


I added Frank as ctags maintainer to cygwin-pkg-maint but didn't remove
you for the time being until the move over is complete.


I've been looking for maintainer ssh keys which have been unused for a 
very long time, with a view to disabling them.


One of the keys identified was for Warren Young.

Looking at this piece of history, I guess I should remove Warren as a 
maintainer, and his ssh key.



Frank,

It looks like we never got a universal-ctags package, so I'm not sure 
what the status of exuberant-ctags maintainer-ship is...

Re: newer version of mingw64-*-win-iconv ?

[Jon Turney via Cygwin-apps]

On 04/06/2024 00:14, Brian Inglis via Cygwin-apps wrote:

On 2024-06-03 13:27, Jon Turney via Cygwin-apps wrote:

On 03/06/2024 06:37, Brian Inglis via Cygwin-apps wrote:

On 2024-06-02 08:56, Jon Turney via Cygwin-apps wrote:

On 29/05/2024 07:58, Brian Inglis via Cygwin wrote:

[...]
Could someone please do any further tweaks for this source git if 
required, and do NMU builds and deploys of these?


I've given you NMU privileges, so now that someone can be you!


Thanks Jon,


[...]


No previous debuginfo packages exist - are these not useful with cross 
builds?


I suspect that maybe the previous package is so old we didn't have 
automatic debuginfo generation when it was built...

Re: ftp.acc.umu.se domain move

[Jon Turney via Cygwin]

On 31/05/2024 07:43, Niklas Edmundsson via Cygwin wrote:

On Thu, 30 May 2024, Jon Turney wrote:


On 23/05/2024 15:13, Niklas Edmundsson via Cygwin wrote:





File archive host name:

Official name changes from ftp.acc.umu.se to mirror.accum.se. The old
host name will continue to work for quite some time (years), but new
deployments should move to using a non-acc.umu.se name.  Since we are
lazy sysadmins, we have also registered the ac2.se (ACC=AC^2) domain
and lots of aliases so ftp.ac2.se also works.

If you have references to other acc.umu.se services (for example
www.acc.umu.se), replace the domain part with accum.se (ie
www.accum.se).


I've updated this in our mirror list.


Hmm. Looking at https://cygwin.com/mirrors.html it seems that our old 
host name ftp.acc.umu.se is still listed?


Yeah, unfortunately we currently don't have a good mechanism to migrate 
any existing Cygwin installations which are configured with the old URL.


Once that's been sorted out (or if it stops working first), I'll remove 
the old URL.



--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: newer version of mingw64-*-win-iconv ?

[Jon Turney via Cygwin-apps]

On 03/06/2024 06:37, Brian Inglis via Cygwin-apps wrote:

On 2024-06-02 08:56, Jon Turney via Cygwin-apps wrote:

On 29/05/2024 07:58, Brian Inglis via Cygwin wrote:

[...]
Could someone please do any further tweaks for this source git if 
required, and do NMU builds and deploys of these?


I've given you NMU privileges, so now that someone can be you!


Thanks Jon,

I think and hope! ;^>

I uploaded both arch packages and have not heard anything from calm 
about mingw64-i686-win-iconv but did get a non-maintainer complaint about:


From: cygwin-no-reply-rdbxbdvo6bxqt0dzr+a...@public.gmane.org
To: Brian Inglis ...
Reply-To: cygwin-apps-rdbxbdvo6bxqt0dzr+a...@public.gmane.org
Subject: calm: cygwin package report for Brian Inglis
X-Calm-Report: 1
Message-Id: 
<171738805632.3596610.16241297892116907567-vpjudf68pyp0lzk1ysf9sd64mghar...@public.gmane.org>

Date: Mon, 03 Jun 2024 04:14:16 -
X-Calm: 1
...
WARNING: package 'mingw64-x86_64-win-iconv' is not in the package list 
for maintainer 'Brian Inglis'
WARNING: package 'mingw64-x86_64-win-iconv' is not in the package list 
for maintainer 'Brian Inglis'

SUMMARY: 2 WARNING(s)

and there is not yet any sign of either being applied to the master 
setup.ini at cygwin.com, which is my other confirmation that an 
announcement would be appropriate, without waiting for mirror updates.


So is there anything more I have to or can do for these?
Do I have to add some kind of NMU flag for the packages somehow?


No, that's just me being distracted and forgetting to restart the thing 
so it re-reads the list.


Sorry about that.  Hopefully working now.

Re: Plans to update meson version?

[Jon Turney via Cygwin]

On 01/06/2024 16:24, Dave Trombley via Cygwin wrote:

Meson appears to be two majore versions behind in cygwin (1.2.3 is latest
available, 1.4.0 was released mid-March this year).

Major projects are starting to not be compilable on Cygwin, consequently,
short of manually building a custom meson that is up to date (for example,
libcairo requires 1.3).

Are there plans to update this at some point?


The "plan" is "when I get around to it"

Thanks for the reminder, though. It seems I overlooked meson 1.3.x, so 
I've updated the package today.


(I don't usually package 1.n.x until 1.n+1.0 is available, because 
historically .0 releases of meson have had a high chance of containing 
regressions, although things are better these days...)



--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

meson 1.3.2-1

[Jon Turney via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

* meson-1.3.2-1

Meson is an open source build system meant to be extremely fast.  It generates
files for various backends including Ninja, Visual Studio, and Xcode. Meson does
not generate Makefiles, relying solely on Ninja for Linux and Unix support.



This is an update to a more recent upstream release:

https://mesonbuild.com/Release-notes-for-1-3-0.html


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

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

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

Re: newer version of mingw64-*-win-iconv ?

[Jon Turney via Cygwin]

On 29/05/2024 07:58, Brian Inglis via Cygwin wrote:

On 2024-05-28 19:12, Bruno Haible via Cygwin wrote:

It would be useful if someone could rebuild the two packages
   https://cygwin.com/packages/summary/mingw64-i686-win-iconv.html
   https://cygwin.com/packages/summary/mingw64-x86_64-win-iconv.html
based off the current git HEAD [1].
Reason: The current git HEAD is a reasonable alternative to
GNU libiconv; all encodings that it supports, other than EUC-JP
and GB18030, have reasonably good conversion tables. Wherease the
current Cygwin packages are based off source code from 2013
and have a major problem already with the ASCII encoding.
[1] https://github.com/win-iconv/win-iconv


Ran playground local and CI builds of these packages at v0.0.8 
successfully:


 https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-win-iconv

 https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-win-iconv

Do we really need the fix at git HEAD to add UCS-2-INTERNAL encoding?

Could someone please do any further tweaks for this source git if 
required, and do NMU builds and deploys of these?


I've given you NMU privileges, so now that someone can be you!


[Are we really still building 32 bit mingw packages when we dropped 
support of 32 bit Windows << 1%?


There's a difference between "we don't support running on 32-bit 
Windows" and "We don't support cross-compiling to 32-bit Windows".


Now, I'd like to do this in an evidence based manner e.g. if we had some 
statistics on packages that cygwin users choose to install, and hardly 
anyone was bothering with mingw 32-bit packages, then dropping them 
would be a good way of conserving our very limited maintainer resource.


But as previously observed, that depends on building something to 
collect that data, which SHTDI.


(There's also some unfinished work by Yaakov in a branch of the cygport 
repo which enhances cross-compile support, so that a single source 
package can produce mingw-cross install packages for multiple 
architectures, which would make it easier to continue to support these 
packages, and/or drop them in future, and/or add mingw arm64 
cross-packages when the toolchain for them exists...)



--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: newer version of mingw64-*-win-iconv ?

[Jon Turney via Cygwin-apps]

On 29/05/2024 07:58, Brian Inglis via Cygwin wrote:

On 2024-05-28 19:12, Bruno Haible via Cygwin wrote:

It would be useful if someone could rebuild the two packages
   https://cygwin.com/packages/summary/mingw64-i686-win-iconv.html
   https://cygwin.com/packages/summary/mingw64-x86_64-win-iconv.html
based off the current git HEAD [1].
Reason: The current git HEAD is a reasonable alternative to
GNU libiconv; all encodings that it supports, other than EUC-JP
and GB18030, have reasonably good conversion tables. Wherease the
current Cygwin packages are based off source code from 2013
and have a major problem already with the ASCII encoding.
[1] https://github.com/win-iconv/win-iconv


Ran playground local and CI builds of these packages at v0.0.8 
successfully:


 https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-win-iconv

 https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=mingw64-x86_64-win-iconv

Do we really need the fix at git HEAD to add UCS-2-INTERNAL encoding?

Could someone please do any further tweaks for this source git if 
required, and do NMU builds and deploys of these?


I've given you NMU privileges, so now that someone can be you!


[Are we really still building 32 bit mingw packages when we dropped 
support of 32 bit Windows << 1%?


There's a difference between "we don't support running on 32-bit 
Windows" and "We don't support cross-compiling to 32-bit Windows".


Now, I'd like to do this in an evidence based manner e.g. if we had some 
statistics on packages that cygwin users choose to install, and hardly 
anyone was bothering with mingw 32-bit packages, then dropping them 
would be a good way of conserving our very limited maintainer resource.


But as previously observed, that depends on building something to 
collect that data, which SHTDI.


(There's also some unfinished work by Yaakov in a branch of the cygport 
repo which enhances cross-compile support, so that a single source 
package can produce mingw-cross install packages for multiple 
architectures, which would make it easier to continue to support these 
packages, and/or drop them in future, and/or add mingw arm64 
cross-packages when the toolchain for them exists...)

Re: libtool can't build shared library unless -no-undefined specified

[Jon Turney via Cygwin-apps]

On 21/05/2024 17:22, Brian Inglis via Cygwin-apps wrote:
[...]
Note that because this flag doesn't do anything for non-PE targets, 
it's (a) always safe to upstream, and (b) doesn't actually prevent 
development from unwittingly introducing unresolved symbols.


In that case, could we ask Bruno to add into gnulib somewhere appropriate?


This doesn't seem like a solution.

There's lots of stuff which uses libtool which doesn't use gnulib.

There might be stuff which uses gnulib, but which does platform-specific 
gymnastics (i.e. has unresolved symbols on ELF platforms, but not on PE, 
or really, genuinely only wants a static library on PE).


All of which is to say, there is no "one size fits all" solution, 
individual projects need to decide how to handle this point, otherwise 
we'd (hopefully) be using it...


(which is not to say that the default could probably have been chosen to 
be less hassle)


This should probably be mentioned in the FAQ item on PE linkage 
peculiarities.


In libtool info?


I meant in https://cygwin.com/faq.html#faq.programming.linker, which 
touches on the issue, but doesn't go into libtool specifics currently.


(But looking at this again, the question would need adding to, also)

Re: TeX Live 2024:: asympote 2.88-1 hangs after outputting a pdf

[Jon Turney via Cygwin]

On 27/05/2024 16:14, Ken Brown via Cygwin wrote:

On 5/27/2024 5:17 AM, Lemures Lemniscati via Cygwin wrote:

On Sun, 26 May 2024 18:02:54 -0400, Ken Brown via Cygwin
Here is a log from gdb. Will it help?
  run
  info threads
  info stack
  list


$ HOME=/tmp gdb --args asy -vv -f pdf test

[...]

Thread 5 "sig" received signal SIGTRAP, Trace/breakpoint trap.


I don't get this SIGRAP when I run the same command.  The program just 
runs to completion.  Maybe someone can explain what might cause this.  I 
have no idea.


Getting SIGTRAP rather than SIGSEGV or whatever here seems like it might 
be an unintended consequence of the dumper changes I made in 3.5.0.



0  0x7ffd8487d313 in KERNELBASE!DebugBreak () from 
/cygdrive/c/WINDOWS/System32/KERNELBASE.dll
#1  0x7ffd527f6367 in break_here () at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/dcrt0.cc:472
#2  0x7ffd52810349 in try_to_debug () at 
/usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/exceptions.cc:597
#3  exception::handle (e=0x28bc6f0, frame=, in=0x28bc200, 
dispatch=)
at /usr/src/debug/cygwin-3.5.3-1/winsup/cygwin/exceptions.cc:810
#4  0x7ffd871b49ff in ntdll!.chkstk () from 
/cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#5  0x7ffd8712e466 in ntdll!RtlFindCharInUnicodeString () from 
/cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#6  0x7ffd871b39ee in ntdll!KiUserExceptionDispatcher () from 
/cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll
#7  0x7ffd5291bdd4 in init_cygheap::find_tls (this=0x8, sig=20, 
issig_wait=@0x28bca3f: false)


The important thing in this backtrace is that an exception is occurring 
in find_tls, not that we break into the debugging while handling it 
(rather than rethrowing the exception to let the debugger handle it, 
which is maybe what should happen? and did in previous versions of Cygwin??)



--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: ftp.acc.umu.se domain move

[Jon Turney via Cygwin]

On 23/05/2024 15:13, Niklas Edmundsson via Cygwin wrote:


Hi!

The contact information, and preferably the host/mirror name, for the
mirror provided by Academic Computer Club (ACC) needs to be changed as
ACC is moving to a new domain. To verify the validity of this
message, point a web browser towards https://ftp.acc.umu.se/ and
notice that the top-level redirects to https://mirror.accum.se/. Also
notice the text about acc.umu.se at the top of the page.

Background: Umeå University has decided that non-official services are
no longer allowed to exist as a sub domain to umu.se. As a consequence
of this we are moving all services from the acc.umu.se domain.

Contact email:

Changes from ftp-...@acc.umu.se to ftp-...@accum.se. The old email
address will stop working sometime in the future.

File archive host name:

Official name changes from ftp.acc.umu.se to mirror.accum.se. The old
host name will continue to work for quite some time (years), but new
deployments should move to using a non-acc.umu.se name.  Since we are
lazy sysadmins, we have also registered the ac2.se (ACC=AC^2) domain
and lots of aliases so ftp.ac2.se also works.

If you have references to other acc.umu.se services (for example
www.acc.umu.se), replace the domain part with accum.se (ie
www.accum.se).


I've updated this in our mirror list.

Thanks for providing a cygwin mirror.


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Use Cygwin gcc or clang to build with ucrt?

[Jon Turney via Cygwin]

On 22/05/2024 00:30, Dan Shelton via Cygwin wrote:

Hello!

Can Cygwin gcc or clang be used to use ucrt instead of cygwin.dll/mingw.dll?


We provide a cross-compiler targeting the Win32 API, but this only 
support  msvcrt currently.


[1] https://cygwin.com/faq.html#faq.programming.win32-no-cygwin


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: LD_PRELOAD for Win32?

[Jon Turney via Cygwin]

On 25/05/2024 22:55, Martin Wege via Cygwin wrote:

Hello,

Does Cygwin or Win32 have something like LD_PRELOAD, so I can
override/substitute functions in a DLL or EXE, like it is common for
UNIX/Linux ELF shared libraries?


This is not generally available on Win32, due to limitations of the PE 
file format.


(basically, the import table lists symbols which are imported, and where 
they are imported from, so the module (shared library or executable) 
which provides a given symbol is determined when the module is *linked*, 
not when it is loaded.



However, when googling "cygwin LD_PRELOAD" (which surely you must have 
done before asking this question?) I discover that there's some voodoo 
in the cygwin DLL (hookapi.cc) which claims to do something like that, 
but it seems (i) this requires the preloaded DLL to explicitly hook 
functions it's overriding, and (ii) maybe only works on functions 
imported by the running executable.


It would be nice to have some documentation for that, and/or a simple 
example which could serve as a testcase.


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [PATCH cygport] bin/cygport.in: Allow `-fdebug-prefix-map` to be selected instead of `-ffile-prefix-map`

[Jon Turney via Cygwin-apps]

On 25/05/2024 08:25, Daisuke Fujimura via Cygwin-apps wrote:

Having seen this commit (
https://cygwin.com/git/?p=cygwin-apps/cygport.git;a=commit;h=9e82685e32f6717675e9f6bf55dd1336e3fc3831
),
I understand that this is problematic from a reproducibility point of
view, but I would like to be able to specify a `-fdebug-prefix-map`
because C sources with code like `#include __FILE__` cannot be
compiled.

https://github.com/cygwin/scallywag/actions/runs/9002845391/job/24732313857#step:6:1302

```
/cygdrive/d/a/scallywag/ruby/ruby-3.3.1-1.x86_64/src/ruby-3.3.1/debug_counter.h:359:10:
fatal error: /usr/src/debug/ruby-3.3.1-1/debug_counter.h: No such file
or directory
359 | #include __FILE__
| ^~~~
compilation terminated.
```

The patch is as follows.


Thanks very much for the patch.

Yeah, I tripped over this when I was testing your previous patch.

This seems like a generic problem which everyone is going to have with 
ruby, though.  And from a brief look at the debug_counter.h header, it 
does seem like a case of excessive cleverness - on first glance, it 
looks like this could just be written using a separate header, rather 
than recursively including itself with some define set...


(and I guess it's actually a gcc bug, or at least misfeature, that you 
can make '#include __FILE__' do something other than it's plain meaning)


Nevertheless, I guess this is needed.


Shell variable names in the patch should be changed to appropriate ones.


Yeah, not sure what a good name for this is. Something like 
'DEBUGINFO_ONLY_DEBUG_PREFIX_MAP', maybe?


It needs to be mentioned in the documentation somewhere, as well.

Re: calm: SPDX licence list data update please

[Jon Turney via Cygwin-apps]

On 24/05/2024 17:08, Brian Inglis via Cygwin-apps wrote:

Hi folks,

Can we please get the SPDX licence list data updated in calm to 3.24 
sometime if possible as the licences complained about below have been in 


I thought I wrote about this the last time you asked, but obviously not.

This is not quite straightforward, as the system python on sourceware is 
currently python3.6, and the last supported nexB/license-expression on 
that is 30.0.0, and moving to a later one has some wrinkles, since 
various pieces of interconnected stuff aren't venv'd (yet?).



releases for nearly a year since 3.21:


[...]


If not, perhaps I could be of some help if I knew requirements?


So, there aren't any requirements here except "validate the SPDX license 
expression to detect maintainer mistakes and typos".


It looks like using that python module might have been a mistake.

I'm not sure why it needs to contain it's own version of the license 
data, ideally we'd have something that read the official SPDX data 
(ratelimited to once per day or something. It looks like maybe this 
would possible to do by feeding our own license list into the module 
rather than using it's built in one, but one could hope for this to be 
built in already...)


It would also be useful if it could also be taught to accept 
'LicenseRef-.*' identifiers.


So, suggestions on a different module to use, or patches to make this 
work better, or cogent arguments why we should just remove this 
validation are all welcome.



You can also now remove the exceptions in calm/fixes.py(licmap):


Thanks, will do so.

Re: Package import request from CTM

[Jon Turney via Cygwin-apps]

On 27/05/2024 20:39, Michal Feix via Cygwin-apps wrote:
Dear all, as suggested on https://cygwin.com/packaging/repos.html let me 
kindly ask for an import of a 'nasm' package history from CTM into GIT 
repository.


Sure, no problem.

History is now imported at: https://cygwin.com/cgit/cygwin-packages/nasm/

I've given it a brief look over and it seems reasonable, but please 
check that it's OK before you start using it.

Re: SSH key update

[Jon Turney via Cygwin-apps]

On 27/05/2024 20:20, Michal Feix via Cygwin-apps wrote:

 BEGIN SSH2 PUBLIC KEY 
Comment: "3072-bit RSA, converted by feixm@michal-pc from OpenSSH"
B3NzaC1yc2EDAQABAAABgQDjQ9jbOytPr/sPDwIbjtFeJqBuDymxzuicJ8NpIN
Osoxkagb0WOLPsSjTgDbftDTCw1QOvCrVP09KvLY76MK8zNIt/97N7w/OmB0iWv9v1LEuT
sFAqDlC4jRVMC4pabidTqDZy0nVC54POIwYd4N65k7fxwGGU77OaZeKpKRRYeTekVSSOoc
jmesIhl+StI8kkPPIZMNpNfsm7DisPoqwZdxxrpCir8xmOMOwU9Wt7CYS+hDqDXSky067O
jn0JVty4utXNv/JzVABmiiEpjnFQSwja0vgrbigOrrycJJuGwv4RiYTK63BHfoKgeX1Wqc
pxNsvCw7RYumGGXjhSGBicDTM9X81hxEJpzzKNkWsAbjed1HRZ8DgQmTzQPT/mUUB+hD/r
7NYoxzEDvDV0hYpuk89j+7XnqaAltEIkXy0sYGsWpp8AJGDkSlHJDGxzlQAqmgDXyijJpS
xgEUxl4nkj8ArBJaFW2mGZxdCDUqMJbYRh1mAfExc+EK2CrkgmlFk=
 END SSH2 PUBLIC KEY 



Name: Michal Feix
Updating ssh key for Michal Feix
Fingerprint: 3072 SHA256:Ie/gfi0gbgbawKADzR/9W2sroK40405A5UGhogoLB5o no comment 
(RSA)

Done. Thanks.

Re: Team Cymru mirror link update

[Jon Turney via Cygwin]

On 22/05/2024 16:38, Tom Ludwig via Cygwin wrote:

Greetings!

My name is Tom and I'm a Systems administrator at Team Cymru. Please 
update our mirror link from http to https://mirror.team-cymru.com/cygwin/


I have updated this in our mirror list.

Thanks for providing a cygwin mirror!


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: [ITA] bash-completion/-devel

[Jon Turney via Cygwin-apps]

On 03/05/2024 14:40, Jon Turney via Cygwin-apps wrote:

On 29/04/2024 22:13, Brian Inglis via Cygwin-apps wrote:
I would like to co-maintain or adopt and revive the above package, 
which was adopted by Eric but not updated since Yaakov.


Thanks.

I added this to your packages.

I guess I need to ask eblake if he wants to orphan his packages, since 
he seems to be no longer active...

Excluding co-maintained packages, the list is:


$ grep 'Eric Blake' cygwin-pkg-maint | grep -v '/'
bashdb   Eric Blake
cppi Eric Blake
cvspsORPHANED (Eric Blake)
cvsutils Eric Blake
gperfEric Blake
libsigsegv   Eric Blake
sharutilsEric Blake

Re: calm: vaulting ancient unifont

[Jon Turney via Cygwin-apps]

On 06/05/2024 17:46, Brian Inglis via Cygwin-apps wrote:

On 2024-05-06 09:27, Jon Turney via Cygwin-apps wrote:

[...]
Anyhow, double checking that the "right thing" happened here, I notice 
that 'unifont' obsoletes 'unifont-debuginfo', which seems a bit weird, 
especially since it contains the expected .dbg files etc.


Brian,

Are you sure that's right?


It appears not!
My reasoning was that as unifont-viewer was split out from 
unifont-fonts, unifont-viewer-debuginfo would be generated, but it 
appears that is not how that works.
Is there any way to make that work, or should I just drop it in the next 
release, or a new -RELEASE?


There's only a single debuginfo package generated for each source 
package.  It's unclear to me that finer granularity would be very useful.


unifont-viewer seems to be just a script, anyhow, so wouldn't have any 
useful debug information.
 I don't think this is of any great importance, so fixing it in the 
next release seems fine.

Re: libtool can't build shared library unless -no-undefined specified

[Jon Turney via Cygwin-apps]

On 17/05/2024 05:50, Brian Inglis via Cygwin-apps wrote:

On 2024-05-16 15:45, Ken Brown via Cygwin-apps wrote:

On 5/16/2024 4:24 PM, Brian Inglis via Cygwin-apps wrote:

Hi folks,

Trying to update dateutils, autotools build fails with:

libtool: error: can't build x86_64-pc-cygwin shared library unless 
-no-undefined is specified


Suggestions for overrides or fixes?

Tried:

LDFLAGS="$LDFLAGS -Wl,--no-allow-shlib-undefined -Wl,--no-undefined"

CYGCONF_ARGS="
  --enable-contrib
  --enable-tzmap-fetch
  lt_no_undefined_flag=--no-undefined
  no_undefined_flag=--no-undefined


You and I discussed this a few years ago in connection with curl.  The 
solution there, and in most similar cases, is to add -no-undefined to 
the appropriate lib*_la_LDFLAGS variable(s) in Makefile.am.  See


Yeah, building stuff for Cygwin often requires adding this flag in the 
appropriate places, to say "yes, I really do want a shared library".


https://www.gnu.org/software/libtool/manual/html_node/Link-mode.html#Link-mode


-no-undefined

Declare that output-file does not depend on any libraries other than
the ones listed on the command line, i.e., after linking, it will not
have unresolved symbols. Some platforms require all symbols in shared
libraries to be resolved at library creation (see Inter-library
dependencies), and using this parameter allows libtool to assume that
this will not happen.


Note that because this flag doesn't do anything for non-PE targets, it's 
(a) always safe to upstream, and (b) doesn't actually prevent 
development from unwittingly introducing unresolved symbols.



This should probably be mentioned in the FAQ item on PE linkage 
peculiarities.

Re: [ITA] dateutils

[Jon Turney via Cygwin-apps]

On 17/05/2024 06:43, Brian Inglis via Cygwin-apps wrote:

Date manipulation utilities

[...]

I would like to adopt the above orphaned package.



Thanks.

I added this to your packages.


https://cygwin.com/cgit/cygwin-packages/dateutils/tree/dateutils.cygport?h=playground


Please cleanup all the commented out detritus.

What is the reasoning for changing SRC_URI to point to github?  The 
project homepage still points to bitbucket.org for downloads.


"*** Warning: DEPEND is deprecated, use BUILD_REQUIRES instead."


Scallywag runs:



https://cygwin.com/cgi-bin2/jobs.cgi?srcpkg=dateutils



The single test failure is not reproducible standalone, and appears to
be a Windows, Cygwin, or shell environment space limitation, due to
running 888 tests on a single command line?


Can you share the reasoning that lets your reach that conclusion from:


FAIL: tzmap_check_02.ctst


The build directory should be available as an artifact which may contain 
more detailed information on the failure.


Have you established that this failure is not a regression?

Re: Technical reason why 32bit Cygwin cannot be installed on 64bit Windows?

[Jon Turney via Cygwin]

On 19/05/2024 00:17, Mark Geisert via Cygwin wrote:
[...]
FWIW Although this wording seems to indicate Cygwin is still supported 
on 32-bit Windows, just discouraged.


This seems like a willfully context-blind reading.

The table above lists Windows versions for which support has been 
discontinued, which includes "All 32-bit".


Further, https://cygwin.com/ plainly states "The Cygwin DLL currently 
works with all recent, commercially released x86_64 versions of Windows 
...", which seems pretty unambiguous.



Suggestions on how to improve this obviously welcomed. (but I'm not a 
big fan of "put fact A in place X as well as place Y, so people who 
ignored it in place Y because it didn't fit there priors can continue to 
ignore it in place X as well.")



--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Technical reason why 32bit Cygwin cannot be installed on 64bit Windows?

[Jon Turney via Cygwin]

On 17/05/2024 17:30, Eliot Moss via Cygwin wrote:

On 5/17/2024 11:21 AM, Cedric Blancher via Cygwin wrote:
On Fri, 17 May 2024 at 16:50, Brian Inglis via Cygwin 
 wrote:


On 2024-05-17 01:48, Cedric Blancher via Cygwin wrote:

Is there a technical reason why 32bit Cygwin cannot be installed on
64bit Windows? We like to create a CI build pipeline, and want to
create binaries for 32bit and 64bit Cygwin on the same machine, but
setup.exe for 32bir Cygwin refuses to install


Practical reason is 32 bit usage < 1%


I would agree for commercial, well-funded enterprises. The situation
is much different for funding-starved education, i.e. schools and
universities, where Win10 32bit is squatting cheap computers in the
*millions*. For example the schools in Paris alone have 22000 active
Win10 32bit licenses in 2022 (last time this was counted).


and Cygwin is all volunteer, with
professionally and/or personally busy developers lacking time to do 
more.

You are on your own with 32 bit dropped,


Does Cygwin 3.6 still compile on 32bit?


AFAIK, yes, though most folks don't compile it themselves.


This is not correct, it does not.

Even if it did, it seems wildly optimistic to assume it just works, when 
no-one has been ensuring that it does.



--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Technical reason why 32bit Cygwin cannot be installed on 64bit Windows?

[Jon Turney via Cygwin]

On 17/05/2024 10:30, Dimitry Andric via Cygwin wrote:

On 17 May 2024, at 09:48, Cedric Blancher via Cygwin  wrote:


Is there a technical reason why 32bit Cygwin cannot be installed on
64bit Windows? We like to create a CI build pipeline, and want to
create binaries for 32bit and 64bit Cygwin on the same machine, but
setup.exe for 32bir Cygwin refuses to install


How exactly does it "refuse to install" ? If it says "mbox : Cygwin is not supported 
on 32-bit Windows", you may not have followed the instructions at 
https://cygwin.com/pipermail/cygwin/2022-November/252542.html, which say:


This links to

https://cygwin.com/install.html#unsupported

which contains those instructions (and is kept up to date).

I'm not entirely sure how the OP managed to obtain an x86 installer, 
without coming across those instructions.



--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: calm: ncurses untest/vault previous version

[Jon Turney via Cygwin-apps]

On 13/05/2024 17:06, Brian Inglis via Cygwin-apps wrote:

On 2024-05-13 09:32, Jon Turney via Cygwin-apps wrote:

On 13/05/2024 06:25, Brian Inglis via Cygwin-apps wrote:

Hi folks,

Looks like after untest ncurses-6.5+20240427-1 calm decided the
previous version in the recommended format 6.4+20240330-1 was older
than prev:

6.4-20231230


So, this would be a bug, if that's actually what happened, because
6.4+20240330 is definitely greater than 6.4 (under the "if all 
comparison chunks are equal, the string with any suffix remaining is 
the greater" clause of the comparison rule).


What actually seems to have happened is that 6.4+20240330 was still
marked as 'test', and so removed by the "packages labelled test: are
expired when a superseding non-test version exists" logic.


Thanks Jon,

Missed that focusing on the versions not the labels in setup.ini.


(Yeah, calm should probably be a bit more verbose about the reasons why
it's vaulting things in the report)

I can vault the old versions but could someone please unvault 
6.4+20240330-1?


Sure, I'll do that.

Do you want me to remove the test label from 6.4+20240330, or turn on
keep-superseded-test for this package?


Sorry, I should have noticed and untest-ed that immediately before 6.5!
Please remove test label to unvault as "prev" not test.
I've been running with it since released as test, until 6.5, and it is 
the final 6.4 we made available, in case anyone has issues with 6.5.


OK. Done.

6.4-20231230 was vaulted to stay under the count of kept versions.

Re: calm: ncurses untest/vault previous version

[Jon Turney via Cygwin-apps]

On 13/05/2024 06:25, Brian Inglis via Cygwin-apps wrote:

Hi folks,

Looks like after untest ncurses-6.5+20240427-1 calm decided the
previous version in the recommended format 6.4+20240330-1 was older
than prev:

6.4-20231230


So, this would be a bug, if that's actually what happened, because
6.4+20240330 is definitely greater than 6.4 (under the "if all 
comparison chunks are equal, the string with any suffix remaining is the 
greater" clause of the comparison rule).


What actually seems to have happened is that 6.4+20240330 was still
marked as 'test', and so removed by the "packages labelled test: are
expired when a superseding non-test version exists" logic.

(Yeah, calm should probably be a bit more verbose about the reasons why
it's vaulting things in the report)

I can vault the old versions but could someone please unvault 
6.4+20240330-1?


Sure, I'll do that.

Do you want me to remove the test label from 6.4+20240330, or turn on
keep-superseded-test for this package?

Re: [PATCH] cygport/lib/src_prep.cygpart: use checksum files with packages

[Jon Turney via Cygwin-apps]

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

On 2024-04-30 23:32, ASSI via Cygwin-apps wrote:

Brian Inglis via Cygwin-apps writes:
Some package upstreams offer only checksums, for example .sha512sum, 
.sha256sum,
for verification rather than gpg signatures, for example .asc, .sig, 
.sign, etc;
use these checksum files when provided in a similar manner to gpg 
signatures;
these files are often provided with fixed names which may be renamed 
on download
to unique values using cygport URI fragment support like 
#/$NAME-VERSION.sha...sum;
use coreutils cksum as it supports all modern and legacy checksums 
and formats.



https://repo.or.cz/cygport/rpm-style.git/commitdiff/c956092ce8d90230b812fb05ad2b4da13df1e36d


Two similar independent implementations mean it would be a good idea to 
add the feature!


Mine preferred cksum as being the most general approach, while not 
worrying or knowing too much about ancient sums, although your 
implementation is better, that is, works properly on those.


Mine also preferred sha*sum file types, while still allowing prefixes 
only without sum, not enumerating them all in the unpack() case, and 
respecting the cksum crc default.


I guess this makes sense as a part of the fetch operation, in thsose 
cases where upstream provides signatures or checksums.



But as briefly discussed in [1], independently of that it would also be 
a good idea for cygport to specify it's own checksum file, which is 
incorporated into the source package, and verified at build prep time.


(Since this would protect against such screw ups, help with build 
reproducibility, and defend against supply chain attacks on upstream)


[1] https://cygwin.com/pipermail/cygwin-apps/2024-March/043540.html

Re: calm: vaulting ancient unifont

[Jon Turney via Cygwin-apps]

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

Thanks Jon? - yay!


Right, I deployed some changes to calm which will gradually let us get 
rid of the "old-style" of obsoletion (where, as here, the old name of a 
package (i.e. font-unifont-misc, font-unifont-ttf) continues to exist 
with a category of _obsolete and requires: its replacement)


(cygport stopped generating these some time ago (0.34.1, 2022), but 
they've been lingering around indefinitely, because in some cases it's 
only the existence of these packages which currently records the fact of 
the obsoletion)



Since someone's bound to get the wrong end of the stick: This doesn't 
mean package maintainers should change anything.


And just to reiterate: As a principle, every version of a package must 
contain complete instructions for upgrading to it. So, it is almost 
never correct to go "I'll remove these OBSOLETE instruction after one 
package release with them, since they've already happened everywhere..."


On 2024-05-04 09:48, 
cygwin-no-reply-rdbxbdvo6bxqt0dzr+a...@public.gmane.org wrote:

INFO: vaulting x86_64/release/unifont/unifont-8.0.01-1-src.hint
INFO: vaulting x86_64/release/unifont/unifont-8.0.01-1-src.tar.xz
INFO: vaulting 
x86_64/release/unifont/font-unifont-misc/font-unifont-misc-8.0.01-1.hint
INFO: vaulting 
x86_64/release/unifont/font-unifont-misc/font-unifont-misc-8.0.01-1.tar.xz
INFO: vaulting 
x86_64/release/unifont/font-unifont-ttf/font-unifont-ttf-8.0.01-1.hint
INFO: vaulting 
x86_64/release/unifont/font-unifont-ttf/font-unifont-ttf-8.0.01-1.tar.xz
INFO: vaulting 
x86_64/release/unifont/unifont-debuginfo/unifont-debuginfo-8.0.01-1.hint
INFO: vaulting 
x86_64/release/unifont/unifont-debuginfo/unifont-debuginfo-8.0.01-1.tar.xz

SUMMARY: 8 INFO(s)


Anyhow, double checking that the "right thing" happened here, I notice 
that 'unifont' obsoletes 'unifont-debuginfo', which seems a bit weird, 
especially since it contains the expected .dbg files etc.


Brian,

Are you sure that's right?

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

[Jon Turney via Cygwin-apps]

On 03/04/2024 15:18, Daisuke Fujimura via Cygwin-apps wrote:

Thank you for reviewing this.


Can you clarify what the "failure" is here?



[...]


/usr/share/rubygems/rubygems.rb:8:in `require': cannot load such file
-- rbconfig (LoadError)


[...]

Thanks very much for the detailed explanation.

So this is an error (or warning?) generated by invoking the 
not-yet-properly installed, just-built ruby in ${D}.


I applied your patch.


On Sun, Mar 10, 2024 at 10:34 PM Jon Turney  wrote:


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

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


Thanks for this patch.

Can you clarify what the "failure" is here?


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


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

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


... except I added something to generically prevent a packages provides: 
appearing it it's requires:

Re: [ITA] bash-completion/-devel

[Jon Turney via Cygwin-apps]

On 29/04/2024 22:13, Brian Inglis via Cygwin-apps wrote:
I would like to co-maintain or adopt and revive the above package, which 
was adopted by Eric but not updated since Yaakov.


Thanks.

I added this to your packages.

I guess I need to ask eblake if he wants to orphan his packages, since 
he seems to be no longer active...


Below are links to existing source packages, build repos, scallywag 
runs, and updated package info.


I would like to further improve the sdesc and ldesc provided to reflect 
that completions are provided for thousands of commands and their 
options and arguments.



Bash Completions and development

Existing source package:

https://cygwin.com/packages/summary/bash-completion-src.html

Updated cygport:

https://cygwin.com/cgit/cygwin-packages/bash-completion/tree/bash-completion.cygport?h=playground


A few comments:


DEPEND="automake dejagnu make screen" # tcllib
BUILD_REQUIRES="$DEPEND"


Just set BUILD_REQUIRES.

I assume the comment about tcllib means something to someone. :)


src_test() {
cd $B
# For some tests involving non-ASCII filenames
export LANG=C.UTF-8
export -f cygtest
# This stuff borrowed from dejagnu-1.4.4-17 (tests need a terminal)
tmpfile=$(mktemp bash-completion.screen.XX.tmp)
#   cygtest


At first glance, because this is commented out, I thought "so this 
doesn't run tests at all"


Maybe remove the commented out line, and write a comment saying 
something like "run tests under screen, since they need a terminal"



screen -D -m bash -c '( cygtest ; echo $? ) >'$tmpfile
cat $tmpfile

> result=$(tail -n 1 $tmpfile)

This cleverness to propagate the exit code is probably also worthy of 
comment, since I had to think about it for a few minutes before I 
realized what it was doing...


Perhaps should remove tmpfile here?


return $result
}

Re: [PATCH cygport] Increase _FORTIFY_SOURCE level from 2 to 3 in CFLAGS

[Jon Turney via Cygwin-apps]

On 28/04/2024 13:21, Christian Franke via Cygwin-apps wrote:

ASSI via Cygwin-apps wrote:

Christian Franke via Cygwin-apps writes:

_FORTIFY_SOURCE=3 is supported by Cygwin 3.5.0 headers and Cygwin gcc
13.2.1 test release.

Silently falls back to level 2 if level 3 is unsupported (older
headers or gcc) or to level 0 if unsupported at all (C++, clang).

Well, if only that was the case…

--8<---cut here---start->8---
  from /usr/include/w32api/windows.h:9,
  from 
/mnt/share/cygpkgs/libarchive/libarchive.x86_64/src/libarchive-3.7.4/test_utils/test_common.h:88,
  from 
/mnt/share/cygpkgs/libarchive/libarchive.x86_64/src/libarchive-3.7.4/tar/test/test.h:38,
  from 
/mnt/share/cygpkgs/libarchive/libarchive.x86_64/src/libarchive-3.7.4/tar/test/test_extract_tar_lrz.c:25:
/usr/include/w32api/_mingw_mac.h:319:8: warning: #warning Using 
_FORTIFY_SOURCE=2 (level 3 requires __builtin_dynamic_object_size 
support) [-Wcpp]
   319 | #  warning Using _FORTIFY_SOURCE=2 (level 3 requires 
__builtin_dynamic_object_size support)

--8<---cut here---end--->8---

Can't we conditiohnalize this to depend on the actual compiler support?


This is a bogus warning. Sorry, my bad.

In my contribution of _FORTIFY_SOURCE support to MinGW-w64 from 2019, I 
didn't realize that these warnings also appear if only Win32 API 
includes (windows.h, ...) are used. The related internal macros have 
only an effect if MinGW-w64 runtime includes (stdio.h, string.h, ...) 
are used.


Meantime this has been fixed upstream:
https://sourceforge.net/p/mingw-w64/mingw-w64/ci/f8e088e


I guess that means we need an updated w32api-header package, with this 
patch added, if it's not yet in a release...

Re: Cygwin - rsync / new release 3.2.7 => 3.3.0

[Jon Turney via Cygwin-apps]

On 29/04/2024 15:10, Jari Aalto wrote:

On 2024-04-28 21:41, Chad Dougherty wrote:

Hello Jari,

On 4/27/24 05:12, Jari Aalto wrote:

Hi Chad, you seemed to take care of rsync while I was unavailable.  If
you still want to maintain rsync, would you update it to latest
version.

I checked and it compiles ok.

... but you might want to also apply the Debian patches to the latest
version


It's good to hear from you.  I'd be happy for you to resume maintainership
of this package if you're willing.  I no longer actively use Cygwin so it
would make more sense for someone else to do it.


Chad,

I guess that means that your other packages are orphaned?

$ grep 'Chad Dougherty' cygwin-pkg-maint
lz4  Chad Dougherty
mingw64-i686-lz4 Chad Dougherty
mingw64-x86_64-lz4   Chad Dougherty
minisign Chad Dougherty
passwdqc Chad Dougherty

Thanks for your work on these as a maintainer.


Thanks Chad, I have the latest ready, so I can continue maintaining.

Jon, would someone update the Cygwin Porters file in order to proceed
with the upload.


Jari,

Done.

I set your rsync-3.3.0-1 upload to be retried, which seems to have 
succeeded.

Re: cygport may not create debug info if top directory contains a symlink

[Jon Turney via Cygwin-apps]

On 18/09/2023 18:24, Brian Inglis via Cygwin-apps wrote:

On 2023-09-18 04:41, Christian Franke via Cygwin-apps wrote:

Brian Inglis wrote:

On 2023-09-17 08:01, Jon Turney via Cygwin-apps wrote:

On 16/09/2023 15:17, Christian Franke via Cygwin wrote:

Found during tests of busybox package:
If the path of the top build directory contains a symlink and the 
project's build scripts normalize pathnames, no debug info is 
created by cygport.


This is because options like
  -fdebug-prefix-map=${B}=/usr/src/debug/${PF}
have no effect because ${B} contains a symlink but the compiler is 
run with the real source path.



[...]


Sidenote: we should probably also be using file-prefix-map, now 
we're on a gcc which supports it.


... also macro-prefix-map, although it looks like changing to 
-ffile-prefix-map is equivalent to -f*-prefix-map which future proofs 
the options!


So I updated to using -ffile-prefix-map in cygport 0.36.8, since that 
seems like the "Right Thing(TM)"


I discovered today that, amazingly, this breaks compiling ruby, since in 
one place it does:


#include __FILE__

(yeah, that's pretty jaw dropping...)

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

[Jon Turney via Cygwin-apps]

On 10/03/2024 16:33, Christian Franke via Cygwin-apps wrote:

Jon Turney wrote:

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

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


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


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




[...]

Thanks for this.


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


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


New patch attached. Is still on top of "Use correct wording ..." patch.

I also added HOMEPAGE to the propagated variables as this should be 
included in an announcement.


Thanks.


+   /bin/bash -c "cd ${top} || exit 1
+${HOMEPAGE+HOMEPAGE=${HOMEPAGE@Q}}
+P=${P@Q}; PF=${PF@Q}; PN=${PN@Q}; PR=${PR@Q}; PV=(${PV[*]@Q})
+${SMTP_SENDER+SMTP_SENDER=${SMTP_SENDER@Q}}
+${SMTP_SERVER+SMTP_SERVER=${SMTP_SERVER@Q}}
+${SMTP_SERVER_PORT+SMTP_SERVER_PORT=${SMTP_SERVER_PORT@Q}}
+${SMTP_ENCRYPTION+SMTP_ENCRYPTION=${SMTP_ENCRYPTION@Q}}
+${SMTP_USER+SMTP_USER=${SMTP_USER@Q}}
+${SMTP_PASS+SMTP_PASS=${SMTP_PASS@Q}}
+${cmd}
+" $0 ${msg} || error "Command '\${${cmdvar}} ${msg}' (cwd=${top}) 
failed"
+}


Sorry I didn't notice this before, and I am terrible at writing shell, 
but perhaps you could share the reasoning behind writing this as above, 
and not as, e.g.


(cd ${top} && env BLAH ${cmd})

avoiding all the verbiage in the description of ANNOUNCE_EDITOR about it 
being fed into 'bash -c' (and hence getting evaluated twice??) rather 
than just run?

Re: [PATCH cygport] Add repro-finish command

[Jon Turney via Cygwin-apps]

On 11/03/2024 11:41, Christian Franke via Cygwin-apps wrote:
Thanks for accepting the repro-check patch. A minor enhancement is 
attached.


Applied. Thanks!

The function is in pkg_pkg.cygpart instead of pkg_cleanup.cygpart 
because then it is easier to keep it in sync with the other __repro_* 
functions.


PS: I have a local script which checks SPDX Identifiers and expressions. 
Any interest to add this to cygport and then check LICENSE settings?


Oh, yes please. That sounds like a good idea.

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

[Jon Turney via Cygwin-apps]

On 10/03/2024 15:44, Christian Franke via Cygwin-apps wrote:

Jon Turney wrote:

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


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


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


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




Yes, it actually doesn't change the behavior of this fragment itself.


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


Yes - but after this src_install() the file will be re-added by 
__predoc() unless _CYGPORT_RESTRICT_postinst_doc_ is set. The patch 
avoids this because __predoc() also uses dodoc().


Ah, I get it.

Applied with a bit of rewording of the commit commentary for dullards 
like myself.


Thanks.

Re: Why python > 36 so many dependencies?

[Jon Turney via Cygwin]

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

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

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


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


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


Take a look at some mirrors.

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


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

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



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


No, don't look there!

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



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


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


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: native symlinks and non-existent targets

[Jon Turney via Cygwin]

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

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

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


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


No.

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


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



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


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


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Fwd: Howto request an upgrade for keychain package

[Jon Turney via Cygwin-apps]

Hi Jari,

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


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


TIA.

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

Hi,

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

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

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

Regards

ninja 1.12.0-1

[Jon Turney via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

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

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



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

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

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

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

[Jon Turney via Cygwin-apps]

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

Hi folks,


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



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

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

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


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

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

[Jon Turney via Cygwin-apps]

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

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


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

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

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

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

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

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


nothing should depend from 3.5
not sure for 3.6


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

So yeah, it looks like nothing uses 3.5.

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

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


Ake,


Hi Jon, sorry for the late reply.


No problem.


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


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


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


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


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

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


Thanks for your work in the past.

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

[Jon Turney via Cygwin-apps]

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

Hi folks,

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

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


Thanks for reporting this.

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


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


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


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

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

[Jon Turney via Cygwin-apps]

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

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

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


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


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


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


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


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

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


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

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


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

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

[Jon Turney via Cygwin-apps]

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


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


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

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

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

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

[Jon Turney via Cygwin-apps]

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


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



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


Generally, no.

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


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


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


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


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


Reviewing the cygports, everything looks OK.

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


I added GeoIP and GeoIP-database to your packages.

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

[Jon Turney via Cygwin]

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

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

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


Thanks very much for this patch!

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


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


I added this.

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


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


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


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


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

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

[Jon Turney via Cygwin-apps]

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

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


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


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

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


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


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


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


We apologize for the inconvenience.

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

[Jon Turney via Cygwin-apps]

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

Hi folks,

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


Thanks for the report.

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

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

[Jon Turney via Cygwin]

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

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


Thanks very much for this patch!

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


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


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


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




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



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



--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: python2 removal

[Jon Turney via Cygwin-apps]

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

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

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

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

[...]


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


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



[...]


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



[...]


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


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


I guess what wants to happen is:

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


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

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

[Jon Turney via Cygwin-apps]

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

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

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

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

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

[...]


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

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


What unexpected thing happens?

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

So maybe the best solution is:

libsvtav1dec0_OBSOLETES=libsvtav1
libsvtav1dec0_REQUIRES=libsvtav1enc1

So libsvtav1 is replaced by both libsvtav1dec0 and libsvtav1enc1


Looks great!


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

Instead, I found

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


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


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


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


Thanks you very much!

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


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


Hopefully, that resolves the misbehavior you describe below.



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

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

Im not sure why this happens.

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

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

What do you think?

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

[Jon Turney via Cygwin-apps]

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

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

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

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

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

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

[...]

David,

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

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


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


No problem. Thanks for maintaining it in the past.

Is the same true for your other packages?

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


Yes, I'm afraid it is.


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


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

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

if anyone would not.



Thanks. I added these to your packages.

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


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

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

[Jon Turney via Cygwin-apps]

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

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

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

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

[...]

David,

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


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


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


No problem. Thanks for maintaining it in the past.

Is the same true for your other packages?

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


Yes, I'm afraid it is.


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

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

Re: calm now runs on-demand

[Jon Turney via Cygwin-apps]

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

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

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

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

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


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


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


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



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

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


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

Thanks for pointing out this problem.


May be I misunderstood how I should use it

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


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

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

[Jon Turney via Cygwin]

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

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


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


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


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


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


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



[...]

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


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

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

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


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


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


  import ConfigParser
ModuleNotFoundError: No module named 'ConfigParser'


[...]


#downgrade libxml2...

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

jpyeron@blackfat ~
$ ./test.py

jpyeron@blackfat ~
$ virt-manager


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

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

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

[1] https://cygwin.com/pipermail/cygwin-apps/2023-April/042778.html


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

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

[Jon Turney via Cygwin-apps]

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

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

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

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

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


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




nothing should depend from 3.5
not sure for 3.6


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


So yeah, it looks like nothing uses 3.5.


I've removed some 3.4 detritus, and 3.5

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


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


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


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


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


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


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

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

[Jon Turney via Cygwin-apps]

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

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

[...]

David,

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


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


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


No problem. Thanks for maintaining it in the past.

Is the same true for your other packages?

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

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

[Jon Turney via Cygwin-apps]

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

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

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


Thanks very much for bug report, and the patch!

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


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

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

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

[Jon Turney via Cygwin-apps]

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

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

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

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

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


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



nothing should depend from 3.5
not sure for 3.6


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


So yeah, it looks like nothing uses 3.5.

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


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

David,

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


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


Thanks.

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

[Jon Turney via Cygwin-apps]

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

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

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

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

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


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



nothing should depend from 3.5
not sure for 3.6


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


So yeah, it looks like nothing uses 3.5.

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


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


Ake,

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


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


Thanks.

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

[Jon Turney via Cygwin-apps]

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

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

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

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

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

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

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

[...]


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


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


Nice :S

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


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


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


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


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

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


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

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

[Jon Turney via Cygwin-apps]

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

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

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

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

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


[...]


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


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


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


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


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


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


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


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


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


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


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


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

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


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


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


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


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

Re: Mirror announcement

[Jon Turney via Cygwin]

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


OK, I'll leave the location unspecified.

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

API to fetch files).

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


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



--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Mirror announcement

[Jon Turney via Cygwin]

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


Thanks for providing a mirror.

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


[1] https://cygwin.com/mirrors.html


--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

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

[Jon Turney via Cygwin-apps]

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

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

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

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


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




nothing should depend from 3.5
not sure for 3.6


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


So yeah, it looks like nothing uses 3.5.

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


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

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

[Jon Turney via Cygwin-apps]

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


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

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


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

[...]


Here's my personal list:

* python

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

 Marco,

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


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

Re: Fwd: Updating cygwin "libnfs" package ?

[Jon Turney via Cygwin-apps]

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

Hi!



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


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

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

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

Re: [ITP] afflib 3.7.20-1

[Jon Turney via Cygwin-apps]

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

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

Jon Turney wrote:
...


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


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


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


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


Good point, new cygport file is attached.


Any further issues with this ITP?


Seems good.

I added this to your packages.

gcab 1.6-1

[Jon Turney via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

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

A GObject library to create cabinet files



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

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

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

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

[Jon Turney via Cygwin]

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


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

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

$ gcc --version
gcc (GCC) 13.2.1 20240203

[...]

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

collect2: error: ld returned 1 exit status


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


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


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


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

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

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

What should I do?


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


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

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



--
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

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

[Jon Turney via Cygwin-apps]

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

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

[...]


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

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


What unexpected thing happens?

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


So maybe the best solution is:

libsvtav1dec0_OBSOLETES=libsvtav1
libsvtav1dec0_REQUIRES=libsvtav1enc1

So libsvtav1 is replaced by both libsvtav1dec0 and libsvtav1enc1


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

Instead, I found

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


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



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


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

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

[Jon Turney via Cygwin-apps]

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

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

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

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

Was anything wrong?


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

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

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


1.8.0-2 is necessary for changing packaging.


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



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


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

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


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


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



In this particular case, that means the cygport should contain

libsvtav1dec0_OBSOLETES=libsvtav1

for as long as the package produces libsvtav1dec0.


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



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


No problem.  Mistakes happen.

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

[Jon Turney via Cygwin-apps]

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

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

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

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

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

Hi folks,
I'm getting the error:

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

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


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



[...]

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


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


This maybe looks like pilot error.

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



I suggest you need to do

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


to push successfully.

If that works, I suggest you memorialize that by doing

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


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


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


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

Glad to hear that things are working again for you!

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

[Jon Turney via Cygwin-apps]

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

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

Was anything wrong?


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


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

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

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

[Jon Turney via Cygwin-apps]

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

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

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

Hi folks,
I'm getting the error:

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

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


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


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


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



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


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


This maybe looks like pilot error.

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



I suggest you need to do

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

to push successfully.

If that works, I suggest you memorialize that by doing

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


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




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

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


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

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

[Jon Turney via Cygwin-apps]

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

Hi folks,
I'm getting the error:

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

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


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


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


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

osslsigncode 2.8-1

[Jon Turney via Cygwin-announce]

The following packages have been uploaded to the Cygwin distribution:

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

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



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

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

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

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

[Jon Turney via Cygwin-apps]

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

Jon Turney via Cygwin-apps writes:

[...]



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


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


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

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


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


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


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

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


[...]

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


Nothing to see here, move along… :-P


...

[...]

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


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


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


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

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

[Jon Turney via Cygwin-apps]

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

Brian Inglis via Cygwin-apps wrote:

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

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

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


Agree - new patch attached.


Applied. Thanks!

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

[Jon Turney via Cygwin-apps]

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

Harmless bug ...



Applied. Thanks.

Re: [PATCH cygport] Add repro-check command

[Jon Turney via Cygwin-apps]

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

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



[...]


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


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


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



Applied. Thanks!

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

[Jon Turney via Cygwin-apps]

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


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


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


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


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



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


I applied the documentation change as that is obviously needed.

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

[Jon Turney via Cygwin-apps]

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


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




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

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

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

[Jon Turney via Cygwin-apps]

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

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


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


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




[...]

Thanks for this.


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


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


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


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

Re: [PATCH cygport] Add more checks of SOURCE_DATE_EPOCH

[Jon Turney via Cygwin-apps]

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



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


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


Ok, but exporting it is harmless there, right?

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




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


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


Ah, right.

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


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