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.2 Andrew Schulman > unison2.48+4.08.1 Andrew 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
Re: calm warnings for libgfortran5 & libgnat8
> On 12/04/2019 15:26, Andrew Schulman wrote: > > calm sent me the below after I uploaded screen-4.6.2-3. Do I need to do > > anything about the warnings? I'm not sure what they're about. I don't think > > I have any packages that depend on libgfortran5 or libgnat8, but maybe I'm > > wrong. > > It's safe for you to ignore these messages. > > These are warnings about the current state of the package release area > after the test release gcc 8.3.0-1 was uploaded (in which libfortan and > libgnat had soversion bumps, so now exist as packages without a current > version) > > Unfortunately calm is not (currently) smart enough to know who needs to > be told about this, so it tells everyone. Cool, thanks. I'm just always glad when it's not my fault.
calm warnings for libgfortran5 & libgnat8
calm sent me the below after I uploaded screen-4.6.2-3. Do I need to do anything about the warnings? I'm not sure what they're about. I don't think I have any packages that depend on libgfortran5 or libgnat8, but maybe I'm wrong. Thanks, Andrew WARNING: package 'libgfortran5' doesn't have a curr version WARNING: package 'libgfortran5' doesn't have a curr version WARNING: package 'libgnat8' doesn't have a curr version WARNING: package 'libgfortran5' doesn't have a curr version WARNING: package 'libgfortran5' doesn't have a curr version WARNING: package 'libgnat8' doesn't have a curr version INFO: adding 2 package(s) for arch x86_64 INFO: move from Andrew Schulman's upload area to release area: INFO: x86_64/release/screen/screen-4.6.2-3-src.tar.xz INFO: x86_64/release/screen/screen-4.6.2-3.hint INFO: x86_64/release/screen/screen-4.6.2-3.tar.xz INFO: x86_64/release/screen/screen-debuginfo/screen-debuginfo-4.6.2-3.hint INFO: x86_64/release/screen/screen-debuginfo/screen-debuginfo-4.6.2-3.tar.xz INFO: vaulting 2 old package(s) for arch x86_64 INFO: move from release area to vault: INFO: x86_64/release/screen/screen-4.6.1-1-src.tar.xz INFO: x86_64/release/screen/screen-4.6.1-1.hint INFO: x86_64/release/screen/screen-4.6.1-1.tar.xz INFO: x86_64/release/screen/screen-debuginfo/screen-debuginfo-4.6.1-1.hint INFO: x86_64/release/screen/screen-debuginfo/screen-debuginfo-4.6.1-1.tar.xz SUMMARY: 14 INFO(s), 6 WARNING(s)
Re: [ITA] freeglut 3.0.0
> Am 12.11.2018 um 23:51 schrieb Ken Brown: > > My cygport file and the one for the current release are attached. There's > > no > > test suite, but I tested it by building asymptote. > > > > Ken > > > > updated the cygwin-pkg-maint Gold star awarded! https://cygwin.com/goldstars/#KB
Re: [ITA} gd 2.2.5-2
> Am 11.11.2018 um 22:25 schrieb Ken Brown: > > Although there's been no new upstream release since the last Cygwin release, > > there have been some bug fixes (including one that I just found to fix a > > crash > > on 32-bit Cygwin), which warrant a new release. > > > > I'm attaching my cygport file and the one patch that can't be gotten by > > "cygport > > fetch". I'm also attaching, for comparison, the cygport file from the > > current > > Cygwin release. > > > > There are two test failures on 32-bit Cygwin. (There were four before I > > fixed > > the crash I mentioned above.) I've reported them upstream and hope to get > > them > > fixed eventually. > > > > Ken > > > > it looks good to me. > I updated the cygwin-pkg-maint Gold star awarded! https://cygwin.com/goldstars/#KB
Re: [ITA] doxygen
> Am 11.11.2018 um 23:38 schrieb Ken Brown: > > There's no need for a new release at the moment, but I'm attaching the > > cygport > > file I would use if there were. It differs in only very minor ways from the > > current cygport file (also attached). > > > > I've tested that the upstream git repo builds and passes all tests. > > > > Ken > > > > updated cygwin-pkg-maint Gold star awarded! https://cygwin.com/goldstars/#KB
Re: [ITA] doxygen
> Am 11.11.2018 um 23:38 schrieb Ken Brown: > > There's no need for a new release at the moment, but I'm attaching the > > cygport > > file I would use if there were. It differs in only very minor ways from the > > current cygport file (also attached). > > > > I've tested that the upstream git repo builds and passes all tests. > > > > Ken > > > > updated cygwin-pkg-maint Gold star awarded! https://cygwin.com/goldstars/#KB
updated ssh key
Name: Andrew Schulman Package: screen BEGIN SSH2 PUBLIC KEY Comment: "2048-bit RSA, converted from OpenSSH" B3NzaC1yc2EDAQABAAABAQDJHwg85y9fnaw7qYzRF32vmwY2GW5Bwcgc/hOxsG AWrpQJ9wsfFK5yHUmQnTmyyuttXhrOjrGsrUK1vtv59bFdJwsbh/i3jwnajBConXZwo3lU rMBnqn5rXTiG/TM4zX18qPErvuKci4/KvDK6b3LG/byo80PrX7r4u50XVgCIAUsdCKIFSQ kMh4rg/WWesXroFUZVFv3MooYpQ4kxrOgyan/uaVJU9+YYQPYFYYCUQteONzqiUty2Dp1/ JRpbsl9Gukcjy0GVN4bSSm96gtiGcUM6LnzIhD1UvKbvuAtjRGkqTm7OTjHVIV8xRcOtdH OUjN751mQnb7IwJPWfcFuv END SSH2 PUBLIC KEY
Re: setup 2.894 release candidate - please test
> Am 13.10.2018 um 20:49 schrieb Jon Turney: > > > > A new setup release candidate is available at: > > > > https://cygwin.com/setup/setup-2.894.x86_64.exe (64 bit version) > > https://cygwin.com/setup/setup-2.894.x86.exe (32 bit version) > > > > Please test and report any problems here. > > very nice. > > May I have a hippo for Jon ? > > Regards > Marco Awarded! http://cygwin.com/goldstars/#JTy
Re: lftp 4.8.4-1 upload error
> It seems that the advice I gave was wrong, and that '-override.hint' > works, but an empty 'override.hint' is (silently) considered invalid > (because it uses the same parser as other .hint files, which aren't > expected to be empty) > > I've added some output so this failure isn't hidden, and added an item > to improve the hint parser to my calm backlog. > > I renamed 'override.hint' to '-override.hint' and set the upload to > retried, which seems to have succeeded. OK, thanks. I did try using -override.hint with x86, but thought it had failed because of some residual complaints about the old versions that came back from calm. Anyway, lftp seems to be back on a regular release course now so I hope I'm done with override.hint for a while. Andrew
Re: lftp 4.8.4-1 upload error
> On 29/08/2018 19:16, Andrew Schulman wrote: > > I just uploaded lftp-4.8.4-1 for x86_64, and got these error notices back > > from calm: > > > > ERROR: package 'lftp' version '4.8.4-1' is most recent non-test version, > > but version '4.7.8-2' is curr: > > ERROR: package 'lftp-debuginfo' version '4.8.4-1' is most recent non-test > > version, but version '4.7.8-2' is curr: > > ERROR: error while validating merged x86_64 packages for Andrew Schulman > > SUMMARY: 3 ERROR(s) > > > > I guess this is because we pinned 4.7.8-2 as curr: some time last year, > I think all of this isn't needed any more, so you can add an empty > override.hint to your upload to supersede that. OK. So this worked for x86, but for some reason when I upload for x86_64, I get this back: ERROR: error while reading uploaded arch x86_64 packages from maintainer Andrew Schulman Any idea why? I've rebuilt and uploaded again with the same result. Thanks, Andrew
Re: lftp 4.8.4-1 upload error
> I think all of this isn't needed any more, so you can add an empty > override.hint to your upload to supersede that. Got it. Thanks.
lftp 4.8.4-1 upload error
I just uploaded lftp-4.8.4-1 for x86_64, and got these error notices back from calm: ERROR: package 'lftp' version '4.8.4-1' is most recent non-test version, but version '4.7.8-2' is curr: ERROR: package 'lftp-debuginfo' version '4.8.4-1' is most recent non-test version, but version '4.7.8-2' is curr: ERROR: error while validating merged x86_64 packages for Andrew Schulman SUMMARY: 3 ERROR(s) I guess this is because we pinned 4.7.8-2 as curr: some time last year, when I had to forcibly roll back from 4.8.0-1. Is that right? Is this something you can fix, or do I need to do something? Thanks, Andrew
how to use opam for package builds?
orpie recently changed to an opam-based build system. So I want to use opam
to update it for Cygwin, but I've never used opam before and I have some
questions about how to use it.
The orpie build instructions say just to run "opam install orpie". When I
do that, opam complains that I haven't set it up yet:
$ opam install orpie
[ERROR] No OPAM root found at /home/andrew/.opam.
Please run 'opam init' to initialize the state of OPAM, or
specify '--root'.
See 'opam init --help' for details.
Now for packaging, what's the right thing to do here? For example I could
create the following install function for Cygport:
src_install()
{
opam init
opam install orpie
}
But this has two problems:
(1) I can't get "opam init" to complete. It hangs after "synchronized from
https://opam.ocaml.org;, until I interrupt it:
$ opam init
Checking for available remotes: rsync and local, git, mercurial.
- you won't be able to use darcs repositories unless you install the
darcs command on your system.
[WARNING] Recommended external solver aspcud not found.
=-=- Fetching repository information
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
[default] synchronized from https://opam.ocaml.org
### hangs here until I hit ctrl-C: ###
[ERROR] Initialisation failed
User interruption
# opam-version1.2.2
# os cygwin
Cannot remove /home/andrew/.opam (error 255).
(2) Even if I get this to work, I don't think it's the right thing to do
because it's setting up persistent opam configuration in my home directory,
which I don't think is the right place for packaging. Should there be some
global opam configuration, that all packaging scripts that rely on opam
would use? If so, where should that go?
Tnanks,
Andrew
Re: [ITA] rsh-0.17-3
> I would like to take over the maintenance of rsh package, which is > currently orphaned. 3 gold stars, for inetutils, rsh, and tcp_wrappers! https://cygwin.com/goldstars/#TY Andrew
Re: Moving on from Cygwin
> > I've been a Cygwin package maintainer for nearly six years, and I've > > learned a lot in my time here. Special thanks to Corinna for leading the > > programme, and to Yaakov for somehow managing to maintain a ridiculous > > number of packages. Cygwin has made a big difference to so many users > > over the years. I know the work done here is genuinely appreciated by > > the community, and I wish the programme every success in the future. > > Thank you very much for your contributions over the years, and for being > willing to help make a smooth transition. Much success in your future > endeavours. > > Andrew, could you please polish a gold watch in honour of David's > retirement? Awarded! https://cygwin.com/goldstars#DSt
Re: can't pull cygwin-htdocs
> On 28/06/2018 18:09, Andrew Schulman wrote: > > Scratching my head. This used to work. Now I get an inscrutable error > > message: > > > >$ git remote -v > >origin ssh://sourceware.org/git/cygwin-htdocs.git (fetch) > >origin ssh://sourceware.org/git/cygwin-htdocs.git (push) > > > >$ git fetch > >FATAL: R any git/cygwin-htdocs Andrew_Schulman DENIED by fallthru > >(or you mis-spelled the reponame) > >fatal: Could not read from remote repository. > > > >Please make sure you have the correct access rights > >and the repository exists. > > Yeah, sorry, I've broken this. > > For the moment, you'll need to pull anonymously (using git:// or > http://) URLs. > > I'm not sure this used to work as a push URL (or should)? I believe you > have a sourceware shell account which should work for that? OK, no problem. Yes, it used to work for push too. If I have a sourceware shell account, I'm not aware of it. Could you send me the details offline? Thanks, Andrew
can't pull cygwin-htdocs
Scratching my head. This used to work. Now I get an inscrutable error message: $ git remote -v originssh://sourceware.org/git/cygwin-htdocs.git (fetch) originssh://sourceware.org/git/cygwin-htdocs.git (push) $ git fetch FATAL: R any git/cygwin-htdocs Andrew_Schulman DENIED by fallthru (or you mis-spelled the reponame) fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists. Huh? What am I doing wrong? ~/.ssh/config has: Host sourceware.org User cygwin Thanks, Andrew
Re: setup 2.888 crashes on --prune-install
> Andrew Schulman writes: > > When I run setup-x86_64.exe or setup-x86.exe with --prune-install as shown > > below, it crashes. An error dialog pops up saying "setup-x86.exe has > > stopped working". No other debug information appears on the console - the > > whole session is shown below. > > That option, as I originally implemented it, should actually leave your > system exactly with those packages requested, without diving into > dependencies. In other words, that list should be self-contained, like > you'd get from copying an existing installation from a different > machine. From what you were saying I guess that you rather want to use > --delete-orphans. Thanks. Yes, --delete-orphans is what I wanted. And sadly I just found out that pdftk is gone :( Andrew
setup 2.888 crashes on --prune-install
When I run setup-x86_64.exe or setup-x86.exe with --prune-install as shown below, it crashes. An error dialog pops up saying "setup-x86.exe has stopped working". No other debug information appears on the console - the whole session is shown below. When I run the same command without --prune-install, it completes normally. Poor setup seems to be having trouble solving all of the dependencies. Not surprising, as my installation is old and crufty. Of course that's what I was hoping --prune-install would help to dig me out of. Andrew c:\Users\x\Downloads\utilities\cygwin32>setup-x86.exe --no-shortcuts --quiet-mode --prune-install --packages atool,autoconf,automake,autossh,bc,bind-utils,byacc,bzr,curl,cygport,discus,dos2unix,doxygen,emacs,file,fish,flexdll,gcc-core,gcc-g++,gettext-devel,git,gnupg2,gsl-devel,help2man,lftp,libargp,libargp-devel,libcrypt-devel,libgd-devel,libiconv,libintl-devel,libncurses-devel,libneon-devel,libpcre2-devel,libpng-devel,libreadline-devel,libwrap-devel,libX11-devel,links,lndir,m4,make,multitail,ncurses,nosleep,ocaml,ocaml-camlp4,openssh,openssl-devel,orpie,p7zip,par2,patch,patchutils,pdftk,perl,pinentry,pinfo,pkg-config,procps-ng,psmisc,readline,rebase,robodoc,rsync,screen,sitecopy,sng,socat,stow,stunnel,time,tree,unison2.27,unison2.32,unison2.40,unison2.45,unison2.48,unison2.49,unison2.51,util-linux,wget,zip, Starting cygwin install, version 2.888 User has backup/restore rights Current Directory: C:\Users\x\Downloads\utilities\cygwin32 Could not open service McShield for query, start and stop. McAfee may not be installed, or we don't have access. root: C:\cygwin32 system Selected local directory: C:\Users\x\Downloads\utilities\cygwin32 net: Direct site: http://mirrors.xmission.com/cygwin/ solving: 699 tasks, update: no, use test packages: no Augmented Transaction List: 0 erase_update-info-dir 03000-1 1 erase aria2 1.32.0-1 2 eraseautomake 10-1 3 erase automake1.4 1.4p6-11 4 erase automake1.5 1.5-11 5 erase automake1.6 1.6.3-12 6 erase automake1.7 1.7.9-11 7 erase automake1.8 1.8.5-11 8 erase bind-utils 9.11.2-2.P1 9 erasecompface 1.5.2-12 10 erasecurl 7.56.1-1 11 erase cvs 1.11.23-2 12 erasediffstat 1.61-1 13 erase doxygen 1.8.14-2 14 erase emacs 25.3-1 15 erase fontconfig 2.12.4-1 16 erase gcc-g++ 6.4.0-5 17 erase gettext-devel 0.19.8.1-2 18 erase ghostscript-fonts-std 20170801-4 19 erase gnupg 1.4.22-1 20 erasegraphviz 2.40.1-3 21 erase gsl 2.3-2 22 erase gsl-devel 2.3-2 23 erase inetutils 1.9.1-2 24 erase ipcalc 0.41-1 25 erase libEGL1 17.3.3-1 26 erase libGL1 17.3.3-1 27 eraselibXpm-devel 3.5.12-1 28 eraselibbind9_140 9.10.4-4.P4 29 erase libclang3.8 3.8.1-1 30 erase libclang4.0 4.0.1-1 31 eraselibcord1 7.6.4-1 32 erase libdialog13 1.3-2.20160828 33 erase libdns166 9.11.0-3.P5 34 erase libfontconfig-devel 2.12.4-1 35 erase libgccpp1 7.6.4-1 36 erase libgcj-common 5.4.0-1 37 erase libgd-devel 2.2.5-1 38 erase libgnutls28 3.3.27-1 39 erase libgsl0 1.16-2 40 erase libguile17 1.8.8-3 41 eraselibicu56 56.1-1 42 eraselibicu57 57.1-1 43 eraselibicu59 59.1-1 44 erase libirs141 9.10.4-4.P4 45 erase
Re: stunnel 5.44 build fails
> > configure.ac:9: error: version mismatch. This is Automake 1.15.1, > > configure.ac:9: but the definition used by this AM_INIT_AUTOMAKE > > configure.ac:9: comes from Automake 1.15. You should recreate > > configure.ac:9: aclocal.m4 with aclocal and run automake again. > > you've patched src/Makefile.am, causing src/Makefile to run automake. > > If you drop stunnel-ldflags.patch and just patch src/Makefile.in as you > did for 5.42 in stunnel-5.42-1.src.patch, I think you should be OK. Yes, that worked, thanks. That's weird about stunnel-5.42-1.src.patch. The source patch has always been to src/Makefile.am, not src/Makefile.in. You can see that in stunnel-ldflags.patch. I see that stunnel-5.42-1.src.patch patches src/Makefile.in, and I have no idea where that came from. Something that cygport did I guess. Anyway thanks for the suggestion. Patching Makefile.in is more brittle than Makefile.am, but it works for now. Andrew
stunnel 5.44 build fails
Prior to stunnel 5.42, I could build stunnel in Cygport with no src_compile
function, just
CYGCONF=--disable-fips
Beginning with stunnel 5.42, the build fails with errors about "possibly
undefined macro" AC_MSG_NOTICE and AC_DEFINE:
$ cygport stunnel.cygport build
>>> Compiling stunnel-5.44-1.x86_64
autoreconf-2.69: Entering directory `.'
autoreconf-2.69: configure.ac: not using Gettext
autoreconf-2.69: running: aclocal --force -I m4
autoreconf-2.69: configure.ac: tracing
autoreconf-2.69: running: libtoolize --copy --force
libtoolize: putting auxiliary files in AC_CONFIG_AUX_DIR, 'auto'.
libtoolize: copying file 'auto/ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'm4'.
libtoolize: copying file 'm4/libtool.m4'
libtoolize: copying file 'm4/ltoptions.m4'
libtoolize: copying file 'm4/ltsugar.m4'
libtoolize: copying file 'm4/ltversion.m4'
libtoolize: copying file 'm4/lt~obsolete.m4'
autoreconf-2.69: running: /usr/bin/autoconf-2.69 --force
configure.ac:4: error: possibly undefined macro: AC_MSG_NOTICE
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure.ac:23: error: possibly undefined macro: AC_DEFINE
autoreconf-2.69: /usr/bin/autoconf-2.69 failed with exit status: 1
*** ERROR: autoreconf failed
Nice. So I tried adding a custom src_compile:
src_compile ()
{
cd "${B}"
cygconf
cygmake
}
But then although configure completes, the build fails with
configure.ac:9: error: version mismatch. This is Automake 1.15.1,
configure.ac:9: but the definition used by this AM_INIT_AUTOMAKE
configure.ac:9: comes from Automake 1.15. You should recreate
configure.ac:9: aclocal.m4 with aclocal and run automake again.
The full build log is below.
Can someone please suggest how to get past this? autoconf and automake are
mysteries to me.
Thanks,
Andrew
$ cygport stunnel.cygport build
>>> Compiling stunnel-5.44-1.x86_64
/home/ASchulma/dev/cygwin/stunnel/stunnel-5.44-1.x86_64/src/stunnel-5.44/configure
--srcdir=/home/ASchulma/dev/cygwin/stunnel/stunnel-5.44-1.x86_64/src/stunnel-5.44
--prefix=/usr -
-exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
--docdir=/usr/share/doc/stunnel --htmldir=/usr/share/doc/stunnel/html -C
--disable-fips
configure: loading site script /usr/share/config.site
configure: creating cache config.cache
configure: initialization
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking build system type... x86_64-unknown-cygwin
checking host system type... x86_64-unknown-cygwin
checking for gcc... gcc
checking whether the C compiler works... yes
checking for C compiler default output file name... a.exe
checking for suffix of executables... .exe
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... yes
checking for style of include used by make... GNU
checking dependency style of gcc... gcc3
checking whether make sets $(MAKE)... (cached) yes
checking whether make supports nested variables... (cached) yes
configure: thread model
checking for a sed that does not truncate output... /usr/bin/sed
checking how to run the C preprocessor... gcc -E
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking whether gcc is Clang... no
checking whether pthreads work with -pthread... yes
checking for joinable pthread attribute... PTHREAD_CREATE_JOINABLE
checking whether more special flags are required for pthreads... no
checking for PTHREAD_PRIO_INHERIT... no
configure: PTHREAD thread model detected
configure: compiler/linker flags
checking whether C compiler accepts -Wall... yes
checking whether C compiler accepts -Wextra... yes
checking whether C compiler accepts -Wpedantic... yes
checking whether C compiler accepts -Wformat=2... yes
checking whether C compiler accepts -Wconversion... yes
checking whether C compiler accepts -Wno-long-long... yes
checking whether C compiler accepts -Wno-deprecated-declarations... yes
checking whether C compiler accepts -fPIE... yes
checking whether C compiler accepts -fstack-protector... yes
checking whether the linker accepts -fPIE... yes
checking whether the linker accepts -pie... yes
checking whether the linker accepts -Wl,-z,relro... no
checking whether the linker accepts -Wl,-z,now... no
checking whether the linker accepts -Wl,-z,noexecstack... no
checking whether C compiler accepts -D_FORTIFY_SOURCE=2... yes
configure:
[ITP] unison2.51
I'm going to package unison2.51 for Cygwin. It's a new member of the Unison family - same as the other unison* packages, but it gets its own new package since it's incompatible with the other versions. So please add unison2.51 to the package list with me as the maintainer. Thanks, Andrew
Re: [ITA] lcms2-2.9-1
> On 2017-11-27 10:04, Ken Brown wrote: > > My cygport file is attached. > > GTG; package is yours now. Thanks! Gold star awarded! https://cygwin.com/goldstars/#KB
Re: [ITA] libXpm-noX 3.5.12
> On 15/11/2017 17:30, Ken Brown wrote: > > My cygport file and other files needed for reproducing the build are > > attached. > > I added this to your uploads, Gold star awarded! https://cygwin.com/goldstars/#KB
Re: [ITA] ghostscript, ghostscript-fonts-std, ghostscript-fonts-other
> On 30/10/2017 19:43, Ken Brown wrote: > > My cygport files and patch are attached. The two fonts packages > > don't need updating, but their cygport files had to be updated, so I'm > > attaching them for future reference. > > > > In the case of ghostscript, the current version is 9.22, but it > > doesn't work with preview-latex: > > > > https://bugs.ghostscript.com/show_bug.cgi?id=698680 > > > > So I propose to start with 9.21 until that issue is resolved. > > > > GTG > > all 3 package are yours. Gold stars awarded! https://cygwin.com/goldstars/#KB
Re: [ITA] xpdf-4.00-1
> On 09/10/2017 17:19, Ken Brown wrote: > > My cygport file and patches are attached. Note that there has been a > > change in the build system since the last release. It now uses cmake > > and libQt. For comparison, I'm also attaching the cygport file from the > > previous release. > > Added to your packages. Gold star awarded! https://cygwin.com/goldstars/#KB
Re: [ITA] xfig-3.2.6a-1
> Corinna Vinschen writes: > >> Any comments? > > > > ship it? > > An option I hadn't considered so far. :-) > > > Regards, > Achim. Gold stars awarded! https://cygwin.com/goldstars/#AG
Re: lftp version override help
> On 11/10/2017 18:35, Ken Brown wrote: > > On 10/11/2017 1:14 PM, Andrew Schulman wrote: > >> As I described elsewhere here, I'm trying to dump lftp 4.8.0-1, which is > >> partly broken, and promote 4.7.8-1 to current. I thought I could do > >> that by > >> uploading override.hint with: > >> > >> prev: 4.7.7-1 > >> curr: 4.7.8-1 > >> test: 4.7.8-1 > > It's not clear what using the same version as test: and curr: means. > > It's not something I considered, so please don't do that. > > It probably should be reported as an error. OK. I was only trying to dump 4.8.0-1 once and for all. > >> But calm doesn't like that: > >> > >> ERROR: package 'lftp' version '4.8.0-1' is most recent non-test version, > >> but version '4.7.8-1' is curr: > >> ERROR: package 'lftp-debuginfo' version '4.8.0-1' is most recent non-test > >> version, but version '4.7.8-1' is curr: > >> ERROR: error while validating merged x86 packages for Andrew Schulman > >> > >> So I guess I need a manual intervention. Can someone please help? > > > > See https://cygwin.com/package-upload.html near the end, under the > > heading "Removing files from the Cygwin distribution". > Note that this will not cause setup to automatically downgrade people > to 4.7.8-1 if they have 4.8.0-1 installed. Understood. I'll tell people in the announcement.
lftp version override help
As I described elsewhere here, I'm trying to dump lftp 4.8.0-1, which is partly broken, and promote 4.7.8-1 to current. I thought I could do that by uploading override.hint with: prev: 4.7.7-1 curr: 4.7.8-1 test: 4.7.8-1 But calm doesn't like that: ERROR: package 'lftp' version '4.8.0-1' is most recent non-test version, but version '4.7.8-1' is curr: ERROR: package 'lftp-debuginfo' version '4.8.0-1' is most recent non-test version, but version '4.7.8-1' is curr: ERROR: error while validating merged x86 packages for Andrew Schulman So I guess I need a manual intervention. Can someone please help? Thanks, Andrew
Re: [PATCH cygport] Add a command to make a test release
> Andrew Schulman writes: > > Ooh, how about this: > > > > cygport lftp.cygport all > > cygport lftp.cygport override curr=4.7.7-1 test=4.7.8-1 > > cygport lftp.cygport up > > > > That would create override.hint and upload it with the package, leaving the > > cygport file and source package alone. > > The command line parsing in cygport would become a lot more complicated > for starters, so the syntax should be different. > > But more to the point, some people want to do this on the command line, > while others do not. I for one don't want to do it from the command > line because I have oodles of packages that I build semi-automatically > and changing the commands issued for each individual package just > doesn't work well for me. So I do want this to be part of the file set > I commit to my Git repository instead (yes, if forced I could wrap > another layer of scripting or cygport patches around it). In other > words, in the end we likely need to have both. That's fine. > A separate issue is if those things should end up in the package > archives. I agree that often they should not, so again my suggestion is > to record this simply in a separate file that does not get packaged and > (as outlined above) to provide means to create the same effects from the > command line. Agree. The idea is that cygport can create override.hint, or the packager can create it. Then cygport uploads it along with the package files. But it's a separate file, not part of the package archive.
Re: [PATCH cygport] Add a command to make a test release
> On 10/5/2017 10:23 AM, Andrew Schulman wrote: > > Sometimes more complicated situations come up. We have one with lftp right > > now: > > > > prev: 4.7.7-1 > > curr: 4.8.0-1 > > test: 4.7.8-1 > > > > This happened because 4.8.0-1 turns out to be broken, and later versions > > won't > > build in Cygwin yet. So I had to promote 4.7.8-1 to test. > > I didn't pay close attention to the lftp bug reports, so what I'm saying > may be nonsense. But wouldn't it make more sense to just remove 4.8.0-1 > if it's broken? Maybe. It was partly broken. > You could still make 4.7.8-1 a test version, leaving a > working 4.7.7-1 as current. > > Doing it this way, you wouldn't need anything but the ability to mark a > release as "test". No, it also requires the ability to remove 4.8.0-1. To do that I have to either ask for help here, or upload an override.hint file with curr: 4.7.7-1 test: 4.7.8-1 or prev: 4.7.7-1 curr: 4.7.8-1 So it'd be nice if cygport could do that for me. Obviously this is an unusual case, but every now and then for one reason or another I need to upload an override.hint file. Any time I do that, it'd be nice if cygport handled the details for me. Ooh, how about this: cygport lftp.cygport all cygport lftp.cygport override curr=4.7.7-1 test=4.7.8-1 cygport lftp.cygport up That would create override.hint and upload it with the package, leaving the cygport file and source package alone. Andrew
Re: [PATCH cygport] Add a command to make a test release
> On 03/10/2017 21:01, Andrew Schulman wrote: > >> This patch (originally by Achim Gratz) adds a mechanism for generating > >> packages marked as 'test' as described in [1]. > >> > >> I'm not committed to any of the details, but I would like to get > >> something with this functionality in, so tell me how you'd like it > >> implemented and I'll do it... > >> > >> [1] https://cygwin.com/ml/cygwin-apps/2016-12/msg5.html > > > > Cygport needs a way to specify which versions are prev, curr, and test in > > cygport files. David Rothenberger and I each proposed a method [1,2]. It > > doesn't matter much to me which method is picked, but it's definitely a > > missing feature. > > I'm not keen on the idea of including this transient information into > the cygport, and thus baking it into the source package. > > However, I also want to make package maintainers lives easier. So, I'm > all for automation to make things less tedious and error-prone, which > this patch attempts to do. > > A few points to consider: > > * I'm going to remove the restriction that you can only have 3 versions. > (I keep on putting this off only because it will break parsing setup.ini > for setup prior to 2.877) > > * (This also means that more than one test: version may be available) > > * Changing curr: doesn't cause setup to downgrade (since 2.864) (unless > --force-current is used, since 2.874) > > * prev: isn't a very significant label, since the only way to install > that version is by manually selecting it, i.e. all it means is "keep > this version around" > > Taking a step back, as a package maintainer, what do you need to > control? What features do we need here? Thanks. Most commonly, I just want to make a version test, which this patch allows. Sometimes more complicated situations come up. We have one with lftp right now: prev: 4.7.7-1 curr: 4.8.0-1 test: 4.7.8-1 This happened because 4.8.0-1 turns out to be broken, and later versions won't build in Cygwin yet. So I had to promote 4.7.8-1 to test. Assuming it's okay, shortly I want to promote it to current and dump 4.8.0-1, leaving prev: 4.7.7-1 curr: 4.7.8-1 I can do this by creating an override.hint file, but right now I have to upload that manually. It'd be nice if I could tell cygport to handle it, in whatever way is best. I think it's fine to put the prev, curr, and test instructions in the cygport file, and have it create and upload the override.hint. cygport files already have version information in them (VERSION, RELEASE). But if you don't like that, we could ask maintainers to create override.hint files separately, and just have cygport recognize and upload those. That's fine too, as long as there's a way to allow different override.hint files by arch, which is bound to be needed sometimes. Andrew
Re: Dr. Volker Zell's packages
> On 03/10/2017 17:00, Andrew Schulman wrote: > >> Unfortunately, we haven't heard from Dr. Volker Zell in quite some time, > >> and a number of his packages are in need of updates or rebuilds. I have > >> marked them ORPHANED in the maintainer list. ITAs welcome. > > > > I use multitail so I can adopt it if the package is in good shape. I'll > > take a look. > > > > Maybe openldap. > > Hi Andrew, > openldap-2.4.42 builds fine with the cygwin source packages > but it segfaults during test. > > The slapd.1.log suggests the segfault is on the test client and not on > the server. > > Can you try to build just to double check that is not my > computer the problem ? Sure, I will as soon as I have time. I only use the openldap client, not the server. So if you use the server too and are considering adopting the package, you should do that.
Re: [PATCH cygport 1/2] Rename DEPEND to BUILD_DEPENDS
> Somewhat clearer as to it's purposes, and pluralized for consistency with > REQUIRES. Yes! Thank you!
[ITA] multitail
I'd like to adopt this from Dr Volker Zell. I've tested the cygport script with the latest version, 6.4.2, and it works fine, so I have a new package ready to upload. Andrew
Re: Dr. Volker Zell's packages
> Unfortunately, we haven't heard from Dr. Volker Zell in quite some time, > and a number of his packages are in need of updates or rebuilds. I have > marked them ORPHANED in the maintainer list. ITAs welcome. I use multitail so I can adopt it if the package is in good shape. I'll take a look. Maybe openldap.
Re: [GOLDSTAR] Re: fflush(NULL) clobbers input streams
> > Achim, thanks for the testcase. Ken, thanks for bisecting. You're > > my hero! > > > > I reverted the patch and created new developer snapshots. > > I forgot the gold star. Thanks again, Ken! Awarded! https://cygwin.com/goldstars/#AG https://cygwin.com/goldstars/#KB
Re: calm now runs on-demand
> On 01/07/2017 12:31, Andrew Schulman wrote: > >> On Apr 17 12:34, Jon Turney wrote: > >>> > >>> I recently deployed an update to calm which should causes it to run > >>> on-demand after a maintainer SFTP upload. > >>> > >>> Hopefully this reduces the inconvenience of having to wait till the next > >>> scheduled run, after an upload is made which fails due to some easily > >>> correctable problem. > >>> > >>> calm continues to also run on a schedule at :10 and :40 past the hour, so > >>> it > >>> will still note changes which have been made directly on sourceware. > >>> > >>> If you have shell access on sourceware, and make such changes, you can > >>> force > >>> calm to run with '~cygwin-admin/bin/calm scan-(uploads|relarea)'. > >>> > >>> Given that, it probably makes sense to consider reducing the frequency of > >>> scheduled runs. > > > > I have upload access, but AFAIK not shell access. I think most maintainers > > don't, unless that's changed. > > Correct. But unless you have shell access to make changes by directly > moving files around on sourceware, you don't need shell access to run calm. > > Currently, calm runs (i) if a !ready file exists in your upload area > when your sftp session closes, and (ii) at 00:10 UTC and every 4 hours > thereafter. Cool, thank you. Andrew
Re: calm now runs on-demand
> On Apr 17 12:34, Jon Turney wrote: > > > > I recently deployed an update to calm which should causes it to run > > on-demand after a maintainer SFTP upload. > > > > Hopefully this reduces the inconvenience of having to wait till the next > > scheduled run, after an upload is made which fails due to some easily > > correctable problem. > > > > calm continues to also run on a schedule at :10 and :40 past the hour, so it > > will still note changes which have been made directly on sourceware. > > > > If you have shell access on sourceware, and make such changes, you can force > > calm to run with '~cygwin-admin/bin/calm scan-(uploads|relarea)'. > > > > Given that, it probably makes sense to consider reducing the frequency of > > scheduled runs. I have upload access, but AFAIK not shell access. I think most maintainers don't, unless that's changed.
Re: gnupg2 ?
> I am uploading all except gpa, that will follow later. Is that the gpg-agent? That'd be great to have. Save me half or 2/3 of the typing when I'm signing packages.
cygport pull requests
I've opened two pull requests for cygport on github. No action has been taken on them. One of them is a fairly trivial bug fix. Are github pull requests a supported way of proposing changes to cygport? Or should we post patches to cygwin-apps? Thanks, Andrew
