https://bugzilla.novell.com/show_bug.cgi?id=880146 https://bugzilla.novell.com/show_bug.cgi?id=880146#c2 --- Comment #2 from Stanislav Brabec 2014-05-27 23:35:21 CEST --- Yes, devel:tools:compiler is another option. sigrok can fit to hardware or a dedicated project in driver: sdcc could be aggregated there. I have another candidate that can be hosted with sdcc: intelhex (already packaged), and one that would depend on sdcc: DPF-AX (digital photo frame firmware for use as a remote display; not yet packaged) Having a dedicated repository for sdcc could have a possible future benefit: Any project that requires sdcc can inherit the whole project without need to aggregate or link. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=880146 https://bugzilla.novell.com/show_bug.cgi?id=880146#c4 --- Comment #4 from Thomas Zimmermann 2014-05-28 09:29:12 UTC --- If we agree that sdcc is in a good shape, i think that we can get it into factory soon and then we don't need a separate repository any more. And then devel:tools:compiler would fit best in my opinion. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=880146 https://bugzilla.novell.com/show_bug.cgi?id=880146#c6 Stanislav Brabec changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |NEW InfoProvider|sbrabec@suse.com | --- Comment #6 from Stanislav Brabec 2014-05-28 16:30:10 CEST --- Reinhard Max: Your suggestion also looks well. Should we have project like electronics or (for example) hardware:design? We already have: arduino in CrossToolchain:avr and many homes avr-gcc in CrossToolchain:avr and many homes avrdude in CrossToolchain:avr and many homes cross-msp430-jtag in CrossToolchain:msp430 openocd in hardware (and Factory) and many homes pcb in science (and Factory) and many homes geda* in science (and Factory) and many homes ems-flasher in hardware and one home *ftdi* in several homes (well, it can do also magic with serial cable, so it is not clearl whether hardware or new project) ... and something in perl project devel:languages:perl:CPAN-* The hardware project has a description: This repository contains tools for using, configuring or fine tuning various types of hardware, both external and internal. We can say, that hardware repository is intended for using this hardware on Linux, and the new repository will be intended for general development of such hardware. The new project can have a description: This repository contains tools for hardware design and development. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=880146 https://bugzilla.novell.com/show_bug.cgi?id=880146#c8 --- Comment #8 from Wojciech Kazubski 2014-05-28 15:22:17 UTC --- (In reply to comment #6)

Should we have project like electronics or (for example) hardware:design?

Project electronics already exists and contains 11 packages, 2 of them broken. The last openSUSE release there is 11.4 and also old Centos and RHEL. Wojciech Kazubski -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=880146 https://bugzilla.novell.com/show_bug.cgi?id=880146#c10 --- Comment #10 from Reinhard Max 2014-05-28 17:54:51 CEST --- (In reply to comment #6)

Should we have project like electronics or (for example) hardware:design?

Yes, I was thinking along these lines, but still search for a name that fits both, the hardware and the firmware aspects that we want to cover with the new project. If I had to pick among these two names, I'd prefer electronics, because hardware:design sounds too speciffic and doing electronics these days almost inevitably means that some sort of programmable device and firmware are involved.

We can say, that hardware repository is intended for using this hardware on Linux, and the new repository will be intended for general development of such hardware.

Yes, but the new repository shall include firmware and not be limited to "such" hardware (in the sense of computer periphery).

The new project can have a description:

This repository contains tools for hardware design and development.

How about "This repository contains tools for developing electronic circuits and firmware for microcontrollers" ? (In reply to comment #8)

Project electronics already exists and contains 11 packages, 2 of them broken. The last openSUSE release there is 11.4 and also old Centos and RHEL.

Seems to have quite some overlap with CrossToolchain:avr already. I'd say let's revive this for the new purpose, but shall it be flat or is it better to have subprojects for the different µC architectures and other tools? e.g.: electronics:avr electronics:msp430 ... electronics:tools (logic analyzers, oscilloscopes, target-independent programmers, JTAG) electronics:cad -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=880146 https://bugzilla.novell.com/show_bug.cgi?id=880146#c12 --- Comment #12 from Torsten Duwe 2014-05-28 16:42:16 UTC --- (In reply to comment #10)

How about "This repository contains tools for developing electronic circuits and firmware for microcontrollers" ?

Sounds good. Where shall we draw the line, between RockBox and an android distribution? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=880146 https://bugzilla.novell.com/show_bug.cgi?id=880146#c14 --- Comment #14 from Thomas Zimmermann 2014-05-30 11:38:10 UTC --- (In reply to comment #7)

May I add

kicad, maybe fritzing (like geda)

urjtag (like OpenOCD or flashers)

Haven't checked whether there are packages yet.

kicad is in science and Factory fritzing is in Education and Factory urjtag exists in 2 homes I would also add sigrok + all dependencies (but the released versions not the git snapshots) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=880146 https://bugzilla.novell.com/show_bug.cgi?id=880146#c16 --- Comment #16 from Adrian Schröter 2014-06-02 07:00:41 UTC --- sbrabec got added to electronics project now. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=880146 https://bugzilla.novell.com/show_bug.cgi?id=880146#c18 --- Comment #18 from Thomas Zimmermann 2014-06-02 19:14:20 UTC --- @Reinhard Max I've synced my sigrok packages (which were originally from you) again with yours. My changes are mainly that I've changed to released versions. Which version would you prefer for electronics? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=880146 https://bugzilla.novell.com/show_bug.cgi?id=880146#c20 --- Comment #20 from Torsten Duwe 2014-06-03 08:48:33 UTC --- I need some GUI API features for my PWM decoder which were not available in the last release, hence the updated versions in my home. Also note that it needs a current libusb (post 13.1): -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=880146 https://bugzilla.novell.com/show_bug.cgi?id=880146#c22 --- Comment #22 from Thomas Zimmermann 2014-06-03 08:56:47 UTC --- I was also only interested in support for the Cypress FX2. They are releasing new version about every half a year. As I'm not interested in support for new devices this is frequent enough for me. But if Torsten needs newer version we should stick to the snapshots (but update the versions in the spec file) I've also packages libserialport. For libusb: I don't know why they've put that version in there configure.ac, i've reduced that dependency to 1.0.9 and it still compiles. (Haven't tested it yet) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=880146 https://bugzilla.novell.com/show_bug.cgi?id=880146#c24 --- Comment #24 from Stanislav Brabec 2014-06-03 18:23:15 CEST --- I added all people from this discussion as maintainers of this project. Feel free to move and add packages there and add more interested people. Build repositories were updated to the standard set. If you need more repositories, you can add them.

Maybe the upstream developers just request the version they have themselves, because they don't test against older versions anymore.

There are subtle bugs in the code that may break particular hardware or use. It still compiles but it does not work properly. By the way, there is at least one package that works only with libusb0. The problem is deeply in the way how libusb handles incomplete transfers: bug 559697 comment 23 -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

electronics:tools (logic analyzers, oscilloscopes, target-independent programmers, JTAG) electronics:cad I think we can use subprojects for crosstoolchains, but all generic software must be in one repository. Many small repositories look like a hell for end user, and sometimes it's really difficult to choose which subproject id better to use for package. For example we have 500+ different packages in science

https://bugzilla.novell.com/show_bug.cgi?id=880146 https://bugzilla.novell.com/show_bug.cgi?id=880146#c26 --- Comment #26 from Dmitry Roshchin 2014-06-03 22:16:13 UTC --- 1. Project destination It's very important to decide would be electronics project just devel project for Factory, or it must be ready for end user (many people want to use latest stable applied software). 2. Project structure project without any problems for maintainers. 3. Moving packages I can move some packages from Science project: electronics-menu geda-gaf geda-xgsch2pcb gerbv gnucap gspiceui gtkwave ? iverilog ? kicad kicad-doc kicad-library ng-spice-rework (must be renamed to ngspice) pcb qucs 4. Unstable versions Electronics project must contain only stable releases, but in some cases we can provide unstable versions. For example I want to use devel version of kicad (there are too much difference between stable and devel branches). So we need to choose the best way. * all unstable packages in one repository (electronics:unstable) * separate repositories (electronics:unstable:kicad) * no unstable versions totally -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=880146 https://bugzilla.novell.com/show_bug.cgi?id=880146#c28 --- Comment #28 from Marcus Rückert 2014-06-04 15:08:09 UTC --- do we really need to have this discussion in bugzilla or can we close it and you move it to mail? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.

https://bugzilla.novell.com/show_bug.cgi?id=880146 https://bugzilla.novell.com/show_bug.cgi?id=880146#c30 --- Comment #30 from Wojciech Kazubski 2014-06-05 16:54:55 UTC --- 1) We can remove avrdude and gtkwave. Both packages are broken here but avalable from main repository since openSUSE 12.2 or even earlier, so there is no need to repair them. RHEL6 also has them. I could not find them in CentOS however. 2) Shall we continue packaging for RHEL and CentOS? Those distributions are from Red Hat family and are not fully compatible with openSUSE/SLE. New packages here does not build well for them. There are some diferences in group system, library naming rules, tools used to install desktop files etc. It is posible to make a specfile covering all cases but it requires frequent use of "%if" command. See some of my packages for Fedora and openSUSE. There are some two possibilities here. One is to remove CentOS and RHEL totally and the other is to disable them by default and enable only for those packages that now build correctly. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.