 Hi and welcome. My name is Marcus Koshani and I'm a Debian developer and also a team the other team member Today I want to give you some insights into the job Java Java in Debian and what challenges we face during our daily packaging work Java is a very important language in Debian if you just count source code lines It ranks in third place only after C and C++ Which are used in a two-third of our software packages With more than 19 million source lines of codes. There's slightly more Java code in Debian than Python I know what some Pythonians would say it's because of the boilerplate and they are probably right but still it is a very important language and and It has a significant number of source code lines three times more than Pearl and Pearl is a very significant language in Debian because almost all our most important system tools are written in it The Java team alone maintains about 1,000 source packages or another count over 1,600 binary packages if you This is almost 11 percent more than we had in Debian stretch Of course, we are not the only team which deals with Java There are other teams like Debian meds or Debian science who deal with specific software packages software written in Java for example for scientific research bioinformatics or Medical care Here and we have also dedicated team for closure and there's another team for packaging Android software So if you ever wondered how you can build the Android operating system from source There's a dedicated Debian team who does only that According to our popularity contest which is up in more than 40 percent of All systems report that they have an open JDK 8 installed on them so you can see There's a lot of Demand for for Java popular applications are that use Java our Libre office in parts Netbeams sweet home 3d free plane or free call. We expect similar numbers in Our upcoming Debbie and 10 Buster release What can you expect in the be in 10 Buster? So first of all very important we have completed the open JDK 11 transition Which required more than 400? package updates actually, I wanted to Complain a lot about the grief that was caused by the transitions but someone told me to keep the talk positive and I Shall not rent so I skip that part for now. Let's move on to build to it And and Maven are up to date We have some problems with Gradle. It is stuck at the last pre Kotlin version because The Gradle developers decided to rewrite some of the build scripts from Java to Kotlin That sounds like a simple problem, but for us it means we have to package Kotlin to build Gradle from source and This is quite hard because Kotlin built depends on itself so we have to bootstrap it and this is yeah Hard task, but help is wanted and we want Kotlin and Debian. So yeah, we like help At JVM languages, of course, it's not all about Java. A lot of other languages run the Java virtual machine We provide Groovy 2.14 Scala 2.11 2.12 requires SBT the Scala built to and Yeah, we have some problems you too So help is wanted We will chip closure 1.9 gyton 1.71 J ruby question mark It has currently three release critical bugs So I don't know if we can ship it in Boston Ideas yeah, unfortunately eclipses gone because we have no maintainers who want to maintain it once had five ones Today there's no one. I Have packaged net beans 10 for Debian a few weeks ago Which was a very demanding tasks about it will make it into Buster Very important for server users and we will ship with jetty 9.4 and Tomcat 9 fully up to date and With system D integration and last but not least reproducibility levels at 85% What does it mean? So if we once in one in the future reach 100% That means you can verify if a binary package built in Debian corresponds to the sources so it gives you more confidence in what we ship and It gives you another security level or a new layer of security You can learn more about the reproducible built afford at reproducible builds dot org This is a whole another talk very interesting topic So now I want to talk about some challenges That we face in our daily packaging work You know that Many build systems just download binary packages from the internet. This is the intended use case so in Debian we say That our software Requires if the software requires other software from outside the main archive. That's not allowed So we make sure we promise you that everything in Debian is built from source and complies with the Debian free software guidelines And we cannot promise that if you can't control the binaries in In external reports, that's not possible. So Every time someone ships only the binaries For example and projects where you often can see that the developer includes job files Then we have to remove them because we cannot control what's in them and we don't have the sources So how can we verify that this binary package is actually corresponds to a specific source package? So there's security risk involved. There are software freedoms involved. So we say no downloads at build time only built with packages that we have the source code and that we built Ourselves that we can control and that will not vanish sometime in the future when some repo external repo will go offline or something else Then the major point is Java is version centric that means you have to pump file and You declare several dependencies so one project declares a dependency on a library 1.0 then Another point a project declares a dependency on the same library, but version 2.0 and third one on 3.0 and so on so for the casual Java developer that's not a problem, but That doesn't scale very well if you try to package that for a distribution like Debian so we would have to package every version and included with Debian and That's time-consuming Ways of disk space There's security risk involved What do you do if if some security vulnerability is discovered? So you have to check is version 1 affected is version 2 affected is version 3 affected And then you have to update all these packages This can work if you have a dedicated staff Who works full-time paid on your software projects and does nothing else than updating these projects? But it is very difficult for a volunteer project like Debian We have unpaid a contributor contributors who have not that time so a big problem is also that many projects ship Uberjaws or FedJaws or bundle everything into one big piece of software I've seen even recommendations for shipping open JDK alongside with your application So this opens enormous security holes it is very difficult to assure or ensure that You are you can maintain this project there can be a lot of security vulnerabilities. How can you verify? That this will work in five years So you have to constantly update the whole package and make sure that it works and that's a very demanding task So Debian we say we ship only one Version of that package we make sure that this one version Works with every other a package in Debian And that you can this that you can it's independently update This simplifies security support and Reduces code duplication But this use case is not very well supported upstream So we constantly fights with build systems that is human. It's okay to Download various different versions of some library and we have to patch them and That makes life very difficult this graph shows a little bit what we face The amount of bugs that we fixed in the past years you can see there's a slight increase and obviously in 2018 something happened and You can also see that only a few contributors fixed a lot of bugs. I don't want to belittle those contributors that fix only a Few bucks a year because we have more than a dozen different contributors, but they concentrate on one package and Sometimes these packages are not affected by many bugs So it is unfair to say they don't contribute anything meaningful. I would never say that What we have other contributors will just update documentation. So this is also very important But they won't show up here. But what I want to tell you with this graph is that Relact more people who want to Yeah, I say we want to get the bigger picture right So we want to fix build systems want to fix Bugs and libraries which they actually don't care for but which are important for other packages so Yeah, it's a bit. It's not equally distributed as you can see the yellow guy fixes almost three times more bugs than the next guy and If he gets a cold or moves on and does something else Yeah, we have lost a very important contributor and the project will Suffer as a whole That's obviously not good They are back to 2018 in 2018 the open JDK transitions happened nine ten and eleven and This caused a massive increase in bucks For example in a build failures most and build failures because classes were removed and methods were removed The open JDK maintainers would say, okay, that's was suspected. We have deprecated all those classes years ago Why didn't you fix it? The problem is many upstream projects say Well, it works with open JDK 8. Why should I update? But we have to make sure that we can ship open JDK 11 in our next stable release Because that gets five years of security support. So if we ship open JDK 8 it will work now But not in five years. So if you depend on security support on the server side Then you have to choose a long-term support at open JDK so It is not true that they been is Ships only old an outdated software actually we work on the forefront But the actual development happens in Debian unstable and if you download they were unstable You could see all this what's going on with the transitions and there's a lot of work involved to make Every package buildable with open JDK 11 and also work at runtime of open JDK 11 I think that's a bit unappreciated by someone by some people, but it's a very important task for Debian Yeah, that concludes my talk. Do we have any questions? Thank you very much anyone with a burning question. I will run to you with the microphone Do you hear me? Okay What do you do when you face the situation so so a piece of software is not compatible with super JDK 11 So how do you decide so does your team act then and does something on the code or do you reach out to? The software project or are both approaches valid and how do you decide which approach to take? Thank you for the question so there are usually Three path and wafts first of all we contact the upstream project and look for new upstream versions obviously So we always try to have the latest software in Debian. So naturally, that's the least amount of work for us So and if you discover up some is not ready yet so we have the choice either to patch and the actual version to work around the problems somehow or To actually fix it if you can fix it because it's a simple fix So we just have the capabilities to do so then we forward the patch upstream and upstream will hopefully implemented and imported If both of these Ways don't succeed then we have to remove the software from Debian because if we cannot build it from source then it's Doesn't it doesn't meet our quality standards Okay, thank you very much. Can I ask for a warm applause for Marcus? Thank you very much Thanks a lot for the talk