Re: [VOTE] Release Apache Doris 0.9.0-incubating-rc01
Hi, Does anyone help us to check and vote？ Now we got two +1(binding). If needed we will cancel and call for next VOTE after fixed all issues which Willem and Justin mentioned. Best Regards, Reed On 2018/12/29 上午10:36， "Li,De(BDG)" wrote: >Hi Dave, > >I got it, thank you very much. Have a good trip. > >Best Regards, >Reed > >On 2018/12/28 下午10:49， "Dave Meikle" wrote: > >>Hi Reed, >> >>I am traveling just now so away from the desktop that I tested the build >>on. I setup a clean virtual machine with Ubuntu 18.04 and tried from >>scratch, resulting in a perfect build. So must be something funky with >>my >>configuration back at base - it's been upgraded a few times, so sorry for >>the hassle. >> >>(NOTE: I tried to build on a remote Ubuntu 18.10 at first getting a >>different error but it made sense due to the 3rd-party LLVM fails due to >>ustat depreciation in glibc). >> >>So +1 (binding) to the release. >> >>Cheers, >>Dave >> >>On Thu, 27 Dec 2018 at 12:13, Li,De(BDG) wrote: >> >>> Hi Dave, >>> >>> Thanks for your reply. >>> >>> The files of flat_map.h and json_to_pb.h are come from brpc, which >>>should >>> be installed in thirdparty/installed/include. >>> >>> >>> It seems brpc is not been compiled and installed successfully. >>> >>> Could you remove brpc and retry build as following command ? It will >>>help >>> us to know what happed. >>> >>> >>> $ cd >>> >>>/home/dmeikle/Development/Apache/incubator/release-review/apache-doris-0 >>>. >>>9. >>> 0.rc01-incubating-src >>> $ rm -f thirdparty/installed/lib/librdkafka.a >>> $ rm -fr thirdparty/src/brpc-0.9.0* >>> $ sh build.sh >>> >>> Regards, >>> Reed >>> >>> On 2018/12/27 下午6:33， "David Meikle" wrote: >>> >>> >Hi Reed, >>> > >>> >> On 27 Dec 2018, at 03:00, Li,De(BDG) wrote: >>> >> >>> >> Thanks to David, could you provide the detail for failure, actually, >>>we >>> >> expect building is OK if following tools installed on Ubuntu. >>> >> >>> >> GCC 5.3.1+, Oracle JDK 1.8+, Python 2.7+, Apache Maven 3.5+, CMake >>> >>3.4.3+ >>> >> >>> >> >>> >> Best Regards, >>> >> Reed >>> > >>> > >>> > >>> >I get the following errors: >>> > >>> >-- CLANG_COMPATIBLE_FLAGS: -I/usr/include/c++/7 >>> >-I/usr/include/x86_64-linux-gnu/c++/7 -I/usr/include/c++/7/backward >>> >-I/usr/lib/gcc/x86_64-linux-gnu/7/include -I/usr/local/include >>> >-I/usr/lib/gcc/x86_64-linux-gnu/7/include-fixed >>> >-I/usr/include/x86_64-linux-gnu -I/usr/include >>> >-- Configuring done >>> >-- Generating done >>> >-- Build files have been written to: >>> /home/dmeikle/Development/Apache/incubator/release-review/apache-doris- 0 .9 >>> >.0.rc01-incubating-src/be/build >>> >[ 1%] Built target gen_ir_descriptions >>> >[ 2%] Built target Udf >>> >[ 3%] Built target Common >>> >[ 14%] Built target Util >>> >[ 23%] Built target Exprs >>> >[ 32%] Built target Gutil >>> >[ 46%] Built target DorisGen >>> >[ 48%] Built target Agent >>> >[ 48%] Building CXX object >>> >src/http/CMakeFiles/Webserver.dir/ev_http_server.cpp.o >>> >[ 49%] Building CXX object >>> >src/olap/CMakeFiles/Olap.dir/olap_header_manager.cpp.o >>> >In file included from >>> /home/dmeikle/Development/Apache/incubator/release-review/apache-doris- 0 .9 >>> >.0.rc01-incubating-src/be/src/http/ev_http_server.cpp:31:0: >>> /home/dmeikle/Development/Apache/incubator/release-review/apache-doris- 0 .9 >>> >.0.rc01-incubating-src/be/src/service/brpc.h:50:10: fatal error: >>> >butil/containers/flat_map.h: No such file or directory >>> > #include >>> > ^ >>> >compilation terminated. >>> >src/http/CMakeFiles/Webserver.dir/build.make:350: recipe for target >>> >'src/http/CMakeFiles/Webserver.dir/ev_http_server.cpp.o' failed >>> >make[2]: *** [src/http/CMakeFiles/Webserver.dir/ev_http_server.cpp.o] >>> >Error 1 >>> >CMakeFiles/Makefile2:581: recipe for target >>> >'src/http/CMakeFiles/Webserver.dir/all' failed >>> >make[1]: *** [src/http/CMakeFiles/Webserver.dir/all] Error 2 >>> >make[1]: *** Waiting for unfinished jobs >>> >[ 49%] Building CXX object >>>src/olap/CMakeFiles/Olap.dir/olap_meta.cpp.o >>> /home/dmeikle/Development/Apache/incubator/release-review/apache-doris- 0 .9 >>> >.0.rc01-incubating-src/be/src/olap/olap_header_manager.cpp:30:10: >>>fatal >>> >error: json2pb/json_to_pb.h: No such file or directory >>> > #include "json2pb/json_to_pb.h" >>> > ^~ >>> >compilation terminated. >>> >src/olap/CMakeFiles/Olap.dir/build.make:806: recipe for target >>> >'src/olap/CMakeFiles/Olap.dir/olap_header_manager.cpp.o' failed >>> >make[2]: *** [src/olap/CMakeFiles/Olap.dir/olap_header_manager.cpp.o] >>> >Error 1 >>> >make[2]: *** Waiting for unfinished jobs >>> >CMakeFiles/Makefile2:471: recipe for target >>> >'src/olap/CMakeFiles/Olap.dir/all' failed >>> >make[1]: *** [src/olap/CMakeFiles/Olap.dir/all] Error 2 >>> >Makefile:129: recipe for target 'all' failed >>> >make: *** [all] Error 2 >>> > >>> >Cheers, >>> >Dave
Re: [VOTE] Release Apache MXNet (incubating) version 1.4.0.rc0
For TensorRT I'd recommend we just remove the third party folder from onnx. I hope this would resolve most dependency license issues. We do not use any of the code in that folder. On Wed, Jan 9, 2019, 9:08 PM Justin Mclean Hi, > > I assume you realise this would be a lot easier if the dependancies were > not copied into the git tree (as mentioned in the link you posted) , but I > assume there a reason for doing this that I’m not aware of. > > Thanks, > Justin > - > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
Re: [VOTE] Release Apache MXNet (incubating) version 1.4.0.rc0
Hi, I assume you realise this would be a lot easier if the dependancies were not copied into the git tree (as mentioned in the link you posted) , but I assume there a reason for doing this that I’m not aware of. Thanks, Justin - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache MXNet (incubating) version 1.4.0.rc0
Hi, > As for your comments: > - 3rdparty/onnx-tensorrt itself has four different git submodules inside it > which is the cause of the number of different licenses. I added the main > license of each repo to our license file. Which probably misses the point I was trying to make I think? It's not the main license you need to list but the licenses of all pieces of software in that bundle. There's 3rd party software bundled the release that isn’t listed in the LICENSE. > For the CC-BY-SA content, we raised the issue on legal-discuss ( > http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201805.mbox/%3CCAK1xzDdw_5-znx=y2wxvlwq_nk4ajmtfuqhp3dhr94wumqd...@mail.gmail.com%3E) > and it seems to be somewhat acceptable for documentation similarly to how > it is allowed for media. This has come up again recently and "it's tough one" [1] (See option 3). I think it would be safer to remove it from the release or replace it with a file with a pointer to the documentation. Thanks, Justin 1. https://lists.apache.org/thread.html/0f0e6cced863755b27e2bfe9e74d6abc922ba4e1912062132272833f@%3Clegal-discuss.apache.org%3E - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: [VOTE] Release Apache MXNet (incubating) version 1.4.0.rc0
Hi Justin, I went through the license file to remove all licenses that no longer exist and tried to add any missing licenses I could find. I also tried to prune our rat-excludes for files that should be checked such as .js ones. As for your comments: - 3rdparty/onnx-tensorrt itself has four different git submodules inside it which is the cause of the number of different licenses. I added the main license of each repo to our license file. - The src/operator files that you mention all have individual licenses that are located inside the file header (but are different than the apache license) For the CC-BY-SA content, we raised the issue on legal-discuss ( http://mail-archives.apache.org/mod_mbox/www-legal-discuss/201805.mbox/%3CCAK1xzDdw_5-znx=y2wxvlwq_nk4ajmtfuqhp3dhr94wumqd...@mail.gmail.com%3E) and it seems to be somewhat acceptable for documentation similarly to how it is allowed for media. Can you help verify whether we have any release blocking problems that we still need to address in our license. Thanks, Zach On 2019/01/07 09:24:07, Hagay Lupesko wrote: > Thanks for clarifying Justin.> > > On Mon, Jan 7, 2019 at 1:06 AM Justin Mclean > > wrote:> > > > Hi,> > >> > > > Good call. I will work with my colleagues in Amazon to try and help with> > > > this.> > >> > > Great if you need any help just ask.> > >> > > > I'm not sure what is the best approach with 3P code issues though: you> > > call> > > > out 3rdparty/onnx-tensorrt as having a mix of license types and having> > > > other issues. However, this is part of another repo, integrated into> > > MXNet> > > > as a git submodule (https://github.com/onnx/onnx-tensorrt.git).> > > > Is it necessary to "fix" licensing of 3P packages as well? I think this> > > > will be very difficult…> > >> > > Fixing downstream is good but not required, it all comes down to the> > > guiding principle [1]. You need to look inside and 3rd party code to see> > > what it contains and list all licenses that are bundled.> > >> > > A simple example is jQuery which is MIT licensed but includes MIT licensed> > > Sizzle so both of these need to mention in the LICENSE file.> > >> > > Thanks,> > > Justin> > >> > > 1. http://www.apache.org/dev/licensing-howto.html#guiding-principle> > > -> > > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org> > > For additional commands, e-mail: general-h...@incubator.apache.org> > >> > >> >
Re: Using GPLv3 in the build?
Ok ... so that was quick, I looked up the guy doing most of the commits and asked him. Here his reply: "As with majority of the compilers (gcc, clang, etc), Kaitai Struct compiler does not make any special takes on the output. If you own the input, you totally own the output, and free to specify your own conditions on its licensing. If you use something from our formats repo — http://formats.kaitai.io/ — it's generally safe to assume that output license equals to KSY input file license (of course, I'm not a lawyer, I can't provide legal advice, blah, blah, etc, the regular disclaimer you've probably seen tons of times already). As most of formats in that repo are CC0-licensed, basically it's public domain, you can do whatever you want with them." So if we input a definition which we write as part of the PLC4X project and which is naturally Apache 2.0, so the output would be Apache 2.0 too ... so that sounds good. Unfortunately he also told me that even if the parsing code was already good, the serialization code is in very early stages and would probably not be up to our expectations :-( So we probably shouldn't base our project on that ... but thanks for the fast response Richard :-) Chris Am 09.01.19, 16:26 schrieb "Richard Eckart de Castilho" : Hi Chris, This seems to be a similar situation as for tools such as automake (which I believe is used by several Apache projects). To the best of my knowledge (I am not a lawyer), the the copyleft clause of the GPLv3 does not impose and restrictions on the output of tools under the license. E.g. if you have a text editor published under GPLv3, the copyleft doesn't affect to the texts you have written with it. In the case of a code generator (like a compiler or like automake) you'd best check if the generated output contains anything that is licensed under the problematic license. For example, the compiler might generate a boot loader block into every application and this boot loader block might be under a copyleft license - that could be a problem. For this reason, e.g. automake has special exceptions to the GPLv3: https://www.gnu.org/licenses/exceptions.en.html If the compiler you want to use does not mention any such exceptions as part of their FAQ/license description, maybe best enter into contact with the developers and ask them. Cheers, -- Richard > On 9. Jan 2019, at 15:53, Christofer Dutz wrote: > > Hi all, > > I just double checked the text on the GPLv3 compatibility. > Stupid thing is the problem I’m having isn’t really covered by that [1]. > > The case I’m currently having is that there is a toolset called Kaitai [2], which sounds interesting for the Apache PLC4X project. > In general you define a data-format and have it generate model, serializer and parser in multiple languages (Similar to Thrift or Protobuf, but with a focus on the transport data-format and not the model). > > This consists of a compiler and a runtime. > > The compiler generates code from sources which use the runtime libraries. > The runtime libraries are Apache 2.0 and MIT licensed, so this would be ok > The compiler however is GPLv3 … > > Now we would not be bunding the compiler and the users wouldn’t need to use it when using PLC4X as it’s only needed in the code-generation phase of the build. > > So before I throw the idea over board, I just wanted to double-check this special case. > > Chris > > > > [1] https://www.apache.org/licenses/GPL-compatibility.html > [2] https://kaitai.io/ > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Re: Establishing an ASF project for training
Gris, sorry for the late reply. I'm only now catching up on emails after the holidays. Thanks for your support! The next steps are for me (in the next two weeks) to write an official proposal. I'll then start a [DISCUSS] Thread and will gather interested parties. We can take it from there. I believe that for the moment there's nothing to do. Regarding the technical discussion: I've intentionally avoided that for now as I wanted to focus on the topic itself before hopefully diving into details later. No matter which technology we chose someone will be unhappy with it but I believe this to be no different than any other "technical" project. Cheers, Lars > > > I really like the idea! > > We, from time to time, also do trainings and workshops with Apache > projects and it would really help to have a better basis. > > And I agree for you that you don’t get payed for *having* slides but for > the show as well as for the insights you get from a good instructor or a > person with background knowledge, so I also see no big concerns in sharing. > > > > One thing that came to my mind was to use some kind of "code based" > generation for the slides, notebooks, brochures like Latex, Markdown, > Asciidoc or else... > > I would strongly advise against using code base generators as the only way > to consume these materials. The reason why is that this is a entry barrier > for folks wanting to contribute to community and project management and who > are not technical. This will also put a huge adoption barrier since we'd > need to assume people using this materials are versed in this technology. > That been said. We could use the code based generator for folks wanting to > do more with what's produced but also publishing official brochures and > content that people can just "grab and go". > > This is in alignment with having a more active attitude towards > recognizing non-code contributions. > > > I would not like to force users to use proprietary tools (PPT) to use > the material. > > And furthermore, this would allow us to have some kind of style files > which could be personalized for corps and which they could keep for each > release. > > Another aspect is that it makes the whole versioning way easier as it is > code and one can see all changes and stuff which is impossible for "binary" > formats. > > I also think we have enough people here that would be able to easily do > an automated resources documentation, so that we could always offer > "compiled" material in pdf in default style or the possibility to do a > custom build with custom styles. > > > > And I think that the incubator would be a good place to start to see if > here, as in all ASF projects, a community can be established and continuous > effort is spend on the project. This would reduce the risk of a "zombie" > project which is probably only really powered by one organization and lives > and dies on their will. > > > > Julian > > > > Am 17.12.18, 14:37 schrieb "Rich Bowen" : > > > > It's worth mentioning that there's a conversation going right now > over on > > the members@ list about creating a "central services" kind of > entity. That > > discussion is primarily focused on design/graphic kind of stuff, but > > training/documentation/presentations are similar in concept, if not > in > > content, and I'm definitely in favor of such an entity existing. > > > > Your anticipated question "Isn't the ASF all about code, now you > want to do > > PPT!" is very insightful. The ASF exists to provide services to > projects, > > and this is an unfilled need that many/most of our projects have. > There is > > precedent - we have an infrastructure organization, a conferences > entity, a > > marketing group, legal, brand, and so on, that provide non-code > services to > > projects. Recognizing contributors for non-code contributions is > *critical* > > for the survival of our projects, and of the Foundation as a whole, > and we > > tend to be very poor at it. > > > > So, suffice it to say, a huge +1 to this concept, although I'm not > sure > > where it should live - whether under ComDev (as you suggest) or as a > > top-level entity. I think the latter makes a little more sense. > While this > > is indeed a function of community development/growth/education, it's > also > > sufficiently different that it may need to be independent. > > > > What are next steps? I don't *think* this is something that should go > > through the Incubator. It's not a Thing Like That. Perhaps a > proposal to > > the Board to create a top-level thing? I'll put a pointer to this > thread > > into that other thread (referenced above), and apologies to those of > you > > who are not ASF Members and cannot see that thread. > > > > > > On Mon, Dec 17, 2018 at 8:23 AM Lars Francke > wrote: > > > > > Hi, > > > > > > I'd like to start a discussion around establishing a project (or >
Re: Using GPLv3 in the build?
Hi Chris, This seems to be a similar situation as for tools such as automake (which I believe is used by several Apache projects). To the best of my knowledge (I am not a lawyer), the the copyleft clause of the GPLv3 does not impose and restrictions on the output of tools under the license. E.g. if you have a text editor published under GPLv3, the copyleft doesn't affect to the texts you have written with it. In the case of a code generator (like a compiler or like automake) you'd best check if the generated output contains anything that is licensed under the problematic license. For example, the compiler might generate a boot loader block into every application and this boot loader block might be under a copyleft license - that could be a problem. For this reason, e.g. automake has special exceptions to the GPLv3: https://www.gnu.org/licenses/exceptions.en.html If the compiler you want to use does not mention any such exceptions as part of their FAQ/license description, maybe best enter into contact with the developers and ask them. Cheers, -- Richard > On 9. Jan 2019, at 15:53, Christofer Dutz wrote: > > Hi all, > > I just double checked the text on the GPLv3 compatibility. > Stupid thing is the problem I’m having isn’t really covered by that [1]. > > The case I’m currently having is that there is a toolset called Kaitai [2], > which sounds interesting for the Apache PLC4X project. > In general you define a data-format and have it generate model, serializer > and parser in multiple languages (Similar to Thrift or Protobuf, but with a > focus on the transport data-format and not the model). > > This consists of a compiler and a runtime. > > The compiler generates code from sources which use the runtime libraries. > The runtime libraries are Apache 2.0 and MIT licensed, so this would be ok > The compiler however is GPLv3 … > > Now we would not be bunding the compiler and the users wouldn’t need to use > it when using PLC4X as it’s only needed in the code-generation phase of the > build. > > So before I throw the idea over board, I just wanted to double-check this > special case. > > Chris > > > > [1] https://www.apache.org/licenses/GPL-compatibility.html > [2] https://kaitai.io/ > - To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org For additional commands, e-mail: general-h...@incubator.apache.org
Using GPLv3 in the build?
Hi all, I just double checked the text on the GPLv3 compatibility. Stupid thing is the problem I’m having isn’t really covered by that [1]. The case I’m currently having is that there is a toolset called Kaitai [2], which sounds interesting for the Apache PLC4X project. In general you define a data-format and have it generate model, serializer and parser in multiple languages (Similar to Thrift or Protobuf, but with a focus on the transport data-format and not the model). This consists of a compiler and a runtime. The compiler generates code from sources which use the runtime libraries. The runtime libraries are Apache 2.0 and MIT licensed, so this would be ok The compiler however is GPLv3 … Now we would not be bunding the compiler and the users wouldn’t need to use it when using PLC4X as it’s only needed in the code-generation phase of the build. So before I throw the idea over board, I just wanted to double-check this special case. Chris [1] https://www.apache.org/licenses/GPL-compatibility.html [2] https://kaitai.io/
