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.
Re: [ITP] passwdqc 2.0.2
On Sun, 23 Oct 2022 at 20:31, Chad Dougherty wrote: > On 2022-10-23 15:19, Adam Dinwoodie wrote: > > On Sun, 23 Oct 2022 at 20:13, Chad Dougherty wrote: > >> I can't reproduce this and they all look OK in my local environment. By > >> any chance do you have a pointer to a public artifact where it occurs? > >> > >> To be sure, these man pages should be identical for each passwdqc > >> function but they should not be empty. > > > > You can see it in the packaged files from your build, at > > https://github.com/crd477/passwdqc-cygport/raw/main/passwdqc-2.0.2-1.x86_64/dist/passwdqc/libpasswdqc-devel/libpasswdqc-devel-2.0.2-1.tar.xz > > > > Weird, they look OK to me: > $ tar -atpvf > ./passwdqc-2.0.2-1.x86_64/dist/passwdqc/libpasswdqc-devel/libpasswdqc-devel-2.0.2-1.tar.xz > -rw-r--r-- crd/None 1958 2022-10-23 14:57 usr/include/passwdqc.h > -rwxr-xr-x crd/None 12768 2022-10-23 14:57 usr/lib/libpasswdqc.dll.a > -rw-r--r-- crd/None 2196 2022-10-23 14:57 > usr/share/man/man3/libpasswdqc.3.gz > -rw-r--r-- crd/None 60 2022-10-23 14:57 > usr/share/man/man3/passwdqc_check.3.gz > -rw-r--r-- crd/None 66 2022-10-23 14:57 > usr/share/man/man3/passwdqc_params_free.3.gz > -rw-r--r-- crd/None 66 2022-10-23 14:57 > usr/share/man/man3/passwdqc_params_load.3.gz > -rw-r--r-- crd/None 67 2022-10-23 14:57 > usr/share/man/man3/passwdqc_params_parse.3.gz > -rw-r--r-- crd/None 67 2022-10-23 14:57 > usr/share/man/man3/passwdqc_params_reset.3.gz > -rw-r--r-- crd/None 61 2022-10-23 14:57 > usr/share/man/man3/passwdqc_random.3.gz > $ curl -OL > https://github.com/crd477/passwdqc-cygport/raw/main/passwdqc-2.0.2-1.x86_64/dist/passwdqc/libpasswdqc-devel/libpasswdqc-devel-2.0.2-1.tar.xz >% Total% Received % Xferd Average Speed TimeTime Time > Current > Dload Upload Total SpentLeft > Speed >0 00 00 0 0 0 --:--:-- --:--:-- > --:--:-- 0 > 100 4392 100 43920 0 11098 0 --:--:-- --:--:-- --:--:-- > 11098 > $ tar -atpvf ./libpasswdqc-devel-2.0.2-1.tar.xz > -rw-r--r-- crd/None 1958 2022-10-23 14:57 usr/include/passwdqc.h > -rwxr-xr-x crd/None 12768 2022-10-23 14:57 usr/lib/libpasswdqc.dll.a > -rw-r--r-- crd/None 2196 2022-10-23 14:57 > usr/share/man/man3/libpasswdqc.3.gz > -rw-r--r-- crd/None 60 2022-10-23 14:57 > usr/share/man/man3/passwdqc_check.3.gz > -rw-r--r-- crd/None 66 2022-10-23 14:57 > usr/share/man/man3/passwdqc_params_free.3.gz > -rw-r--r-- crd/None 66 2022-10-23 14:57 > usr/share/man/man3/passwdqc_params_load.3.gz > -rw-r--r-- crd/None 67 2022-10-23 14:57 > usr/share/man/man3/passwdqc_params_parse.3.gz > -rw-r--r-- crd/None 67 2022-10-23 14:57 > usr/share/man/man3/passwdqc_params_reset.3.gz > -rw-r--r-- crd/None 61 2022-10-23 14:57 > usr/share/man/man3/passwdqc_random.3.gz > > And this matches what I got when I extracted them into the root > directory on my system: > $ ls -lart /usr/share/man/man3/*passwdq* > -rw-r--r-- 1 root None 61 Oct 23 14:57 > /usr/share/man/man3/passwdqc_random.3.gz > -rw-r--r-- 1 root None 67 Oct 23 14:57 > /usr/share/man/man3/passwdqc_params_reset.3.gz > -rw-r--r-- 1 root None 67 Oct 23 14:57 > /usr/share/man/man3/passwdqc_params_parse.3.gz > -rw-r--r-- 1 root None 66 Oct 23 14:57 > /usr/share/man/man3/passwdqc_params_load.3.gz > -rw-r--r-- 1 root None 66 Oct 23 14:57 > /usr/share/man/man3/passwdqc_params_free.3.gz > -rw-r--r-- 1 root None 60 Oct 23 14:57 > /usr/share/man/man3/passwdqc_check.3.gz > -rw-r--r-- 1 root None 2196 Oct 23 14:57 > /usr/share/man/man3/libpasswdqc.3.gz Ah! Error on my part: I hadn't realised how `man` handles redirects. You're quite right, this is all good!
Re: [ITP] passwdqc 2.0.2
On Sun, 23 Oct 2022 at 20:13, Chad Dougherty wrote: > On 2022-10-23 13:42, Adam Dinwoodie wrote: > >> .hint and .cygport files are attached and can also be found here along > >> with built packages: > >> https://github.com/crd477/passwdqc-cygport > > > > Mostly looks good to me, but I think there are a couple of errors: > > > > - etc/passwdqc.conf and usr/share/man/man5/passwdqc.conf.5.gz look to > > me like they belong in the libpasswdqc0 package > > > > Ah, you're right. Good catch. Fixed in the working repo I mentioned > above. > > > - The usr/share/man/man3/passwdqc_* man pages are all empty > > > > I can't reproduce this and they all look OK in my local environment. By > any chance do you have a pointer to a public artifact where it occurs? > > To be sure, these man pages should be identical for each passwdqc > function but they should not be empty. You can see it in the packaged files from your build, at https://github.com/crd477/passwdqc-cygport/raw/main/passwdqc-2.0.2-1.x86_64/dist/passwdqc/libpasswdqc-devel/libpasswdqc-devel-2.0.2-1.tar.xz > Thanks for reviewing this. I really appreciate it, especially while I'm > still getting familiar with this process. Glad to help, and thank you for getting involved :)
Re: [ITP] passwdqc 2.0.2
On Sat, 22 Oct 2022 at 00:06, Chad Dougherty wrote: > > Hello, > > I'm interested in becoming a package maintainer for passwdqc: > https://www.openwall.com/passwdqc/ > > > > .hint and .cygport files are attached and can also be found here along > with built packages: > https://github.com/crd477/passwdqc-cygport Mostly looks good to me, but I think there are a couple of errors: - etc/passwdqc.conf and usr/share/man/man5/passwdqc.conf.5.gz look to me like they belong in the libpasswdqc0 package - The usr/share/man/man3/passwdqc_* man pages are all empty To be clear, I've not actually tested the function of the package, just the build process and output.
Re: [ITA] lz4
On Sat, 22 Oct 2022 at 21:59, Chad Dougherty wrote:
> I'd like to adopt the lz4 library that is currently listed as orphaned.
>
> I've updated the cygport to the current version, 1.9.4:
> https://github.com/crd477/lz4-cygport
I've not tested the actual compilation, but I have done some test
builds, and this all looks good to me!
> Is it acceptable for me to put these updates into the cygwin git repository?
Once you're listed as a maintainer, yes; up until then, you won't have
permission to write to that repository.
> Also, is it expected that I should also take the
> mingw64-{i686,x86_64}-lz4 packages too?
AIUI that's preferred but not required; they're separate packages, so
it's entirely possible for them to have separate maintainers.
Re: LICENSE values for non-standard OSS licenses
On Fri, 14 Oct 2022 at 17:28, Jon Turney wrote: > > On 11/10/2022 09:37, Adam Dinwoodie wrote: > [... > > ``` > > ERROR: invalid hints git-filter-repo-2.38.0-1-src.hint > > ERROR: package 'git-filter-repo': errors in license expression: ['Unknown > > license key(s): LicenseRef-inherit-git, LicenseRef-inherit-libgit2, > > LicenseRef-inherit-libgit2-examples'] > > ERROR: errors while parsing hints for package 'git-filter-repo' > > ERROR: error parsing /sourceware/cygwin-staging/home/Adam > > Dinwoodie/noarch/release/git-filter-repo/git-filter-repo-2.38.0-1-src.hint > > ERROR: error while reading uploaded arch noarch packages from maintainer > > Adam Dinwoodie > > SUMMARY: 5 ERROR(s) > > ``` > > Sigh. Yeah, this isn't working well and is causing people problems, so > I've changed this validation failure from an error to a warning, for the > moment. > > I might remove it totally, or revise how it works in the future. I definitely appreciate the principle of declaring this sort of thing! The current mechanism might not be working, but I suspect that's mostly an issue of deciding what we're trying to achieve with it, and what options there are for achieving that… > > So it looks like the issue is the way I've encoded the non-standard > > licensing options. "LicenseRef-"(idstring) seems to be the way to > > encode this sort scenario, per [1] and [2], but that doesn't seem to be > > acceptable to calm. > > > > [1]: > > https://spdx.github.io/spdx-spec/v2.3/other-licensing-information-detected/ > > [2]: https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/ > > That says that anything starting "LicenseRef-" can be used to indicate a > license not on the SPDX license list, but I'm not sure where "inherit" > comes from? Does this just have a meaning defined in some other distro > which uses SPDX license expressions? > > Since these expressions containing LicenseRef ids don't have a definite > meaning, perhaps it would just as good for it to be undefined, which is > what omitting it currently indicates. LicenseRef- licenses are, as you say, anything not on the SPDX list; there's no specific definition beyond that. If we were following the full SPDX specifications, rather than just using a small part of them, the license name would – for non SPDX-list licenses – reference the actual license text, so the LicenseRef-whatever string would just be a reference for the user to look up the license text listed as LicenseRef-whatever. "LicenseRef-inherit-git" and the like are values I made up on that basis. If we were providing full SPDX documents, I'd be including a definition of what I meant by "LicenseRef-inherit-git", which would be the relevant extract from https://github.com/newren/git-filter-repo/blob/main/COPYING. I'm not aware of anywhere else using that syntax. > > Are there any suggestions about how to resolve this? I don't think I > > can just use the standard license strings: even if we used GPL-2.0-only > > in place of LicenseRef-inherit-git -- incorrect as that's the license > > *currently* used by Git, but the license for git-filter-repo explicitly > > incorporates any future OSS license Git might use -- that still leaves > > the problem of LicenseRef-inherit-libgit2, which is currently GPL 2.0 > > with an exception that's not covered by any of the SPDX standard > > exceptions. > > > > For now I can just remove the LICENSE values to get the build released, > > but that seems like a temporary approach at best... > > Well, yes, but then "everything is temporary, anyway" :-) Very true!
Re: LICENSE values for non-standard OSS licenses
On Wed, Oct 12, 2022 at 04:28:36PM -0600, Brian Inglis wrote: > On 2022-10-12 18:59 UTC, Adam Dinwoodie wrote: > > On Wed, Oct 12, 2022 at 07:58:56PM +0200, Achim Gratz wrote: > > > Adam Dinwoodie writes: > > > > ERROR: invalid hints git-filter-repo-2.38.0-1-src.hint > > > > ERROR: package 'git-filter-repo': errors in license expression: > > > > ['Unknown license key(s): LicenseRef-inherit-git, > > > > LicenseRef-inherit-libgit2, LicenseRef-inherit-libgit2-examples'] > > > > ERROR: errors while parsing hints for package 'git-filter-repo' > > > > ERROR: error parsing /sourceware/cygwin-staging/home/Adam > > > > Dinwoodie/noarch/release/git-filter-repo/git-filter-repo-2.38.0-1-src.hint > > > > ERROR: error while reading uploaded arch noarch packages from > > > > maintainer Adam Dinwoodie > > > > SUMMARY: 5 ERROR(s) > > > > ``` > > > > So it looks like the issue is the way I've encoded the non-standard > > > > licensing options. "LicenseRef-"(idstring) seems to be the way to > > > > encode this sort scenario, per [1] and [2], but that doesn't seem to be > > > > acceptable to calm. > > > > [1]: > > > > https://spdx.github.io/spdx-spec/v2.3/other-licensing-information-detected/ > > > > [2]: https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/ > > > > As it should, since "inherit-git" or any of the other variations doesn't > > > seem to be a valid license expression per the above. > > > I'm trying to use "LicenseRef-inherit-git" and similar, not just > > "inherit-git", to be clear. > > From > > https://spdx.github.io/spdx-spec/v2.3/other-licensing-information-detected/ > ... > > From https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/ > ... > > > > Both of these seem to say that "LicenseRef-inherit-git" and similar is > > exactly the way to describe a license that isn't covered by the SPDX > > License List, at least unless I'm grossly misunderstanding how > > license-ref is defined in the ABNF and/or what the LICENSE value in the > > cygport file is supposed to store. > > > > > Are there any suggestions about how to resolve this? I don't think I > > > > can just use the standard license strings: even if we used GPL-2.0-only > > > > in place of LicenseRef-inherit-git -- incorrect as that's the license > > > > *currently* used by Git, but the license for git-filter-repo explicitly > > > > incorporates any future OSS license Git might use -- that still leaves > > > > the problem of LicenseRef-inherit-libgit2, which is currently GPL 2.0 > > > > with an exception that's not covered by any of the SPDX standard > > > > exceptions. > > > > Well I think you can, the license explicitely says you can chose any of > > > them as you see fit, so you can pick one today and another tomorrow if > > > you are so inclined. > > > Yes, that's true. I'm not a fan of making decisions for sub-licensees > > that I don't need to make, though; under the same logic, there would be > > no need for the "OR" syntax in SPDX at all... > > AFAICS git uses BSD-3-Clause-Clear, BSL-1.0, GPL-2.0-or-later, > LGPL-2.0-or-later, and MIT, where are the exception and inherit-git/libgit2 > from? > > Does your inherit-git/libgit2 refer to "...under the terms of the 'git' > package..." statements, and is that kind of reference really required, > rather than just taking the reference to be the explicit licences? Yes, exactly. Specifically, the "whatever open source licecense that git.git or libgit2 use now or in future" part. That "now or in future" is a significant bit of license flexibility, IMO, in the same way that "GPLv3" and "GPLv3 or later" are significantly different license terms, even if right now they're effectively identical. As I said before, I can just take Achim's suggestion of exercising my right as a licensee to pick specific licenses from the selection available. But I'd rather not set things up such that folk getting their code via me do so under more restrictive license terms than if they'd obtained the source and/or binaries directly, at least unless there's an overwhelmingly good reason for that. > For custom exceptions, and from SPDX discussion, I think you could use WITH > LicenseRef-cygwin-exception-... or similar wording, whatever is currently > preferred. That's not my reading of the spec. Looking at the ABNF at [0], a license-expression using a "WITH" statem
Re: LICENSE values for non-standard OSS licenses
On Wed, Oct 12, 2022 at 09:45:35AM -0600, Brian Inglis wrote: > On 2022-10-12 9:00 UTC, Adam Dinwoodie wrote:> On Tue, Oct 11, 2022 at > 02:13:00PM -0600, Brian Inglis wrote: > > > On Tue, 11 Oct 2022 09:37:23 +0100, Adam Dinwoodie wrote: > > > > I'm trying to upload a new version of git-filter-repo, and took the > > > > opportunity to set the LICENSE value in the cygport file. The new value > > > > looks valid according to my reading of the SPDX specification, but is > > > > being rejected by calm. > > > > The license for git-filter-repo is a bit complicated, because different > > > > parts have different licenses, and several of them aren't "normal" > > > > licenses. The license is described at [0] and files referenced / linked > > > > from there. > > > > [0]: https://github.com/newren/git-filter-repo/blob/main/COPYING > > > > I've encoded this as the somewhat verbose > > > > LICENSE='(MIT OR LicenseRef-inherit-git OR > > > > LicenseRef-inherit-libgit2) AND (MIT OR LicenseRef-inherit-git OR > > > > LicenseRef-inherit-libgit2 OR LicenseRef-inherit-libgit2-examples) AND > > > > GPL-2.0-only' > > > > The error I'm getting from calm is as follows: > > > > ``` > > > > ERROR: invalid hints git-filter-repo-2.38.0-1-src.hint > > > > ERROR: package 'git-filter-repo': errors in license expression: > > > > ['Unknown license key(s): LicenseRef-inherit-git, > > > > LicenseRef-inherit-libgit2, LicenseRef-inherit-libgit2-examples'] > > > > ERROR: errors while parsing hints for package 'git-filter-repo' > > > > ERROR: error parsing /sourceware/cygwin-staging/home/Adam > > > > Dinwoodie/noarch/release/git-filter-repo/git-filter-repo-2.38.0-1-src.hint > > > > ERROR: error while reading uploaded arch noarch packages from > > > > maintainer Adam Dinwoodie > > > > SUMMARY: 5 ERROR(s) > > > > ``` > > > > So it looks like the issue is the way I've encoded the non-standard > > > > licensing options. "LicenseRef-"(idstring) seems to be the way to > > > > encode this sort scenario, per [1] and [2], but that doesn't seem to be > > > > acceptable to calm. > > > > [1]: > > > > https://spdx.github.io/spdx-spec/v2.3/other-licensing-information-detected/ > > > > [2]: https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/ > > > > Are there any suggestions about how to resolve this? I don't think I > > > > can just use the standard license strings: even if we used GPL-2.0-only > > > > in place of LicenseRef-inherit-git -- incorrect as that's the license > > > > *currently* used by Git, but the license for git-filter-repo explicitly > > > > incorporates any future OSS license Git might use -- that still leaves > > > > the problem of LicenseRef-inherit-libgit2, which is currently GPL 2.0 > > > > with an exception that's not covered by any of the SPDX standard > > > > exceptions. > > > > For now I can just remove the LICENSE values to get the build released, > > > > but that seems like a temporary approach at best... > > As well as SPDX standard script comments e.g "# SPDX-License-Identifier: > ...", the same in a variable LICENSE_SPDX="SPDX-License-Identifier: ...", > and LICENCE_URI="COPYING..." which documents the basis, I've started using > _LICENSE... variables for the different subpackages, which may not be > currently checked, but simplifies using SPDX terms e.g. > <https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/gsasl.git;a=blob;f=gsasl.cygport;hb=refs/heads/playground> I like the theory; I think I'm wary of doing this sort of thing without the blessing of the folk responsible for calm and/or cygport. I'm probably overthinking things, but I'm always worried that coming up with schemes that don't have that sort of official blessing will create another https://xkcd.com/927/ > > > To a similar issue of mine in another thread here (search license) Jon > > > replied calm uses: > > > https://github.com/nexB/license-expression > > > produced by the same project/dev as scancode (which scans a codebase to > > > identify licences as part of project AboutCode), which has registered an > > > SPDX namespace for its own LicenceRefs available at: > > > https://scancode-licensedb.aboutcode.org/ > > > which makes me believe Cygwin should use LicenseRef-scancode-public-domain > > > or as referenced there Licen
Re: LICENSE values for non-standard OSS licenses
On Wed, Oct 12, 2022 at 07:58:56PM +0200, Achim Gratz wrote:
> Adam Dinwoodie writes:
> > ERROR: invalid hints git-filter-repo-2.38.0-1-src.hint
> > ERROR: package 'git-filter-repo': errors in license expression: ['Unknown
> > license key(s): LicenseRef-inherit-git, LicenseRef-inherit-libgit2,
> > LicenseRef-inherit-libgit2-examples']
> > ERROR: errors while parsing hints for package 'git-filter-repo'
> > ERROR: error parsing /sourceware/cygwin-staging/home/Adam
> > Dinwoodie/noarch/release/git-filter-repo/git-filter-repo-2.38.0-1-src.hint
> > ERROR: error while reading uploaded arch noarch packages from maintainer
> > Adam Dinwoodie
> > SUMMARY: 5 ERROR(s)
> > ```
> >
> > So it looks like the issue is the way I've encoded the non-standard
> > licensing options. "LicenseRef-"(idstring) seems to be the way to
> > encode this sort scenario, per [1] and [2], but that doesn't seem to be
> > acceptable to calm.
> >
> > [1]:
> > https://spdx.github.io/spdx-spec/v2.3/other-licensing-information-detected/
> > [2]: https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/
>
> As it should, since "inherit-git" or any of the other variations doesn't
> seem to be a valid license expression per the above.
I'm trying to use "LicenseRef-inherit-git" and similar, not just
"inherit-git", to be clear.
>From
>https://spdx.github.io/spdx-spec/v2.3/other-licensing-information-detected/
> 10 Other licensing information detected section
>
> 10.1 License identifier field
>
> 10.1.1 Description
>
> Provide a locally unique identifier to refer to licenses that are not
> found on the SPDX License List. This unique identifier can then be
> used in the packages, files and snippets sections of the SPDX document
> (Clause 7, Clause 8 and Clause 9, respectively). The metadata for the
> license identifier field is shown in Table 63.
>
> Table 63 — Metadata for the license identifier field
>
> Attribute | Value
> --+
> Required | Conditional
> Cardinality | 0..1 conditional (Mandatory, one) if license is not on
> | SPDX License List.
> Format| `"LicenseRef-"[idstring]` where `[idstring]` is a
> | unique string containing letters, numbers, `.` and/or
> | `-`.
>
> 10.1.2 Intent
>
> Create a human readable short form license identifier for a license
> not on the SPDX License List. This identifier shall be unique within
> the SPDX document. In previous versions of SPDX, the references were
> required to be sequential numbers, but as of version 1.2, creators may
> specify references that are easier for humans to remember and mentally
> map.
>From https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/
> ... A license expression could be a single license identifier found on
> the SPDX License List; a user defined license reference denoted by the
> LicenseRef-[idString]; a license identifier combined with an SPDX
> exception; or some combination of license identifiers, license
> references and exceptions constructed using a small set of defined
> operators (e.g., AND, OR, WITH and +). We provide the definition of
> what constitutes a valid an SPDX License Expression in this section.
>
> The exact syntax of license expressions is described below in ABNF.
>
> idstring = 1*(ALPHA / DIGIT / "-" / "." )
>
> license-id =
>
> license-exception-id = A.2>
>
> license-ref = ["DocumentRef-"(idstring)":"]"LicenseRef-"(idstring)
>
> simple-expression = license-id / license-id"+" / license-ref
>
> compound-expression = (simple-expression /
> simple-expression "WITH" license-exception-id /
> compound-expression "AND" compound-expression /
> compound-expression "OR" compound-expression /
> "(" compound-expression ")" )
>
> license-expression = (simple-expression / compound-expression)
Both of these seem to say that "LicenseRef-inherit-git" and similar is
exactly the way to describe a license that isn't covered by the SPDX
License List, at least unless I'm grossly misunderstanding how
license-ref is defined in the ABNF and/or what the LICENSE value in the
cygport file is supposed to store.
> > Are there any suggestions about how to resolve this? I don't think I
> > can just use the standard license strings: even if we used GPL-2.0-only
> > in place of LicenseRef-inherit-git -- incorrect as that's the license
> > *currently* used by Git, but the license for git-filter-repo explicitly
> &g
Re: LICENSE values for non-standard OSS licenses
On Wed, Oct 12, 2022 at 10:36:02AM +0200, Thomas Wolff wrote: > > > Am 11/10/2022 um 22:13 schrieb Brian Inglis: > > On Tue, 11 Oct 2022 09:37:23 +0100, Adam Dinwoodie wrote: > > > I'm trying to upload a new version of git-filter-repo, and took the > > > opportunity to set the LICENSE value in the cygport file. The new value > > > looks valid according to my reading of the SPDX specification, but is > > > being rejected by calm. > > > The license for git-filter-repo is a bit complicated, because different > > > parts have different licenses, and several of them aren't "normal" > > > licenses. The license is described at [0] and files referenced / linked > > > from there. > > > [0]: https://github.com/newren/git-filter-repo/blob/main/COPYING > > > I've encoded this as the somewhat verbose > > > LICENSE='(MIT OR LicenseRef-inherit-git OR > > > LicenseRef-inherit-libgit2) AND (MIT OR LicenseRef-inherit-git OR > > > LicenseRef-inherit-libgit2 OR LicenseRef-inherit-libgit2-examples) > > > AND GPL-2.0-only' > From a mere Boolean perspective, this looks redundant and should be > simplified to > LICENSE='(MIT OR LicenseRef-inherit-git OR LicenseRef-inherit-libgit2) > AND GPL-2.0-only' Hmm. You're obviously correct from a Boolean logic perspective, but my aim was to provide something more information-rich than a purely Boolean statement. Specifically, each file within the packages produced by this cygport script will be covered by one of the and-joined statements. Some files are GPLv2, some are MIT, "inherit-git" or "inherit-libgit2", and some are MIT, "inherit-git", "inherit-libgit2" or "inherit-libgit2-examples". Removing "inherit-libgit2-examples", as logically simplifying the statement would do, in my mind implies that license isn't at all relevant, even though it does apply to some parts of git-filter-repo. Which version is preferable probably comes down to the intent of the LICENSE value in the cygport file and in the various places that consume that information, either now or in future. If it's intended significantly for human consumption, having the information-rich version may be useful; if it's intended primarily for machine consumption, the simplified version would probably be preferable. >From digging around the SPDX specifications and examples a bit, I think we're already some distance away from the intent of SPDX. If you look at [0], for example, you can see detail is given separately for the source and compiled code, and within each of those, the license information is specified separately for each file. Using a single license string for -- potentially -- multiple packages means we're much more likely to encounter this sort of problem, as it's much more likely that different packages produced by the same cygport file, or different files within each package, are going to be covered by different licenses. [0]: https://github.com/spdx/spdx-examples/tree/master/example4/spdx
Re: LICENSE values for non-standard OSS licenses
On Tue, Oct 11, 2022 at 02:13:00PM -0600, Brian Inglis wrote: > On Tue, 11 Oct 2022 09:37:23 +0100, Adam Dinwoodie wrote: > > I'm trying to upload a new version of git-filter-repo, and took the > > opportunity to set the LICENSE value in the cygport file. The new value > > looks valid according to my reading of the SPDX specification, but is > > being rejected by calm. > > The license for git-filter-repo is a bit complicated, because different > > parts have different licenses, and several of them aren't "normal" > > licenses. The license is described at [0] and files referenced / linked > > from there. > > [0]: https://github.com/newren/git-filter-repo/blob/main/COPYING > > I've encoded this as the somewhat verbose > > LICENSE='(MIT OR LicenseRef-inherit-git OR LicenseRef-inherit-libgit2) > > AND (MIT OR LicenseRef-inherit-git OR LicenseRef-inherit-libgit2 OR > > LicenseRef-inherit-libgit2-examples) AND GPL-2.0-only' > > The error I'm getting from calm is as follows: > > ``` > > ERROR: invalid hints git-filter-repo-2.38.0-1-src.hint > > ERROR: package 'git-filter-repo': errors in license expression: ['Unknown > > license key(s): LicenseRef-inherit-git, LicenseRef-inherit-libgit2, > > LicenseRef-inherit-libgit2-examples'] > > ERROR: errors while parsing hints for package 'git-filter-repo' > > ERROR: error parsing /sourceware/cygwin-staging/home/Adam > > Dinwoodie/noarch/release/git-filter-repo/git-filter-repo-2.38.0-1-src.hint > > ERROR: error while reading uploaded arch noarch packages from maintainer > > Adam Dinwoodie > > SUMMARY: 5 ERROR(s) > > ``` > > So it looks like the issue is the way I've encoded the non-standard > > licensing options. "LicenseRef-"(idstring) seems to be the way to > > encode this sort scenario, per [1] and [2], but that doesn't seem to be > > acceptable to calm. > > [1]: > > https://spdx.github.io/spdx-spec/v2.3/other-licensing-information-detected/ > > [2]: https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/ > > Are there any suggestions about how to resolve this? I don't think I > > can just use the standard license strings: even if we used GPL-2.0-only > > in place of LicenseRef-inherit-git -- incorrect as that's the license > > *currently* used by Git, but the license for git-filter-repo explicitly > > incorporates any future OSS license Git might use -- that still leaves > > the problem of LicenseRef-inherit-libgit2, which is currently GPL 2.0 > > with an exception that's not covered by any of the SPDX standard > > exceptions. > > For now I can just remove the LICENSE values to get the build released, > > but that seems like a temporary approach at best... > > To a similar issue of mine in another thread here (search license) Jon > replied calm uses: > > https://github.com/nexB/license-expression > > produced by the same project/dev as scancode (which scans a codebase to > identify licences as part of project AboutCode), which has registered an > SPDX namespace for its own LicenceRefs available at: > > https://scancode-licensedb.aboutcode.org/ > > which makes me believe Cygwin should use LicenseRef-scancode-public-domain > or as referenced there LicenseRef-PublicDomain, and license-expression > should be able to use the scancode list. I'm not sure I understand your point. Neither LicenseRef-scancode-public-domain nor LicenseRef-PublicDomain look appropriate here, as none of the code has been placed in the public domain. I'm a bit confused about the "Cygwin should use" point, too: are you saying that Cygwin itself should be declared as having a public domain license? I think that's not true, too, per https://cygwin.com/licensing.html
LICENSE values for non-standard OSS licenses
Hullo, I'm trying to upload a new version of git-filter-repo, and took the opportunity to set the LICENSE value in the cygport file. The new value looks valid according to my reading of the SPDX specification, but is being rejected by calm. The license for git-filter-repo is a bit complicated, because different parts have different licenses, and several of them aren't "normal" licenses. The license is described at [0] and files referenced / linked from there. [0]: https://github.com/newren/git-filter-repo/blob/main/COPYING I've encoded this as the somewhat verbose LICENSE='(MIT OR LicenseRef-inherit-git OR LicenseRef-inherit-libgit2) AND (MIT OR LicenseRef-inherit-git OR LicenseRef-inherit-libgit2 OR LicenseRef-inherit-libgit2-examples) AND GPL-2.0-only' The error I'm getting from calm is as follows: ``` ERROR: invalid hints git-filter-repo-2.38.0-1-src.hint ERROR: package 'git-filter-repo': errors in license expression: ['Unknown license key(s): LicenseRef-inherit-git, LicenseRef-inherit-libgit2, LicenseRef-inherit-libgit2-examples'] ERROR: errors while parsing hints for package 'git-filter-repo' ERROR: error parsing /sourceware/cygwin-staging/home/Adam Dinwoodie/noarch/release/git-filter-repo/git-filter-repo-2.38.0-1-src.hint ERROR: error while reading uploaded arch noarch packages from maintainer Adam Dinwoodie SUMMARY: 5 ERROR(s) ``` So it looks like the issue is the way I've encoded the non-standard licensing options. "LicenseRef-"(idstring) seems to be the way to encode this sort scenario, per [1] and [2], but that doesn't seem to be acceptable to calm. [1]: https://spdx.github.io/spdx-spec/v2.3/other-licensing-information-detected/ [2]: https://spdx.github.io/spdx-spec/v2.3/SPDX-license-expressions/ Are there any suggestions about how to resolve this? I don't think I can just use the standard license strings: even if we used GPL-2.0-only in place of LicenseRef-inherit-git -- incorrect as that's the license *currently* used by Git, but the license for git-filter-repo explicitly incorporates any future OSS license Git might use -- that still leaves the problem of LicenseRef-inherit-libgit2, which is currently GPL 2.0 with an exception that's not covered by any of the SPDX standard exceptions. For now I can just remove the LICENSE values to get the build released, but that seems like a temporary approach at best...
Re: Cygwin Git repos refusing push
On Sat, 8 Oct 2022 at 14:12, Jon Turney wrote: > > On 04/10/2022 15:02, Adam Dinwoodie wrote: > [...] > >> > >> I've adjusted the gitolite configuration so this should work again. > > > > Would it be possible to add some output to the hooks to provide a useful > > explanation for what's going on? I think anything a hook prints to > > stdout or stderr will be seen by the user in the `git push` output, and > > something a bit more informative than "DENIED" would be nice! > > This is not totally straightforward, as this hook is part of, and > managed by, gitolite. > > > It's not a big issue either way, but having a more informative output in > > this case might have saved me a bit of time trying to ensure the problem > > was genuinely on the server and not just that I was doing something > > daft. > > Do you have a suggestion as to what else the hook should say? Something to the effect of "This server does not permit pushing to any branch other than 'master' or 'playground'" would have made it clearer what was going on, at least for me. But as I say, if it's difficult to do, it's not a big deal!
Re: [ITP] rsync 3.2.6
On Wed, Oct 05, 2022 at 09:29:08PM -0400, Chad Dougherty wrote: > Hello all, > > I've been using cygwin for a long time but this is my first attempt at this > process so please be gentle :) > > I noticed that the current rsync package (3.2.3+20200903+git9f9240b-4) is > trailing on security updates and also still using the g-b-s method. I pinged > the listed maintainer directly last week asking if they were planning to do > any updates but have not heard back. I hope this was not a faux pas as I > didn't read until later that it's best to raise the issue on the list first. Definitely a faux pas, but it's done now. I definitely made my fair share of errors of etiquette when I first tried packaging things, so I don't think it's worth worrying too much over. Jari isn't very active on the lists these days, but I think he is still active, so he might want to weigh in. > I've attempted to update the port here: > https://github.com/crd477/cygports/tree/main/rsync > > The package files were built by doing: > cygport rsync.cygport prep compile test install package-test > > cygport test reported the following: > ... > > > Here is the reported feature comparison between the existing and updated > packages. This is one area where some things might need to be fixed with > the update. > Existing pacakge: > $ rsync --version > rsync version 3.2.4dev protocol version 31 > Copyright (C) 1996-2020 by Andrew Tridgell, Wayne Davison, and others. > Web site: https://rsync.samba.org/ > Capabilities: > 64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints, > socketpairs, hardlinks, no hardlink-specials, symlinks, IPv6, atimes, > batchfiles, inplace, append, ACLs, xattrs, optional protect-args, iconv, > symtimes, prealloc, stop-at, no crtimes > Optimizations: > no SIMD, asm, openssl-crypto > Checksum list: > xxh128 xxh3 xxh64 (xxhash) md5 md4 none > Compress list: > zstd lz4 zlibx zlib none > > rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you > are welcome to redistribute it under certain conditions. See the GNU > General Public Licence for details. > > Updated package: > $ rsync --version > rsync version 3.2.6 protocol version 31 > Copyright (C) 1996-2022 by Andrew Tridgell, Wayne Davison, and others. > Web site: https://rsync.samba.org/ > Capabilities: > 64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints, > socketpairs, symlinks, symtimes, hardlinks, no hardlink-specials, > hardlink-symlinks, IPv6, atimes, batchfiles, inplace, append, ACLs, > xattrs, optional secluded-args, no iconv, prealloc, stop-at, crtimes > Optimizations: > no SIMD-roll, no asm-roll, openssl-crypto, no asm-MD5 > Checksum list: > xxh128 xxh3 xxh64 (xxhash) md5 md4 none > Compress list: > zstd lz4 zlibx zlib none > > rsync comes with ABSOLUTELY NO WARRANTY. This is free software, and you > are welcome to redistribute it under certain conditions. See the GNU > General Public Licence for details. "no iconv" concerns me; I'm not desperately familiar with how iconv works, but I believe that'll potentially cause issues for rsync users who aren't using ASCII. I'd guess the issue is your build environment is missing a relevant build-time dependency, probably libiconv or libiconv-devel. Otherwise this looks good to my relatively inexpert eyes, and I'd definitely be grateful for this package getting an update! I think we need to give Jari a chance to respond on-list, and see what the folks who have actual authority around maintainership and non-maintainer uploads say. Adam
Re: Cygwin Git repos refusing push
On Tue, Oct 04, 2022 at 01:28:27PM +0100, Jon Turney wrote: > On 04/10/2022 08:55, Adam Dinwoodie wrote: > > There's a hook on the Cygwin Git infrastructure that is refusing to > > accept updated tags for the git package. There's no explanation of why > > the push is being rejected, but this worked four weeks ago when I pushed > > v2.37.3-1, and is failing now. > [...] > > $ git push cygwin v2.38.0-1 > > Enumerating objects: 10, done. > > Counting objects: 100% (10/10), done. > > Delta compression using up to 4 threads > > Compressing objects: 100% (8/8), done. > > Writing objects: 100% (8/8), 762 bytes | 381.00 KiB/s, done. > > Total 8 (delta 6), reused 0 (delta 0), pack-reused 0 > > remote: FATAL: W refs/tags/v2.38.0-1 git/cygwin-packages/git > > Adam_Dinwoodie DENIED by fallthru > > remote: error: hook declined to update refs/tags/v2.38.0-1 > > To cygwin.com:git/cygwin-packages/git.git > > ! [remote rejected] v2.38.0-1 -> v2.38.0-1 (hook declined) > > error: failed to push some refs to > > 'cygwin.com:git/cygwin-packages/git.git' > > > > Is this a bug in the server side hooks, or have I missed some expected > > change in behaviour here? It's not a big deal -- I'm not using the > > Thanks for reporting this. > > A few weeks ago, I made a change to prevent pushes to branches which don't > have a defined role in our scheme (i.e anything not 'master' or > 'playground'), and accidentally prevented tags from being pushed as well. > > I've adjusted the gitolite configuration so this should work again. Would it be possible to add some output to the hooks to provide a useful explanation for what's going on? I think anything a hook prints to stdout or stderr will be seen by the user in the `git push` output, and something a bit more informative than "DENIED" would be nice! It's not a big issue either way, but having a more informative output in this case might have saved me a bit of time trying to ensure the problem was genuinely on the server and not just that I was doing something daft. > In passing, I notice that this repo doesn't have a master branch, only tags, > as that has never been pushed to, which may or may not be what you intended. It's intended; the aim is that folk looking for repositories with packaging code can find them in the common location that's linked from the Cygwin website, but without giving the impression that those are the primary repositories. I'm just using them as a mirror for the actually released code, with the primary repository living on GitHub.
Cygwin Git repos refusing push
There's a hook on the Cygwin Git infrastructure that is refusing to accept updated tags for the git package. There's no explanation of why the push is being rejected, but this worked four weeks ago when I pushed v2.37.3-1, and is failing now. I initially encountered the failure on the GitHub runners, but I see the same behaviour when I attempt to reproduce the behaviour locally: $ git show v2.38.0-1 tag v2.38.0-1 Tagger: me-and Date: Mon Oct 3 22:40:46 2022 + v2.38.0-1 commit 97e2629305827082566bd7d56fc9a0544b4603e7 (tag: v2.38.0-1, origin/next, origin/main, origin/HEAD) Merge: f3e0456 65b7884 Author: Adam Dinwoodie Date: Mon Oct 3 19:18:59 2022 +0100 Merge branch 'v2.38.0' $ git remote -v cygwin https://cygwin.com/git/cygwin-packages/git.git (fetch) cygwin cyg...@cygwin.com:git/cygwin-packages/git.git (push) origin https://github.com/me-and/Cygwin-Git (fetch) origin https://github.com/me-and/Cygwin-Git (push) $ git push cygwin v2.38.0-1 Enumerating objects: 10, done. Counting objects: 100% (10/10), done. Delta compression using up to 4 threads Compressing objects: 100% (8/8), done. Writing objects: 100% (8/8), 762 bytes | 381.00 KiB/s, done. Total 8 (delta 6), reused 0 (delta 0), pack-reused 0 remote: FATAL: W refs/tags/v2.38.0-1 git/cygwin-packages/git Adam_Dinwoodie DENIED by fallthru remote: error: hook declined to update refs/tags/v2.38.0-1 To cygwin.com:git/cygwin-packages/git.git ! [remote rejected] v2.38.0-1 -> v2.38.0-1 (hook declined) error: failed to push some refs to 'cygwin.com:git/cygwin-packages/git.git' Is this a bug in the server side hooks, or have I missed some expected change in behaviour here? It's not a big deal -- I'm not using the Cygwin Git infrastructure for anything other than discoverability, and my working repositories are the ones on GitHub -- but if nothing else I'd like to know if I've inadvertently broken something! Adam
Re: Moving my packaging repos to gitlab
On Thu, 4 Aug 2022 at 11:13, Hamish McIntyre-Bhatty wrote: > I'm considering moving my Cygwin packaging repos over to gitlab, as I > find it easier to organise and use. Are there any potential > problems/lost features from me doing this? Where are your repos currently stored? Personally, I keep repos for all the projects I maintain on GitHub; I mirror them to https://cygwin.com/git-cygwin-packages/ whenever I create a release, in the name of helping other folks find the packaging code, but the repos I actually work with day-to-day are the GitHub ones.
Re: SFTP release directories missing
On Sun, Jul 03, 2022 at 01:31:02PM +0200, Christian Franke wrote:
> Christian Franke wrote:
> > Adam Dinwoodie wrote:
> > > I'm currently seeing attempts to run `cygport stage` fail with
> > > an error "cd: Access failed: No such file (/x86_64/release)". And
> > > logging in manually over sftp, that looks to be accurate; the only
> > > file I can see is my !mail file.
> > >
> > > ```
> > > $ echo $'ls\npwd\n' | sftp cyg...@cygwin.com
> > > Connected to cygwin.com.
> > > sftp> ls
> > > !mail
> > > sftp> pwd
> > > Remote working directory: /
> > > sftp>
> > > ```
> > >
> > > Clearly something has gone wrong with the upload space for my
> > > packages; can someone fix it / tell me what I need to do to fix it?
> >
> > I got the same problem 2x today during upload of pass and etckeeper.
> > Could be fixed by creating the directories manually with mkdir.
> >
>
> Seems to be fixed now. Empty directories {noarch,x86,x86_64}/release
> reappeared in my lftp account.
Confirmed everything looks good for me now too, thank you for checking!
SFTP release directories missing
I'm currently seeing attempts to run `cygport stage` fail with an error "cd: Access failed: No such file (/x86_64/release)". And logging in manually over sftp, that looks to be accurate; the only file I can see is my !mail file. ``` $ echo $'ls\npwd\n' | sftp cyg...@cygwin.com Connected to cygwin.com. sftp> ls !mail sftp> pwd Remote working directory: / sftp> ``` Clearly something has gone wrong with the upload space for my packages; can someone fix it / tell me what I need to do to fix it? Adam
[ITP] rdfind 1.5.0
Hi all, I'd like to publish rdfind. This is already available on, e.g., Debian per https://packages.debian.org/search?keywords=rdfind. It's distributed as GPLv2 or later. Hint file below, and the full release packages from my test build are available at https://github.com/me-and/Cygwin-rdfind/releases/tag/v1.5.0-1-itp category: Utils requires: cygwin libgcc1 libnettle6 libstdc++6 sdesc: "Redundant data finder" ldesc: "Rdfind is a command line tool that finds duplicate files. It is useful for compressing backup directories or just finding duplicate files. It compares files based on their content, NOT on their file names." Adam
Re: [ITP] etckeeper 1.18.17-1
On Wed, Jun 29, 2022 at 09:55:10AM +0200, Christian Franke wrote: > Christian Franke wrote: > > Adam Dinwoodie wrote: > > ... > > > > > I'm also vaguely pondering whether it's worth adding git as a > > > dependency. That's not strictly right, since etckeeper doesn't *need* > > > git, but it's going to be the use case for 99.9% of users, and in the > > > absence of Cygwin having a "recommends" style dependency, just adding > > > git seems like it might be sensible. But I'm far from convinced there. > > > > I'm also not sure and decided to add no git dependency. 99.8% of the > > users considering to install etckeeper may already have git installed > > :-) > > > > The Debian package does not use "rec" but "dep (git or hg or brz or > > darcs)" which defaults to git. > > If git is installed, the Debian postinst script runs 'etckeeper init && > > etckeeper commit' on fresh installs. I decided to leave this to the > > user. > > > > A possible simple extension which would allow the user to choose between > manual or automatic installation+initialization: > > Provide an optional package, for example "etckeeper-git-init", which depends > on etckeeper+git and only contains /etc/postinstall/etckeeper-git-init.sh > which triggers new initialization code in > /etc/postinstall/zp_zzz_etckeeper-postinstall.sh via some file in > /var/cache/etckeeper. This code performs 'etckeeper init && etckeeper > commit' if and only if VCS=git is selected and /etc/.git does not exist. Honestly, I suspect it's not worth the effort of doing things like that. As you say, 99.8% of users who might be interested in using etckeeper are going to be people who already have a good idea what they're doing and will be able to work it out for themselves. Thinking about it some more, I'm also mildly concerned about the small but non-trivial proportion of users who blithely install every package available on Cygwin, which I don't think is going to be an issue for more-or-less any other *nix distribution. I don't normally think it's worth doing much to actively catering for those users -- I'm generally of the opinion that they're making their own misery -- but in this case automatically starting etckeeper would be a potentially significant impact, and for the sake of both their lives and yours, I suspect it's best to just leave etckeeper as something that requires manual initiation. That said, if you're keen to set up that optional package, I definitely don't think it's a bad idea; "it wouldn't be worth the effort to me" doesn't mean you shouldn't do it!
Re: [ITP] etckeeper 1.18.17-1
On Tue, Jun 28, 2022 at 12:58:23PM +0200, Christian Franke wrote: > I would like to contribute etckeeper. > > https://etckeeper.branchable.com/ > https://repology.org/project/etckeeper/versions > > etckeeper-1.18.17-1.hint: > category: Utils > requires: bash coreutils grep sed > sdesc: "Store /etc in git or mercurial" > ldesc: "Etckeeper is a tool to let /etc be stored in git or > mercurial. It hooks into Cygwin Setup to automatically commit changes > made to /etc during package upgrades. It tracks file metadata > (permissions, owner, group) that version control systems do not > normally support." > > Package for review: > wget -r -nH --cut-dirs=2 \ > https://chrfranke.de/cygwin/noarch/etckeeper/etckeeper-1.18.17-1.hint \ > https://chrfranke.de/cygwin/noarch/etckeeper/etckeeper-1.18.17-1-src.hint \ > https://chrfranke.de/cygwin/noarch/etckeeper/etckeeper-1.18.17-1-src.tar.xz > \ > https://chrfranke.de/cygwin/noarch/etckeeper/etckeeper-1.18.17-1.tar.xz \ > https://chrfranke.de/cygwin/noarch/etckeeper/etckeeper-1.18.17-1.sha256 > > Tested with git. Only a few tests were done with hg. LGTM! I've not tested the actual function, but the packaging looks sound, and I trust etckeeper enough that if the packaging is sound I'm happy the rest will follow :) I do wonder if it's worth trying to submit your patches upstream; they seem like the sort of thing the upstream project might be interested in taking, and it minimises the amount of work you have to do as a maintainer. I'm also vaguely pondering whether it's worth adding git as a dependency. That's not strictly right, since etckeeper doesn't *need* git, but it's going to be the use case for 99.9% of users, and in the absence of Cygwin having a "recommends" style dependency, just adding git seems like it might be sensible. But I'm far from convinced there. Adam
[ITP] git-filter-repo
Given packaging git-filter-repo has stalled, and Jon Turney has solicited new ITPs, I've taken the work James Morris did earlier this year and finished things off. Source and binary packages, plus hint files, are available at https://github.com/me-and/Cygwin-git-filter-repo/releases/tag/v2.34.0-1-draft Adam
Re: [ANNOUNCEMENT] cygport 0.35.0-1
On Mon, May 02, 2022 at 09:51:21PM +0100, Jon Turney wrote: > The following packages have been uploaded to the Cygwin distribution: > > * cygport-0.35.0-1 > > cygport is the standard method for building and maintaining > packages for the Cygwin distribution. > > Highlights of this release: > > * New subcommands 'vars' and 'srcpackage' Just wanted to say: this vars command is going to be *super* useful for some of my build automation, thank you!
[PATCH cygport v3] autotools.cygclass: correctly detect Autoconf 2.70+
The latest version of Autoconf is 2.71, but the version detection
incorrectly considers 2.70 and higher as being the same as 2.59 and
lower for the purposes of specifying documentation directories. Correct
that, and make the version detection a bit more future-proof by parsing
out the actual version parts and performing numeric comparison.
While we're at it, add a bit more commentary explaining the intent of
the different behaviour over the different Autoconf versions.
---
Interdiff against v2:
diff --git a/cygclass/autotools.cygclass b/cygclass/autotools.cygclass
index 38ac8f0..b40828b 100644
--- a/cygclass/autotools.cygclass
+++ b/cygclass/autotools.cygclass
@@ -652,7 +652,7 @@ cygconf() {
fi
configure="${confdir}/configure"
- confver=$(grep -m 1 'GNU Autoconf' ${configure} | cut -d ' ' -f 6)
+ confver="$("$configure" --version | sed -rn 's/.*GNU Autoconf
([0-9\.]+)/\1/p')"
confver_maj=${confver%%.*}
confver_min=${confver##*.}
if [ $confver_maj -ne 2 ]
cygclass/autotools.cygclass | 40 ++---
1 file changed, 28 insertions(+), 12 deletions(-)
diff --git a/cygclass/autotools.cygclass b/cygclass/autotools.cygclass
index cce9be0..b40828b 100644
--- a/cygclass/autotools.cygclass
+++ b/cygclass/autotools.cygclass
@@ -619,6 +619,8 @@ cygconf() {
local confdir;
local configure;
local confver;
+ local confver_maj;
+ local confver_min;
local f;
local foo_config;
local prefix;
@@ -650,7 +652,13 @@ cygconf() {
fi
configure="${confdir}/configure"
- confver=$(grep -m 1 'GNU Autoconf' ${configure} | cut -d ' ' -f 6)
+ confver="$("$configure" --version | sed -rn 's/.*GNU Autoconf
([0-9\.]+)/\1/p')"
+ confver_maj=${confver%%.*}
+ confver_min=${confver##*.}
+ if [ $confver_maj -ne 2 ]
+ then
+ error "unexpected autoconf version";
+ fi
# AC_CONFIG_FILES should not be dist'ed, but it sometimes happens anyway
eval $(grep -h '^ac_config_files=' ${configure})
@@ -678,18 +686,26 @@ cygconf() {
confargs+=" --libdir=${prefix}/${MULTILIB_LIBDIR}"
fi
- case "x${confver}" in
- x2.6[0-9]*)
- confargs+=" --docdir=/usr/share/doc/${PN}
--htmldir=/usr/share/doc/${PN}/html"
- ;;
- *)
- confargs+=" --infodir=${prefix}/share/info
--mandir=${prefix}/share/man"
- ;;
- esac
+ if [ $confver_min -ge 60 ]
+ then
+ # Autoconf version supports --docdir and --htmldir, which will
+ # need to be specified manually. It also supports --infodir
+ # and --mandir, but the defaults for those match the FHS.
+ confargs+=" --docdir=/usr/share/doc/${PN}
--htmldir=/usr/share/doc/${PN}/html"
+ else
+ # Autoconf version does not support --docdir or --htmldir, so
+ # don't specify those. Set --infodir and --mandir, as those
+ # have defaults that don't match the FHS.
+ confargs+=" --infodir=${prefix}/share/info
--mandir=${prefix}/share/man"
+ fi
- case "x${confver}" in
- x2.[5-9]*) confargs+=" -C" ;;
- esac
+
+ if [ $confver_min -ge 50 ]
+ then
+ # Always use a cache file; prior to 2.50, this was the default,
+ # thereafter it needs to be requested explicitly.
+ confargs+=" -C"
+ fi
if cross_compiling || inherited toolchain
then
--
2.35.1
Re: [PATCH cygport v2] autotools.cygclass: correctly detect Autoconf 2.70+
On Mon, Mar 14, 2022 at 07:05:20PM +, Jon Turney wrote:
> On 13/03/2022 20:44, Adam Dinwoodie wrote:
> > configure="${confdir}/configure"
> > confver=$(grep -m 1 'GNU Autoconf' ${configure} | cut -d ' ' -f 6)
> > + confver_maj=${confver%%.*}
> > + confver_min=${confver##*.}
> > + if [ $confver_maj -ne 2 ]
> > + then
> > + error "unexpected autoconf version";
> > + fi
> > # AC_CONFIG_FILES should not be dist'ed, but it sometimes happens anyway
> > eval $(grep -h '^ac_config_files=' ${configure})
>
> When I test this locally, it fails, as (note the full stop at the end of the
> line):
>
> > $ grep -m1 Autoconf configure
> > # Generated by GNU Autoconf 2.71.
Huh. Apparently that string has a less consistent format than I'd
assumed; I'd tested that line against the configure script for Git, but
that gets different behaviour:
$ grep -m1 Autoconf git-2.35.1-2.x86_64/build/configure
# Generated by GNU Autoconf 2.71 for git 2.35.1.
I'll try to come up with something a bit less fragile...
[PATCH cygport v2] autotools.cygclass: correctly detect Autoconf 2.70+
The latest version of Autoconf is 2.71, but the version detection
incorrectly considers 2.70 and higher as being the same as 2.59 and
lower for the purposes of specifying documentation directories. Correct
that, and make the version detection a bit more future-proof by parsing
out the actual version parts and performing numeric comparison.
While we're at it, add a bit more commentary explaining the intent of
the different behaviour over the different Autoconf versions.
---
Interdiff against v1:
diff --git a/cygclass/autotools.cygclass b/cygclass/autotools.cygclass
index 2ab5626..38ac8f0 100644
--- a/cygclass/autotools.cygclass
+++ b/cygclass/autotools.cygclass
@@ -655,6 +655,10 @@ cygconf() {
confver=$(grep -m 1 'GNU Autoconf' ${configure} | cut -d ' ' -f 6)
confver_maj=${confver%%.*}
confver_min=${confver##*.}
+ if [ $confver_maj -ne 2 ]
+ then
+ error "unexpected autoconf version";
+ fi
# AC_CONFIG_FILES should not be dist'ed, but it sometimes happens anyway
eval $(grep -h '^ac_config_files=' ${configure})
@@ -682,7 +686,7 @@ cygconf() {
confargs+=" --libdir=${prefix}/${MULTILIB_LIBDIR}"
fi
- if [ $confver_maj -ge 2 -a $confver_min -ge 60 ] || [ $confver_maj -ge
3 ]
+ if [ $confver_min -ge 60 ]
then
# Autoconf version supports --docdir and --htmldir, which will
# need to be specified manually. It also supports --infodir
@@ -696,7 +700,7 @@ cygconf() {
fi
- if [ $confver_maj -ge 2 -a $confver_min -ge 50 ] || [ $confver_maj -ge
3 ]
+ if [ $confver_min -ge 50 ]
then
# Always use a cache file; prior to 2.50, this was the default,
# thereafter it needs to be requested explicitly.
cygclass/autotools.cygclass | 38 ++---
1 file changed, 27 insertions(+), 11 deletions(-)
diff --git a/cygclass/autotools.cygclass b/cygclass/autotools.cygclass
index cce9be0..38ac8f0 100644
--- a/cygclass/autotools.cygclass
+++ b/cygclass/autotools.cygclass
@@ -619,6 +619,8 @@ cygconf() {
local confdir;
local configure;
local confver;
+ local confver_maj;
+ local confver_min;
local f;
local foo_config;
local prefix;
@@ -651,6 +653,12 @@ cygconf() {
configure="${confdir}/configure"
confver=$(grep -m 1 'GNU Autoconf' ${configure} | cut -d ' ' -f 6)
+ confver_maj=${confver%%.*}
+ confver_min=${confver##*.}
+ if [ $confver_maj -ne 2 ]
+ then
+ error "unexpected autoconf version";
+ fi
# AC_CONFIG_FILES should not be dist'ed, but it sometimes happens anyway
eval $(grep -h '^ac_config_files=' ${configure})
@@ -678,18 +686,26 @@ cygconf() {
confargs+=" --libdir=${prefix}/${MULTILIB_LIBDIR}"
fi
- case "x${confver}" in
- x2.6[0-9]*)
- confargs+=" --docdir=/usr/share/doc/${PN}
--htmldir=/usr/share/doc/${PN}/html"
- ;;
- *)
- confargs+=" --infodir=${prefix}/share/info
--mandir=${prefix}/share/man"
- ;;
- esac
+ if [ $confver_min -ge 60 ]
+ then
+ # Autoconf version supports --docdir and --htmldir, which will
+ # need to be specified manually. It also supports --infodir
+ # and --mandir, but the defaults for those match the FHS.
+ confargs+=" --docdir=/usr/share/doc/${PN}
--htmldir=/usr/share/doc/${PN}/html"
+ else
+ # Autoconf version does not support --docdir or --htmldir, so
+ # don't specify those. Set --infodir and --mandir, as those
+ # have defaults that don't match the FHS.
+ confargs+=" --infodir=${prefix}/share/info
--mandir=${prefix}/share/man"
+ fi
- case "x${confver}" in
- x2.[5-9]*) confargs+=" -C" ;;
- esac
+
+ if [ $confver_min -ge 50 ]
+ then
+ # Always use a cache file; prior to 2.50, this was the default,
+ # thereafter it needs to be requested explicitly.
+ confargs+=" -C"
+ fi
if cross_compiling || inherited toolchain
then
--
2.35.1
Re: [PATCH cygport] autotools.cygclass: correctly detect Autoconf 2.70+
On Sat, Mar 12, 2022 at 01:02:39PM +, Jon Turney wrote:
> On 11/03/2022 22:40, Adam Dinwoodie wrote:
> > - case "x${confver}" in
> > - x2.6[0-9]*)
> > - confargs+=" --docdir=/usr/share/doc/${PN}
> > --htmldir=/usr/share/doc/${PN}/html"
> > - ;;
> > - *)
> > - confargs+=" --infodir=${prefix}/share/info
> > --mandir=${prefix}/share/man"
> > - ;;
> > - esac
> > + if [ $confver_maj -ge 2 -a $confver_min -ge 60 ] || [ $confver_maj -ge
> > 3 ]
>
> Great. Thanks.
>
> I think it would be acceptable to error on autoconf >=3.0, rather than
> assuming it's going to be autoconf 2.6+ compatible.
No problem, I'll respin now. I'd thought about doing exactly that, but
the current code looked like it was designed to assume things would be
fine unless there was a specific reason to bail out, so I tried to
follow that paradigm rather than bail out when there was no known reason
for doing so.
[PATCH cygport] autotools.cygclass: correctly detect Autoconf 2.70+
The latest version of Autoconf is 2.71, but the version detection
incorrectly considers 2.70 and higher as being the same as 2.59 and
lower for the purposes of specifying documentation directories. Correct
that, and make the version detection a bit more future-proof by parsing
out the actual version parts and performing numeric comparison.
While we're at it, add a bit more commentary explaining the intent of
the different behaviour over the different Autoconf versions.
---
cygclass/autotools.cygclass | 34 +++---
1 file changed, 23 insertions(+), 11 deletions(-)
diff --git a/cygclass/autotools.cygclass b/cygclass/autotools.cygclass
index cce9be0..2ab5626 100644
--- a/cygclass/autotools.cygclass
+++ b/cygclass/autotools.cygclass
@@ -619,6 +619,8 @@ cygconf() {
local confdir;
local configure;
local confver;
+ local confver_maj;
+ local confver_min;
local f;
local foo_config;
local prefix;
@@ -651,6 +653,8 @@ cygconf() {
configure="${confdir}/configure"
confver=$(grep -m 1 'GNU Autoconf' ${configure} | cut -d ' ' -f 6)
+ confver_maj=${confver%%.*}
+ confver_min=${confver##*.}
# AC_CONFIG_FILES should not be dist'ed, but it sometimes happens anyway
eval $(grep -h '^ac_config_files=' ${configure})
@@ -678,18 +682,26 @@ cygconf() {
confargs+=" --libdir=${prefix}/${MULTILIB_LIBDIR}"
fi
- case "x${confver}" in
- x2.6[0-9]*)
- confargs+=" --docdir=/usr/share/doc/${PN}
--htmldir=/usr/share/doc/${PN}/html"
- ;;
- *)
- confargs+=" --infodir=${prefix}/share/info
--mandir=${prefix}/share/man"
- ;;
- esac
+ if [ $confver_maj -ge 2 -a $confver_min -ge 60 ] || [ $confver_maj -ge
3 ]
+ then
+ # Autoconf version supports --docdir and --htmldir, which will
+ # need to be specified manually. It also supports --infodir
+ # and --mandir, but the defaults for those match the FHS.
+ confargs+=" --docdir=/usr/share/doc/${PN}
--htmldir=/usr/share/doc/${PN}/html"
+ else
+ # Autoconf version does not support --docdir or --htmldir, so
+ # don't specify those. Set --infodir and --mandir, as those
+ # have defaults that don't match the FHS.
+ confargs+=" --infodir=${prefix}/share/info
--mandir=${prefix}/share/man"
+ fi
- case "x${confver}" in
- x2.[5-9]*) confargs+=" -C" ;;
- esac
+
+ if [ $confver_maj -ge 2 -a $confver_min -ge 50 ] || [ $confver_maj -ge
3 ]
+ then
+ # Always use a cache file; prior to 2.50, this was the default,
+ # thereafter it needs to be requested explicitly.
+ confargs+=" -C"
+ fi
if cross_compiling || inherited toolchain
then
--
2.35.1
Re: [ITP] git-filter-repo 2.34.0
On Tue, Mar 08, 2022 at 03:42:13PM -0500, James Morris wrote: > Hi Adam, > > Thanks for the feedback! > > > - You've patched the shebang from `/usr/bin/env python3` to > > `/usr/bin/python3`. To what end? /usr/bin/env is part of coreutils > > for Cygwin, so there shouldn't be any risk that it won't be installed. > > If someone has their own compiled python3 in /usr/local/bin, they'd > > probably expect that to be used, so I don't think I'd change the > > shebang unless there's some clear and specific reason for doing so. > > I am trying to prevent exactly what you described. git-filter-repo > needs Python >=3.5 to function and we know that `/usr/bin/python3` is > the correct version. Suppose a user installed Python 3.3 at > `/usr/local/bin/python3`, now git-filter-repo will run with the wrong > Python version and most likely break. This is what other distributions > do when they distribute Python scripts and I'm fairly sure Debian > explicitly calls this out in its policy. I just went and did an entirely unscientific check of the scripts I have installed in my Cygwin /bin/ directory. It looks like there's no great consistency, but the majority of scripts there (20 to 9) are calling the relevant Python interpreter directly rather than relying on env. Personally, I'd probably not bother changing things from the upstream package, but if you'd rather do things this way I'm not going to argue :) > > - You're changing the shebang with both a patch file and with a line in > > src_compile; you don't need to do both! I suspect this is an artefact > > of how Cygport packages the source files, but AIUI the canonical way > > to do this sort of patching with Cygport is to drop the sed line from > > your .cygport file and just keep the patch file that gets generated. > > Yeah the patch file was automatically generated when I ran `cygport > all` and I wasn't sure what to do with it. To me it seems silly to > have a patch just to change the shebang line when `sed` works fine. > I'll try removing `sed` to see what happens. Cygport automatically generates patches when it detects a difference between the "src" and "origsrc" directories. You're changing something in "src", so the patch gets generated. The idea is that you can adjust things in the src directory by hand, then when you run cygport it'll automatically store the diffs so you never need to make the same changes again. I suspect the best solution here would be to either (a) drop the sed line and just use a patch file, or (b) make the change in the inst directory as part of the `src_install` function in the .cygport file, i.e. fixing it up as part of doing the "installation" step rather than the "compilation" step. But the sed command is idempotent, so while having both is redundant and a bit odd, I don't think it does any harm. > > - You've set the category as both Devel and Python. IMO (I've not > > checked what the general consensus on this is) this shouldn't be in > > Python: it's a tool that happens to use Python, but I'd expect the > > Python category to be for things that are specifically useful to > > people doing Python dev, so things like libraries that can be usefully > > imported in a Python module, or tools for debugging Python scripts. I > > think this should only be in the Devel category. > > Yeah I initially didn't have it in the Python category, but then I > thought about how other tools like bzr and mercurial are there so it > seemed appropriate. Granted I didn't check if they also provided > Python libraries, but I thought it made sense to put git-filter-repo > in the Python category to maybe warn users that installing it would > pull in Python. I've just checked both bzr and mercurial, and they definitely do provide Python packages. I don't think it's necessary to warn users about dependencies by using categories; setup provides those warnings already when it does dependency resolution. > > - That said, I think ideally you'd also be packaging git_filter_repo.py, > > which does provide a Python library that users can import. At that > > point, this would unambiguously belong in both categories. > > I wasn't sure how to go about this since I didn't know if that would > mean making a bunch of 'python3*-git-filter-repo' packages. > Do you think I should make it importable, remove it from the Python > category, or just leave it as is? My preference here would be to make it importable. That's not going to be something many people are interested in, but there's no reason not to. It can still be a single package -- as bzr and mercurial are -- providing both the main executable and the Python libraries. There's obviously a balance here: monolith packages that add a bunch of dependencies or eat a bunch of disk space / bandwidth, to provide functions many users won't care about, are clearly a bad idea. But the cost of having both the Python module and the executable in this package is going to
Re: Cygport configure script argument handling
On Fri, Mar 11, 2022 at 12:38:47AM -0500, Yaakov Selkowitz wrote:
> On Thu, 2022-03-10 at 16:41 +0000, Adam Dinwoodie wrote:
> > I've fallen down a slight rabbit hole looking at the cygconf function in
> > Cygport's autotools.cygclass. The specific bit of code that's causing
> > me consternation is thus:
> >
> > case "x${confver}" in
> > x2.6[0-9]*)
> > confargs+=" --docdir=/usr/share/doc/${PN}
> > --htmldir=/usr/share/doc/${PN}/html"
> > ;;
> > *)
> > confargs+=" --infodir=${prefix}/share/info
> > --mandir=${prefix}/share/man"
> > ;;
> > esac
> >
> > Firstly, I think the glob is incorrect: it looks like it was intended to
> > match files that came from Autoconf versions 2.60 and up -- 2.60 is when
> > Autoconf added the docdir and htmldir arguments -- but it has stopped
> > working as expected: Autoconf released 2.70 in December 2020, and is now
> > up to 2.71. The above code won't match those versions.
>
> Yes, this likely needs to be updated for 2.70+.
Grand, I'll see if I can offer a patch shortly :)
> > Secondly -- and I'm not sure if this is intended or not -- I don't
> > understand why --infodir and --mandir are only defined for versions
> > prior to 2.60 (and, apparently unintentionally, 2.70 onwards). Those
> > are valid both before and after 2.60. My best guess is that the intent
> > was for the first option to fall through to the second, so for 2.60+ all
> > four options would be defined, but that would have required `;&` or
> > `;;&` rather than `;;`.
>
> No. 2.60 included changes for these (and other) directory values:
>
> https://lists.gnu.org/archive/html/autotools-announce/2006-06/msg2.html
>
> docdir and htmldir were added in 2.60, hence we don't want to pass them when
> <=2.59 is detected. infodir and mandir were changed in 2.60, from
> $prefix/{info,man} (which cygport needed to override for FHS compliance) to
> $datarootdir/{info,man}, where the new datarootdir is $prefix/share, meaning
> they no longer needed to be overriden by cygport.
Ah! Yes, that makes sense. Thank you for the explanation!
Adam
Cygport configure script argument handling
I've fallen down a slight rabbit hole looking at the cygconf function in
Cygport's autotools.cygclass. The specific bit of code that's causing
me consternation is thus:
case "x${confver}" in
x2.6[0-9]*)
confargs+=" --docdir=/usr/share/doc/${PN}
--htmldir=/usr/share/doc/${PN}/html"
;;
*)
confargs+=" --infodir=${prefix}/share/info
--mandir=${prefix}/share/man"
;;
esac
Firstly, I think the glob is incorrect: it looks like it was intended to
match files that came from Autoconf versions 2.60 and up -- 2.60 is when
Autoconf added the docdir and htmldir arguments -- but it has stopped
working as expected: Autoconf released 2.70 in December 2020, and is now
up to 2.71. The above code won't match those versions.
Secondly -- and I'm not sure if this is intended or not -- I don't
understand why --infodir and --mandir are only defined for versions
prior to 2.60 (and, apparently unintentionally, 2.70 onwards). Those
are valid both before and after 2.60. My best guess is that the intent
was for the first option to fall through to the second, so for 2.60+ all
four options would be defined, but that would have required `;&` or
`;;&` rather than `;;`.
Can anyone explain what the intent of this code is? Are these both the
bugs that I think they are, or am I missing the intent?
Re: [ITP] git-filter-repo 2.34.0
On Mon, Mar 07, 2022 at 07:11:24PM -0500, James Morris wrote: > Hello, > > I'd like to maintain the package for git-filter-repo, a Python script > to quickly edit git history. It's MIT licensed, available in both > Debian and Fedora, and I've also just recently packaged > git-filter-repo up for MSYS2. Oh excellent! I've been thinking about doing this myself, but I'm very happy for someone else to do the work! > Cygport package files can be found here: > https://drive.google.com/drive/folders/12RXG0804TmR9ZF2STpV7LXqpJMucYAfx?usp=sharing A few thoughts from me before I think this is good to go: - You've patched the shebang from `/usr/bin/env python3` to `/usr/bin/python3`. To what end? /usr/bin/env is part of coreutils for Cygwin, so there shouldn't be any risk that it won't be installed. If someone has their own compiled python3 in /usr/local/bin, they'd probably expect that to be used, so I don't think I'd change the shebang unless there's some clear and specific reason for doing so. - You're changing the shebang with both a patch file and with a line in src_compile; you don't need to do both! I suspect this is an artefact of how Cygport packages the source files, but AIUI the canonical way to do this sort of patching with Cygport is to drop the sed line from your .cygport file and just keep the patch file that gets generated. - You've set the category as both Devel and Python. IMO (I've not checked what the general consensus on this is) this shouldn't be in Python: it's a tool that happens to use Python, but I'd expect the Python category to be for things that are specifically useful to people doing Python dev, so things like libraries that can be usefully imported in a Python module, or tools for debugging Python scripts. I think this should only be in the Devel category. - That said, I think ideally you'd also be packaging git_filter_repo.py, which does provide a Python library that users can import. At that point, this would unambiguously belong in both categories. - You're installing the main script into /usr/bin. I think the executable should probably be installed into /usr/libexec/git-core, along with other Git executables. This is what `git --exec-path` returns, and matches what's described in INSTALL.md. More generally, I think you should be emulating one of the installation mechanisms in INSTALL.md, either using the provided makefile, or following the described steps in the "Manual Installation" section of that doc. - Currently Cygport can't run the test suite. Ideally it'd be able to; it seems unlikely that there would be Cygwin-specific regressions in this code, but it's not out of the question, and given upstream provide a test suite, it seems a shame to not use it. That all said, this is clearly very close to ready to ship, and as I say, it'll definitely be useful once it's available. Thank you! Adam
State of github.com/cygwinports
There's a GitHub organisation at https://github.com/cygwinports that looks to have been largely abandoned; there doesn't seem to have been any meaningful activity there since at least July 2019, and the link in the top bar has clearly been taken over by domain squatters. I think the purpose of that organisation is now entirely served by the Git repos hosted at https://cygwin.com/git/, and clearly nobody is using it. Should someone (I guess Yaakov, as the organization owner) officially consign the organization to history and delete it? I do think it would be nice to have a GitHub organization to hold Cygwin packaging paraphernalia, which maintainers could ignore, or use as a mirror to or from the Cygwin-hosted repos, as they prefer. I'm happy to set that up and organize it myself, but I expect it'll be simpler to manage starting from a clean slate. Adam PS: it turns out that getting appropriate medical treatment for something you had no idea wasn't normal for 30 years makes it much easier to get stuff done! Hence the flurry of activity, as I catch up with around a decade of wishlist / "wouldn't it be nice if" things I'd never quite had the time and energy to get to...
Re: calm: cygwin package upload report for Pierre A. Humblet
On Wed, Feb 09, 2022 at 08:34:16AM -0500, Pierre A. Humblet wrote: > On 2/8/2022 4:11 PM, cygwin-apps@cygwin.com wrote: > > WARNING: copying 'exim-4.95-1.hint' to 'exim-4.95-1-src.hint' > > INFO: srcpkg exim-4.95-1-src.tar.xz contains 0 .cygport files > > INFO: cannot determine homepage: from srcpkg exim-4.95-1-src.tar.xz > > ERROR: package 'exim': required key 'homepage' missing > > ERROR: errors while parsing hints for package 'exim' > > ERROR: error parsing /sourceware/cygwin-staging/home/Pierre A. > > Humblet/x86_64/release/exim/exim-4.95-1-src.hint > > ERROR: error while reading uploaded arch x86_64 packages from maintainer > > Pierre A. Humblet > > SUMMARY: 1 WARNING(s), 2 INFO(s), 4 ERROR(s) > > Exim is a legacy package not relying on cygport. > > Looks like calm is not happy with that. > > Can it be convinced to accept it, like it used to? The note that there's no cygport file is only marked as "INFO"; the error appears to be that there's no homepage listed in the .hint file. I don't know what you're doing to generate the .hint files without cygport -- all the packages I maintain use cygport -- but I expect you just need to update whatever your process is to add the homepage. Adam
Orphaning fzf
The upstream fzf package moved from Ruby to Go some time ago. I had vague but noble intetions to try to maintain a fork on the basis of the last version of the Ruby code, but never managed anything useful. In that context, I expect it's time that I officially throw in the towel, and mark fzf as orphaned. The existing build still works, and I don't think there's likely to be any crass security problems or anything like that. But there's no longer any upstream support, and I clearly don't have the capacity to properly maintain it solo. I'm not quite sure what the process is here, but I suspect it's just a case of someone with the appropriate access making an update to https://cygwin.com/cygwin-pkg-maint Adam
Re: [PATCH setup] Show a MessageBox warning if running on a deprecated Windows version
On Fri, Jan 14, 2022 at 12:45:06PM +0100, Corinna Vinschen wrote: > On Jan 14 10:54, Adam Dinwoodie wrote: > > On Fri, 14 Jan 2022 at 09:05, Corinna Vinschen wrote: > > > On Jan 13 15:13, Jon Turney wrote: > > > > Show a MessageBox warning if we are running on a Windows version which > > > > we have deprecated Cygwin support for: > > > > > > > > - Windows 6.0 (Windows Vista, Windows Server 2008) > > > > - 32-bit Windows > > > > > > > > This warning can be disabled with '--allow-unsupported-windows'. > > > > --- > > > > > > > > Notes: > > > > Not sure if this is needed, or maybe this is just annoying to the > > > > ~3% of > > > > users who are running effected OSes. But maybe we want to annoy > > > > them > > > > into doing something about it? > > > > > > Question is, how often should setup show this message? Every time might > > > really be a bit annoying. Some kind of "I saw it, now leave me alone, > > > at least for a while" kind of function would be great. > > > > Eh. The installer tries to add icons to my desktop every time I run it > > unless I provide a command-line argument every time. This behaviour > > seems no more or less annoying to me, and I think having users see > > that warning is much more important than adding a desktop icon. > > Point. Perhaps more constructively: I've become inured to the bits of setup's behaviour that I find annoying, and I've created my own workarounds (specifically, a bash function that wraps setup and automatically provides a bunch of arguments, including `-d` to avoid adding icons I don't want). I expect most people who are using setup have also become inured to these annoyances, and I don't think adding this additional warning is a significant additional annoyance. That said, just because I've become inured to these annoyances, doesn't mean we* couldn't do better. In particular, I think a lot of the parts of the setup UI you have to go through every time could more usefully be hidden after a user has gone through them once, and only displayed again if (a) the user requested that with a command-line option, (b) the options have legitimately changed, or possibly (c) the user clicks (say) an "Advanced mode" button on the first page of the installer. In particular, I expect the installer would be that bit friendlier to most users if the default behaviour were as if `-Mn` were specified by default every time after the first run. This is obviously well outside the scope of the immediate conversation, but I thought it worth revisiting the topic with a more constructive view, rather than my initial slightly grumpy reaction. Adam * I say "we" here; I sadly do not have the bandwidth for committing to working on even small enhancements to setup's usability. The perennial open source issue: someone has to do it, and I have far too many other things to spend time on...
Re: [PATCH setup] Show a MessageBox warning if running on a deprecated Windows version
On Fri, 14 Jan 2022 at 09:05, Corinna Vinschen wrote: > On Jan 13 15:13, Jon Turney wrote: > > Show a MessageBox warning if we are running on a Windows version which > > we have deprecated Cygwin support for: > > > > - Windows 6.0 (Windows Vista, Windows Server 2008) > > - 32-bit Windows > > > > This warning can be disabled with '--allow-unsupported-windows'. > > --- > > > > Notes: > > Not sure if this is needed, or maybe this is just annoying to the ~3% of > > users who are running effected OSes. But maybe we want to annoy them > > into doing something about it? > > Question is, how often should setup show this message? Every time might > really be a bit annoying. Some kind of "I saw it, now leave me alone, > at least for a while" kind of function would be great. Eh. The installer tries to add icons to my desktop every time I run it unless I provide a command-line argument every time. This behaviour seems no more or less annoying to me, and I think having users see that warning is much more important than adding a desktop icon.
Re: Is it possible to 'cygport upload' with same p-v-r?
On Sat, 28 Aug 2021 at 09:09, Mark Geisert wrote: > > HI all,B > I'd like to re-spin the latest version of cygutils, that is, upload newer > files with the same release number (1.4.16-5). Is this possible, or do we > now always change the release# when uploading? > Thanks, I'm pretty sure this isn't possible, and nor should it be. Once it has been uploaded, people may have downloaded it. Without a change to at least the release number, the setup programs won't know that they should download and install the newer build.
Handling a Cygwin-specific security vulnerability
Hello maintainers! I've just been informed off-list that there's a Cygwin-specific security vulnerability in one of the packages I maintain. I'm reluctant to go into details on a public list, but I'd also appreciate some support in the best way to manage this to get patches out without exposing package users to unnecessary security risk. I'm already working with the upstream to find an appropriate patch, and I think I have at least a reasonable handle on best practices for releasing this sort of patch, but I'd appreciate being able to talk over the specifics with someone (singular or plural) with more experience of handling this sort of situation. Is there any way I can get that sort of support from the maintainer community? Adam
Re: ssh key / upload problem on new PC
On Tue, 16 Mar 2021 at 11:25, Thomas Wolff wrote: > > Hi, > I'm about to upload mintty 3.4.7 but I'm getting a "Host key > verification failed." error. > Trying this on a new machine; I copied the whole ~/.ssh folder from my > old machine, something that used to work in the past. It still works > from the old machine (as confirmed by fallback for uploading mintty 3.4.6). > Does anybody have an idea what might be going wrong? Do I need a new ssh > key? (But porting the key worked before...) What happens if you do `ssh cyg...@cygwin.com`? That'll normally point out what the error is. I expect either (a) you've managed to not copy over your `.ssh/known_hosts` file somehow, or (b) some of the files you've copied over have the wrong permissions; my money's on the latter. If so, `chmod 600 ~/.ssh/*; chmod 700 ~/.ssh` will normally get things going again. Adam
Re: [ITA] asciidoc 9.0.5
On Wed, 10 Feb 2021 at 09:20, Marco Atzeri via Cygwin-apps wrote: > > On 10.02.2021 09:40, Adam Dinwoodie wrote: > > Asciidoc is currently both orphaned and bugged, per my email to the > > main list. I've got the latest upstream release building, confirmed it > > resolves my Python versioning issues with the Git builds, and can > > upload as soon as I get the GTG. > > > > New packaging source: https://github.com/me-and/Cygwin-AsciiDoc/tree/next > > > > Build log: https://github.com/me-and/Cygwin-AsciiDoc/actions/runs/552677569 > > > > Full build output: > > https://github.com/me-and/Cygwin-AsciiDoc/suites/2005247005/artifacts/40091144 > > > > Packages and hint files: https://1drv.ms/u/s!AhKYM5BNTYlAhaFH5xlHfnOZLWik1g > > > > forgot to pack something ? > > $ cygport asciidoc.cygport all > /pub/tmp/asciidoc-9.0.5-1.src/asciidoc.cygport: line 17: > build-requires.txt: No such file or directory Ah crud, good catch, thank you!
[ITA] asciidoc 9.0.5
Asciidoc is currently both orphaned and bugged, per my email to the main list. I've got the latest upstream release building, confirmed it resolves my Python versioning issues with the Git builds, and can upload as soon as I get the GTG. New packaging source: https://github.com/me-and/Cygwin-AsciiDoc/tree/next Build log: https://github.com/me-and/Cygwin-AsciiDoc/actions/runs/552677569 Full build output: https://github.com/me-and/Cygwin-AsciiDoc/suites/2005247005/artifacts/40091144 Packages and hint files: https://1drv.ms/u/s!AhKYM5BNTYlAhaFH5xlHfnOZLWik1g
Re: GitHub automation for Cygwin builds [Was: Updated: moreutils v0.65-1]
On Sat, 16 Jan 2021 at 22:31, Ken Brown wrote:
> On 1/16/2021 3:33 PM, Adam Dinwoodie wrote:
> > On Sat, 16 Jan 2021 at 20:22, Adam Dinwoodie wrote:
> >> Version 0.65-1 of moreutils has been uploaded and should be coming
> >> soon to a distribution server near you.
> >
> > In case anyone's interested or has thoughts:
> >
> > As part of working on this release, I've been playing with GitHub's
> > automation tools. The entire build / test / package / release / upload
> > process was performed using free ephemeral GitHub-managed VMs. At
> > least in theory, this reduces the manual work for future releases to:
> >
> > - Commit a version of the Cygport file with an updated version number.
> > - Create a tag and push that tag to GitHub
> > - Wait for the confirmation email to arrive
> > - Send the announcement email
> >
> > This is obviously serving a similar purpose to the automated builds
> > that Scallywag provides; I'm not sure I'd have bothered with this
> > project had I not already been most of the way through it before I
> > spotted Scallywag existed. I suspect in theory Scallywag's access to
> > the Cygwin servers means it's potentially more powerful, but Scallywag
> > also comes with some general caveats ("at this stage, this is only
> > probably useful for verifying that BUILD_REQUIRES is correct"),
>
> I assume you're quoting from https://cygwin.com/packaging/build.html.
> Scallywag
> does have some limitations currently, but I think the statement you quoted is
> obsolete. I often have Scallywag deploy my packages, as does Jon Turney.
Yes, that was my source here. I experimented with Scallywag briefly,
but was put off by (a) that warning and (b) the fact that my first
builds failed because I apparently use the wrong quoting style in my
Cygport files. And, as I say, that I was already a significant way to
a working GitHub Action process.
> The limitations I've bumped into are:
>
> 1. Scallywag will time out after an hour on each arch.
This is a killer for me. Getting this working with moreutils was a
simple proof-of-concept; the key package where this will likely save
me time and energy is Git, and the Git test suite takes multiple hours
to run on Cygwin. GitHub actions have a per-job limit of 6 hours, and
a per-workflow limit of 72 hours.
> 2. Several of my packages fail to build on x86 because of gcc crashes.
>
> I think these limitations are outweighed by the fact that a Scallywag build is
> automatically triggered by a push to an official source repo
> (https://cygwin.com/packaging/repos.html). All maintainers can use this
> without
> any special setup.
That's clearly incredibly valuable, yes. I'm hoping to reduce the
special setup using GitHub Actions requires, but it's clearly going to
require more than zero setup.
Adam
GitHub automation for Cygwin builds [Was: Updated: moreutils v0.65-1]
On Sat, 16 Jan 2021 at 20:22, Adam Dinwoodie wrote:
> Version 0.65-1 of moreutils has been uploaded and should be coming
> soon to a distribution server near you.
In case anyone's interested or has thoughts:
As part of working on this release, I've been playing with GitHub's
automation tools. The entire build / test / package / release / upload
process was performed using free ephemeral GitHub-managed VMs. At
least in theory, this reduces the manual work for future releases to:
- Commit a version of the Cygport file with an updated version number.
- Create a tag and push that tag to GitHub
- Wait for the confirmation email to arrive
- Send the announcement email
This is obviously serving a similar purpose to the automated builds
that Scallywag provides; I'm not sure I'd have bothered with this
project had I not already been most of the way through it before I
spotted Scallywag existed. I suspect in theory Scallywag's access to
the Cygwin servers means it's potentially more powerful, but Scallywag
also comes with some general caveats ("at this stage, this is only
probably useful for verifying that BUILD_REQUIRES is correct"),
whereas I think with care this could replace local builds today.
The configuration to make this work is almost entirely in
<https://github.com/me-and/Cygwin-moreutils/blob/v0.65-1/.github/workflows/ci.yml>,
and I expect the modifications to make this work for most other
packages would be straightforward. I'm hoping to make the process and
required configuration simpler, by creating a pre-defined GitHub
action that hides most of the boilerplate.
If you're curious, you can see the full build output for the final
release build at
<https://github.com/me-and/Cygwin-moreutils/actions/runs/490534324>.
Fixing moreutils Git repo
Somewhere along the way I seem to have unsubscribed from this list, and therefore managed to miss a bunch of development with the Git repositories at https://cygwin.com/git-cygwin-packages/. As a result I thought they were still naive repositories with no fancy logic or automation, and my first experiments with the moreutils repo have created a branch I'd like to force-push to or delete, but am blocked by the hooks. Would it be possible for someone with the relevant access to either delete the "next" branch from the moreutils repo, or delete the repo wholesale so I can recreate it (with more care) from scratch? Tangentially, is there any clear documentation on what functions these repos have these days? There's some info at https://cygwin.com/packaging/repos.html, but (for example) that makes no mention of the build automation that clearly now exists, nor of any branch protection. And while I can go through the mailing list archives, that also requires reading through a bunch of messages that are going to be no longer relevant.
Re: Unable to upload: "Permission denied (publickey)"
On Wednesday 22 November 2017 at 04:35 pm +, Jon Turney wrote: > On 22/11/2017 15:17, Adam Dinwoodie wrote: > >I'm currently unable to upload packages I maintain: attempting to > >connect to cygwin-rdbxbdvo6bxqt0dzr+a...@public.gmane.org over SSH or SFTP > >is failing. I'm > >reasonably confident I haven't done anything locally to change my key; > >has something happened server-side to cause problems? > > > > Wed 22 Nov 14:54 $ sftp -i ~/.ssh/cygwin_rsa > > cygwin-rdbxbdvo6bxqt0dzr+a...@public.gmane.org > > cygwin-rdbxbdvo6bxqt0dzr+a...@public.gmane.org: Permission denied > > (publickey). > > Connection closed > > > >Happy to provide more detailed diagnostics if they'd be useful, but I'm > >guessing the problem is either going to be resolved by fixing something > >server-side or just re-uploading my SSH public key. > > Thanks for reporting this. > > Yes, this seems to be due to some server-side problem, which overseers have > fixed. Seems to be working now, thank you!
Unable to upload: "Permission denied (publickey)"
I'm currently unable to upload packages I maintain: attempting to connect to cyg...@cygwin.com over SSH or SFTP is failing. I'm reasonably confident I haven't done anything locally to change my key; has something happened server-side to cause problems? Wed 22 Nov 14:54 $ sftp -i ~/.ssh/cygwin_rsa cyg...@cygwin.com cyg...@cygwin.com: Permission denied (publickey). Connection closed Happy to provide more detailed diagnostics if they'd be useful, but I'm guessing the problem is either going to be resolved by fixing something server-side or just re-uploading my SSH public key. Cheers, Adam
Re: [ITP] moreutils 0.61
On Monday 20 November 2017 at 05:19 pm +, Jon Turney wrote: > On 15/11/2017 13:10, Adam Dinwoodie wrote: > >I'm looking to package moreutils, a collection of small Linux utilities. > >It is already included in Debian and Ubuntu (amongst others), and is > >released under GPLv2. > > > >Proposed Cygwin packaging: https://tastycake.net/~adam/cygwin/ > No debuginfo package seems to be generated, but otherwise looks good. I was mildly surprised by that, too. I'm used to cygport just magically making that work, and I'm not sure where to even begin looking at resolving the lack of debuginfo. > I added this to your uploads. Thanks! I'll upload shortly.
Re: [ITP] moreutils 0.61
On Wednesday 15 November 2017 at 08:52 pm +, Tony Kelman wrote: > >> >> - parallel: run multiple jobs at once > >> > >> I'd be hesitatnt to package that since it directly clashes with GNU > >> parallel (not available on Cygwin yet). > > > > Hmm. I wasn't aware of GNU parallel, and I'm not sure how that sort of > > problem is generally handled. Possibly that could be broken out into a > > separate package to make it easier for folk to install one or the other? > > I considered and decided against breaking the entire lot into separate > > packages, but this is perhaps a good argument for at least separating > > that. > > This has been a long source of tension between moreutils' author and the > debian packager (probably fedora and other distros too). I don't know off > the top of my head what solution those distros have come up with for the > name conflict but they may be doing something worth investigating and > imitating. > > I have made frequent use of mispipe and ts, and would probably use other > pieces of moreutils if I remembered them better, so I'd use and appreciate > a cygwin package of them - assuming a solution is found to the potential > name conflict. It looks like both OS X's Homebrew and Debian's Apt deal with this by just having the packages conflict. Homebrew definitely warns about the conflicts, when it sees you trying to install both packages, and I would assume Apt does too. I'm guessing setup-*.exe doesn't have the ability to detect and handle this sort of conflict, but I can see a bunch of alternative options: - Do nothing for now and deal with the problem as and when someone ITPs GNU parallel. - Add detection for this sort of conflict somehow, and refuse to allow users to install conflicting packages. - Document the conflict in release announcements but otherwise do nothing, and allow the packages to overwrite each other if both are installed. - Rename moreutils parallel (e.g. `mparallel`) so it doesn't conflict. - As and when GNU parallel is packaged, rename it (e.g. `gparallel`) so it doesn't conflict. - Just refuse to package one or the other for Cygwin. I'm leaning towards either doing nothing and leaving it as a problem for the future, or renaming moreutils parallel now, but I'd be very interested in the list's opinion.
Re: [ITP] moreutils 0.61
On Wednesday 15 November 2017 at 07:31 pm +0100, Achim Gratz wrote: > Adam Dinwoodie writes: > > I'm looking to package moreutils, a collection of small Linux utilities. > > It is already included in Debian and Ubuntu (amongst others), and is > > released under GPLv2. > > This looks like a really mixed bag… Is there some more documentation > somewhere on the web? The only online documentation I'm aware of is on the homepage I linked to, plus a bunch of folk espousing the benefits of the package. I guess you could also look at the man pages, either in the packages I uploaded, or the uncompiled source for them at https://git.joeyh.name/index.cgi/moreutils.git/tree/. > >> - parallel: run multiple jobs at once > > I'd be hesitatnt to package that since it directly clashes with GNU > parallel (not available on Cygwin yet). Hmm. I wasn't aware of GNU parallel, and I'm not sure how that sort of problem is generally handled. Possibly that could be broken out into a separate package to make it easier for folk to install one or the other? I considered and decided against breaking the entire lot into separate packages, but this is perhaps a good argument for at least separating that.
[ITP] moreutils 0.61
I'm looking to package moreutils, a collection of small Linux utilities. It is already included in Debian and Ubuntu (amongst others), and is released under GPLv2. Homepage: https://joeyh.name/code/moreutils/ Debian package: https://packages.debian.org/sid/utils/moreutils Ubuntu package: https://packages.ubuntu.com/zesty/moreutils Proposed Cygwin packaging: https://tastycake.net/~adam/cygwin/ Quoting from the moreutils homepage: > Probably the most general purpose tool in moreutils so far is > sponge(1), which lets you do things like this: > > % sed "s/root/toor/" /etc/passwd | grep -v joey | sponge /etc/passwd > > There are lots more listed below, and I'm always interested to add > more to the collection, as long as they're suitably general-purpose, > and don't duplicate other well-known tools. > > - chronic: runs a command quietly unless it fails > - combine: combine the lines in two files using boolean operations > - errno: look up errno names and descriptions > - ifdata: get network interface info without parsing ifconfig output > - ifne: run a program if the standard input is not empty > - isutf8: check if a file or standard input is utf-8 > - lckdo: execute a program with a lock held > - mispipe: pipe two commands, returning the exit status of the first > - parallel: run multiple jobs at once > - pee: tee standard input to pipes > - sponge: soak up standard input and write to a file > - ts: timestamp standard input > - vidir: edit a directory in your text editor > - vipe: insert a text editor into a pipe > - zrun: automatically uncompress arguments to command
Re: [Attn. Maintainers] Perl 5.26.1 (release is imminent)
On Mon, Oct 23, 2017 at 12:47:41PM -0500, Yaakov Selkowitz wrote: > On 2017-10-18 13:20, Achim Gratz wrote: > > Again the reminder that the following packages will have to be re-built > > since they install perl modules: > > > > git: Distributed version control system > > grepmail:search mailboxes for mail matching an expression > > (installed binaries and support files) > > pristine-tar:Regenerate pristine tarballs (installed binaries > > and support files) > > sendxmpp:Commandline XMPP (jabber) utility (installed binaries > > and support files) > > Adam, Jari, these packages still need to be rebuilt. I'll update and rebuild Git now. Adam
Intent to disown: fzf
Folks, (Gene, I've CC'd you as you're the only specific person I'm aware of who may have interest in taking this over and I suspect you're not on this list.) The upstream fzf project has retired support for the Ruby version of their tool in favour of the Go version, and Cygwin doesn't have a Go compiler. I'd intended to fork and maintain the Ruby version myself, but I've not had the time to do that work in the past 18 months. As such, I'm going to officially abandon that maintainership. In case anyone wants to take over the maintainership and/or the Ruby fzf project, the code for both the project itself and for packaging it for Cygwin are available at the below links: https://github.com/me-and/fzf https://github.com/me-and/Cygwin-fzf For the avoidance of doubt, I'm absolutely intending to keep maintaining Git and The Silver Searcher. Adam
Re: SSH key for upload access
On 18 April 2017 at 16:21, Adam Dinwoodie wrote: > Name: Adam Dinwoodie > Package: git Replying so the original email is still in the correct format: I'm sending in a new key because I've managed to lose the password for my previous upload SSH key.
SSH key for upload access
Name: Adam Dinwoodie Package: git BEGIN SSH2 PUBLIC KEY B3NzaC1yc2EDAQABAAACAQC6Q+n5YorDTYF9bag+N80WCSatVBTjG5Ia4s3dhk F3SQk2U+RJZmmLhQU8cwWqw6r7OpBJIhtzxHYkUQ4qsiXVh8tSUE6SQ6eqor1k2UnKLS4p g2OVLkCQU3sdqr6v6NdlwvDiH22tO4Xf9S5uh9yQJ9RGkQrpxkV8BZyaiz08hakfYYNn62 xl2vzeKc7EXDAH9GAI7M/LW2oHws9IAMuM/INqtU7bSqVEuQrw18WK9qT61FjP8+9hQFIK Zy84yA1fNxRjx0MobVGCK4VpCHPaJC8sUzMaQ/UqZ++tGKANluL5FQUiAWv0jAd+MgDugm 8tmwCnZsVv6PfgjUzGLkokTG4uGElabl+sk0RAec0oN/lD50DgMInmL8xsq8mzw1diGtIC otkl8y0y4x7FQ1fNTBgwyj3PRdg5lwiFZ98xSdKgY0V4RS/vwepSEWOOwTgPcW4dMu Th+0xc2nyMkhAV5LGbSRxpnhQjL3GiSd/2HBa+055d+g2D7XOrPUCW93QbpyDoA6Go/IDq r9oKEyJMizjVn/BPz08oV+xnlFGyiyreS9qwfYezloecFqGMAaF9v38pdDQfs5OuU8XQBX FPjYYYXYkTtA+F9Aewj9FTYNyTjDudQdF7T7bZktoF/+D3YaVcr94P4UzezZjUDodMqu0L OOWU2Y4fBRQhhw== END SSH2 PUBLIC KEY
Re: [ACTION REQUIRED] ARCH=noarch uploads with cygport 0.22.0
On Tue, May 10, 2016 at 05:11:15PM -0500, Yaakov Selkowitz wrote: > Once you have upgraded to cygport 0.22.0, maintainers MUST email a > list of their package(s) which qualify as noarch AND are already > marked ARCH=noarch or will be with the next release. fzf is already marked as a noarch package. Adam
Process for retiring a subpackage
Per previous discussion on this list, I'm planning on retiring the separate packaging of Bash completion scripts in the packages I maintain, and folding the files into the main package. I can't find any documentation that'll hold my hand through that process, so can somebody with the relevant arcane knowledege check my understanding of what's necessary? Taking git-completion as an example, where I'm moving all the contents from that package into the main git package: - For the first release that obsoletes git-completion: - Create the main git package in such a way that it contains the files that would previously have been in git-completion. - Create a dummy git-completion package that: - Has a dependency on the git package (which it normally does anyway). - Has a category of "_obsolete". - Has no actual content. - Create the rest of the release as normal. - For following releases: - Continue to create all the packages as normal (excluding git-completion). - Don't bother to create new versions of the git-completion package. The above process is cobbled together from memory of emails going past this list, so I'd appreciate someone checking I've understood correctly.
Re: calm messages [x86]
On Thu, Mar 17, 2016 at 11:37:37AM -0500, Yaakov Selkowitz wrote: > On 2016-03-17 07:42, cygwin-no-re...@cygwin.com wrote: > >package 'git-svn' hints changed > >- 'requires': 'git perl perl-YAML perl_base subversion-perl', > >? > > Missing subversion-perl on your build machine? > > >package 'gitweb' hints changed > >- 'requires': 'bash perl_base ruby git lighttpd', > >?--- > >+ 'requires': 'bash git lighttpd', > > gitweb.cgi is a perl script, so perl and several modules are > definitely required here. > > >package 'git' hints changed > >- 'requires': 'bash cygwin libcurl4 libexpat1 libgcc1 libiconv2 libintl8 > >libopenssl100 perl perl-Error perl-TermReadKey perl_base python zlib0 > >cygutils less openssh rsync', > >? - > > Why no more bash dependency? All good questions! I spotted and fixed the first already in v2.7.3-2; the other two I'm not sure what changed -- I've been using the same Cygport file and haven't done anything to remove those dependencies -- but I'll have a look when I get time to do some more digging, hopefully tomorrow.
Re: [HEADSUP] New github organization "cygwin"
On Thu, Mar 17, 2016 at 04:49:17PM +0100, Corinna Vinschen wrote: > today I claimed the "cygwin" name at github.com. If you have some funny > project which is using Cygwin in the first place, and you want to do > that under the "cygwin" cover, feel free to drop us a mail here on > cygwin-apps and we add you as member. You can then create your own git > repo under this hood if you like. It should just be closely related to > Cygwin. I have the Cygport files for the various packages I maintain tracked on GitHub; is that the sort of thing you're looking for? I'd be happy to move them under the Cygwin banner. My GitHub username is me-and.
Re: calm messages [x86]
On Fri, Mar 18, 2016 at 12:40:17PM -0500, Yaakov Selkowitz wrote: > On 2016-03-18 07:32, Adam Dinwoodie wrote: > >On Thu, Mar 17, 2016 at 11:37:37AM -0500, Yaakov Selkowitz wrote: > >>On 2016-03-17 07:42, cygwin-no-re...@cygwin.com wrote: > >>>package 'gitweb' hints changed > >>>- 'requires': 'bash perl_base ruby git lighttpd', > >>>?--- > >>>+ 'requires': 'bash git lighttpd', > >> > >>gitweb.cgi is a perl script, so perl and several modules are > >>definitely required here. > > > >On this particular package, I've restored the dependency on ruby that > >Cygport stopped picking up. I haven't restored the dependency on > >perl_base, on the grounds that it's included indirectly via the > >dependency on git. > > I'd have to look closer, but it may be that ruby is optional (only > used when 'webrick' is chosen as the web server), but perl is > definitely not. Besides keeping direct dependencies clear, I think > there are some perl modules which need to be required as well. I don't use gitweb, so I've never really paid attention to the package. Digging into it now (recording here as much for my own reference and posterity as for anything else): - git-instaweb is a bash script; it looks like you could in theory not bother with it and start git-web manually, but the documentation is sufficiently focussed on git-instaweb, and the overhead of a requirement on bash is sufficiently low that I think I want to leave that requirement in rather than attempt to remove it. Plus that's a requirement that Cygport is picking up for itself, and I'd rather not play with Cygport's magic unnecessarily. - gitweb requires _a_ web server, but it looks like it'd be equally happy with with the Apache httpd as with lighttpd, and possibly other things too (webrick? plackup?). It might be worth removing that requirement to let users choose to use Apache's httpd instead. - It looks like ruby is indeed only required if the server is webrick, so I propose removing that as a dependency again. - gitweb.cgi is indeed a Perl script, and has a bunch of Perl module dependencies I've not (yet) worked through to check exactly what those dependencies mean in terms of Cygwin packages. Thus far I've been mostly reliant on Cygport's dependency generation, on the grounds that it hasn't seemed too far from the mark in the past, and I'd rather not have to work out by hand what dependencies have changed every time I package a release. I think, rather than working out what the correct dependencies here should be and configuring them manually, particularly for Perl modules where the mapping from a Perl module name to the Cygwin package isn't always obvious, I'd like to try to work out what's stopping the dependency detection from picking up the dependencies automatically. That feels like a fairly hefty task, though -- I've not dug around much in the Cygport code in the past, and not at all in the dependency handling bits of it.
Re: calm messages [x86]
On Thu, Mar 17, 2016 at 11:37:37AM -0500, Yaakov Selkowitz wrote: > On 2016-03-17 07:42, cygwin-no-re...@cygwin.com wrote: > >package 'gitweb' hints changed > >- 'requires': 'bash perl_base ruby git lighttpd', > >?--- > >+ 'requires': 'bash git lighttpd', > > gitweb.cgi is a perl script, so perl and several modules are > definitely required here. On this particular package, I've restored the dependency on ruby that Cygport stopped picking up. I haven't restored the dependency on perl_base, on the grounds that it's included indirectly via the dependency on git.
Re: calm messages [x86]
On Thu, Mar 17, 2016 at 02:52:28PM -0500, Yaakov Selkowitz wrote: > On 2016-03-17 14:00, Adam Dinwoodie wrote: > >All good questions! I spotted and fixed the first already in v2.7.3-2; > > This 2.7.3-2 is incorrect on a few counts: > > 1) if the *only* issue is dependencies (and not the contents of the > build itself) then we can fix the setup.hint on sourceware without a > new release. For 32-bit, I believe the only issue is dependencies; for 64-bit there is a change in the binaries as well. I hadn't realised just changing the setup.hint files was an option, but it sounds like just doing a complete rebuild of everything is the sensible fix anyway. > 2) it looks like you manually repackaged some but not all of git for > this. A release should be a complete build with cygport, not some > ad-hoc improvisation. > > Because of the latter, I have removed the 2.7.3-2 tarballs from the > distro. If you need to make a rebuild to fix packaging issues, > please spin a complete 2.7.3-3 build. Fair enough. As I said, I'm not going to be able to spin that out tonight, but I should be able to do it tomorrow. > >the other two I'm not sure what changed -- I've been using the same > >Cygport file and haven't done anything to remove those dependencies -- > >but I'll have a look when I get time to do some more digging, hopefully > >tomorrow. > > Either something changed in the package itself (e.g. executable > permissions on scripts?) or its a change in cygport. Either way, > let's fix this so that these packages work OOTB. Thinking about it, I suspect my build environment changed; I'd been relying on the DEPEND setting in git.cygport to catch any problems there, but that was clearly missing some things, so I expect it's causing the rest of the problems too. > (BTW, thanks to jturney for this new feature in calm. I hope people > will pay attention to these from now on.) Agreed; I hadn't spotted it was anything useful to check until too late, but I'll definitely be looking at it in future.
Re: Process for retiring a subpackage
On Fri, Mar 18, 2016 at 12:45:01PM -0500, Yaakov Selkowitz wrote: > On 2016-03-18 07:24, Adam Dinwoodie wrote: > >On Thu, Mar 17, 2016 at 10:46:53AM -0500, Yaakov Selkowitz wrote: > >>Simpler: > >> > >>git_OBSOLETES="git-completion" > >> > >>Just leave this in indefinitely. > > > >Ah, handy! One thing that's missing, which I suspect is a bug in > >Cygport: I'd expect the git-completion package produced after adding > >that would have a category of "_obsolete", but I needed to define > >git_completion_CATEGORY for that to happen. > > No, that's not necessary, cygport handles that just fine. Did you > forget to remove git-completion from PKG_NAMES? ... Yes Oops Thank you!
Re: [HEADSUP] New github organization "cygwin"
On Fri, Mar 18, 2016 at 09:00:56PM +0100, Corinna Vinschen wrote: > On Mar 18 12:49, Yaakov Selkowitz wrote: > > On 2016-03-18 08:27, Corinna Vinschen wrote: > > >On Mar 18 12:37, Adam Dinwoodie wrote: > > >>I have the Cygport files for the various packages I maintain tracked on > > >>GitHub; is that the sort of thing you're looking for? I'd be happy to > > >>move them under the Cygwin banner. > > >> > > >>My GitHub username is me-and. > > > > > >Yaakov, would you mind to let me in as well? > > > > I sent you both invitations to cygwinports. > > Thanks, I'm in :) Likewise, thank you!
Re: Process for retiring a subpackage
On Thu, Mar 17, 2016 at 10:46:53AM -0500, Yaakov Selkowitz wrote: > On 2016-03-17 07:04, Adam Dinwoodie wrote: > >Per previous discussion on this list, I'm planning on retiring the > >separate packaging of Bash completion scripts in the packages I > >maintain, and folding the files into the main package. I can't find any > >documentation that'll hold my hand through that process, so can somebody > >with the relevant arcane knowledege check my understanding of what's > >necessary? > > > >Taking git-completion as an example, where I'm moving all the contents > >from that package into the main git package: > > > >- For the first release that obsoletes git-completion: > > > > - Create the main git package in such a way that it contains the files > > that would previously have been in git-completion. > > > > - Create a dummy git-completion package that: > > Simpler: > > git_OBSOLETES="git-completion" > > Just leave this in indefinitely. Ah, handy! One thing that's missing, which I suspect is a bug in Cygport: I'd expect the git-completion package produced after adding that would have a category of "_obsolete", but I needed to define git_completion_CATEGORY for that to happen.
Re: [ITP] The Silver Searcher / Ag
On Tue, Mar 15, 2016 at 01:18:16PM +0100, Corinna Vinschen wrote: > On Mar 15 11:52, Adam Dinwoodie wrote: > > On Tue, Mar 15, 2016 at 11:36:57AM +0100, Corinna Vinschen wrote: > > > Hi Adam, > > > > > > On Mar 15 10:05, Adam Dinwoodie wrote: > > > > Does this and/or Warren's email count as a GTG? I have the packages > > > > ready to upload... > > > > > > I added ag to cygwin-pkg-maint. Please go ahead. > > > > Hmm. The package I uploaded was called the_silver_searcher, to match > > Fedora's packaging (plus Gentoo, Arch, Slackware, BSD, ...), and I think > > the mismatch is preventing upset from picking up the packages. Could > > you rename the package in cygwin-pkg-maint? > > Done. Thank you!
Re: [ITP] The Silver Searcher / Ag
On Tue, Mar 15, 2016 at 11:36:57AM +0100, Corinna Vinschen wrote: > Hi Adam, > > On Mar 15 10:05, Adam Dinwoodie wrote: > > Does this and/or Warren's email count as a GTG? I have the packages > > ready to upload... > > I added ag to cygwin-pkg-maint. Please go ahead. Hmm. The package I uploaded was called the_silver_searcher, to match Fedora's packaging (plus Gentoo, Arch, Slackware, BSD, ...), and I think the mismatch is preventing upset from picking up the packages. Could you rename the package in cygwin-pkg-maint? Thank you!
Separate packages for completion scripts?
Seeking opinions from other package maintainers: is it desirable to have Bash (et al.) completion scripts as part of the main package they're associated with, or should they be packaged separately? Currently, the two packages I maintain (fzf and Git) both have separate packages for their Bash completion scripts. For Git, that was the behaviour when I adopted the package, and for fzf I copied the example set by Git. Looking now, the only other package that has its Bash completion script as a separate install to the main package is dbus; everything else just includes the completion scripts as pant of the main package.[0] I'm thinking about this in the context of packaging Ag, which also has a Bash completion script, and I'm thinking including it in the main package is the easiest option, both from my perspective and from an end-user perspective. The only disadvantages I can think of are for people who definitely don't want the completion script even though they do want the tool and they do want the rest of bash-completion, but I could well believe that's an empty set. Does anyone here have any preferences or opinions? I'm currently thinking I'll package Ag's completion script in the main package, and look at rolling the other completion scripts into the main package when I get around to switching to use pkg-config to get the relevant directory names. [0]: https://cygwin.com/cgi-bin2/package-grep.cgi?grep=etc%2Fbash_completion.d%5C%7Cusr%2Fshare%2Fbash-completion%2Fcompletions=x86_64
Re: [ITP] The Silver Searcher / Ag
On Tue, Feb 23, 2016 at 10:54:04AM -0600, Yaakov Selkowitz wrote:
> On 2016-02-23 08:42, Adam Dinwoodie wrote:
> >SRC_URI="https://github.com/ggreer/the_silver_searcher/archive/${PV}.tar.gz;
>
> SRC_URI="https://github.com/ggreer/the_silver_searcher/archive/${VERSION}/the_silver_searcher-${VERSION}.tar.gz;
>
> This works better with DISTDIR.
I didn't know that URL existed. I'll switch to that and do similar for
fzf, which also uses the first version of the command.
> >the_silver_searcher_completion_REQUIRES='the_silver_searcher bash_completion'
>^
> That should be bash-completion with a hyphen.
Good spot, thank you!
> > cyginstall bashcompdir=/etc/bash_completion.d
>
> We have bash-completion-2.1 now, so you can use
> bashcompdir=$(pkg-config --variable=completionsdir bash-completion)
> -- and change *_CONTENTS accordingly.
Ooh. I hadn't spotted that change or the addition of on-demand
completion loading. I'll have a look at whether the other packages I
maintain can take advantage of that, too.
For this package, it doesn't look as simple as _just_ changing
bashcompdir, though, as the script is called "ag.bashcomp.sh". That
works just fine putting the file in compatdir, but doesn't load if it's
in completionsdir, because that expects the script to just be called
"ag". I can see a few different solutions, and I'd appreciate a second
opinion:
1. Patch the Ag build process to call the script "ag" rather than
"ag.bashcomp.sh". This looks like it'd be a slightly complex and
fragile patch, though.
2. Rename "ag.bashcomp.sh" to "ag" after the cyginstall step. This
still feels a bit fragile to me, although less so than option 1.
3. Install the script as "ag.bashcomp.sh", then create a symlink from
"ag" to "ag.bashcomp.sh". I'm currently leaning towards this as the
neatest and safest solution, not least because it uses Cygport's
dosym rather than a bare mv, although it does leave a more-or-less
useless file in the completions directory.
4. Just install to /etc/bash_completion.d (although probably using
"pkg-config --variable=compatdir bash-completion), which appears to
be what the upstream package currently intends.
Anyone have any thoughts/advances on those options?
(The neatest solution would obviously be to get the upstream package to
install in the right directory in the first place, and it looks like
they'd be amenable to such a change based on an issue from 2013[0], but
it looks like it'd require some autoconf magic to be able to handle
versions of Bash completion both with and without on-demand loading, and
autoconf is an art I do not currently have.)
[0]: https://github.com/ggreer/the_silver_searcher/issues/271
[ITP] The Silver Searcher / Ag
Folks, I'm looking at packaging The Silver Searcher, aka Ag. The Silver Searcher is a grep/Ack replacement designed for searching code and optimised for speed. The package has an Apache 2.0 license, and is already packaged for Debian, Ubuntu and Fedora, amongst others. setup.hint is below, further information in the links. Adam Package home page: http://geoff.greer.fm/ag/ Package source: https://github.com/ggreer/the_silver_searcher License: https://github.com/ggreer/the_silver_searcher/blob/master/LICENSE Cygport files: https://github.com/me-and/Cygwin-ag Debian package: https://packages.debian.org/sid/utils/silversearcher-ag Ubuntu package: https://launchpad.net/ubuntu/+source/silversearcher-ag Fedora package: https://apps.fedoraproject.org/packages/the_silver_searcher category: Utils requires: cygwin liblzma5 libpcre1 zlib0 sdesc: "Ag: a code searching tool with a focus on speed" ldesc: "The Silver Searcher (Ag) is a code searching tool similar to Ack, with a focus on speed."
Cygport uploading different files to different arch directorys for noarch packages
I'm seeing what seems to be some very odd behaviour from Cygport when uploading noarch packages: Cygport uploads all the packages for the 64-bit architecture, but only the main and source packages for 32-bit architecture. Mostly I'm looking to know whether other people experience the same behaviour when using Cygport to upload noarch packages -- the behaviour I'm seeing is entirely reproducible on my system. I've done some digging, and I'm utterly baffled, so I'm going to post this here in case anyone else has any cunning theories; arguably this is into the realms of an lftp/cygport/bash bug, so if folk want me to take it to the main list, I'm happy to do that too. Here's what I'm seeing (having commented out the !ready line in pkg_upload.cygpart to allow testing, although I've checked both ways and that doesn't make a difference): $ cygport fzf.cygport upload >>> Uploading fzf-0.10.8-1.noarch >>> Running lftp sftp://cygwin:@cygwin.com cd ok, cwd=/x86/release Transferring file `fzf-0.10.8-1-src.tar.xz' Transferring file `fzf-0.10.8-1.tar.xz' Transferring file `setup.hint' cd ok, cwd=/x86_64/release New: 3 files, 0 symlinks 116628 bytes transferred in 1 second (84.4 KiB/s) Transferring file `fzf-0.10.8-1-src.tar.xz' Transferring file `fzf-0.10.8-1.tar.xz' Transferring file `setup.hint' Making directory `fzf-bash' Transferring file `fzf-bash/fzf-bash-0.10.8-1.tar.xz' Transferring file `fzf-bash/setup.hint' Making directory `fzf-bash-completion' Transferring file `fzf-bash-completion/fzf-bash-completion-0.10.8-1.tar.xz' Transferring file `fzf-bash-completion/setup.hint' Making directory `fzf-fish' Transferring file `fzf-fish/fzf-fish-0.10.8-1.tar.xz' Transferring file `fzf-fish/setup.hint' Making directory `fzf-vim' Transferring file `fzf-vim/fzf-vim-0.10.8-1.tar.xz' Transferring file `fzf-vim/setup.hint' Making directory `fzf-zsh' Transferring file `fzf-zsh/fzf-zsh-0.10.8-1.tar.xz' Transferring file `fzf-zsh/setup.hint' Making directory `fzf-zsh-completion' Transferring file `fzf-zsh-completion/fzf-zsh-completion-0.10.8-1.tar.xz' Transferring file `fzf-zsh-completion/setup.hint' Total: 6 directories, 15 files, 0 symlinks New: 15 files, 0 symlinks 129612 bytes transferred in 8 seconds (15.3 KiB/s) Upload complete. Note only three files were uploaded before the cd to /x86_64/release. I've looked at the cygport code, and I can see no way this could happen -- the code for uploading to x86 and x86_64 is the same code on a loop -- and yet it's happening reliably for me. By way of further testing, I hacked the Cygport code to dump the lftp commands to file, then emulated the lftp command from my Bash shell: $ cat upload_commands set cmd:fail-exit on set cmd:interactive on set net:max-retries 1 open sftp://cygwin:@cygwin.com cd /x86/release rm -f fzf/!ready || echo -n mirror -v -eR fzf cd /x86_64/release rm -f fzf/!ready || echo -n mirror -v -eR fzf $ lftp -f <(cat upload_commands) cd ok, cwd=/x86/release Making directory `fzf-bash' Transferring file `fzf-bash/fzf-bash-0.10.8-1.tar.xz' Transferring file `fzf-bash/setup.hint' Making directory `fzf-bash-completion' Transferring file `fzf-bash-completion/fzf-bash-completion-0.10.8-1.tar.xz' Transferring file `fzf-bash-completion/setup.hint' Making directory `fzf-fish' Transferring file `fzf-fish/fzf-fish-0.10.8-1.tar.xz' Transferring file `fzf-fish/setup.hint' Making directory `fzf-vim' Transferring file `fzf-vim/fzf-vim-0.10.8-1.tar.xz' Transferring file `fzf-vim/setup.hint' Making directory `fzf-zsh' Transferring file `fzf-zsh/fzf-zsh-0.10.8-1.tar.xz' Transferring file `fzf-zsh/setup.hint' Making directory `fzf-zsh-completion' Transferring file `fzf-zsh-completion/fzf-zsh-completion-0.10.8-1.tar.xz' Transferring file `fzf-zsh-completion/setup.hint' Total: 6 directories, 15 files, 0 symlinks New: 12 files, 0 symlinks 12984 bytes transferred in 7 seconds (1.8 KiB/s) cd ok, cwd=/x86_64/release Total: 6 directories, 15 files, 0 symlinks So everything works fine there: it correctly finishes the x86 upload I started in Cygport and does nothing for the already completed x86_64 upload. For further testing, I hacked Cygport up some more to write that upload_commands file out, then immediately read from it using the same command as above. This produced the bugged behaviour again, which implies it's definitely something about the Cygport environment that's causing the odd behaviour. As I say, I'm utterly baffled by this. For now I'll just upload the remaining x86 files manually, but I'd love to know what's going on.
Re: [ITP] fzf 0.10.8
On 5 November 2015 at 10:05, Corinna Vinschen wrote: > Hi Adam, > > On Nov 2 10:37, Adam Dinwoodie wrote: >> Folks, >> >> I'm looking at packaging fzf[0], which is a "fuzzy finder" with shell >> and Vim integration. It's not nearly so fast on Cygwin as it is on my >> Linux and Mac boxes, sadly (I suspect a combination of it needing to >> fall back to Ruby due to Cygwin's lack of Go compiler, plus the standard >> Cygwin overheads), but it's still pretty fast, and I've been using it >> myself on Cygwin for a couple of weeks, and on my CentOS box for a fair >> bit longer. >> >> The upstream package has an MIT license and is already included by Arch >> Linux[1]. The main setup.hint is below, and it's ready to upload as >> soon as it's declared GTG; I've uploaded the entire package tree[2] and >> Cygport packaging code[3] for reference, too. >> >> [0]: https://github.com/junegunn/fzf >> [1]: https://aur.archlinux.org/packages/fzf/ >> [2]: https://tastycake.net/~adam/cygwin/fzf/ >> [3]: https://github.com/me-and/Cygwin-fzf/ > > GTG. Thanks! I'm just in the process of working out how to deal with a bash-completion source ordering issue, then I'll upload and announce. (In case you're interested: bash-completion sources files in its directory apparently in alphabetical order. This means fzf's bash-completion script gets sourced before some things it's supposed to override; I'm trying to find a slightly less fragile way to avoid that than just renaming the script as "-fzf" or similar...) Adam
[ITP] fzf 0.10.8
Folks, I'm looking at packaging fzf[0], which is a "fuzzy finder" with shell and Vim integration. It's not nearly so fast on Cygwin as it is on my Linux and Mac boxes, sadly (I suspect a combination of it needing to fall back to Ruby due to Cygwin's lack of Go compiler, plus the standard Cygwin overheads), but it's still pretty fast, and I've been using it myself on Cygwin for a couple of weeks, and on my CentOS box for a fair bit longer. The upstream package has an MIT license and is already included by Arch Linux[1]. The main setup.hint is below, and it's ready to upload as soon as it's declared GTG; I've uploaded the entire package tree[2] and Cygport packaging code[3] for reference, too. [0]: https://github.com/junegunn/fzf [1]: https://aur.archlinux.org/packages/fzf/ [2]: https://tastycake.net/~adam/cygwin/fzf/ [3]: https://github.com/me-and/Cygwin-fzf/ Adam category: Shells requires: ruby ruby-curses sdesc: "Command line fuzzy finder" ldesc: "fzf is a general-purpose command-line fuzzy finder"
Re: Adding a subpackage
On 08/08/2015 06:31, Achim Gratz wrote: Adam Dinwoodie writes: I've discovered a neat Git tool -- git subtree -- which is part of Git's contrib directory and isn't something we currently distribute as part of any of the existing Git-related packages. openSUSE ships this in git-core since some time. AFAIK the only reason it is still in contrib is the fact that it can't work on Windows. Yes, I discovered it at least in part via my Mac, where Homebrew installs it as part of the core Git installation too. I'd been planning on just adding it as a new package in Cygwin, without really thinking about whether that's actually the right thing to do; do you/anyone else think it'd be preferable to just roll this into the main Cygwin package instead of defining a new one? (I'm assuming its dependencies are a subset of those for the main Git package; if it doesn't that'd be a very strong argument for keeping them separate.) I'd like to start adding this to the stack of Git packages I build and distribute. I don't think the build stage is going to be difficult, but what (if anything) do I need to do to get git-subtree as a package that's in setup.ini? Is it just a case of uploading the new package and setup.hint, or do I need to do some additional magic? If it's a sub-package (i.e. the source package is git), then you just package it up the usual way. If you'd want it standalone (not advisable in this case) you would need to ITP it so it gets added to the list of packages you maintain. Yes, my expectation was that it'd fall under my responsibility as Git maintainer, rather than being something that's tracked separately, although I wasn't entirely sure whether just adding the new package would require an ITP (although given it's included in several other major distros, I didn't think there'd be a problem there either way). Good to know that, since it comes from the same source and is already included in the source bundle for the Git packages, that I don't need to do anything to add the new package to those available other than update git.cygport to build and package the new files. BTW, git-merge-changelog (from GNUlib) would be a candidate for this treatment and is currently lacking from Cygwin. Not something I've heard of until now, but it seems sensible. Are you planning on ITPing this yourself, or would you like me to look at maintaining it? I'm happy with either, provided building it on Cygwin is reasonably trivial; it's not a tool I use so I can't say I'm particularly invested in spending time on it. Adam
Adding a subpackage
I've discovered a neat Git tool -- git subtree -- which is part of Git's contrib directory and isn't something we currently distribute as part of any of the existing Git-related packages. I'd like to start adding this to the stack of Git packages I build and distribute. I don't think the build stage is going to be difficult, but what (if anything) do I need to do to get git-subtree as a package that's in setup.ini? Is it just a case of uploading the new package and setup.hint, or do I need to do some additional magic? Adam
Re: [Attn Maintainer] git git-svn
On Sun, Aug 02, 2015 at 08:35:25AM +0200, Achim Gratz wrote:
The tests for 2.5.0 just completed:
--8---cut here---start-8---
fixed 1
success 12528
failed 0
broken 179
total 12808
--8---cut here---end---8---
…on both architectures. I do not have cvs installed, so those tests (as
well as Perforce) have not run.
I'm going to continue to be cautious: while I think the risk of bumping
up to v2.5.0 is very low, if there are problems with that or any of the
other numerous recent changes (this has been the first time a release
has got above the -1 version since I took over maintainership), I want
to keep the changes reasonably slow to help narrow down where the
problem comes from.
A few suggestions for changes to the cygport:
--8---cut here---start-8---
SRC_URI=https://git.kernel.org/cgit/git/git.git/snapshot/${PN}-v${PV}.tar.gz;
SRC_DIR=${PN}-v${PV}
--8---cut here---end---8---
Then not inherit git, a snapshot is less wasteful then the cloning
unless you plan to really work with the repository which cygport makes
difficult anyway.
Done. I switched from something similar when I took over the
maintainership, as using inherit git seemed like The Right Thing To Do
when I was first playing around with Cygport. As you say, though, it's
just adding overhead with no advantage. (Indeed if I want to play
around with the Git repository itself, I already have a copy of that
ready to go.)
--8---cut here---start-8---
[[ $ARCH_x86_64 ]] DEPEND=$DEPEND libiconv libiconv-devel
--8---cut here---end---8---
Drop this line and add libiconv, libiconv-devel plus dblatex to the
DEPENDS unconditionally.
I'm sure when I first added that line, it made sense with the
dependencies. I've made this change as well now, though, as it seems to
be the right thing to do at this point.
Thanks!
Adam
Re: [Attn Maintainer] git git-svn
On Sat, Aug 01, 2015 at 08:17:59PM +0200, Achim Gratz wrote: Adam Dinwoodie writes: I think git-svn should and used to depend on subversion-perl, but this seems to have gone missing, somehow. How very odd! That was one of the automatically generated dependencies, so presumably the dependency generation has just gone a bit sideways, probably because of the Perl version change. I don't think so, that package hasn't been renamed or anything like that. As long as the installed.db and the *.lst.gz files are OK, it should find these. Well my latest rebuild picked up the dependency automatically, and the only thing I can think of that changed between the two is that I picked up the latest version of subversion-perl. Whatever it was, it's fixed now :)
Re: [Attn Maintainer] git git-svn
On 01/08/2015 15:18, Jon TURNEY wrote: On 30/07/2015 20:41, Achim Gratz wrote: Adam Dinwoodie writes: These packages are now uploaded, with a !perl file instead of a !ready file. Thanks. I'm going to look at taking the latest upstream releases once the new version of Perl has been released; I didn't want to take a version bump while we are also taking other changes. I think git-svn should and used to depend on subversion-perl, but this seems to have gone missing, somehow. How very odd! That was one of the automatically generated dependencies, so presumably the dependency generation has just gone a bit sideways, probably because of the Perl version change. I'm expecting to be away for most of the weekend, so I'll try and rebuild early next week; hopefully once all the other Perl-related packages have stabilised, it'll pick up the dependency automatically again, but if not, I'll just add it manually. (In theory I could go digging into how Cygport works out such dependencies, but it's all black magic to me so I'm just going to take the lazy option for now.)
Re: [HEADSUP] Perl update to 5.22.0
On Fri, Jul 31, 2015 at 11:42:53PM +0200, Achim Gratz wrote: With the invaluable help of Yaakov and John on the server side, the mass update of all things Perl is now complete. I would like to thank all maintainers for helping with re-releases of their packages. I don't know if that's my call to make, but I'd like to ask for a round of gold stars for: John, Yaakov, Adam, David, Marco, Jari, Ken and Andrew (in no particular order). Don't get too keen: I've just realised I didn't change the Git version number when I packaged it. I'm repackaging now with a new build number, so setup-*.exe will pick it up correctly. Adam
Re: [Attn Maintainer] git git-svn
On Tue, Jul 28, 2015 at 07:43:56AM +0200, Achim Gratz wrote: Adam Dinwoodie writes: I'm just waiting for it to finish running through the test suite before I upload :) Thank you. These packages are now uploaded, with a !perl file instead of a !ready file. I'm going to look at taking the latest upstream releases once the new version of Perl has been released; I didn't want to take a version bump while we are also taking other changes.
