 I'll just say a quick thanks for all the extra tasks that have been written. It's been a while since I have gone a few days' time with some... I'll just say as a new meme. I'll just talk. Yeah, having sort of talked about this with Gregor last debconf and had various talks with him about how it was a good idea and how I should really join and sign up, I think I finally sent an email about two months ago and actually only uploaded my first already existing package about three days ago and that was more my fault than anyone in the Pro of Group fault but I followed the instructions and how you do the SVN inject thing and all of that and it all just worked so it looks like the docs are good and it wasn't that I was scared to join because of scary people on the list. I was just trying to find enough time so I think that lots of things you're doing are right. We are pleased to have you with us. I am new and I am considering joining this group. I would like to know which kind of tasks can be taken care of by somebody who knows perot but not much about anything else. We have a thousand and three hundred packages. We have tasks. Is Perot 6 going to come to Dedia somehow? Somehow somewhere, yes. When? How? Nobody knows. Well, there is already a Perot 6 in Dedia. There are several in fact. There is Rapudo and I think there was Pogs at least for some time. But the thing is people expect the Perot 6 transition to be something that happens at a given moment. Perot 6 has existed for a long time but still the most important implementation is and will be for a very long time Perot 5. And basically everything we are handling right now are Perot 5 modules. Well, this group is in charge of over 1,000 modules. So yes, some of those modules implement some Perot 6 functions under Perot 5 or behavior rather than functions. But let's worry about Perot 6. It will come eventually... If you want to build it, it takes the Perot 8 thing. Yeah, and Rapudo is part of it. The package is called Perot. Is it the same Perot as it was in Dedia before? Yeah. Are they into minor conformities today? It's already solved, yeah. I invite you to use the microphone because at least Jeremiah is following us. Following us? Hello. There are some information from ISE. Jeremiah shouts that Perot is the virtual machine. Ryan says that Duke isn't packaged, and can it be packaged? Yes. Could you please just follow all on ISE? I hope Jeremiah doesn't mind too much if we miss a bit of the... I mean, it will be recorded. I think Tincha took care of it, but let's not distract ourselves too much. It's working. How many of you are in the camera? So, Fikki, help people. Slow, endless loop. Yeah. Maybe we should start to look on the list of topics for discussion. They are still in the Debian Wiki, as I've written in my last mail, and I've just now pasted it on ISE. So, Fikki.debian.org, slash teams, slash Debian Perl groups, slash open tasks in friendly nice camera case. For those who want to... Debian dash Perl. If you're joining now, I can paste it again. Sure. How does topic manipulation work? Yeah. I am looking at the previous meeting notes, which... Well, we have decided some things, and some things are really decided. Right? So, we have much less to talk about today, which is good because the beer will get warm if we have to talk much longer. So, the first thing to do is the version to get migration. There is no any progress. I am to blame. I don't know what to do about that. Some day in a rainy, some day... Yeah, obviously, the outcome wasn't the nice, the right place for me. I got distracted by some tiny organizational details we had to solve. So, yeah, here we are. Yeah. Next. Yeah, we decided that policy will change about the dependency. Perl 5.6. Do all the left models. Keep to irritate us. Every now and then. Applications. Yeah. We just live with that. We don't have much to decide. Ah, that checksumming thing. Somebody has to do it. We need a volunteer. The checksumming of the Debian rules and automatic update of it. Yeah. Don't you recall? So, the automatic update of the rules should be before, probably if the current file matches are known checksum, that is also automatically generated. I'm just confused because I'm looking at the open tasks page and you're looking probably at the minutes of the last one. So, it's a different order. Ah, order, yeah. I'm fine, just go ahead. So, we need some volunteer for this to make it happen. Okay, team takes care. I like that. Okay, you took a task. No more than 10 tasks per person. Still work in progress. We already had the pet support. Thanks to Gregor++. Do we need a crown job for that? For the still work in progress? I don't think so. It shows up now in pet as a warning flag, over thing and the clean up has to be done manually anyway. What we could do also is to add an icon or something that is even more visually attractive. Now it's just underlined. You might miss it. Yeah, I mean, well, yeah. Focusing on shape form rather than meaning, I mean, I think pet is quite understandable and visually nice way for the amount of information it handles. So, I wouldn't put too much energy into making it beautiful. Sorry, when I said attractive, I wanted to say something that catches your attention, because it's old. It was not pretty. I wanted to say something blinky. Okay, so... If you want, I can implement the blink tag on Flash. With sound. Poink, poink, poink, poink. At what frequency? At what bitrate? We want small. Okay, that bitrate. Tintu will add an icon to the same packages. Next point. Tintu did what? No, I... Tintu will add an icon. An icon? That's something to... More... Something that is more than just an underlined. In what section? That's still working progress. Tintu adds Flash. Okay. Who implemented ignore version? Change lock handling? Sorry, I don't remember. Ryan, okay. Ryan implemented it in Pet, and Brian Cassidy has done the work of adding this ignore version, blah, blah, blah, and I think hundreds of packages and almost got met. So I think he also deserves our thanks. Right, next topic. We are nowhere with deciding what standard headers we use. There is a wiki page about this. Linked one too. We need some standard phrases in the change lock. That act as a flux, indicating some states that we are interested in for Pet. And some stuff like this. Like ignore version, which is already implemented. Where was that page? I did it. Yeah, who works on that? Who knows about consensus. And about different spaces. Yeah, we need somebody to track this down and get it finished. One way or another. I'll take it. Yummy. Where is the paste? Yeah, and given my success with get some attempts, that will be for Christmas. Yes, Jeremiah, they're green. We like green. They're very cool, actually. There is no anybody else with t-shirts like this. Even after this, not as green as before. Right, rename source packages. I think Gregor is already on this track. There were very few packages that needed this rename. Maybe five then? Well, I've renamed the easy one. Meaning those packages that only provide create one binary package that is actually library. So I renamed the source package to be the same. And I've sent a list of the other packages which provides several binary packages. I really applications and not libraries. So I think we can leave them there about 5 or something. You're saying this is policy? This should be done? Or because I've just recognized some of the CDBS packages I've been saying that it's like that. It's not like that. That is a different source package. I named the source package as upstream, named it source package, and then the binary as Debian policy. Is it now policy in Debian that in Debian Pearl that the source package should be named equally? There's no reason to have it otherwise. We usually do it that way. So let me tell you specifically, please do not ever have a source package name which does not have a corresponding binary package of the same name without a very good reason for doing so. There is no reason if you are only producing one package. The primary reason to consider doing that is if you are packaging a library and your library has a so name, that's the only reason to consider having a source package name which does not have a corresponding binary package of the same name. I think the main problem here is that, for example, we have some few salient packages like MIME Tools, which should be LibMIME Tools Pearl. Or... Wow, okay. Magic, which should be LibIME Magic Pearl. Right. It's so important that it is relevant to clean up this. I'm talking about Debian Pearl. So about pre-existing packages, it's much more of a pain to have to rename the source package. So unless you have a real serious reason to need to rename your source package, it may not be worth it. And the reason why that is... I'm telling you that's problematic is because tracking down the conversion between version propagation as far as the BTS concerned and figuring out which source package was a descendant of a different one is... Yeah, it's more problematic. So, I mean, if it's just... If it's causing you a serious problem, then okay, yeah, fine. No bugs against that package, whatever, that's not my problem. But it's something that you need to be aware of because it's very difficult to know which source package goes to what descendant when you change names. As far as the BTS is concerned, it generally looks like it's a whole new package. I promise I will never do it again. Sorry, sorry. No, no, no, it's not my problem. It just means that your bugs all of a sudden you have to manually play with your bugs. And so that... In small cases, it's probably not what you need to do, but in big cases, it's a problem. The good news, the few packages I've remained don't have any open bugs. This is really a problem for big packages. So, yeah, if your package has two bugs, then it doesn't matter. So, we're still following the minutes from last. Package check needs to be rewritten in Perl. Package check is this nasty... Yes, who does that? Jeremy, can you rewrite the package check in Perl? You've been volunteering. I've been taught. Silence means agreement. Can you run anything from the back wall? Great. Thanks. Great. Okay, I note this. Yeah, the next point which we have discussed and where there hasn't been any progress since last week, at least as far as I know, is the question of patches. We have some patches in our packages, mostly fixing small errors, and we're not really good at forwarding them upstream. So, this needs to be done. And we've also been talking about standardizing the meter information in the patches. And since there is this DEP3, we might just as well use it instead of inventing something new. My idea was, and actually my plan was to at least write the idea down in a bit more words, but my idea was to have some tool like patch change. That would be just a simple wrap around an editor that opens up your patch and adds the necessary headers, converts the existing ones. I guess it's not really difficult to write for someone who knows how to write such stuff, but it might be really, really handy maybe with some command line options or something like DEP change, but for editing, patch headers to have them standardized. Unfortunately, neither have I written my thoughts down, nor has anyone volunteered yet to work on it, but maybe we can find somewhere now. Can I construct some new? Yeah, anyway. I think this tool would be useful before chasing all the patches if there are four of them. Because it will be easy with that tool, plus having such a great amount of work with it would help testing if there are some possible improvements in that tool that it will show up used. Yeah, and if the patches have to correct forward it, no, whatever header, then it's very easy to find out which patches have to be forwarded. Maybe even the tool has some switch to prepare and mainly can be forwarded or something like that. Patch change doesn't feel right as a name. We have to decide about the name, that's very important. Yeah, he or she who writes this tool may decide on the name. And in the end it belongs into Dev Scripts, I guess, but if someone from our group would write it and we'd write it, I guess they would be happy to accept it. Any way of tracking which patches were forwarded and which not? Actually, on the patch we are using to put the RT bug number if the package was forwarded. And I remember that I had to just, at some point, at the beginning of the year, using an in convention like state if the package is forwarded or the package is just valid for something that's not being forwarded. And that still could be, gave a good idea if you don't need to open the patch. Maybe it would be better if we started using tags, instead of renaming the file each time. We have been talking about this in the last meeting and we said if we adopt this DEP3 with the headers, whether it's one forwarded, yes, no, it doesn't need it. Then we actually don't need to use the file name because it's already there. I expect when, if, whether DEP3 is approved, it would be close enough to what we are already doing that it would not be a pain to just adopt it. The good thing is that DPs don't have to be approved. We can just use them like we do it with the copyright thing where people are still, are still flaming about it and we are using it for a year or something. Yeah, we use this in a thousand packages. We declare this as standard, so... Thank you very much. Next. I don't remember if it's here in the list, but the other thing we were talking about was the cellular headers in the control file for... For the backtracker. For the backtracker, yeah. Oh, it was already discussed. We were discussing about having cellular headers in the control file for the backtracker, for having a tool for working batches or something, but the idea is for this batch editing tool to be able to help developers to forward bug substrings. So it may construct a mail that is almost ready to be sent. It won't send anything automatically. Human interaction will be required. But still some help in this regard will be very useful and for this we need to know where the bugs are to be sent. And for this, we think that a cellular header in the source control file will be the appropriate place to add that. It will be useful not only to that tool, but maybe it can be used for all to the package tracking system or somebody else, or for UDT for some nice statistics. Already in the depth file proposal for the copyright file, it is clarified that it's under discussion, which is in a moment, to have the... It's not the copyright owner that is in the top, but it is the contact. And it is different ways to contact the currently active person, and it is an optional field, which means if there is no active upstream, then this does not exist. If there is a currently active upstream, then different ways to contact these people. And so I would suggest to try and look in the copyright file, see if there is this A22 specific hint, and if it's there, look if there is an email address. Then use that one. If there is not an email address or the hint is not there, then ask for it or look somewhere else. Instead of inventing a new place in... Are we talking about this? An email doesn't work for us, because in our case, from where we stand, we have lots of packages that use the request tracker on C-Pen, which... I'm correcting myself. Then look for the kind of resources we want to look for. So then look for an HTTP string that is matching the Perl groups, Perl upstream's request tracker. Whatever it is that we want to look for, look for it in the copyright file, because it has an open-ended hint place to place different ways to contact currently active upstream. I think we don't even have to add something, because actually for C-Pen's RT, we can use the name field in the copyright file, which is the dist, the distribution on C-Pen, and we have to hold it. Unless for the packages whose upstream doesn't like request tracker, and if we send a bug there, they got irritated, you stupid Debian folks, you don't read my documentation, it's clearly stated there to use... But we do this anyway. It's great to have systematic things for thousands of packages, but we really should, like similar to having hand-editing the files, the emails before sending them, or the messages before sending them, similarly we should be able to express something else, whatever it is in each package. Yeah, well, maybe then we should add some additional information for the upstream modules where they don't use C-Pen's RT. But doesn't it make sense to have the information in copyright file of how to contact upstream? I maintain it there. It isn't hurting anybody. No, I'm just trying to find a pragmatic approach where we don't have to change 1,300 files. So my idea would be used if there's no explicit bug upstream, something field and just take the name field which is the distance and send a mail to bugs-distribution at RT... So you're talking about an implicit fallback? Exactly, exactly. That is to try throw it at the default... That seems to also cover your case. If there's a weirdo upstream, then express the weirdo things in the copyright file. Which is, well, I mean, I understand the thing is to make it policy, but that's exactly what we do right now. Whenever we have something to tell upstream, we have this same default. Well, if a sim gets pissed because we are not following that same default, then we'll do something about it the other way. What are the chances that the copyright file will be approved for such a place? Similar to the tagging of patches, as I see it, even if it does not get approved, that does not mean that it gets rejected, that we are not allowed to express ourselves the way we do in the copyright file. So even if it ends with nothing, the depth file, it still makes sense to try and look at the copyright file for some pattern. And if it's there, then don't use the default. We can still continue to use it in the public until something else comes up as a better default. Yeah, so my question is, do we want to use the copyright file for this? You're asking me if we want to? I'm asking everybody. And I already answered, I think. I think we should do that. Because there's a chance that this can become a standard. I do think that this is one of the things that have added most value to this rule, that we can build on very sane and very regular default values. So they agree with this. We can follow that rule. When extracting information, okay. My question is more like, when you enter that information, I stumble upon a package whose upstream isn't using a request tracker. Where do I write this? Well, okay, if the upstream is not following, is not paying much attention to the request tracker, I would say instead of pointing the project home page to C-PAN, point it to whatever they want. But usually it will point to C-PAN. And we know that C-PAN home pages have a request tracker. So you... Just to guess that we don't need anything anywhere. Just follow the home page. Or deduce from the home page where the back tracker is. I say that if... I mean, that's something we have to agree as policy. But if the home page points to C-PAN, we should recognize that it's a full C-PAN regular thing. If it points to search for... Well, we should use the search for tracker. Or if it points to www.mystiffymodule.org, well... They still may use Google of course. Yeah, but if the information they provide as their main contact page and the main page to look for new module notifications falls out of the regular... of the pattern we use for everything, then we know there must be enough information for both things, for tracking new upstream versions which may not be in C-PAN even, and for contacting regarding bugs. It should be somewhere written. Yeah, that's my question. Where? You're not talking about where the information is. You're talking about where we should document where it is, right? Yeah. And my proposal is to use the place that is already a working progress in Debian in general, not only in Pearl Group, but in Debian in general. There's a proposal to store this kind of information in a hint in the copyright file. The prayer for that, I see, is first, copyright file will be always possible to have a non-structured copyright file. Because even if the proposal is accepted, it will not be mandatory for sure. So it will be more difficult to parse, and it's not meant to be used like that, the copyright file. Only in the cases that people are using the standardized copyright, but maybe having a header, a field, the control file will be better for that because it's structured always, and you can find it always. I would not be worried about this, because even if you do not use the structured format, you can still throw in single snippets that are structured, and I believe it is very simple to search, to grep, or pearl-like, to Regex for information in the copyright file. And we might say that we only want to use information if the first line declares that it's following the file. The file says that the first line should be that this is in this version of whatever format it is, and then you could expect the rest of it to be a specific format. So look at the first line. If the first line matches some pattern, then troll the document for this kind of information. If the first line does not, then don't scan the document and give up and use the implicit default. I don't see a problem in... That is, as I see part of the DIP file, that, yes, it's saying to not use DIP file, but I see it as counterproductive to now, in the Pearl Group, invent another place to place some information that is explicitly part of DIP file. I don't see a benefit for that because, as I say, it's not more safe to extract the information from the control file than it is to extract it from a DIP file-based structured copyright file. It is not more safe. In DIP file, yes. It is for contact to upstream. It's a hint, but it's not exactly the backtracker that is what he wants. So you want a hint that is explicitly for backtracker upstream, not for upstream? Yes, exactly. I was talking on the time of the backtracker. You don't have a microphone. On a proper meta-yaml file that is documented. I argue that it's not really the case. I'm saying that it should be the case. They may have proper meta-file, full incorrect information, and they will yell with you because they state in the pod clearly, not use custom. So we need some place for our own usage to state this when necessary. I agree. I agree that the copyright file is an appropriate place for it. I understand what you are saying now. Please, and we can in the copyright files add some X headers, however we like it. Exactly. Like X, backtracker, whatever. And fall back to the default. So for the five insane upstreams we add some friendly headers. It's a line which we use for the packages. Yeah, right. I would propose contact bts. They tie it to the contact information, but a bts, a specific contact type. With X or without X? With X because it currently is in the discussion if it requires an X or not for default hints. So with an X just to be safe. Yeah. What would be this magic? Because if it's called contact, if we're submitting or browsing bugs or etc. We can handle both. It can be the HTTP address of the request track queue and from this we can deduce that this request tracker... We might need to know which kind of tracker is it. If you need machine readable separation then you need two different hints, but if you just need multiple information within this then just space limited. We might need to define a format for that at some point. Okay. Use one hint for each. It sounds like you really want this very machine readable. Then use one hint for each kind of bts variation you really could think of. It's fine with me. Blow this copyright file. It's cool. It's already bloated. You need to laugh into the microphone. Okay. So we have to hurry. Dan says no beer until we're done. And I just said that Dan is always right. So we document this in X, contact bts in Japan copyright. End of discussion. Someone writes the purchasing tool. I want to know who that is. Yeah. Then we need some way to track patches, not forwarded upstream, but hand them down. Is this to be in pet? Or... How do we... We need to be able to check if we have patches not forwarded upstream and work on them and either mark them as table and specific or forward them upstream. But now we have... How do we start on this? Now in pet we have the list of patches and the names. So we can add parsing for the headers we were talking about in the last two points. And add support to pet to mark them as usual forwarding. Yeah, but you have in pet a long list of packages, some with patches, some with not, some with forwarded patches, some with not. So if I want to work exactly on this, you have to review all the patches, all the blows. We could do a specific build for this. It's just reducing everything and doing a different template. It's just that. Well, it works for me. I can even volunteer for that. You just did. Thank you very much. Right, when I received... The intro writes a new template. I am touched too. Typing with one hand is not very... Yeah, fixing LinkedIn errors repository life. Some strange faces without putting the microphone on me. You were breathing. Yeah, I was breathing. I often breathe quite often. Well, I think, yeah, we have some LinkedIn warnings, especially, say, from packages behind the standard version 5.6 something that was the last one that required changes from what we've taken. Correct. But mostly, I think, we are LinkedIn clean. Now, we can just query on the, well, the LinkedIn reporting thingy for what reports are they generally for the group. I would bet that most of them regard, say, patches we applied before we standardize on Quilt or something like that. Well, they have been converted. But I don't know if they have headers or so. I don't know. I mean, I do not feel we have so many LinkedIn warnings group-wide, say, okay, okay, okay, stop the face. We do. We do some very boring stuff like pot errors. Yeah, but very boring, very boring LinkedIn. Pot errors. Yeah, but yeah, pot errors. But very boring LinkedIn warnings are, I mean, there's something we should fix when there is a package upload. I do not think we should invest too much energy in fixing minor LinkedIn warnings all over. I mean, yes, if there is an upload and there is a LinkedIn warning, fix it. Yeah. I like that. Yeah, I agree. I think this is a nice, optional project for someone who wants to do something useful and improve the quality, but optional. A sum of code. Fastest bug fixing. Jackie F is just suggesting X, yes. As a control. X colon, yes. Let's continue. Yeah. I think if this X, leading X is approved in a depth five, it must be X dash. Yeah. Okay, let's go. No, it means a package is able to talk with X. Ancient packages. That was your idea, Kunal. Listen, ancient packages. These with some old standard version. Yeah. The thing is, yeah, I think we should track which packages have not been touched for too long time. Say packages which have a pet should warn us about packages which have a very ancient standard version and which have not been touched. I mean, because the amount of things that should be done for a package over two years old is already something that may cause us... that may require changes. So, yeah, I would add to pet. The latest change has been already started to be tracked by Gregor. We can also add a check for the compatible version to verify if it's in the rules. Ah, the age compatible. Yeah, yeah. If it's in the given slash combat, it's easy. Well, I think, again, thinking about the general policy we are using for over 1,000 packages. If combat is inside rules, something should be warned. I think now this is also an interim warning. Yeah. Yeah. So, yeah. So, it's done. And put it as an error. The latest upload is very ancient. Because of the reading of the social... Okay. Because I was just thinking... That's not an interim. I think it's perfect. Okay. We don't just need it. Okay. Ryan is working on unifying the repacking scripts. I want to see, yes. Okay. Yeah. For all three of them. I think I have like this. Okay. Yeah. Okay. We have reached the next topic. This repack script. Ryan has actually committed a proposal already some days ago. I wrote the mail on the list making some suggestion for a minor change. And that's the status. Maybe someone should take a look at it. Almost done. And then we just use it. Do any packages use it? Shall I crap? Okay. I invite you to use it down. It's almost done. And then it's welcome. Next. How to do it now? Post-line. Clean up. We remove of the alternate build dependencies from modules 5.10 or some outside module package. Who wants to work on this? No one. Yeah, but that's another task. Ryan says the unified repack is done. Ryan says the unified repack is done. That's right. Yeah. That's what I also said. I have to admit that I'm also getting tired. Damien, what was the last task you were looking for volunteers for? Post-line cleanup of the build dependencies on modules. Yeah, yeah, yeah. But I suggest we wait for... No, that's not post-line. That's post-squeeze. I suggest we wait for the squeeze release. No. No. We don't need this after-line anymore. Use this right now. Because you can safely depend on the modules 5.10. Yeah, but a week ago we said, and that was written here in the minutes, we do this after-squeeze, because we want to make backpotting easier. Yeah. That's my... That's what my notes says, too. Yeah. That to do was about removing transitional packages. Yeah, I've done that already. And unless we change our mind now, we leave those alternative build dependencies. I will secretly do my drop-and-no, I will notice. That's done. And post-process. Yeah, the next one is this... The next one is this upload of the half-adopted packages. I don't know how many hundreds we have taken over. We have lots. I don't know if hundreds, but... I mean, okay, I understand that J-Bonesy ones are done, but we still have the Florian ones. I don't know how many, but we still have a lot of not yet uploaded. Yeah, and since a few days we only have half of them, because Ansgar has worked like crazy. Thanks, Ansgar. On them. It was a really great job, and I've uploaded them afterwards. But there's still quite a few left and work on them would be appreciated. Ah, 70 to 80 left. Yeah, yeah. DH make pro. Oh, I have nothing to add. We're still there. Yup. That's the way it is. DH make pro. On the Western Front, nothing new. Copyright, la-la-la. All these. Please stay away from it. Okay. All the years. Only two topics left. No, only one. Well, we also have to start a page. Send it to check on new packages. Yeah. There's no easy way. Okay. I'm done. I am done with my list. Somebody else. I'm version pro. I'm version pro. Yeah, it was so way before and we decided that on the previous meeting, we dropped the version from the pro dependencies if it's lower than 5.8. Actually, the Lintian check for that has already gone since some time and policy just needs to be uploaded. The bug is seconded and everything. I think the CDS sort of, six pages. Two. Okay. All quiet. No, I was just looking at the open tasks page. There's, I think there's only one point that was also not out. It was not also in the minutes from last time. And that's the idea from last year, drinking Andares in Madelblada, the local theater. And that was the possibility of writing the letter to the coal community and telling them in a friendly but clear way what we think about modern install. No, I think it would happen. Yeah, I think it's true. It's true. So? I'm not sure if we want to do this, how we want to do this, but... Yeah, I think it's true. You suck. You suck better. So anybody who thinks this is a bad idea and will just use this confrontation with modern install author, that's Adam Kennedy, if you don't know him. He seems to be a nice guy. He will solve lots of ideas. Lots. Every... Not each idea is very nice, but... I think some people like Gabor, people from the C-pans are really soft, the same as us, I think. There were also taking ideas from us to create new metrics and good... good procedures. Maybe if we say to them, please don't do this anymore. Okay, nobody objects. So we decide to write some statement. Please. Please. The right side would be a good idea. It's absolutely voluntary. Which letter? A letter of protest against modern install viral behavior. Okay. So it says, please share it. Oh, sure. Should we take down the yes? Okay, we can write it together on IRC, on Whiteboard, whatever. It's not urgent. We suffer for some... one year already. So who's that? Fideos? All right, all right. Next topic? Beer. Shut up. You may now speak again. I don't remember anything. So... So it looks we can close our annual meeting or something like that? Dear guests, you have been witnessing one of the meetings of the pro-group. We will now take another meeting outside of this place. Unfortunately, there is no video coverage there, but there are a lot of these kinds of pipes with some yellow liquid. Thanks for watching. Thanks for participating. And now, advertisements. A bunch? No, advertisements. Yeah. And now for advertisements. Bye. See you soon, I hope. Next year, Ryan, you have to be at DebCon. No more excuses.