 Anyway, because the first topic that I wanted to cover is how can we keep using security.devn.org for WISI, which involves while somehow transitioning the rights from the security team over to the LTS team when the support period ends. And without any FTP master to discuss this, it's a bit useless. So maybe we will first start with a new topic. Second topic is what do we want to support and what can we afford to support for WISI LTS? Do we want, on two levels, do we want to support more architectures, people who are currently supporting only A and D64, E3, and 86? And what about the list of interpreted packages? So they would be really nice if it could be a bit shorter. This is supposed to be a bot, so not only me speaking, I will ask you your input and I hope that we will be making input from security team members. So we have our FTP master. You alone? No, sorry. So maybe we can go back to the first topic because I expect the second topic will take more time to stop all the topics we have. The fourth question is what I have written down, but if you have other topics throughout, sure, we can do some more. So maybe... Then there's another topic then what to do if the issue is not fixed in stable? Yeah, it's part of the missed question. No, the missed question is not fixed in unscable, but there's also the situation that packages are not fixed in stable. It's usually... It's related to... So I would like to add another question, but I'm not sure if this is on topic, and the question is are we going to do an LTS for every release? For example, or are we going to make three releases because it will make more and more support effort? I know that there are problems with skipping releases, but is this possible for just something else? There's a kind of support time frame that shouldn't be much overlap. I mean, if it's two years, we essentially have an overlap of a couple of months and no solvers. If you would skip it, you would leave it in the world. Yeah, that's possible. It fits very well. So there's no point in skipping a release the way it's organized means we roughly support every release for five years, two and a half by the world security team and two and a half by the LTS team. So it's much more... And I think we can say that we will do LTS for future releases. Till now, LTS was an experiment, and I think we can... TTS experimented success and have been continuing doing LTS for years. Yeah, I think that's an important point, actually. That's what we already announced, because... Well, it was rather explicit in the JSC release and announcements that it would benefit from LTS as well because up to now LTS has been sort of working relatively well. So maybe Ansgar, you're trying to start and then work for you or Moritz, I don't know, who are... How can we handle this... this usage of state-critical without having a report or by the LTS team? So I think once, basically, we have to squeeze LTS suit on security W and O.C. instead of... No, by the way, we want... No space suits you want to keep using the suite that the security team is using so that the user do not have anything to change in their source list. And currently, the policy on LTS is rather free-form, because this is something that we could change. I mean, right now, the suite is open to any DDTMs. There's no proposed update in front of... Has there's new queue in front of it? While there are queue in the case of security repository? From my point of view, although my reaction is okay if we keep this queue and F to handle the burden of validating or accepting the package that are uploaded. So, because we have people sort of in charge for front desk work, that could be in charge of accepting new equals. It doesn't need to change everything, but at least we'll hand over access rights. Yeah, that's probably possible, but so if you get a login on security master, you can... You can check here. Maybe I should go towards the other side, when someone else does. So, one of the things we have security master on an extra list is because there are these embedded issues. I don't know if the LTS team is supposed to see them or they are still being embedded, but there are various ways to see them if you are on security master. So, that's basically something we need to ask the security team for. Then having a suit without any policy queues is fairly simple. So, that's like squeeze LTS currently works. A bit of a not nice part is that we currently have the unsupported architectures that are present as well. And if you support only MV64 and I386, then the packages get out of sync between architectures, which is a bit confusing. Can you stop a moment so that Jean-Pierre can take notes, because you have the third topic right now and she's at the first. I forgot the second one. Can we drop architectures during the lifetime technically, yes. What is the problem with the fact that they would be not in sync? Is it just on the display? I think it's mostly in display and some people packages might get uninstallable on the out of sync architectures. I don't think that's too much of a problem, because they are no longer supported anyway. Can they be removed from the unsupported architectures? You might also do that instead, because people then notice that it's no longer supported and it's no longer there. That might actually be a good idea. One other thing, there we are. If you want a suit without a policy queue like squeezeLTS is currently handled, that's very simple, because you don't need any lock-in or anything. We just drop the one set of the policy queues and accept uploads directly. I think having the option to wait until all the bids and packages are nice. Keeping a queue makes sense. Not a day to interrupt when you have something to say. I would think that the possibility that every GV can upload to it is something really nice which should break in case of more complicated cuts. Currently for the current architectures there will be rather fast to build so I'm not sure how much of a problem is in practice. You always introduce some additional stuff which people who are not involved in a day-to-day basis will miss. I think 80-90% of all people for that time in the audience of NLTS could only use this before. So I don't think that's much of a problem. I would keep it as simple as possible. The more complicated it gets for the what you want to encourage is to have like the maintainer wants to make the extra effort and still prepares NLTS for his own customer package so that's the ideal case that person does the update himself. The more complicated it gets the more special steps in between then you lose that or you just introduce regression so I'm not sure how if there's a specific problem which arose from how the work how the way it's handled. Right now I think what we want to get is that the packages are available in the same place that people don't need to switch their outsources. So it's a technical way. It doesn't change the workflow so that maintainers can just upload to the suit. Maybe it's a bit related to the second topic because at least I'm a customer of a hoster which provides our own CPU so personally I would like Can we say the first topic? Yeah but just to keep giving back to the topic if we add this architecture we want to dim more following ATS and a larger risk of being unable to package because usually when it builds on IED 64 it builds on E3 ATS 6 it might not be the case for our architecture. I agree it's probably not needed at the start but if we have this problem maybe at the moment I don't know anything that ensures that the packages have been not just like so there's no coordination between the uploads and the issuing the DLA so whether the uploader has a minus of those builds and then send the DLA once the builds are ready but even that does not mean that it's necessary actually on mirrors what they sent the DLA before what packages are actually available but with security there shouldn't be there shouldn't be mirrors but they're still still going to wait for those builds to happen we shouldn't be saying that's that's fine clearly the queue in front of well if we don't want to check if we have this queue then we have to change the time the maintainer can send the DLA that's why until we approve it's alright that it doesn't impact since we need to drop this queue and have an open policy let's keep it that way for now and we can't see that maybe if we start to have problems we start to copy that we know yeah both the DLA can you add to this topic the two benefits we have from this also because the benefits are users don't have to change sources list and no delay through mirroring yeah and then I would like to ask the security team this risk of seeing environment vision is not a risk it's a real problem like anybody at the moment only the security team can look into security master so how would you think how do we fix it or address the problem can we address that problem I'm not sure but it's not only the problem of being able I mean the broader the there's an abundance of privilege escalations all the time so the more people you get with even unpublished access to security master you always have to risk so we need to keep this in mind we need to tidy it there's no queue to where we have to accept package nobody needs to have access there's one other annoying thing currently about security master if you were to use it that is all mails generated by the archive software are currently redirected to the security team mailing list because well I would that in our barcode upload was accepted and so on we want to prove on that anyway but the current stage is that only the security team would get mails about any uploads that happened and also about rejections is there a way around that because clearly in the workflow right now people upload the way they get their accepted mail and then they send their DLA so the current idea is that mail notifications should also go to the person who signed the upload so that maintainers that prepare security authors that are not on the security team notice if something unexpected happens but that doesn't exist yet and ideally that the accepted messages for the squeeze for the LTS release should also be sent to the public mailing list so that happens now for squeeze LTS I mean it could be just so technically in a way that it still gets uploaded to the current which is going to be used and once all supported architectures so both both 30 so 606 and 8064 are present it gets sent to the security master for some script but once it's more complicated in the end I think we want to fix and make sure that's the end it just takes the line so actually we have nothing to do we saw part of your plans to mail the person who signed the upload yes because that person should know about upload anyway there's also a fact like every every developer uploads a security update to the archive and if something's broken they don't notice and we have to bounce it mainly to them that's what we generate back here we'll just talk about that okay so basically we have solved everything terribly or is there something else that might in resist change maybe it's a time so discuss topics free at the same time because I guess if we want to under the embargo issues we really have to use an embargo queue as well and some members of the LTS team will have to have access so I also I think there's no strict need for an embargo queue it's a separate list so it's not in our discretion anyway but I think it can be arranged that one person on the team gets access to the linux stage vendors list and then that person can prepare the updates and once they are available it gets uploaded I think it should be two or three people it's at least two limited we already have the mag ball as max out I mean if that people is to be is on the page or whatever I don't think we can squeeze another three we are already at the high limit we have the most people of all distributions on the subscribers list and I mean we can argue we are getting another person to be being some separate sub-project but we won't be able to get three or something like that we already have more than redhead and susan for example so I don't think so if some person is unavailable for vacation or whatever that that person is unavailable for vacation or whatever they can just tell us and we'll bounce things to someone else but I think we'll be able to get three I didn't want to consider this question directly but there are only the parts that would have an impact on the deck installation so who should have access to the signature that they have not or the machine to so you said unbagged queues are not necessary because the person handling should just report the thing at the right time basically sorry? that is delayed by the minute but it has to wait three days that's probably not true so we'll consider this nothing comes to mind right now let's go to the next topic we have to go to decide what set of package we're going to support or what set of architecture as I said below I've got at least one request of customers who are interested in arm support for long term support exactly it was sort of generic query not so specific to squeeze clearing and it doesn't make sense so would it make sense to support of arm HF4 and I guess only this one because Armral is not the kind of server device that you I mean all of these Armral architecture is actually using server installations I don't think I don't think Arm Plastic Arm is used very much in server installations I don't know there is a scallway.com which is part of online.net which has a full cloud infrastructure based on Arm device that they can bring Plastic Arm Plastic Arm does that give it a 64 bit on systems? no it's it's not an arm64 I don't know which processor it is I have always said it's really this architecture but I don't know if it makes sense because if it's only me I don't want to contact other people that makes sense might it make sense for Jesse maybe because I think some of the virtualization stuff is just getting in place now so there's lots of stuff missing in Arm which is still a little easy yeah my impression is that I'm actually using in terms of hardware support which is kind of just pretty difficult I think would rather ask the question why not support all architectures because DSA want to get rid of IA64 I did not ask DSA what they sort of keeping I just think I would drop but in general I wonder why not supporting them all there might be some packages which don't find that most security issues will be fixed in all architectures I think if you keep architectures that are still supported in the later release it's probably not an issue because we maintain builties for those anyway and having them build an extra suit probably doesn't impact it too much I think current support might be other these stuff might be nice to support that's also the icing to the ice stuff which hits the break it's mostly all doing the routines it's not supported at the moment quite a number of software which is quite brutal if you look at the statement proposed updates where things get stuck for a while it's almost impossible to get OpenJDK for example continuously update it of course also it's only supported upstream essentially for I think Spark for historical reasons and for x86 and it breaks all the time and I don't think this would work out we haven't had OpenJDK enter a stable point update since three years by now because it's always breaking in some later release it would make sense to just look at what are people using and not saying is this the deviant thing that just supports everything all the time but it comes with a significant cost given that the sponsorship which you guys have accumulated is something at the 50% level let's spend resources on which it's useful if there's no demand for running no one is running Spark on deviant for practical purposes have some toy box somewhere in the basement and why build all these packages and why deal with revisions and all that I don't know what the best way to decide what we want to review what we want to support in a way in terms of packages here's a list of packages that we do not support right now in squeeze so the other way around is to discuss them in squeeze which we would rather not support so we should maybe move onto this list before we discuss things that are now which are constant pain I don't know of any because before we pull in stuff there might be stuff we want to pull out virtual box anything with our personal strength yeah yeah I think that's about the point actually because it's a pain too once again we have some we have some people here which are bigger to work with us and keep it can you just ask the same way you asked for squeeze at least the supporters and ask them what packages they use oh I know which packages they use actually I can show you that did you send an update for this for Weezy? no I mean I don't really send it for squeeze but it could have changed for Weezy this is something that we did not publish yet but that I want to publish that all the contributors paid for Weezy it's the list of packages installed by our sponsors so you can see we have a package not supported not supported but I how do you tell the percentages? it's basically a professional customer of the customers we have this package installed by Sheet and Sal but there are some Sheet who don't give the list of all installed packages only packages that care about I don't know that's why some packages are not at least give some idea of which one is popular which one is not popular we have quite a long list already of packages which are installed by several of customers so I don't know if you want to check out a specific package we can I don't think anyone use video with you on production side he would be surprised by what you can see anyway I don't know what is more interesting you used with a suggestion that that's not a permanent address though I mean that there was packages when squeeze was imminent if you look at that third of that packages are removed for example I just filed a review request for another one so this needs to be checked there are some which I think for example FFMTEC is not easy for example Google 6 is no longer easy access to C for example it's essentially removed several of those haven't made it too easy as well because they will receive our free copy for a long time and I maintain so I think to make a there are some packages which will be from all the small normal businesses for example PDGO has been removed there are some which which you need to discuss on a generic like should there be support for IZ Weasel for example you won't be able to to support Chromium and Weezy because it's already unsupported in Weezy since the hero releases require a more recent version of G++ since you need some G++ and 11 features which are not available in the two chain which is available in Weezy some of them are technically impossible and for assignments mostly a policy called ISTA is very mild for IZ Weasel ISTA for example ISA for example also no longer exists Is that basically a question if you want to support any typical desktop applications Yeah I mean it's mostly I mean I'm not really involved in ITS just some points I would like to raise but what's the focus audience what are people what are people want to support and I mean support supporting a significant amount of work since you need to essentially follow the LTS releases otherwise there's no way to do it and my commie won't be able to do at that work so it will be handled as part of the frequency and stuff and if you're doing that is there I mean is it in the interest of the people of paying and is there anyone using IZ Weasel In the case of IZ Weasel we have we're doing the work internally so the reason why it's not done for for squeeze is just that actually it's similar to Chromium that we need Python 2.7 we don't have that in squeeze so it's not big data in squeeze so they can't upload it to package it will be built and on their side they are building it with a sort of PPA which has Python 2.7 and was squeezed and then they are just injecting the result of the build in their normal squeeze should we maybe consider something like that as well for us maybe at some point this is going to be harder but there's a reason both to add new build tools to the LTS if necessary maybe while the case of Chromium it will not be possible because the more reason C++ also has so LTS and C++ has changed that's not possible in the case of Python you can still change the binary name to make it specific to the IZ Weasel build so with some accuracy it will be possible but we can't really anticipate what our IZ Weasel will be structured and done and it's changing every essentially the releases are essentially less every six weeks and I think the LTS releases will be a year will it be a year? it will be seven maybe two weeks so essentially roughly a year plus or minus something so no one really knows how IZ Weasel 59 will look like it will be possible to do this in back ports because you can put the depends in a sloppy back port I mean you might be able to make it work I mean Rafa you guys I think he is doing the work for Redempt Buddha and if he has been able to do this by now it probably works out but I think you can't make promises for that but how does anyone really need these two applications for LTS maybe LTS maybe FH it's their work systems they run like for researchers for researchers there are other desktop users those two are the same so schools often have that so looks like we even 37% of the paid customers so I will be planning to support some form of virtualization that was my next question maybe we don't want to check each package individually but clearly KVM, XAM and QVM were packaged that are installed and sponsored it's an important use case I know they tend to be affected by quite a lot of issues like where they see use work but do you see any issue apart from the amount of work or it for the presentation first question was for example and QEMO were at really early stages so even if you would throw a solid full time position on that you wouldn't have been able to backport all this because you would need to essentially backport huge parts of functionality which are missing from these kinds of security fixes I'm not sure about 1112 which is for QEMO individually I'm not sure I'm not sure it will probably work out but it also depends on the level of familiarity with the first people who are familiar with QEMO willing to you will get run into some contributed backport because a lot of these security fixes are actually intrusive so the older guests will not be able to get it it's probably easier because they sign absolute support they've back quite long they still support and we've asked for you three and a half years so it's not that bad but with QEMO I think you're on your own for much much earlier it's another kind of long term support series and this is the kind of package where we can do wire shaft and then port a new version out of question if you would do that with QEMO you would very likely have to fix the work from time to time because new features can sometimes break all the work so yeah at least the package is entangled in some way I think it's doable but it's just not that we can just call it and there might be other things like CBIOS and these kind of things but I think for the virtualization part of the production would be really nice to have this kind of thing so maybe it might be through the effort yeah, yeah can we have more friends? maybe we can have a check what brand enterprises currently support or something like that if this is by accident some kind of version will be quite close to understanding this wording or something like that would make sense but we should aim to support virtualization and we can see cost of upgrading to a new version and this is something that we can do not only for the old version but for the old version it might be forced like yes or no sure that this is too specific or too general because we should and which virtualization technology and well it's obviously which are not supported right now it's a little bit easier yeah I'm not sure I'm not sure of supporting LXC in business with what I think it is LXC is LXC actually a package that is counting regular security support issue do you remember Maurice there were anything mostly about that thing it's not a business it's a business or a useful business more like a company useful without a new kind of most of that it's not useful okay we don't have many minutes left on the topic of embargoed issue we had some discussions with the mailing list already a few months ago Maurice do you agree with the idea of creating an alias for two or three people from the MTS team where you or anyone that would be designated to follow the training embargoed list forward the relevant information so that's I think we can just find one person who can get subscribed to Linux slash vendors and then that person can handle it and if that person is on location or whatever then we can stay for a few weeks but we don't get entangled in that so it would rather not have the security team forward that that to Zee so yes you could try that someone is directly appointed on this list there are no aliases allowed on Linux slash vendors but I don't want that but you also want to form a group well I guess yeah but the idea of that is that you're not forwarding what is sent there it's not automatically yeah but not even if there's no border plates if we just find someone then he must do the work then he must do the work himself he should not share the data with you can't subscribe in alias so you just find one person and then we can recommend that that person gets added to Linux slash vendors and then we can forward at his discretion some of the information sent there is exclusively not allowed to be forwarded so in that case that person would need to do the work himself but what are you referring to that isn't the access to the Linux slash vendors or what does well my idea was that we would not add someone from the alias team directly to the alias on this list do you want to create a contact point if we just want to form something yes to us we can certainly do that but I was referring to get access to the Linux slash vendors list because that would not be possible with such a setup and then we can forward whatever or we should just add them to cc show them to the world would that be enough or do you still want someone from the alias team to join the alias on this I think it would still be useful because that person should ideally also participate in the discussions on that mailing list so there is something there is a discussion like does someone still use that version so in that case that person could step forward and say yeah this is actually still supported without the other subscribers being and you could also for example if that person is on that mailing list he would also know to the others for example say for example in case there is the patch for the squeeze version it's more complicated than for stable or for easy or for jesse and then that person could check out with the person who reported it etc etc so there might be just cases where the longer discussion involves about that and in that case it would be totally bad if someone totally unrelated to this or maybe it just pops up when they type up this information so that's rather make this official and clean and find the person who will be appropriate the alias on this domain managed directly by the security team we use it in the past but then the screen now with the other mail has been nice in the so we should just open it yeah just to see honestly in the future yeah I guess we have under the most important question on this question we can do it off off video and on the order while on the list are we happy with the result okay so thank you for participating enjoy the rest of your conference