Re: [ITA] cmake 3.12.0
Am 26.07.2018 um 20:41 schrieb Achim Gratz: Marco Atzeri writes: I am trying to build and pack libuv. If I find no problem I will ITP it. It might be worth to wait for Cygwin 2.11 for this particular lib. Regards, Achim. Noted Marco --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus
Re: [ITA] cmake 3.12.0
> do you need a static lib ? > I saw some distri are packaging it. Presumably the static lib should go in a -devel package? I wouldn't want to link cmake to the static lib though, that would defeat the purpose of de-vendoring it and using separately packaged dependencies. > builds successfully out of box for Cygwin with default build > script provided by Kitware. The default build script uses vendored dependencies which is understandable for Kitware's own reproducibility and testing burden, but generally not the way distros prefer to build cmake. Better to follow the example of the way the existing package is built, but updating the patches and accounting for new dependencies.
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: [ITA] cmake 3.12.0
Marco Atzeri writes: > I am trying to build and pack libuv. > If I find no problem I will ITP it. It might be worth to wait for Cygwin 2.11 for this particular lib. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf rackAttack: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [ITA/ITP] python-paramiko 2.4.1, python-bcrypt 3.1.4, python-PyNaCl 1.2.1
On Wed, Jul 25, 2018 at 9:52 PM Yaakov Selkowitz
wrote:
> On Tue, 2018-07-24 at 10:17 +0200, Michael Wild wrote:
> > Another question: if you look at the cygport file
> >
> https://github.com/themiwi/cygwin/blob/master/python-paramiko/python-paramiko.cygport
> ,
> > I jump through some hoops to get
> > /usr/share/doc/Cygwin/python{2,3}-paramiko.README generated from a single
> > patch and installed. Am I missing something? Particularly, the
> python-wheel
> > cygclass does not seem to include files in /usr/share/doc/Cygwin.
>
> TBH those "Cygwin READMEs" are not required and I generally do not
> include them in any of my packages. Therefore, cygport isn't
> completely automated when it comes to those.
>
Ah, what a relief. I was starting to worry that I have to include them in
my other packages too :-)
Pushed the simplifications and uploaded the packages to Dropbox for final
review and waiting for GTG.
Michael
Re: How to package a Python script
Ok, thanks! That clears things up for me.
On Wed, Jul 25, 2018 at 7:59 PM Yaakov Selkowitz
wrote:
> On Wed, 2018-07-25 at 16:55 +0200, Michael Wild wrote:
> > How should I go about packaging a Python executable? Separate packages
> > for python2 and python3? Only one of them? If so, which? If for both,
> > is there any advice how to achieve this? I don't think that the
> > python-wheel.cygclass deals with scripts in /usr/bin/ as the docs say
> > that scripts should be added to PKG_CONTENTS by the maintainer. How
> > would I go about making sure that I get a *2 and *3 version, also
> > possibly with a symlink from * to *2? Is there a cannonical example I
> > can look into? My casual trawling through my own Cygwin installation
> > didn't turn up anything useful...
>
> Depends on the package. Most python-based scripts also include
> modules, and sometimes those modules are generally usable and the
> script is just a convenient entrypoint thereto (in which case it should
> be named 'python-foo', *2 and *3 should be made via python-
> wheel.cygclass, and the script packaged with *3), and sometimes they
> serve only themselves (in which case it should be named 'foo' and
> packaged with the appropriate choice of python{2,3}-
> {distutils,wheel}.cygclass).
>
> --
> Yaakov Selkowitz
> Software Engineer - Platform Enablement Group
> Red Hat, Inc.
>
>
>
Re: [ITA] cmake 3.12.0
> One of the main reasons I haven't put in the effort to update the cmake > package is that recent versions of cmake have new dependencies which it > vendors by default, which is not the way distros such as cygwin prefer to > build things. For a cygwin packaging build of cmake (as with other tools), > the "right way" is presumably to use system versions of all library > dependencies. Cmake 3.12.0 builds successfully out of box for Cygwin with default build script provided by Kitware. So I think its a good chance to build and update the package. Moreover I tested it in lots of our C++ projects that must be build under Cygwin via Appveyor CI. For this reason I add pre-build step with building the latest cmake: - if "%type%"=="Cygwin" appveyor-retry appveyor DownloadFile " https://cmake.org/files/v3.12/cmake-3.12.0.tar.gz; -FileName "cmake.tar.gz" - if "%type%"=="Cygwin" C:\cygwin64\bin\bash -lc "cd $APPVEYOR_BUILD_FOLDER; mkdir temp; cd temp; mv ../cmake.tar.gz ./cmake.tar.gz; tar xzf cmake.tar.gz --strip-components=1; ./bootstrap && make && make install; cd ..; rm -rf ./temp" Of course the best solution for us is to have cmake 3.12.0 updated in Cygwin repository, because its building time is about ~30min
Re: [ITA] cmake 3.12.0
Am 26.07.2018 um 08:00 schrieb Marco Atzeri: In general is better to have a separate package for any dependency; it make much simpler to maintain all. I am trying to build and pack libuv. If I find no problem I will ITP it. Tony, do you need a static lib ? I saw some distri are packaging it. Building the shared lib I see several errors, and the log is not very clear on the root causes. not ok 25 - dlerror # exit code 134 # Output from process `dlerror`: # Assertion failed in /tmp/prova/libuv-1.22.0-1.i686/src/libuv-1.22.0/test/test-dlerror.c on line 45: strstr(msg, path) != NULL not ok 45 - fs_copyfile # exit code 134 # Output from process `fs_copyfile`: # Assertion failed in /tmp/prova/libuv-1.22.0-1.i686/src/libuv-1.22.0/test/test-fs-copyfile.c on line 124: r == 0 not ok 84 - fs_scandir_file # exit code 134 # Output from process `fs_scandir_file`: # Assertion failed in /tmp/prova/libuv-1.22.0-1.i686/src/libuv-1.22.0/test/test-fs.c on line 2477: r == UV_ENOTDIR not ok 102 - getaddrinfo_fail # exit code 134 # Output from process `getaddrinfo_fail`: # Assertion failed in /tmp/prova/libuv-1.22.0-1.i686/src/libuv-1.22.0/test/test-getaddrinfo.c on line 43: status < 0 not ok 103 - getaddrinfo_fail_sync # exit code 134 # Output from process `getaddrinfo_fail_sync`: # Assertion failed in /tmp/prova/libuv-1.22.0-1.i686/src/libuv-1.22.0/test/test-getaddrinfo.c on line 117: 0 > uv_getaddrinfo(uv_default_loop(), , NULL, "xyzzy.xyzzy.xyzzy.", NULL, NULL) not ok 148 - pipe_connect_to_file # exit code 134 # Output from process `pipe_connect_to_file`: # Assertion failed in /tmp/prova/libuv-1.22.0-1.i686/src/libuv-1.22.0/test/test-pipe-connect-error.c on line 53: status == UV_ENOTSOCK || status == UV_ECONNREFUSED not ok 169 - poll_oob # exit code 134 # Output from process `poll_oob`: # Assertion failed in /tmp/prova/libuv-1.22.0-1.i686/src/libuv-1.22.0/test/test-poll-oob.c on line 99: n == 4 not ok 203 - spawn_reads_child_path # exit code 134 # Output from process `spawn_reads_child_path`: # Assertion failed in /tmp/prova/libuv-1.22.0-1.i686/src/libuv-1.22.0/test/test-spawn.c on line 1679: r == 0 not ok 234 - tcp_close_accept # exit code 134 # Output from process `tcp_close_accept`: # Assertion failed in /tmp/prova/libuv-1.22.0-1.i686/src/libuv-1.22.0/test/test-tcp-close-accept.c on line 60: status != 0 not ok 260 - tcp_unexpected_read # exit code 134 # Output from process `tcp_unexpected_read`: # Assertion failed in /tmp/prova/libuv-1.22.0-1.i686/src/libuv-1.22.0/test/test-tcp-unexpected-read.c on line 80: 0 == uv_accept(handle, (uv_stream_t*) _handle) not ok 261 - tcp_write_after_connect # exit code 134 # Output from process `tcp_write_after_connect`: # Assertion failed in /tmp/prova/libuv-1.22.0-1.i686/src/libuv-1.22.0/test/test-tcp-write-after-connect.c on line 41: status == UV_ECONNREFUSED full package on http://matzeri.altervista.org/ to download (and remove the index.html's) : wget -r -np -nH --cut-dirs=0 \ http://matzeri.altervista.org/x86/libuv/index.html wget -r -np -nH --cut-dirs=0 \ http://matzeri.altervista.org/x86_64/libuv/index.html find x86 x86_64 -name index.html -o -name md5.sum | xargs rm Regards Marco --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus
Re: [ITA] cmake 3.12.0
Am 26.07.2018 um 02:50 schrieb Tony Kelman: No, all I'm saying that there's a protocol for that. The maintainer is supposed to monitor this list I do read the mailing list, but don't write to it very often - composing a plain-text email is overly complicated with the mobile email clients I use most of the time, and I was traveling this past week. Noted, thanks for the feedback. One of the main reasons I haven't put in the effort to update the cmake package is that recent versions of cmake have new dependencies which it vendors by default, which is not the way distros such as cygwin prefer to build things. For a cygwin packaging build of cmake (as with other tools), the "right way" is presumably to use system versions of all library dependencies. This would require an ITP on at least libuv, and any other new dependencies of cmake that the latest version has but 3.6 didn't. This might include rhash and json-cpp (looking at how msys2 has updated their packaging of cmake over time), but I'm not positive. In general is better to have a separate package for any dependency; it make much simpler to maintain all. I am trying to build and pack libuv. If I find no problem I will ITP it. If Ivan is willing to package and maintain libuv and any other new cmake dependencies so they can be de-vendored, I'm fine with him adopting cmake. For his own sake, I'd recommend doing a better job than I did of tracking down any test failures and pursuing upstreaming the cygwin patches. Many of those originate from Yaakov, and there is some past discussion on the list about a few of them. Those patches are kind of a pain to rebase with each new version, so working to upstream them will save time over the long run. Can you manage a co-maintainership and guide him on the effort ? I haven't reviewed what Ivan has changed in the packaging, patches, etc. So heavy cygwin users of cmake, particularly packagers of other cmake-built programs and libraries, should carefully test out the new builds. Noted. -Tony Regards Marco --- Diese E-Mail wurde von Avast Antivirus-Software auf Viren geprüft. https://www.avast.com/antivirus
