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 attachm
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 #2
gt; Let's work together to get 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,
> > >
> > &
check if there's a way to replace a package with a notice so when a
> dependency 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 an
platform=linux&language=scala&processor=gpu&;;
> >
> > https://mxnet.apache.org/get_started?platform=linux&language=java&processor=gpu&;;
> >
> > https://mxnet.apache.org/get_started?platform=linux&language=clojure&processor=gpu&;;
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
eption for compiled-linked binaries 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
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" (
> https://www.apache.org/legal/resolved.html#op
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 dele
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, tha
o 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
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 unfort
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 o
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 is
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:
> C
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
> &qu
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 al
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 c
mxnet to
> 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
> wr
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 +0000, Lausen, Leonard wrote:
> Bisect identifies
> https:/
gards
Leonard
On Tue, 2020-02-04 at 22:26 +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, Leona
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:
> Hi Chris,
>
> you previously found and fixed a OMP race condition
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
> > > > > wr
censes, and things
> > points to them.
> >
> > 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
> > redistribu
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 dl
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 stat
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 previou
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 201
gt;
> > https://apache-mxnet.s3-us-west-2.amazonaws.com/dist/2019-12-07/dist/mxnet_cu92-1.6.0b20191207-py2.py3-none-manylinux1_x86_64.whl
> >
> >
> >
> >
> >
> >
> >
> >
> > https://apache-mxnet.s3-us-west-2.amazonaws.com/dist/2
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 wor
n Yuan wrote:
> > > >
> > > > 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?
> > > >
> > > &
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
> >
> > >
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 rece
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 int
containing a
link 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, Le
14979
On Sun, 2019-12-08 at 16:27 -0800, Pedro Larroy wrote:
> Hi Leonard.
>
> Are you saying that you have updated this library and the problems desribed
> in the related tickets are no longer present?
>
> P.
>
> On Sunday, December 8, 2019, Lausen, Leonard
>
to
> > occur or not occur.
> >
> > 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 li
.whl
>
> 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 particul
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 assert problem is really a problem, 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.
> >
>
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 que
e 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 PM Lausen, Leonard
> wrote:
>
> > I think it's reasonable to assume that
ut 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
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.
>
> R
gt; 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:
>
> > Cur
> https://github.com/apache/incubator-mxnet/issues/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
&g
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) piotr@34-215-197
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
> c
. I don't feel like that concern has 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:
> >
> > pi
we don't move forward with lazy 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
t;
> > > > As we 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.inva
.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 lim
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
>
> ____
> Fro
12-02 at 05: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 MX
is attracting 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.apa
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 https://github.com/apache/incub
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 target
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 3.
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 furthe
65 matches
Mail list logo