 I think I will start now. Like last year, we did a little buff on ideas and things we could do, so I would like to repeat that because we actually got something useful out of it last year, namely render profiles which is waiting to be released with the next version of Lintian. I have put down some possible topics we can debate when you're free to well to propose your own. So are there anyone who wants to speak about any of the topics here? Want to know more about those or have a topic to propose? There? Maybe another. 14. So if there are any suggestions or ideas, what Lintian is? Okay, I suppose I could give a short run on that. Lintian is our static analysis tool for checking packages for common sets of errors. It is currently used on upload to check for a number of FTP master object text which actually objects packages with these tags in them or these laws. So it's a tool which is quite helpful for most maintainers to find out if they have made a common mistake or a serious mistake in their package and it detects a right range of things, not that, but it detects a range of things from spelling mistakes, common ones to share things like package mileage, I mean broken packages to missing fields and possibly missing fields. So we have our, is that a question the Lintian extra one? Because it's also in the top. Right, checks requiring internet access. I am inclined to believe that would fall on the Lintian extra as would checks requiring or using the up cashier or packages files on the system. Although the idea is great, we did have a suggestion for using the up cashier for checking broken dependencies or so. Basically one of the design choices in Lintian has been that we do not rely on the system state in most cases, almost all cases. So they would fall under Lintian extras as a non-official Lintian check most likely. That or they would fall under the static analysis framework where you would be able to use the banners that we would refactor part of the Lintian code. So you could hand our code package, we would unpack the required things you need from it and you would do your own check, which does not have to comply with outputting a tag or so. So one of the new, there was a question? You mentioned there multi version and architecture support. So in the in the past there have been a few checks that we've been unable to perform because we're essentially only checking one thing at a time. So it's difficult to check for things like file conflicts between packages that don't conflict with each other, for instance. Is that something that you're thinking of gluing into the same framework? You're saying with the architecture saying the multiple architecture? Right. So that's processing modules at the same time according to your gobby notes. Could that extend to the text of what's happening in parts of the archive so that Lintian could do more accurate checks on the interactions between packages as well as on packages themselves? Yes. To clear, let's say how, the multiple version architecture support would be not for archive wide scan. What I had in mind here was if you hand me the old version, the old version, and a new version of a package, it could do, for example, file conflicts due to files moving in the upgrade, but it wouldn't be for Lintian devian.org. But there was actually someone who proposed that we did have the stable version of all the packages, and then we would also do the upgrade test from stable to unstable as the same way of handling that. That is actually a valid point we could put on a layer. Now, multiple version of Lintian architecture support also includes a part that some people use as a merge changes tool to merge multiple changes from multiple architectures into one changes, and then just doing one upload. In the past that worked, but after I added group processing, it broke horribly. In the past, it has worked because Lintian was doing things in the right order for the wrong reasons, and it just happened to work. But this would be actually giving official support for it. And if combined with a static analysis framework, perhaps we can do even more sophisticated checks, although not on Lintian devian.org, or not as a part of Lintian, but people in this room might set up some check using this. So are we getting something? Among the other ideas I have gathered is this, the last one here, about using a domain specific language. If you happen to have looked at the Lintian source code, there is at least one of the checks, which is a huge loop consisting of a thousand line loop doing if file matches something, some regular expression, or is in some list. We would like to see a dependency. That must imply dependency, or else you get this tag, or you have to do this, or that, or together. So there is a potential here to refactor a lot of the code while writing a fairly simple domain specific language, which hopefully would cover a lot of the cases and simplifying a lot of checks. And for the rest of the cases, we would fall back to the standard code we're using now. That is awesome idea. Analyzing bitlocks for common potential problems. There you go. Yeah, there's a bug of report on that. I don't think Lintian could support that reliably because it involves analyzing locks, which have a variety of different output formats and whatnot. But I think we could add that under this as an application for a static analysis framework to do that. That being said, I wouldn't rule out patches that could use something. But most of the severity of things are static. So when we start the run, we can't change them to be more severe. Yeah. It's an easy way to get all build logs of the Lintian run from the Lintian build. It's just a matter of great queries. Certainly. But it's, I'm not certain that the other Lintian maintainers will approve it. We'll see. Yeah. Lintian isn't allowed to depend on that network because you want reliable results. You want the same results every time you run it. And if there's network services involved, you probably might respond with something else and you get different results. And that's not in the aim of Lintian. So the reason I want to have the build block analysis in Lintian is that we have very different places currently where we analyze build blocks. That's on the build list, on a case-by-case basis. In IA64, we do reject some package uploads by warnings. Did? Okay. And we do have some issues with passing build flags due to the compiler, which does not happen in many, many packages. And we do not have a place to catch these issues. And if I look at the output of Lintian, I think it's the correct place to do the checks. To have all these checks does not on a C-flex or does ignore some warnings from the compiler to have them together with the other Lintian warnings. And I think it's a very fundamental thing to have. As one of the build team maintainers, we also would like to have some thing that checks it and maybe rejects or not uploads to package-based warnings like IA64 used to do, but it doesn't do anymore now. I think it's not an issue of the build team maintainers. It's an issue of the package builds and to have a common place to collect these warnings. So just, well, I would like to see Lintian not, well, that you have the build logs as an additional resource and have the results presented with the other results. Okay. Lucas has one. So I agree it's important to have all warnings and errors about packages displayed in the central place that the maintainer will see them, but I'm not sure if abusing Lintian for that is a good idea. But the problem is that if you, when you run Lintian on a package, you get to see the warnings about the package that you just, that you are working on while you would see warnings for some things that you need to, which you need to upload the package to get it fixed. So from a Lintian maintainer point of view, the problem in analyzing build logs is that it's not really a part of anything. Currently, we check their packages, we check source packages, which is basically the DSC file from where we extract the tab balls we need. Adding, sort of injecting a build log into the source file, which source package would be the central, the best place to do it. Because else we would analyze log for each binary package. It's still difficult to do that, injecting it, at least in Lintian itself. I am again thinking a lot here, referring it to the static analysis framework and search, including external data to be injected together with it. It's not, obviously not going to end up checking your package when you upload to the Debian archive, it's not going to, well, end up in Lintian Debian. They're all unfortunately in that way, but it's currently my best guess if I look at it. It's back on DPKG where we're considering adding, storing the build log and listing it in the changes file. So, in theory, it would make sense, but unfortunately, I fear that the interest is going down in this because once we have throw away depths that we upload and that all the builds are rebuilt, all the other packages are rebuilt on the server side, it's not going to be interesting anymore. So, I fear this bug will never be fixed. In theory, it would make sense for Lintian to also check the build logs if it's associated to the source package via the changes file. Yes, if that part was done, we would technically have access in Lintian terms to the log file and we could use the group processing part to analyze the log or just the changes itself. From there to actually doing it, I see a couple of problems personally with actually doing it reliably since the output moment can be very different in some logs. Well, some logs just say compiling file and that's it. You get a list of files compiled and you don't get the actual command line run. So, in that case, we would be better off passing the entire build system of upstream which is not entirely trivial either, but yes, we could look at that but I would wait till we actually have the logs with the changes file for that. Another thing I could bring up is this part here with getting more developers. Before I joined, there was over 200 bugs rotting on the BTS, now we're down to 192 for bugs rotting. So, if you're interested, we do need man powers, especially we need diverse developers. So, a common thing among Lintian developers appear to be the Duperl and some of them are either on the policy team or in the release team but we have very few Python developers or actually from a lot of teams, corner teams and that also means we don't know the internals of all the policies for the teams which makes it very hard to write reliable checks for them. So, if you are working on a team and you feel your checks or policies are not there you could feel free to join us and we'll try to help. So, who did this one? Could you explain what you mean with this? Do you hear me? Kind of, give an option if you know that you are breaking a law or a rule but you have to do it for your internal packages to install software in opt or whatever and to have a global override option so you can apply a specific kind of pattern to your packages and just ignore some stuff. I am actually very pleased to tell you that with the profiles you can just write a profile that makes it ignore the given tag so with the new linch and release coming in to release that actually ought to be solved. Okay, cool. Is there anyone here considering to do a linch and divin.org setup because we have been, I know of other than linch and divin.org we have some derivative, a single one doing it would help from Ross directly but is that something people are actually interested in doing? There have been a couple of attempts to do lintyandodderbridge.com for the obvious reasons. I think that the last person who tried to do it wandered off at some point. I don't know whether it still possibly got stuck but do you know if there's anything on Ubuntu wire at the moment? There's nothing on Ubuntu wire currently. The main thing that has been blocking me is trying to get away to get some of the hard coding that are in the harness script rearranged so that I can run them in an arbitrary location cleanly and safely. Ah, okay. The documentation from the previous person was useful but incomplete. Okay, so if you're interested feel free to follow up afterwards and we can look at it. I have been working on cleaning that part up actually. We have here a code that is called is about according to I think we had a part of that, yes, last year with the scope of lintyand I can't really remember what the outcome of that was. I don't suppose anyone here remembers. Okay, I'll take that back with me. But there is a chance that we will, actually the CPP check we will probably just leave as it is because we already have a separate service doing CPP check already so there would be not much idea in doing that. And I think the other one after CPP check I think that's one SAG is working on. I think you would fall under the static analysis framework at least we have mentioned that idea to him. But, so, quick quality. Okay, any other ideas, useful things that you hope lintyand could do for you? That lintyand doesn't do, something lintyand does it shouldn't do? Do you find lintyand useful? Well, that's a start. That's a neat something. So, should we start working on box now that there's nothing to do? Okay, that's one. I have to admit I didn't check this before asking that. Is there some guy that explained how to write lintyand checks? And the second part is probably we need to make the process of writing lintyand checks as easy as possible. The idea of having a specific language is good, in my opinion. But in general everything that makes it easy for people who don't want to understand all the things that make lintyand works they should anyway be able to write tests, for example for their team, for their language, for what they're doing. I'll just jump down to Nurnia. I think we should be really pretty... I don't know if there's been much work on a DSL so far but I think we should be really pretty careful about taking that approach. You'd often find that writing checks involves... You need general language facilities quite often. So you need to use... Maybe not all the features in Perl, that's probably impossible but you need to use an awful lot of the standard features of a language in order to implement a check properly. I'd be a little worried about ending up with a DSL that wasn't useful enough for writing checks until you got to the point where it was a bit as complex as Perl where you basically had to embed chunks of Perl into it. I wonder if beating up the library is a better approach to that. Are there people who are trying to write lintyand checks who are just scared of writing Perl or find it very difficult to write it? That's very loud. I only ever wrote one check but I didn't find it very hard. I'm not a Perl okay, I'm not a Perl wizard, but it maybe took me an afternoon to go from, oh I should write this to send a patch. I think it's not... I understand that empty people's experience might be different but I don't know, my experience was okay that there was enough hints and document. Anyway, for what that's worth. Yes, I also wrote one of the lintyand checks more or less recently and if you are hanging out on RSE in the DBNQA channel, Nils usually is around and very helpful and responsive and including the tests, it also didn't take me much longer than a day but yeah, I know I have quite some experience myself so I'm not one of the Perl's. Right, as usual writing the test takes the majority of the time as usual for a test-driven program but I think the original driver for that was being able to embed fragments of checkiness into policy and then being able to extract those automatically out into lintyand. I don't think that's ever really got past the stage of an idea but I think that's where the idea of a DSL came from. Okay, that might be it. Actually on the test I am pleased to announce we got around over 70% coverage now of all tags 80% if we look at the old legacy test as well but we're actually progressing thanks to people including tests in their patches. Are there anyone here who would like to work on a check? Have something in mind that lintyand could check for but it doesn't do and they haven't submitted a bug report for it? I do might have some ideas but I just don't get lithium right now. Are you scope and design, for example? Limitations in our design and such? I don't get it. I haven't read anything about it. Right, that's not what you can do there. But refer to come talk to me afterwards. Another thing I happen to know is that we have some won't-think bugs against lintyand which we leave open for the sole purpose of well they are a good idea but lintyand cannot do it due to limitations or design choices. So have anyone actually checked it out and considered implementing some of these or do you think it's a good idea for us to leave them there? I just had a question. Does the lintyand team look at overrides in the archive? Sorry? Does the lintyand team look at existing overrides that package maintainers have added for stupidity or for whatever other reasons? I am not sure how many are checked so actually in that department I think we are trying to be relatively civil. I don't know, we don't have the test upstreams but it's a big file for IBSC which was I think filed by Ganneth a while back so I don't think we have any of those. No I mean are you... Are the lintyand maintainers looking at the overrides that people have added to their packages to figure out why they've been added and whether it's just because the maintainer dislikes lintyand or because there's an actual bug or... Oh you mean the patches? No the overrides. Oh no, overrides. We accept overrides at face value. In fact when I have looked at the lintyand deepend.org occasionally I have found packages where I suspect the maintainer simply just fills the overwrite file automatically from a running lintyand. I didn't check the rules file it might actually have a sample I can produce but I didn't check. But sometimes you see a list of overrides and you think this one is a two click thing you can fix in the description. It shouldn't be too hard. What do you think should be done about such people? Well I have to remain professional. You on the other hand, go ahead find a bad and... Now I mean I don't understand then desire to automatically overwrite everything in it if you don't care what the lintyand says just upload it as it is and if it doesn't have any fatal tags you can largely ignore it except for your peers might knock your head off with whatever warnings are narrow as it shows up but... So a follow up to that is there a way to put a comment associated with an override? No, long standing wish list item actually and I did try to implement it once but I ended up giving up on it but it is on my to do this somewhere down there but yes, here you can add comments in the override itself but we don't extract them so the problem is they don't show up and they can do it all for example Any other ideas, proposals? regarding the overwrites and others? Alternatively I can sell the part where we implemented the new profile stuff that overwrites in some cases can be ignored we have done this for the fatal overwrites fatal algebrajects so when you run lintian the common version of lintian will not allow you to override fatal tags in the standard dbn profile so you should actually see the same output as the fdpmasters radio on On this item here that is a good idea but we actually have quite a lot of bugs in lintian itself to fix so we are actually not very active in contacting outside people actually in relation to that it says in the lintian manual we will file bugs so you shouldn't do it unfortunately that is not as true as it sounds so if anyone is interested in working with filing bugs based on lintian tags maybe I can hook you up with something to do it might have been there is the possibility of taking the serious tags with a certain severity extract those from the lintian files and then check those packages that have that particular tag and just autofile it if you are interested in doing a script like that feel free to drop by also it might be useful there is a question if anyone wants to do that, talk to me because my own archival script could help in not filing duplicate bugs can you write a line here for the notes that would be great no I just thought about it at that point too any other ideas? I didn't suspect as much okay, you have a question one last idea for ideas about how to get ideas for new checks read the devian mentors list and review packages and you'll find lots of problems that possibly aren't yet checked by lintian I'm already following the devian mentors list I'm not actually reading mails to actively anymore unfortunately as it is we already have a lot of checks request for checks filed against lintian.org I tend to work on the easiest one to keep the bug count down which looks prettier it's not because I don't like the other checks particularly but it's just a question of keeping it down and keeping my motivation up actually going looking for them for extra things is a little like shooting myself in the foot right now if you feel like helping, you're free to check these and come up with the suggestions usually it's not that hard to the simple case is usually not too hard it's three or four lines of protocol so that is very welcome also the tag descriptions could use a lot of updating occasionally so if you see people not understanding the tag descriptions blog reports and that is very welcome as well incidentally if there's anyone working with pearl and translations translating tag descriptions was actually last year and we haven't worked on it so if anyone's interested in that we could also have a look at that in that case I don't really have a lot of things to do other than keep asking you for more ideas I guess if there's nothing else I will just end early thank you for this