 My pleasure to present Chris Halls and Renee Engelhardt who will be talking about openoffice.org in Debian. Okay, thank you. Hi, it's nice to see so many people. We wanted to become one. I mean, OpenOffice is very popular among users that are to conference like this. There's not so many people that are interested. This is the Debian OpenOffice team. None of these people work full-time on OpenOffice. Well, Renee does a little bit in this day job. I work a little bit in my day job, but mostly we do stuff in our spare time. So, these two people are the people who process all of the bug reports and the packages, and so on, and I don't know how many of you have tried to build OpenOffice. Four to five, okay. Did anyone actually succeed? Oh, well done. So, yeah, and how long did it take you? I think it was overnight. Overnight, okay. But yeah, just packaging is a big job. And then, as Debbie maintained, we're also expected to coordinate with AppStream, who are about 60 developers, and also not really into the same type of free software as we are, most of them being at San. They just have a different view of the world. It's like, if you go up to a Windows user and ask some question, why don't you script something in like? And it's the same thing if we ask them, well, why are you writing this in Java? And they're just like, well, Java's quicker, and what's the problem? It's free. And so, we've got quite a lot to do. Yeah. So, we've got quite a lot to do. And I do actually wonder sometimes whether the maintainer field should be Debbie and OpenOffice team, because we often get mailed, like, could the team do this and maybe the team would like to look at this, and we're like, we don't have time. We're just trying to keep the packages up to date. Just keeping them up to date is a big job. So, at the moment, current status, about 321 outstanding, and this is climbing the whole time. Okay, so that's the bad side of our job. Let's tell you a little bit about OpenOffice 2. Everyone's probably wondering, when is it coming out? Well, so are we. OpenOffice 2, well, it was originally supposed to be out in March, April this year, and it's been put back for various reasons. There was supposed to be one beaten while it was really more like an alpha. So, there's talk of another beta coming out, and, well, there's no release date yet. But this is a time when you can actually test OpenOffice 2 and find out what problems there are before it actually goes stable. René's been doing most of the packaging over the last few months, and Matthias as well. Matthias is a Ubuntu maintainer, and he's helped us quite a lot with OpenOffice. So, we've got packages in Experimental, but not in Unstable, because the FTP masters aren't so keen on us having two versions of OpenOffice in Unstable, because it's quite big, in case anybody haven't noticed. Mainly because of the sheer size, the actual up-to-date version in Experimental is source and steps, 400 megabytes. One upload. So, I guess it's understandable why you don't want two packages of the option, and then the automators. Yeah, it grows with every version. Keep adding more and more stuff. It's another difference in mindset. These guys work regularly with Solaris and with Windows, and you don't have all of the nice package libraries together. So, what do you do to make it easier for developers? You lump everything together. And, like, there's loads of developing developers saying to me, why on earth is there? What's the biggest thing? Is there a gene they've been there at all the time? There was at some point, but just big libraries. We do actually patch them out in the packaging. That's one thing that René and I have been doing. As long as it's possible it's done. There is some libraries that are heavily patched inside the tree. ICU is megabyte and you can't build it out because it's so heavily patched. If the ICU maintainer wants a fairly patched version, maybe, but it's not happened yet, and AppStream wants to resolve that problem, but for later version. Yeah, AppStream have got a lot to do as well. Sun have got different priorities to us, and they're putting in new features, which may or may not be interesting for us. New database components are pretty good, apart from the fact that it is Java. They are putting more and more Java into OpenOffice, as you've probably realised. Thankfully, GCJ is getting better and better, and now with version 2 OpenOffice and version 4 of GCJ, we can actually compile OpenOffice with GCJ. Unfortunately, that makes it start up even slower, but we're hoping to be able to use the shared library, what is it, SO building of GCJ to actually pre-compile stuff, but there's some problems with the current version, so we'll have to see where we can get that in and working. But yeah, that's been a lot of top discussion. Richard Storman, for example, has actually been made regularly on the JVK list at AppStream trying to sort this out. So at least people have been taking an interest there, and that's moving forward. As far as the packaging itself goes, we have just been doing version 2 recently. There's a lot of bugs still to go, and one of the things that we've done is we've started moving over to use earlier to actually make it easier for people who aren't Debian developers to get involved. A year ago, at the last EPCOM, I stood here and talked to people about how to help with triaging bugs. We did get some help, but it's gone back to being just when I am myself really. Although OpenOffice itself is a big package and we use a lot of hardware to build it, there are still a lot of things that would help us. All of these bugs here, we try to work on the very serious severity ones. But if you go down to the normal severity, there are just pages and pages of reports by OpenOffice users. And generally OpenOffice users, on average, aren't used to writing bug reports as much as it might be for a more sophisticated development type of package. So we get really basic reports, and we have to spend time with every single one of these going back and forth with the user to work out what exactly is the problem and how to reproduce it. Just somebody who could help us with that, for example, looking at some bugs, that would help us get the countdown. There's a lot of really low-hanging fruit in these stuff that can be... Some of them may even not apply anymore. There is some bugs reported against 110 or even 103. I am pretty sure some of them don't apply anymore. Protracted is partly type-consuming, and the package can still go on. So it's not so easy to find out whether to close the bugs. Sometimes even the submitters don't answer anymore. Yeah. Yeah, just somebody going through and working out which submitters are timed out would help. Now this one, version 110, there's quite a big chance that that's been fixed already. Yeah, so this bof is actually a recruiting bof. No, not really. Do you have any questions about what we've talked about? So far, are there any of you who have some time and would like to help us improve the open-office packages? Oh, great. I wonder how many of you actually use the open-office packages. That's two in a room, so there's a lot higher than you'd normally expect. I mean, we do have millions of users, and most people don't really help us. And they also are under the impression that there are loads of people beavering away at Deviant to make these open-office packages. Does anybody have any suggestions about how we can actually get this message across better? Has anybody looked at the packaging, the project, the documentation? I'm wondering if I had the specific thing, the dictionaries. There was a thing I did some packaging for, not in Deviant, but a bit for the Deviant package work, which was a fairly easy dictionary installer for open-office, which would be installed either into the user or into the home folder. And now the dictionaries are sort of trickled in by the normal Deviant packages, and that actually has a lot more dictionaries available than the Deviant packages, and plus I suppose it would be easier to just package that instead of packaging every single dictionary. How would one go about suggesting a social thing? Because obviously nobody wants to piss people off and suggesting to remove all the dictionary packages and installing the app. How would one go about suggesting something reasonable? Talking about the actual technical issues and trying to establish why we've actually got the situation that we have. I might explain it to you a bit. The original upstream didn't have any installer at all. The MyStyle dictionaries do predate that. The advantage of having dictionaries as packages means that it's totally integrated with the rest of the system. But as you say, it doesn't scale. We don't have time to look after every language, but we would prefer somebody to look after their language. Since we have MyEyeSpell and Aspell dictionaries, it seems reasonable enough to say, here's the framework, go off and make your dictionaries, but as you say, they're not all done. Now, if you've got a... Sorry, Andrew. Just about the dictionaries, something that would make it easier to package individual languages would be if there was a framework which was just a single dictionary. The source package for dictionaries is a whole lot of dictionaries. That creates individual, deviant packages, which is fine if you've only got one maintainer, but if you've got one maintainer per language, it becomes difficult. I like being able to install a language support The point is that MyEyeSpell dictionaries can easily be built from the MyEyeSpell dictionaries. So what the most packages we do is not to take the zips from the upstream side, they convert the MyEyeSpell dictionaries into MyEyeSpell dictionaries. And so the maintainers are, of course, the family because it comes from the normal MyEyeSpell source package. Am I right, I think you were asking, is there like a template for a single dictionary? Yes, and it's about... We've had it for about three years, and it's in the CVS. But as Rene says, you can also build them from MyEyeSpell dictionaries. If you build from the zip files, you can get just the template. You can use the template, or you can use any other MyEyeSpell dictionaries because it's not built from an MyEyeSpell source package. But can we actually look at the idea of a central installer? The main drawback of it is that you don't have it integrated with your package database. How have you gone about solving that? What do you do? If I remember correctly, there was some time ago, if I remember correctly, you could give it sort of pre-seeded. So I suppose you could, on installing that package, you could let it choose why that comes with it, or the set of pre-seeds that are tied into the paper, whatever language you use on your system. And then it would obviously, on first run, automatically fetch those. That's a little hackish, I suppose, but might be easier as personally taking over the package. Okay, so it's something that you're downloading a bit like MSTT core funds or something, is it? Yeah, although the dictionaries are the MSTT free. Okay. And when you, you actually had that as a package? Yeah, I packaged that one. Some were, but I did not. Because obviously the framework was already there, you have your package, wondering if you, because I was also under misconception that there was an open office team working on it. And it might be a first step to alleviate some of your work. I don't think, well, by the way, my system, Yeah, that's a good question that is asked, does it conflict with my spell packages? What do you do with the dictionary list? Well, again, sometimes I'd have to look into that again, but from what I remember, even running it, I'll have to adapt some paths because there was written for red hat systems or whatever. But I don't think I've got any confidence. Again, I'll have over this. Yeah, what I meant, there's a single dictionary dot list file, and you need to maintain that file. Are you generating it automatically? No, it comes with the library. I actually don't do it. That's the problem. That's one of the things that we sorted with the MySpel packaging. There was a policy for that in place in the Lick Names comment package, which says the policy for Ispel, Ispel, and so on pages. And in the end, it was just provided info file for an script. Where you write in that info file what this dictionary list entry should contain. And at the post end of the packages should call your script, update on office tickets. And this script regenerates the dictionary list from scratch, preserving the eventual modifications but creating it from scratch. So that's everything packages installation has the new stuff we've got. Yes, so we're certainly open to it. Well, I'll have a look at that. Okay, great. Have a look at how the MySpel diction is worked with the updating the dictionary list. Yes, why not? Does anybody think of a reason why we shouldn't do that? Given that it doesn't work and it doesn't need to alter that. I suppose you're changing the user interface to how you install the diction. It's a DevConf interface, so is it? No, it's a GGA interface. Okay. I'm not sure about that. Sorry, Mattis. Okay, non-interactive. But my line's un-interactive. I'm not sure about that. I don't think anyone would think so. Okay. But yes, please look at it. It's something that I've been thinking about with this sort of data type of package where you've got masses and matters of different files per language or whatever. And it does end up not scaling perfectly when you're integrated into the package database. As you say, when there's more people making these dictionists and the package maintainers can keep up with. And where it's something regular like that, then yes, maybe we can find a better way of doing it. Did somebody look at what was facing MySpell with ASpell? Yeah. Now, the reason why ASpell could not be used on all platforms is because it doesn't exist on Windows, I would guess. I'm not sure, but it was a platform and compatibility problem. And efficiency as well, if I remember right. There was some technical reasons for not being able to use ASpell everywhere that you could use OpenOffice. I do remember there was an older implementation that used to use ASpell, but that was un-maintained. I don't think there's any real technical issues with using ASpell, but it would need somebody to maintain it. So it's just lack of manpower. ASpell wasn't a solution for all platforms. I think that's how it went. Do you know any more? No. That's almost everything. The license are compatible. So if anyone wants to buy the plug-in for ASpell, it's no problem. But I actually won't do it, and we will not have any range of... Anyone can do it using the RP. I think it's doing well. Now, there used to be an old implementation, but I guess it got removed. GCC-4, thanks to Matthias's work, we've got a lot closer to being able to use GCC-4. And they said it builds on i386, but not on other architectures yet. Is that right? It... I don't have the versions built on powerful C2, but somehow the registration of the components in the Office installation does fail now. I haven't yet used it. Why? Because I need to get packaging more finished. I hope with the new GCC it goes away. If not, I will have to look. On other platforms, it's more tricky. Spark didn't build at all. Even the 100 and i8, which did work on top of the i386, S390 didn't build at all, and M64 is the history for itself. Okay, we'll come on to 64 a bit later. I forgot to put it in the list actually. Okay, so why do we need GCC-4? The reason is that it has this symbol visibility feature. And why do we need that? Because by turning this on and hiding symbols from shared libraries, you end up with smaller binaries and you end up with a lot faster start-up performance. Over 60% are pro-quoted. I haven't actually tested it. And it says that it feels fast when it starts. It's effectively as fast as it is, but I haven't measured it either. So that for us is something that's quite important to do. I mean, packaging takes higher priority, but as soon as we can actually use that, it will make it a lot faster, easier, and quicker to start up. So, yeah. Doesn't 3.4 have visibility feature? Does 3.4 have the visibility feature? No. There is a patch which is available for it, but it's not in the Debian GCC. Red Hat and Sousa, I think, and maybe others actually applied that and have been building up an office with GCC 3.4, but we haven't been doing that. Well, it had for not being around the corner, then we must have thought about it. Sun, as they released the official in-store sets, we have two. They use an ONGCC also. Sun use the ONGCC. They use the C with the feature, and then build with that visibility. Yeah. Actually, at one point, I don't know if they still think that Vell was building an internal GCC just to build open office as part of their packaging. So, does this mean that a back port to search is going to be impossible or just difficult? Back port to open office or to? To. To search? To search. I just tried to... I figured. Because of GCC? Well, with those features, yes, it will be difficult. You can build it with C4, but then you don't have the visibility feature. The main problem with back porting is GCC, because if I want the users to have a future environment, I would need a back port of GCC 4 for search we got off GCC 4. Exactly. One day. Sorry. What we did for our woody back ports, which is another job that we've been doing, was to actually turn off features that weren't available. So, for example, I think the front config support was turned off, wasn't it? Things like that. So, actually going back to being more of a nilla version of the packages by doing that, we can actually get something that runs on an older one. So, that's probably the way that we'll have to go with Sarge, and if people want faster startup, they'll have to upgrade to Edge. Do you have any plans to do a Sarge back port? A Sarge back port yourselves? Well, I haven't got one at the moment. It could just be as we have time. I have... For the company I've worked for, we have... We've maintained some older systems, and occasionally I'm asked to do back ports for them, at which point I also check them in, and then, if it's not too much extra work, I'll then release them outside. But, yeah, at the moment, we don't really have enough time to maintain proper back ports, just stepping down again. As you know, just to put it quite out, they're calling GCC, do you know what they're doing? They're calling Sarge Java packages to be their port. That's what we're doing. So, you end up doing half a fetch anyway, just to... So, 30 Java back... 30 Java packages would have to be back ported for that. That's it. So, we need to get Edge out quickly. Yeah, that would be better. We could get Edge out quickly. But, truly, in the package relationships, there are some Java libraries in the defense. I would need to back port those through. I would need how to get them built on a Sarge system. I would need to back port GCC Field 4 for the Java stuff. You could disable the Java stuff, but then you have very interesting bugs in the Office Suite. So, it's not really... That's a good idea. In an emergency, yes, but I would not like to do it. Because a safe-ass dialogue who pops up every time you press Enter is not that funny. Yeah, that is true. I mean, if I notice correctly, basically, at Sun, there is a tendency right now to put a lot more Java than before into open-office. Do you feel that it might reach a point where it will no longer be possible to build anything useful for Debian because we don't have Sun's own GVM ported? No, because... Sorry, I should have to keep the question. Do we feel that there might be a point when the open-office packages are not really usable because there's so much Java stuff going in there? I don't think so, because we have enough influence to be able to say, Stop your... This is going in the wrong direction. It takes time to swing Sun, but the distributors, we do work together and have not insignificant voice. And also, the idea was that some would only start adding essential Java features once the free JDKs were ready to go. There isn't anybody who's saying, We don't care about free JDKs. It's more a case of the developers who are implementing the features don't realise the issues because they just use internal, their own Sun, and there are a lot of them, and it's very difficult to keep up with them implementing all of the new features. And also, there is this expectation that the free JDKs will get better. We did have an agreement with them that they wouldn't implement stuff that depended on new versions of JDKs, and that does hold. There are some features that need 1.4 JDK, but they're internally there on 1.5 already, but they've agreed not to use features, and also they have committed to actually replacing features that use proprietary Sun classes. They have done that to a certain extent. Again, it takes a long time, but they are working with us. They've also spent quite a lot of time in re-implementing the JDK loader, this JVM framework that actually makes it much easier to load a free JDK, well, a different JDK. So, such as a JCG? Yes, such as JCG, yeah. Okay, should we talk about 64-bit? Well, this is a project number, what was it, 284 in our list. It's actually from a 64-bit, and do you have a 64-bit machine now? No, do I. So, it's one thing that we've not actually per... it's not an itch that we personally have to scratch yet. It's an ongoing effort at SunSenseeers. They have at least two CVS branches for next now. Where the... CVS branches. CVS branches. Where the last one is still open, and now it's not yet finished. And Sun apparently doesn't do much work anymore, at least I don't see one. But some people from the community do now, and there is some slow, but steady progress. At the moment, rumors say it should build, it should start, but it should not be able to open documents. But at least it's a promise, it starts and builds. I should give you some background to this. OpenOffice started off a style office, and it was originally 16-bit. There's a lot of legacy code, and there are a lot of base classes that he used that make assumptions that you're not expecting to see 64-bit environments. So it's a case of going through all of the code and making sure that things work. You've got conversions from pointers to 32-bit integers, for example, and back again. And it's pretty fundamental. You have to go through and make sweeping changes to types all across the code base, and because it's so big, you've got a good chance of breaking stuff. So there are a lot of people that want to do it, and there are people who have been working on it for literally months already. It's just the code base is very big, and it doesn't all come quickly. Yeah. How big just to get the feeling of that? Code base. 8 million lines of code. I think 1.1 is 76, it's big. 1.0 used to be 70,000 swabs fast, and there's more now. My laptop here is a Pentium 3600 MHz, and it takes over a day nowadays to build open for some less. What does the ARM build demon take? For 1.1, it takes 7 days. That's actually one thing that we could improve a lot is to split things up a bit and not have to build it's one big chunk. The problem is that the current system works really well for the people at ARM because they all sit on the same network and they have an engineering department that set up servers, they've got NFS mounts with all of the source code. They don't even have to compile it themselves. It's actually, it will compile in a really modular way. If you actually look at the build scripts, you can treat each project separately. It's just that they like to distribute the source as one big block in 10 minutes. Wouldn't it be appropriate then for either the Debian project or some other open source player or distribution to basically ask IBM and one of the compatible manufacturer to basically loan us an SSH connection to a faster machine like a 1 or 2 MHz machine for both of the main architectures if we had hardware sponsoring. The problem with a remote machine is that you can't actually hack on the code so quick. And as I was saying, you can actually do incremental builds. The build systems fail sophisticated and you don't have to build a lot to do incremental stuff. If you're actually working on the code you don't need to do a lot of building at all. We've even got scripts that will link your active build tree into your system install so that if you're working on a slow machine you'll have to wait for the few source files that you've modified to compile but these will then be linked together into a shared library pretty quickly without having recompiled the rest of it and you can actually get the working out of this working. So it's really the speed of the machine that you're working at that's more important than the speed of the building. I mean, at Debian we have the build infrastructure and once we're ready we can upload it somewhere and it can go. What has been done is the tinderboxes, for example, to actually repeatedly build stuff. Novel, for example, sponsored machines. But if you think that's a good idea we'd certainly appreciate more help with hardware so please help us do that but we just don't have time to go and chase do political stuff as well as the packaging. Because one example that comes to mind that might be useful that happened recently is when the Mac Mini came out a bunch of powerpiece enthusiasts basically paid one to Benjamin Herringschmidt, the main kernel coder for PPC. Of course now we're talking about a fairly affordable piece of hardware, about 500 euros. But basically I'm thinking that what if company basically sent you, let's say, for six months some 64-bit hardware just to make sure that you get the part up to the perfection and then at that point we can resume using only the Debian Build D system. Yeah, actually personal hardware as you're suggesting actually getting a machine sent that would help us. We've got one back in the air anybody who's got a PowerPC machine will probably know this one. We've had, this is our oldest important bug the top one here and several duplicates that it crashes. It's really easy to reproduce if you try to load the bibliography but until recently neither of us have had a PowerPC machine. René's now got one but he's established it. I just tested it with a milestone and it didn't crash anymore and oh, lucky, okay, fixed. But the problem was I have this laptop since two months or so and before that I wasn't able to test it in any way. So... Yeah, that's made the idea of the machines. Did I get through my list? I live a project, did I mention that? Just that we've been moving stuff over to there to make it easier to for people who want to get involved to actually do something. One thing that we could do is is there anybody here who'd be interested in having a tool through our website? It's very out of date nowadays. There's the latest news. February 2005. Oh, we're done. Okay, I haven't done a user. But just somebody who's interested in the status. For example, the tool that was mentioned. Nowhere. Yeah, that's a true version too. Just somebody who's interested in following along a little bit and keeping up to date with what's going on and maybe saying on ISE what do you think... what do you think go 2.0 statuses or something and then just actually writing it up on the website, for example. That would be a big help. We don't really get a lot of constructive help on the mailing list. It's usually bug reports or complaints that the team haven't done this and that. But we really are open and we would like to help. Go on. It would help if the first paragraph of this web page would say that the team is two people because it implies that well, some people are working to get open of this running on Linux Alpha. It implies really a lot of people. Okay, this website implies a lot of people. This sentence is mainly referred to people who did the architecture part upstream. But you, of course, are right. We have more or less the same problem as the video game or security team. It's also written that it's a big team but it isn't. Okay. Yeah. Any volunteer? Okay. Any volunteer? Great, thank you. Anybody else volunteering? Yeah, great. That's good. We've had quite a few questions from Martin, isn't it? Cue Frank is I know you. On IRC. So yeah, that'd be great. We have our own channel and we'll sit there and answer questions when we... Please come and join us. And thanks everybody personally. Thank you.