[ITA] cmake 3.12.0

[ITA] cmake 3.12.0

[Ivan Shynkarenka]

I'd like to update cmake package. I prepared the latest cmake 3.12.0
package for x86/x86_64:

https://chronoxor.com/cygwin/x86/cmake/cmake-3.12.0-1.hinthttps://chronoxor.com/cygwin/x86/cmake/cmake-3.12.0-1.tar.xzhttps://chronoxor.com/cygwin/x86/cmake/cmake-3.12.0-1-src.tar.xz
https://chronoxor.com/cygwin/x86_64/cmake/cmake-3.12.0-1.hinthttps://chronoxor.com/cygwin/x86_64/cmake/cmake-3.12.0-1.tar.xzhttps://chronoxor.com/cygwin/x86_64/cmake/cmake-3.12.0-1-src.tar.xz

Otherwise I'd like to contact with current cmake maintainers, but I cannot
find their email anywhere.

Re: [ITA] cmake 3.12.0

[Ivan Shynkarenka]

Package links are corrected:

https://chronoxor.com/cygwin/x86/cmake/cmake-3.12.0-1.hint

https://chronoxor.com/cygwin/x86/cmake/cmake-3.12.0-1.tar.xz

https://chronoxor.com/cygwin/x86/cmake/cmake-3.12.0-1-src.tar.xz

https://chronoxor.com/cygwin/x86_64/cmake/cmake-3.12.0-1.hint

https://chronoxor.com/cygwin/x86_64/cmake/cmake-3.12.0-1.tar.xz

https://chronoxor.com/cygwin/x86_64/cmake/cmake-3.12.0-1-src.tar.xz


On Tue, Jul 24, 2018 at 5:15 PM, Ivan Shynkarenka <chronoxor@gmail.com>
wrote:

> I'd like to update cmake package. I prepared the latest cmake 3.12.0 package for x86/x86_64:
>
> https://chronoxor.com/cygwin/x86/cmake/cmake-3.12.0-1.hinthttps://chronoxor.com/cygwin/x86/cmake/cmake-3.12.0-1.tar.xzhttps://chronoxor.com/cygwin/x86/cmake/cmake-3.12.0-1-src.tar.xz
> https://chronoxor.com/cygwin/x86_64/cmake/cmake-3.12.0-1.hinthttps://chronoxor.com/cygwin/x86_64/cmake/cmake-3.12.0-1.tar.xzhttps://chronoxor.com/cygwin/x86_64/cmake/cmake-3.12.0-1-src.tar.xz
>
> Otherwise I'd like to contact with current cmake maintainers, but I cannot
> find their email anywhere.
>
>

Re: [ITA] cmake 3.12.0

[Marco Atzeri]

Am 24.07.2018 um 16:18 schrieb Ivan Shynkarenka:
> Package links are corrected:
>
...
>
>
> On Tue, Jul 24, 2018 at 5:15 PM, Ivan Shynkarenka
> wrote:
>
>> I'd like to update cmake package. I prepared the latest cmake 3.12.0 package for x86/x86_64:
>>

>> Otherwise I'd like to contact with current cmake maintainers, but I cannot
>> find their email anywhere.

The last announcement is a good hint:
https://sourceware.org/ml/cygwin-announce/2016-09/msg00036.html

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

[Takashi Yano]

On Tue, 24 Jul 2018 17:15:56 +0300
Ivan Shynkarenka wrote:
> Otherwise I'd like to contact with current cmake maintainers, but I cannot
> find their email anywhere.

You can find the current maintainer's name on this page:
https://cygwin.com/cygwin-pkg-maint

You can find the mail address of the maintainer of cmake in these messages:
https://cygwin.com/ml/cygwin-apps/2014-09/msg00029.html
https://cygwin.com/ml/cygwin-announce/2016-09/msg00036.html

However, I think it is better to discuss with him on this mailing list.

-- 
Takashi Yano <takashi.yano@nifty.ne.jp>

Re: [ITA] cmake 3.12.0

[Achim Gratz]

Ivan Shynkarenka writes:
> Otherwise I'd like to contact with current cmake maintainers, but I
> cannot find their email anywhere.

That communication should happen right here.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [ITA] cmake 3.12.0

[cyg Simple]

On 7/24/2018 3:01 PM, Achim Gratz wrote:
> Ivan Shynkarenka writes:
>> Otherwise I'd like to contact with current cmake maintainers, but I
>> cannot find their email anywhere.
> 
> That communication should happen right here.
> 

Egads, Ivan wants to help and you give him a run around without doing a
little research.  Okay, yes there are maintainers listed.  William
Hoffman's last post on cmake was in 2005, probably the first release.
Tony Kelman's last post was in March of this year but for the cmake
release it was in 2015.  Looking at kelman dot net, I don't know if Tony
receives messages or not but I've added him in Cc to this thread to
determine if it is still viable.  I'll let you know, otherwise Tony,
please respond.

Note to find Tony's email address I search the mail archive[1] for
`kelman "cmake"' to determine the last response. The archive has the
email address in munged format.

[1] https://cygwin.com/ml/cygwin/

-- 
cyg Simple

Re: [ITA] cmake 3.12.0

[Achim Gratz]

cyg Simple writes:
> Egads, Ivan wants to help and you give him a run around without doing a
> little research.

No, all I'm saying that there's a protocol for that.  The maintainer is
supposed to monitor this list, if he doesn't, the package might be up
for grabs after a final ping from the project leads.  There is no need
for anybody else to look for mail addresses that may or may not be
actively monitored.  The general rule is to not mail package maintainers
directly and IMHO that's the right idea.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf Blofeld V1.15B11:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

Re: [ITA] cmake 3.12.0

[Ivan Shynkarenka]

 > There is no need for anybody else to look for mail addresses that may or
may not be actively monitored.
> The general rule is to not mail package maintainers directly and IMHO
that's the right idea.

Thanks a lot for the information! I'm new in Cygwin contribution world, but
I want to help.
So lets wait a little bit, maybe some one of cmake maintainers will help to
update the package.

On Tue, Jul 24, 2018 at 11:49 PM, Achim Gratz <Stromeko@nexgo.de> wrote:

> cyg Simple writes:
> > Egads, Ivan wants to help and you give him a run around without doing a
> > little research.
>
> No, all I'm saying that there's a protocol for that.  The maintainer is
> supposed to monitor this list, if he doesn't, the package might be up
> for grabs after a final ping from the project leads.  There is no need
> for anybody else to look for mail addresses that may or may not be
> actively monitored.  The general rule is to not mail package maintainers
> directly and IMHO that's the right idea.
>
>
> Regards,
> Achim.
> --
> +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
>
> SD adaptation for Waldorf Blofeld V1.15B11:
> http://Synth.Stromeko.net/Downloads.html#WaldorfSDada
>

Re: [ITA] cmake 3.12.0

[Marco Atzeri]

Am 24.07.2018 um 22:49 schrieb Achim Gratz:
> cyg Simple writes:
>> Egads, Ivan wants to help and you give him a run around without doing a
>> little research.
>
> No, all I'm saying that there's a protocol for that.  The maintainer is
> supposed to monitor this list, if he doesn't, the package might be up
> for grabs after a final ping from the project leads.  There is no need
> for anybody else to look for mail addresses that may or may not be
> actively monitored.  The general rule is to not mail package maintainers
> directly and IMHO that's the right idea.

There are always exception to the rule.
There were several requests to update cmake and he never replied.
Tony is not currently actively maintaing the package,
and it is also not very active on the cygwin mailing list.

If Ivan try to contact him and see if he can help on next
release I see no harm.

Corinna,
If you have another mail address of Tony can you check his
status ?

> Regards,
> Achim.

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

[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.

I haven't been maintaining cmake very well, I've seen and noted all the
requests for updates but haven't had time to refresh the package. Ivan's
request is the first one that sounds more like "how can I help do this"
rather than "please do this for me, why haven't you done this."

I agree with the "general rule [...] to not mail package maintainers
directly" but the plain-text requirements of the list and the limited
functionality of gmane nowadays at least made it simpler to respond to
a direct email that Ivan already sent me. To reiterate, and expand, my
response publicly now that I have regular access to a device from which
I can send plain-text emails:

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.

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.

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.

-Tony

Re: [ITA] cmake 3.12.0

[Marco Atzeri]

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

Re: [ITA] cmake 3.12.0

[Marco Atzeri]

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(), &req, 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*) &peer_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

[Ivan Shynkarenka]

 > 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

[Tony Kelman]

> 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] cmake 3.12.0

[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.
-- 
+<[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] cmake 3.12.0

[Marco Atzeri]

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