Re: [ITA] cmake-3.18.0-1 and related packages
Subject: Re: [ITA] cmake-3.18.0-1 and related packages Date: Sat, 18 Jul 2020 09:01:20 +0200 From: Achim Gratz > Marco Atzeri via Cygwin-apps writes: > > I know, but it take times, specially as I will hate to lose > > the history if I port only last version > > You can rewrite the git repo with filter-branch to keep the history. I > did that with my packages since I also had them in a single repo. I now > have them as submodules in a new repo, although the submodules wouldn't > strictly be necessary. > All right. I've made a new history branch here by extracting with git filter-branch and merge: https://github.com/cygwin-lem/cygwin-pkg/tree/new_master_cmake And attached a result of 'git log --pretty=fuller --graph --color=always' as an HTML file. Please review it. If it is OK, I'll push to the repo https://cygwin.com/git-cygwin-packages/cmake.git . Regards, Lem
Re: [ITA] cmake-3.18.0-1 and related packages
Achim Gratz writes:
> Marco Atzeri via Cygwin-apps writes:
>> I know, but it take times, specially as I will hate to lose
>> the history if I port only last version
>
> You can rewrite the git repo with filter-branch to keep the history. I
> did that with my packages since I also had them in a single repo. I now
> have them as submodules in a new repo, although the submodules wouldn't
> strictly be necessary.
Here are a the scripts that I created for this conversion. The first
one filters each subdirectory into its own branch. The second one
imports one such branch into a new repo. You need to define a cygpack:
alias in your gitconfig (global or local) to use it directly. Obviously
you'll want to loop across all your packages, I did that directly in the
shell. It goes without saying that you should do all operations on
fresh clones of your repositories so you can easily start over if
necessary.
The third script was for packages that I took over from Yaakov that he
had put earlier history on the Cygwin server (from Cygport, mostly) and
I had already local history fro my releases; it will fetch what's on
Cygwin and then append any local history. If the relation is more
complicated than that you will either need to rewrite the history
manually or drop / branch off some of the intertwined history.
--8<- .gitconfig -cut herestart->8---
[url "git://cygwin.com/git/cygwin-packages"]
InsteadOf = cygpack:
[url "ssh://cyg...@cygwin.com/git/cygwin-packages"]
pushInsteadOf = cygpack:
--8<- .gitconfig -cut hereend--->8---
--8<- splitgit.dash -cut here--start->8---
#!/bin/dash
pkgs=""
spkg=""
if [ $# -gt 2 ] ; then
orepo=$1; shift
nrepo=$1; shift
pkgs=$1; shift
spkg=$pkgs
else
echo "Not enough arguments!\n$@"
exit 1
fi
while [ $# -gt 0 ] ; do
pkgs="$pkgs $1"
spkg="$spkg|$1"
shift
done
echo "$spkg"
# clone repo and keep reference to original
git clone $orepo $nrepo
cd $nrepo
git branch unsplit master
# stuff packages into separate subdirectories
git filter-branch --index-filter ' \
git ls-files -s | \
perl -pE '"'"'s:\t('$spkg'):\t$1/$1:'"'"' | \
env GIT_INDEX_FILE=$GIT_INDEX_FILE.new git update-index --index-info && \
mv "$GIT_INDEX_FILE.new" "$GIT_INDEX_FILE" \
' HEAD
git branch subdirs
# split each subdir into a new branch
for pkg in $pkgs ; do
git filter-branch -f --subdirectory-filter $pkg -- --all
git branch $pkg
git reset --hard original/refs/heads/master
done
--8<- splitgit.dash -cut here-end--->8---
--8<- gitimport.dash -cut herestart->8---
#!/usr/bin/dash
if [ $# -gt 1 ] ; then
srepo=$(realpath $1); shift
pkg=$1; shift
else
echo "Not enough arguments!\n$@"
exit 1
fi
echo "$pkg"
# create new git repo
git init $pkg
cd $pkg
# import history
git fetch -fu $srepo master:master
git reset --hard
git remote add origin cygpack:/$pkg
#
cd ..
--8<- gitimport.dash -cut hereend--->8---
--8<- grafthist.dash -cut herestart->8---
#!/bin/dash
if [ $# -gt 1 ] ; then
srepo=$(realpath $1); shift
pkg=$1; shift
else
echo "Not enough arguments!\n$@"
exit 1
fi
echo "$pkg"
# create new git repo
git clone git://cygwin.com/git/cygwin-packages/${pkg}.git || git init $pkg
cd $pkg
# import history
git fetch $srepo refs/heads/${pkg}:import
git checkout import
if [ "origin" = "$( git remote )" ] ; then
# append imported history
sha1=$( git show-ref refs/heads/master | cut -d\ -f 1 )
echo $sha1
git filter-branch -f \
--commit-filter ' \
if [ $# -eq 1 ] ; then \
git commit-tree -p $( git show-ref refs/heads/master | cut -d" " -f
1 ) $1 ; \
else \
git commit-tree "$@" ; \
fi ' \
--msg-filter ' \
sed -e "s/initial commit/Take over maintenance/;s/^\* //" \
' \
HEAD
fi
git branch -f master import
git reset --hard
cd ..
--8<- grafthist.dash -cut hereend--->8---
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Samples for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldSamplesExtra
Re: [ITA] cmake-3.18.0-1 and related packages
Marco Atzeri via Cygwin-apps writes: > I know, but it take times, specially as I will hate to lose > the history if I port only last version You can rewrite the git repo with filter-branch to keep the history. I did that with my packages since I also had them in a single repo. I now have them as submodules in a new repo, although the submodules wouldn't strictly be necessary. 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.18.0-1 and related packages
On 18.07.2020 08:12, Achim Gratz wrote: Marco Atzeri via Cygwin-apps writes: New cygport and patch files are placed to https://github.com/cygwin-lem/cmake-cygport/tree/n_3.18.0-1d (I can't find any git repository for cmake.cygport). all mine are together at https://github.com/matzeri/cygwin-pkg You should put them on https://cygwin.com/git-cygwin-packages/ preferrably as the canonical source. I know, but it take times, specially as I will hate to lose the history if I port only last version Regards, Achim. Regards Marco
Re: [ITA] cmake-3.18.0-1 and related packages
Marco Atzeri via Cygwin-apps writes: >> New cygport and patch files are placed >> to https://github.com/cygwin-lem/cmake-cygport/tree/n_3.18.0-1d >> (I can't find any git repository for cmake.cygport). > > all mine are together at > > https://github.com/matzeri/cygwin-pkg You should put them on https://cygwin.com/git-cygwin-packages/ preferrably as the canonical source. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Q+, Q and microQ: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds
Re: [ITA] cmake-3.18.0-1 and related packages
Subject: Re: [ITA] cmake-3.18.0-1 and related packages Date: Fri, 17 Jul 2020 23:13:55 +0200 From: Marco Atzeri via Cygwin-apps > On 17.07.2020 22:14, Lemures Lemniscati via Cygwin-apps wrote: > > Hi! > > > > I suggest an update to CMake v3.18.0 (Date: Wed Jul 15 07:19:20 2020 -0400). > > https://github.com/Kitware/CMake/tree/v3.18.0 > > > > I'm not at all familiar with CMake, which is a very large system. > > And, though I don't mind being an additional maintainer for cmake, > > I guess it's difficult for me to maintain cmake packages just by myself. > > cmake is a bit of pain, I can agree > > >> Current maintainers are: https://cygwin.com/cygwin-pkg-maint > >> cmakeTony Kelman/Marco Atzeri > > > technically as I am still here, cmake is not orphan > > > > New cygport and patch files are placed > > to https://github.com/cygwin-lem/cmake-cygport/tree/n_3.18.0-1d > > (I can't find any git repository for cmake.cygport). > > all mine are together at > > https://github.com/matzeri/cygwin-pkg Thank you, Marco. I would like to support as far as I can. Regards, Lem
Re: [ITA] cmake-3.18.0-1 and related packages
On 17.07.2020 22:14, Lemures Lemniscati via Cygwin-apps wrote: Hi! I suggest an update to CMake v3.18.0 (Date: Wed Jul 15 07:19:20 2020 -0400). https://github.com/Kitware/CMake/tree/v3.18.0 I'm not at all familiar with CMake, which is a very large system. And, though I don't mind being an additional maintainer for cmake, I guess it's difficult for me to maintain cmake packages just by myself. cmake is a bit of pain, I can agree Current maintainers are: https://cygwin.com/cygwin-pkg-maint cmakeTony Kelman/Marco Atzeri technically as I am still here, cmake is not orphan New cygport and patch files are placed to https://github.com/cygwin-lem/cmake-cygport/tree/n_3.18.0-1d (I can't find any git repository for cmake.cygport). all mine are together at https://github.com/matzeri/cygwin-pkg New test package files are placed here: https://app.box.com/s/8q5mpv4kv080jxsyc5tbongrerwfzbuz/folder/118159586901 I will give a view cmake-3.18.0-1 cmake-doc-3.18.0-1 cmake-gui-3.18.0-1 bash-completion-cmake-3.18.0-1 emacs-cmake-3.18.0-1 vim-cmake-3.18.0-1 There are new additional packages: bash-completion-cmake and vim-cmake-3.18.0-1. They contain new files in CMake v3.18.0 and not in earlier versions -- Lem I have cmake-3.17.3-1 build and already packed, but I am no really fine with testing any reason why you need 3.18.0 Regards Marco
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] 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] 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(), &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
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
> 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
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
> 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 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
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
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
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
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
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
Re: [ITA] cmake 3.12.0
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 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
On 29/09/2014 06:11, Tony Kelman wrote: check if the Help files are used by the main program or by the gui If yes fit them in the same package, if not leave in cmake-doc. Very good catch Marco, thanks. The Help files are indeed used by the main cmake CLI when you call --help-*, there is some runtime .rst processing. So I moved them into the main package. I also fixed the ftp test failure, already got a patch merged upstream. The other failure's more complicated and will take some time to fully resolve. Packaging source at https://github.com/tkelman/cygwin-cmake and results at https://dl.dropboxusercontent.com/u/8244638/cmake.i686.tar https://dl.dropboxusercontent.com/u/8244638/cmake.x86_64.tar updated. -Tony can you please adjust your mail program or use a better one ? All your replies are breaking the follow-up chain. https://cygwin.com/ml/cygwin-apps/2014-09/threads.html Regards Marco
Re: [ITA] cmake
check if the Help files are used by the main program or by the gui If yes fit them in the same package, if not leave in cmake-doc. Very good catch Marco, thanks. The Help files are indeed used by the main cmake CLI when you call --help-*, there is some runtime .rst processing. So I moved them into the main package. I also fixed the ftp test failure, already got a patch merged upstream. The other failure's more complicated and will take some time to fully resolve. Packaging source at https://github.com/tkelman/cygwin-cmake and results at https://dl.dropboxusercontent.com/u/8244638/cmake.i686.tar https://dl.dropboxusercontent.com/u/8244638/cmake.x86_64.tar updated. -Tony
Re: [ITA] cmake
On 28/09/2014 10:10, Tony Kelman wrote: Jinja2 and docutils are also packaged Those have similarly simple-looking cygport files in ports so guess I'll do those too. Current cmake has no cmake-doc so we can also skip HTML documentation cmake 3 uses sphinx to generate its man pages, not just the html docs. Not having a man page seems less okay. I agree About packaging does make senss to put /usr/share/cmake-3.0.2/Help under cmake-doc ? Should not fit in cmake ? Okay, I can put it in the main cmake package. It is the .rst sources used to generate the html docs, seemed like it would add space to the main package, but not too much. check if the Help files are used by the main program or by the gui If yes fit them in the same package, if not leave in cmake-doc. For me it is GTG, no objection to have a new maintainer as the current one is surely missing for too long time. Regards Marco
Re: [ITA] cmake
Jinja2 and docutils are also packaged Those have similarly simple-looking cygport files in ports so guess I'll do those too. Current cmake has no cmake-doc so we can also skip HTML documentation cmake 3 uses sphinx to generate its man pages, not just the html docs. Not having a man page seems less okay. About packaging does make senss to put /usr/share/cmake-3.0.2/Help under cmake-doc ? Should not fit in cmake ? Okay, I can put it in the main cmake package. It is the .rst sources used to generate the html docs, seemed like it would add space to the main package, but not too much.
Re: [ITA] cmake
On 28/09/2014 02:04, Tony Kelman wrote: It may be a better fit for someone else's knowledge and day-to-day usage though. Nevermind, I should've actually looked at http://sourceforge.net/p/cygwin-ports/python-sphinx/ci/master/tree/python-sphinx.cygport first. It's using distutils instead of pip, but it looks like cygport already does all the work. I'll have a go at ITP'ing the latest version of python-sphinx myself, if all it needs is a maintainer other than Yaakov. Doesn't address the pip vs distutils issue, but that can wait. -Tony [100%] sphinx-build html: see Utilities/Sphinx/build-html.log Traceback (most recent call last): File "/usr/bin/sphinx-build", line 5, in from pkg_resources import load_entry_point File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 2803, in working_set.require(__requires__) File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 696, in require needed = self.resolve(parse_requirements(requirements)) File "/usr/lib/python2.7/site-packages/pkg_resources.py", line 594, in resolve raise DistributionNotFound(req) pkg_resources.DistributionNotFound: Jinja2>=2.3 Utilities/Sphinx/CMakeFiles/documentation.dir/build.make:52: recipe for target 'Utilities/Sphinx/doc_format_html' failed after installing Jinja and docutils than cmake builds fine and the program itself looks fine. For me is GTG assuming Jinja2 and docutils are also packaged or documentation build is reduced to not use them. Current cmake has no cmake-doc so we can also skip HTML documentation About packaging does make senss to put /usr/share/cmake-3.0.2/Help under cmake-doc ? Should not fit in cmake ? Regards Marco
Re: [ITA] cmake
It may be a better fit for someone else's knowledge and day-to-day usage though. Nevermind, I should've actually looked at http://sourceforge.net/p/cygwin-ports/python-sphinx/ci/master/tree/python-sphinx.cygport first. It's using distutils instead of pip, but it looks like cygport already does all the work. I'll have a go at ITP'ing the latest version of python-sphinx myself, if all it needs is a maintainer other than Yaakov. Doesn't address the pip vs distutils issue, but that can wait. -Tony
Re: [ITA] cmake
SPHINX_EXECUTABLE (sphinx-build) is not found! Do we have sphinx on cygwin ? I think it is only on cygwinport Ah sorry, I should've mentioned that. I didn't find sphinx as a Cygwin package, no. I had to do `pip install sphinx`. Though now I'm trying to remember where I got pip from, since I don't see it packaged either. I must've just downloaded and run https://bootstrap.pypa.io/get-pip.py Looks like Yaakov maintains most of the Python packages and doesn't need to add any more to the hundreds of packages he maintains, but it would make sense IMO to have python-pip and python-sphinx packaged for Cygwin. If Python were my primary language and I knew the proper way to package Python tools for Cygwin I'd volunteer. It may be a better fit for someone else's knowledge and day-to-day usage though. -Tony
Re: [ITA] cmake
On 26/09/2014 04:34, Tony Kelman wrote: Feels a little odd to be proposing adopting cmake from its original author, but I guess he's a busy guy and has not been responsive to requests on cygwin lists to update the package. I found Yaakov had a recent cygport file and set of patches in ports, I started from there. I imported Yaakov's git history and you can see my changes at https://github.com/tkelman/cygwin-cmake Had to tweak a couple of patches and remove another to account for upstream changes. Also added a separate cmake-doc subpackage for the sphinx-generated html documentation. Results (multiple subpackages, put together into one tarball per arch): i686 https://dl.dropboxusercontent.com/u/8244638/cmake.i686.tar x86_64 https://dl.dropboxusercontent.com/u/8244638/cmake.x86_64.tar the build stop here -- Found Qt4: /usr/lib/qt4/bin/qmake (found suitable version "4.8.6", minimum required is "4.4.0") CMake Error at Utilities/Sphinx/CMakeLists.txt:39 (message): SPHINX_EXECUTABLE (sphinx-build) is not found! Do we have sphinx on cygwin ? I think it is only on cygwinport -Tony
