Re: maintainer email address change
> On 12/01/2024 14:43, Andrew Schulman via Cygwin-apps wrote: > > I need to update my maintainer email address, to > > andrex_dot_e_dot_schulman_at_gmail_dot_com. I don't see my current address > > stored anywhere in the cygwin-htdocs, so I guess it's stored somewhere else, > > since calm sends me emails there. Thanks, Andrew > > By long-standing, if not clearly stated, policy, we treat maintainer > email addresses as private information, so it's not stored anywhere public. > > In future, please note that there is a self-service way to do this [1], > but I have updated this for you. > > [1] https://cygwin.com/package-upload.html#reports Oh, thank you! Yes, I might have remembered that. It's been a long time since I uploaded that file. Thanks for your help. Andrew
maintainer email address change
I need to update my maintainer email address, to andrex_dot_e_dot_schulman_at_gmail_dot_com. I don't see my current address stored anywhere in the cygwin-htdocs, so I guess it's stored somewhere else, since calm sends me emails there. Thanks, Andrew
Re: [ITA] pocl
> On 03/01/2024 06:25, Takashi Yano via Cygwin-apps wrote: > > On Wed, 3 Jan 2024 14:14:12 +0900 > > Takashi Yano via Cygwin-apps wrote: > >> I'd like to adopt the pocl package. > >> > >> - Update to latest upstream release. > > $ git diff |grep "^+" > +++ b/cygwin-pkg-maint > +pocl Takashi Yano Gold star awarded! https://cygwin.com/goldstars/#TY
Re: adopting
> On 22/12/2023 03:49, Marco Atzeri via Cygwin-apps wrote: > > Following the inputs from Jon > > https://cygwin.com/packages/reports/unmaintained.html > > > > I am taking over > > > > $ git diff | grep "^+" > > +++ b/cygwin-pkg-maint > > +alternatives Marco Atzeri > > +bzip2 Marco Atzeri > > +gdbm Marco Atzeri > > +libffi Marco Atzeri > > Very much appreciated. > > More gold stars for you! Yes indeed! https://cygwin.com/goldstars/#MA Especially thanks for taking over alternatives. I looked at that one myself a while back, and in the time I had I couldn't finish untangling where we got it and which parts we were using. The cygport script needs an overhaul I think.
Re: [ITA] wavpack
> I'd like to adopt the package wavpack. > Thanks in advance. 3 gold stars! For limbsamplerate, soxr, and wavpack. https://cygwin.com/goldstars/#TY
[ITA] jq
I'd like to adopt the jq package. It's currently orphaned from Yaakov. I have an updated build script ready to push up for the current release (1.6-1), and a new release (1.7) is expected soon. Andrew
Re: what license is this?
> Hi, Andrew et al., > > > https://github.com/jqlang/jq/blob/master/COPYING > > Debian uses the following in its /usr/share/doc/jq/copyright file: > > License: MIT > License: CC-BY-3.0 > License: Expat > License: GPL-2.0+ > > That might help... Thank you, and Achim! And sorry for being so grumpy about it. The whole license thing is just a joy suck. Thanks for your help. Andrew
what license is this?
https://github.com/jqlang/jq/blob/master/COPYING Most parts of this are "as is, do what you want but preserve this notice." That has the spirit of the Beerware license[1], but it's not exactly that. I'm sure there must be another license on the SPDX list[2] that fits better, but I can't tell which one without reading them all, which would make me want to kill myself. The rest seems to be covered by CC-BY-3.0 AND ICU. I wish people wouldn't get so creative with their licenses. Thanks, Andrew [1] https://spdx.org/licenses/Beerware.html [2] https://spdx.org/licenses/
Re: chattr makes cygport slow
> On 16/07/2023 20:32, ASSI via Cygwin-apps wrote: > > Jon Turney via Cygwin-apps writes: > >> The warning (error if RESTRICT=case_insensitive) should occur for all > >> commands, not just prep. > > > > OK. > > > >> How about the attached. > > > > Looks promising. > > Ok. I made a cygport 0.36.6 release with this change. > > Please let me know if it makes things better (or worse!)? So much better. Thank you. Andrew
Re: chattr makes cygport slow
> On 06/07/2023 18:36, Andrew Schulman via Cygwin-apps wrote:
> >> Recently I noticed that `cygport finish` has become really slow on some of
> >> my
> >> package source trees. After I run for example
> >>
> >> cygport libargp.cygport finish
> >>
> >> it waits for about 5 minutes without any message to the console, before the
> >> first "Removing work directory" message appears.
> >>
> >> pstree shows that during this time cygport is waiting for chattr. In
> >> /usr/bin/cygport I see:
> >>
> >> if [ $OSTYPE = "cygwin" ]
> >> then
> >> chattr -fR +C ${workdir} >/dev/null 2>&1 || true
> >> fi
> >>
> >> which is trying to make the workdir case-sensitive.
> >>
> >> Whatever the advantages of that are, it can take a long time. Would it be
> >> possible to skip it at least in the case of "finish"? It seems silly to
> >> spend
> >> all that time fixing up a directory tree that we then turn around and
> >> remove
> >> with rm -rf.
>
> For a long time, we've just been assuming that anyone using cygport has
> case-sensitivity turned on somehow (as the build underling a cygport
> might assume that it's present, as is normal on a unix)
>
> So, the idea here is that we try to ensure it's on, at least for the
> working directory.
>
> Skipping it when 'finish' is used isn't right, because then 'finish all'
> wouldn't work as desired. But yeah, it seems that this is in the wrong
> place. I'll look into moving it.
Thanks. Annoying, I realize. Unfortunately doing it separately for each command
isn't right either, if it runs 3 times instead of once when I run 'cygport prep
make inst'.
Also, just fixing it for 'finish' would still leave the delay for the other
commands. Maybe a switch that would allow turning it off, either host-wide in
~/.cygport.conf, or for a project that didn't need it in *.cygport.
> I think there's possibly something else going wrong if it's taking 5
> minutes, as that seems excessive.
Could be BLODA. My host has MS antivirus.
Re: chattr makes cygport slow
> Recently I noticed that `cygport finish` has become really slow on some of my
> package source trees. After I run for example
>
> cygport libargp.cygport finish
>
> it waits for about 5 minutes without any message to the console, before the
> first "Removing work directory" message appears.
>
> pstree shows that during this time cygport is waiting for chattr. In
> /usr/bin/cygport I see:
>
> if [ $OSTYPE = "cygwin" ]
> then
> chattr -fR +C ${workdir} >/dev/null 2>&1 || true
> fi
>
> which is trying to make the workdir case-sensitive.
>
> Whatever the advantages of that are, it can take a long time. Would it be
> possible to skip it at least in the case of "finish"? It seems silly to spend
> all that time fixing up a directory tree that we then turn around and remove
> with rm -rf.
And/or, maybe add a switch to suppress it. I've commented it out of my
/usr/bin/cygport for now, because it makes me wait an extra 5 minutes before
every cygport command, at least on this particular source tree with 12K files in
it.
chattr makes cygport slow
Recently I noticed that `cygport finish` has become really slow on some of my
package source trees. After I run for example
cygport libargp.cygport finish
it waits for about 5 minutes without any message to the console, before the
first "Removing work directory" message appears.
pstree shows that during this time cygport is waiting for chattr. In
/usr/bin/cygport I see:
if [ $OSTYPE = "cygwin" ]
then
chattr -fR +C ${workdir} >/dev/null 2>&1 || true
fi
which is trying to make the workdir case-sensitive.
Whatever the advantages of that are, it can take a long time. Would it be
possible to skip it at least in the case of "finish"? It seems silly to spend
all that time fixing up a directory tree that we then turn around and remove
with rm -rf.
Thanks,
Andrew
Re: [GOLDSTAR] Re: [ITA] ruby 3.2.2
> On 19/04/2023 23:42, Daisuke Fujimura via Cygwin-apps wrote: > > Hello, > > > > > > > > Cygportfile: > > - > > https://cygwin.com/git-cygwin-packages/?p=git/cygwin-packages/playground.git;a=shortlog;h=refs/heads/ruby > > > > Packages, logs: > > - https://github.com/cygwin/scallywag/actions/runs/4743191979 > > According to our rules, Fujimura-san deserves one of our literally > priceless gold stars for adopting Ruby. > > ... and several more, arranged into a tasteful tiara or something, for > adopting and updating various ruby language packages. Awarded! https://cygwin.com/goldstars/#DF
Re: Trusted maintainers (was: Re: How does a package become orphaned? (was Re: Attn maintainer: python-paramiko))
> On 11.05.2023 15:57, Andrew Schulman via Cygwin-apps wrote: > >> Entrusted with these strange superpowers, the following god-like beings > >> walk unknown amongst us: > >> > >> Achim Gratz > >> Corinna Vinschen > >> Ken Brown > >> Marco Atzeri > > > > Hippos! https://cygwin.com/goldstars/ > > > > I have the impression that Jon is also in the list > > another Hippo please for all the work he is doing on the infrastructure > of the Cygwin project. > > Marco Awarded! https://cygwin.com/goldstars/#JTy
Re: Trusted maintainers (was: Re: How does a package become orphaned? (was Re: Attn maintainer: python-paramiko))
> Entrusted with these strange superpowers, the following god-like beings > walk unknown amongst us: > > Achim Gratz > Corinna Vinschen > Ken Brown > Marco Atzeri Hippos! https://cygwin.com/goldstars/
Re: pinfo build fails with undefined macro: AM_INTL_SUBDIR
> On Apr 11 09:21, Andrew Schulman via Cygwin-apps wrote: > > I'm trying to rebuild pinfo 0.6.13. That's the current version in Cygwin, > > so I > > know I was able to build it successfully a couple of years ago. But now > > when I > > try, the build fails with > > > > error: possibly undefined macro: AM_INTL_SUBDIR > > Check configure.ac which version of autotools is required. There's a > good chance you need autoconf 2.69. You can probably fix that problem > in the cygport file by adding > > WANT_AUTOCONF="2.5" Thanks. I tried several different values of WANT_AUTOCONF and WANT_AUTOMAKE, but they didn't help. From what I can tell, AM_INTL_SUBDIR is just gone from automake now. So I removed the call to AM_INTL_SUBDIR, and that build problem is fixed. Anyway thanks for pointing me in a direction. Andrew
pinfo build fails with undefined macro: AM_INTL_SUBDIR
I'm trying to rebuild pinfo 0.6.13. That's the current version in Cygwin, so I
know I was able to build it successfully a couple of years ago. But now when I
try, the build fails with
error: possibly undefined macro: AM_INTL_SUBDIR
I'm afraid my grasp of autotools is too weak for me to know what the problem is
here. At present I'm using the inherited src_complile() function from
autotools.cygclass. In the past I used:
src_compile ()
{
cd "$S"
gettextize -f # needed to create tools/config.rpath
cygautoreconf --install
cd "$B"
cygconf
cygmake
}
but that doesn't fix the AM_INTL_SUBDIR problem.
The full build log is below. Could someone suggest a solution?
Thanks,
Andrew
$ cygport pinfo.cygport make
*** Warning: Building on a case-insensitive filesystem
>>> Compiling pinfo-0.6.13-3.x86_64
autoreconf-2.71: export WARNINGS=
autoreconf-2.71: Entering directory '.'
autoreconf-2.71: running: /usr/bin/autopoint -V 0.21.1 --force
autopoint: warning: Version mismatch: specified -V 0.21.1 but the package uses
gettext version 0.14.4. Forcibly upgrading to 0.21.1
autoreconf-2.71: running: aclocal --force -I macros
configure.ac:144: warning: macro 'AM_INTL_SUBDIR' not found in library
autoreconf-2.71: configure.ac: tracing
autoreconf-2.71: running: libtoolize --copy --force
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'tools'.
libtoolize: copying file 'tools/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'macros'.
libtoolize: copying file 'macros/libtool.m4'
libtoolize: copying file 'macros/ltoptions.m4'
libtoolize: copying file 'macros/ltsugar.m4'
libtoolize: copying file 'macros/ltversion.m4'
libtoolize: copying file 'macros/lt~obsolete.m4'
autoreconf-2.71: configure.ac: not using Intltool
autoreconf-2.71: configure.ac: not using Gtkdoc
autoreconf-2.71: running: aclocal --force -I macros
configure.ac:144: warning: macro 'AM_INTL_SUBDIR' not found in library
autoreconf-2.71: running: /usr/bin/autoconf-2.71 --force
configure.ac:55: warning: The macro `AC_PROG_CC_C99' is obsolete.
configure.ac:55: You should run autoupdate.
/mnt/share/cygpkgs/autoconf2.7/autoconf2.7.noarch/src/autoconf-2.71/lib/autoconf/c.m4:1659:
AC_PROG_CC_C99 is expanded from...
configure.ac:55: the top level
configure.ac:104: warning: The macro `AC_CHECKING' is obsolete.
configure.ac:104: You should run autoupdate.
/mnt/share/cygpkgs/autoconf2.7/autoconf2.7.noarch/src/autoconf-2.71/lib/autoconf/general.m4:2499:
AC_CHECKING is expanded from...
macros/readline.m4:102: AC_SEARCH_READLINE is expanded from...
macros/readline.m4:46: AC_CHECK_READLINE is expanded from...
configure.ac:104: the top level
configure.ac:104: warning: The macro `AC_FD_CC' is obsolete.
configure.ac:104: You should run autoupdate.
/mnt/share/cygpkgs/autoconf2.7/autoconf2.7.noarch/src/autoconf-2.71/lib/autoconf/general.m4:399:
AC_FD_CC is expanded from...
macros/readline.m4:111: AC_READLINE_VERSION is expanded from...
macros/readline.m4:46: AC_CHECK_READLINE is expanded from...
configure.ac:104: the top level
configure.ac:159: error: possibly undefined macro: AM_INTL_SUBDIR
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
autoreconf-2.71: error: /usr/bin/autoconf-2.71 failed with exit status: 1
*** ERROR: autoreconf failed
Re: does this match an SPDX license?
> On 2023-04-10 07:17, Andrew Schulman via Cygwin-apps wrote: > > autossh comes with the license shown below. Is there an SPDX license > > identifier > > (https://spdx.org/licenses/) that I can associate with this? It looks most > > like > > public domain to me. Thanks, Andrew > > > > autossh is copyright (c) Carson Harding, 2005. > > All rights reserved. > > > > Redistribution and use in source and binary forms, with or without > > modification, are freely permitted. > > > > THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, > > INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY > > AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL > > THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, > > SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, > > PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; > > OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, > > WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR > > OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF > > ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. > > Not that I have seen or can find: where did you find the text, so I can ask? The author of autossh, Carson Harding, emailed me the license text years ago, after I asked him what license he wanted to use. I could email him again to ask if there's a standard license he wants to use; just thought I'd check here first. > This is a totally permissive licence, without any conditions, just warranty > and > liability disclaimers. > > You could use e.g. LicenseRef-motd-autossh-permissive-no-conditions for now. Thanks. I think that will do for now. Andrew
does this match an SPDX license?
autossh comes with the license shown below. Is there an SPDX license identifier (https://spdx.org/licenses/) that I can associate with this? It looks most like public domain to me. Thanks, Andrew autossh is copyright (c) Carson Harding, 2005. All rights reserved. Redistribution and use in source and binary forms, with or without modification, are freely permitted. THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
[ITP] fish-doc
In the next release of fish, I'm going to split the package into fish and fish-doc. I can't remember if someone needs to add me to the maintainers list for the new fish-doc package, or if that happens automatically since they're created from the same source package. If someone does need to add me as the maintainer of fish-doc, can you please do that? Thank you, Andrew
Re: [GOLDSTAR] Re: [ITA] libsndfile (1.2.0)
> > I've given you the adopted packages: libsndfile, mpg123, opus, > > opus-tools, opusfile, SDL2. I'll look at the rest later. > > Please accept these literally priceless gold stars for adopting these > packages. Awarded! https://cygwin.com/goldstars/#TY
Re: Cygwin x86 end-of-life
> On 11/11/2022 16:16, Jon Turney wrote: > > On 11/11/2022 15:50, Jon Turney wrote: > >> > >> As has previously been announced, Cygwin is dropping support for x86 > >> Windows. Cygwin 3.3.6 is the final version supporting x86 (32-bit) > >> Windows, and the forthcoming Cygwin 3.4 will be released for x86_64 only. > >> > >> Concurrent with that, updates to x86 packages will be stopped, and the > >> Cygwin x86 package repository will be archived. > > > > I plan to pause package uploads this coming Monday (2022-11-14), before > > starting the re-organization of the package repository to make this > > archive. > > Since there have been some complaints about short notice, and to give > time to work out the issues with gettext/libunistring, I'm going to > defer this by one week, until Monday 2022-11-21. Thank you!
Re: Cygwin x86 end-of-life
> > Am 11.11.2022 um 17:16 schrieb Jon Turney: > > On 11/11/2022 15:50, Jon Turney wrote: > >> > >> As has previously been announced, Cygwin is dropping support for x86 > >> Windows. Cygwin 3.3.6 is the final version supporting x86 (32-bit) > >> Windows, and the forthcoming Cygwin 3.4 will be released for x86_64 > >> only. > >> > >> Concurrent with that, updates to x86 packages will be stopped, and > >> the Cygwin x86 package repository will be archived. > > > > I plan to pause package uploads this coming Monday (2022-11-14), > > before starting the re-organization of the package repository to make > > this archive. > Although expected for a while, the exact date is now a very short-time > announcement. Can we have a moratorium for a short while? Agree. Maybe I should have known from previous announcements that the forever cutoff date was today, but I didn't. I'm now in the process of updating a couple of packages that need it, so the i686 archive will reflect the latest available versions. It would be helpful if we had a couple more days to update before the portcullis comes down. Thanks, Andrew
[ITP] unison
I want to maintain a new Unison package, this time called - ready? - unison. Starting with the current release, version 2.52, the Unison project has solved the version incompability problems that caused us to have to maintain multiple packages, like unison2.49, unison2.51+4.04.2, and so on. Versions 2.52 and later will all come in just one package, unison. Many Unison users will be able to upgrade to the new unison, and uninstall the old ones. But I'm not obsoleting the old ones, because the new release is only compatible with old versions going back to 2.48, and many long-lived distros still have Unison versions older than that. So users who sync with those hosts will still need to keep the old packages installed for some time. Andrew
Re: replacing a previous package verson
> On 11/04/2022 14:02, Andrew Schulman via Cygwin-apps wrote:
> > After all this time I feel that I should know the answer to this, but here
> > goes.
> >
> > I have fish-3.4.1-1, a bugfix release. I want it to replace fish-3.4.0-1,
> > leaving fish-3.3.1-1 as the previous release.
> >
> > What's the best way to do this? Should I create override.hint, with
>
> > keep: 3.3.1-1
>
> This alone means 'keep 3.3.1-1 as well as anything else you would keep'.
>
> Since that seems to be what you really want ('keep previous major
> version around '), I'd suggest just doing that.
Thanks!
Re: replacing a previous package verson
> After all this time I feel that I should know the answer to this, but here > goes. > > I have fish-3.4.1-1, a bugfix release. I want it to replace fish-3.4.0-1, > leaving fish-3.3.1-1 as the previous release. > > What's the best way to do this? Should I create override.hint, with > > keep: 3.3.1-1 > replace-versions: 3.4.0-1 > > ? This seems as though it might be right, but one question I have is, will > override.hint persist in future releases unless I replace it? Or, should I just set prev: 3.3.1-1 in fish.cygport, and let cygport and calm handle it from there?
replacing a previous package verson
After all this time I feel that I should know the answer to this, but here goes. I have fish-3.4.1-1, a bugfix release. I want it to replace fish-3.4.0-1, leaving fish-3.3.1-1 as the previous release. What's the best way to do this? Should I create override.hint, with keep: 3.3.1-1 replace-versions: 3.4.0-1 ? This seems as though it might be right, but one question I have is, will override.hint persist in future releases unless I replace it? Thanks, Andrew
Re: New packages: unison2.51+4.04.2, unison2.51+4.10.0
> > Since I marked unison2.51+4.04.2 as obsoletes: unison2.51, it seems that > > unison2.51 now needs to be removed as a separate package? calm says: > > > > ERROR: package 'unison2.51' is at paths unison2.51 and > > unison2.51+4.10.0/unison2.51 > > this says that unison2.51+4.10.0 obsolets unison2.51 > not unison2.51+4.04. > > Can you confirm ? Sorry for the confusion. I posted the wrong error message. Since unison2.51 can only appear in one place, it should be obsoleted by unison2.51+4.04.2, which uses the same OCaml version. So Jon, can you please move unison2.51 under unison2.51+4.04.2 ? > > Can you help with that? > > my usual solution is > > create directory unison2.51+4.10.0 > move directory unison2.51 under unison2.51+4.10.0 > > this will allow the upload. I did that, but I still got the error message, I think when calm tried to move my upload into the main file location. Andrew
Re: New packages: unison2.51+4.04.2, unison2.51+4.10.0
> On 22.12.2021 17:21, Andrew Schulman via Cygwin-apps wrote: > > Please add me as maintainer of two new unison packages: > > > > unison2.51+4.04.2 > > unison2.51+4.10.0 > > > > These will obsolete the current unison2.51 package. > > > > Thanks, Andrew > > > > added. Since I marked unison2.51+4.04.2 as obsoletes: unison2.51, it seems that unison2.51 now needs to be removed as a separate package? calm says: ERROR: package 'unison2.51' is at paths unison2.51 and unison2.51+4.10.0/unison2.51 Can you help with that? Thanks, Andrew
Re: New packages: unison2.51+4.04.2, unison2.51+4.10.0
> On 22.12.2021 17:21, Andrew Schulman via Cygwin-apps wrote: > > Please add me as maintainer of two new unison packages: > > > > unison2.51+4.04.2 > > unison2.51+4.10.0 > > > > These will obsolete the current unison2.51 package. > > > > Thanks, Andrew > > > > added. Thanks. > Question: why Unison need all these versions ? > > $ grep "unison" cygwin-pkg-maint > unison2.27 Andrew Schulman > unison2.32 Andrew Schulman > unison2.40 Andrew Schulman > unison2.45 Andrew Schulman > unison2.48 Andrew Schulman > unison2.48+4.04.2Andrew Schulman > unison2.48+4.08.1Andrew Schulman > unison2.49 Andrew Schulman > unison2.51 Andrew Schulman > unison2.51+4.04.2Andrew Schulman > unison2.51+4.10.0Andrew Schulman Yeah. It's too complicated. The problem is that different versions of unison are only compatible with each other if the first two numbers of the Unison version are the same, AND they were compiled with compatible versions of OCaml. The underlying problem is that both Unison and OCaml have changed their "marshaling" or data serialization format over time. If the marshaling formats are different, data could be corrupted. To prevent that, Unison will quit if it connects to an incompatible version on the other end. So this is a headache for packagers. We don't know what version might be running on the other end, so we have to provide a bunch of different versions, so users are likely to have one that works for them. The Unison README.Cygwin file has more information. This problem has been discussed a lot recently on the Unison lists. The Unison devs are aware of it and are working towards a future release that will start to preserve backwards compatibility if the marshaling format changes again in the future. Andrew
New packages: unison2.51+4.04.2, unison2.51+4.10.0
Please add me as maintainer of two new unison packages: unison2.51+4.04.2 unison2.51+4.10.0 These will obsolete the current unison2.51 package. Thanks, Andrew
Re: [ATTN MAINTAINERS] OpenSSL 1.0 dependencies
> > We should get rid of dependencies to the obsolete OpensSSL 1.0 library > that is no longer maintained upstream and has several critical bugs. > > Current and previous versions of the following packages depend on the > outdated libopenssl100 (a lot of these have many packages depending on > them in turn and/or are orphaned): ... > lftp ... Are you sure about lftp? AFAIK it only uses libssl1.1: $ lftp --version LFTP | Version 4.9.2 | Copyright (c) 1996-2020 Alexander V. Lukyanov ... Libraries used: Expat 2.4.1, idn2 2.3.2, libiconv 1.16, OpenSSL 1.1.1l 24 Aug 2021, Readline 8.1, zlib 1.2.11 $ ldd /usr/bin/lftp | grep ssl cygssl-1.1.dll => /usr/bin/cygssl-1.1.dll (0x4c7bc)
Re: updated ssh key
> I ran my script to update your key, but it didn't seem to do anything, > which confused me, until I noticed this appears to be the same as your > current key [1]. > > [1] https://cygwin.com/pipermail/cygwin-apps/2020-February/039822.html Doh. Thanks.
updated ssh key
Name: Andrew Schulman BEGIN SSH2 PUBLIC KEY Comment: "384-bit ECDSA, created by Andrew Schulman" E2VjZHNhLXNoYTItbmlzdHAzODQIbmlzdHAzODQAAABhBIh5WtQRqhzLyhiCds BhExlJjXY+NeKxt7tp3l4ViEOwGAPmiMp9keikNzVrpBy2poorumkZDCJrCxx3855UxdnV E51GAO7toxiCMM8BNHX3fnDj6rgydpjCNRStBQUqWQ== END SSH2 PUBLIC KEY
Re: [ATTN. Maintainer] libargp
> Achim Gratz writes: > > The files are on the libargp branch of the playground repository: > > https://cygwin.com/git-cygwin-packages?p=git/cygwin-packages/playground.git;a=shortlog;h=refs/heads/libargp > > I've updated the branch with a bugfix. Some parts had been refactored > out of argp.h into config.h so the standalone library (which doesn't > install config.h of course) would build & test OK, but you couldn't > compile a project using the installed version. I'm putting these > definitions back during install and you can actually compile with it > now, both on the native and the MinGW64 toolchains. I've also > re-arranged a things so that the source package actually has all the > files necessary for building. Thank you! I haven't updated that package in years. I'll take a look soon. Andrew
Re: [PATCH cygport] Update xorg.cygclass URLs [GOLDSTAR]
> On Thu, 08 Apr 2021 19:26:44 -0400, Andrew Schulman via Cygwin-apps > > Awarded! > > > > https://cygwin.com/goldstars/#LM > > https://cygwin.com/goldstars/#AG > > Thank you! > > Lem BTW I wanted to name you #LL in the Gold stars page, but that name is already taken, by Lapo Luchini. If you prefer another acronym, let me know and I'll change it. #Lem? Andrew
[ITA] pv
I want to maintain pv, since it's being orphaned. I lightly updated the old cygport script, and checked that the latest version, 1.6.6, builds OOTB. Will upload the new release as soon as it's approved. Thanks, Andrew
Re: [PATCH cygport] Update xorg.cygclass URLs [GOLDSTAR]
> On Tue, 2021-01-05 at 15:06 +0100, Achim Gratz wrote: > > Yaakov Selkowitz via Cygwin-apps writes: > > > In fact, there are probably a bunch of other http: which could be > > > converted to https: at this point. I would suggest anyone who does > > > that (in separate commit(s)) should get a gold star. > > > > The patch series from Lem plus another handful of cleanups is available > > at: > > > > https://repo.or.cz/cygport/rpm-style.git/shortlog/refs/heads/URL-updates > > Thank you Lem for the patches, and Achim for gathering them together on a > branch. It was surely tedious work, but necessary and much appreciated. > These are (finally!) merged, can we get some gold stars please? Awarded! https://cygwin.com/goldstars/#LM https://cygwin.com/goldstars/#AG
Re: [Attn. Maintainers] prepare your packages for release of perl-5.32
> Andrew Schulman via Cygwin-apps writes: > > Packaging error will be fixed in the forthcoming stow-2.3.1+5.32-1, which > > will be compatible with perl-5.32. So same release as the perl update. > > Please let us know when you have uploaded the package. Thanks. Uploaded stow-2.3.1+5.32-1.
Re: [Attn. Maintainers] prepare your packages for release of perl-5.32
> Andrew Schulman via Cygwin-apps writes: > > Thank you. stow is ready now. And no, I hadn't seen the packaging error - > > fixed in the next release. > > You mean the one that you've just readied or another one? I'd prefer if > it was fixed in coincidence with the update if it isn't too much of a > bother for you. Packaging error will be fixed in the forthcoming stow-2.3.1+5.32-1, which will be compatible with perl-5.32. So same release as the perl update.
Re: [Attn. Maintainers] prepare your packages for release of perl-5.32
> On 2/4/2021 9:04 AM, Ken Brown via Cygwin-apps wrote: > > On 2/4/2021 7:10 AM, Andrew Schulman via Cygwin-apps wrote: > >>> The Perl 5.32 test repository is now updated with the stage 3 bootstrap > >>> packages at: > >>> > >>> root=http://cygwin.stromeko.net/ > >>> $root/perl-5.32 > >> > >> Not sure I understand. In setup I entered > >> > >> http://cygwin.stromeko.net/perl-5.32 > >> > >> as a mirror URL, but setup complains: > >> > >> Mirror error: Setup.ini signature > >> http://cygwin.stromeko.net/perl-5.32/x86_64/setup.xz.sig from > >> http://cygwin.stromeko.net/perl-5.32 failed to verify. > > > > Try adding '-K http://cygwin.stromeko.net/stromeko.gpg' to your invocation > > of > > setup. > > P.S. I assume you're asking about this so that you can rebuild perl-Stow. In > case you missed it, Achim made a packaging suggestion here: > > https://cygwin.com/pipermail/cygwin/2021-January/247594.html > > Ken Thank you. stow is ready now. And no, I hadn't seen the packaging error - fixed in the next release.
Re: [Attn. Maintainers] prepare your packages for release of perl-5.32
> The Perl 5.32 test repository is now updated with the stage 3 bootstrap > packages at: > > root=http://cygwin.stromeko.net/ > $root/perl-5.32 Not sure I understand. In setup I entered http://cygwin.stromeko.net/perl-5.32 as a mirror URL, but setup complains: Mirror error: Setup.ini signature http://cygwin.stromeko.net/perl-5.32/x86_64/setup.xz.sig from http://cygwin.stromeko.net/perl-5.32 failed to verify. Am I doing that wrong? Thanks, Andrew
Re: [ITP] no-more-secrets 0.3.3
> Hello, > > [ITP] A new package proposal: no-more-secrets > > - no-more-secrets > > > > SUMMARY: Recreation of the decrypting text effect from the 1992 movie Sneakers > HOMEPAGE: https://github.com/bartobri/no-more-secrets > SRC_URL: https://github.com/bartobri/no-more-secrets/archive/v0.3.3.tar.gz > LICENSE: GNU General Public License v3.0 LOL +1! More games for Cygwin!
Re: [RFC] cygport pm for managing package releases
> I'm very keen on reducing the maintainer workload by increasing the > automation available to them. Good. > However, I'm not so sure about the approach proposed, which perpetuates > the 'create strange files which have a special meaning when uploaded > causing something non-obvious to happen' behaviour. > > I think I'd perhaps rather just extend the work done with 'untest' [2] > to allow maintainers to do these things directly. > > [2] > https://cygwin.com/git/?p=cygwin-apps/calm.git;a=commit;h=0a29ad572cbe1bcc64fd3624f5c38eee79c50445 I'm all in favor of using simpler methods. I just want to collect them all in one place in cygport, so maintainers - * don't have to remember, care, or find documentation for what the details are for different package management functions; * don't have to keep track as those methods change or improve; * can rely on a stable and documented set of cygport commands to manage their packages. So as better automation becomes available, like the untest feature, we can build that into cygport. But the maintainers won't necessarily have to know; they can still just run cygport pm untest, for example. Andrew
New package: socat2
Please create a new package socat2, with me as the maintainer. It seems that socat versions 1 and 2 are long-term different, and creating a separate socat2 package will allow me to stop treating socat 2.x releases as perpetually in test. Thanks, Andrew
[RFC] cygport pm for managing package releases
cygport has automated a lot of the work of building and maintaining packages for Cygwin. But one area where it doesn't help yet is in managing the available releases of a package. For me as the maintainer of a dozen or so packages, there are routine tasks that I still find to be painful: * Finding out which versions of a package are currently available in the Cygwin repositories, and which if any are marked as "test". * Marking or unmarking a version as "test". * Removing versions from the repositories. * Marking a package as obsolete. All of these are still manual tasks. Most require digging through documentation (though that's also much improved in the last few years), manually editing .hint files or creating dummy package files, and manually uploading files to the right places in sftp://cygwin.com. It's not fun, and so I don't keep up with it as well as I should. To alleviate that, I think cygport should add a set of "pm" commands to automate package management. For example: * cygport pm list - list versions available in the Cygwin repositories. * cygport pm test - set/clear "test" status for a version. * cygport pm del - remove a package version from the repositories. * cygport pm obsolete - mark a package as obsolete. And probably others. I think this would make maintainer's lives easier, and make these management tasks more reliable. I can spend some time planning and developing this, and if others want to collaborate on it, so much the better. But before I start on that, I want to get people's comments here about whether: * It's worth doing; * (More to the point) It'd be likely to be accepted upstream, assuming the implementation is satisfactory; and * There may be problems in implementing it that I haven't thought of. I can think of a few problems or objections: 1. The "pm" commands will bake into cygport logic that's specific to how the package repositories and upset currently work. So if those change, cygport will have to change to match them. That's true, but not just for cygport pm - other parts of cygport, such as cygport up, are basically clients for upset. And at least it'll centralize the changes in one place, so maintainers won't have to worry about them. 2. "pm list" will require finding and parsing an appropriate setup.ini file, unlike the other "pm" commands which will manipulate sftp://cygwin.com. I think these are surmountable, but I want to know if there's a general agreement that it's worth doing. BTW a successful example like this one is the "cygport up" command, which we added a few years ago to automate uploading packages to cygwin.com. I think it's working well. Andrew
New packages: unison2.48+4.04.2, unison2.48+4.08.1
Please add me as the maintainer for two new Unison packages: unison2.48+4.04.2 unison2.48+4.08.1 If you want to know why we need this, please see the thread starting at [1] (and continuing at [2], thanks pipermail). I'm going to release them initially as test packages, to see if they have the right OCaml versions to meet the current need. There may be more in the future. Thanks, Andrew [1] https://cygwin.com/pipermail/cygwin/2020-August/246097.html [2] https://cygwin.com/pipermail/cygwin/2020-September/246099.html
Re: Putting packages up for adoption
> On Apr 1 16:58, Yaakov Selkowitz wrote: > > On Tue, 2020-03-24 at 16:19 -0400, Andrew Schulman wrote: > > > > On Mar 19 23:47, Yaakov Selkowitz wrote: > > > > > Hello Cygwin package maintainers, > > > > > > > > To that end, in the best interest of the community, please consider my > > > > > packages up for adoption. > > > > > > > > Yaakov > > > > > > > > There's no number of goldstars or plush hippos which would do justice to > > > > what you did for Cygwin, Yaakov. If there's something like the ULTIMATE > > > > PLUSH HIPPO REPLACING EVRY OTHER PLUSH HIPPO, you should get it. > > > > > > Well that's what I get for not checking the list for a week. > > > > > > I'm happy to oblige, and I have sort of a picture in my head of what that > > > might look like, but I'm not skilled at rendering it. If anyone has any > > > recommendations, please send to me directly by email. > > > > While I appreciate the thought, please don't trouble yourself over > > this. A nicely polished "gold watch" will do just fine. :-) > > Or a Pink plush watch, perhaps? > > > Corinna One pink plush watch! The only one ever made, I'm afraid. I had to travel to Nepal to get it. So no one else will ever be able to get one. https://cygwin.com/goldstars/#YS
Re: cygport upload
> > OK, works. Can lftp or cygport be configured so that lftp does not ask > > for a password? Or to use sftp instead? > > I don't know of any configuration for lftp to turn off that behaviour > (which is arguably a defect in lftp), but that's probably something you > could investigate for yourself. > > I am not sure why lftp is used instead of sftp, possibly it is > insufficiently scriptable to do what cygport wants to do. I wrote the upload command for cygport, with review by Yaakov. Yes, it is harder to script than you might guess. I originally proposed to offer sftp and lftp options, but he said to strip it down to just lftp. The logic is in /usr/share/cygport/lib/pkg_upload.cygpart. If the SSH_KEY environment variable isn't set, then lftp connects with the connect string sftp://cyg...@cygwin.com which will prompt for a password. To use an ssh key, set SSH_KEY equal to the file name of the key. You can do that in ~/.cygport.conf, for example: SSH_KEY=~/.ssh/id_dsa Then if the key is already loaded in a running ssh_agent, or if it's unencrypted, you shouldn't get a password prompt. Note that SSH_KEY is documented in the cygport docs. Good luck! Andrew
Re: Putting packages up for adoption
> On Mar 19 23:47, Yaakov Selkowitz wrote: > > Hello Cygwin package maintainers, > > To that end, in the best interest of the community, please consider my > > packages up for adoption. > > Yaakov > > There's no number of goldstars or plush hippos which would do justice to > what you did for Cygwin, Yaakov. If there's something like the ULTIMATE > PLUSH HIPPO REPLACING EVRY OTHER PLUSH HIPPO, you should get it. Well that's what I get for not checking the list for a week. I'm happy to oblige, and I have sort of a picture in my head of what that might look like, but I'm not skilled at rendering it. If anyone has any recommendations, please send to me directly by email. Andrew
updated SSH key
Name: Andrew Schulman Package: screen BEGIN SSH2 PUBLIC KEY E2VjZHNhLXNoYTItbmlzdHAzODQIbmlzdHAzODQAAABhBIh5WtQRqhzLyhiCds BhExlJjXY+NeKxt7tp3l4ViEOwGAPmiMp9keikNzVrpBy2poorumkZDCJrCxx3855UxdnV E51GAO7toxiCMM8BNHX3fnDj6rgydpjCNRStBQUqWQ== END SSH2 PUBLIC KEY
Re: [Attn. Maintainers] perl-5.30.1 -- prepare for release
> > I have done another update of my private Perl repository over the > weekend. While not all maintainers will immediately be ready with their > updates due to external circumstances, I'd like to release the new Perl > version at the end of this week or maybe over the weekend. > > In preparation of the release, please follow the instructions below to > upload the packages (re-)created with the new Perl version to the Cygwin > server. Please be reminded that the new packages should not be "test" > versions so that setup.exe will offer them automatically when they are > distributed to the mirrors. This is done for stow. Note, I only put the !perl file in /noarch/release/stow, not also in /noarch/release/stow/perl-Stow. Andrew
Re: Would anyone adopt subversion?
> On 18/11/2019 23:24, David Rothenberger wrote: > > Is anyone willing to adopt Subversion? > > Please accept this literally priceless gold star in acknowledgment of > your efforts in maintaining subversion for the past 12 (!) years. > > Thanks for maintaining this package. Gold star awarded! https://cygwin.com/goldstars/#DR Plus, a gold star each for Jon and Marco, for their stealth adoptions of the xclip and aspell packages. I actually had to modify the Perl script that generates the gold star page, to cover the case where there is NO web URL for an award, because the maintainer never announced it. Andrew
Re: [Attn. Maintainers] perl-5.30.1
> Achim Gratz writes: > > Perl version 5.30.1 was just released. I will have an unexpected > > timeslot available at the beginning of next week that I plan to use to > > update Perl for Cygwin. This of course means all Perl distribution > > packages and any other packages that install into the Perl module > > directories will need to be updated. > > So it appears likely that the update shifts to the beginning of next > year (which probably means early February rather than mid-to-end > January). I'll probably have time to work through this before then. But in case I don't, and I just wait to update stow until you release the new Perl version, is there any disadvantage to that aside from the short time when stow won't work with the latest Perl? And the risk of a further delay due to any build problems? Thanks, Andrew
Re: [Attn. Maintainers] perl-5.30.1
> Perl version 5.30.1 was just released. I will have an unexpected > timeslot available at the beginning of next week that I plan to use to > update Perl for Cygwin. This of course means all Perl distribution > packages and any other packages that install into the Perl module > directories will need to be updated. By now I should maintain or > co-maintain almost all Perl distribution packages, but there are a few > that are left over or captive in some other packages. > > I'd appreciate if the respective maintainers would reply to this post > with the names of the affected packages and if they can roll an update > around the time mentioned. Thanks. Hi. stow makes the perl-Stow package. Sure, I can rebuild that, it'll only take a few minutes. Please just let us how when we should go ahead. Andrew
Re: git repositories for cygwin packaging - please test
> > While a number of maintainers keep their cygwin packaging under some > sort of version control, there is currently no central collection of > these repositories. > > To remedy this lack, using the same ssh key you use for sftp package > upload, package maintainers can now also push to git repositories, like so: > > git push cyg...@cygwin.com:/git/cygwin-packages/ > > where is a package name you are listed as a maintainer for > in http://cygwin.com/cygwin-pkg-maint. > > These repositories are lazily created on the first push. In my testing, git push hangs on the first push, after "Initialized empty git repositories". After I interrupt, it finishes normally. Maybe a misconfiguration on my end. ~/d/c/fish> git push --set-upstream origin master Initialized empty Git repository in /sourceware1/projects/cygwin-home/cygwin-packages/fish.git/ # Insert Ctrl-C here Counting objects: 92, done. Delta compression using up to 4 threads. Compressing objects: 100% (75/75), done. Writing objects: 100% (92/92), 14.87 KiB | 249.00 KiB/s, done. Total 92 (delta 33), reused 0 (delta 0) To cygwin.com:/git/cygwin-packages/fish * [new branch] master -> master Branch 'master' set up to track remote branch 'master' from 'origin'.
Re: git repositories for cygwin packaging - please test
> While a number of maintainers keep their cygwin packaging under some > sort of version control, there is currently no central collection of > these repositories. > > To remedy this lack, using the same ssh key you use for sftp package > upload, package maintainers can now also push to git repositories, like so: > > git push cyg...@cygwin.com:/git/cygwin-packages/ > > where is a package name you are listed as a maintainer for > in http://cygwin.com/cygwin-pkg-maint. Nice work, thanks. And, a big step towards an automated package build server! Gold star! https://cygwin.com/goldstars/#Jty
Re: [ITA] openldap
> I'd like to take over the orphaned openldap package. As with the > previous maintainer, I don't use the server components myself, so I'm > short on hands-on experience with these. Gold star awarded! https://cygwin.com/goldstars/#AG
Re: [GOLDSTAR] Re: Moving packages between arch and noarch
> Achim Gratz writes: > > Jon Turney writes: > >> I recently deployed a calm update which makes this process (and it's > >> reverse, when a previously noarch package becomes archful) no longer > >> require any manual steps. > >> > >> So, going forward, you may build each version of a package with > >> ARCH=noarch and upload to noarch/, or without, and upload to x86/ and > >> x86_64/. > > > > Thanks, that should earn you a couple gold stars! Andrew? > > Let's see if I get Andrews attention this time > :-) Whoop! Awarded! https://cygwin.com/goldstars/#JTy
