- dev - lists.openatom.io

Re: SIG-Proposal-reST Documentation and Sphynx Auto-generation
by 万承臻 31 Dec '20

31 Dec '20

approve ---Original--- From: "Jianyu Liu"<jianyu.liu(a)huawei.com> Date: Wed, Dec 30, 2020 22:13 PM To: "dev(a)openharmony.io"<dev(a)openharmony.io>; Cc: "Gururaj Shetty"<gururaj.shetty(a)huawei.com>;"Konagalla Satya Ratna Kishore"<konagalla.kishore(a)huawei.com>; Subject: [Dev] SIG-Proposal-reST Documentation and Sphynx Auto-generation Hello,     Here’s the SIG proposal for reST Documentation and Sphynx Auto-generation. The goal of the SIG is to create documentation processes and tools, that allow community to extend, as well as system to auto-generate.   The lead maintainers of this SIG are Konagalla Satya Ratna Kishore ( konagalla.kishore(a)huawei.com ) and Gururaj Shetty ( gururaj.shetty(a)huawei.com ).   Detailed proposal is attached.       Thank you. Best Regards,   Jianyu Liu   Warsaw Research Center  

1 0

Re: SIG-Proposal-Best Open Source RTOS integration
by 万承臻 31 Dec '20

31 Dec '20

approve ---Original--- From: "Jianyu Liu"<jianyu.liu(a)huawei.com> Date: Wed, Dec 30, 2020 22:17 PM To: "dev(a)openharmony.io"<dev(a)openharmony.io>; Cc: "Amit Kucheria"<amit.kucheria.ext(a)huawei.com>; Subject: [Dev] SIG-Proposal-Best Open Source RTOS integration Hello,     Here’s the SIG proposal for Best Open Source RTOS integration. The goal of the SIG is to quickly solve the third-party chip kernel adaptation by integrating the industry's existing mature RTOS.   The lead maintainer of this SIG is Amit Kucheria ( amit.kucheria.ext(a)huawei.com ).   Detailed proposal is attached.       Thank you. Best Regards,   Jianyu Liu   Warsaw Research Center  

1 0

SIG-Proposal-Over The Air（OTA）updates
by Jianyu Liu 30 Dec '20

30 Dec '20

Hello, Here’s the SIG proposal for Over The Air（OTA）updates. The goal of the SIG is to connect cross kernel OTA devices to cloud. The lead maintainer of this SIG is Amit Kucheria ( andrei.gherzan(a)huawei.com<mailto:andrei.gherzan@huawei.com> ). Detailed proposal is attached. Thank you. Best Regards, Jianyu Liu Warsaw Research Center [w6]

1 0

subscribe
by Nagesh shamnur 10 Dec '20

10 Dec '20

Regards, Nagesh S Huawei Technologies India Pvt. Ltd. Survey No. 37, Next to EPIP Area, Kundalahalli, Whitefield Bengaluru-560066, Karnataka Tel: + 91-80-49160700 Ext H1-5A-308 Mob: 9900117960 Email: nagesh.shamnur(a)huawei.com [Company_logo] ________________________________ This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

1 0

The SIG Application for My Project
by delphi_tang 08 Dec '20

08 Dec '20

Hi, all I'm Delphi Tang (唐佐林) from HOS community, and I have an idea to simplify the HOS device application development. For the purpose, I create the open source project on Gitee named Python for HOS and I'd like to make it as a SIG project for the further development. I list some infomation about the project below, and I wish your feedback. Enjoy it! Delphi Tang (唐佐林) Project: Python for HOS Summary Python for HOS is an optional module for HOS device development which is aimed at using Python language to develop device application. At the moment, HOS device application is created via C language and the developer has no other choice, which would be a wide gap for the junior. Python is a simple and widely used language, the requirement for supporting Python on HOS device is huge. On the other hand, Python application is described as script, no need to compile to binary before deploying to device, the language feature could simplify the process of application deployment and upgrade. Motivation 1.    Only C language is supported for HOS device 2.    The process of application deployment is complicated 3.    Application upgrade from the air is difficult 4.    Make it easy to make HOS device simulator Goals 1.    Making a Python engine for HOS device 2.    Binding HOS device system API to Python type 3.    Making Python module as a choice to develop application 4.    Using the Python engine to make HOS device simulator on PC Non-Goals NA Proposal 1.    Porting the Python engine from MicroPython project and doing the necessary clipping 2.    Making Python module as a choice at the application layer, NOT the system layer 3.    Binding the system API from C type to Python type at HOS side 4.    Providing a user friendly tool to transmit Python script from PC to device 5.    Re-implement Python type system API on PC side to simulate device behavior User Stories (optional) I’m a deep learning engineer to supply CV solution for other companies currently. Somtimes, I’d like to talk about HOS from Huawei to them, the CV algorithm practitioner. Most of them show me the enthusiasm on HOS development, and they want to have a try. But, unfortunately, they are just good at using Python to create application and unfamiliar with C, the gap from Python to C makes a terrible obstacle for them to try to play with HOS, especially the HOS device. So, the idea emerged from my mind, why not make Python as a choice to develop HOS device application. Notes/Constraints/Caveats (optional) NA Risks and Mitigations NA Design Details 1. System Architecture 2. The Applilcation Level Adapter Test Plan 1. Python API Unit Test 2. Python Module Integration Test 3. Muti-Type Device Platform Test Graduation Criteria NA Upgrade / Downgrade Strategy NA Implementation History NA Drawbacks NA Alternatives NA Infrastructure Needed (optional) NA References (optional) NA

4 4

HiSilicon hi3861 build (wifiiot): PATH gotcha (and other setup)
by Christopher Tom 30 Oct '20

30 Oct '20

Hopefully can save others a little time. The PATH to the gcc executables can't end with a '/' character or you will get an error like "riscv32-unknown-elf-ld: cannot find -lgcc" (see get_lib_path in vendor/hisi/hi3861/hi3861/build/scripts/scons_env_cfg.py). eg. PATH=/gcc_riscv32/bin not PATH=/gcc_riscv32/bin/ Other requirements: the PATH to the executables must contain gcc_riscv32 and end with bin, and libgcc.a must be in the directory ../lib/gcc/riscv32-unknown-elf/<gcc version number>/ relative to the executables directory. (ie. must be a relatively standard directory structure). Might be relevant for those thinking of putting the executables in $HOME/bin. The scons_env_param_check in scons_utils.py performs the same check as get_lib_path and supports ending with '/' so it may be fair to ask HiSilicon to call this function instead. I also needed to install the scons, pycrypto, and ecdsa packages for the HiSilicon hi3861 build (available through pip).

2 1

Problem accessing repository through openharmony.gitee.com/openharmony/
by Christopher Tom 26 Oct '20

26 Oct '20

For the past few days I haven't been able to access https://openharmony.gitee.com/openharmony/ either through the website or repo/git. I can connect to the website at https://gitee.com/openharmony/ and after changing the 3rd line of .repo/manifests/default.xml from <remote fetch="https://openharmony.gitee.com/openharmony/" name="origin" review="https://openharmony.gitee.com/openharmony/"/> to <remote fetch="https://gitee.com/openharmony/" name="origin" review="https://openharmony.gitee.com/openharmony/"/> I can sync with repo (and faster than openharmony.gitee.com/openharmony/ was). But the manifest seems to still be pointing at openharmony.gitee.com/openharmony/, is anyone else having problems accessing the repository? Am I doing something wrong?

1 0

OpenArkCompiler仓库呢？之前开源的仓库怎么不见了
by Netroby 14 Sep '20

14 Sep '20

老的仓库现在看不到了 https://gitee.com/harmonyos/OpenArkCompiler/commit/d14c022feada8ce6d8c45792… 现在访问，就提示没有权限你们开源的，还可以收回？这么玩？ Appreciate your time. ---------------------------- Netroby

2 1

来了来了，终于订阅成功了。恭喜鸿蒙开源
by Netroby 14 Sep '20

14 Sep '20

来了来了，终于订阅成功了。恭喜鸿蒙开源由于一直没搞定邮件收取，所以注册验证没成功。一直是没订阅成功，看起来终于搞定了。大家好。恭喜鸿蒙开源一起加油，期待鸿蒙越来越好 Appreciate your time. ---------------------------- Netroby

1 0

帮助
by 叶在林 14 Sep '20

14 Sep '20

帮助

1 0

Welcome to the "dev" mailing list!
by ]]如奇是才本♐ 12 Sep '20

12 Sep '20

Welcome to the "dev" mailing list! To post to this list, send your email to:   dev(a)openharmony.io You can unsubscribe or make adjustments to your options via email by sending a message to:   dev-request(a)openharmony.io with the word 'help' in the subject or body (don't include the quotes), and you will get back a message with instructions.  You will need your password to change your options, but for security purposes, this password is not included here.  If you have forgotten your password you will need to reset it via the web UI.

1 0

回复：
by 万承臻 11 Sep '20

11 Sep '20

Mouri Naruto，您好！谢谢您对OpenHarmony社区的关注，对于您提出的几个问题，答复如下。如您有其他License相关的疑问，也可以同时联系邮箱law(a)openatom.org. wanchengzhen https://openharmony.gitee.com/wanchengzhen ------------------ 原始邮件 ------------------ 发件人: "Mouri Naruto" <Mouri_Naruto(a)outlook.com>; 发送时间: 2020年9月10日(星期四) 晚上10:16 收件人: "dev(a)openharmony.io"<dev(a)openharmony.io>; 主题: [Dev] 我下载源代码的地址：http://tools.harmonyos.com/mirrors/os/1.0/code-1.0.tar.gz   我好好的看了下里面的源代码，对鸿蒙引用的第三方库的许可表示担忧。   首先鸿蒙使用了 Linux 内核（third_party\Linux_Kernel）的部分实现，该项目采用 GPL v2 许可，那么关于设备开发者定制了鸿蒙的内核，会有必须要求开源的风险。答复：OpenHarmony的third_party\Linux_Kernel库包含两部分内容，1是jffs2模块，2是scripts模块。（1）jffs2模块是为了兼容jffs2而引入，jffs2采用GPLV2+EXCEPTION的许可，并非纯粹的GPLV2，您可以通过如下链接查看其许可证：https://gitee.com/openharmony/third_party_Linux_Kernel/blob/master/fs/jffs2/LICENCE OpenHarmony对jffs2模块的编译及链接使用方式满足其EXCEPTION的规定，故对该模块的使用，不会导致项目其它代码受到GPLV2的影响。（2）scripts模块是独立的编译工具，仅在编译过程中用来生成 conf和mconf工具，代码不会编译打包到kernel_liteos_a内核中。因此kernel_liteos_a内核不受GPL影响。其次鸿蒙在用 Linux 内核部分实现的情况下还用了 OpenSSL 的实现（third_party\openssl），而 OpenSSL 的开源许可证严格来说不兼容 GPL 系列开源许可证。（参阅：https://www.gnu.org/licenses/license-list.html#OpenSSL）答复：根据对您第一个问题的答复可知，Linux内核部分实现的使用并不会导致OpenHarmony内核受到GPL的影响，故不影响OpenHarmony对OpenSSL的使用，不存在许可证兼容性问题。还有 freetype 库（third_party\freetype）的许可可能也需要担心（这个库采用的双许可，要么 GPLv2，要么就是与 GPLv2 互斥的 BSD 风格许可），但由于鸿蒙的代码树第三方库包含了 Linux 的代码，于是这方面也没法确定。答复：根据对您的第一个问题的答复可知，OpenHarmony对Linux内核部分实现的使用并不会导致OpenHarmony内核受到GPL的影响，故不影响OpenHarmony选择BSD license使用free type库。  还有 hi35xx 芯片支持的代码里引用了 ffmpeg （vendor\hisi\hi35xx\middleware\source\third_party\ffmpeg\ffmpeg-y）这个最起码需要遵守 LGPL v2.1 的库。答复：OpenHarmony采用动态链接方式使用LGPL许可证下的ffmpeg库，不会导致该项目其它代码受到LGPL许可证的影响。  我希望社区能够在这方面做出解答，期待回复。   总之希望鸿蒙项目顺利。   Best Regards, Kenji Mouri (https://github.com/MouriNaruto)    

1 0

done
by 苦叶子 11 Sep '20

11 Sep '20

1 0

关于鸿蒙 OS 开源许可的担忧
by Mouri Naruto 10 Sep '20

10 Sep '20

我下载源代码的地址：http://tools.harmonyos.com/mirrors/os/1.0/code-1.0.tar.gz 我好好的看了下里面的源代码，对鸿蒙引用的第三方库的许可表示担忧。首先鸿蒙使用了 Linux 内核（third_party\Linux_Kernel）的部分实现，该项目采用 GPL v2 许可，那么关于设备开发者定制了鸿蒙的内核，会有必须要求开源的风险。其次鸿蒙在用 Linux 内核部分实现的情况下还用了 OpenSSL 的实现（third_party\openssl），而 OpenSSL 的开源许可证严格来说不兼容 GPL 系列开源许可证。（参阅：https://www.gnu.org/licenses/license-list.html#OpenSSL）还有 freetype 库（third_party\freetype）的许可可能也需要担心（这个库采用的双许可，要么 GPLv2，要么就是与 GPLv2 互斥的 BSD 风格许可），但由于鸿蒙的代码树第三方库包含了 Linux 的代码，于是这方面也没法确定。还有 hi35xx 芯片支持的代码里引用了 ffmpeg （vendor\hisi\hi35xx\middleware\source\third_party\ffmpeg\ffmpeg-y）这个最起码需要遵守 LGPL v2.1 的库。我希望社区能够在这方面做出解答，期待回复。总之希望鸿蒙项目顺利。 Best Regards, Kenji Mouri (https://github.com/MouriNaruto)

1 0

(no subject)
by Yangni (A) 10 Sep '20

10 Sep '20

杨妮消费者资料部华为技术有限公司 Tel : +86 18709251268 Email : neen.yang(a)huawei.com [cid:image001.png@01D68786.D2726C90] This e-mail and its attachments contain confidential information from HUAWEI, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

1 0

订阅OpenHarmony邮件列表
by Liuguo (A) 01 Sep '20

01 Sep '20

1 0