 Fynau bywyd yw'r ysgwpwys. Nils yw'n iawn... Nid yn ymgyrch y dedlad y Llynedd yng nghymru... Côl i gael graffon Llynedd, bydd y maen nhw'n adnwg yma. Rwy'n gweithio y peth sydd yma. Rwyf yn bwysig y peth, yr unangol eithaf â bod yn ei wneud y rhai newydd. Eriminwch mor hi arno ar gyfer beth, yma, Llynedd yn syrffodaeth hefyd yng ngymru, o'r gwaith, o'r ddweud o'r ddweud. Rydw i ddweud o'r ddweud, rwy'n credu'n rhoi gan geusio. I ddim yn gydag o'r ddweud o'r ddweud o'r ddweud o'r ddweud o'r hanfod gyda'r cag rywun arno ddweud yw'r ddweud. I ddweud o'r ddweud o'r ddweud o'r ddweud, mae'n bwysig yn dweud i'n ddweud o'r ddweud o'r ddweud? ..either for your own team or for some domain or some language, like the package Ruby on package Java checks or something like that. Go ahead. Can they be written in Python? The checks? No. That's why we have separate package linitian for Python. I'm sorry, what was that again? That's why we have a separate package called linitian for Python written in Python doing checks for Python. I'm afraid I have to prove you wrong here. It is mostly written in Perl. I do know it forks a separate Python process twice or something like that, but it is mostly written in Perl. And it actually uses most of the linitian framework. So what? You have a question more, come with it. My question is, why is it a separate package? Because Jacob Wilt decided he wanted a separate package, I'm not actually sure. But in the old days it was more monkey patching than it is now. It still does a bit of monkey patching because it doesn't like a couple of letters or something like that. It doesn't feel it's efficient enough for something. But you would have to ask him why. But I believe you can install linitian for Python next to your linitian and run linitian, that's this profile, Debian, Python, or something like that, and then it runs all these checks and it should mostly just work. You can go try it. So, would anyone be interested in doing some checks for an accent? So, I already contributed to some checks. Now, the thing is, as far as I understand you, the question is whether I would be interested in maintaining them separately from linitian? Well, not necessarily separately, but also that. So, for example, in your case, I would be interested in maintaining them separately from linitian. For example, in your case you added system D checks, which would make sense as a general purpose check for many packages. But if you're doing a team specific check, it might not make sense to have it in linitian proper because it is only relevant to the specific team. Right. So, I'm also involved in Go packaging, so there we could have that. Now, my question though is, I'm not entirely clear on when linitian gets updated in such a way that the web interface gets the new version and when you would release new stuff and how my separate package would play into that. Maybe you can clarify. So, the web version we see is a git checkout. So, at the current stage, your package would simply not fit into it. But generally, it wouldn't anyway unless your checks are in the default profile, which your team specific or language specific checks might not be depending on how generally they are. So, that was the web thing. What was the other thing you asked? The other thing is whenever there's a new linitian release, how would my package be involved in that? So, how do you coordinate that or what's the plan there? So, currently we have no plan because we have nothing to plan for. Jacob Wilk, with his linitian for Python, has decided that he doesn't trust our backwards compatibility, which is a good call right now because I'm not promising any. So, he has a very strict version dependencies and then it's uninstallable for two days while he bumped the API usage and then that's that. And sometimes you just have to bump the versions and it just works. But yes, staple API is something we don't really have, at least not for the majority of things we provide. I do know that, but I also need to know what people want to use so I can make the API for it. Right now we have a lot of internal stuff that just works because it's only supposed to work for us. We have been thinking about writing some checks for package perl team just as you wrote it to check for team specific conventions or policies. So far it's only an idea, no one has looked into it, but I guess we will. I'm glad to hear that. Are there any other people considering doing a language check or something on package check? If nothing else, we can meet up after the talk and debate how to get into it. The other question we have here is if you did write your own checks, possibly in a separate package or in a LinkedIn proper, but not necessarily in the default profile, would it be important for you that it ended up in a LinkedIn divin.org website? Or is that just meh? So can I show your hands how many would say it's a necessity that it ended up in the website? Okay, that's a bit. And how many from I don't care at all? That's two or three. Okay. Any one who can comment on, want to say anything extending? Well, just a general comment. It's a typical case in which the people who don't care can just, you know, don't look at the website. It's not like it does negative consequences. No, but it's a question of whether or not I have to spend time adding support for it. And here is another one. Yes, sorry. I just want to say something on that. So it's often the case that if I'm maintaining the packages and the LinkedIn checks on my team, the packages from my team are going to probably not have the problems that the checks are looking for anyway. They're going to be the best maintained in the archive. And it's other people who are maintaining packages outside of my team, related to my team that would trigger these checks are more likely to have the problems. So those are the ones that you're most likely going to want to have on LinkedIn.debian.org. Right. Again. Slightly related to this. If I write a LinkedIn check for packages that have some Java in it, is it easy for the check to detect, well, this is a package containing some Java stuff, and I need to run and I leave all other packages in peace? Now generally we just run the check on everything. And if they detect something, they admit it. And if they don't, they just don't. Usually a do nothing check is fairly fast, even though it checks all files or something like that. So I would have to come up with some idea how to know whether this rule applies to the package or not. Yes, if it's, well, possibly yes, depending on what you're trying to do. We don't have a good way of detecting it in general. So another thing we have, I have a question here is, are there some of the design limitations in LinkedIn that would be a deal breaker to you if you were to write your own checks? And I have to add here that some of the design choices we list as design choices are actually more of a preference. So determinism and not using the abcasio or stuff like that is things we have chosen not to do, but it's actually things you can do. But there are some other things like you can only process a given binary together with a source. And right now you can only, they only process the same version or the binary is built from one version. So is there any of that which you consider changing if you want to use this framework? Okay, let's put it in on this. So I don't remember the specific use case, but I'm pretty sure when you try to add some common specific tests to LinkedIn, we had the usual fight with the deterministic approach and the sense that we wanted something like if this package is installed, then do this, otherwise do that. And that was considered by breaking the determinism for some value of determinism. Right. So you can do that in a third-party check if you want. So that is just something we don't want in LinkedIn probably because it ruins the determinism and it's not difficult to possibly test for perhaps depending on exactly how it was done. But it's not something you cannot do. So as I mentioned earlier, I'll have some tutorials and examples if you haven't seen how to write a check. I have the tutorials open, the checks open here. So on the screen here I have a simple source check. It's written in a given package, there's a rule for that listed in the user manual. And basically this line here is the thing that emits a tag. It requires nothing else than that. And the hard part is figuring out when to do it and when not to do it. The other part of writing a check is having a small description file that, first of all, describes what the check is named, what it implies soon, a bit of description. And then you add tags listed downwards. First the name, how severe it is and how certain your check is of it. And then this is the pattern shown with LinkedIn info. But that's basically all I have. So are there any other questions, any ideas, anything you want to try? There's a question here. You suggest more people create their own plugins apart from LinkedIn, right? Not only, but yes. Is there some way, someone not knowing that there is a plugin for, let's say, Java team to be warned that they shouldn't start the plugin to... You want LinkedIn to warn if it looks like a Java package. Well, basically to come back to the same problem that Thomas had with how do I know this is a package I have to apply to. There's no real good way to do that. There's heuristics, which works, for example, if you're looking for a team package, you could look for the maintainer containing your team email or something like that, which would be fairly trivial. But you can have Java packages outside the Java team, I suppose, so those would not be detected. So it's a little hard to warn for it because we're detecting it in the first place. Maybe some checking for build depends or whatever, I don't know. You can check for the build depends, but I suppose we could add heuristics, but it doesn't add up in a sense that if I have to write in LinkedIn proper and check for all the things you might be missing, then every time somebody asks a new thing, I have to opt into LinkedIn to warn about it. That's the only problem with that approach. Thomas, there's a question for Thomas. When I develop a LinkedIn test, how do I test it? Do I need to run it on a source package every time, or can I run it on an unpacked tree? And second question is, while I'm doing packaging, can I run a subset of LinkedIn tests on my folder where I do the packaging without building the source package, running it in pBuilder? For the second question first. No, you cannot run LinkedIn on an unpacked source tree at the moment. There's a request for it that's quite old, and you're welcome to run the patch for it. But there's a technical problem in how do you detect croft in a source package that is unpacked because you might have a git file that is supposed to be there because the package source will filter it out when it creates the divian.target set or something like that. So you actually get a lot of false positives in that that you don't have to manually filter it out further out based on the type, based on the thing you do. In regards to testing LinkedIn checks, we have some Perl unit testing that loads the checks, tests that the checks can be loaded, that your description file is detected correct. We also have an extensive test within LinkedIn itself, and it doesn't generalise very well. You may remember I tried to do a deep-in testing framework with Poltac at some point that never really got off. That was an attempt to generalise the LinkedIn test suite to work with other packages as well. I will mention for completeness the unit testing utilities using LinkedIn itself are actually installed with LinkedIn itself so you can use the same unit testing that we do. It's a simple thing, but it catches common mistakes like things doesn't compile syntax errors, even spelling mistakes in your attack description to some extent. The other questions in regards to third-party checks, anyone have any ideas, any creative ideas to what they want to implement or use it for? I suggest that anyone here doing backports to Davion backports? So a couple of you. So how many of you have tried to upload a backports and have it rejected because you forgot to use dash v some version? Show of hands. Now how many of you would have liked LinkedIn to warn you and tell you you're doing something? Yes. You can do that now. I actually suggested this to the backports meaning less than a while ago. So if anyone's interested in doing that, come see me afterwards. I'll set you up with what you need to know. There's a question there. Another issue that is not checked, well hasn't been checked. I've just yesterday upgraded LinkedIn actually from unstable, but so what occurred to me is that I well forgot to release the change look so it was unreleased on top in the first line and that hasn't been checked in the past either so I'm not sure if it's checked now but if not then it would be a cool feature. There is a bug for it that is currently tech won't fix. I don't remember the exact discussions but a lot of people don't want LinkedIn to annoy them with unreleased because they do incremental builds so they build and then they run LinkedIn and they fix something, they run LinkedIn and fix something. But there are those people like you who want it to say you're forgetting to activate unreleased thing. Most people tend to have deep put warned them about that but this is a thing where you can do a personal check for your own usage to check for unreleased being there. David has the question. Would it be possible I mean there's no sense all of us doing the same personal check or say 50% of us doing the same personal check would it be possible to have optional checks that we could just enable with some config file? It would but someone would have to maintain it and I'm not sure I'm willing to commit to maintaining it at least not alone. Okay I mean so I don't know that these checks would be any different than the checks you have now. It's more a question of you're not sure if everybody wants them and in that case it seems like having the check and being able to switch it off and on or... Yeah I mean some of the checks people want can't be done due to political reasons in in Lincin like checking the out cash if you're doing something really stupid I did for fun make a prototype test of check for that I think see if I have it no I don't have it here but it's fairly simple to do but a lot of people have a lot of ideas and I want people to write them because I don't scale Okay I don't know if you saw the X or buff but you saw the nice block graph that kept growing I have the same problem in Lincin although I didn't reach the 1,000 mark yet but I like to keep that under control so I'm hoping to spread out the work and maybe have a distributed solution like DIPEP I have at the moment So having a package of extra checks that somebody else maintained would be work okay from a technical point of view Yes Okay that's fine then And I might be willing to comment if not at least consult be a consultant for it Okay There is a question again Mike I believe So from your last remark to understand that you actually need help from your last remark about the comparison between Lincin and DEPEP helper is it actually that you need help in terms of team around you? In every development announcement email there is a request for help this is a nice project to help you just need 30 minutes every now and then to do a check Yes So it's good to speak it out here loud I think Yes I would greatly appreciate more Lincin maintenance and obviously this is a trick to make you stop doing Lincin work and eventually move into Lincin and doing my work for me So But also even then if you do your own checks it's going to downscale the amount of bug reports I get for various things including checks for neat white spaces usage which I'm somewhat hesitant to add if only because it seems like a waste of time on my time to do it Okay So this is the number where questions about Lincin and his checks so is there anything else people want to debate about Lincin? We have about 25 minutes left so yes if anything about Lincin related at all going once Paul has Just a random idea pick a random package in the archive or a random package from mentors and have a monthly ISE meeting to find issues in the package and then write checks for it So that's a good idea Anyone wants to volunteer for something like that? Show of hands, don't be shy I know it's recorded but I'm sure we can have it cut out No, okay So basically that's the same problem that happened with everything else I do in Lincin There are plenty of great ideas there are just not many people wanting to do them and also I've seen the list of sponsoring checks great idea some money needs to run them and I'm sure a lot of new people would appreciate having them but my workload does not quite allow me to do that or rather or do the expense of other things Okay, so let me ask you a question What do you think is the greatest flaw in Lincin? What is the greatest problem with Lincin? It's written in pearl Okay, do you volunteer to be volunteered in python? Again, we have a chicken and egg problem with that There's a question here in front from Michael So first of all this is very nitpicky and I just want to thank you for Lincin and it's really a great tool but I think that it's slow not per se the running it on packages even though that is slow too I notice it really a lot with the go packages that are quite big in terms of megabytes because they contain a lot of compile stuff but also especially in development like not sure if you remember but when we were talking about it I mentioned that I was unable to run the test suite in an acceptable time frame like it would take me many many many minutes and it would be hard to run it in the first place but that could probably be fixed but getting it quicker to run is a much much harder problem but I would think that this is what keeps me from working more on Lincin even though I now have some experience Right So Lincin itself is admittedly slow I have been trying to improve that since 258 and basically every one or two releases I fix something in pipeline or something so reduce this time for a special case in law and I've got to the point where it's now slow rather than horribly slow but there's a fundamentally a lot of problems design-wise and possibly even just what we do so we have some ordering in what we can do when and they seem to be stored on unpacking things checking what type of file there is with file which got a lot better in one of the previous releases and then there is if you have a thousand man pages it's been here and neither can it maintain us I'm sorry but that's a problem in Mandi B it takes 0.1 or 2 seconds to process a man page so when you have a thousand it accumulates and you basically need to find and Lincin calling Watson or have him do something about it and he knows it's all he has to do this but apparently that's a pretty long to do list because it's not in the room then he doesn't know he has to run The test suite is annoying me as well I did a fix for that to some extent but half the problem is that basically every test we have of the expensive ones takes about 3 seconds in build time alone so optimized e-package would actually be a good call here and then of course something that Lincin needs time to process on but right now I think the build time of all these packages is actually one of the slower parts now but yes I would like to see it fast as well I think that was the question from Bernard first and then Mike One thing that I think could be a bit improved with the test suite is documenting or making the documentation easier found how to run only parts of the test suite If I add a new check I always need some 5 minutes till I've figured out how to only run my new test There are some things written in there but I usually always look at the wrong place to find how to do it Yeah and I'm not really sure I'm allowed to mess with the structure of that I have a part documentation of how the test suite works how you've run it It is in doc tutorial, Lincin tutorial and then test suite the part and you just pull doc on it and you get this nicely formatted readable thing rather than this There it tells you how to run specific tests based on whether it's a given tag or it's a given check or just a specific test in itself So I might need to do a top level read me for that and be stressed on that there might be a good idea Can somebody write that to the gobby please a top level read me for pointing people to the right documentation In regards to the speeds just before my guts on there's one, there are two things you can do to improve Lincin speed right now by installing optional packages one is installing lip outer die pearl two 18 or higher which fixes a start up time cost and the other is installing lip pearl IO gysyp pearl which reduces the number of times we have to fork an external gysyp to decompress something especially the latter for K3 obesity actually can take off minutes runtime So is it okay if I change the topic now to go away from speed of the test Go ahead So I actually want to continue where Michael started with the comment just a couple of comments before I want to give you my really big appreciation about what Lincin does especially well I've become a DD in March and I've been before March I've uploaded to mentors the Lincin checks and everything it's the teaching tool in packaging for newcomers if it wasn't Lincin people would not know how to fulfil all these different parts in the policy so it's actually for the newcomer process new member process in Debian it's the essential tool and I'm really surprised how we become really shy all of us when it comes to you actually requesting help so what I say for myself is I wouldn't be able to oversee all these policy things and stuff all these elements into test specific test for specific packages in specific languages normally if you do the work like you are a Lincin developer there is a point where you don't realise what kind of great work you're doing but you're doing it and what happens as well is that you're so so into it that people stare at you and think oh that's Niels so he's doing this Lincin thing there might be a few people in a room that would say yes I do that I send patches and everything but probably those people are really busy with other areas in Debian as well so there's appreciation first and then there is this how can we get people into supporting you because it's a really crucial tool you're providing for Debian thank you Paul has a remark Paul has a so I have a question do you have any data about well we kind of push Lincin on to all the new maintenance and they all use it that's all good but do you have any data about how many long term Debian people are looking at the output of Lincin or explicitly not looking at it or whatever no I don't actually have concrete numbers I do eventually occasionally get angry mails from people that got their package aren't you rejected especially when the FTP masters fixed their problem with non-overbindable tax and then between two uploads of a given package and somebody came to me and said Lincin's brain damaged and yes it was a false positive but he had known for a year that it was supposed to not be accepted but he just went on and didn't but now I don't actually have concrete numbers and on a related note I actually don't control what is auto rejected and what is not you have to work on the FTP masters here although I suggest some tax but in general I don't actually control it so I believe there was a comment here yes on more automated rejections you have to track the FTP masters into a room and beat them with a stick of what you want them to arch-reject there's a question from David I don't know Genneth volunteers to yell at those people for you excellent thank you Genneth so did you have something or did you retract it banner so along the lines of who's using Lintian and who's not anecdotally myself I'm using Lintian but not the pedantic checks and actually it's a bit of a pet peeve of mine that people tell new users to use the pedantic checks because I think they're the ones that require the most judgement to know if they make sense but anyway that's just my personal opinion that is true there are actually many cases where we should really consider whether or not a given pedantic check makes sense mostly I let the maintenance have decided that when I do occasionally have time to sponsor but yeah go ahead I think I'm of the opposite opinion I think it's good if new maintainers look at the pedantic checks if only there's a higher chance that they have a check which they see that it doesn't apply to them I think a big problem of Lintian and new maintainers is that Lintian is too good so new people start to see Lintian as the thing that is always right and if Lintian says something they must follow it and I think that's why more pedantic checks visible for newcomers is good because then they see that these are guidelines and informations and while Lintian is good it's not an all omniscient being that can tell them what to do the problem is actually people asking me whether or not it's okay to overwrite no upstream change lock which is a pedantic tag for those upstream that doesn't have it and it's like most people don't even bother doing it but they come and ask me so I overwrite this tag and it's like yeah I don't care but yes Genesis people run it with all the checks there are and then many of them fill without the uninteresting ones at first and perhaps overwrite them whether it makes sense so on the subject of overrides have you looked at the ones that are in the archive and whether any of them make sense at all I'm pretty sure some of them do but basically I don't have time to track down every of them I do occasionally scroll over the list every now and then that's why I learned we had 35 overrides for minkivie and the likes where they have used for something and then they have some object files for cross compiling into whatever platform and that makes up every 1 in 5 overrides on Ninja Debian at all which sort of surprised me but other than that I don't really have time to dig into everyone so occasionally I see something suspicious and I follow above it but most of the time I just meh just in that you're also welcome to go hunt overrides in regards to your comment about being on writing lindian text and you get to be on top of the policy and all that it's actually not how it happens most people start asking us to write checks for a question of behaviour or for newer things like system D and eventually those get promoted to be part of the policy so lindian is often ahead of the policy in many regards of course there's sometimes that the policy maintainers add something but in that case rast the policy maintainer tends to just give us a list of this is what we're about to include the new policy, some of it we might be able to check from the rest, people have to do themselves so if that's what scares you I can tell you you don't need to remember the policy by heart, I don't and often I don't read it for this purpose at all and you can even start with a simple thing such as reading through our tack descriptions because most of them have typos and what not because nobody reports those, well some do but not a lot and I'm actually considering to add translation support for tack descriptions if only to get more people to review them okay we have some 8 minutes left on any other questions the comments the science David again lots of talk, not so much work have you considered a lindian sprint do you think you might get people to show up for it, it would be fun it would definitely be fun but I'm concerned whether or not people would say anything, they're just so up there they're going to eat the food but okay perhaps we can see a show of hands how many people would be interested in intending a lindian sprint for the purpose of working on lindian based checks show of hands I mean I'm kind of lying because I'm too far away but okay there are at least 5 to 6 so we might be able to do that okay any other final remarks here David again doing my job for a change Gennif raises his hand he will attend a lindian sprint now I'm not sure they're doing it okay excellent okay but if there's nothing more people want to say then I think I will call call it a buff so thank you all for coming