Re: how CI system works in MxNet?

[shiwen hu]

I think it was the last build of a residual file. Try make clean. first

2017-08-13 22:35 GMT+08:00 Nan Zhu :

> Hi, all
>
> I just noticed something which raises this question
>
> Yesterday afternoon, I checked
> https://github.com/apache/incubator-mxnet/commits/master and the first
> commit passed all tests
>
> However, when I checked again this morning, the test result was changed to
> fail...
>
> (one of my PRs also exposes this symptom)
>
> Would anyone please share the insights about which part of our CI system
> can produce this?
>
> Best,
>
> Nan
>

Re: [VOTE] Release MXNet version 0.11.0

[shiwen hu]

+1

2017-08-12 19:16 GMT+08:00 Chris Olivier :

> +1
>
> On Sat, Aug 12, 2017 at 2:28 AM Ly Nguyen  wrote:
>
> > This is the vote to release Apache MXNet (incubating) version 0.11.0.
> > Voting will start now (Saturday, August 12, 2017 9:26 AM UTC) and
> > close Tuesday, August 15, 2017 9:26 AM UTC.
> >
> > Link to release notes:
> > https://cwiki.apache.org/confluence/display/MXNET/v0.11.0+Release+Notes
> >
> > Link to release candidate 0.11.0.rc0:
> > https://dist.apache.org/repos/dist/dev/incubator/mxnet/0.11.0.rc0/
> >
> >
> >
> > Please test and vote accordingly:
> >
> > +1 = approve
> >
> > +0 = no opinion
> >
> > -1 = disapprove (provide reason)
> >
>

Re: how CI system works in MxNet?

[shiwen hu]

It may be that Sphinx cannot work incrementally

2017-08-13 23:05 GMT+08:00 shiwen hu <yajiedes...@gmail.com>:

> I think it was the last build of a residual file. Try make clean. first
>
> 2017-08-13 22:35 GMT+08:00 Nan Zhu <zhunanmcg...@gmail.com>:
>
>> Hi, all
>>
>> I just noticed something which raises this question
>>
>> Yesterday afternoon, I checked
>> https://github.com/apache/incubator-mxnet/commits/master and the first
>> commit passed all tests
>>
>> However, when I checked again this morning, the test result was changed to
>> fail...
>>
>> (one of my PRs also exposes this symptom)
>>
>> Would anyone please share the insights about which part of our CI system
>> can produce this?
>>
>> Best,
>>
>> Nan
>>
>
>

mxnet pip build.

[shiwen hu]

what the 2017-08-10 mxnet pip build git tags. and what use cudun version?
.i want build the windows version.

Re: MXNet: Run PR builds on Apache Jenkins only after the commit is reviewed

[shiwen hu]

In addition, the recent CI congestion probably because of the windows CI
failure.

2017-09-12 10:54 GMT+08:00 Tianqi Chen <tqc...@cs.washington.edu>:

> I agree that have the CI is useful, at least make sure that lint stage is
> done.
>
> Tianqi
>
> On Mon, Sep 11, 2017 at 7:49 PM, Hagay Lupesko <lupe...@gmail.com> wrote:
>
> > Build success or failure is a great feedback mechanism, of equal
> importance
> > to code review. Do we really want to delay it until another Dev gives a
> > thumbs up? It feels like a step backwards from automation.
> >
> > If our problem is resource constraint, can't we address it by throwing
> more
> > instances into the pool?
> >
> > On Sep 11, 2017 6:28 PM, "shiwen hu" <yajiedes...@gmail.com> wrote:
> >
> > > Jenkins can be set to automatically cancel old builds, but I'm not sure
> > if
> > > it's already been set
> > >
> > > 2017-09-12 9:19 GMT+08:00 Chris Olivier <cjolivie...@gmail.com>:
> > >
> > > > Is the load artificially high because there's such a backlog due to
> > other
> > > > reasons? Many may be triggering trivial changes to kick off another
> > build
> > > > attempt (I have).
> > > >
> > > > Do new PR changes actually stop the old build or do those go to
> > > completion?
> > > > I realize they show on the PR as a new build has started, but are the
> > old
> > > > builds/tests always interrupted?
> > > >
> > > >
> > > > On Mon, Sep 11, 2017 at 6:12 PM Naveen Swamy <mnnav...@gmail.com>
> > wrote:
> > > >
> > > > > +1
> > > > >
> > > > > Even a small change in the PR is initiating a new build, I think
> this
> > > is
> > > > > needless and not serving any good purpose until a reviewer has
> looked
> > > > into
> > > > > the PR. This is also adding unnecessary load on the mxnet build
> > > pipeline
> > > > > and slaves.
> > > > >
> > > > > Thanks, Naveen
> > > > >
> > > > >
> > > > > On Mon, Sep 11, 2017 at 5:50 PM, Meghna Baijal <
> > > > meghnabaijal2...@gmail.com
> > > > > >
> > > > > wrote:
> > > > >
> > > > > > Hi All,
> > > > > > We would like to initiate a change in the way the PR builds are
> > being
> > > > > > triggered. At the moment, every time a Pull Request is created, a
> > > build
> > > > > > gets triggered on Jenkins. Additional builds also get triggered
> due
> > > to
> > > > > > changes to the same PR.
> > > > > > Too many PR builds leads to resource starvation and very long
> > queues
> > > > and
> > > > > > long build times. Hence we would like to add some checks where a
> > > human
> > > > > > reviewer manually marks it to something like “ok to build”
> before a
> > > PR
> > > > > > build is triggered.
> > > > > >
> > > > > > Do you think this approach would be helpful and we should move
> > > forward
> > > > > > with it?
> > > > > >
> > > > > > Thanks,
> > > > > > Meghna Baijal
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > >
> >
>

Re: MXNet: Run PR builds on Apache Jenkins only after the commit is reviewed

[shiwen hu]

Jenkins can be set to automatically cancel old builds, but I'm not sure if
it's already been set

2017-09-12 9:19 GMT+08:00 Chris Olivier :

> Is the load artificially high because there's such a backlog due to other
> reasons? Many may be triggering trivial changes to kick off another build
> attempt (I have).
>
> Do new PR changes actually stop the old build or do those go to completion?
> I realize they show on the PR as a new build has started, but are the old
> builds/tests always interrupted?
>
>
> On Mon, Sep 11, 2017 at 6:12 PM Naveen Swamy  wrote:
>
> > +1
> >
> > Even a small change in the PR is initiating a new build, I think this is
> > needless and not serving any good purpose until a reviewer has looked
> into
> > the PR. This is also adding unnecessary load on the mxnet build pipeline
> > and slaves.
> >
> > Thanks, Naveen
> >
> >
> > On Mon, Sep 11, 2017 at 5:50 PM, Meghna Baijal <
> meghnabaijal2...@gmail.com
> > >
> > wrote:
> >
> > > Hi All,
> > > We would like to initiate a change in the way the PR builds are being
> > > triggered. At the moment, every time a Pull Request is created, a build
> > > gets triggered on Jenkins. Additional builds also get triggered due to
> > > changes to the same PR.
> > > Too many PR builds leads to resource starvation and very long queues
> and
> > > long build times. Hence we would like to add some checks where a human
> > > reviewer manually marks it to something like “ok to build” before a PR
> > > build is triggered.
> > >
> > > Do you think this approach would be helpful and we should move forward
> > > with it?
> > >
> > > Thanks,
> > > Meghna Baijal
> > >
> > >
> > >
> > >
> >
>

who know what version cmake in our windwos ci?

[shiwen hu]

Preparing for cuda9.0 and vs2017 and update the first-class CUDA with
cmake.but it must  version 3.9 cmake.who know what version cmake in our
windwos ci now?

Re: who know what version cmake in our windwos ci?

[shiwen hu]

set the minimum CMake requirements for MXNet users to 3.9 or minimum
required 3.8, but I haven't tested 3.8
because need to use this function
https://cmake.org/cmake/help/latest/release/3.8.html?highlight=cuda
and the old FindCUDA(our now use) not work in vs2017,

2017-10-06 3:02 GMT+08:00 kellen sunderland <kellen.sunderl...@gmail.com>:

> Just to clarify Shiwen, are you proposing to use CMake 3.9 on our CI, or to
> set the minimum CMake requirements for MXNet users to 3.9?
>
> To give us some more context could you provide a link to a document
> describing what the problem is, or give us the error that will result from
> using the wrong version?
>
> On Thu, Oct 5, 2017 at 5:59 PM, shiwen hu <yajiedes...@gmail.com> wrote:
>
> > the cmake  first-class CUDA  and vs2017 must 3.9
> > the old cmake CUDA can't work with vs2017.And cmake recommends using the
> > new approach.
> >
> > 2017-10-05 12:40 GMT+08:00 Chris Olivier <cjolivie...@gmail.com>:
> >
> > > What file requires cmake 3.9? Why? That’s a pretty steep requirement.
> > >
> > > On Wed, Oct 4, 2017 at 9:15 PM shiwen hu <yajiedes...@gmail.com>
> wrote:
> > >
> > > > Preparing for cuda9.0 and vs2017 and update the first-class CUDA with
> > > > cmake.but it must  version 3.9 cmake.who know what version cmake in
> our
> > > > windwos ci now?
> > > >
> > >
> >
>

Re: who know what version cmake in our windwos ci?

[shiwen hu]

Reference resources my cmake issue
https://gitlab.kitware.com/cmake/cmake/issues/17313

2017-10-06 9:25 GMT+08:00 shiwen hu <yajiedes...@gmail.com>:

> set the minimum CMake requirements for MXNet users to 3.9 or minimum
> required 3.8, but I haven't tested 3.8
> because need to use this function https://cmake.org/
> cmake/help/latest/release/3.8.html?highlight=cuda
> and the old FindCUDA(our now use) not work in vs2017,
>
> 2017-10-06 3:02 GMT+08:00 kellen sunderland <kellen.sunderl...@gmail.com>:
>
>> Just to clarify Shiwen, are you proposing to use CMake 3.9 on our CI, or
>> to
>> set the minimum CMake requirements for MXNet users to 3.9?
>>
>> To give us some more context could you provide a link to a document
>> describing what the problem is, or give us the error that will result from
>> using the wrong version?
>>
>> On Thu, Oct 5, 2017 at 5:59 PM, shiwen hu <yajiedes...@gmail.com> wrote:
>>
>> > the cmake  first-class CUDA  and vs2017 must 3.9
>> > the old cmake CUDA can't work with vs2017.And cmake recommends using the
>> > new approach.
>> >
>> > 2017-10-05 12:40 GMT+08:00 Chris Olivier <cjolivie...@gmail.com>:
>> >
>> > > What file requires cmake 3.9? Why? That’s a pretty steep requirement.
>> > >
>> > > On Wed, Oct 4, 2017 at 9:15 PM shiwen hu <yajiedes...@gmail.com>
>> wrote:
>> > >
>> > > > Preparing for cuda9.0 and vs2017 and update the first-class CUDA
>> with
>> > > > cmake.but it must  version 3.9 cmake.who know what version cmake in
>> our
>> > > > windwos ci now?
>> > > >
>> > >
>> >
>>
>
>

Re: ICLAs vs Contributors

[shiwen hu]

yes.nobody tell them.

2017-08-30 14:43 GMT+08:00 Henri Yandell <he...@yandell.org>:

> They're not committers, so I doubt anyone has requested they sign a ICLA.
> Looking at the GitHub history, some haven't been active in a while.
>
> Hen
>
> On Tue, Aug 29, 2017 at 11:07 PM, shiwen hu <yajiedes...@gmail.com> wrote:
>
> > Maybe they don't know how to start the ICLA process.Consider creating a
> > boot page.
> >
> > 2017-08-30 13:06 GMT+08:00 Henri Yandell <bay...@apache.org>:
> >
> > > (cc to John and Justin as they'd asked about this)
> > >
> > > Looking at the current MXNet GitHub contributors list (411
> contributors):
> > >
> > > We have 36 signed CLAs at this point.
> > >
> > > Of the top 36 contributors, the following 15 top contributors aren't
> > > covered by a CLA:
> > >
> > > 8:sneakerkg
> > > 9:kevinthesun  (post Incubation)
> > > 17:hjk41
> > > 18:mavenlin
> > > 19:tornadomeet
> > > 20:winstywang
> > > 21:jermainewang
> > > 22:qiaohaijun
> > > 23:vchuravy
> > > 25:Roshrini  (post Incubation)
> > > 26:howard0su
> > > 28:sbodenstein
> > > 31:ptrendx  (post Incubation)
> > > 35:zackchase   (post Incubation)
> > > 36:yanqingmen
> > >
> > > Note that some of these are post entering the Incubator.
> > >
> > > Some of the 411 contributors we should ask for CLA/SGs from. Those
> above
> > > are most likely the first to get agreements signed from, and we need to
> > > determine how far down the list to go.
> > >
> > > The git logs are trickier to use as they don't use the github login; so
> > > doing an analysis of the diffs themselves is trickier.
> > >
> > > Hen
> > >
> >
>

Re: ICLAs vs Contributors

[shiwen hu]

Maybe they don't know how to start the ICLA process.Consider creating a
boot page.

2017-08-30 13:06 GMT+08:00 Henri Yandell :

> (cc to John and Justin as they'd asked about this)
>
> Looking at the current MXNet GitHub contributors list (411 contributors):
>
> We have 36 signed CLAs at this point.
>
> Of the top 36 contributors, the following 15 top contributors aren't
> covered by a CLA:
>
> 8:sneakerkg
> 9:kevinthesun  (post Incubation)
> 17:hjk41
> 18:mavenlin
> 19:tornadomeet
> 20:winstywang
> 21:jermainewang
> 22:qiaohaijun
> 23:vchuravy
> 25:Roshrini  (post Incubation)
> 26:howard0su
> 28:sbodenstein
> 31:ptrendx  (post Incubation)
> 35:zackchase   (post Incubation)
> 36:yanqingmen
>
> Note that some of these are post entering the Incubator.
>
> Some of the 411 contributors we should ask for CLA/SGs from. Those above
> are most likely the first to get agreements signed from, and we need to
> determine how far down the list to go.
>
> The git logs are trickier to use as they don't use the github login; so
> doing an analysis of the diffs themselves is trickier.
>
> Hen
>

windows ci problem

[shiwen hu]

some error like " Cannot contact mxnet-win7: java.lang.InterruptedException"
and jenkins is blocked

Re: GitHub releases section used for non-releases

[shiwen hu]

this util is use in decompression mkldnn depend. pr is
https://github.com/apache/incubator-mxnet/pull/10629 .
marcoabreu Ask me not to put it in a private repositories.
If it doesn't feel right, we can discuss another plan.
Now I've changed it to pre-release

2018-05-02 6:37 GMT+08:00 Hen :

> Wincing at a binary of 7z being there. Seems like something to delete.
>
> On Tue, May 1, 2018 at 3:32 PM Marco de Abreu <
> marco.g.ab...@googlemail.com>
> wrote:
>
> > Hello,
> >
> > I have just had a look at
> > https://github.com/apache/incubator-mxnet/releases
> > and it seems like the releases section is being used for other purposes
> > than MXNet releases (e.g.
> > https://github.com/apache/incubator-mxnet/releases/tag/utils). This
> causes
> > MXNet 1.1.0 to not be shown as "Latest release" and results in confusion.
> >
> > In general, I don't really understand the purpose of utility releases and
> > why they are being done under the main repository. Could somebody
> elaborate
> > and provide some insight? I haven't found any communication on dev@
> about
> > this.
> >
> > Best regards,
> > Marco
> >
>

Re: Propose to discontinue supporting Apache MXNet on Windows 7

[shiwen hu]

At present, all precompiled packages are win10-compiled.
There are no large-scale reports that can no run win7.
Therefore, there is no problem for all precompiled package users to stop or
continue supporting.

Timur Shenkao  于2018年9月3日周一 下午5:14写道：

> Users live like you described: install mxnet, then import fails, switch to
> TF or Pytorch and forget mxnet forever.
>
> Only very stubborn users spend time in loop: compiling / building wheel /
> conda package on external machine, copy to destination machine, fail with
> some dependency error, etc. Until patience is lost or something workable is
> created.
>
> On Monday, September 3, 2018, Lin Yuan  wrote:
>
> > Thanks for all the constructive discussions. I have a few thoughts on
> this
> > topic:
> >
> > When we say we support a particular platform X, I suppose it means the
> > following processes in production:
> >
> > 1) Active developer support, the minimum of which is a clear instruction
> to
> > build from source on X.
> > 2) Thorough test in each release/patch on X.
> > 3) Continuous integration on X
> >
> > It seems today we are missing all of them for Windows 7 (correct me if I
> am
> > wrong). I have found issues opened over 9 months ago #9271
> >  which fails
> simply
> > by importing mxnet and exiting on Windows 7. Thus, I am wondering how
> many
> > users are actually running MXNet on Windows 7 for meaningful work. How
> did
> > live by with such an obvious blocker.
> >
> > If we do have a large active user base to support, we then should
> dedicate
> > resource to implement the above three items in order to claim that we
> > support Windows 7. After all, maybe we should change the thread topic to
> > "Should we start supporting Windows 7 again?" :)
> >
> > I really appreciate your valuable comments. Have a great labor day
> weekend!
> >
> > Lin
> >
> >
> > On Sun, Sep 2, 2018 at 12:37 PM Timur Shenkao  wrote:
> >
> > > >> I also believe that it is possible to install more recent >>
> versions
> > of
> > > Visual Studio on Windows 7.
> > >
> > > It's about security reasons and AD permissions and bought licenses for
> > VS,
> > > not about general technical impossibility of installation of up-to-date
> > > versions.
> > >
> > > On Sunday, September 2, 2018, Marco de Abreu
> > >  wrote:
> > >
> > > > Thanks for the data and these quite important points. I agree and
> > hereby
> > > > change my vote to -1.
> > > >
> > > > Barber, Christopher  schrieb am So.,
> 2.
> > > > Sep.
> > > > 2018, 18:56:
> > > >
> > > > > FWIW, my company is only beginning to transition to Windows 10 now,
> > and
> > > > my
> > > > > past experience would lead me to believe that many enterprises
> stick
> > > with
> > > > > old versions of Windows long past when you think they would.
> > > > >
> > > > > Seems to me that if you are unwilling to deprecate python 2.7, then
> > > > > continuing to support Windows 7 is a no-brainer. You are more
> likely
> > to
> > > > get
> > > > > users to switch to python 3 than you are to get them to install a
> new
> > > > > operating system.
> > > > >
> > > > > And do you really want to drop support for platforms that your
> > > > competitors
> > > > > still support? Given MXNet's market share, I wouldn't dream of
> > > dropping a
> > > > > platform until after the more popular frameworks have already done
> > so.
> > > > >
> > > > > I also believe that it is possible to install more recent versions
> of
> > > > > Visual Studio on Windows 7.
> > > > >
> > > > > On 9/2/18, 1:57 AM, "kellen sunderland" <
> > kellen.sunderl...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > Google analytics are sadly probably the best numbers we're
> going
> > to
> > > > > get.
> > > > > Of course these numbers are likely to over-represent windows
> > usage,
> > > > as
> > > > > I'm
> > > > > sure many people are looking up documentation on a windows
> > machine
> > > > > while
> > > > > ssh'd into a cloud instance or IoT device.
> > > > >
> > > > > What's the trend over time for these numbers Mu?  Is Windows 7
> > > usage
> > > > > relatively stable over the last year?
> > > > >
> > > > > On Sun, Sep 2, 2018 at 1:58 AM Mu Li 
> wrote:
> > > > >
> > > > > > According to google analytics, ~12% users who visited mxnet's
> > > > > website are
> > > > > > using Windows 7. It's a significant number. Even though we
> > cannot
> > > > > conclude
> > > > > > that all of these users will run MXNet on Windows 7, I
> suggest
> > we
> > > > > still
> > > > > > support win7.
> > > > > >
> > > > > > BTW, anyone who can access mxnet's google analytics report
> can
> > > > > verify this
> > > > > > number by following this instruction:
> > > > > >
> > > > > >
> > > > > https://stackoverflow.com/questions/1340778/detecting-
> > > > windows-7-with-google-analytics
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Sat, Sep 1, 2018 at 1:55 PM 

Re: Propose to discontinue supporting Apache MXNet on Windows 7

[shiwen hu]

The known problem with Win7 now is
https://github.com/apache/incubator-mxnet/issues/9271.
Because I've upgraded Win10, so I can't reproduce this problem, and I can't
solve it.
I am not sure whether the problem has been solved now.
I am sorry about this

shiwen hu  于2018年9月3日周一 下午7:43写道：

> At present, all precompiled packages are win10-compiled.
> There are no large-scale reports that can no run win7.
> Therefore, there is no problem for all precompiled package users to stop
> or continue supporting.
>
> Timur Shenkao  于2018年9月3日周一 下午5:14写道：
>
>> Users live like you described: install mxnet, then import fails, switch to
>> TF or Pytorch and forget mxnet forever.
>>
>> Only very stubborn users spend time in loop: compiling / building wheel /
>> conda package on external machine, copy to destination machine, fail with
>> some dependency error, etc. Until patience is lost or something workable
>> is
>> created.
>>
>> On Monday, September 3, 2018, Lin Yuan  wrote:
>>
>> > Thanks for all the constructive discussions. I have a few thoughts on
>> this
>> > topic:
>> >
>> > When we say we support a particular platform X, I suppose it means the
>> > following processes in production:
>> >
>> > 1) Active developer support, the minimum of which is a clear
>> instruction to
>> > build from source on X.
>> > 2) Thorough test in each release/patch on X.
>> > 3) Continuous integration on X
>> >
>> > It seems today we are missing all of them for Windows 7 (correct me if
>> I am
>> > wrong). I have found issues opened over 9 months ago #9271
>> > <https://github.com/apache/incubator-mxnet/issues/9271> which fails
>> simply
>> > by importing mxnet and exiting on Windows 7. Thus, I am wondering how
>> many
>> > users are actually running MXNet on Windows 7 for meaningful work. How
>> did
>> > live by with such an obvious blocker.
>> >
>> > If we do have a large active user base to support, we then should
>> dedicate
>> > resource to implement the above three items in order to claim that we
>> > support Windows 7. After all, maybe we should change the thread topic to
>> > "Should we start supporting Windows 7 again?" :)
>> >
>> > I really appreciate your valuable comments. Have a great labor day
>> weekend!
>> >
>> > Lin
>> >
>> >
>> > On Sun, Sep 2, 2018 at 12:37 PM Timur Shenkao 
>> wrote:
>> >
>> > > >> I also believe that it is possible to install more recent >>
>> versions
>> > of
>> > > Visual Studio on Windows 7.
>> > >
>> > > It's about security reasons and AD permissions and bought licenses for
>> > VS,
>> > > not about general technical impossibility of installation of
>> up-to-date
>> > > versions.
>> > >
>> > > On Sunday, September 2, 2018, Marco de Abreu
>> > >  wrote:
>> > >
>> > > > Thanks for the data and these quite important points. I agree and
>> > hereby
>> > > > change my vote to -1.
>> > > >
>> > > > Barber, Christopher  schrieb am
>> So., 2.
>> > > > Sep.
>> > > > 2018, 18:56:
>> > > >
>> > > > > FWIW, my company is only beginning to transition to Windows 10
>> now,
>> > and
>> > > > my
>> > > > > past experience would lead me to believe that many enterprises
>> stick
>> > > with
>> > > > > old versions of Windows long past when you think they would.
>> > > > >
>> > > > > Seems to me that if you are unwilling to deprecate python 2.7,
>> then
>> > > > > continuing to support Windows 7 is a no-brainer. You are more
>> likely
>> > to
>> > > > get
>> > > > > users to switch to python 3 than you are to get them to install a
>> new
>> > > > > operating system.
>> > > > >
>> > > > > And do you really want to drop support for platforms that your
>> > > > competitors
>> > > > > still support? Given MXNet's market share, I wouldn't dream of
>> > > dropping a
>> > > > > platform until after the more popular frameworks have already done
>> > so.
>> > > > >
>> > > > > I also believe that it is possible to install more recent
>> versions of
&

Requesting slack access

[shiwen hu]

please add me to slack

Re: Can upgrade windows CI cmake?

[shiwen hu]

Now, other problems are solved by modifying CMakeLists.txt.but The command
line is too long problem must update cmake.However I don't know which
minimum version fixed the problem.I try to do some tests to find out the
minimum version.

Pedro Larroy  于2019年12月7日周六 上午3:52写道：

> CMake shipped with ubuntu has issues when compiling with CUDA on GPU
> instances.  I wouldn't recommend anything older than 3.12 for Linux GPU
>
>
> https://github.com/apache/incubator-mxnet/blob/master/ci/docker/install/ubuntu_core.sh#L63
>
> I don't know about windows CMake version but would make sense to require a
> newer version.
>
> On Thu, Dec 5, 2019 at 7:26 PM Lausen, Leonard 
> wrote:
>
> > Currently we declare cmake_minimum_required(VERSION 3.0.2)
> >
> > I'm in favor of updating our CMake requirement. The main question may be
> > what
> > new version to pick as minimum requirement.
> >
> > In general, there is the guideline
> >
> > > You really should at least use a version of CMake that came out after
> > your
> > > compiler, since it needs to know compiler flags, etc, for that version.
> > And,
> > > since CMake will dumb itself down to the minimum required version in
> your
> > > CMake file, installing a new CMake, even system wide, is pretty safe.
> You
> > > should at least install it locally. It's easy (1-2 lines in many
> cases),
> > and
> > > you'll find that 5 minutes of work will save you hundreds of lines and
> > hours
> > > of CMakeLists.txt writing, and will be much easier to maintain in the
> > long
> > > run.
> > https://cliutils.gitlab.io/modern-cmake/
> >
> > https://cliutils.gitlab.io/modern-cmake/chapters/intro/newcmake.html
> > gives a
> > short overview of all the improvements made to CMake over the past 6
> years.
> >
> > It's easy for users to upgrade their cmake version with pip:
> >   pip install --upgrade --user cmake
> > Thus it wouldn't be overly problematic to rely on a very recent version
> of
> > cmake, if indeed it's required.
> >
> > Nevertheless, if an earlier version fixes the problems, let's rather pick
> > that
> > one. Did you confirm which version is required to fix the problem?
> >
> > For now you could try if the CMake version shipped in the oldest
> supported
> > Ubuntu LTS release (Ubuntu 16.04) is fixing your problem (CMake 3.5)? If
> > not,
> > please test if CMake version shipped in Ubuntu 18.04 (CMake 3.10) fixes
> > your
> > issue.
> >
> > Thanks
> > Leonard
> >
> > On Fri, 2019-12-06 at 08:45 +0800, shiwen hu wrote:
> > > i am send a pr  https://github.com/apache/incubator-mxnet/pull/16980
> to
> > > change windows build system.but now ci cmake version seems to be a bug.
> > > can't to compile.can upgrade to 3.16.0?
> >
>

Can upgrade windows CI cmake?

[shiwen hu]

i am send a pr  https://github.com/apache/incubator-mxnet/pull/16980 to
change windows build system.but now ci cmake version seems to be a bug.
can't to compile.can upgrade to 3.16.0?

Re: Can upgrade windows CI cmake?

[shiwen hu]

i test 3.12.2 3.13.3 3.14.2 3.15.5

shiwen hu  于2019年12月7日周六 下午7:28写道：

> yes.
>
> Lausen, Leonard  于2019年12月7日周六 下午7:20写道：
>
>> Do you mean starting 3.15.5 it works fine?
>> The image you attached doesn't display on my end.
>>
>> On Dec 7, 2019 19:12, shiwen hu  wrote:
>> [image.png]
>>
>> I tested these versions.  until 3.15.5 is working fine.
>>
>> shiwen hu mailto:yajiedes...@gmail.com>>
>> 于2019年12月7日周六 下午1:24写道：
>> Now, other problems are solved by modifying CMakeLists.txt.but The
>> command line is too long problem must update cmake.However I don't know
>> which minimum version fixed the problem.I try to do some tests to find out
>> the minimum version.
>>
>> Pedro Larroy > pedro.larroy.li...@gmail.com>> 于2019年12月7日周六 上午3:52写道：
>> CMake shipped with ubuntu has issues when compiling with CUDA on GPU
>> instances.  I wouldn't recommend anything older than 3.12 for Linux GPU
>>
>>
>> https://github.com/apache/incubator-mxnet/blob/master/ci/docker/install/ubuntu_core.sh#L63
>>
>> I don't know about windows CMake version but would make sense to require a
>> newer version.
>>
>> On Thu, Dec 5, 2019 at 7:26 PM Lausen, Leonard > >
>> wrote:
>>
>> > Currently we declare cmake_minimum_required(VERSION 3.0.2)
>> >
>> > I'm in favor of updating our CMake requirement. The main question may be
>> > what
>> > new version to pick as minimum requirement.
>> >
>> > In general, there is the guideline
>> >
>> > > You really should at least use a version of CMake that came out after
>> > your
>> > > compiler, since it needs to know compiler flags, etc, for that
>> version.
>> > And,
>> > > since CMake will dumb itself down to the minimum required version in
>> your
>> > > CMake file, installing a new CMake, even system wide, is pretty safe.
>> You
>> > > should at least install it locally. It's easy (1-2 lines in many
>> cases),
>> > and
>> > > you'll find that 5 minutes of work will save you hundreds of lines and
>> > hours
>> > > of CMakeLists.txt writing, and will be much easier to maintain in the
>> > long
>> > > run.
>> > https://cliutils.gitlab.io/modern-cmake/
>> >
>> > https://cliutils.gitlab.io/modern-cmake/chapters/intro/newcmake.html
>> > gives a
>> > short overview of all the improvements made to CMake over the past 6
>> years.
>> >
>> > It's easy for users to upgrade their cmake version with pip:
>> >   pip install --upgrade --user cmake
>> > Thus it wouldn't be overly problematic to rely on a very recent version
>> of
>> > cmake, if indeed it's required.
>> >
>> > Nevertheless, if an earlier version fixes the problems, let's rather
>> pick
>> > that
>> > one. Did you confirm which version is required to fix the problem?
>> >
>> > For now you could try if the CMake version shipped in the oldest
>> supported
>> > Ubuntu LTS release (Ubuntu 16.04) is fixing your problem (CMake 3.5)? If
>> > not,
>> > please test if CMake version shipped in Ubuntu 18.04 (CMake 3.10) fixes
>> > your
>> > issue.
>> >
>> > Thanks
>> > Leonard
>> >
>> > On Fri, 2019-12-06 at 08:45 +0800, shiwen hu wrote:
>> > > i am send a pr  https://github.com/apache/incubator-mxnet/pull/16980
>> to
>> > > change windows build system.but now ci cmake version seems to be a
>> bug.
>> > > can't to compile.can upgrade to 3.16.0?
>> >
>>
>>

Re: Can upgrade windows CI cmake?

[shiwen hu]

yes.

Lausen, Leonard  于2019年12月7日周六 下午7:20写道：

> Do you mean starting 3.15.5 it works fine?
> The image you attached doesn't display on my end.
>
> On Dec 7, 2019 19:12, shiwen hu  wrote:
> [image.png]
>
> I tested these versions.  until 3.15.5 is working fine.
>
> shiwen hu mailto:yajiedes...@gmail.com>>
> 于2019年12月7日周六 下午1:24写道：
> Now, other problems are solved by modifying CMakeLists.txt.but The command
> line is too long problem must update cmake.However I don't know which
> minimum version fixed the problem.I try to do some tests to find out the
> minimum version.
>
> Pedro Larroy  pedro.larroy.li...@gmail.com>> 于2019年12月7日周六 上午3:52写道：
> CMake shipped with ubuntu has issues when compiling with CUDA on GPU
> instances.  I wouldn't recommend anything older than 3.12 for Linux GPU
>
>
> https://github.com/apache/incubator-mxnet/blob/master/ci/docker/install/ubuntu_core.sh#L63
>
> I don't know about windows CMake version but would make sense to require a
> newer version.
>
> On Thu, Dec 5, 2019 at 7:26 PM Lausen, Leonard 
> wrote:
>
> > Currently we declare cmake_minimum_required(VERSION 3.0.2)
> >
> > I'm in favor of updating our CMake requirement. The main question may be
> > what
> > new version to pick as minimum requirement.
> >
> > In general, there is the guideline
> >
> > > You really should at least use a version of CMake that came out after
> > your
> > > compiler, since it needs to know compiler flags, etc, for that version.
> > And,
> > > since CMake will dumb itself down to the minimum required version in
> your
> > > CMake file, installing a new CMake, even system wide, is pretty safe.
> You
> > > should at least install it locally. It's easy (1-2 lines in many
> cases),
> > and
> > > you'll find that 5 minutes of work will save you hundreds of lines and
> > hours
> > > of CMakeLists.txt writing, and will be much easier to maintain in the
> > long
> > > run.
> > https://cliutils.gitlab.io/modern-cmake/
> >
> > https://cliutils.gitlab.io/modern-cmake/chapters/intro/newcmake.html
> > gives a
> > short overview of all the improvements made to CMake over the past 6
> years.
> >
> > It's easy for users to upgrade their cmake version with pip:
> >   pip install --upgrade --user cmake
> > Thus it wouldn't be overly problematic to rely on a very recent version
> of
> > cmake, if indeed it's required.
> >
> > Nevertheless, if an earlier version fixes the problems, let's rather pick
> > that
> > one. Did you confirm which version is required to fix the problem?
> >
> > For now you could try if the CMake version shipped in the oldest
> supported
> > Ubuntu LTS release (Ubuntu 16.04) is fixing your problem (CMake 3.5)? If
> > not,
> > please test if CMake version shipped in Ubuntu 18.04 (CMake 3.10) fixes
> > your
> > issue.
> >
> > Thanks
> > Leonard
> >
> > On Fri, 2019-12-06 at 08:45 +0800, shiwen hu wrote:
> > > i am send a pr  https://github.com/apache/incubator-mxnet/pull/16980
> to
> > > change windows build system.but now ci cmake version seems to be a bug.
> > > can't to compile.can upgrade to 3.16.0?
> >
>
>

Re: Can upgrade windows CI cmake?

[shiwen hu]

[image: image.png]

I tested these versions.  until 3.15.5 is working fine.

shiwen hu  于2019年12月7日周六 下午1:24写道：

> Now, other problems are solved by modifying CMakeLists.txt.but The command
> line is too long problem must update cmake.However I don't know which
> minimum version fixed the problem.I try to do some tests to find out the
> minimum version.
>
> Pedro Larroy  于2019年12月7日周六 上午3:52写道：
>
>> CMake shipped with ubuntu has issues when compiling with CUDA on GPU
>> instances.  I wouldn't recommend anything older than 3.12 for Linux GPU
>>
>>
>> https://github.com/apache/incubator-mxnet/blob/master/ci/docker/install/ubuntu_core.sh#L63
>>
>> I don't know about windows CMake version but would make sense to require a
>> newer version.
>>
>> On Thu, Dec 5, 2019 at 7:26 PM Lausen, Leonard > >
>> wrote:
>>
>> > Currently we declare cmake_minimum_required(VERSION 3.0.2)
>> >
>> > I'm in favor of updating our CMake requirement. The main question may be
>> > what
>> > new version to pick as minimum requirement.
>> >
>> > In general, there is the guideline
>> >
>> > > You really should at least use a version of CMake that came out after
>> > your
>> > > compiler, since it needs to know compiler flags, etc, for that
>> version.
>> > And,
>> > > since CMake will dumb itself down to the minimum required version in
>> your
>> > > CMake file, installing a new CMake, even system wide, is pretty safe.
>> You
>> > > should at least install it locally. It's easy (1-2 lines in many
>> cases),
>> > and
>> > > you'll find that 5 minutes of work will save you hundreds of lines and
>> > hours
>> > > of CMakeLists.txt writing, and will be much easier to maintain in the
>> > long
>> > > run.
>> > https://cliutils.gitlab.io/modern-cmake/
>> >
>> > https://cliutils.gitlab.io/modern-cmake/chapters/intro/newcmake.html
>> > gives a
>> > short overview of all the improvements made to CMake over the past 6
>> years.
>> >
>> > It's easy for users to upgrade their cmake version with pip:
>> >   pip install --upgrade --user cmake
>> > Thus it wouldn't be overly problematic to rely on a very recent version
>> of
>> > cmake, if indeed it's required.
>> >
>> > Nevertheless, if an earlier version fixes the problems, let's rather
>> pick
>> > that
>> > one. Did you confirm which version is required to fix the problem?
>> >
>> > For now you could try if the CMake version shipped in the oldest
>> supported
>> > Ubuntu LTS release (Ubuntu 16.04) is fixing your problem (CMake 3.5)? If
>> > not,
>> > please test if CMake version shipped in Ubuntu 18.04 (CMake 3.10) fixes
>> > your
>> > issue.
>> >
>> > Thanks
>> > Leonard
>> >
>> > On Fri, 2019-12-06 at 08:45 +0800, shiwen hu wrote:
>> > > i am send a pr  https://github.com/apache/incubator-mxnet/pull/16980
>> to
>> > > change windows build system.but now ci cmake version seems to be a
>> bug.
>> > > can't to compile.can upgrade to 3.16.0?
>> >
>>
>

Re: CD with windows need a special jenkins slave machine like restricted-utility

[shiwen hu]

use x64 host msvc. cmake -T host=x64

Pedro Larroy  于2020年1月10日周五 上午7:28写道：

> Is there a solution for this error in VS2017?
>
> c:\users\administrator\mxnet\src\operator\mxnet_op.h(943) : fatal error
> C1002: compiler is out of heap space in pass 2
>
>
>
> On Tue, Jan 7, 2020 at 5:11 PM shiwen hu  wrote:
>
> > >
> > > I personally encountered the problem that 2015 can't compile in high
> > > version cuda. But I can't remember the details. We can continue to use
> > 2015
> > > until we encounter problems.
> > >
> >
>

Re: MXNet 1.6 as last release with Python 2 support?

[shiwen hu]

+1

Lai Wei  于2020年1月18日周六 上午2:51写道：

> +1
>
>
> Best Regards
>
> Lai
>
>
> On Fri, Jan 17, 2020 at 10:39 AM Lin Yuan  wrote:
>
> > +1
> >
> > On Fri, Jan 17, 2020 at 10:04 AM Xingjian SHI 
> > wrote:
> >
> > > +1. We should move to support Python>=3.5 only.
> > >
> > > Get Outlook for iOS
> > > 
> > > From: Lausen, Leonard 
> > > Sent: Friday, January 17, 2020 10:02:30 AM
> > > To: d...@mxnet.apache.org 
> > > Subject: Re: MXNet 1.6 as last release with Python 2 support?
> > >
> > > If the lazy consensus passes, I believe the minimum Python version
> > > supported
> > > would be Python 3.5.
> > >
> > > Python 3.5 because it seems to be the minimum Python 3 version tested
> by
> > > our CI,
> > > specifically in the jobs running on Ubuntu 16.04.
> > >
> > > Best regards
> > > Leonard
> > >
> > > On Fri, 2020-01-17 at 17:36 +, Lausen, Leonard wrote:
> > > > Dear MXNet community,
> > > >
> > > > as effective January 1, 2020, no new bug reports, fixes, or changes
> > will
> > > be
> > > > made
> > > > to Python 2, and as MXNet 1.6 will be released after January 1,
> 2020, I
> > > > suggest
> > > > to announce in the MXNet 1.6 release notes that MXNet 1.6 is the last
> > > release
> > > > supporting Python 2.
> > > >
> > > > We have previously reached consensus on announcing that Python 2 is
> > > dropped in
> > > > the next major release (ie. MXNet 2), however, given the delay in 1.6
> > > release,
> > > > the plan to release 1.7 in the future and that Python 2 is dead
> > already I
> > > > think
> > > > we can revisit this assumption.
> > > >
> > > > Advantages are
> > > > - Time savings for developers, as Python 3 standard library contains
> > more
> > > >   features than Python 2, and it is more efficient to target only 1
> > > language
> > > >   (Python 3) instead of 2 languages (Python 2 & 3)
> > > > - Simplification and cost savings for CI
> > > >
> > > > I thus suggest 72h lazy consensus for announcing dropping of Python 2
> > as
> > > > described above. If you disagree, please veto (send "-1") and we can
> > > continue
> > > > supporting Python 2 in all 1.x releases as per previous consensus.
> Note
> > > that
> > > > at
> > > > the time of previous consensus, no 1.7 release was planned.
> > > >
> > > > Best regards
> > > > Leonard
> > >
> >
>

Re: Stopping nightly releases to Pypi

[shiwen hu]

why not use pypiserver? it is  compatible server for pip.use it can install
pack like pip install -i http:/// mxnet --pre

Skalicky, Sam  于2020年1月7日周二 上午2:55写道：

> Thats a good idea Leonard, we can have a static html page in the bucket
> for this. But keep in mind pip wheels do have a COMMIT_HASH file packaged
> inside. So we can always figure out which commit/build a user has by
> dumping this file from the mxnet installation. File name of the pip wheel
> is not so important.
>
> Sam
>
> > On Jan 6, 2020, at 10:19 AM, Lausen, Leonard 
> wrote:
> >
> > Consider a user finds a bug in a nightly version but we can't narrow
> down the
> > version of mxnet used as the name is constant over time. Or users wan't
> to
> > revert back to the previous nightly version installed but don't know
> which date
> > it was from due to constant name.
> >
> > Instead I suggest we introduce an autogenerated page like
> > https://download.pytorch.org/whl/nightly/cu101/torch_nightly.html
> >
> > Then "pip install -f URLTOPAGE mxnet" will install the latest available
> version.
> > Maybe the team maintaining the S3 bucket can reconsider creating such
> page for
> > the intermediate time until the CD based nighlty build is operating.
> >
> > On Mon, 2020-01-06 at 10:01 -0800, Lin Yuan wrote:
> >> +1 for a nightly pip with fixed name.
> >>
> >> We need this to track mxnet integration with other packages such as
> Horovod.
> >>
> >> Sam, when do you think we can have this nightly build with a fixed name?
> >>
> >> Thanks,
> >>
> >> Lin
> >>
> >> On Sun, Jan 5, 2020 at 7:48 PM Skalicky, Sam  >
> >> wrote:
> >>
> >>> Hi Tao,
> >>>
> >>> We dont have this yet, but we did think about putting the latest
> wheels in
> >>> a specific place in the s3 bucket so they are always updated.
> Initially we
> >>> decided not to do this since the main MXNet CD should have been fixed.
> But
> >>> since its still not fixed yet, we might try and go ahead and do this.
> >>>
> >>> Sam
> >>>
> >>> On Jan 5, 2020, at 6:02 PM, Lv, Tao A  >>> tao.a...@intel.com>> wrote:
> >>>
> >>> Hi,
> >>>
> >>> How to install the latest available build of a flavor without
> specifying
> >>> the build date? Something like `pip install mxnet --pre`.
> >>>
> >>> Thanks,
> >>> -tao
> >>>
> >>> -Original Message-
> >>> From: Skalicky, Sam  >>> sska...@amazon.com.INVALID>>
> >>> Sent: Monday, January 6, 2020 2:09 AM
> >>> To: dev@mxnet.incubator.apache.org dev@mxnet.incubator.apache.org>
> >>> Subject: Re: Stopping nightly releases to Pypi
> >>>
> >>> Hi Haibin,
> >>>
> >>> You typed the correct URLs, the cu100 build has been failing since
> >>> December 30th but other builds have succeeded. The wheels are being
> >>> delivered into a public bucket that anyone with an AWS account can
> access
> >>> and go poke around, here’s the URL for web access:
> >>>
> >>>
> >>>
> https://s3.console.aws.amazon.com/s3/buckets/apache-mxnet/dist/2020-01-01/dist/?region=us-west-2=overview
> >>>
> >>> You will have to log into your AWS account to access it however (which
> >>> means you’ll need an AWS account).
> >>>
> >>> It looks like only the following flavors are available for 2020-01-01:
> >>> mxnet
> >>> mxnet-cu92
> >>> mxnet-cu92mkl
> >>> mxnet-mkl
> >>>
> >>> Sam
> >>>
> >>> On Jan 4, 2020, at 9:06 PM, Haibin Lin   >>> haibin.lin@gmail.com>> wrote:
> >>>
> >>> I was trying the nightly builds, but none of them is available:
> >>>
> >>> pip3 install
> >>>
> >>>
> https://apache-mxnet.s3-us-west-2.amazonaws.com/dist/2020-01-01/dist/mxnet_cu100-1.6.0b20200101-py2.py3-none-manylinux1_x86_64.whl
> >>> --user
> >>> <
> >>>
> https://apache-mxnet.s3-us-west-2.amazonaws.com/dist/2020-01-01/dist/mxnet_cu100-1.6.0b20200101-py2.py3-none-manylinux1_x86_64.whl--user
> 
> >>> pip3 install
> >>>
> >>>
> https://apache-mxnet.s3-us-west-2.amazonaws.com/dist/2020-01-02/dist/mxnet_cu100-1.6.0b20200102-py2.py3-none-manylinux1_x86_64.whl
> >>> --user
> >>> <
> >>>
> https://apache-mxnet.s3-us-west-2.amazonaws.com/dist/2020-01-02/dist/mxnet_cu100-1.6.0b20200102-py2.py3-none-manylinux1_x86_64.whl--user
> 
> >>> pip3 install
> >>>
> >>>
> https://apache-mxnet.s3-us-west-2.amazonaws.com/dist/2020-01-03/dist/mxnet_cu100-1.6.0b20200103-py2.py3-none-manylinux1_x86_64.whl
> >>> --user
> >>> <
> >>>
> https://apache-mxnet.s3-us-west-2.amazonaws.com/dist/2020-01-03/dist/mxnet_cu100-1.6.0b20200103-py2.py3-none-manylinux1_x86_64.whl--user
> 
> >>> pip3 install
> >>>
> >>>
> https://apache-mxnet.s3-us-west-2.amazonaws.com/dist/2020-01-04/dist/mxnet_cu100-1.6.0b20200104-py2.py3-none-manylinux1_x86_64.whl
> >>> --user
> >>> <
> >>>
> https://apache-mxnet.s3-us-west-2.amazonaws.com/dist/2020-01-04/dist/mxnet_cu100-1.6.0b20200104-py2.py3-none-manylinux1_x86_64.whl--user
> 
> >>>
> >>> ERROR: Could not install requirement mxnet-cu100==1.6.0b20200103 from
> >>>
> 

Re: Stopping nightly releases to Pypi

[shiwen hu]

or use PyPICloud.it can storage pack to s3 and compatible to pip.

shiwen hu  于2020年1月7日周二 上午10:27写道：

> why not use pypiserver? it is  compatible server for pip.use it can
> install pack like pip install -i http:/// mxnet --pre
>
> Skalicky, Sam  于2020年1月7日周二 上午2:55写道：
>
>> Thats a good idea Leonard, we can have a static html page in the bucket
>> for this. But keep in mind pip wheels do have a COMMIT_HASH file packaged
>> inside. So we can always figure out which commit/build a user has by
>> dumping this file from the mxnet installation. File name of the pip wheel
>> is not so important.
>>
>> Sam
>>
>> > On Jan 6, 2020, at 10:19 AM, Lausen, Leonard 
>> wrote:
>> >
>> > Consider a user finds a bug in a nightly version but we can't narrow
>> down the
>> > version of mxnet used as the name is constant over time. Or users wan't
>> to
>> > revert back to the previous nightly version installed but don't know
>> which date
>> > it was from due to constant name.
>> >
>> > Instead I suggest we introduce an autogenerated page like
>> > https://download.pytorch.org/whl/nightly/cu101/torch_nightly.html
>> >
>> > Then "pip install -f URLTOPAGE mxnet" will install the latest available
>> version.
>> > Maybe the team maintaining the S3 bucket can reconsider creating such
>> page for
>> > the intermediate time until the CD based nighlty build is operating.
>> >
>> > On Mon, 2020-01-06 at 10:01 -0800, Lin Yuan wrote:
>> >> +1 for a nightly pip with fixed name.
>> >>
>> >> We need this to track mxnet integration with other packages such as
>> Horovod.
>> >>
>> >> Sam, when do you think we can have this nightly build with a fixed
>> name?
>> >>
>> >> Thanks,
>> >>
>> >> Lin
>> >>
>> >> On Sun, Jan 5, 2020 at 7:48 PM Skalicky, Sam
>> 
>> >> wrote:
>> >>
>> >>> Hi Tao,
>> >>>
>> >>> We dont have this yet, but we did think about putting the latest
>> wheels in
>> >>> a specific place in the s3 bucket so they are always updated.
>> Initially we
>> >>> decided not to do this since the main MXNet CD should have been
>> fixed. But
>> >>> since its still not fixed yet, we might try and go ahead and do this.
>> >>>
>> >>> Sam
>> >>>
>> >>> On Jan 5, 2020, at 6:02 PM, Lv, Tao A > >>> tao.a...@intel.com>> wrote:
>> >>>
>> >>> Hi,
>> >>>
>> >>> How to install the latest available build of a flavor without
>> specifying
>> >>> the build date? Something like `pip install mxnet --pre`.
>> >>>
>> >>> Thanks,
>> >>> -tao
>> >>>
>> >>> -Original Message-
>> >>> From: Skalicky, Sam > >>> sska...@amazon.com.INVALID>>
>> >>> Sent: Monday, January 6, 2020 2:09 AM
>> >>> To: dev@mxnet.incubator.apache.org> dev@mxnet.incubator.apache.org>
>> >>> Subject: Re: Stopping nightly releases to Pypi
>> >>>
>> >>> Hi Haibin,
>> >>>
>> >>> You typed the correct URLs, the cu100 build has been failing since
>> >>> December 30th but other builds have succeeded. The wheels are being
>> >>> delivered into a public bucket that anyone with an AWS account can
>> access
>> >>> and go poke around, here’s the URL for web access:
>> >>>
>> >>>
>> >>>
>> https://s3.console.aws.amazon.com/s3/buckets/apache-mxnet/dist/2020-01-01/dist/?region=us-west-2=overview
>> >>>
>> >>> You will have to log into your AWS account to access it however (which
>> >>> means you’ll need an AWS account).
>> >>>
>> >>> It looks like only the following flavors are available for 2020-01-01:
>> >>> mxnet
>> >>> mxnet-cu92
>> >>> mxnet-cu92mkl
>> >>> mxnet-mkl
>> >>>
>> >>> Sam
>> >>>
>> >>> On Jan 4, 2020, at 9:06 PM, Haibin Lin > > >>> haibin.lin@gmail.com><mailto:haibin.lin@gmail.com>> wrote:
>> >>>
>> >>> I was trying the nightly builds, but none of them is available:
>> >>>
>> >>> pip3 install
>> &g

Re: CD with windows need a special jenkins slave machine like restricted-utility

[shiwen hu]

>
> I personally encountered the problem that 2015 can't compile in high
> version cuda. But I can't remember the details. We can continue to use 2015
> until we encounter problems.
>