Thank you Joe for getting the CI back into a working state. Do you have any
insights into what went wrong to get into the dysfunctional state?
On Mon, 2020-06-01 at 12:17 -0700, Joe Evans wrote:
> CAUTION: This email originated from outside of the organization. Do not click
> links or open
On Fri, 2020-05-29 at 12:15 -0400, Carin Meier wrote:
>
> Going forward - we with future releases, we can have all users build their
> own packages, just for the existing ones that are compliant on maven.
>
> On Fri, May 29, 2020 at 12:14 PM Carin Meier wrote:
>
> > Leonard,
> >
> > Is this
though this the best we can and move forward
> > towards graduation.
> >
> > Best,
> > Carin
> >
> > On Tue, May 26, 2020 at 9:46 PM Lausen, Leonard > wrote:
> >
> > > Hi Marco,
> > >
> > > thank you for explain
ependency management resolves it, it won't just say "not found" but
> provide meaningful information. Simply expecting that users will visit the
> website and figure it out is not sufficient and to me that user experience
> journey has to be addressed before we purge the rel
=gpu;;
> >
> > https://mxnet.apache.org/get_started?platform=linux=java=gpu;;
> >
> > https://mxnet.apache.org/get_started?platform=linux=clojure=gpu;;
> >
> > Thanks,
> > Carin
> >
> >
> >
> >
> > On Tue, May 26, 2020 at 1:09
On Fri, 2020-05-08 at 20:49 +, Lausen, Leonard wrote:
> I see the following two potential remedies:
>
> 1) Ask the Infra team to delete all MXNet releases on repository.apache.org
>
> 2) Ask the Infra team to delete all MXNet GPU releases on
> repository.apache.org and p
using libc, so that the
> result binary won't be affected by GPL.
>
> TQ
>
> On Tue, May 12, 2020 at 2:47 PM Lausen, Leonard
> wrote:
>
> > On Tue, 2020-05-12 at 13:05 -0700, Zach Kimberg wrote:
> > > I would also like to ask how we use libgfortran? S
On Tue, 2020-05-12 at 13:05 -0700, Zach Kimberg wrote:
> I would also like to ask how we use libgfortran? Since it is category X, we
> should not be depending on it for any of the core functionality in MXNet.
> It can only have an "optional feature" (
>
On Mon, 2020-05-11 at 13:56 -0400, Carin Meier wrote:
> Does removing the jars from both of these solutions also remove them from
> maven central?
Does Maven Central automatically mirror jars from repository.apache.org? Or were
these jars uploaded there manually?
> > 1) Ask the Infra team to
On Sun, May 10, 2020 at 8:06 AM Markus Weimer wrote:
> On Sat, May 9, 2020 at 10:50 PM Tianqi Chen wrote:
> >
> > Seems the conclusion so far is only release source through apache and
> > release the binary builds as third party(as a different community, a
> > company or individual)
>
> Yes,
them and expect them to be on the machine?
>
>
> On Fri, May 8, 2020 at 1:50 PM Lausen, Leonard
> wrote:
>
> > Hi all,
> >
> > repository.apache.org is an official Apache Software Foundation release
> > channel
> > and the MXNet project has been publishing
Hi all,
repository.apache.org is an official Apache Software Foundation release channel
and the MXNet project has been publishing convenience binaries via that channel
since quite a while. Unfortunately it appears that no-one has initiated a
license review of these convenience binaries, and
Hi Marco,
should be fixed by https://github.com/apache/incubator-mxnet/pull/18179
Some earlier steps required for the fix was to update the AMI used by CI to run
"Docker cache build & publish" to include docker-compose binary.
Best regards
Leonard
> Hi everyone,
>
> due to the recent rebuild
WRT Docker Cache: We need to add a mechanism to invalidate the cache and rebuild
the containers on a set schedule. The builds break too often and the breakage is
only detected when a contributor touches the Dockerfiles (manually causing cache
invalidation)
On Thu, 2020-03-26 at 16:06 -0400, Aaron
On opt-out: People may be unaware of opt-out would not use it. There is no
incentive to use opt-out, as the PR author doesn't pay any money for CI run.
I agree with Marco though that opt-in alone may cause usability issues, as
contributors may not be aware of how to trigger the CI.
One solution
One open source project that uses such staging workflow is cmake. Consider the
recent PR https://gitlab.kitware.com/cmake/cmake/-/merge_requests/4446
They use a robot that understands "Do: test", "Do: stage", "Do: unstage" and
"Do: merge". Nightly tests are run on all staged PRs. A similar bot may
Thanks Pedro for you work to improve the CI setup.
For Windows, let's see if fixing the deterministic failure of GPU tests with the
updated toolchain helps to fix the non-deterministic failures in the old
toolchain.
Best regards
Leonard
On Fri, 2020-02-21 at 15:37 -0800, Pedro Larroy wrote:
>
s!
>
>
>
> On 2/12/20, 11:05 AM, "Lausen, Leonard" wrote:
>
> Thank you Denis for taking up this initiative. With respect to "Introduce
> per-PR
> CI bot" and the "[mxnet-ci] run" command. Would it make sense to add
>
Thank you Denis for taking up this initiative. With respect to "Introduce
per-PR
CI bot" and the "[mxnet-ci] run" command. Would it make sense to add
"retriggering only failed pipelines" to the scope? For example users could be
asked to specify the name of the pipeline, or have "[mxnet-ci] run
Hi,
as the respective PR has been open for a while and as there has been no follow-
up to Patric's mail, I suggest to merge it once CI passes after Tao's conflict
resolution earlier today.
This gives community members time to test for regressions prior to the 1.7
release. If such were found, we
piece together the build instructions.
>
> Thanks,
>
> Markus
>
>
> [0]: https://mxnet.apache.org/get_started/ubuntu_setup
> [1]: https://github.com/apache/incubator-mxnet/tree/master/config
>
> On Tue, Feb 4, 2020 at 3:05 PM Lausen, Leonard
> wrote:
> >
this commit until upstream releases cmake build system support in a release.
In the meantime anyone is welcome to work on an equivalent patch based on the
custom build system in latest stable jemalloc.
On Tue, 2020-02-04 at 22:46 +, Lausen, Leonard wrote:
> Bisect identifies
> https://gith
Leonard
On Tue, 2020-02-04 at 22:26 +, Lausen, Leonard wrote:
> Actually below reproducer is wrong. The issue was apparently fixed on master
> recently. I'm running an automated bisect and will report the result later.
>
> On Tue, 2020-02-04 at 21:44 +0000, Lausen, Leonard wrote:
Actually below reproducer is wrong. The issue was apparently fixed on master
recently. I'm running an automated bisect and will report the result later.
On Tue, 2020-02-04 at 21:44 +, Lausen, Leonard wrote:
> Hi Chris,
>
> you previously found and fixed a OMP race condition du
Hi Chris,
you previously found and fixed a OMP race condition during fork at
https://github.com/apache/incubator-mxnet/pull/17039
This time no forks are involved. Could you run the following reproducer on
master branch:
git clone --recursive https://github.com/apache/incubator-mxnet/ mxnet
gt; > 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
I am not a lawyer, but the case for ps-lite seems can be resolved as long
> > as we can confirm these files follows Apache-2.0, as
> > https://www.apache.org/licenses/LICENSE-2.0 only requires us to
> > redistribute
> > the license and anything in the NOTICE, but we do no
As of jemalloc 5, jemalloc default build can not be used in libraries that are
dlopened. However, libmxnet.so is dlopened by Python (ctypes). To use MXNet with
jemalloc 5, users must not link to system libjemalloc.so but must rather link to
a libjemalloc compiled with special parameters to allow
Dear MXNet community,
as per recent mail on gene...@incubator.apache.org [1] there are a number of
licensing issues in MXNet 1.6rc1. Based on anecdotal evidence I believe there
has been no release so far without any licensing issues, which is a blocker to
MXNet graduating from it's incubating
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
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
Regarding visual studio 2019: It seems we currently support Visual Studio 2015?
Is there anything that Visual Studio 2015 can't do? If so, code and
documentation should also be updated based on the new minimum version.
On Tue, 2020-01-07 at 14:19 +0800, shiwen hu wrote:
> it need visual studio
Some more background:
Since a few days, CI downloads and installs a more recent cmake version in the
Windows job based on
https://github.com/leezu/mxnet/blob/230ceee5d9e0e02e58be69dad1c4ffdadbaa1bd9/ci/build_windows.py#L148-L153
This ad-hoc download and installation is not ideal and in fact a
> > >
> > > > Are these release blocker? It's very risky to make such last-minute
> > big
> > > > change after code freeze.
> > > >
> > > > Can we do this in the next release?
> > > >
> > > > Lin
> > >
t; > vote or wait until the
> > > https://github.com/apache/incubator-mxnet/issues/17105 is fixed?
> > >
> > > Thanks!
> > >
> > > Lin
> > >
> > > On Wed, Dec 18, 2019 at 12:55 AM Lausen, Leonard
> >
> > > wrote
Thanks Przemysław for managing this release and everyone who contributed to it.
Unfortunately Zechen Wang just discovered another issue with GPU Pointwise
Fusion: https://github.com/apache/incubator-mxnet/issues/17105
Thus, -1.
Unfortunately, as the nightly release pipeline was broken until
That error should be fixed by Chris's work at
https://github.com/apache/incubator-mxnet/pull/17039
It is currently expected that libmxnet.so transitively requires both libomp.so
and libgomp.so. If this is an issue, we need to build OpenBLAS from source as
part of our build scripts, because it
ink to all recent builds.
Best regards
Leonard
On Tue, 2019-12-10 at 22:03 -0800, Lin Yuan wrote:
> Is there a way to install the latest nightly package without having to
> specify exact date?
>
> Thanks,
>
> Lin
>
> On Sun, Dec 8, 2019 at 6:13 PM Lausen, Leonard
> wro
gt;
> > Is there another explanation for the call stack with the assert? Can this
> > bug be ruled out?
> >
> >
> > Here is an example of the atfork team concept with libgomp as well.
> > Probably you can check the current libgomp code itself but this explains
>
Or you can install directly by just giving the link to pip like this:
>
> pip install
> https://apache-mxnet.s3-us-west-2.amazonaws.com/dist/2019-12-07/dist/mxnet-1.6.0b20191207-py2.py3-none-manylinux1_x86_64.whl
>
> Credit goes to everyone involved (in no particular order)
>
the link to pip like this:
> >
> > pip install
> > https://apache-mxnet.s3-us-west-2.amazonaws.com/dist/2019-12-07/dist/mxnet-1.6.0b20191207-py2.py3-none-manylinux1_x86_64.whl
> >
> > Credit goes to everyone involved (in no particular order)
> > Rakesh Vasudeva
the bug being reported would be
> > prioritized and fixed. it should be fixed regardless. all the time spent by
> > some CI people trying to remove this could have simply fixed the actual bug
> > in a small fraction of the time.
> >
> >
> > On Fri, Dec 6, 2019 at 8:44 P
Chris, I'm trying to understand the situation better exactly because I think
this bug is important and I would like to address it. Therefore I asked you a
question, expecting your answer would be helpful to solve this problem.
Unfortunately it seems to me that your answer misses the point of my
ess. all the time spent by
> some CI people trying to remove this could have simply fixed the actual bug
> in a small fraction of the time.
>
>
> On Fri, Dec 6, 2019 at 8:44 PM Lausen, Leonard
> wrote:
>
> > I think it's reasonable to assume that the Intel MKLDNN te
e 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.
>
> I
Pradyun Gedam of the Pypi team helped to increase our limit just now.
> I just increased the limits as detailed below. Please be mindful of how
> frequently you make releases with such a high limit -- each release will have
> a not-insignificant impact on how much traffic PyPI has to serve.
>
>
//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 decla
10856#issuecomment-562637931
>
>
> https://github.com/apache/incubator-mxnet/issues/11417
>
> https://github.com/apache/incubator-mxnet/issues/15690
>
>
>
> On Fri, Dec 6, 2019 at 12:39 AM Lausen, Leonard
> wrote:
>
> > Is this related to https://gi
Is this related to https://github.com/apache/incubator-mxnet/issues/10856?
I unlocked that Github issue based on the Apache Code of Conduct
https://www.apache.org/foundation/policies/conduct#specific-guidelines
On Sat, 2019-11-30 at 02:47 -0800, Pedro Larroy wrote:
> (py3_venv)
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
>
s been properly addressed
> so far.
>
> -Marco
>
> Lausen, Leonard schrieb am Mi., 4. Dez. 2019,
> 04:09:
>
> > As a simple POC to test distribution, you can try installing MXNet based on
> > these 3 URLs:
> >
> > pip install --no-cache-dir
> >
>
zy consensus.
> > >
> > > -Marco
> > >
> > > Tao Lv schrieb am Di., 3. Dez. 2019, 14:31:
> > >
> > > > * For pypi, we can use mirrors.
> > > >
> > > > On Tue, Dec 3, 2019 at 9:28 PM Tao Lv wrote:
> > > >
have many users in China, I'm considering the accessibility of S3.
> > > > For pip, we can mirrors.
> > > >
> > > > On Tue, Dec 3, 2019 at 3:24 PM Lausen, Leonard <
> > > > lau...@amazon.com.invalid
> > > >
> >
.html; option to pip.
Best regards
Leonard
On Mon, 2019-12-02 at 05:42 +0000, Lausen, Leonard wrote:
> Hi MXNet Community,
>
> since more than 2 months our binary Python nightly releases published on Pypi
> are broken. The problem is that our binaries exceed Pypi's size limit.
> D
cv/blob/master/docs/build.yml#L12>;) and I know
> conda has bad reputation in response to pip installation options:
> https://github.com/conda/conda/issues/6805 <
> https://github.com/conda/conda/issues/6805>
>
> Thanks,
> Zhi
>
> > On Dec 1, 2019, at 11:14 PM, La
; Yes, 1.6 is the target release, but I don't see a world where the team can
> create new operators, and then get it pushed out to stable fast enough for the
> book writers.
>
> Sincerely,
>
> Alex Chung
>
> ________
> From: Lausen,
5:53 +, Sunderland, Kellen wrote:
> Makes sense to me to release nightlies to s3 only. Can we reduce size by
> cutting down on the SMs we release? Was the main complaint around cuda
> release sizes?
>
> On Dec 1, 2019 9:43 PM, "Lausen, Leonard" wrote:
> Hi MXNet Commun
racting a community that so far has been relying on the
> nightly builds in advance of stable.
>
> Sincerely,
>
> Alex Chung
>
>
> From: Lausen, Leonard
> Sent: Sunday, December 1, 2019 9:42 PM
> To: d...@mxnet.apache.org
&g
Hi MXNet Community,
since more than 2 months our binary Python nightly releases published on Pypi
are broken. The problem is that our binaries exceed Pypi's size limit.
Decreasing the binary size by adding compression breaks third-party libraries
loading libmxnet.so
Hi MXNet Community,
currently MXNet provides binary nightly releases of the master branch on pypi.
Do we have any binary nightly releases of the 1.6 branch available (eg on a S3
bucket)?
As the 1.6 branch and the master branch start to diverge, it would be good for
downstream projects that
Numpy team decided to wait another 4 weeks before dropping Python 3.5.
So they'll drop it in the 1.19 release.
Reference:
https://mail.python.org/pipermail/numpy-discussion/2019-October/080191.html
On Wed, 2019-11-06 at 14:36 -0800, Pedro Larroy wrote:
> In Numpy they are considering dropping
Hi Przemek,
https://github.com/apache/incubator-mxnet/issues/16049 was fixed in master
branch yesterday. Can we include it for the 1.6 release?
Thank you
Leonard
On Fri, 2019-10-25 at 14:24 +, Przemysław Trędak wrote:
> Dear MXNet Community
>
> Last night I updated 1.6.x branch to point to
Hi Marco,
do you mean retriggering PRs should be possible for all members of
https://github.com/orgs/apache/teams/mxnet-committers/members team? It doesn't
work for me unfortunately (even though I login to the CI via my Github account).
The retrigger button simply doesn't show up.
Are any
63 matches
Mail list logo
