 Please welcome Steve Komalik. I hope I spoke it nearly as correct as you liked it. It's close enough. Okay, thanks. Talking about his obsession. So, Steve, please. The stage is yours. Thank you. I wasn't going to start this with a bad joke, but I may as well. So, you know, obsession by Stephen Kaye, my new fragrance. I'm hoping this better than the one I did in LCA. Hopefully, due to the fact that I have more than one talk, I was traveling to LCA and I went to a wedding reception in Yass. And I was with the mini-con and said, Oh, would you like to win tomorrow? Oh, all right. What I hope to cover in this talk is a give you a short trawl through the milestones that I've passed or stumbled over while developing Linda. I plan on taking you deep into the guts of Linda and showing you what makes a tick. And I'll go over what you might want to do to help me out. And then I'll show you what I think I might want to do for the future of Linda. Well, I'm aware that LinkedIn already exists. Where's Jiren? Where are you hiding? I'm aware that it exists. But actually, at the time I started writing Linda, LinkedIn was obtained. Mine was, I felt it was unmatched. My opinions of the code are still colored by my first impressions of reading the pearl. You know, and it doing things like morning about Vlipsy 6 that haven't actually for the last three years or so. You know, much everywhere. And being a twisted mash of shell and pearl just doesn't really give you all that fuzzy feeling of, you know, no false positives and stuff like that. The second reason is I wanted to learn PIN. And I found the best way to do that is to actually think of something and start writing it, you know, going through a tutorial or something. And the third reason is I have an utterly unhealthy interest in policy. I don't know why, but I get excited when there are new versions of policy released and I watch Debbie in Dash Policy at list.d.o with unhealthy obsession. So first, Linda actually started life as Lisa. And when it was shown at LCAO, I got a few ideas, some of which are still actually in Linda today. The main thing that I looked away from that talk was AJ. I don't know who he's here. He sort of said that Lisa's already used by the Katie package for handling new and by hand packages and could you please choose something else? So he suggested also the fact that it starts with LIN and I liked it so it stuck. So the rest of the conference was actually spent rewriting the packaging and making her like the new name. I announced Linda to Debbie in Dash Develop on the 16th of March 2002 and I made DWN four days later which March. Linda 008 complete with a stupid typo was uploaded to the archive on the 4th of June and made it through new six hours later. The next big milestone was 0013 which added support for changes and new devs. So the next milestone was 1.0 after 0018. I thought I'd fixed enough bugs to actually warrant a major version jump. The next thing of note was actually kind of fun and I implemented in 013 which is multiple output formats. I'm pretty sure most of you have actually seen them but I'll show them off anyway. We just pick a random... Oh, bollocks. Well that's VNC Wreck being dumb but don't hit tab. It's just a random package I happen to have in the directory. The next mode is even more fun. Anything to say for yourself? Well they're mine. Then a 016 actually included a POT file. I didn't actually have any idea how to do localization or internationalization then but I started generating one so it's got to count for something. Linda 00112, James Troupe, Matthews Close and myself implemented a way of seeing if a binary indirectly links against two different versions of the same library. For example you've got a binary that links against two libraries let's call them library A and library B. Library B links against library C and then the fun starts when library A and library C are the same library with two different sovers. I actually have an example to show you. Someone's already screwed up the C++ transition and has uploaded their package too early and they would have actually caught this if they'd run Linda across their package before uploading it. Since you've embarrassed me, why don't you show us who maintains that? Alright. I don't think they're here. Uh-oh, that'd be in JP. That's again. So the next milestone was 0.2 after I'd actually rewritten enough to consider it good enough and true to form it took another four releases to actually stabilize again. In 2.2 I actually got rid of the dependency on Python app by no longer using app package for version comparison. It's kind of funny getting a segfault bug on PA risk on a architectural package. It seems that the Python app library does something really screwy and causes a segfault of Python on PA risk. Do you know if that's still true? I worked around it by getting rid of the dependency. I'm going to pass the microphone over to Brandon. He'd give the rest of the talk. I think I'll do that in check. In 0.2.6 I tried to do the whole localization thing all by myself. Started passing lang and friends and trying to print out other languages and warnings by looking up description.past.lang like DebKont does in its templates. A few versions later I actually figured out that this was a really bad move. Passing lang is bloody hard. Even then, what happens if you get it wrong? I left that bit of the code alone just hoping that no one noticed. No one actually did because they didn't actually get any translations. In 0.2.16 something quite amusing happened. I was a couple of days away from releasing it and someone filed a bug saying that their package couldn't be unpacked by Linda. I'm checking and actually by that stage I'd rewritten Level 2 Unpacking to fix another bug. That's right, I looked at it and decided it was absolute crap. I'm running Linda on this .deb going, but it does work. What are you talking about? 0.3.0 is the biggest milestone to date. Change log entry is 140 lines long and I've pretty much hit every bit of code. This is also where I start going through the guts of Linda. Linda copped a bootstrapping module, which runs early initialization, but it isn't actually that early because the command line parser module runs first. This is why Bootstrap actually exists because if you need to actually do anything that references the Linda namespace in the command line parser, the Linda module actually imports Linda.cl parser and then if you try and import Linda in that you go around and around and around. So I actually just had the epiphany to add a Bootstrap module to fix that. Collector appeared afresh which encapsulates running file and objump and LDD and other such things. That was pulled out of Unpacker since I wanted 0.3.0 to be a little bit cleaner. I wrote 12 parsing modules from scratch, mainly because the control file parser in 0.2 could be used to scare small children and because most of the files and debbing packages required to be parsed can be actually done with a generalistic RFC822 style parser. A test suite. I know it's a good idea and I've been meaning to do one for quite a while and 0.3 was actually when I finally decided to figure out how to do it. It runs about 195 tests which probably encapsulate about 400-odd warnings. The other scary thing is that just the checks of Linda is about a thousand lines of placement and the test suite is about four and a half. An actual localization of error messages. Has anyone ever tried running Linda in a German locale? Does it work? I fixed that bug. Which version of Linda are you running? Bother. Can you come and see me after? I actually have seen it working though. I promise I'm not picking on Brandon or anything. Does that look correct? I really thought I fixed that. Because I got a bug file against it. I looked at it and went, I thought I fixed that. So German is actually the most complete translation I have even though I've been told it doesn't work. Although admittedly there are a few issues with actually getting translators to work their magic over 530 strings, most of which are paragraph-sized. Related to this change, description files were no name to data files because the descriptions actually no longer live there and are in a POT file. So she does what? The first thing that happens is Python is spawned off, funnily enough because it's written in Python. Roughly six modules in the London namespace are imported. A few unimportant things are looked over like is our installation saying, can it find a few directories and are there files under them? Am I running as root? If it is, it will drop to nobody. And they should specify the minus capital S flag because someone said if I run it as root then it can't read the files it unpacks. Well, it's minus capital S for stupid. And then it checks if there's one or more valid files specified on the command line. We then instantiate a checker object which does all the heavy lifting like unpacking and running all the checks, running all the checks that are in the registry. After all the checks are run, the overrides are processed and then we print out the errors in the warnings, the ones that weren't actually overridden. That's a basic description of what happens. You know, Linda in 100 words or less. There are a few other things that need to be explained like CLParser doing the extremely early initialization like checking your files that exist. And the fact that checks themselves need to inherit from libchecks.lindachecker since that actually provides a few of the methods that you need to actually call to be a sane check. So I've got a little one here. Even if you don't understand Python, I feel this is probably self-explanatory enough that I can just step through it quickly and to show you what happens. Class means I want to be a class. I inherit from libchecks.lindachecker. Def means I want to make a method or a subroutine in Python. I don't know why. The check binary one is special. When the last line is called, the check.register, it actually runs on the class and sees it if everyone checks binary or source one or two and then runs it at that level. And then I just call the newer feature method, which just runs AR and then if there's data.tar or data.tar.bz2 in there, I say, you know, you're running a new, you're using a new feature that is actually allowed. Funnily enough, that's allowed in Ubuntu at the moment, so I don't know what they're doing with this check. So how can you help out? I know I say this every time, but translations, nothing makes my day like receiving an email with a PO file attached that teaches Linda a new language or corrects her skills in a language. Write patches. I have never received a non-trivial patch to Linda. I don't know why this is, you're all afraid of my Python skills or what, but I'd like to really receive a patch via a bug report. Even just testing her, another thing that makes my day is a well-thought-out bug report that says, you know, I run Linda on my package and it does this. And, you know, I think it should do, should do this instead. It's in this check, it's about this line. I don't have any Python skills, so I can't fix it, but to have a look. One of the things that actually annoys me the most is when I get a bug report filed against Linda saying, I ran Linda on this package, here is the error. And then I check, and the package in question is not even in the archive, and they haven't provided me a website where to get the package. An idea for a new test or what you'd consider a false positive test, even if you're wrong, I'll still look at the code and see if I can actually see what it does and maybe just, you know, kick myself and rewrite it because it looks dumb. Linda is mostly undocumented. I know this is hard to believe. But, you know, all the documents actually written are in my head. I've made attempts at correcting this by actually documenting Linda. I've done two small docs, both text files that haven't been touched since about point one. But I usually get bored halfway through or distracted, and my idea for writing the docs just goes away. I'd really like Linda to have auto-generated good documentation. I don't know if there's the oxygen or something like that for Python, but maybe if someone knows anything about doing auto-documentation, come and find me or send me a mail or something. Well, now I'm going to make a complete not a fool of myself and write a test for Linda in real time. So I've got my copy of Emacs. I'm going to write this as a local check, which go under .linda in your home directory. So the first thing to realize is that you need to, yes, you need to import libchecks and checks. Define a class and don't forget to inherit. Yes, it's that hard to read. Does anyone know how I can do that to Emacs then? Run Emacs in the next term. Are you mad? Yeah, sorry, dim the light. Where's the MC gone then? What I'll do is this instead. Where is it? It was something involving... It's the other menu. Really? There we go. Yes. I was doing that before that happened. Is that better? Well, I can read it. What about the rest of you? So now we're switching back to Emacs. Will you people please make up your mind and Control-Write button doesn't do anything? Is the font just too small? Is that what's wrong? Fine. I can do that. I don't make typos. I could. I'm not crazy. Because... Sorry? That's already large. I can go one up. Right. I think that's in a menu. Right. I just prefer this as opposed to typing using, say, cat or echo. So we implement the first method. You pass self because it's going to actually be a method as opposed to just being a standard subroutine. I'm not going to implement separate method calls for this. I'm just going to go and do it. So how about we just make fun of something that everyone's seen before? And so we want this to actually print something out. And so you accomplish that by calling self.signal error. And because I forgot to do this before when I was checking if this actually worked, and thanks to increasing the font size, I can actually see the mini buffer. Let's just hope I can type blind. Hooray! And we say it's an error because we want people to be embarrassed that they're checking a supplicant package. And we'll just check if Linda has actually noticed. And that's what happens when you don't do it right. So I'll just accidentally borrow. Yeah, well, don't believe everything you hear. And it's not there. Of course it's not there. Now, third time's the charm. There it is. And now you'll notice that it actually just types out the string with an underscore s at the end. It means it's trying to look at the short description string in the .pt file. Get text notices that there's no string called supplicant-package underscore s and just returns the original string. I've tried... In the half an hour or so I had before coming here, I tried to figure out if I could make that better. It seems I can't. If anyone has any ideas of how to do that, please see me as well. So looking towards Linda04, I don't actually have any hard and fast ideas. I'm actually mulling over the idea of using Alexa to go through the RSA-22 style files since if you throw Linda something she doesn't understand an RSA-22 file, it does actually just die with like a 20 line traceback. I'm also considering profiling the hell out of her and rewriting parts and see, but number one, I don't know how to do that and number two, I would like to know how to do that. So if anyone knows if that's a good idea or a bad idea, right. And right on time, questions. Has anyone got any? Dancer? Yeah, 15 minutes for questions. I'll finish early. That's okay. First... Well, I had a question. When I release a package, I generally have a script that runs both Linda and Lentian, and then I look at all the different errors and warnings and compare them and try to figure out which are broken in which way and which is my fault. And I wonder if this is ever going to get more unified so I can just run one program that actually outputs all the things that they will check for right now. Well, jump on him and tell him to remove Lentian from the archive and problem solved. I have actually been meaning to talk to Geron about perhaps, I don't know, having some way of having them interoperate. I don't know if that's actually going to become reality, but I can try. The reason I started Linda is because I didn't like Lentian, so that's why there's two of them. But if you really care, you'll run both, which I also think is really good advice. Whereas the maintainer of Bookmark Bridge evidently did not, since Lentian doesn't actually do the double slip check. You've got to bug about that, did you notice? Yeah. No, that's actually... Well, the question was, does the check work if you don't have the libraries installed? I tried to debug this. It's actually quite hard to do it. If you don't have the libraries on the file system. Since Bookmark Bridge links against G++4 and parts of KDE link against G++3, you need the KDE lib on the file system to actually check what it links against. I found that if you don't actually have it installed, you don't get the error. But I thought that this was okay since if the maintainer is running it, he's going to have the library installed so he can actually run the damn thing. Anyone else? Hold on. It does mean that if you run a Linda multiple times on a different system, on a certain package, you can get different outputs because it really depends on what environment you're running in. Also, is Linda cross-architecture? Can you run it on a policy package if you own i386? Yes. I think I still suggest or recommend Benutil's Multi-Arch, which deals with this sort of thing. It will deal. I haven't tried it recently, but as far as I'm aware, it still actually works. At the moment, I'm actually in the middle of breaking FTP, ukdebin.org, by running Linda across the entire archive. At some point, I'm going to run it across not just i386 packages like I am at the moment, but i386 PowerPC and perhaps something like Arm or Spark or something and just see what happens. Any other questions? I know Danza have one. Hi. I'm Junichi Yagawa. I would like to ask about the internationalization aspect. The internationalization what sorry? Internationalization of the strings in Linda. Because you have the strings, the short strings and long strings as a very cryptic string, as some string under the S and some string under the L. That's called the tag. Why are you using the tag as a translation, get text, what do you call it? I can't remember, but get text. Message ID. Not the actual short string because most translators are used to translating the short message ID as the original English. Yes. I'm aware of that and if Christian Perry is here, he's been jumping on me about it since I got here. He filed a bug saying that the internationalization of Linda is just appalling and what are you doing? Basically, get text is designed to take one string, look up another string. I don't want to have the English just in the checks because then if you've actually got two checks with the same text, you then may actually get the wrong long description if they've got different long descriptions. So I look it up by tag. So I'm actually doing what get text was actually designed to do, which is take one string, look up another one, and return it if it exists, as well as a little hack to the Python get text module so that it actually falls back to EN rather than C. But since I think 0, 1, 14 or so, I've actually started... No, not you. Looks like I haven't built Linda. Anyway, what happens during the build process is that the EN.po is actually passed in and is actually spat out into the POT with the English as a comment and the tag as the message ID so that translated should hopefully just be able to change the message stir and then submit it as a PO file and everyone's happy. However, Christian Perry still isn't. He has a question. Yeah, not actually a question but I want to resume our talks together because I think... Well, we are talking now also, but we talked together a while ago and the problem with this system and you know it now, the translators do not notice when you change the English messages. So this is why we still have to improve the things and then we have to find someone who is able to hack down something again. Probably... Yeah, it's a call for volunteers. Do we actually have any get takes tackers in the audience? Yeah, we need get takes tackers to sort this out. All right, you all just have our knowledge. All right. We will find one. Any more questions? Yes, Lars. Would it be possible to rewrite the policy so that it can automatically be... The checks can automatically be generated from that. Sorry, can you speak a little slower? Would it be possible to rewrite the policy, the actual document, in a machine-parsable format that could be used to generate the checks itself? I have one question. Are you mad? Yes. I started this to write a checker, not rewrite policy. I like the way you think. Sorry? I don't implement everything in policy as yet. Patches welcome. This has actually come up before where I actually said you're mad the first time. Why didn't ESR come? He likes writing shit like this. I haven't actually... Since policy just aims to be so well-defined, it's actually, in my opinion, quite difficult to do something like this and write your package must do this. I don't think you can just take policy on its own and just sort of convert it to some machine-parsable format then put it through, then actually pass it and just run it across the package and see what you get. I don't think that's worthwhile because you've also got... If you write policy in machine-parsable format, then you're actually taking away the author's idea of what policy actually means. And I think that's where some of the strength flies, where someone like Brandon can look at a paragraph in policy and just say, I think it means this, where someone else can look at it and say, no, I think you're wrong, it means this. Then you take it to the tech committee and sort it out. But... In two or three years. In two or three years, yes. Any other questions? But if someone actually wants to do that, Patches are welcome, I'm guessing, either to dev in policy or Linda. No one else? Right, thank you for your attention.