Re: [PATCH cygport] Add customization support for announce command
On Wed, May 01, 2024 at 04:49:10PM +0200, Christian Franke via Cygwin-apps
wrote:
> Adam Dinwoodie via Cygwin-apps wrote:
> > On Tue, Apr 30, 2024 at 12:27:35PM +0200, Christian Franke via Cygwin-apps
> > wrote:
> > > Jon Turney wrote:
> > > > On 10/03/2024 16:33, Christian Franke via Cygwin-apps wrote:
> > > > > + /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?
> > > >
> > > >
> > > None of the mentioned variables are exported to the environment by
> > > cygport.
> > > I wanted to keep this fact in the subshell. Therefore the assignments are
> > > added to the script instead of passing via env(ironment). The latter won't
> > > even work with the PV variable because arrays could not be exported.
> > >
> > > Variables would not be evaluated twice. For example in the rare case that
> > > someone uses something like
> > >
> > > SMTP_SERVER="smtp.$(hostname -d)"
> > >
> > > in cygport.conf, this would immediately expand to
> > > SMTP_SERVER="smtp.some.domain". The above
> > >
> > > ${SMTP_SERVER+SMTP_SERVER=${SMTP_SERVER@Q}}
> > >
> > > would expand to
> > >
> > > SMTP_SERVER=${SMTP_SERVER@Q}
> > >
> > > and then to
> > >
> > > SMTP_SERVER='smtp.some.domain'
> > >
> > > (The @Q bash extension ensures proper quoting).
> > Using a subshell created by ( ... ) would achieve the behaviour you're
> > after, without requiring nearly so much quote handling. The code Jon
> > has pulled out could be rewritten as below; using ( ... ) would mean
> > that everything happens in a subshell and the exports don't affect the
> > rest of the environment.
> >
> > ```
> > (
> > cd "$top"
> > export HOMEPAGE P PF PN PR PV SMTP_SENDER SMTP_SERVER SMTP_SERVER_PORT
> > SMTP_ENCRYPTION SMTP_USER SMTP_PASS
>
> This unnecessarily exports all variables (except PV, see below) to the
> subcommands run by $cmd.
>
>
> > "$cmd" "$msg" || error "Command $cmd $msg (cwd=${top}) failed"
>
> This would limit $cmd to simple commands instead of multiline scripts. This
> reduces flexibility and some of the examples I provided in my original post
> would no longer work:
> https://sourceware.org/pipermail/cygwin-apps/2024-February/043501.html
Ah, right! Apologies, I'd missed/forgotten that context.
I still think this is the wrong approach. Cygport has a very well
established design paradigm for running non-trivial custom code: there's
a default Bash function in the Cygport library files, and an individual
cygport file can override that function with its own version. If
running something more than a simple command is required here, I'd have
thought following that established paradigm would be a much more
sensible approach. This would also completely avoid the need for any
special variable handling, because the function will run in an
environment where the variables are already set.
I'd suggest a pair of functions that _aren't_ read-only, say
`announce_edit` and `announce_send`, that default to the current code
for editing and sending the announcement, but which a maintainer can
override in their cygport file should they so desire.
I really don't like passing strings around to be eval'd, particularly
when they're expected to contain non-trivial code. Given
Re: [PATCH cygport] Add customization support for announce command
On Tue, Apr 30, 2024 at 12:27:35PM +0200, Christian Franke via Cygwin-apps
wrote:
> Jon Turney wrote:
> > On 10/03/2024 16:33, Christian Franke via Cygwin-apps wrote:
> > > + /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?
> >
> >
>
> None of the mentioned variables are exported to the environment by cygport.
> I wanted to keep this fact in the subshell. Therefore the assignments are
> added to the script instead of passing via env(ironment). The latter won't
> even work with the PV variable because arrays could not be exported.
>
> Variables would not be evaluated twice. For example in the rare case that
> someone uses something like
>
> SMTP_SERVER="smtp.$(hostname -d)"
>
> in cygport.conf, this would immediately expand to
> SMTP_SERVER="smtp.some.domain". The above
>
> ${SMTP_SERVER+SMTP_SERVER=${SMTP_SERVER@Q}}
>
> would expand to
>
> SMTP_SERVER=${SMTP_SERVER@Q}
>
> and then to
>
> SMTP_SERVER='smtp.some.domain'
>
> (The @Q bash extension ensures proper quoting).
Using a subshell created by ( ... ) would achieve the behaviour you're
after, without requiring nearly so much quote handling. The code Jon
has pulled out could be rewritten as below; using ( ... ) would mean
that everything happens in a subshell and the exports don't affect the
rest of the environment.
```
(
cd "$top"
export HOMEPAGE P PF PN PR PV SMTP_SENDER SMTP_SERVER SMTP_SERVER_PORT
SMTP_ENCRYPTION SMTP_USER SMTP_PASS
"$cmd" "$msg" || error "Command $cmd $msg (cwd=${top}) failed"
)
```
I've removed the array handling for $PV, as it's not an array; possibly
you've confused it with $PVP? In any case, there is no way to pass an
array to "$cmd" unless "$cmd" is itself a Bash function, as there's no
standard way to store anything other than strings in environment
variables.
I've also removed the `|| return 1` part, since cygport runs with `set
-e` enabled so you only want to catch non-zero return codes if you want
specific error handling.
Finally, I've also added "$msg" to the arguments to "$cmd"; that seems
to be missing and seems to be critical to this working at all!
Alternatively, if you really wanted to avoid the export statement, the
below will achieve the same thing; the only use of the subshell at this
point is to avoid the `cd` changing the working directory for the rest
of the script.
```
(
cd "$top"
HOMEPAGE="$HOMEPAGE" P="$P" PF="$PF" PN="$PN" PR="$PR" PV="$PV"
SMTP_SENDER="$SMTP_SENDER" SMTP_SERVER="$SMTP_SERVER"
SMTP_SERVER_PORT="$SMTP_SERVER_PORT" SMTP_ENCRYPTION="$SMTP_ENCRYPTION"
SMTP_USER="$SMTP_USER" SMTP_PASS="$SMTP_PASS" "$cmd" "$msg" || error "Command
$cmd $msg (cwd=${top}) failed"
)
```
Jon suggested using `env`, although I don't think it provides any
function here that isn't already provided by built-in Bash function.
Personally, I'd rewrite the whole __pkg_announce_run_cmd_on_msg function
as below, although some of this is just my own stylistic preferences (in
particular, I try to avoid `eval` if at all possible, and here `local -n`
works just fine):
```
__pkg_announce_run_cmd_on_msg() {
local cmdvar="$1"
local -n cmd="$1"
local msg="$2"
if [[ ! "$cmd" ]]; then
inform "$cmdvar is empty"
return 0
fi
echo
inform "Launching '$cmd $msg'"
(
cd "$top"
export HOMEPAGE P PF PN PR PV SMTP_SENDER SMTP_SERVER \
SMTP_SERVER_PORT SMTP_ENCRYPTION SMTP_USER \
SMTP_PASS
"$cmd" "$msg" || error "Command '$cmd $msg' (cwd=${top}) failed"
)
}
```
Re: [ITP] python-rfc6555 0.1.0
On Fri, Nov 10, 2023 at 04:23:31PM +, Jon Turney wrote: > On 08/11/2023 17:56, Adam Dinwoodie via Cygwin-apps wrote: > > I'd like to package python-rfc6555. This is a Python module that's now > > required for offlineimap, for which I'm slowly working towards > > submitting an ITA. > > > > The Python module has an Apache 2.0 license, and is available at least > > from Debian per https://packages.debian.org/bookworm/python3-rfc6555 > > > > cygport file is attached, and cygport build results are available at: > > Attachment seems to be missing, but I looked at the cygport and it seems ok. D'oh. > I added this to your packages. Thank you!
[ITP] python-rfc6555 0.1.0
I'd like to package python-rfc6555. This is a Python module that's now required for offlineimap, for which I'm slowly working towards submitting an ITA. The Python module has an Apache 2.0 license, and is available at least from Debian per https://packages.debian.org/bookworm/python3-rfc6555 cygport file is attached, and cygport build results are available at: - https://tastycake.net/~adam/python-rfc6555/python-rfc6555-0.1.0-1-src.hint - https://tastycake.net/~adam/python-rfc6555/python-rfc6555-0.1.0-1-src.tar.xz - https://tastycake.net/~adam/python-rfc6555/python3-rfc6555/python3-rfc6555-0.1.0-1.hint - https://tastycake.net/~adam/python-rfc6555/python3-rfc6555/python3-rfc6555-0.1.0-1.tar.xz - https://tastycake.net/~adam/python-rfc6555/python39-rfc6555/python39-rfc6555-0.1.0-1.hint - https://tastycake.net/~adam/python-rfc6555/python39-rfc6555/python39-rfc6555-0.1.0-1.tar.xz - https://tastycake.net/~adam/python-rfc6555/python38-rfc6555/python38-rfc6555-0.1.0-1.hint - https://tastycake.net/~adam/python-rfc6555/python38-rfc6555/python38-rfc6555-0.1.0-1.tar.xz
Re: [cygport RFC PATCH 1/1] Run install functions separately
On Sun, Nov 05, 2023 at 10:24:43PM +, Adam Dinwoodie via Cygwin-apps wrote:
> ```
> #!/usr/bin/bash
>
> src_install () {
> false
> echo "This step *does* run"
> }
>
> src_install && echo "As does this step"
> ```
The above example should have had `set -e` at the top. Everything I
said holds both with and without it, but the point I was trying to make
is definitely much clearer when both examples have `set -e` and the only
difference is whether there's an && between the function call and the
echo.
Re: [cygport RFC PATCH 1/1] Run install functions separately
On Fri, Nov 03, 2023 at 05:57:08PM +0100, ASSI via Cygwin-apps wrote:
> Adam Dinwoodie via Cygwin-apps writes:
> > When running as part of a `&&` chain, Bash's `set -e` behaviour is
> > suppressed entirely, which means calls that produce non-zero error codes
> > will be ignored if they're called inside functions that are part of such
> > a chain.
> >
> > To avoid silent failures from commands in a src_install function being
> > ignored, don't chain the function calls with &&, and instead just let
> > Bash's `set -e` behaviour handle failures.
>
> That patch circumvents the shortcutting of the execution chain at the
> first fail and might produce undesirable results elsewhere. Unless
> there's another interesting behaviour in Bash, it should suffice to
> follow the last command in the "&&" chain by "|| false" to transfer the
> status of the chain to PIPESTATUS (provided that the return code of the
> functions involved is set correctly).
I think you've misunderstood how `set -e` works. When `set -e` is
active, any non-zero return code from the final command in a pipeline
will cause the script to exit. So both with and without my patch, a
non-zero return code from __prepinstalldirs, src_install or
__src_postinst will cause execution to stop.
The issue is that the && chain disables `set -e` for anything other than
the final command in the chain, *including within functions*. In most
functions in cygport, a non-zero return code will cause cygport to
error, but because the && chain disables `set -e`, failures within
src_install are silently ignored. Counterintuitively, having the &&
chain present means that execution will _continue_ after a failure!
Compare the two scripts below:
```
#!/usr/bin/bash
set -e
src_install () {
false
echo "This step never runs"
}
src_install
echo "This also doesn't run"
```
```
#!/usr/bin/bash
src_install () {
false
echo "This step *does* run"
}
src_install && echo "As does this step"
```
I believe the intent of using `set -e` in cygport is that when there's a
failure -- as with the false command in the src_install functions above
-- execution will stop. This works as expected in the first example,
but in the second example, the `false` call has no effect whatsoever:
Bash will run both the echo within the function and the one that follows
the function.
See also:
- https://www.shellcheck.net/wiki/SC2310
- https://mywiki.wooledge.org/BashFAQ/105
Alternatively, just have a look at the test case I attached to the cover
email; I'd expect that cygport file to fail the install stage, because
the first command in the src_install function is an unhandled failure.
Currently, the src_install succeeds, with no hint of any problems, but
with my patch, it produces an error as expected.
[cygport RFC PATCH 1/1] Run install functions separately
When running as part of a `&&` chain, Bash's `set -e` behaviour is
suppressed entirely, which means calls that produce non-zero error codes
will be ignored if they're called inside functions that are part of such
a chain.
To avoid silent failures from commands in a src_install function being
ignored, don't chain the function calls with &&, and instead just let
Bash's `set -e` behaviour handle failures.
---
bin/cygport.in | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
diff --git a/bin/cygport.in b/bin/cygport.in
index 3f89ac67..3bf4a4fa 100755
--- a/bin/cygport.in
+++ b/bin/cygport.in
@@ -679,7 +679,11 @@ do
inst*)
__stage Installing;
__log_init ${installlog};
- (__prepinstalldirs && src_install && __src_postinst)
2>&1 | tee -a ${installlog};
+ {
+ __prepinstalldirs
+ src_install
+ __src_postinst
+ } 2>&1 | tee -a ${installog};
_status=${PIPESTATUS[0]};
;;
postinst*)
@@ -764,12 +768,20 @@ do
__stage Compiling && src_compile 2>&1 | tee -a
${compilelog} && \
test ${PIPESTATUS[0]} -eq 0 && \
__log_init ${installlog} && \
- __stage Installing && (__prepinstalldirs && src_install
&& __src_postinst) 2>&1 | tee -a ${installlog} && \
- test ${PIPESTATUS[0]} -eq 0 && \
- __log_init ${pkglog} && \
- __stage Packaging && (__pkg_binpkg && __pkg_pkgcheck &&
__pkg_srcpkg ${_pkg_tag} && __pkg_dist ${_pkg_tag}) 2>&1 | tee -a ${pkglog} && \
- test ${PIPESTATUS[0]} -eq 0
- _status=$?;
+ __stage Installing
+ {
+ __prepinstalldirs
+ src_install
+ __src_postinst
+ } 2>&1 | tee -a ${installlog};
+ if test ${PIPESTATUS[0]} -eq 0; then
+ __log_init ${pkglog} && \
+ __stage Packaging && (__pkg_binpkg &&
__pkg_pkgcheck && __pkg_srcpkg ${_pkg_tag} && __pkg_dist ${_pkg_tag}) 2>&1 |
tee -a ${pkglog} && \
+ test ${PIPESTATUS[0]} -eq 0
+ _status=$?;
+ else
+ _status=1;
+ fi
;;
help)
__show_help;
--
2.40.1
[cygport RFC PATCH 0/1] Bug fix? src_install commands fail silently
I've discovered what I _think_ is a cygport bug: most functions within
cygport run with `set -e` enabled in Bash, so if a command has a
non-zero return code that isn't explicitly handled, that'll cause the
cygport command overall to fail. This doesn't work within src_install,
and I _suspect_ that's a bug following from some decidedly unintuitive
Bash behaviour.
The attached test case demonstrates the problem: running `cygport
test.cygport prep compile test` will fail, because of the `false` call
at the start of `src_test`. Running `cygport test.cygport prep compile
install`, however, won't fail, even though there's a `false` call at the
start of the `src_install` function.
Specifically, when src_install is called in the cygport executable, it's
called as below:
(__prepinstalldirs && src_install && __src_postinst) 2>&1 | tee -a
${installlog}
The fact that Bash normally only considers the final command in a
pipeline is handled by a subsequent check of ${PIPESTATUS[0]}, but
quoting the Bash man page description for `set -e`:
> The shell does not exit if the command that fails is ... part of any
> command executed in a && or || list except the command following the
> final && or || If a compound command other than a subshell
> returns a non-zero status because a command failed while -e was being
> ignored, the shell does not exit.
>
> If a compound command or shell function executes in a context where -e
> is being ignored, none of the commands executed within the compound
> command or function body will be affected by the -e setting, even if
> -e is set and a command returns a failure status.
So because the function call is part of a && chain, the `set -e`
behaviour is completely disabled within that function; the only way a
non-zero return code would be propagated from within the function is if
(a) it were explicitly `return`ed or (b) it came from the final command
in the function.
I've provided a single patch to fix this specific issue, partly because
I'd already written it and thought I might as well share it, but I think
this probably wants a bit more thought. In particular, there are two
things that might mean we want to handle this differently:
- I've only fixed a single problem, but I think bugs of this style are
much more common, e.g. in the similar code for the `cygport compile`
command. It might make sense to fix this in far more locations.
- I wouldn't be at all surprised if this bug, and others of the same
ilk, have become load-bearing. If this gets fixed, it might cause a
lot of build scripts that have otherwise been happily ignoring benign
non-zero return codes suddenly start failing unexpectedly.
Adam Dinwoodie (1):
Run install functions separately
bin/cygport.in | 26 +++---
1 file changed, 19 insertions(+), 7 deletions(-)
--
2.40.1
NAME=test
VERSION=1
RELEASE=1
CATEGORY=Test
SUMMARY='Test package'
HOMEPAGE=
LICENSE=
src_compile () {
cd "$B"
{
echo '#!/usr/bin/env sh'
echo "echo 'Hello, world!'"
} >helloworld
}
src_install () {
false
cd "$B"
dobin helloworld
}
src_test () {
false
PATH="${D}/usr/bin:$PATH"
helloworld | grep 'Hello'
}
[cygport PATCH] Check for pythonXX-wheel when using python-wheel
The python wheel package is required for building using the python-wheel
cygclass, but nothing in cygport verifies its existence, and the error
from the Python commands themselves aren't particularly helpful either.
To avoid other people wasting the time I just did trying to debug Python
build errors, check if the relevant wheel executable is installed, and
complain if it isn't.
---
cygclass/python-wheel.cygclass | 1 +
1 file changed, 1 insertion(+)
diff --git a/cygclass/python-wheel.cygclass b/cygclass/python-wheel.cygclass
index 4f71639d..3f274b98 100644
--- a/cygclass/python-wheel.cygclass
+++ b/cygclass/python-wheel.cygclass
@@ -111,6 +111,7 @@ do
esac
check_prog_req pip${ver} python${ver//.}-pip
+ check_prog_req wheel-${ver} python${ver//.}-wheel
done
#o* python-wheel.cygclass/PKG_NAMES (python-wheel)
--
2.40.1
Re: tzdata packaging options
On Tue, 17 Oct 2023 at 23:48, Brian Inglis via Cygwin-apps wrote: > > Hi folks, > > I have been building and distributing tzdata with maximal backward > compatibility > since adopting the package. > > The maintainer and some distros are choosing to consolidate data and drop > historical details since 1970. > I question whether there are any Cygwin users who use and need the TAI-offset > including leap seconds zoneinfo/right subtree, and whether we also need to > include the zoneinfo/posix subtree, duplicating the data in the main zoneinfo > tree? > > There could be astrologers, genealogists, modern-history historians, and > developers of related software who use the complete historical details, and > astronomers, physicists, who use the TAI-offset including leap seconds > zoneinfo/right subtree. > > I am unsure if anyone depends on the posix subtree duplicating the main tree. > > I could split the current package into the main tree and the "posix" subtree > each 1.7MB, and the "right" subtree 2.3MB. > > For tzdata-minimal, which could become the Base package, I could generate > another build with only zones consolidated with common history since 1970, but > that would require another build with different options to generate the data > to > compile, so presumably another source package, unless there is a way to > generate > say a minimal subtree with another cygmake with different MAKEOPTS, and have > it > packaged the same as the main subtree, or could cygport go bananas? > > Fedora was developing a tzdata-minimal package, which was only to include UTC > for containers, but it looks like UTC-only should work by not installing > *ANY* > tzdata, so they shelved their efforts: > > https://fedoraproject.org/wiki/Changes/tzdata-minimal > > https://bugzilla.redhat.com/buglist.cgi?component=tzdata=Fedora > > Do we think there could be a use case for a UTC-only (Base?) no tzdata package > e.g. CI, and the no data defaults will be handled adequately? > > For RH see RHEL Timezone Data (tzdata) - Development Status Page: > > https://access.redhat.com/articles/1187353 > > Suggestions for how best to proceed with these options, and to ask these > questions of users on the main list? I expect that – while I use Cygwin in CI contexts – that's relatively rare, and most folk using Cygwin will be using it directly. I expect not having at least a core of tzdata files available by default would cause some considerable confusion for those users, as I imagine lots of them consume data from those packages without realising they're doing so. If Cygwin's setup and dependency resolution tools had, say, the equivalent of Debian's task package groups and/or Recommends/Suggests dependencies, it might be sensible to have tzdata recommended for desktop use but not required for server use. Until and unless those enhancements happen, though, IMVHO at least a core tzdata package should be part of the base installation. That said, I suspect there's very few people who need all the extensive data, and those people probably know they're doing something a bit weird, so moving the "posix" and/or "right" trees into separate packages seems reasonable. (Although if "posix" is just a duplicate of the main tree, wouldn't that actually make things worse? If they're duplicated in the same package, I'd expect them to at least be well-compressed, and potentially to be hardlinks so the additional space from including both is near-zero…) _That_ said, given the relatively cheap costs of disk space and bandwidth, I don't see much value in shaving a few MB here and there when this is still a relatively small part of most Cygwin installations. So overall I'd be inclined to do whatever is the least work that's not going to break things. FWIW, if you wanted to canvass opinions from the wider list, I think the email you've sent here would be fine for that purpose, although I'd probably remove the implementation details (e.g. the discussions of cygmake) and just list the options available and the different impacts thereof.
Re: python2 removal
On Sun, 30 Apr 2023 at 19:25, Jon Turney wrote: > > On 25/02/2023 16:51, Adam Dinwoodie via Cygwin-apps wrote: > > On Sat, 25 Feb 2023 at 16:23, Jon Turney via Cygwin-apps wrote: > >> On 16/01/2023 12:49, Jon Turney via Cygwin-apps wrote: > >>> On 15/01/2023 12:52, Jon Turney via Cygwin-apps wrote: > >>> [...] > >>>> Python 2.7 is the last python2 version, which was sunsetted on January > >>>> 1, 2020. > >>> [...] > [...] > >> > >> From a brief survey, only offlineimap and urlgrabber (which should > >> probably be named python-urlgrabber, since it contains a python module) > >> seem to be actively maintained enough to support python3. > >> > >> So I will probably remove the others, and consider if it's possible and > >> worthwhile to update those. > >> > >> (I also noted that breezy appears to be the python3 replacement for bzr > >> and getmail6 appears to be the python3 replacement for getmail.) > > > > I'm happy to adopt both of these. I'll give Jari a little while to > > reclaim them first, not least as I'm not going to have the time to > > spend on packaging these for at least a week or so, but if Jari (or > > anyone else) doesn't claim them first, I'll send an ITA once I've > > checked I can get the packaging to work. > Gentle ping to ask if you are still intending to package these? Yes, they're both on my to-do list, but I've had a whole bunch of real life come up over the past few months. If the delay is causing issues, though, I can bump them up my priority list…
Re: xlsx2csv package may not be required.
On Thu, Mar 16, 2023 at 07:58:48PM -0600, Doug Henderson via Cygwin-apps wrote: > There is a current pure python version of xlsx2csv which runs for many > versions of Python 2 and Python 3. > > It may not be necessary to provide a package for it in cygwin. > Instead, users may install the pure python package from PYPI > https://pypi.org/ using pip or another python package manager. Installing using pip or similar is an option for the vast majority of packages that are available through the Cygwin installer; by that logic it wouldn't make sense to provide most of the Python packages we provide. Which wouldn't be an invalid strategy, but it would be a very big change in how we handle things! I think the advantage of using the Cygwin packages is a better likelihood of packages actually being compatible with Cygwin, rather than having some weird and unpredictable package dependency issue. A pure Python xlsx2csv is very unlikely to be affected by that sort of issue, but providing it as a Cygwin package means users shouldn't need to even think about whether the package is a pure Python package or not.
Re: python2 removal
On Sat, 25 Feb 2023 at 16:23, Jon Turney via Cygwin-apps wrote: > On 16/01/2023 12:49, Jon Turney via Cygwin-apps wrote: > > On 15/01/2023 12:52, Jon Turney via Cygwin-apps wrote: > > [...] > >> Python 2.7 is the last python2 version, which was sunsetted on January > >> 1, 2020. > > [...] > >> 2) Looking for packages whose names don't start with 'python', but > >> where the current version installs something into > >> /usr/lib/python2.7/site-packages/ and/or into /usr/bin/ with a shebang > >> containing 'python2', the following packages appear to need rebuilding > >> for python3: > > > > Hi maintainers, > > > > Please consider rebuilding your packages listed below for python3. > > > > If you are no longer interested in being a maintainer for these (or all > > of your) Cygwin packages, please let us know, so we can update our > > records and stop bothering you about them! > > > >> package source package maintainer > >> > >> bzrJari Aalto > >> cfget Jari Aalto > >> codeville Jari Aalto > >> getmailJari Aalto > >> offlineimapJari Aalto > >> tailor Jari Aalto > >> urlgrabber Jari Aalto > >> > > Hi Jari, > > In the absence of any response, I have assumed these are all orphaned. > > If that's not what you wanted to happen, please let me know. > > From a brief survey, only offlineimap and urlgrabber (which should > probably be named python-urlgrabber, since it contains a python module) > seem to be actively maintained enough to support python3. > > So I will probably remove the others, and consider if it's possible and > worthwhile to update those. > > (I also noted that breezy appears to be the python3 replacement for bzr > and getmail6 appears to be the python3 replacement for getmail.) I'm happy to adopt both of these. I'll give Jari a little while to reclaim them first, not least as I'm not going to have the time to spend on packaging these for at least a week or so, but if Jari (or anyone else) doesn't claim them first, I'll send an ITA once I've checked I can get the packaging to work.
Re: Version string of package
On Fri, Jan 13, 2023 at 01:22:44PM +, Jon Turney via Cygwin-apps wrote:
> On 13/01/2023 11:52, Takashi Yano via Cygwin-apps wrote:
> > Hi,
> >
> > Is it allowed to include '-' in version string (e.g. '20230113-stable')?
> > I'm asking because mksetupini warns:
> >
> > mksetupini: file 'xxx.tar.xz' in package yyy contains '-' in version
> >
> > though it works as expected.
>
> Short answer:
>
> It's a bug that this isn't a fatal error. Please don't do it!
>
> Long answer:
>
> Package naming in Cygwin has a long and tangled history. This isn't
> explicitly precluded by the rules at [1], but probably should be.
>
> (Fedora, which we generally follow for packaging rules, now doesn't allow
> '-' in versions, just digits, letters and '.')
>
> We need to be able to unambiguously separate a NVR string into the package
> name, version and release.
>
> Underscores are allowed in package names, so the simple approach of
> splitting on the rightmost two hyphens would work, if we don't allow
> exceptions like this.
>
> (We can get it right in this case, because we have a piece of extra
> information: the directory the package is in, which happens to always be
> named N in the current scheme of things, but we might want to change that)
>
> [1] https://cygwin.com/packaging-package-files.html
I just spotted [0] in the Cygport documentation, and was reminded of
this conversation. According to that, the version string is explicitly
allowed to include hyphens! I suspect that's fundamentally a
documentanion bug these days, and should just be expunged...
[0]: https://cygwin.github.io/cygport/syntax_cygpart.html#VERSION
Quick patch below; I can submit this properly as a GitHub PR or with
`git send-email` or otherwise if that'd be useful...
diff --git a/lib/syntax.cygpart b/lib/syntax.cygpart
index 4a400a71..6b992031 100644
--- a/lib/syntax.cygpart
+++ b/lib/syntax.cygpart
@@ -316,7 +316,7 @@ __target_is_embedded() {
#v* Globals/VERSION
# DESCRIPTION
# The upstream package version number. PV must begin with a digit 0-9, and
-# subsequent characters can be a digit, letter, dot, hyphen, or underscore.
+# subsequent characters can be a digit, letter, dot, or underscore.
#
#v* Globals/RELEASE
# DESCRIPTION
Re: [ITP] libinih
On Fri, Jan 13, 2023 at 02:27:46PM +, Jon Turney wrote: > On 11/01/2023 23:16, Adam Dinwoodie via Cygwin-apps wrote: > > On Wed 11 Jan 2023 at 03:14:20PM +, Jon Turney wrote: > > > On 09/01/2023 16:32, Adam Dinwoodie via Cygwin-apps wrote: > > > > As requested at [0], I've offered to package libinih for Cygwin. It has > > > > a BSD license[1] and is already packaged for a bunch of *nix distros, > > > > including Fedora, Debian and Arch[2]. > > > > > [...] > > > This looks good, except... > > > > > > I'd ask you to split this into libinih0 and libinih-devel packages. > [...] > > > > Makes sense! Here's a rebuild: > > > > https://github.com/me-and/Cygwin-inih/releases/tag/v56-1-rc2 > Thanks. > > I added this to your packages. > > > NAME=libinih > > Since the upstream name is just 'inih', the source package should probably > be named that also. Can I double-check how that should work from a package naming perspective? I *think* that means we'd have: - libinih0-$PVR, being the libraries themselves - libinih0-debuginfo-$PVR, being the debugging symbols for the libraries - inih-devel-$PVR, being the header, static libraries and pkgconfig files - inih-$PVR.src, being the source code Is that right? In particular, is it right that the debuginfo name matches the library, while the devel package doesn't? Or should it only be the source package that has a different name? (The build linked above as rc2 has the debuginfo package as inih-debuginfo, and the devel package as libinih-devel, but on reflection that doesn't seem quite right to me. If nothing else, I think I'd expect to find the debug symbols in a package with the same name as the package I'm debugging...) > > libinih0_CONTENTS="\ > > usr/bin/*.dll\ > > usr/share/\ > > " > > You probably want to write this glob as '*-0.dll', so that when the > soversion changes, packaging fails, rather than silently ploughing on to > contain a libinit0 containing cyginit-1.dll... > > (Or factor out the soversion as variable, or something...) Done, thank you for the suggestion!
Re: [ATTN MAINTAINER] tig
On Fri, Jan 13, 2023 at 06:06:22PM +0100, Libor Ukropec via Cygwin-apps wrote: > Dne 13.01.2023 v 17:59 Libor Ukropec via Cygwin-apps napsal(a): > > Dne 10.01.2023 v 15:04 Jari Aalto via Cygwin-apps napsal(a): > > > > > > > > Hi, Thanks for the heads up. I've uploaded new version and added the > > > *.cygport in my Github repository of tig for possible new maintainer > > > in the future. > > > > > > The patches deal some fixes in the xmlto(1) of manual pages build. > > > > > > Jari > > > > > Hi Jari, > > > > I updated to the latest tig, but when executing, it complains about > > missing dependency, but recently I saw many updates to the cygwin > > packages. Any idea if other package was broken, or tig is missing some > > dependency in the metadata? > > > > C:/cygwin64/bin/tig.exe: error while loading shared libraries: > > cygpcreposix-0.dll: cannot open shared object file: No such file or > > directory > > > > Manual installation of "libpcreposix0 8.45-1" seems resolving the problem. > > > > Libor > > > Problem lies somewhere in the compile process? > here is my output for tig I compiled few weeks ago: > > $ ldd ./ttiigg/tig-2.5.4-1.x86_64/build/src/tig.exe > ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffe8659) > KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL > (0x7ffe8516) > KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll > (0x7ffe839e) > cygwin1.dll => /usr/bin/cygwin1.dll (0x7ffe416d) > cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x5461d) > cygncursesw-10.dll => /usr/bin/cygncursesw-10.dll (0x48ca3) > > > and here is from the installed: > $ ldd /usr/bin/tig.exe > ntdll.dll => /cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll (0x7ffe8659) > KERNEL32.DLL => /cygdrive/c/WINDOWS/System32/KERNEL32.DLL > (0x7ffe8516) > KERNELBASE.dll => /cygdrive/c/WINDOWS/System32/KERNELBASE.dll > (0x7ffe839e) > cygwin1.dll => /usr/bin/cygwin1.dll (0x7ffe416d) > cygncursesw-10.dll => /usr/bin/cygncursesw-10.dll (0x48ca3) > cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x5461d) > cygpcre-1.dll => /usr/bin/cygpcre-1.dll (0x3fd63) > cygreadline7.dll => /usr/bin/cygreadline7.dll (0x579cd) > cygpcreposix-0.dll => /usr/bin/cygpcreposix-0.dll (0x520b4) I strongly suspect that, like git, tig will use libpcre if it was present at compile time, and won't if it isn't. Typically I'd expect distribution builds to include libpcre support for this sort of thing. That would mean Jari's compilation was correct, but the .hint files didn't correctly list the necessary dependencies. Jari, your email mentioned a possible new maintainer; are you intending to hand over responsibility, or do you just mean for a hypothetical future maintainer at some point in the future?
Re: [ITP] libinih
On Wed 11 Jan 2023 at 03:14:20PM +, Jon Turney wrote: > On 09/01/2023 16:32, Adam Dinwoodie via Cygwin-apps wrote: > > As requested at [0], I've offered to package libinih for Cygwin. It has > > a BSD license[1] and is already packaged for a bunch of *nix distros, > > including Fedora, Debian and Arch[2]. > > > > [0]: https://cygwin.com/pipermail/cygwin/2023-January/252780.html > > [1]: https://github.com/benhoyt/inih/blob/master/LICENSE.txt > > [2]: https://repology.org/project/inih/versions > > > > Provisional release packages are available at [3], and I've copied the > > main .hint file below for reference. > > > > [3]: https://github.com/me-and/Cygwin-inih/releases/tag/v56-1-rc1 > > Thanks. > > This looks good, except... > > > I've not maintained this sort of library before; I've defaulted to > > including everything in a single package, but Lem suggested splitting > > out a -devel package to contain the header files[4][5]. I don't think > > it makes much difference either way -- the monolithic package is only > > ~16 KB compressed -- and it seems plenty of other Cygwin packages have > > their header files in the same package as the runtime package, but I'd > > appreciate thoughts from everyone else on what's thought to be best > > practice these days... > > I'd ask you to split this into libinih0 and libinih-devel packages. > > Firstly, I don't want to get into making judgements about what the size > threshold is for a package to be "small enough to not bother". > > Secondly, I think, if there's ever a soversion change (i.e. cyginih-0.dll > becomes cyginih-1.dll), structuring it as a single package makes it > impossible to parallel install the old and new soversions together, thus > breaking any other packages linked with the old soversion until they are > rebuilt. Makes sense! Here's a rebuild: https://github.com/me-and/Cygwin-inih/releases/tag/v56-1-rc2 > If you're aware of other packages "done wrong" based on that understanding, > I guess that's something that needs looking into... Ah, I think I was thinking about this backwards. I'd thought that, for example, make is a problem, because it's not marked as a "*-devel" package, but it puts a header file in /usr/include as well as all the files needed by mere users of make.[0] [0]: https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Fmake%2Fmake-4.4-1 It sounds like that's not a problem at all, though: make doesn't provide any libraries to link against. What might be more of a problem is something like file, which does provide a DLL for other packages to link against, and which isn't separated out into a "lib*" package.[1] [1]: https://cygwin.com/cgi-bin2/package-cat.cgi?file=x86_64%2Ffile%2Ffile-5.41-2=usr%2Fbin%2F.%2A%5C.dll (But maybe there's something about file that means we can be confident it'll never have an soversion change? Almost all my practical experience with wrangling library linking is with software appliances that ignore the issue by replacing all the binaries in an effectively- atomic operation, so I am well out of my areas of expertise here!)
[ITP] libinih
As requested at [0], I've offered to package libinih for Cygwin. It has a BSD license[1] and is already packaged for a bunch of *nix distros, including Fedora, Debian and Arch[2]. [0]: https://cygwin.com/pipermail/cygwin/2023-January/252780.html [1]: https://github.com/benhoyt/inih/blob/master/LICENSE.txt [2]: https://repology.org/project/inih/versions Provisional release packages are available at [3], and I've copied the main .hint file below for reference. [3]: https://github.com/me-and/Cygwin-inih/releases/tag/v56-1-rc1 ~~~ category: Libs requires: cygwin libgcc1 libstdc++6 sdesc: "Simple .ini file parser" ldesc: "inih (INI Not Invented Here) is a simple .INI file parser written in C" ~~~ I've not maintained this sort of library before; I've defaulted to including everything in a single package, but Lem suggested splitting out a -devel package to contain the header files[4][5]. I don't think it makes much difference either way -- the monolithic package is only ~16 KB compressed -- and it seems plenty of other Cygwin packages have their header files in the same package as the runtime package, but I'd appreciate thoughts from everyone else on what's thought to be best practice these days... [4]: https://github.com/me-and/Cygwin-inih/pull/1 [5]: https://cygwin.com/pipermail/cygwin/2023-January/252791.html Cheers, Adam
Re: [ATTN MAINTAINER] tig
On Tue, 13 Dec 2022 at 17:16, Libor Ukropec via Cygwin-apps wrote: > > Dne 12.12.2022 v 17:32 Adam Dinwoodie via Cygwin-apps napsal(a): > > On Sun, Dec 11, 2022 at 11:15:35PM +0100, Libor Ukropec via Cygwin-apps > > wrote: > >> Hello Jari, > >> > >> cygwin contains "tig" in version 2.4.1 (2019-07-30) and there's already > >> 2.5.4 (2021) with many bug fixes and improvements available. > >> Can I kindly ask whether it is possible to update the package? > >> I do not see a git repository for the tig package, so I attached the > >> cygport > >> file if it can save you some effort (in compare to the following scallywag, > >> I've added the LICENSE info the script) > >> > >> Scallywag report is here: > >> https://github.com/cygwin/scallywag/actions/runs/3670966767 > > > > I believe Jari's repo for the tig Cygwin packaging is on GitHub[0], and > > it looks like it's using the old pre-Cygport packaging mechanism. I've > > not looked through that repo myself (yet, at least) but it looks like > > there are some patches that imply a naïve build might not work > > perfectly. Or those packages might be entirely obsolete... > I did not look for the GitHub, but the naive compile and run worked with few > custom > actions in the cygport script. > > > > [0]: https://github.com/jaalto/cygwin-package--tig > > > > FWIW, I'd be happy to at least attempt to add this package to my small > > Cygwin Git packaging empire, and take responsibility for keeping it up > > to date going forwards. But that's only if Jari wants to relinquish > > Yes, let's wait for Jari's answer > > that hat, and even then I think Libor clearly gets first refusal given > > they've written the new Cygport file. > > > Here comes my weak English. Will I be refused by Jari or do you mean that I > will refuse > you because I did the Cygport file? > > If the latter, I have no objections you are the maintainer (let's wait for > Jari), I just > wanted to give a helpful hand, not only to rudely ask for the update. And > also to play > more with the cygports and expand my portfolio (I am shy to say `empire`) :) Apologies for the idioms! I mean that if Jari wants to stop being the maintainer, you should be allowed to become the maintainer if you want to, because you wrote the up-to-date cygport file. "First refusal" means, essentially, that you get given the chance to do something before anyone else does. In this case, you'd get the option to become maintainer, and I would only get the option to do so if you refused.
Re: [ATTN MAINTAINER] tig
On Sun, Dec 11, 2022 at 11:15:35PM +0100, Libor Ukropec via Cygwin-apps wrote: > Hello Jari, > > cygwin contains "tig" in version 2.4.1 (2019-07-30) and there's already > 2.5.4 (2021) with many bug fixes and improvements available. > Can I kindly ask whether it is possible to update the package? > I do not see a git repository for the tig package, so I attached the cygport > file if it can save you some effort (in compare to the following scallywag, > I've added the LICENSE info the script) > > Scallywag report is here: > https://github.com/cygwin/scallywag/actions/runs/3670966767 I believe Jari's repo for the tig Cygwin packaging is on GitHub[0], and it looks like it's using the old pre-Cygport packaging mechanism. I've not looked through that repo myself (yet, at least) but it looks like there are some patches that imply a naïve build might not work perfectly. Or those packages might be entirely obsolete... [0]: https://github.com/jaalto/cygwin-package--tig FWIW, I'd be happy to at least attempt to add this package to my small Cygwin Git packaging empire, and take responsibility for keeping it up to date going forwards. But that's only if Jari wants to relinquish that hat, and even then I think Libor clearly gets first refusal given they've written the new Cygport file.
