 I'm going to go ahead and get started. This is the LinkedIn boss for anybody who's no-one-clenched. Hi. My name is Russ Albury. I'm the most active LinkedIn maintainer at the moment. And I don't have anything particularly prepared to swap this kind of schedule for the last minute. But I do can talk over sort of what's been going on with LinkedIn for the last year or so. And then sort of what I see is the big things that are out there right now that probably need to get done to it. And then I expect most of this is going to be a general discussion. So feel free to interrupt me or whatever as we go. Also, I talk too fast. So I'll try to slow down, but feel free to let me know if you missed something or whatever. So I've been working on LinkedIn for about a year. It was one of the first things I did after I got out of NM. And at this point, we're in a happy state where we're under 100 bugs again. And there are no bugs with priority higher than which works better. LinkedIn is sort of the general goal. LinkedIn is a standalone package checker, which is very important and something that not everybody quite understands. The idea of LinkedIn is that it does static checks on a single debut package. It doesn't know anything about the rest of the archive. It doesn't know anything about any external data sources. It doesn't know anything about the bug tracker, about open bugs. You think along those lines. And that's very intentional in its design. There's a lot of other interesting QA things that you can do in the archive if you look at the whole archive or if you also look at the bug tracker. And it's great for other people to write those, maintain those. The goal of LinkedIn is to be something that you can run on a single package, hopefully relatively securely, even if the package is nasty. And if you want the same version of LinkedIn on the same package, you should always get the same results, which is important for us to be able to maintain lyndian.deity.org and have it's output be stable. So LinkedIn has a variety of bugs that are priority wish list and or tag won't fix that we keep open because they're basically ideas for how to do cross package checks or full archive checks that no one has implemented yet. And I just keep them there and open because they're a pretty reasonable repository of ideas for those kinds of things that people will do. They won't ever be done in LinkedIn itself because they're kind of outside of design parameters. So it's an interesting place to look if you're looking for ideas for things to do across the archive. The top, my top priority in LinkedIn is to try to get rid of as many false positives as I can. That's the reason why I'm particularly happy that we don't have any bugs that are higher than priority wish list that are still open. Wish list bugs are usually requests for please check this, please check that, please look for this thing that we aren't looking for currently. The reading thing where there's a false positive where LinkedIn diagnoses something that it shouldn't priority higher than that. And I try to get all of the clothes before each release of the LinkedIn. There are a few places where LinkedIn just can't, the check that you want LinkedIn to do is very useful and just is gonna have false positives on some packages. And so for those who just tell people to use overrides and there are a few of those, but my goal is to get all of those where if you have this and it really is legitimate you should use an override, documented in the long description of the tag. So when you run LinkedIn-i, you should see in the tag description if this was intentional, please use an override. A really good example of that is setUID or setGID programs. LinkedIn by default will produce a tag for every setUID or setGID program in your package. That's not necessarily a bug. It may be something that's entirely intentional that's what the package should do. But I think that the check is useful enough and it's important enough that you be aware that you have setUID or setGID programs in your package that I wanna keep that check. But that means that any package that has a setUID or setGID program should add an override that says yes I know there's a setUID, setGID program. So that's kind of where we're at right now. I don't have a lot of time to work on LinkedIn, but I try to go back and implement one or two of the wishlist bugs each time we do a release. Sometimes I get to more of them. There's certainly a big opportunity for people to help out by looking at the wishlist, find some checks that you think you could do or that looks cool or whatever and plan it and provide a patch. I, you know, it's great to have those patches that makes it my life a lot easier. We can integrate those pretty quickly. The, the LinkedIn.dev.org was down, was not being updated for a while for about six months or so. Fixed that recently. It's now running the latest version of LinkedIn again. It should be relatively up to date. I went through LinkedIn.dev.dev.org after I resurrected it and looked for false positives in some of the obvious places and cleaned up a whole bunch of them. But it's another good place to look. It's a particularly good place to look if you're looking for false positives where LinkedIn is doing, getting something wrong, that nobody's bothered to report. Because you know, LinkedIn.dev.org you can page through and see how does that look legitimate and does that look like a real problem. There's a note on LinkedIn.dev.org and I mentioned this in another talk that says that from, that people shouldn't file mass bugs based on LinkedIn results, that the LinkedIn maintainers will do that from time to time. Well, the LinkedIn maintainers aren't doing that from time to time. I don't, I really don't have time to do that. And neither does anyone else on the maintenance team. But, so it would be if anybody wants to look for LinkedIn tags that look like they represent real archive problems and start looking at doing mass bug filings based on those, I think that would be a great thing for somebody to volunteer to do. Please talk to us about it first on the LinkedIn mailing list because in some cases the tags don't represent problems that are of sufficient severity to warrant a mass bug filing or there's a known place where the tag isn't really entirely accurate. And sometimes there's in one tag is better than another for looking for a particular problem. That's generally where I think LinkedIn is at right now. Where I think it needs to go is that right now LinkedIn has exactly three levels of tags severity. There are errors or warnings and there are info messages. My goal, I think that it should be possible for just about any dead end package apart from the override thing that I mentioned earlier to be clean, LinkedIn clean on all three levels all the way through info. I check all of my packages with dash capital I and I clean up all of my info tags. But there are a lot of info tags that are for problems, that are for problems that not everyone agrees are really problems or that affect so many packages and aren't particularly important that they sit there at the info level. A good example of that one is in terms of any Amrock specification if you wanted to enter a literal dash as for like an option and a command page you're supposed to put a backslash in front of it. And that's been the case since the beginning of the whole Amrock. Lots of upstreams just don't do that because it's always worked. Unless you print it out of your man page using GROF and PostScript and actually print it on a printer you can't tell the difference from in the GROF and the man program and most distributions between having a backslash in front of it or not having a backslash in front of it. And even if you do print the whole thing out it isn't completely obvious what the difference is. There are some subtle differences though because if you don't put the backslash in front of the hyphen GROF will consider that a point at which you can break the line. So if you've got a long option like you do long options and you don't backslash the hyphens GROF will wrap in the middle of the hyphen and in the middle of the line do other weird kind of things. Also for a while we turned on support in GROF for unicode hyphens. So you've got real hyphens or real dashes at which point if you don't have a backslash in front, when you search through the man page for a dash something you don't actually find the option because it's not a dash, it's an actual hyphen. Anyway, so Lyntien notices those, Lyntien diagnoses those. However, there are tons of packages in the air tag with this problem and tons and tons of man pages with this problem. And eventually the GROF maintainer just gave up and went back to making dashes dashes even if they're not backslash. So that's an example of Lyntien info tag and there are a few other things like that in Lyntien where it's just kind of sitting there and it is a bug but it's just not a bug that's higher than a priority to really get an exercise to that. But the three severity thing is really limiting and the difference between errors and warnings is often kind of fuzzy. Errors mean it's a violation of a policy must directive or it means your package just won't work or it means it's something that's really severe or it means it's something that's kind of severe but we're really certain that it's actually broken or it may mean something that's not that severe but it's so easy to fix that you should just fix it. But all those things are errors. Warnings are things that are like incredibly severe except that we get it wrong a lot or they're things that aren't particularly severe or their policy should violations or we weren't sure if it really could be an error so we made a warning and then there's the problem that a lot of people do from Lyntien rather than giving it any options so they never see the info tags. So there's two, basically error and warning are the tags everybody sees and people for when they say the package of Lyntien clean usually treat them pretty interchangeably and info tags, you know, a much smaller percentage of people ever even see them. So that's not particularly great and it doesn't let you do some really interesting things. The other people quickly know what you've been wanting to do. For example, it would be great if Lyntien knew which tags in Lyntien came from policy directives because then you could do, run Lyntien and say, show me only the policy violations. I don't care about, you know, what some, what the man page for deadvelvers said or what, you know, what the deadvelvers reference might have told me to do. I want to only see the policy violations. And the error, so you might want to see only the developer's reference violations or thing along those lines. So the idea of tagging with the source of the check is I think pretty important. The second thing that I'd like to do is we have this severity mixed in with how sure we are there's actually a problem. Those should be separated. There should be a severity, which is policy much should or recommends or is your package broken, your package might be broken, you know, that kind of a level of thing. And then there's Lyntien's really sure. Lyntien's kind of sure. Lyntien is not sure at all on a kind of a different metric. And so it needs to be those three different types of classifications of the tagging Lyntien. If we, once we have that, we can do some really interesting things. For example, you could have DAC run Lyntien with flags that say only show me tags where Lyntien is sure it's a policy issue and it violates a must. And if Lyntien returns any tags, it could reject the upload. You can't use Lyntien to reject uploads in DAC right now because there's just too much other stuff in there and including stuff that not all the developers agree with. So that's a big project. That's gonna be quite a lot of work. The tag code in Lyntien is pretty complicated. And we need to figure out a fairly rational mapping because people, you probably want to generally map the stuff back to error warning and info or something very like it for most of the time. Most people are giving these extra flags or at least simplify that because you give people a three dimensional grid point at the beginning of each tag that's probably more information than they actually want. And we also have to of course go through every check. Many of them do have references already noted in the check, but a lot of them don't. A lot of them that actually have references don't have a reference noted. Some of them there isn't a reference. So we have to go through and do all that classification. So that's a project that I'm probably not gonna have time to work on extensively and particularly soon. But if somebody wants volunteer to work on that, that would be great. And it's something that I do intend to make happen at some point. So thanks of course. And Lyntien goes into the case and the classification. So you also don't have time to work on actually making it possible to do the classification. Yeah. And then the second thing that does need some to be looked at is the documentation. In general, and also the long tag descriptions. There are just, the long tag descriptions need to be edited in terms of consistency. There's a lot of places where they use back tick, forward tick as quote marks, which we should stop doing. There's a lot of differing styles in the way things are presented. In particular, Lyntien.deddy.org does support some degree of HTML markup, but the way that that markup is used and the tag in the long descriptions is completely inconsistent. And we need to track down references for everything that has a reference system. There's also a Lyntien manual, which I don't know if anybody's edited any time particularly recently. I think no, it's not all special, I don't think that's the case, is it one, one? Yeah. And it gets bit old. Well, it has been updated for when it's overriding, so that's about it. So I'm guessing there's stuff in there that's out of date that needs to be filled with. And then I probably, I personally would rather rewrite the man pages for Lyntien and Pod, and because right now they're sort of oddly double spaced in places and there's no kind of weird bits to get at to how they're gonna end up might make them a little bit less maintainable. So there's generally some documentation issues that I think are worth looking at. And then there's also sort of in the blue sky territory, there's the idea that Manoj had for putting together some kind of pseudo code or other kind of technical description of a policy statement in such a fashion that you could write, you could have Lyntien take a pseudo code directly from policy and interpret it as a check. That's definitely way out there. Definitely some kind of thing that would need some, it's the kind of thing that I could very easily see being master's or doctoral thesis. If somebody wanted to take all the work that various people would put in the proof theory and programming and the languages that people constructed around doing or improving properties of programs and figure out how we might be able to describe parts of the policy in that fashion, I think that would be really interesting. I'm not sure that it's gonna happen short of somebody actually deciding that sounds really cool and I have a background in doing proof theory. So that's pretty much what I had as kind of a general overview in a general state of things. I'm really interested in other people's ideas, thoughts, experiences with Lyntien, things that you think Lyntien should do way too each week you can use Lyntien in the project, but I was gonna really wanna get fixed. It's very interesting to do a scroll poll. Who is interested in actually working on Lyntien itself, like the core of Lyntien, who thinks it might be interesting to get into? Anyone? Besides Lyntien, isn't it? And who's interested in maybe writing some extra checks that's like, which whatever, okay, so that's fighting more, so it's all good thing. Like, idea to learn to throw in some nice ideas of what we could do with Lyntien, but you're not willing to actually write both of them. This is also very nice, so, okay. Maybe you're writing new checks before writing additional input. Yeah, but not like in the course, more like in pursuit of how Lyntien itself works and the tech classification out and stuff like that. Writing tests is, that's difficult to do. You don't actually need to understand all of Lyntien, just the checking code, which is much more, much less to understand. I've probably written maybe 100 checks since I started working on Lyntien. I would say that 95% of them are less than 20 lines in total. In general, there's enough stuff there already that most of the infrastructure. I should understand what kind of information is already available and it's pretty easy to do. A lot of checks also are probably similar to some existing techs, so it makes it additionally easy. Backlines of product can be a bit difficult. Yeah, but I mean, a lot of it, I've been trying to, as much as possible, move checks out of code and into data, wherever there's a whole class of tests that we do very similarly. So for example, there's a whole set of tests now for you ran this program out of your Demian rules file, but you didn't build the 10 on the right package. And there's a whole, and now that's basically all data. You can just, you have a RegEx in a package that you have to depend on, and there's just a table you can update, and you don't have to change a line of code. I wanna do more of that. I also, I mean, Lyntien has grown organically over the years and it's kind of messy and there's pieces that are duplicated in different places. There's various things that really need to get pulled out into the library and used in a cleaner fashion. We finally have a fairly solid library for doing dependency analysis that can handle all of the version relationships that we have with Debbie and they can do things like, does this set of dependencies imply this set of dependencies? And I'm digging out now everything, all the different code that parsed dependencies and replacing it with that library, except for the one piece of code that parses the dependent blank was for syntax errors because it has to be a little bit more robust than a regular library. Another example of the kind of thing that needs to get pulled out into a library is that right now we do checks for batchisms in gel scripts and maintainer scripts and there's a few that we're modifying policy to say are fine, using local, using test-a, test-o. I think the general project consensus was that we shouldn't be worrying about that because all of our shells support that. But there's a bunch of other stuff that only batch does that is less common, which we check for in the maintainer scripts right now. There's several bugs out there that say, please check init scripts, please check your dev.nultz file, please check all the other scripts that are out of the package. And so that code needs to get pulled out to a library that can check a line of shell or that can untangle a line of shell or whatever and then call it to several different places, check different scripts. Even better would be something that could actually understand the syntax of a shell script because right now we have a bunch of places where we're trying to analyze post install, other types of maintainer scripts and say, does it call this, does it call that? Do you delete a device file, which policy said you're not allowed to do this, do you do that? And right now it's all kind of regex matching on shell code, which is scary. And there's like all this code in there that deal with the fact that people might put things that you think are a problem inside a here doc. So it's actually not, it's a string and not actually code and it has to detect that. You know, if somebody ever wanted to write a shell parser in Perl that understood BornShell, one team would use it. It would be actually, let us write several checks that right now are just really difficult to do. Stop using BornShell for all the maintainer scripts and use something that actually had, you know, closer to find some antics that wasn't quite as general for, and have like an escape if you really needed BornShell, but I have a package that uses a Perl maintainer script, so I'm probably not one of those guys. In Linda, in addition to the sentimentatus, the concept, what's going on? I'd love there to be more. As near as I can tell, Linda's pretty dead at the moment. There haven't at least, I mean, I'm pretty sure that I haven't installed on my system and therefore would be seeing new packages as they come out. And I haven't seen a new upload with Linda in two years, something like that. I mean, for the production of the game, it's mainly two of them, it's more than I've seen. There was one, okay. I must have just missed it then. Two of them, it was six. Oh, really? Yeah. Oh wait, if it was last week, that would explain it, because the system on which I would notice those uploads is not the system I have, well, I've been busy with something like that. The previous one was one year ago. Okay. Okay. Are active in the diversity of this team? And how does it happen? I don't have a good feel for what Linda does that Linda doesn't, or vice versa. I do know that Linda tried to do some shared library analysis that I think was probably a bad idea that we decided not to do in LinkedIn and that was the source of most of the recent bug activity that I'd seen. I know Python, but I don't know Python well and I don't know Python well enough really to dig into the source code and kind of try to figure out exactly what it's doing. And I don't know if the Linda maintainer had ever really participated in the LinkedIn list or anything. Not really. I've talked to them quite a bit when I started with LinkedIn stuff and I was like, I really didn't think it was very productive use of developer energy to write two tools with the same goal. But we couldn't get to some agreement on merging things on one way or the other. So you can like to like keep writing the code on its own and it was fine with that and it's looking into LinkedIn, whatever there happens to take it over. And well otherwise I said, yeah, just follow the code, I actually believe the internet was in line. So yeah, well, it didn't really go anywhere. Okay. You know, I'd be happy to interrupt to integrate more and discuss more. I don't really have the time personally to analyze one thing and look for ideas. You know, my feeling is that LinkedIn's undergone a lot of maintenance and a lot of improvements recently. You know, we've been averaging about one and a half to two uploads a month for the last year with pretty long change logs. And you know, there's just a lot of stuff that changes about package checking and I think it's, unless it's actively maintained, it's difficult for it to stay really focused on the problem that they're having right now. I mean, stuff like the X-transition, you almost have to get a check or release out almost right away when things start. Because otherwise you lose a lot of the benefit of having to check or pick up the problem. I can certainly understand though why somebody would want to start over with something that they felt they could structure more cleanly than the LinkedIn code. Because LinkedIn code, there's several different structuring ideas in there. It's like a lot of code bases that have been around for a long time. There's a lot of transitions to a better structure that are 90% done. So, and that's a better thing. It definitely does need more work on it. And it's the old, you know, start over versus incrementally changed thing. I used to be a start over person. I'm now an incrementally changed person. But it's kind of a coding style difference. As in the LinkedIn infrastructure, it's not like when you mention them all to apply Python code tests in it. Now it's actually, the tests are included in Chrome instead of executed. They usually executed, then it was really easier. But, well, the LinkedIn code is like, those tests really want to be inside LinkedIn. Of course, it could be worse because it's not like there's interest from both sides to make it happen. But it's definitely necessary to, you know, grow to work on LinkedIn tests. You're not used to Python. This is it. This is it before. Yeah, well, now it's a little bit for the trick here. I mean, it's like not a single example of it. But I'm not, it's not very neat to do with people who would like to really run some use bit of extra LinkedIn codes. And they insist that it wouldn't be the person to do it. I'm not really sure if there are things of it. I mean, I think if it's a comprehensive large check that looks really useful and the implementer haven't used Python, I seriously think we should seriously consider just including it. The other thing is that, you know, I know both Python and Perl and the thought process behind figuring out what the check and the process of testing it on a package is to be sure that the check is reasonable is the hard part of writing a check. The actual implementation is usually not the hard part. So I'm quite happy to have people file Logan's LinkedIn and give me a check written in Python and I can rewrite it to Perl. I mean, that's not hard. The hard part is figuring out what to check and how. That's also true. Would there be any real interest of people to write something in Python instead? All right, so this was for me the interesting part. This is very difficult for Lisa because I don't know anything about Perl. Okay. But I like to figure it out quite. And therefore I was very interested in that. I'm going to develop it, but on the other hand, it would be impossible to write anything for Perl. It's, I never would like to. Okay, yeah, of course that is really. There's a lot of this, it's like coming up with some smart way to actually find, programmatically find some problem that you might as a human can easily see, say, oh my God, what's this thing doing over there? To actually code it into a program that's very often very tricky to do, so. Yeah, and there's a lot of wishlist bugs if you look at the LinkedIn lists that are basically sending, the LinkedIn bug lists that are basically sitting there waiting for somebody to come up with a really neat idea of how to look at, how to try to fix them. How to try to analyze them. Like for example, there's a wishlist bug. There's a wishlist bug that's asking for us to check to see if a Nitscripts follow the policies document in terms of their output format. And that's, I'm not even sure where to start on how to actually do that. Now having a shell parser would be nice. I'll show it to you in the channel. Well, we have another half hour, although if we end up a little bit early so that people can get upstairs or if they talk, it starts immediately when we end. That probably is the horrible thing. The, well, people are thinking about ideas. I would, well, we have a bunch of people in the room I will appeal for, see if anybody knows anything about how I can solve the second oldest bug against LinkedIn. It's one of the nice things about working on the old wishlist bugs in LinkedIn is that the occasional we get to close five-digit bug numbers which are getting increasingly rare, I mean. So there's a request that we check to make sure that all shared libraries are built with dash capital D underscore re-entrant. Policy also says that you're supposed to build all shared libraries with dash underscore re-entrant. It nearly can tell almost all shared libraries in LinkedIn are not built with dash underscore re-entrant. The bug was filed almost eight years ago and I have no idea if we care anymore. In which if we don't care anymore we should take it out of policy because policy still claims that you have to do this. And, you know, that basically when this bug was filed we were using Linux threads and view of C and it was in a totally different world. And I just, so does anybody have any idea the history of that random collection of dev-in developers? And I asked Steve once before and he was like, oh yeah, I think we remember that but I have no idea. So it's sitting there. There was some idea of how to implement it and I haven't implemented it entirely because I don't think we actually want to because the archive doesn't seem to have exploded and isn't doing this currently. But, anyone else with any ideas, comments, suggestions, concepts, can I ask you to talk about how you see LinkedIn working with more than other topics? Yeah. Well, so what are the pieces left for us to say, produce LinkedIn or via mall? For that to happen, it's basically one of the easy things that you could use mall to make the engine of the unit work from it. And it was, yeah, like a package tracking system like overview of each package with LinkedIn test and get free overview of which tags, tag summary on the main page and stuff like that. I think mall is particularly useful for like the things where you want to check packages for the event on the environment so it's not static. And I don't think it's a good relation to mall can help very much LinkedIn because LinkedIn is a static checker and whatever would be nice to do can happen within LinkedIn. I don't really see on the focus itself, LinkedIn, anything that mall particularly can help with, except making it a bit more accessible results. And in supporting mass filings based on LinkedIn, I think mall can be of help by maintaining infrastructure to actually mark a certain tag as, okay, this book is the book that's filed based on this tag or this tag has been reviewed by a human to be a false positive. So, we are, should not monitor it and the rest of the metadata that exists still needs a human to look at them. That's very useful, though being able to keep track of what's been decided to be a false positive. Yeah, that is something that mall can be of position. So, I don't think in the actual checking that mall can be of any significant help at all. It's not the purpose. And as in like checking things where you actually want to find out which symbols are provided anywhere in the archive, for example, that is things that you can do in mall. Now, it's currently no real software doing that. One of the works that was found on LinkedIn, like ages ago, I remember, don't remember the work number, was like checking whether symbols being used which library did correspond to. You can maybe find conflict in symbols across the archive, for example, if you would like from all the libraries in all the archive, extract the symbol name, you can find out which one is conflict and then throw some alerts about that. Yeah. I don't myself very intimately familiar with all kinds of linking and symbol stuff. So, I would definitely need help from people or people with good ideas of what you could actually do, do with mall in this regard. I don't know which kinds of things would cause problems. There is checks for shared library dependencies, SO names and that sort of thing are high on the list of things that people tend to file which was plugged against LinkedIn for. Things like binaries in bin should only use libraries and slash live and not libraries and user live. That's another kind of thing that LinkedIn can't check because LinkedIn doesn't have the idea of the libraries coming from. I'll be using all the inputs implement because you could write for all symbols, you could check which libraries is from a storm where the library is in nice lift or not so intrusively and then give an appropriate alert. If indeed a binary in slash bin is actually using something on user bin. And another example of that is that there was a recent bug file that said asking LinkedIn to check that the Nitscripts that are in the RCS directory that should only use binaries from bin and Sbin because user may not be mounted yet. The currently LinkedIn can check to see if you give the full path of the binary in the Nitscript that it's not a full path that's outside of bin and Sbin but if you use the unqualified name of the binary, LinkedIn doesn't know what package is coming from and therefore doesn't know where it's located. So that's another kind of thing that would check out. Because you first need to map in from my data where it is. Yeah, so that's where I'm hoping to hand off a lot of those all kind of across the whole library. I'll pass the whole archive sort of checks as to the whole infrastructure. I'm wondering whether it would make sense to actually package and make some tool that can go into some or that you would like writes in the video scripts that we use directly into more. It's can have, it is definitely useful to have something you can actually install yourself easily because it's packaged. And I'm not really sure whether that would be possible because it would depend on the mold infrastructure basically to do cross-on archive checks. So maybe people have ideas how it would be possible to have understand the loan program which really uses mold. I mean, if you need to query it a lot, that probably could actually make some remote querying possible. So that's actually when you have on your own system a certain package, you can ask it to use the mold database for them stable remotely. When you are on your own computer to actually get the information needed to product the checks, the archive-wide checks over there. So maybe that would be possible. So that would mean in a new program, new checker program that's not really related to the thing. Of course it's like a package checker that is like separate from the internet. The other thing I was gonna mention actually, if someone has free time to work on Fluteam.dev.inva.org is pretty spectacularly ugly. Because it's basically just the simplest HTML that you can generate from a bunch of tags. If someone who wants to go through and clean up things like the fact that we do an H2 tag, fold an H1 tag, and maybe provide some CSS and make it look less ugly, that would be great. I don't really have time to do, but I don't think it would be particularly difficult. Devian doesn't really have a general theme for web pages, but I mean, if I were grabbing for ideas for what it could look like, I'd probably look at the BTS, the new BTS web interface seems pretty clean and pretty simple, but less of a week. And something similar to that would probably be great. Pearl, again. Maybe also make a new LinkedIn logo. It actually uses the current Devian logo instead of the one before that. And the thing when designed, not Devian's logo for quite long already. Oh, what was it again? Oh, yeah, a new view of a chicken or a pig with it. So, and there's all sorts of interesting data mining things that you can do on LinkedIn that I have thought about, but not actually done. I did recently text the code that Derian's page so that it will tell you how many overridden tags there are, at which point I discovered there's 10,729 in the archive, which seems awfully high. Now, there are some places where we do encourage people to use overrides. I mean, there's probably, there's no right there for almost every SETU-AD program anywhere in Devian, so there's a few. And I know there's a bunch of overrides for some LinkedIn checks around shared libraries. So, LinkedIn will give you a warning if you have a package that contains more than one shared library, or if you have a package whose name doesn't match the shared library name. And in some cases, those are not problems that the maintainer actually should fix because there are things that, if you're packing a new shared library, you should not do it that way. But if you have an existing shared library in LinkedIn where you have a bunch of things that already depend on that particular package name, changing that package name just to match the package naming convention is not really a good idea and the release team doesn't really want you to do that. So, I know there's some sources like that that produce a fair number of overrides, but I don't think those produce 10,729. So, that would be an interesting thing to look at and figure out what people are overriding, why people are overriding it. I know that a lot of those are probably false positives in LinkedIn that this, somebody would be here to have the overrided to file the bug. Or the bug could have been filed during a period. Well, I mean, if there was a bug, I probably found it, but it's hard to tell. Stuff can drop. And there are certainly plenty of tags to investigate as to whether or not there are real problems. I mean, there's 8,054 error tags across the entire overhead. There's 45,854 warnings. The warnings, there's a lot of stuff in warnings and a lot of that is standard version warnings, which you should be aware of when you're uploading your package, but once the package has been uploaded, it's not really interesting. So, you can just kind of filter those out, but there's still quite a bit there. And every once in a while, I go poking through there and look at packages and notice that packages have problems that I think are fairly obvious problems. And then think about filing a bug and then sometimes file a bug we usually don't. So that there's, I think there's a lot that could be done in QA just by, you know, using the data mining results that we've already got here in terms of what's showing up. What if you just say a warning when an override doesn't override, actually, if a test doesn't give a warning and it's overrated, what if you just say a warning about the right, there you go. So it turns out that the delineation does, actually. The problem with it is, well, there's two problems with it. One of them is that it's an info level package. So you need to run Latin dash capital I to see it. That I'm of two minds about because, I mean, I could increase it to a warning, but the problem is that there are cases where a package legitimately has an issue that comes and goes, in which case they may want to just override it, but it may, that problem may not be present in every version of the package and it gets kind of annoying to take it out in and out. I came up with an example of that one time back when I was thinking about this and now the example completely escapes my mind. So maybe it isn't as big of a deal as I thought. So there's an argument that may be made that I could increase that to a warning. I will note though that overrides, that don't actually override a tag that are just kind of sitting there doing nothing are not actually included in that 10,729 count. That's actually overridden tags that Lintian tried to issue. There's more than that that are just sitting out there on you to add user as a couple of overrides that are just not doing anything because we, it was a bug in Lintian the next long time ago. The other problem with that tag, the reason why you probably never saw it even if you were using Lintian at the info level is that for some reason the source code didn't issue that tag unless you ran Lintian with the dash V flag for verbose. I don't know why, but I took that out in the most recent version. So now it's just a regular info tag like all the rest of them. Yeah, probably because it's not pretty a problem that you can think of yourself. Yeah, but that's the kind of thing that makes sense to me in an info tag. I mean it isn't, and that's the real reason why I'm not doing a warning because there isn't actually a problem with the package. There's nothing about the package that's gonna break. It's just a cleanliness thing. One of the goals that I, one of the things I'd like to get out of the more advanced tagging system is there's a whole bunch of wish list items in Lintian that I've not written a test for even though they're fairly easy tests because they wouldn't annoy the hell out of a lot of people. They're aesthetics checks basically. They're stuff like, when you write your dependencies, is it always dependency space open parent, close parent comma space next dependency instead of smashing all the white space together. And some people feel strongly about that kind of thing. Some people like to check that kind of thing when they're doing mentoring to teach people good coding style. Some people just really don't wanna be bothered with that classification in Lintian that's aesthetics checks. It might even be off by default. And people who want that kind of thing can turn on the whole category of the aesthetics checks and include a whole bunch of stuff like that. There's one of our more famous and frequent bug reporters is particularly excited about making sure there are no trailing of white space in any file. And that can sit in aesthetics. At some level, and people who don't care can not care and also ignore this, but. Well, yeah, I've also been successfully doing that, but. If one binary package depends on another and part of the process that I've required and you've made a patient sort of an instance, I mean, dependent upon the packages there, any way Lintian can find the job versus the required knowledge of the total package. So unfortunately not. That's one of the, that's exactly one of the cases where a Lintian long tag description will say, please use an override, is if the man paid you in a different package that you depend on. It's also the reason why Lintian doesn't check for bank links and links, because we would get false positives on every single, on every single library death package because we don't have enough information to know that there's another package out there on that file. Yeah. The Lintian package is a phone call and a package call. And we have an apple for user. Yes. That would be a, I think that would be a good idea. Yeah. There's a link to Lintian already in the column, but there's not, it doesn't extract the information and show it to you. Yeah, I'd like to see an apple on the Lintian. Yes. I've noticed that it didn't have a filter on. We actually do provide that information in a fashion that's even generally useful because we generate this file for QA. Not even looking at it a lot. There's even a post-process form of that file, which we generated for some reason that I don't actually recall the moment. I think it was for the package karma page or something along those lines. But there's a file that we generate, if I can find it, which is, contains only the, it contains like only the number, the error count in every package. And in more, you will sort of have these summaries and the interface should be somewhat similar to a package checking system. Ah, yes. It's in double the reports QA list text. So it's in lintian.debian.org slash qa.qa.list.txt. And it contains, it looks like package name, error count, one account. So QA could just use that and get to generate that pretty easily. I guess you're right. I thought there was more on time now. I'm checking. I think you already provide some sort of information like a number of the use for warning and number E. It looks like there isn't a W or an E in this particular. I think it might have been a little bit. Yeah, that's a good idea. Thank you. We have about 12 minutes. Okay, good. I'm happy to do some test writing. I don't know if you're interested in my description. You know, I need to sort of know how the test works. That's the idea that you were thinking of? Or silent? Yeah. It's Saturday, 7-1 conference. There's an update in lintian.debian.org, so warnings. And people have been telling us, that this lintian error was fixed in the next release. Yeah, kind of ingenious, right? In this release, there is a new one. I don't know if there are new ones. Because it's so real, so real, the ones of, imagine. That's how you go on. It's nice to see when an internal test appears. Okay, when it was fixed. So when it was appeared, that takes in different packages, yes. And then if it reappeared, because there was a missing. The challenge comes to mind, and I think it's a good idea that we can do. The challenge is gonna be that, when lintian changes itself, and eliminates false positives. That's a challenge as well. Can be second that you want to do that as well. What goes, what new experiences do you want to post by a new version of lintian being used for all those things? Yeah, there are cases, because of the way the lintian archive checking works, where you're not gonna be able to distinguish between a lintian change and a package change, because they happen at the same time from lintian's perspective. Because when I released, when I released the original lintian, basically I stopped the daily cronja, and rerun lintian on the whole archive. But that's a regular lintian run, so it will pick up the packages that have been used here since the last daily cronja. But that's not necessarily a problem. We just marked that line as, two things change at the same time. We don't know what you're talking about. How long does it take? It takes about 36 hours. This is only in stable IP, it takes. Yes. It takes, I think, a week, if you're running about testing in stable or large. Profiling that, at some point to figure out what takes the longest, which is very interesting. You were suspecting the man-page checks, which wouldn't surprise me. Yeah, I noticed incredible increase in running time whenever the lintian stuff happened. Yeah. So, I'd like to, yeah, let's go to some more packages that take the longest on our documentation packages for libraries. Yeah, let's hope, yeah. It doesn't finish on some of the, our last dash doc or something. And mine took five more than an hour or something. Yeah, openoffice.org-dev-doc took like two hours unblocked. But that was a different problem. That was a, that's actually a bug, I think, fixing with you. But the man-page stuff, unfortunately, right now, in order to figure out, in order to check the man-page for man-heirs and other kinds of things, we actually run GROP on every man-page in the package and GROP is not the world's fastest program. Yeah. So, Pupart, we had tick. Pupart would. Lintian is supposed to be safe and it's not actually running any code of the package. So, you can actually run it over any package without danger of executing random codes. Pupart's actually runs the maintainers scripts, which is problematic. That should be the case. It is not something that we have done. Okay, all right. Remember what it was, I was thinking about it. We do run, we run shell scripts through bash with this check option, but if that actually runs any code, that's a bug in bash. Yeah. Oh, yeah, that was just because I had the option of giving an option to form memory. Okay, yeah. Yeah, well, if I gave them this, maybe we run it in the, so it's a different issue. Things like Pupart's really ideally, what you want to do is be able to run them under QMU and their own for VM or something along those lines. So, yeah. But I mean, I really would like to get to the point where we can run Lintian on every incoming package and DAC and kick out packages that have the real clear obvious errors, which means that I really care a lot about maintaining that ability to run Lintian on possibly hostile packages. Because, I mean, it's not, theory there should be a hostile package in the incoming queue, but you know, it's always possible and it's something to always be. There are a lot of those tools for multiple purposes and I don't think we should make Lintian like a master tool that's running everything else with Lintia, you have Lintian, and besides that, Pupart, and besides that, all the kinds of cross-archive checks, and besides that, dependency check analysis by QA and et cetera. So, we are about six minutes early, but since the next talk starts exactly at three, I've probably been voting to do adjourn unless anyone else has any additional questions, let people get a chance to get upstairs. What if you use somebody, do you use somebody first, something that you don't even know, what do you call it? Yeah, I'm planning on trying to summarize the information I gave at the beginning about sort of the general state of Lintian and the stuff that we're looking for help on as a viz from the Lintian containers and post the Devin Debellon ounce, because it seemed like it'd be a reasonable idea, so I'll try to go ahead and do that. It might take me a couple of days after I get back home. Thank you. Yeah, absolutely. By the way, I last night here of the re-entranted. Oh, yes. I look like it's only if you use one, four, or five functions which are undefined if you don't do that, which are not defined in the actual file. Oh, okay. So it's... In other words, it has to be found only in both functions. So we should like check whether one of those four, five functions are being used, and in that case, we should throw an alert and put an event on it. Good, yeah. So that's a right check to do, but it looks like giving the information that we need to find the... Okay. I'd be interested to know which functions they are. And it might be, how good to check big logs and final packages which produces one in about 20 different functions. Yeah, because undefined functions are generally problems anyway. Yeah. Yeah. Okay, thank you. You're welcome. Thank you.