Re: cygport: allow setting prev:, curr:, and test: in autogenerated setup.hint
It seems you've re-invented something that David Rothenberger has implemented before in a slightly different way: http://thread.gmane.org/gmane.os.cygwin.applications/26034 It's also integrated in my patched-up version of cygport here: git://repo.or.cz/cygport/rpm-style.git FWIW, I've been using Dave's patch a few times and it seems slightly less verbose than what you've got. OK. Sure, VERSIONS=curr:1.7.3.0-2 test:2.0.0-b8-1 also works, and it has the advantage of not baking in the current 3-version prev/curr/test setup quite so much. OTOH setting PREV, CURR and TEST feels a little more natural to me with the current 3-version setup. Either way would be fine with me, as long as I have a way of automatically setting the versions in the cygport file, instead of having to manually edit setup.hint after the build. Andrew
cygport: allow setting prev:, curr:, and test: in autogenerated setup.hint
I have a package (socat) where I need to set the curr: and test: fields in setup.hint. I got tired of adding them to the autogenerated setup.hint files after every build, so I wrote a patch for cygport to support specifying them in the cygport file. For example, setting CURR=1.7.3.0-2 TEST=2.0.0-b8-1 in the cygport file will give curr: 1.7.3.0-2 test: 2.0.0-b8-1 in setup.hint. The PREV, PKG_PREV, CURR, PKG_CURR, TEST, and PKG_TEST variables are all supported. The variable name TEST might be too generic, but I'm not aware of any other uses for it, and grep -r '\TEST\' in the cygport source turns up none. If necessary it could be renamed to e.g. SETUP_TEST, but then probably CURR, PKG_CURR etc. would all have to be renamed too. The patch is in the setup.hint branch of https://github.com/andrex-e-schulman/cygport.git. Andrew
Re: cygport upload: patch for openssh 6.8p1
Any thoughts on a better regex or on keeping compatibility with other
systems?
Right, OK. See the attached revised patch, which uses
[0-9a-f]{2}(:[0-9a-f]{2}){15}|SHA256:.{44}
to detect the key fingerprint. The left side is the same as now, for pre-6.8
systems, which use MD5 without a label. The right side is for version 6.8 and
later, where the default is SHA256 with the label 'SHA256:' prepended. So
this
should cover all cases.
A more precise regex is
[0-9a-f]{2}(:[0-9a-f]{2}){15}|SHA256:[A-Za-z0-9+/=]{43}
I've committed this change to my upload branch at
https://github.com/andrex-e-schulman/cygport.git.
Also in that branch, I've added documentation of the fact that users will need
to connect to cygwin.com at least one time by sftp before they upload, in order
to store the host public key in their known_hosts file, as explained in
https://cygwin.com/ml/cygwin-apps/2015-03/msg00193.html .
Andrew
Re: cygwin.com sftp key fingerprint?
Is the key fingerprint posted anywhere on cygwin.com or sourceware.org? I can't find it. If not, would someone mind adding it to the Uploading Packages to cygwin.com page (https://sourceware.org/cygwin-apps/package-upload.html), so people can verify it? Good idea. PGA? OK, here you go. The patch is a bit large, because I took the opportunity to reorganize the text a bit and add a new section showing how to upload packages the automated way using cygport up. The complete revised page is at http://home.comcast.net/~andrex2/cygwin/package-upload.html . Andrew package-upload.html.patch Description: Binary data
Re: cygport upload: patch for openssh 6.8p1
On Sun, 2015-05-24 at 12:32 -0400, Andrew Schulman wrote:
Since the latest update to openssh, ssh-keygen's output format for key
fingerprints has changed. The default hash algorithm is now base64-encoded
SHA256 instead of MD5, and the hash name precedes its value, like
SHA256:lvRrjAXmEhzDp5kQqzelsei8s5hXJ+zLaqJ2yiGXmYc
This breaks the current logic for detecting key fingerprints in cygport's
lib/pkg_upload.cygpart. The attached patch fixes the problem. (You might
know
a more precise regex for the base64-encoded hash value than I do. I
couldn't
find any documentation of it anywhere, and just settled for
SHA256:.{44}
There's another problem: this is new to 6.8; any out-of-date Cygwin
systems, or even current RHEL or Fedora 21 systems, won't have this, nor
do they support the -E flag which could be used to specify md5.
Any thoughts on a better regex or on keeping compatibility with other
systems?
Right, OK. See the attached revised patch, which uses
[0-9a-f]{2}(:[0-9a-f]{2}){15}|SHA256:.{44}
to detect the key fingerprint. The left side is the same as now, for pre-6.8
systems, which use MD5 without a label. The right side is for version 6.8 and
later, where the default is SHA256 with the label 'SHA256:' prepended. So this
should cover all cases.
Andrew
pkg_upload_key_fingerprint.patch
Description: Binary data
cygwin.com sftp key fingerprint?
I show the SFTP key fingerprint for cygwin.com as SHA256:MFNiczzfX8/nvLSRZwR3CxMyycKtMan64Zm4C373FeM Can anyone please confirm that? Is the key fingerprint posted anywhere on cygwin.com or sourceware.org? I can't find it. If not, would someone mind adding it to the Uploading Packages to cygwin.com page (https://sourceware.org/cygwin-apps/package-upload.html), so people can verify it? Thanks, Andrew
Re: stunnel build chokes on -no-undefined
From a quick peek at the source, you should make this change in src/Makefile.am -libstunnel_la_LDFLAGS = -avoid-version +libstunnel_la_LDFLAGS = -avoid-version -no-undefined Right - thanks. Yep, that takes care of it. and then hope that libstunnel has no undefined symbols that need to be provided by someone else to link a whole program. Most libraries do not have such undefined symbols. You can probably send that change upstream. Where did -Wl,-no-undefined come from? It was added to CFLAGS in the cygport file. I don't remember why, but I probably added it myself some time in the past. Oops. I've taken it out again now. Thanks a lot for your help. Andrew
Re: stunnel build chokes on -no-undefined
The libtool command should almost always include -no-undefined, so you should probably add that. OK, thanks. So, uh... could you suggest how I would add an option to the libtool command? Sorry, I'm just not strong on autotools. Thanks, Andrew
stunnel build chokes on -no-undefined
In stunnel 5.17, the build of libstunnel.la fails with can't build shared library unless -no-undefined is specified: /bin/sh ../libtool --tag=CC --mode=link gcc -Wl,-no-undefined -fdebug-prefix-map=/home/andrex/dev/cygwin/stunnel/stunnel-5.17-1.x86_64/build=/usr/src/debug/stunnel-5.17-1 -fdebug-prefix-map=/home/andrex/dev/cygwin/stunnel/stunnel-5.17-1.x86_64/src/stunnel-5.17=/usr/src/debug/stunnel-5.17-1 -Wall -Wextra -Wpedantic -Wformat=2 -Wconversion -Wno-long-long -Wno-deprecated-declarations -fstack-protector -fPIE -D_FORTIFY_SOURCE=2 -avoid-version -fPIE -pie -o libstunnel.la -rpath /usr/lib env.lo -lz -lwrap libtool: error: can't build x86_64-unknown-cygwin shared library unless -no-undefined is specified Makefile:464: recipe for target 'libstunnel.la' failed Of course, the libtool command does include -Wl,-no-undefined. I don't know much about this, but I do seem to recall that the linker flags should come at the end, or something like that. Could anyone please suggest a solution? I'm attaching stunnel.cygport, and src/Makefile.am from which the above command was generated. Please let me know if there are other files I should provide. Thanks, Andrew stunnel.cygport Description: Binary data Makefile.am Description: Binary data
cygport upload: patch for openssh 6.8p1
Since the latest update to openssh, ssh-keygen's output format for key
fingerprints has changed. The default hash algorithm is now base64-encoded
SHA256 instead of MD5, and the hash name precedes its value, like
SHA256:lvRrjAXmEhzDp5kQqzelsei8s5hXJ+zLaqJ2yiGXmYc
This breaks the current logic for detecting key fingerprints in cygport's
lib/pkg_upload.cygpart. The attached patch fixes the problem. (You might know
a more precise regex for the base64-encoded hash value than I do. I couldn't
find any documentation of it anywhere, and just settled for
SHA256:.{44}
)
Andrew
pkg_upload_key_fingerprint.patch
Description: Binary data
Re: [ITA] inetutils
On Apr 3 13:12, D. Boland wrote: I noticed that the package is orphaned. I 'd like to adopt it. Sure, adopting orphaned packages is super. Gold star awarded: http://cygwin.com/goldstars/#DB
Re: [ITA] xclip-0.12: Command line clipboard grabber
On Apr 23 14:21, Dr. Volker Zell wrote: Marco Atzeri writes: On 4/23/2015 1:53 PM, Dr. Volker Zell wrote: Hi I would like to adopt and maintain the orphaned 'xclip' package. already your https://cygwin.com/cygwin-pkg-maint I presume Corinna touched it, but there is no trace in the cvs log. Can I upload ? Did you checked the package ? Yes, please go ahead. Gold star awarded: http://cygwin.com/goldstars/#VZ
Re: [ITA] mosh
On Fri, 2015-05-15 at 23:06 +0200, Achim Gratz wrote: Mosh has been orphaned by Reini Urban and the setup.hint in 32bit is currently having a wrong dependency. I'm using mosh and would like to take over maintenance. Since there was no intervening upstream release, I've simply rebuilt using cygport and the latest toolchain. GTG, please proceed. Gold star awarded: http://cygwin.com/goldstars/#AG
Re: Obsolete dependency report, 2015-May-15 [GOLDSTAR]
On Sat, 2015-05-16 at 10:56 +0200, Marco Atzeri wrote: I am uploading the dependencies of singular now and testing Yue's last monolithic proposal. If it passes the test as expected I will also upload both archs during weekend. Wonderful! Thank you very much for helping with this. Andrew? This has been a lot more work than an average ITA; could Marco get two gold stars please? Awarded! http://cygwin.com/goldstars/#MA
Re: [PLUSH HIPPO] Re: [ITA] maxima-5.35.1
On Mon, 2015-05-18 at 17:41 -0400, Andrew Schulman wrote: On Mar 5 20:54, Achim Gratz wrote: In order to reap the fruits of Ken Brown's work on clisp and its dependencies (which seem to have escaped the attention of the plush hippo hordes so far) What? That's inexcusable. Andrew, one plush hippo for Ken, please. OK, sure. But I'm having trouble finding it... can you please point me to a cygwin-apps post? Hard to point to just one, but you could use this: https://cygwin.com/ml/cygwin-apps/2015-02/msg00186.html Awarded! http://cygwin.com/goldstars/#KB BTW, any news on rebuilding sng? https://cygwin.com/ml/cygwin-apps/2015-02/msg00152.html No, as you've probably noticed I haven't been able to spend time on Cygwin lately. Thanks for the reminder, though. I'll get to it when I can. Andrew
Re: [PLUSH HIPPO] Re: [ITA] cygwin-doc
On Mar 13 14:29, Jon TURNEY wrote: As invited [1], I shall adopt the cygwin-doc package. That's definitely a pink plush hippo for you. I made you maintainer in cygwin-pkg-maint. Awarded! http://cygwin.com/goldstars/#JTy
Re: [PLUSH HIPPO] Re: [ITA] maxima-5.35.1
On Mar 5 20:54, Achim Gratz wrote: In order to reap the fruits of Ken Brown's work on clisp and its dependencies (which seem to have escaped the attention of the plush hippo hordes so far) What? That's inexcusable. Andrew, one plush hippo for Ken, please. OK, sure. But I'm having trouble finding it... can you please point me to a cygwin-apps post? I'm proposing to resurrect maxima as a Cygwin package. The packaging is modeled after openSUSE. Resurrect? We had that already at one point? You're fishing for hippos, too, it seems ;) Gold star awarded: http://cygwin.com/goldstars#AG
Re: [SECURITY] lftp
A security issue has been noted with lftp: https://bugzilla.redhat.com/show_bug.cgi?id=1180209 This is the patch for 4.6.1: http://pkgs.fedoraproject.org/cgit/lftp.git/plain/lftp-4.6.1-auto-confirm.patch Thanks, I wasn't aware of that. New release coming out shortly.
Re: [SECURITY] lftp
A security issue has been noted with lftp: https://bugzilla.redhat.com/show_bug.cgi?id=1180209 This is the patch for 4.6.1: http://pkgs.fedoraproject.org/cgit/lftp.git/plain/lftp-4.6.1-auto-confirm.patch Thanks, I wasn't aware of that. New release coming out shortly. lftp will now no longer automatically store the host key fingerprints of unverified ssh servers. That's good, but it means that cygport up will now fail (probably mysteriously) for maintainers who are connecting by ssh/sftp to cygwin.com for the first time. New maintainers will need to connect by regular sftp to cygwin.com one time first, to store the host key fingerprint in known_hosts. After that cygport up will work. The cygport documentation should be updated to say this.
Re: HEADSUP: Packages with obsolete dependencies [GOLDSTARS]
Should I get anything for taking the orphaned grep/gperf/bison/diffutils/gzip when cgf left? (A single gold star is plenty for me; that plush hippo is above and beyond the level of effort it took :) For sure: https://cygwin.com/goldstars/#EB Sorry for the oversight. If anyone else is due some gold stars that I overlooked, please let me know.
Re: HEADSUP: Packages with obsolete dependencies [GOLDSTARS]
On Mar 4 19:23, Achim Gratz wrote: Corinna Vinschen writes: On Mar 3 15:59, Warren Young wrote: On Mar 3, 2015, at 1:25 PM, Corinna Vinschen corinna-cygwin-rdbxbdvo6bxqt0dzr+alfa-xmd5yjdbdmrexy1tmh2...@public.gmane.org wrote: On Mar 3 13:23, Warren Young wrote: On Mar 3, 2015, at 2:11 AM, Corinna Vinschen corinna-cygwin-rDBXBDvO6BVhl2p70BpVqQ-XMD5yJDbdMReXY1tMh2IBgC/g2k4z...@public.gmane.org wrote: Now that we have so many goldstars in circulation, maybe we can finally use it as new currency? Hey, shall we move from goldstars to plush hippos? The standard solution is higher denominations. So, we need platinum, rhodium, and uranium stars now. Hang on... plush hippos *are* a higher denomination. Whats the exchange rate? 3.1415926 goldstars for one plush hippo. Only for the pink ones, though. ;-) Huh? The plush hippos are always pink! Awarded! http://cygwin.com/goldstars/#CV
Re: [ITA] less-458-1
On Thu, 2015-02-12 at 08:06 +0100, Marco Atzeri wrote: I built and packaged the last stable version of less. wget -r -np -nH --cut-dirs=0 \ http://matzeri.altervista.org/x86_64/less/index.html wget -r -np -nH --cut-dirs=0 \ http://matzeri.altervista.org/x86/less/index.html I don't expect major issue, but just in case do you prefer I upload as test ? There is already a 458-1 for x86_64, so please call this 458-2. Otherwise, GTG; I don't see a need to make this test:. Gold star awarded: http://cygwin.com/goldstars/#MA
Re: [ITA] mscgen - Message Sequence Chart rendering programme
On Wed, 2015-02-18 at 14:28 +, David Stacey wrote:
# 32-bit:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/32bit/release
wget --no-check-certificate --no-host-directories --force-directories
--cut-dirs=5 \
${BASEURL}/mscgen/mscgen-0.20-2-src.tar.xz \
${BASEURL}/mscgen/mscgen-0.20-2.tar.xz \
${BASEURL}/mscgen/mscgen-debuginfo/mscgen-debuginfo-0.20-2.tar.xz \
${BASEURL}/mscgen/mscgen-debuginfo/setup.hint \
${BASEURL}/mscgen/setup.hint
# 64-bit:
BASEURL=https://dl.dropboxusercontent.com/u/119453582/Cygwin/64bit/release
wget --no-check-certificate --no-host-directories --force-directories
--cut-dirs=5 \
${BASEURL}/mscgen/mscgen-0.20-2-src.tar.xz \
${BASEURL}/mscgen/mscgen-0.20-2.tar.xz \
${BASEURL}/mscgen/mscgen-debuginfo/mscgen-debuginfo-0.20-2.tar.xz \
${BASEURL}/mscgen/mscgen-debuginfo/setup.hint \
${BASEURL}/mscgen/setup.hint
Rebuilt using libgd3, with three patches from Fedora [1].
GTG. Thanks for adopting,
Gold star awarded: http://cygwin.com/goldstars/#DSt
Re: [ITA] fcgi-2.4.0-3
On Tue, 2015-02-17 at 15:54 -0500, Ken Brown wrote: The x86 build is the same as Reini's build of 2.4.0-2, except for (a) a tweak to allow it to build with the current gcc and (b) a minor packaging change: The package provides some example C/C++ files in /usr/share/doc/fcgi/examples, and the build process compiles these. Reini put the corresponding *.exe files in a subdirectory of /usr/lib. If you choose to install them at all, this is correct. /usr/share is only for architecture-independent files. I also have a question: There are two *.la files, which cygport packages on x86 but not on x86_64. Should I add KEEP_LA_FILES=none, or do I risk breaking something by removing them from the 32-bit distro? The latter. The x86_64 build is new, but it built with no problems. Besides the examples location, there is another problem: libfcgi0_CONTENTS=usr/bin/*.dll Don't EVER do this; think about what would happen when a future release bumps the ABI version. Instead, be specific: libfcgi0_CONTENTS=usr/bin/cygfcgi*-0.dll GTG with these fixes. Gold star awarded: http://cygwin.com/goldstars/#KB
Re: [ITA] icu-54.1-1
On Mon, 2015-02-16 at 16:37 -0500, Ken Brown wrote: This builds easily on both arches, using essentially the same cygport file as Yaakov used for icu-51.2-1 on x86_64. I tested it by rebuilding the TeX Live binaries against libicu54. GTG. Please proceed, and thanks for adopting. I have also added a section to the obsolete dependency tracker for the old versions of icu. Gold star awarded: http://cygwin.com/goldstars/#KB
Re: [ITA] groff
On Feb 18 20:56, Achim Gratz wrote: I've cygported groff and want to maintain it. The current packaging did not have some files with perl dependencies and the X11 tools were not present. BANG! You're maintainer. Gold star awarded: http://cygwin.com/goldstars/#AG
Re: HEADSUP: Packages with obsolete dependencies
ploticus Andrew Schulman This package needs to be updated and I've tried a few times to rebuild it, but the build always fails and so far I haven't been able to solve it. I'm not actively using it any more anyway, so maybe it's time to obsolete it, unless someone else wants to pick it up. I'm always willing to discuss cases like this. Please post the .cygport and patches, along with the error message(s) you are seeing. Hm... I just fixed one problem and it seems to build now. Let me look at this again when I have a little more time - maybe I can finally update it. Updated.
Re: [RFC] cygport upload
On 2/12/2015 11:42 PM, Yaakov Selkowitz wrote: I have created an upload branch in cygport git based on master with Andrew's upload work for further testing. I'm still undecided on $arch/!ready vs. $arch/release/$package/!ready. Thoughts? $arch/release/$package/!ready should avoid the unlikely case when upload of a second package is running but a first package is in transfer from stage to main area. I agree, in case that's not obvious. Andrew
Re: [RFC] cygport upload
I have created an upload branch in cygport git based on master with Andrew's upload work for further testing. FWIW, I've been using it to upload my packages since the last update on Jan. 17, and before that too, with no problems. I always keep my ssh keys loaded in a running ssh-agent, so I've tested that case pretty well. I think it would be most useful to test the other cases: ssh-agent running but key not loaded; ssh-agent not running; private keys encrypted/unencrypted. Andrew
Re: HEADSUP: Packages with obsolete dependencies
orpieAndrew Schulman OK. I just rebuilt orpie, and now it depends on libncursesw10. Is that the right successor to libncurses10? If so, I'll upload the new build. ploticus Andrew Schulman This package needs to be updated and I've tried a few times to rebuild it, but the build always fails and so far I haven't been able to solve it. I'm not actively using it any more anyway, so maybe it's time to obsolete it, unless someone else wants to pick it up. Andrew
Re: HEADSUP: Packages with obsolete dependencies
On Wed, 2015-02-11 at 11:28 -0500, Andrew Schulman wrote: orpieAndrew Schulman OK. I just rebuilt orpie, and now it depends on libncursesw10. Is that the right successor to libncurses10? If so, I'll upload the new build. Yes, please. Done. ploticus Andrew Schulman This package needs to be updated and I've tried a few times to rebuild it, but the build always fails and so far I haven't been able to solve it. I'm not actively using it any more anyway, so maybe it's time to obsolete it, unless someone else wants to pick it up. I'm always willing to discuss cases like this. Please post the .cygport and patches, along with the error message(s) you are seeing. Hm... I just fixed one problem and it seems to build now. Let me look at this again when I have a little more time - maybe I can finally update it. And: sng Andrew Schulman ATM this won't build with libpng16. The source was only patched last year for libpng15, and not by the main author. I can't remember now where the patches came from - it wasn't me - but I'll see what I can find out. If you want to look at the build, here are the cygport and patch files: wget \ http://home.comcast.net/~andrex2/cygwin/sng/sng.cygport \ http://home.comcast.net/~andrex2/cygwin/sng/sng-ChangeLog.patch \ http://home.comcast.net/~andrex2/cygwin/sng/sng-sngc.patch \ http://home.comcast.net/~andrex2/cygwin/sng/sng-sngd.patch \ http://home.comcast.net/~andrex2/cygwin/sng/sng-usage.patch And the following files, taken from libpng15 I believe, have to be copied into the root of the build tree: wget \ http://home.comcast.net/~andrex2/cygwin/sng/extras/pngdebug.h \ http://home.comcast.net/~andrex2/cygwin/sng/extras/pnginfo.h \ http://home.comcast.net/~andrex2/cygwin/sng/extras/pngpriv.h \ http://home.comcast.net/~andrex2/cygwin/sng/extras/pngstruct.h Don't ask me why, I don't remember and the patches were someone else's. It worked. ATM the build is failing with: gcc -DHAVE_CONFIG_H -I. -I/home/andrex/dev/cygwin/sng/sng-1.0.6-2.x86_64/src/sng-1.0.6 -ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix-map=/home/andrex/dev/cygwin/sng/sng-1.0.6-2.x86_64/build=/usr/src/debug/sng-1.0.6-2 -fdebug-prefix-map=/home/andrex/dev/cygwin/sng/sng-1.0.6-2.x86_64/src/sng-1.0.6=/usr/src/debug/sng-1.0.6-2 -MT sngd.o -MD -MP -MF .deps/sngd.Tpo -c -o sngd.o /home/andrex/dev/cygwin/sng/sng-1.0.6-2.x86_64/src/sng-1.0.6/sngd.c /home/andrex/dev/cygwin/sng/sng-1.0.6-2.x86_64/src/sng-1.0.6/main.c: In function fatal: /home/andrex/dev/cygwin/sng/sng-1.0.6-2.x86_64/src/sng-1.0.6/main.c:43:5: warning: implicit declaration of function strlen [-Wimplicit-function-declaration] vsprintf(buf + strlen(buf), fmt, ap); ^ /home/andrex/dev/cygwin/sng/sng-1.0.6-2.x86_64/src/sng-1.0.6/main.c:43:20: warning: incompatible implicit declaration of built-in function strlen which seems like a trivial problem, but I haven't conquered it yet. Andrew
Re: cmake update needed
On Feb 4 12:45, Tony Kelman wrote: Bill promised several time to update cmake, but it seems clear to me that is has no the time to take care of it. It will be better to officially declare the package orphan so another volunteer can take it. Happy to adopt it. Super, thanks a lot. I added you to cmake in cygwin-pkg-maint, so, whenever you're ready, feel free to upload. Downside: You have to accept a goldstar ;) POW hit-and-run gold star at http://cygwin.com/goldstars/#TK
Re: [ITP] ssh-pageant 1.4
Dear all I would like to package ssh-pageant and propose it for inclusion in Cygwin. The small tool acts like an ssh-agent, but instead of storing its own keys, it is connecting to the PuTTY Pageant tool. This way the very useful Pageant tool can be used from Cygwin and no separate ssh-agent is required. +1
Re: [HEADSUP] Dropping libopenssl098 from distro
I, for one, welcome our new clisp overlord! ALL HAIL THE CLISP OVERLORD
Re: Python 3.4.2 [GOLDSTAR]
After much deliberation, I have decide to put my packages up for adoption. I have not had enough free time to properly maintain my packages for quite some time. Unfortunately, this is not going to change for the foreseeable future. No worries, hopefully you're busy with good things. Could we polish a gold watch in recognition of Jason's 14 years of contributions to Cygwin? Awarded! http://cygwin.com/goldstars/#JT
Re: cygport improvements: upload, fish, src_prep_fini_hook
If SSH_KEY is set (in the environment, or in ~/.cygport.conf), then cygport will load that key into an ssh-agent if necessary. Minor nit: SSH_KEY as env var is so generic and easily confused with the variables set by ssh-agent. Wouldn't something with CYGPORT in its name be better? CYGPORT_SSH_KEY? Either way is okay with me. Yaakov, do you have a preference? If SSH_KEY is not set, then it's just too hard to figure out what key ssh will use. To figure that out, we'd have to reproduce a bunch of logic in ssh, including parsing the ssh config file, and that's not going to happen. So, in this case we just give up and give lftp the connect string sftp://cygwin-rdbxbdvo6bxqt0dzr+a...@public.gmane.org, which will cause it to prompt for a passphrase every time. This puzzles me a bit. Even if an ssh-agent is running? Does lftp utilize a running ssh-agent? Yes, it does. lftp calls ssh to use as its network transport, so ssh-agent is supported and all of the usual rules apply for which key ssh will use for the connection. But here's the problem: I need to add the right key to ssh-agent before I run lftp. But which key is that? It could be any of the standard key names, or the user could specify an IdentityFile for cygwin.com in ~/.ssh/config. To figure it out I'd have to either: (1) Reimplement the rules that ssh uses to decide which key to use, including parsing ~/.ssh/config; or (2) Get ssh to tell me which key it uses, by running an initial ssh connection to cygwin.com and processing the output to get information about the key. I've thought about both of these options, and they're hard. They'd add complexity and unreliability that I think aren't justified by the gain in ease of use. So, the fallback is just to make maintainers add SSH_KEY to their .cygport.conf file, if they don't want to get prompted for a passphrase every time. I think it's an okay compromise. Andrew
Re: [HEADSUP Maintainers] _autorebase
On Jan 17 11:16, Achim Gratz wrote: Corinna Vinschen writes: What would be most helpful is to get a piece of documentation for us maintainers how to use the new _autorebase facility, sent with a fat HEADSUP subject, and which we can ideally add to setup.html. The _autorebase package is designed to require no intervention from a package maintainer in most cases. [...] Thanks Achim! The whole autorebase effort is so clearly gold star worthy that I went ahead and awarded one: http://cygwin.com/goldstars/#AG (I hope my description is right)
Re: cygport improvements: upload, fish, src_prep_fini_hook
You're right, this isn't pretty. :-( Any progress since then? OK, here's what I've worked out. If SSH_KEY is set (in the environment, or in ~/.cygport.conf), then cygport will load that key into an ssh-agent if necessary. * If no ssh-agent is running, cygport will start one and load the key, then kill the agent when the upload is done. * If an ssh-agent is running but the key isn't already loaded into it, cygport will load the key, then unload it again when the upload is done. In either of the above cases, ssh-add will prompt for a passphrase if needed when it loads the key. So in this case, the user will be prompted for a passphrase if and only if one is needed. Hooray. If SSH_KEY is not set, then it's just too hard to figure out what key ssh will use. To figure that out, we'd have to reproduce a bunch of logic in ssh, including parsing the ssh config file, and that's not going to happen. So, in this case we just give up and give lftp the connect string sftp://cyg...@cygwin.com, which will cause it to prompt for a passphrase every time. So this isn't a perfect solution, but I think it's the best available compromise. If, like me, you always have your keys loaded into an ssh-agent, and you don't want to be prompted for an unneeded passphrase on every upload, then you'll need to do the one-time configuration of setting SSH_KEY in your ~/.cygport.conf file. Then cygport will be able to figure out that it doesn't need to prompt you every time. I've coded the above and tested it in all of the cases of SSH_KEY set/not set, ssh agent running/not running, private key file encrypted/not encrypted, loaded/not loaded. It works for me, but of course more testing is welcome. Result is pushed to https://github.com/andrex-e-schulman/cygport/tree/upload. Thanks to Corinna for the suggestion of using ssh-agent. Andrew
Re: [GOLDSTAR] Re: [HEADSUP] Dropping libopenssl098 from distro [pure-ftpd done]
On Jan 16 09:08, Marco Atzeri wrote: On 1/15/2015 2:03 PM, Marco Atzeri wrote: On 1/14/2015 3:13 PM, Corinna Vinschen wrote: Hi folks, it's really *really* overdue to remove the OpenSSL 0.98 DLLs from the 32 bit distro. Fortunately they were never in the 64 bit distro. pure-ftpdKostya Altukhov I will look on it Regards Marco rebuilt and uploaded as 1.0.29-2 the 32 bit version. I will look later to upgrade it and the 64 bit version. It will take some time as Kostya made substantial patches to handle quota and root. Thanks, I think this is worth a goldstar. Andrew, do your worst. Awarded! http://cygwin.com/goldstars/#MA
Re: cygport improvements: upload, fish, src_prep_fini_hook
- Look if ssh-agent is running (SSH_AGENT_PID non-empty?) - If not, start ssh-agent and ssh-add. This asks for the passphrase, if any. - run sftp - If the script started ssh-agent, run eval $(ssh-agent -k) I just played with this a bit and it turned out that you must be careful in terms of the login shell the user is using. If you run this in a bash script, while the user's login shell is tcsh, it's essential to start ssh-agent with the -s flag: eval $(ssh-agent -c) [...] eval $(ssh-agent -k -c) Otherwise ssh-agent will generate tcsh-compatible setenv/unsetenv commands :} Ack, thanks. Another case is if the user sets SSH_KEY to use a specific key, and they already have an ssh-agent running, but it doesn't include that key. Then the key will have to be added and then removed again afterward, or maybe a different ssh-agent started. I'll have to think about that. SSH_KEY? This env var is not supported by ssh. If that's an lftp thingy you can ignore it using the above method. On second thought, yes, the user might want to use an ssh key which is not usually maintained by ssh-agent. Would it make sense to allow storing the key in ~/.cygport.conf? Yes, SSH_KEY is a variable that I added just to the cygport upload command, to allow people to specify a different key they might want to use for uploading. It can be specified in the shell environment or in ~/.cygport.conf. Testing if the key is already maintained by ssh-agent is easy: $ ssh-add -l 2048 88:75:95:cf:de:12:e0:15:45:f2:a6:8e:89:08:93:2c /path/to/private-key Checking the path might be sufficient, but if you want to be really sure, you could check against the fingerprint value instead: $ ssh-keygen -l -f /path/to/private-key 2048 88:75:95:cf:de:12:e0:15:45:f2:a6:8e:89:08:93:2c some string Yes, comparing hashes is better (though a bit scrapy). Thanks, Andrew
Re: cygport improvements: upload, fish, src_prep_fini_hook
It's vexing that it's so hard to find a solution to such a simple problem: prompt the user for a password if and only if one is needed. Indeed. Here's another crazy idea. - Look if ssh-agent is running (SSH_AGENT_PID non-empty?) - If not, start ssh-agent and ssh-add. This asks for the passphrase, if any. - run sftp - If the script started ssh-agent, run eval $(ssh-agent -k) Yeah, I think that is actually a pretty good idea. Thanks. Another case is if the user sets SSH_KEY to use a specific key, and they already have an ssh-agent running, but it doesn't include that key. Then the key will have to be added and then removed again afterward, or maybe a different ssh-agent started. I'll have to think about that. All that is a bit of work, but it uses all supported methods, and no screen scraping, so I think it's worth doing. Andrew
Re: cygport improvements: upload, fish, src_prep_fini_hook
You're right, this isn't pretty. :-( Any progress since then? Well, I had a good idea: set up a shared (ControlMaster) ssh connection first, in order to get the authentication out of the way, then have the sftp batch step use the shared connection. Unfortunately it seems that that idea isn't going to work, because although I didn't know it at first, ssh shared connections don't work in Cygwin. (Unless something has changed - no answer yet to https://cygwin.com/ml/cygwin/2015-01/msg00010.html .) Other possible ideas: * Write an expect script to look for a password prompt, pass it on to the user if it comes, otherwise go on with the batch sftp. * Start sftp as a bash coproc, and write bash code to look for the password prompt in the output. I tried this a bit but again it seems that sftp suppresses the password prompt if it detects that its stdin isn't coming from a TTY. Even if those ideas can be made to work, none of them is clearly better than the one I described before. All add complexity and depend on screen scraping. It's vexing that it's so hard to find a solution to such a simple problem: prompt the user for a password if and only if one is needed. If none of that seems worth the extra work, then I guess the fallback is to use lftp sftp://cygwin:@cygwin.com so that the user will always be prompted for a password, whether one is needed or not. Personally I would hate that, because I always have a running ssh-agent exactly so that I don't have to answer password prompts all the time. But it would work. PITA Andrew
Re: cygport improvements: upload, fish, src_prep_fini_hook
lftp sftp://cygwin:@cygwin.com Sorry, should be lftp sftp://cyg...@cygwin.com
Re: cygport autogen.sh gives DOS line ending errors
After you clone cygport in Cygwin, do you get the same result as below? $ file autogen.sh autogen.sh: Bourne-Again shell script, ASCII text executable, with CRLF line terminators No CRLF. Either you're using a Windows git, or maybe you're trying to clone into a text mount. Thank you for your help. I found the problem. In my ~/.gitconfig, SOMEONE set [core] autocrlf = true I say SOMEONE because I would NEVER do that. In the last few weeks I've been trying out some Windows git clients. I'm not even sure which ones, but I installed and uninstalled several. One of them apparently took the liberty of making this change for me. Grrr. I nuked the offending line and the problem is fixed. Sorry to have bothered you. Andrew
cygport autogen.sh gives DOS line ending errors
Here's a strange one. When I check out cygport and try to run its
autogen.sh, I get a bunch of errors about DOS line endings:
/tmp git clone
git://cygwin-ports.git.sourceforge.net/gitroot/cygwin-ports/cygport
Cloning into 'cygport'...
remote: Counting objects: 9806, done.
remote: Compressing objects: 100% (5420/5420), done.
remote: Total 9806 (delta 7577), reused 5556 (delta 4376)
Receiving objects: 100% (9806/9806), 1.37 MiB | 1.15 MiB/s, done.
Resolving deltas: 100% (7577/7577), done.
Checking connectivity... done.
/tmp cd cygport
/tmp/cygport git submodule update --init
Submodule 'data/gnuconfig' (git://git.sv.gnu.org/config.git) registered for
path 'data/gnuconfig'
Cloning into 'data/gnuconfig'...
remote: Counting objects: 3644, done.
remote: Compressing objects: 100% (1678/1678), done.
remote: Total 3644 (delta 1933), reused 3629 (delta 1925)
Receiving objects: 100% (3644/3644), 591.90 KiB | 971.00 KiB/s, done.
Resolving deltas: 100% (1933/1933), done.
Checking connectivity... done.
Submodule path 'data/gnuconfig': checked out
'5049811e672698aa2337bb27ede94e54c9174154'
/tmp/cygport ./autogen.sh
./autogen.sh: line 2: $'\r': command not found
: invalid optionne 3: set: -
set: usage: set [--abefhkmnptuvxBCHP] [-o option-name] [arg ...]
./autogen.sh: line 4: $'\r': command not found
./autogen.sh: line 7: $'\r': command not found
head: cannot open '.\r/configure.ac' for reading: No such file or directory
./autogen.sh: line 9: $'\r': command not found
./autogen.sh: line 10: syntax error near unexpected token `$'{\r''
'/autogen.sh: line 10: `verbose() {
What's strange about this is that I've run these same steps many times
before, and autogen.sh always ran fine, with no line ending errors. But
since a week or two ago, I always get this error, on all of my cygwin
hosts.
git shows that autogen.sh hasn't changed in years, so it seems that
something about my cygwin installation has. What am I doing wrong?
If I run 'dos2unix autogen.sh', then autogen.sh runs fine and I can
continue with make; make install. But then I start to run into more errors
about DOS line endings in other files.
Output of cygcheck -svr is attached.
Andrew
cygcheck-svr.out
Description: Binary data
Re: cygport autogen.sh gives DOS line ending errors
On 2014-12-30 09:43, Andrew Schulman wrote: Here's a strange one. When I check out cygport and try to run its autogen.sh, I get a bunch of errors about DOS line endings: Are you sure you're using a Cygwin git? Yes. /tmp which git /usr/bin/git /tmp git --version git version 2.1.1 I actually did have a Window git installed, although it wasn't on the PATH. But to be sure, I removed it and tried again, with the same result.
Re: cygport autogen.sh gives DOS line ending errors
On 2014-12-30 09:43, Andrew Schulman wrote: Here's a strange one. When I check out cygport and try to run its autogen.sh, I get a bunch of errors about DOS line endings: Are you sure you're using a Cygwin git? So is Cygwin git normally supposed to take care of the DOS line endings? After you clone cygport in Cygwin, do you get the same result as below? $ file autogen.sh autogen.sh: Bourne-Again shell script, ASCII text executable, with CRLF line terminators
Re: cygport improvements: upload, fish, src_prep_fini_hook
Here's what I have at the moment based on your branch as of a few weeks ago. However, with password-protected SSH keys, the password prompt isn't handled properly. Any ideas? OK, I've looked into this. It can be done, but the only solution I can see so far is ugly. Here's the deal: Using lftp: There's no way to get lftp to ask for a passphrase if and only if it needs one. I asked about this on the lftp list, and Alexander confirmed it. lftp will either always ask for a passphrase, if the connect string looks like cyg...@cygwin.com or never ask for one, if it looks like cygwin:@cygwin.com So the only way to get lftp to ask for a passphrase iff it needs one is to figure out in advance which key will be used, find out whether the key is encrypted, and use that to pick one of the above connect strings. More about that below. Using sftp: sftp seems as though it might work better, since it will prompt the user for a passphrase if and only if it needs one to decrypt the key. But to feed a batch script to sftp you have to use sftp -b, and unfortunately that disables interactive prompting for the passphrase. I checked this by running sftp -b with an encrypted key, and sure enough, it didn't prompt for the passphrase but just reported Connection closed. So this all kind of sucks. The only solution I can see so far is: (1) Run ssh -v cyg...@cygwin.com initially, and scrape stderr to find the file name of the key that's being used. (Between ssh-agents, IdentityFile entries in .ssh/config, and default key file names, I don't think there's any other sane way to figure out what key file ssh will use.) (2) Run ssh-keygen -y or similar, to figure out whether the key is encrypted. (3) If the key is encrypted, run lftp sftp://cyg...@cygwin.com so lftp will prompt for the passphrase. If it's not encrypted, run lftp sftp://cygwin:@cygwin.com and lftp won't prompt. Is this solution acceptable? It's ugly and slow (an extra ssh connection), but I guess it should be reliable. Is there some better way that I'm overlooking? An expect script? That's starting to sound like a lot of work. Andrew
Re: [HEADSUP Maintainers] setup.exe new postinstall facitilities
--8---cut here---start-8--- I love the little ASCII art scissors.
Re: cygport improvements: upload, fish, src_prep_fini_hook
The point of having an upload command is to relieve packagers of the tedium and likelihood of getting it wrong when they have to remember where to connect to and which commands to run to put what files where. How much nicer to just run cygport up and let cygport handle it. It then does not in fact work correctly when you're uploading from more than a single cygport file that depend on each other. I guess this is a limitation of cygport. cygport always only works with one cygport file at a time, in each invocation. So no, it won't look around to find required packages built from different cygport files and upload them too/first, if that's what you mean. If you're talking about the case of multiple packages being built from one cygport file and one source archive, yes, it does handle that case correctly. I frequently build multiple packages (in the case of Perl that means tens to hundreds depending on whether I do a full rebuild or just updates) and there's no way I'm ever going to upload anything directly from the build machine to cygwin.com. So what you're implementing isn't useful in that situation for me. I'll just patch cygport to link the dist directories into my local mirror structure then. Hm. OK. That sounds like an unusual case to me, but I guess it might make sense to add a variable to allow uploading to some place other than cygwin.com. It could get into some work to deal with upload methods for different URL schemes, though. I'm still struggling a bit with sftp. * !ready will only be created after all of the files have been successfully uploaded. If there's an error during the upload, it's not created. There is only a single cygport file handled for each invocation. Yes. But if there are multiple resulting packages, they're all uploaded together, then !ready is created. * The current implementation puts the !ready file into a package-specific directory, e.g. /x86_64/screen, instead of /x86_64. So by running cygport up you only flag a single package as ready, not the whole arch directory. That is better, but still doesn't handle the case where dependencies across packages change. That is admittedly rare, but it's a limitation of what you're implementing. Yes it is, since it doesn't handle dependencies across packages with different cygport files at all. Just one cygport file at a time, and the one or more packages that are built from it. Andrew
Re: cygport improvements: upload, fish, src_prep_fini_hook
On Dec 8 20:40, Andrew Schulman wrote: Here's what I have at the moment based on your branch as of a few weeks ago. However, with password-protected SSH keys, the password prompt isn't handled properly. Any ideas? Re password prompts: I see the problem. It's because I echo the lftp script to stdout, and pipe it into lftp -f /dev/stdin. So stdin is unavailable for the password prompt. I think using process substitution instead will be an easy fix for this. OK, I looked into this. Unfortunately lftp seems not to support using encrypted SSH keys for sftp. First I freed up stdin for lftp to use, by using process substitution instead of -f/dev/stdin, as I said before. But it still doesn't work. So I tried it with lftp from the command line. With an unencrypted key it works, but with an encrypted key you get the following: $ lftp sftp://cygwin:@cygwin.com lftp cygwin-rdbxbdvo6bxqt0dzr+a...@public.gmane.org:~ set sftp:connect-program ssh -a -x -i /path/to/encrypted/key lftp cygwin-rdbxbdvo6bxqt0dzr+a...@public.gmane.org:~ ls `.' Enter passphrase for key '/home/andrex/.ssh/keys/home': and the connection fails. It seems that lftp intercepts the password prompt. OK, my mistake. lftp author reminded me that this is only happening because I specified an empty passphrase in the connect string: colon after cygwin in sftp://cygwin:@cygwin.com;. So I'll take another look and fix this. I may be missing something here, but given that this is all scripted anyway, why not use sftp directly? I did code an alternate implementation using sftp, but it had some disadvantages. I think the main one was that sftp doesn't have a recursive delete or mirror, so I had to write a bunch of kludgy rm's. Both ways work, with minor disadvantages. Andrew
Re: cygport improvements: upload, fish, src_prep_fini_hook
Andrew Schulman writes: upload Adds the upload command: upload finished packages to cygwin.com. I don't think the !ready files should be created by cygport, at all. Yaakov will decide, but I disagree. The point of having an upload command is to relieve packagers of the tedium and likelihood of getting it wrong when they have to remember where to connect to and which commands to run to put what files where. How much nicer to just run cygport up and let cygport handle it. I suppose the step of uploading the !ready file could be separated out into a separate cygport command, but it really doesn't seem worth the trouble. Also, I would rather want to place these files into a local staging/mirror area first and then upload after the files have been tested (lftp work great for this). But cygport already does that. They're in the dist/$PN subdirectory, all arranged as they need to be for uploading. You can test them there until you're satisfied they're correct, before you run cygport up. Also note that: * !ready will only be created after all of the files have been successfully uploaded. If there's an error during the upload, it's not created. * The current implementation puts the !ready file into a package-specific directory, e.g. /x86_64/screen, instead of /x86_64. So by running cygport up you only flag a single package as ready, not the whole arch directory. Andrew
Re: cygport improvements: upload, fish, src_prep_fini_hook
* The current implementation puts the !ready file into a package-specific directory, e.g. /x86_64/screen, instead of /x86_64. Should say: /x86_64/release/screen, instead of /x86_64/release.
Re: cygport improvements: upload, fish, src_prep_fini_hook
Here's what I have at the moment based on your branch as of a few weeks
ago. However, with password-protected SSH keys, the password prompt
isn't handled properly. Any ideas?
Re password prompts: I see the problem. It's because I echo the lftp
script to stdout, and pipe it into lftp -f /dev/stdin. So stdin is
unavailable for the password prompt.
I think using process substitution instead will be an easy fix for this.
OK, I looked into this. Unfortunately lftp seems not to support using
encrypted SSH keys for sftp.
First I freed up stdin for lftp to use, by using process substitution
instead of -f/dev/stdin, as I said before. But it still doesn't work.
So I tried it with lftp from the command line. With an unencrypted key it
works, but with an encrypted key you get the following:
$ lftp sftp://cygwin:@cygwin.com
lftp cyg...@cygwin.com:~ set sftp:connect-program ssh -a -x -i
/path/to/encrypted/key
lftp cyg...@cygwin.com:~ ls
`.' Enter passphrase for key '/home/andrex/.ssh/keys/home':
and the connection fails. It seems that lftp intercepts the password
prompt. I'll ask about this on the lftp list, but meanwhile I think the
best we can do is to add a note in the documentation saying that users
will have to provide either an ssh-agent, or an unencrypted key in
SSH_KEY. I went ahead and added that.
All the other issues have been addressed:
* Rebased against cygport/master.
* Moved !ready into $archdir/$NAME.
* Re-added doc for Uploading/SSH_KEY (accidentally removed in 8954ada).
* Misc. other small fixes to agree with your patch.
* In __pkg_upload(), I see you removed the default case in
case ${ARCH} in
i686) archdir=(x86) ;;
x86_64) archdir=(x86_64) ;;
noarch) archdir=(x86 x86_64) ;;
*) error Don't know where to upload packages with architecture
${ARCH} ;;
esac
The default is intended as future-proofing for other, future Cygwin
architectures. I figure it's better to code an explicit error message now,
than to leave a lurking error condition for later. But your call.
Andrew
Re: [HEADSUP] Base category
isn't it rather annoying that even Base packages have dependencies outside the Base category? So, even if I perform a plain Base-only installation, I get asked if dependencies shall be fullfilled, which, as a question, is more than borderline anyway. Therefore, shouldn't we put all packages Base packages depend on into Base as well? I can't find it in the archives now, but a year or two ago we talked about this in the context of libargp. There's a Base package (can't remember which one) that depends on libargp. But the consensus at the time was that we shouldn't put libargp into Base, because if the other package stopped requiring it, it wouldn't belong there on its own. So if we're talking about permanently adding those other packages to the Base category, I don't agree. But it we're talking about adding them to Base automatically only as long as another Base package requires them, then I guess that's fine. Andrew
Re: cygport improvements: upload, fish, src_prep_fini_hook
BTW I see that you commented out the line: echo rm -f !ready || echo -n in the lftp script in __pkg_upload(). That line is there to prevent a race condition if the maintainer has already made one upload, then later starts to make another one, at the same time that upset starts to copy files from the upload area. In that case, upset could copy partially uploaded or corrupt files. To prevent that, we first remove !ready, then put it back later after the new upload is complete. Thanks for reminding me: I was wondering if it made more sense to place a !ready file in each top-level package directory, or handle each arch like you have done. I could see arguments either way, so I'm open to suggestions. Isn't a `cygport cygportfile upload always per-arch? It's per-arch and per-package, so the !ready file can go in the $ARCH/$PN directory, instead of $ARCH. That's what Yaakov is suggesting. I think that is better - more specific since uploads are per-package. I'll make it so. We still want to remove any exiting $ARCH/$PN/!ready file first though, to prevent race conditions if a packager decides to re-upload a package while upset is starting to copy the package files.
Re: cygport improvements: upload, fish, src_prep_fini_hook
Here's what I have at the moment based on your branch as of a few weeks ago. However, with password-protected SSH keys, the password prompt isn't handled properly. Any ideas? OK. Looks good. Re password prompts: I see the problem. It's because I echo the lftp script to stdout, and pipe it into lftp -f /dev/stdin. So stdin is unavailable for the password prompt. I think using process substitution instead will be an easy fix for this. I'll code this up, test it and push it out shortly. BTW I see that you commented out the line: echo rm -f !ready || echo -n in the lftp script in __pkg_upload(). That line is there to prevent a race condition if the maintainer has already made one upload, then later starts to make another one, at the same time that upset starts to copy files from the upload area. In that case, upset could copy partially uploaded or corrupt files. To prevent that, we first remove !ready, then put it back later after the new upload is complete. Andrew
Re: [HEADSUP] Proposal for change in postinstall script handling (was Re: [RFC] incremental rebase)
On Nov 19 12:38, Achim Gratz wrote: Corinna Vinschen writes: In any case, this is mainly about putting the mechanism in place or rather to specify it. Making it usable would require support from cygport and upset/genini. Not upset, it seems. IIUC the stratumification can firmly stay in setup' s hands with some support from cygport. Upset wouldn't even notice it. Using hidden groups (like the non-functional _PostInstallLast we already have) would be an obvious way to do that. Isn't that moot then? Stratum z would do it for free... In both cases the use of the prefix is what decides the stratum. Arguably that could be made explicit in setup.hint instead, but that would require extension of the data format and changes to tools that use the data. As long as we're manually assigning those strata (or farming this out into cygport) then no such support would be needed indeed. ANother question: setup is used by other projects it seems. How do we ensure they either agree with us or are unaffected by this change? Makes sense. And the naming convention? No chance for collisions with existing scripts? The Cygwin Package Search says that no such postinstall scripts currently exist, so I'd say we're GTG with the prefix idea. I'd like to have some more input here. Maintainers, if you have any input to this, please follow up. I'm sorry - I didn't follow the previous discussion and am having trouble following this. Could you please restate what's being proposed?
Re: [HEADSUP] Proposal for change in postinstall script handling (was Re: [RFC] incremental rebase)
I'd like to have some more input here. Maintainers, if you have any input to this, please follow up. I'm sorry - I didn't follow the previous discussion and am having trouble following this. Could you please restate what's being proposed? It starts here: https://cygwin.com/ml/cygwin-apps/2014-11/msg00064.html Two major proposals on the plate: https://cygwin.com/ml/cygwin-apps/2014-11/msg00086.html https://cygwin.com/ml/cygwin-apps/2014-11/msg00098.html Thanks. Frankly it all looks overcomplicated to me. The current system of here's a postinstall script, run it once some time after the package files are installed has always completely met my needs. But I get that other packages have stronger requirements, so I don't object. As long as cygport will handle the details of naming the script, maybe from hints in the cygport file about the priority or order, then it doesn't matter to me which proposal we use. Andrew
Re: [HEADSUP] Proposal for change in postinstall script handling (was Re: [RFC] incremental rebase)
Andrew Schulman writes: I'm sorry - I didn't follow the previous discussion and am having trouble following this. Could you please restate what's being proposed? TL;DR: Everyone who has been happy with the current way of how install and postinstall works has nothing to fear or do. Thanks. I will fear and do nothing :)
[ITP] sitecopy
I want to maintain sitecopy for Cygwin. sitecopy is in Debian: https://packages.debian.org/stable/utils/sitecopy setup.hint: category: Net Web requires: libintl8 libneon27 sdesc: Manage a WWW site via FTP, SFTP, DAV or HTTP ldesc: Sitecopy is for copying locally stored websites to remote servers. With a single command, the program will synchronize a set of local files to a remote server by performing uploads and remote deletes as required. The aim is to remove the hassle of uploading and deleting individual files using an FTP client. Sitecopy will also optionally try to spot files you move locally, and move them remotely. Sitecopy is designed to not care about what is actually on the remote server - it simply keeps a record of what it THINKS is in on the remote server, and works from that. Package files: x86: http://home.comcast.net/~andrex2/cygwin/x86/sitecopy/setup.hint http://home.comcast.net/~andrex2/cygwin/x86/sitecopy/sitecopy-0.16.6-1.tar.xz http://home.comcast.net/~andrex2/cygwin/x86/sitecopy/sitecopy-0.16.6-1-src.tar.xz x86_64: http://home.comcast.net/~andrex2/cygwin/x86_64/sitecopy/setup.hint http://home.comcast.net/~andrex2/cygwin/x86_64/sitecopy/sitecopy-0.16.6-1.tar.xz http://home.comcast.net/~andrex2/cygwin/x86_64/sitecopy/sitecopy-0.16.6-1-src.tar.xz
Re: [ITP] discus
Neat, but does it work as intended? $ df Filesystem 1K-blocks Used Available Use% Mounted on //calimero.vinschen.de/cygwin 194676832 48674368 146002464 26% /cygwin //calimero.vinschen.de/ext 191068816 29408432 161660384 16% /ext C: 41581564 353284086253156 85% /mnt/c Q: 2097148 254722071676 2% /mnt/q $ discus Mount Total Used Avail Prcnt Graph /mnt/c 39.66 GB 33.69 GB 5.96 GB85.0% [--] /mnt/q 2.00 GB 24.9 MB 1.98 GB 1.2% [--] I'm missing my network shares. --help doesn't show an option character. So I went ahead and changed /etc/discusrc to include shares but not if they are bind mounts: opts[mtab] = !/bin/grep -E '^[A-Z]: |^//[a-z]' /proc/mounts | grep -v iso9660 | grep -v ',bind' $ discus Mount Total Used Avail Prcnt Graph /cygwin185.66 GB 46.42 GB139.24 GB25.0% [***---] /ext 182.22 GB 28.05 GB154.17 GB15.4% [**] /mnt/c 39.66 GB 33.69 GB 5.96 GB85.0% [--] /mnt/q 2.00 GB 24.9 MB 1.98 GB 1.2% [--] Would that make sense as default or do you deliberatly restrict this to local drives? Thanks. Yes, that makes sense as a default, and I'll include it in release -1. I was just trying to eliminate bind mounts, but I overlooked network shares. Andrew
[ITA] time
Another abandoned package. Builds with only a little fiddling. Last update upstream was in 1996. x86: http://home.comcast.net/~andrex2/cygwin/x86/time/setup.hint http://home.comcast.net/~andrex2/cygwin/x86/time/time-1.7-4.tar.xz http://home.comcast.net/~andrex2/cygwin/x86/time/time-1.7-4-src.tar.xz x86_64: http://home.comcast.net/~andrex2/cygwin/x86_64/time/setup.hint http://home.comcast.net/~andrex2/cygwin/x86_64/time/time-1.7-4.tar.xz http://home.comcast.net/~andrex2/cygwin/x86_64/time/time-1.7-4-src.tar.xz
[ITP] discus
I want to maintain discus for Cygwin. discus is in Debian: https://packages.debian.org/unstable/utils/discus setup.hint: category: Utils requires: python sdesc: Pretty version of df(1) command ldesc: Discus aims to make df prettier, with features such as color, graphs, and smart formatting of numbers (automatically choosing the most suitable size from kilobytes, megabytes, gigabytes, or terabytes). If you don't want Discus deciding the best sizes, you can also choose your own increments, along with specifying the number of decimal places you'd like to see. Package files (noarch): http://home.comcast.net/~andrex2/cygwin/setup.hint http://home.comcast.net/~andrex2/cygwin/discus-0.2.9-1.tar.xz http://home.comcast.net/~andrex2/cygwin/discus-0.2.9-1-src.tar.xz
Re: HEADSUP Maintainers: Stale packages on sourceware
Please find attached a list of old package tarballs which are not listed anywhere in setup.ini, meaning that they are not listed as a previous, current, or test package, and cannot be installed with setup. These files consume a total of over 1.3Gib. Do maintainers have any objections to these being removed? I don't have any objection for my packages (lftp, screen, socat, stunnel). I had actually just noticed these old tarballs on one of the Cygwin mirrors, and was going to ask about them. In my opinion, they should be automatically removed once they're no longer installable. If some maintainers aren't comfortable with that, then maybe the old package files could be removed after a wait of, say, 3 months. But that could take some bookkeeping, and really it's hard to think of a case when it would be important to do. Andrew
Re: cygport improvements: upload, fish, src_prep_fini_hook
On 2014-10-19 09:13, Andrew Schulman wrote: I've published several improvements to cygport on Github. Each improvement is in its own branch: upload Adds the upload command: upload finished packages to cygwin.com. I definitely want to add this feature. However, the implementation is overly complicated; only one upload client need be supported, which should then be added to requires:. (Yes, I'm aware that downloading handles wget or curl, but that is legacy code and the same should apply there.) The pkg_name for loops are also incorrect wrt subpackages. Both fixed in the upload branch.
Re: cygport improvements: upload, fish, src_prep_fini_hook
Thanks for taking a look. On 2014-10-19 09:13, Andrew Schulman wrote: I've published several improvements to cygport on Github. Each improvement is in its own branch: upload Adds the upload command: upload finished packages to cygwin.com. I definitely want to add this feature. However, the implementation is overly complicated; only one upload client need be supported, which should then be added to requires:. (Yes, I'm aware that downloading handles wget or curl, but that is legacy code and the same should apply there.) OK, I'll pick one and simplify. lftp and sftp both work, but both have annoyances. I still haven't found a way to make lftp give better progress information during uploads - it seems really determined to shut that information off when it's not getting input from a TTY. sftp doesn't have a recursive remove so you have to do a bunch of extra kludgy work to remove the existing upload directories. The pkg_name for loops are also incorrect wrt subpackages. OK. Can you please suggest a package with subpackages that I can easily build to see what's going on in that case? Also, I want to be sure I understand https://sourceware.org/ml/cygwin-apps/2014-08/msg00028.html. That message was talking about primary package names, which now all go at the top level under release. But subpackages should still be nested within their primary package directories, like the *-debuginfo packages. Correct? And I guess that cygport will create the subpackage directories within dist/ as they should be uploaded? fish Creates fish scripts in /etc/profile.d/*.fish. Merged, with a note in the documentation wrt portability. Good, thanks. src_prep_fini_hook Adds support for the src_prep_fini_hook() hook function, which runs at the end of prep, after creation of the src directory. This seems to be the only way to copy in complete files to the src directory during prep. If all you want to do is copy files to $S during unpacking, just add them to SRC_URI. That is the only use case I have for that hook. I'll take a look and see if that works. Andrew
Re: cygport improvements: upload, fish, src_prep_fini_hook
OK. Can you please suggest a package with subpackages that I can easily build to see what's going on in that case? Nevermind, I'm using arpack.
cygport improvements: upload, fish, src_prep_fini_hook
I've published several improvements to cygport on Github. Each improvement
is in its own branch:
upload
Adds the upload command: upload finished packages to cygwin.com.
fish
Creates fish scripts in /etc/profile.d/*.fish.
src_prep_fini_hook
Adds support for the src_prep_fini_hook() hook function, which runs
at the end of prep, after creation of the src directory. This seems to be
the only way to copy in complete files to the src directory during prep.
src_patch_hook() and src_unpack_hook() don't work for that, because they
run before src is created. (You could use them to copy files into
origsrc, but then the diff wouldn't appear in the cygwin.patch.)
I find this hook essential for copying in extra files such as the
CYGWIN-PATCHES directory, including README.Cygwin, during prep, and
having them reflected in the cygwin.patch. In .cygport.conf:
CYGPORT_USE_UNSTABLE_API=1
src_prep_fini_hook ()
{
cd ${top}
# copy in extra files
if [[ -d extras $(ls extras) ]] ; then
inform Copying in extra files
cp -a extras/* ${S}
fi
}
It's much easier to maintain extra files as files like this and copy them
in during prep, than to keep them as patches.
Originally proposed years ago by Charles Wilson. Some old discussion is
at https://sourceware.org/ml/cygwin-apps/2008-10/msg00087.html .
all
Merges the upload, fish, and src_prep_fini_hook branches. This is the
version I use for my regular packaging.
Git repository:
Web https://github.com/andrex-e-schulman/cygport
git clone https://github.com/andrex-e-schulman/cygport.git
To try a package with all of the above improvements (for x86 or x86_64):
wget http://home.comcast.net/~andrex2/cygwin/cygport-0.17.0-aes1.tar.xz
tar -Jx -C/ -f cygport-0.17.0-aes1.tar.xz
Andrew
Re: Updated: bc-1.06.95-2
It seems you meant to send these to announce Yes, sorry about that.
Re: [ITA] fish
Hi Andrew, On Oct 13 11:38, Corinna Vinschen wrote: On Oct 13 04:33, Andrew Schulman wrote: I'd like to adopt the fish package. The package seems to be abandoned. A new release is out upstream with multiple security fixes, but the Cygwin package hasn't been updated. Emails to the maintainer have bounced, and he hasn't answered recent discussions on the cygwin list about the need to update the package and fix some problems in it. thanks for your willingness to take over. I just wrote another mail to Konrad, and so far it didn't bounce. If I don't get a reply during this week, the package is all yours. It's yours. I just got the bounce so we're having a hard time to reach out to Konrad. OK. Thanks.
[ITA] bc
I see that bc is orphaned. Since fish depends on it, I'd like to adopt it. I checked the cygport script, and it builds fine from source. bc hasn't been updated since 2006, so I'm not expecting to make any new releases any time soon. Andrew
Re: [ITA] bc
bc hasn't been updated since 2006, so I'm not expecting to make any new releases any time soon. The 32 bit version is older, lacking some patches and lacking a cygport based source archive. Would you mind terribly to create and upload a bc-1.06.95-1 32 bit package along the lines of the 64 bit version? OK
Updated: bc-1.06.95-2
The bc package has been updated in the Cygwin distribution. This is a minor update, a Cygwin point release, that includes the latest patches from upstream, latest meaning mostly 3 years ago or more. bc is an arbitrary precision numeric processing language. Syntax is similar to C, but differs in many substantial areas. It supports interactive execution of statements. bc is a utility included in the POSIX P1003.2/D11 draft standard. Andrew E. Schulman *** To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain.com_at_cygwin.com If you need more information on unsubscribing, start reading here: http://cygwin.com/lists.html#subscribe-unsubscribe Please read *all* of the information on unsubscribing that is available starting at this URL.
Updated: fish-2.1.1-3 [SECURITY]
The fish package has been updated in the Cygwin distribution. New in this release: * Multiple security fixes. See the release notes for version 2.1.1 at http://fishshell.com/release_notes.html . * Add system directories to PATH. fish now runs correctly as the user's default login shell. * Source /etc/profile.d/*.fish at start in login shells. * Add dependency on bc. This is a security update. All fish users are strongly urged to upgrade. fish is the friendly interactive shell. It's a Unix shell that focuses on interactive use, discoverability, and user friendliness. The design goal of fish is to give the user a rich set of powerful features in a way that is easy to discover, remember, and use. Home page: http://fishshell.com Andrew E. Schulman *** To update your installation, click on the Install Cygwin now link on the http://cygwin.com/ web page. This downloads setup.exe to your system. Then, run setup and answer all of the questions. *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the List-Unsubscribe: tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain.com_at_cygwin.com If you need more information on unsubscribing, start reading here: http://cygwin.com/lists.html#subscribe-unsubscribe Please read *all* of the information on unsubscribing that is available starting at this URL.
Re: cygport upload command?
Minor nit: This should be `cygport upload' to be in line with the other cygport commands. Alternatively, cygport could introduce a two-letter abbreviation scheme, for instance: cygport download- cygport dl or (rcs-like) co cygport prep- cygport pr cygport build - cygport mk or cc cygport install - cygport in cygport package - cygport pk cygport upload - cygport up or (rcs-like) ci I didn't say so, but yes, the command is named and described everywhere as 'cygport upload'. 'cygport up' also works. I didn't think of 'cygport ci', but that's a good idea.
[ITA] fish
I'd like to adopt the fish package. The package seems to be abandoned. A new release is out upstream with multiple security fixes, but the Cygwin package hasn't been updated. Emails to the maintainer have bounced, and he hasn't answered recent discussions on the cygwin list about the need to update the package and fix some problems in it. I took the existing cygport script, revised it a bit, added fixes for all of the known problems, and rolled a new release (below). If it seems okay, I'll upload it. Andrew x86: http://home.comcast.net/~andrex2/cygwin/x86/setup.hint http://home.comcast.net/~andrex2/cygwin/x86/fish-2.1.1-2.tar.xz http://home.comcast.net/~andrex2/cygwin/x86/fish-2.1.1-2-src.tar.xz x86_64: http://home.comcast.net/~andrex2/cygwin/x86_64/setup.hint http://home.comcast.net/~andrex2/cygwin/x86_64/fish-2.1.1-2.tar.xz http://home.comcast.net/~andrex2/cygwin/x86_64/fish-2.1.1-2-src.tar.xz
Re: [ITA] fish
One comment regarding the new config.fish file - can you make the cd $HOME dependent upon the CHERE_INVOKING variable being unset? That way chere will work for those who set it up for fish. See /etc/profile for the bash equivalent. Sure, that will go in revision -3.
Re: cygport upload command?
On 2014-07-07 20:14, Andrew Schulman wrote: Yaakov, would you consider adding an 'upload' command to cygport, that would handle the uploading details? That would take away the last bit of manual work in a routine package update. I'm a bit busy at the moment, but it sounds like a good idea to me. I have an implementation of this ready at https://github.com/andrex-e-schulman/cygport. What's new compared to upstream git: * New upload command (cygport up). * Documented upload command in manuals and README. * Currently only one upload client, lftp, is supported. I've tested the implementation a good bit, and it works well as long as there's no trouble, i.e. lftp can connect to sftp://cygwin.com. If it can't connect, then you get told max-retries exceeded and Upload failed, which doesn't help at all to figure out why the upload failed (can't connect, can't authenticate, ...). Unfortunately, it's hard to make lftp give much better information. * Simple API for adding support for other upload clients. The API is described in pkg_upload.cygpart. I'm planning to add support for sftp and rsync soon, and I hope it will be easier to get useful failure information from them if the upload fails. Please let me know if you have any comments or would like to see any changes. Andrew
Re: [ITA] ed-1.10-1
On 2014-08-17 03:46, Marco Atzeri wrote:
On 17/08/2014 09:56, Yaakov Selkowitz wrote:
On Sun, 2014-08-17 at 09:44 +0200, Marco Atzeri wrote:
On 17/08/2014 08:47, Yaakov Selkowitz wrote:
Why no debuginfo?
no idea.
the build system is a bit basic, pre-autoconf age,
Then you need to help it along. This is a bit outdated but should help
you fix that:
http://sourceforge.net/p/cygwin-ports/ed/ci/master/tree/ed.cygport
done.
cygmake CFLAGS=${CFLAGS}
was enough
Great, thanks. ed is yours now.
Belated gold star awarded: http://cygwin.com/goldstars/#MA
Re: [ITA] Git et al
I'm not sure what the process is for adopting somebody else's package; the Submitting a new package instructions don't seem to apply since it's not a new package, but I don't yet have upload rights to just go ahead and do it. Adam, you are now listed as maintainer in cygwin-pkg-maint, so go ahead and submit your ssh key email. I trust that you'll fix the remaining package wrinkle before actually pushing a package, but even though I had a slight issue in rebuilding the package, I haven't had any problems using the pre-built binaries. Belated gold star awarded: http://cygwin.com/goldstars/#AD
Re: cygwin-pkg-maint maintance [gold star]
On 2014-08-11 17:03, Marco Atzeri wrote: attached 2 files. The first is basically what should be the new cygwin-pkg-maint that cover all the active package in both 32bit and 64 bit. This was great, thank you. After rearranging the release areas, I was able to get a more reliable list of what is currently on the server, and made a few more tweaks. All packages are reported as lower case. That always annoyed be about this list, so I did change the list to use proper case. The second one is the list of packages reported in the current file that do not exist as package or source package. We don't need those, so they're all gone, as well as those packages which are now nothing more than upgrade helpers. Could you check the latest cygwin-pkg-maint and see if I missed anything? Andrew: could you polish a gold star for Marco for showing initiative wrt Cygwin infrastructure at this juncture? Awarded! http://cygwin.com/goldstars/#MA
Re: [ITA] p7zip
Thanks all for the feedback and help. Sorry for showing up at a bad time. Note: You should perhaps remove the keepdir that preserves the /usr/lib/p7zip/Codecs directory. This drops a zero-size .keep-p7zip file in there that elicits a warning from p7zip since it isn't a codec. On the other hand, no warnings if the directory is simply missing and I don't know of any package that tries to drop anything in there anyway. I made this suggested change, and think I got everything uploaded. https://cygwin.com/cgi-bin2/package-grep.cgi?grep=p7ziparch=x86_64 looks promising, anyway. Guessing the sdesc from setup.hint doesn't get indexed as often? Now I should write to cygwin-announce, yeah? And we can remove p7zip from https://cygwin.com/cygwin-64bit-missing. That wasn't so bad! I skimmed through the list of orphaned packages to see if there was anything else that I'm familiar with building from source, but nothing jumped out at me. People who adopt orphaned packages get a gold star. You can visit yours at http://cygwin.com/goldstars/#TK .
Re: [ITA] p7zip
Yes, there's ARCH, ARCH_i686, and ARCH_x86_64. See /usr/share/doc/cygport/manual.html. Thanks, that's a great resource. I'm used to long-form docs being online somewhere rather than already installed along with the package. I'm a bit unclear what needs to happen next, despite reading all of https://cygwin.com/setup.html several times. Do I need another GTG for the slightly-modified version I posted? Or do I just ask please upload for that set of files now? Ah, okay. No, unfortunately that page has fallen out of date with current practice. Sorry about that. Package maintainers now upload their own packages. The procedure is described at https://sourceware.org/cygwin-apps/package-upload.html. In your request for upload privileges, be sure to mention that you're adopting p7zip, so you get listed as maintainer for that and will be allowed to upload it. Andrew
Re: [ITA] p7zip
On the topic of cygport, is there a variable that indicates whether --32 or --64 was specified? Yes, there's ARCH, ARCH_i686, and ARCH_x86_64. See /usr/share/doc/cygport/manual.html.
Re: [ITA] p7zip
Hi, I noticed that all of Chuck Wilson's packages are now listed as orphaned. I'm particularly interested in getting one of them, p7zip, uploaded to the 64-bit distribution. I sent a few messages to the main list in March discussing what I needed to change in order to get the existing cygport to build in 64 bit Cygwin. I'm willing to adopt the package, if someone can guide me through the rest of the process. Let me know if I'm doing this right. Package files are uploaded here: https://ci.appveyor.com/api/buildjobs/1cxy8w15aq971cyr/artifacts/p7zip-9.20.1-1.x86_64/dist/p7zip/p7zip-9.20.1-1.tar.xz https://ci.appveyor.com/api/buildjobs/1cxy8w15aq971cyr/artifacts/p7zip-9.20.1-1.x86_64/dist/p7zip/p7zip-9.20.1-1-src.tar.xz https://ci.appveyor.com/api/buildjobs/1cxy8w15aq971cyr/artifacts/p7zip-9.20.1-1.x86_64/dist/p7zip/setup.hint Packaging is GTG.
cygport upload command?
Using cygport, I think that packaging has become quite easy now. At least, once the cygport script is built and working, updating a package to a new release is as easy as updating the version number in the cygport script, then running 'cygport ... download all'. Except for one thing: the upload step. Maintainers still have to go through the procedure at https://sourceware.org/cygwin-apps/package-upload.html. Although it's easier than the old manual upload process, it's still a little tedious and error-prone. Yaakov, would you consider adding an 'upload' command to cygport, that would handle the uploading details? That would take away the last bit of manual work in a routine package update. If you don't have the time or interest to add an upload command yourself, would you consider a patch? I've spent some time looking through cygport code, and I might have time to give it a try, or maybe someone else would. Andrew
Re: [ITA] xloadimage
On Jun 24 22:49, David Stacey wrote: xloadimage is an X11 image viewer and processor. The Cygwin package was orphaned by Jari earlier this month [1]. Thanks for taking over. Looks good, please upload. Thanks, Corinna Gold star awarded: http://cygwin.com/goldstars/#DSt
Re: ITA: rsync -- fast, versatile file synchronizing tool
Adopting rsync (orpahaned, Lapo Luchini): https://cygwin.com/cygwin-pkg-maint I have new 3.1.0 ready for both x86 and x86_64. Let me know when I can upload. Jari Gold star awarded: http://cygwin.com/goldstars/#JAa
Re: ITA: tnef -- Tool to unpack MIME application/ms-tnef attachments
On Jun 15 12:57, Jari Aalto wrote: Adopting tnef (orpahaned, Jonathan C. Allen): https://cygwin.com/cygwin-pkg-maint I have new 1.4.9 ready for both x86 and x86_64. Let me know when I can upload. Please go ahead with this one and rsync. Thanks a lot for taking over! Gold star awarded: http://cygwin.com/goldstars/#JAa
Re: [ITA] run-1.3.1-1
On 2014-06-09 13:11, Achim Gratz wrote: Since Chuck went AWOL (it's really distressing that nobody heard anything from him since February) I've packaged a corrected version of run with cygport. I won't be able to do much in the way of further development for run. So if anybody else wants to pick it up now or later that's fine with me, too. For the sake of uploading, I have listed you as the maintainer in cygwin-pkg-maint. If someone else steps up with further development, we can change that then. Gold star awarded: http://cygwin.com/goldstars/#AG
[ITP] sng
I'd like to maintain sng for Cygwin. sng is a markup language and compiler/decompiler for PNG images. sng is in Debian (https://packages.debian.org/wheezy/sng). It also used to be in Cygwin, until it was obsoleted last year because it depended on libpng12. Thanks to Yaakov for pointing me to the patches from Gentoo that update it to libpng15. With that help sng now builts and runs fine again in Cygwin, x86 and x86_64. Andrew category: Graphics requires: libpng15 rgb sdesc: Markup language and compiler/decompiler for PNG ldesc: SNG (Scriptable Network Graphics) is a minilanguage designed specifically to represent the entire contents of a PNG (Portable Network Graphics) file in an editable form. Thus, SNGs representing elaborate graphics images and ancillary chunk data can be readily generated or modified using only text tools. SNG is implemented by a compiler/decompiler called sng that losslessly translates between SNG and PNG.
Re: [ITP] sng
On May 20 04:40, Andrew Schulman wrote: I'd like to maintain sng for Cygwin. sng is a markup language and compiler/decompiler for PNG images. sng is in Debian (https://packages.debian.org/wheezy/sng). It also used to be in Cygwin, until it was obsoleted last year because it depended on libpng12. Thanks to Yaakov for pointing me to the patches from Gentoo that update it to libpng15. With that help sng now builts and runs fine again in Cygwin, x86 and x86_64. This is your package anyway, so just go ahead. Oops. So it is - I didn't see that.
Re: revise Package Contributor's Guide?
On 13/05/2014 20:32, Andrew Schulman wrote: Attached is a patch which moves the old method one and two to an archive page, and continues the boffo packaging example into the section for the cygport method. Other stuff left to do: - Change to link to the new upload process page - Correct paths on the package server from release/ to arch/release - Change the examples to use .xz compression Jon, I think this is a good start. I suggest that you go ahead and move this out, so we can continue improving the page from there. Andrew Thanks. I think I applied this a few days ago. OK, I see now that you did. I think it's much better than before. BTW, if you want to write patches for the cygwin website (hint hint), I think the runes to check out a local copy of it are: cvs -d :pserver:anoncvs-9JcytcrH/ba+ujob2ku...@public.gmane.org:/cvs/cygwin co htdocs Sure. I think it will be easier to make improvements now from a more up-to-date guide. I'll send patches here for you to apply. Andrew
[ITA] pinfo
I'd like to adopt the pinfo package, since I use it. I have a new build of the latest version, 0.6.10, ready for x86 and x86_64, with a new cygport build script. I'm not sure if there's anything else I need to do. If there's no objection, I think I can just add pinfo to my !packages file in the upload directory, and I'm the new maintainer? Andrew
Re: revise Package Contributor's Guide?
Attached is a patch which moves the old method one and two to an archive page, and continues the boffo packaging example into the section for the cygport method. Other stuff left to do: - Change to link to the new upload process page - Correct paths on the package server from release/ to arch/release - Change the examples to use .xz compression Jon, I think this is a good start. I suggest that you go ahead and move this out, so we can continue improving the page from there. Andrew
Re: [ITA] pinfo
On Tue, May 13, 2014 at 03:03:19PM -0400, Andrew Schulman wrote: I'd like to adopt the pinfo package, since I use it. I have a new build of the latest version, 0.6.10, ready for x86 and x86_64, with a new cygport build script. I'm not sure if there's anything else I need to do. If there's no objection, I think I can just add pinfo to my !packages file in the upload directory, and I'm the new maintainer? Nope. https://sourceware.org/cygwin-apps/package-upload.html#FAQ cygwin-pkg-maint is the master file. OK. Then I request to be made maintainer of pinfo in that file.
cygport creates .gz packages, not .xz
I'm running cygport 0.15.0-1 in x86_64. I thought cygport was always
supposed to create .xz packages now, but for some reason for me it's
creating .gz packages.
I have the xz package installed, and /usr/bin/xz works. My cygport file
is below. What am I missing?
Thanks, Andrew.
NAME=socat
VERSION=1.7.2.4
RELEASE=1
CATEGORY=Net
SUMMARY=Bidirectional data transfer relay
DESCRIPTION=socat is a relay for bidirectional data transfer between
two
independent data channels. Each channel may be a file, pipe, device
(serial line etc. or a pseudo terminal), a socket (UNIX, IP4, IP6 -
raw, UDP, TCP), an SSL socket, proxy CONNECT connection, a file
descriptor (stdin etc.), the GNU line editor (readline), a program,
or a combination of two of these. These modes include generation of
'listening' sockets, named pipes, and pseudo terminals.
HOMEPAGE=http://www.dest-unreach.org/socat/;
SRC_URI=http://www.dest-unreach.org/socat/download/socat-${VERSION}.tar.gz;
PATCH_URI=
1.7_struct_pktinfo.patch
src_compile ()
{
cd ${B}
cygconf
cygmake
}
src_install ()
{
dodir /usr/share/doc/${PN}
cd ${B}
cyginstall
cd ${D}
dosym ../Cygwin/${PN}.README /usr/share/doc/${PN}/README.Cygwin
}
Re: cygport creates .gz packages, not .xz
I'm running cygport 0.15.0-1 in x86_64. I thought cygport was always supposed to create .xz packages now, but for some reason for me it's creating .gz packages. Sorry - not true. Please disregard. Andrew
setup wants to install new packages
I reported this problem a few months ago. Now I have a screenshot to show it: http://postimg.org/image/e5uzokbn9/ My last setup run was about a week ago. I just started setup-x86_64.exe, and OOTB it wants to install 9 new packages. I didn't select them, and they're not required - setup just selected them for me. Does anyone know why? Anyone else ever see this? BTW this is a transient problem: when I exit setup and restart, the new packages aren't selected again. Andrew
