Hello Thomas, Am 15.04.2018 um 20:16 schrieb Thomas Zimmermann:

On 2018 M04 15, Sun 18:40:08 CEST Andreas Färber wrote:

...

I've submitted esptool 2.3.1 for inclusion in Tumbleweed:

https://build.opensuse.org/request/show/596756

esptool is a set of tools to work with Espressif ESP8266 and ESP32 microcontrollers.

Hi, it seems we have two devel projects for esptool, the other one is here: https://build.opensuse.org/package/show/CrossToolchain:xtensa/esptool

We should have a look at both of them and decide in which project should be used as devel project.

There is nothing really to decide here... I've already tried to hint you in 2016 that putting random packages into CrossToolchain:xtensa is not a helpful idea - it's not an official devel project for anything. GCC toolchains belong into devel:gcc, Python packages into devel:languages:python and other microcontroller tools into electronics or hardware. Either you want to contribute to Tumbleweed or you want to do your own thing in a hidden corner - that's _your_ decision, not mine. If you don't submit, don't complain! I checked in Factory and d:l:python for an existing package, none, after Espressif a month ago at Embedded World pointed me to their esptool for lack of upstream-ready OpenOCD. Your package is at version 1.3 (one year old), mine at 2.3.1. Yours doesn't follow the new Python Singlespec packaging conventions and is pre-python3, so it can't be submitted to Factory as is; mine got accepted into d:l:p some weeks ago and is on its way to Factory now. So you're welcome to contribute to my package in devel:languages:python, I'd happily make you co-maintainer. You could add "Obsoletes: esptool" to the python2- sub-package, but Factory is building python3-esptool only, so they should install side-by-side. https://en.opensuse.org/openSUSE:Packaging_Python_Singlespec Since 2016 I have an untested cross-xtensa-binutils sitting in my home: I replied to you on 2016-05-18 on opensuse-packaging list:

In particular I am wondering whether it might be possible to build a non-Espressif based xtensa toolchain with my pending newlib package and our binutils and gcc5/gcc6. In a quick experiment binutils succeeds to build [1] but I don't spot xtensa support in newlib - is libc one of those binary libraries [that you had mentioned]?

[1] https://build.opensuse.org/package/show/home:a_faerber:xtensa/cross-xtensa-b... But instead of working with me to figure out what standard C library to use, to turn that into a full cross-toolchain, you went on to tell me that you only need libraries for peripherals because you already use crosstool-ng ... which from my perspective is not suited for Factory, so our paths parted with - disappointingly - no common objective. Background: https://events.opensuse.org/conference/oSC16/program/proposal/918 Note that while my cross-xtensa-binutils package is not official in any way, it is a _branch_ of the official one in devel:gcc, so that I can eventually submit back and get it into Factory. My problem is, I don't know what triplet and name to use since I'm not so familiar with those architectures and implementations - can we have a binutils shared across GCC targets? Do we need a GCC for ESP32, one for ESP8266, one for any other Xtensa? I.e., how much is compiled-in, how much is just command line argument defaults? Richie doesn't like copying whatever hardware vendors are doing, asking me for better code sharing (e.g., cross-arm-none-gccX toolchains are reusing cross-arm-binutils). Espressif pointed me to https://esp-idf.readthedocs.org/ but that doesn't appear to explain details of how to build a cross-toolchain in terms of configure arguments and target triplet differences. It rather instructs to either download a binary xtensa-esp32-elf toolchain or use their crosstool-NG like you did. https://esp-idf.readthedocs.io/en/latest/get-started/linux-setup-scratch.htm... I just checked my latest newlib package (3.0.0) and I still don't spot any xtensa or esp* code in the upstream tarball: https://build.opensuse.org/package/show/devel:gcc/newlib Apparently all the xtensa code still sits downstream in patches: https://github.com/espressif/crosstool-NG/tree/xtensa-1.22.x/local-patches/n... For GCC it doesn't look as extreme: https://github.com/espressif/crosstool-NG/tree/xtensa-1.22.x/local-patches/g... Espressif only mentioned to me some errata for PSRAM access not being upstream - I'm guessing that's GCC patches 0007 and 0013 then. So we'll need to talk to Espressif, Tensilica or whomever to make them understand it's a bad idea hording downstream patches and to get that situation fixed somehow. For RISC-V we were in a similar situation with newlib being the bottleneck, and they got it resolved - so there's hope! Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org

Hi Simon, Please respect my Reply-to if you want to have your response read. Am 16.04.2018 um 03:40 schrieb Simon Lees:

On 16/04/18 07:30, Andreas Färber wrote:

...

Hello Thomas,

Am 15.04.2018 um 20:16 schrieb Thomas Zimmermann:

...

On 2018 M04 15, Sun 18:40:08 CEST Andreas Färber wrote:

...

I've submitted esptool 2.3.1 for inclusion in Tumbleweed:

https://build.opensuse.org/request/show/596756

esptool is a set of tools to work with Espressif ESP8266 and ESP32 microcontrollers.

Hi, it seems we have two devel projects for esptool, the other one is here: https://build.opensuse.org/package/show/CrossToolchain:xtensa/esptool

We should have a look at both of them and decide in which project should be used as devel project.

There is nothing really to decide here... I've already tried to hint you in 2016 that putting random packages into CrossToolchain:xtensa is not a helpful idea - it's not an official devel project for anything. GCC toolchains belong into devel:gcc, Python packages into devel:languages:python and other microcontroller tools into electronics or hardware. Either you want to contribute to Tumbleweed or you want to do your own thing in a hidden corner - that's _your_ decision, not mine.

The python part is not strictly true here, there are plenty of python packages not in devel:languages:python. Many python bindings for other libraries for example live in the devel project of that library, once you get to tools and applications they are spread out all over obs. devel:languages:python is a great spot for python libraries but many other things can have better homes elsewhere.

We're not talking about a random package that happens to have Python bindings along. It's a Python based tool, the tarball is from PyPi, and I've jumped through hoops to follow our Wiki-documented Python packaging guidelines plus Tomas' personal review nits. There is no rule that says, if there's executable Python scripts move the package elsewhere - on the contrary, it's documented how to deal with executables in detail on the Singlespec Wiki page. For a different packaging project, python-angr, I've encountered several such non-dlp packages that are making things very painful, especially if they don't even get submitted to Factory. They don't follow the same Python conventions (e.g., z3) and get reviewed by different people. Do we need a python2-esptool? I don't know. That's what our macros currently generate and at some point I guess we'll get python4- packages or whatever, it's not hardcoded by me - unlike if you start packaging without using those macros. Speaking of macros, no one appears to monitor and respond to issues filed against python-rpm-macros. Apart from technical limitations I've run into with the new macros, I find it rather ugly to hardcode that our executables in %files should use %python3_only - shouldn't that be, e.g., %executables_python_only (referring to %python_for_executables, where python3 can be overridden via PrjConf once necessary) to avoid having to touch all packages again when there's the next Python version? https://github.com/openSUSE/python-rpm-macros

Personally as this package seems to just ship binaries rather then libraries, personally I think it would be better called "esptool" unless there is already an esptool available in another language. I'd also put it in either then electronics or hardware given that by your definition this seems to be "microcontroller tools" rather then a python library.

I would also only ship the python3 version, having a python 2 and python 3 version of the same binary in the repo's doesn't really make sense. If it was a library other python2 applications may still use then maybe. However using singlespec will still make your life easier when we migrate to another python version or interpreter.

From my perspective as user, the whole python2 vs. python3 situation is still a big mess, with inconsistent availability of dependencies and several upstreams not yet ready for python3 while we are building certain bindings only for python3 already. On top I've been running into debuginfo(?) packaging issues with Python modules building native

Why didn't you do it then? Had someone else done the packaging work, I wouldn't have needed to mess with it and we wouldn't be having these late bikeshed discussions. I'm trying to do it right and had to learn the new Singlespec convention for this package (combining the two Wiki pages would certainly help newbies, and there's also 404 dlp3 links). The documentation does _not_ say it only applies to packages that might be used by Python 2 libraries! In practice most Python tools I've encountered instantiate some class that could then AFAIU just as well be used directly from another script, so there's no clear distinction between executable and module AFAIK. Again, I am not a Python developer. Did you notice that this package depends on two non-Factory packages, python-flake8-import-order and python-flake8-future-import? They're on their way to Factory now thanks to my work (you're welcome!), but so far it was not possible to build esptool without dlp. And as mentioned that is happening all over again with angr, because dependencies are either missing in dlp/Factory or were not converted to Singlespec yet or people build Python sub-packages in ways that have no correlation to how Python (singlespec) packages would actually use them. libraries, namely capstone (non-Singlespec) and bintrees (Singlespec). Regards, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org