 Okay, great. So welcome everybody to the 2018 edition of the Debian Electronics Buff. This is meant to be an opportunity for us to share information about what's happening with packages that are used for electronics design and related tasks that are in Debian. It's a little bit different than last year. I asked for a Debian Electronics Buff because we were sort of in what I thought was a slightly desperate situation with not enough people working on the electronics packages to even sort of maintain the status quo and I'm very pleased that several folks have sort of popped up since the session last year and as a result I personally think things aren't in too bad a shape at the moment but very much the same as in the past. I think there's a real value in our sort of talking as a team and as people who are interested in these packages. So I was going to propose that maybe a good way for us to spend the time today is to talk a little bit about progress that's been made since last year. I'm happy to talk about a little bit of that but then others of you that have been working on things are using various electronics packages that know more about those packages than I do. I hope we'll chime in. I assume there's got to be, it looks like there are a couple of mics down there we can pass around to one in front here and one there on the table. So when the time comes we can pass those around. I have one open question about packages that I'm helping to maintain in the electronics team that I'd love to talk about just a little bit and if there are other open questions with other packages within the electronics realm it seems like a great chance for us to talk about those and if there's any decisions we can help drive towards that's great and then generally what can we do going forward to do an even better job of maintaining the various electronics tools that are packaged in Debian. For those of you who don't know I went ahead and stuck the URL on the slide here so it would be quite visible in the video and so forth as to where you can sort of find the root of pointers to follow about things that are happening in the electronics team. So I think for lots of teams in Debian not just electronics one of the big things that's happened in the last year was we moved a bunch of package repositories over to the new Salsa infrastructure within Debian and in the process there was a little bit of sort of name shuffling and cleaning up of the group name so electronics dash team is where you'll find all the electronics related packages within the Salsa infrastructure. I looked earlier today and as of this morning we have 15 current members identified in the electronics team on Salsa which is pretty cool. I don't know that all of those are actively working on stuff but we've had a couple of folks join just I think in the last few days and hopefully we see continued interest going forward and more people wanting to join the team. I think I counted about 26 source packages that are currently in the electronics team group there. There are I think other pieces of software they're flagged as being in the electronics section in Debian that are not currently on Salsa under electronics team and there's of course nothing wrong with that but I would certainly encourage anybody who's maintaining electronics related software in Debian that's not already inside the electronics team to at least consider the idea of joining the team helping to maintain the collective set of packages that are useful for electronics stuff and maybe getting some help maintaining the pieces that they're working on outside of the context. And then sort of the last thing that I think I can do reasonably effectively because I am sort of in the middle of it is talk a little bit about what's going on with the particular schematic capture and printed circuit board tool set that I use the most which is the GPL EDA or GEDA suite and so let me just rattle through a little bit. The sort of main design capture tool sort of schematic level capture tool is this thing called GEDA GAF which produces the schematic tool GSCAM and various related stuff. There have been some minor packaging updates in the last year but we're still on upstream stable version 1.8.2 there has not been an upstream stable release in a really long time and I will tell you that I personally see crashes in GSCAM from time to time and there's a really weird rendering bug where every once in a while it's like text rendering just goes berserk and if you refresh the screen or change the scaling or something it fixes itself and so there are clearly things that even as a regular user of the tool I stumble over all the time but just haven't been motivated to try and track down and part of the reason for that is that upstream is now up to something like version 1.9.2 which they explicitly tag as an unstable release. On the other hand when you ask questions about things it's not unusual on the list to have it pointed out that oh that's fixed in current head in the repo and so one of the things that I find myself scratching my head about is if slash when it would make sense for us to package the upstream unstable 1.9.2 if in fact it turns out to fix some of the known bugs in 1.8.2 but I haven't sort of gotten enough enthusiasm or momentum towards doing that to actually do something there's anybody else here that is using GSCAM and friends and has an opinion about that I'd love to hear it if there's nobody in the room that's using the stuff and folks who are watching the stream or see this video later want to send me email and give me thoughts that would be great I'm one of multiple people who helped to maintain that sort of packages in Debian so I'm not the only person with an opinion does anybody have something they want to throw out right now about that or is everybody kind of not caring whatever I do is just fine yeah yeah smiles around the room okay the second thing I'll mention is I mentioned last year that the GEDA GAF package was being forked by another upstream community to create a set of tools called Lepton EDA Lepton as a name is a little bit unfortunate because there is already a Lepton for a totally unrelated thing packaged in Debian but you know that's our lives it appears to me though I haven't really been following it super closely that 1.9.4 is the latest Lepton release they forked I think late in 2016 and have been working I have not seen anybody actually package that for Debian I guess one of the things that we could consider is whether that's worth packaging and bringing in either in addition to or in parallel to packaging the 1.9.2 version of GEDA GAF my only concern about that has to do with sort of the extent to which either or both of those teams is paying attention to the PCB R&D fork of PCB which I'll get to in a second with respect to the tool PCB which is the printed circuit board design tool in this particular suite in the last year that's been updated from version 4.0. something to 4.1.2 mostly bug fixes a few changes in the way units are recorded in design files so if you use the current version of PCB you want to be a little careful about thinking that you could go back to previous versions and not have a little bit of a data issue with the file format being tweaked but right now 4.1.2 is working just fine for me and all the things that I do however there was this project I talked about some last year that's a fork that's been going on now for at least four maybe five years of PCB which is now essentially a completely new tool called PCB-R&D some really dramatic percentage of the source code has now been replaced a lot of internal data structures and code structures have been reworked PCB-R&D is interesting to me because it allows me to sort of carry forward all of the designs I have in PCB and all of the effort that I've put into library parts for both schematics and printed circuit board work and in general the same process flow for moving from schematic capture to printed circuit boards and so on that we have with PCB but PCB-R&D has a new file format it now encapsulates the concept of pad stacks within footprints and sub-circuit support exists and one of the things that there's really no easy way to do with a footprint in PCB that you can do in PCB-R&D is have features in the outline layer which means things that printed circuit board shops need documented in the outline layer for creating things like slots for tabs on a part don't have to be quite as hackishly handled as they were in the past with PCB so I'm personally actually looking at moving some or all of my designs over from PCB to PCB-R&D in the next year starting with a design that I'll probably be moving you know next week as a result I've been personally packaging PCB-R&D and tracking upstream quite closely and that's currently at version 2.0.0-1 which is the latest upstream release and then I was just, people ask all the time so I put one of the examples of a board that Keith and I did in this tool chain that circuit board is about, I don't know, yay big, it's a whole lot bigger on the screen than it is in real life but for those that are watching the stream and trying to figure out what electronics tools are all about it's to allow you to design things like this so with that the stuff that I feel like I have to contribute to the buff is much done. Things that I think would be really interesting to hear from somebody else about are the status of the key cad tool chain for doing printed circuit board designs and that other major tool set if there's anybody here that wants to talk to that Noodle's I know that you've been doing work on things like open OCD that are also in this space it'd be really cool to sort of hear what's going on there and what the status is and anybody else that has stuff that you'd like to offer sort of some status reports since this time last year that would be really great there's a couple of microphones down here if we could kind of, if anybody that wants to add some additional progress stuff would jump in, let's do that and then we can open up and take questions Yeah so open OCD wasn't in great shape last year I've pulled it to the latest upstream release and sort of triaged a bunch of the bugs we had one particularly embarrassing security issue this year that involved me having to do back ports to pretty much every release that we currently had out there at the moment I think the main thing about it is I'd like to see a new upstream release it doesn't actually have ARM64 support it's like 0.10 is the current open OCD release and it's from January 2017 and they've done a lot of work upstream on getting ARM64 support working in it and that would be nice to see I don't really want to get involved in doing a back port of upstream work on that because there's just been so many changes to that but I've had a few interactions with upstream so I might poke them and go hey, any odds the other piece I've been working on is the whole SIGROC toolchain so that's LodgeGanalyzer again upstream is actually a Debian developer but just didn't have time to look after it so I took over from that and again it's up to date that's actually been quite useful for me because it's now working in ways that it wasn't previously I got a question in terms of electronic design we cover in the team we've got some tools that are about electronic tools such as JTAG and LodgeGanalyzer the other piece that I know you and I have discussed BDLR compiler toolchains for embedded devices so I did a rather cac-handed NMU of SDCC this week but it seems like a tool that is useful for embedded devices that very much fits in the embedded space today I've been spending some time on a full GCC toolchain for the ESP266 which again doesn't fit into anything that runs Linux it's an embedded space processor now SDCC is small enough I can say right I think that should be part of the team a full GCC port seems a little bit too heavy but I wondered what anyone else's opinions on the whole matter were actually Keith if you wanted to jump in and talk a little bit about the GCC ARM for embedded things that you did I know you and I are planning to talk about that in more detail tomorrow but the part of it that might be relevant here about you know where's that package in the archive and where does that stuff live and is this relative to it yeah we have a wow so the GCC GCC can obviously be compiled for a bazillion different targets one of the targets that we have for ARM right now is obviously the regular Linux ARM compiler what we need what I needed instead was GCC compiled without any libc dependency so that I could use GCC in a library less embedded environment that turns out to actually be impossible GCC requires a libc but you can compile it without any operating system requirements it doesn't depend upon any operating system infrastructure so there is in the archive a GCC ARM none which is to say it doesn't depend on any operating system interface and it uses the EABI and for an embedded environment you don't care what the EABI is because there is no library there one of the big problems that I've had with embedded systems is finding a libc to use in the GCC AVR world there's an AVR a special libc for that tool chain STCC comes with a libc for STCC GCC ARM none EABI depends upon nanolib nanolib actually requires a POSIX operating system under it in the default compilation mode so we actually don't have a good libc for embedded systems yet I've been hacking around with a nanolib that replaces the standard IO bits from nanolib with the standard IO that comes with the AVR libc and that's almost a good idea it's really a very nice little embedded standard IO library that I'm pretty fond of obviously it's not high performance but in my embedded environment standard IO is used for debugging only so it would be great if we had some standard mechanism, common mechanism across platforms for a libc that was used for embedded systems nanolibs as close as we have right now but it's not quite there the way that I initially packaged the GCC ARM was our standard libc our standard GCC source had a set of patches on top of that so it had a build dependency on the GCC source package which is not a source package it's a binary package in the repository that actually installs the source code to GCC in your system so when you install the GCC source package you get the sources to GCC installed in a machine in a way that you can then build a compiler from them so our usual GCC targets use that package as one of their build dependencies and then just compile it with the appropriate options that's what I did with the original port of the GCC ARM non-EABI compiler right now another person who's maintaining that package, August I'm not sure Augustin has decided to instead incorporate the sources to GCC the package I'm not quite sure why, I may go re-investigate that but it's really useful if you're building an embedded GCC toolchain to use the standard Debian GCC sources that way you get a common upstream set of somebody else is maintaining the bulk of your compiler which is awesome so you get security fixes, you get upstream integration you get back ports, that kind of thing so that's a really great way to start and I think I'm going to go fix the ARM EABI non-1 I know Charles has been doing that for his toolchain so it makes a really small source package, you literally have a build dependency on our GCC source package a small set of host-specific patches which could eventually get integrated into our shared GCC source package and then just here's the target architecture go build a compiler so I guess there's two detailed questions one is what section of the archive should that package live in and is it something that sounds like it would be appropriate to put under the electronics team on Salsa or does it just live somewhere else and we don't care and more precisely to help answer Noodle's question of what should he do with the ESP version of this if he ends up building something he wants to put in the archive I don't know what area it should live in yeah good question I'm not really sure I know either and this is one of those things where it's like okay who's going to care for this well it's unclear to me that anybody outside of electronics team space is really going to be wildly enthusiastic about embedded systems programming which is where these compilers really get used but maybe I'm wrong maybe different and I have no answer for these embedded systems but different question is we have a lot of electronics packages maintained in Debian science team and we have a lot of packages maintained by non-team do you intend to try to get this same under your same policy in your same Salsa group because I think this would make perfectly sense to collect the electronics people Do you have an example or two of the package you're sharing on? The page of Debian science electronics and you can show and all people can see I have a lot of stuff I can pronounce the all should I put it in ILC the link I'm not on IRC at the moment I will tell you it's blends.debian.org Hang on one second We could actually to a browser and I need to shove it over there Hang on Hey that actually almost worked Wow but I can't see it now Oh I get too complicated sometimes Sorry people Okay so where is it? Blends Blends Blends.debian.org Slash Science Slash tasks Slash electronics Electronics as in C missing Yeah if only I could see what I was doing What I was doing Yes enter There you see a list of all those packages which somebody most probably not you considers electronics relevant Yeah so it's interesting the Arduino stuff is another kind of weird example in this space right because it's also like I guess it depends on GCC AVR or does it I don't know it certainly provides on top of that And you have a lot of packages maintained by Debian Science maintainers, private people and there are only a very few the minority is maintained by the Debian Electronics team and my question is would it make sense to invite those people like Milan Kutcheri to package AVR in the Debian Electronics team to the same policy and enable all maintainers doing something Sounds like so much work I'm pretty relaxed about it actually I mean I love the fact for example that AVR dude is packaged in Debian but I don't as to where it happens Do you have a sense one way or the other would you love to see some of these things go away or I did this with the Debian Meet stuff because it was the only way to make sure that we have all package maintained in kind of the same quality and makes them up to date and so I'm not sure how it was with the electronics stuff but we also So there's an interesting overlap here because the GEDA stuff I mean it's mentioned here but that is actually that's the GEDA GAF package in the electronics thing GCC AVR is showing up here yeah that's another I even don't know who is maintaining this plans tasks are maintained by Debian science people and the only thing what you give is depends package name okay so this is a I get it so this is a task which contains a list of packages that people think are relevant to science slash electronics okay so there's no particular so this is the same problem I identified before that there are a lot of things electronics people care about that are not actually within electronics team and I don't you know what I care about is that they're actually being attended to and if they're being well maintained and nobody's stressed about it I don't care if it's under electronics team or not I would certainly invite anybody whose package shows up somewhere like this what I mean yeah you know if anyone who maintains a piece of software that's in science task electronics wants to come you know put that package on salsa under electronics team and collaborate with the rest of us that probably be just fine one one further I want to respond to one of your points I think you have a well either I'm not aware of it or we just don't have one but there's no coherent policy between the team about how the packages are maintained it's a central point where people are maintaining packages but we don't have a team why this is how you do things there's some advice that goes on the list but don't put too much stock in that it's a convenient place to put packages that I think are often used as tools for the thing you want to get done rather than the end of themself and therefore having lots of people who are potentially interested able to work in them with the benefit the team offers yes we don't have like one grand unifying how we're going to package things policy we are very much loosely organized in that I there are many packages of the 26 ish source packages and electronics team that I've never looked at or used much less work on so it's yeah I don't think we have a really simple answer but I would certainly invite anybody maintaining a package that's on this list to consider whether joining electronics team would be helpful my point is that electronics team is not widely known under the deviant maintenance it had almost completely vanished this time last year and so what we're trying to do is kind of get things back up to speed and honestly if someone came to me at some point and said you idiot why aren't you doing it some other way I think you know we would all smile and go thanks for educating us but right now those of us who are actually working on the packages that are in the electronics team repos don't know of anywhere else to put them so I think I have quite a good overview about all this kind of topic related stuff and electronics was kind of escaping of my so and the other thing I want to say is would one of the team mind about maintaining this task inside the deviant science team because this is probably quite often and at some point in time somebody said down what's electronic relevant and put on this list but this is probably we have more packages that are relevant for electronics and not mentioned here and maybe there is some stuff inside which is questionable this would be really cool if somebody from the team who knows the stuff would check this task I'm curious enough to at least take a look at it one time I don't know that I'm willing to commit to trying to help maintain this it's not about you but if you have 15 people that's part of the answer though I personally am interested enough I will take at least one look at it maybe some of us can sit around on a hack lab or something and scroll through and see what's interesting in particular if there are things that pop out as not being well maintained that we ought to try and suck in and you know rescue the packages as was being discussed this morning then maybe that's a way to identify some potential targets did you have something else you wanted to throw in or just the right so is there anybody here that uses or helps maintain the key cad toolchain Carson do you want to talk about that a little bit what's happened in the last or any of you I'm not maintaining the key cad library but our company use key cad to develop electronics devices so we are trying to make some patches for new features for key cad maybe we can push that package push that patch into the upstream this is what we are going to do that would be great that would be great yeah my name is Carson I am packaging the key cad package for two years I think just to mention patches welcome plus please go upstream that's the best way to do I don't want to add patches that just exists and there we are and other people and users are also useful in Apple and I don't want to diverge much from upstream so yeah key cad 5 is alive now for three weeks yeah this was a little bit yeah difficult sometimes not from the Debian side more from the upstream side people are happy to get new contributors and to new maintainers and it's a little bit sometimes say at a chaotic but okay we've done it I've got some communication with Jean Renaud I think it's the name he's doing the PPA for Ubuntu and we got some common sense how to do the package layout and so we mostly found now given packages or living packages so we can live in Debian and Ubuntu as well and if people using the PPA it's not that big hassle for users so it's just an upgrade of packages and if we go down we don't use PPA I also got some conversations to upstream as well and mainly I do also with German localizations if I got time in the past few months I got not that much time to update the documentation for the e-schema and all the tools inside so I mainly get the focus on updating the documentation of the LTNN and yeah, ngspice is still living in UQ if someone wants to poke with FTPMAS those are living since two months now and I would be happy to enable also some simulation stuff once ngspice is enabled accepted into main because upstream was very friendly and communicate also to me and take a big advantage to just with version 28 get rid of all the non-free stuff yeah, I was excited to see that but it was quite easy more or less so that's still sitting in what kind of stuff would be needed to be done and say what okay, we will do it so that's still sitting in the NMQ right now okay, maybe we can poke somebody here while we're there just don't want it poke then we are and it has such a complicated history I can completely understand why it might put the fear in someone to want to deal with it but yeah do you want to jump in? yeah, so because you asked for users so we are also using Kiket with the pocket science lab maybe some of you might have seen it we have put it on the table on the ground floor yeah, and we are moving now to production, to producing more so we have a few feature requests I don't know if you have good relationships to upstream let's talk later more in details for example like commercial producers have some specific requirements for example some different formats and so on so yeah, it's pretty exciting to see like completely open hardware, free hardware to move to production here with Kiket so the whole chain yeah, all layers are free yes, yes and by the way those who haven't noticed Keith and I will be doing a talk tomorrow I don't remember what time on how we are using entirely free stuff in the design development of the electronics and the actual rockets that we find are a rocketry hobby so that's sort of a use case example and why we do all that and the various ways we have ended up contributing back to Debian as a result so yeah, so other thing you've got, what do you want to jump in on? yeah I'm packaging GHDL which is the GHDL simulator I've been doing that for a while I already all uploaded in February but the package was rejected because of a problem and that was the 035 the last latest stable the latest release at least and so the libraries got a bit different and so I've been redoing the packaging because including the external libraries changed and actually got better but yeah, I wasn't working that much over the month I hope to upload it before today and didn't manage it but it'll be soon it's a bit of a complicated package because yeah, it's a compiler and it supports internal backend, it supports LLVM and GCC and I decided to put them all in and yeah, so the support that comes with it which is free software is GHDL93 and it needs the official IEEE libraries for GHDL2008 support which I then will have the package as a non-free binary which is which will come later and since I had to integrate that somehow it's been it's been a bit longer but it'll come soon Is it all feeling good or are there things various of us could try to help you with while we're all here at Dubconf? No, I've been working with myself and there's a lot of decisions in how to organize it and well, I'm finalizing on something and I think once I got it uploaded I think I can share some of it. Okay, very cool yeah, certainly while we're here at Dubconf if there's things that we can do to help each other out that would be great but yeah other people that are, yeah you want to jump back in, noodles? Are there other things people are maintaining or working on or want to talk about? Let's just dive right in. I have a question about the pocket science stuff you're using a PIC24 chip do you have an open tool chain for that or are you using the horrendous MPLAB stuff? So actually yeah we're using a PIC24 it's not open because like we base it on a previous project so we actually created it from there step by step and then also we moved to so we're moving like making it open step by step the idea is like maybe a next version move to but like actually there are always a lot of small things to improve and at some point you have to decide to make a version, maybe go into production because we're also developing software for it so we want more developers who can work with the device and use the software and so on and get it out into the education from making the hardware to getting like free education materials for schools or have startups use it or whatever that's our idea but as you say and the chip itself is also not being open right so anyone who wants to provide us with a free chip that's a big challenge right? Yeah I hear PICs the ecosystem is terrible in particular I play with the bus pirate which actually ties into some of the logic analyzer stuff and it's a lovely device and it compiles stuff for it because it's a PIC24 it's a complete PN Yeah and Keith and I had this interesting experience that we had a device that we built around an AVR at one point and then we kind of went and looked when we were talking about maybe manufacturing some and realized that we could buy 32 bit ARM core SOCs for less money then we could get either AVRs or PICs for that's not always true it depends on how much IO and what capabilities you need and so forth but I've been really impressed at how much the price on the ARM stuff has come down and since that does have a really great free and open toolchain available for most of it and we figured out how to do source debugging on most of them with open OCD and other things that seems to be a pretty good place to land right now. I'm personally really really interested in risk 5 and I'll be showing up at the risk 5 buff tomorrow with a couple of toys we can talk more about that in that context that is sort of peripherally related to electronic stuff but or at least to me it is because to me it's all about getting chips designed but you know yeah, whatever. Other folks have things they want to talk about? Questions? I've started a project which is which is all using free software and free toolchains to make some electronic devices so my keyboard here is all designed by KeyCAD and the program the chip on it is STM32 I use ARM9E BI-GCC for source code compiling and so it's a pretty free hardware I think. That's cool. I think the development in Linux is getting better and better pretty optimistic for risk 5 I already got one but I've not started the risk 5 development yet. Since you mentioned if we have questions, for instance I'm currently developing well, I guess you could call it a peripheral in the sense that it supports that it's meant to be attached to a regular Linux machine preferably a Debian one and I was wondering do you think it makes sense to do things like actually packaging the firmware for the devices in the archive so that people can actually just get an already built version of the firmware from Debian instead of from me? So putting binary firmware into Debian is something we've talked about at various times in the past. I meant putting the source firmware in the archive so that people can get the right image built by Debian. The products that Keith and I build are all supported by binaries that are built from the Altos source package which is in Debian and we ship the binary firmware for all of our products in the Debian binary package so at least in our case for example of where we're already doing that I know that if we start talking about really huge firmware images then the archive maintainers might have questions about how important it really is to put that on all of the mirror network but I really like being able to just apt install Altos anywhere and have all the stuff I need so I've actually been we've been talking about at some point maybe if I ever get around to it refactoring so that instead of delivering a single binary package from our growing in size source package we might split it up because there's really no reason for all those firmware binaries to be rebuilt on all of the architectures auto builders but compared to some of the really large packages in Debian that take forever on the auto builders it's really not a huge big deal so we just haven't worried about it for much yet but I would think as long as we're not sort of abusing that network I can't imagine why it would be a real problem I certainly hope it's not a problem because I'm doing it anybody else sorry you said you said the source package was Altos ALTOS okay I'm cloning it right now it's big sorry well I don't know maybe it's not related to most of the people here but actually I discovered that there's a completely open source torture from successes maybe I just need to put up some background there is a brand a manufacturer of APJA that is called LATIS and they have a series of APJA board that is called IC40 and they have the open source torture and actually I have tried the open source the lens that is pretty awesome and actually I have burned the RISC-5 core on it and it works like charm so I'm pretty optimistic that one day we all have a completely open source torture to educate our maybe college student or graduate student to do their development so thank you so you've actually burned a working RISC-5 implementation using an entirely free tool chain into a LATIS part oh dude I hope you show up at the RISC-5 and talk about that a little bit tomorrow for sure and I think that it is simple because the example itself is work out of all of the bugs right okay that's cool I did not know you could do that with stuff that's in Debian right now so I'm actually quite excited to hear more about that okay I will take the actually I forgot to bring it here and just show you right away yeah that's quite okay well there's a RISC-5 buff sometime tomorrow I think or no it's Saturday sorry it's on Saturday and if you if somebody is not going to be here and has RISC-5 things to talk about you know feel free to come find me because RISC-5 is something I find quite exciting and would love to do more with okay time wise I think we're getting relatively close to the end of the time that was allocated you've got one more thing I want to throw out I mean I'm happy to hang around but I know the video folks would like to wrap up here in another minute or so I just want to mention that there is a new electronic simulator package Simul IDE which is most appropriate for educational purposes okay so you can check it out I haven't seen it okay thanks for letting us know what's the name of it again Simul IDE Simul IDE S-I-M-U-L-I-D-E got it excellent thanks for letting us know about that okay with well with all with that thank you all very much for your time and your attention