 So, welcome to the LSB booth. I'm glad we are more than two people. So, here's the little agenda I've prepared. Just a short introduction on what's LSB, if you don't know. Then discuss the source package in Debian. Two specific binary packages that are LSB based and LSB released. And open discussion, action points, and feel free to interrupt at any given time if you have complements, information, questions, whatever. So, what's LSB? From Wikipedia, the LSB is designed to be binary compatible and produce a stable application, binary interface for independent software vendors. You can check the link if you want. The spec actually lists very extensively all interfaces. So, binary interfaces, data definitions, precisely. So, including the headers of the various libraries that have to be into. That have to be into a given distribution, the surnames, etc. There was multiple architectures, I think something like 14 architectures. There was S390X introduced recently in LSB. Well, recently in terms of LSB time space. Like it was probably introduced last year. LSB is there mostly as a useful reference for non-free binaries so that you can compile them on AMD64 against a given set of libraries and expect that to work on any certified distribution and it would just run without crashing and do what you wanted to do. Of course, if you have a free software, you can just download the source and rebuild it in every distribution. So, it's not really there for free software, it's more service from free software for non-free vendors. There are two tools that are available, provided by the Linux Foundation. One is an application checker that you can just upload your application and we'll check if the interface you use are in the LSB release that you point to. And the distribution checker, that is something that will launch a virtual machine or within a machine. Don't try to run that on your laptop because it will run as root and do many dirty things on your file system. So, that's why you should probably run it in a virtual machine. Last I tried, it was A, quite hard to run and B, then you get like 500 things that you have to fix in Debian and I probably mostly give up. The source package in Debian, you can check the tracker or the package, the PTS for that. Basically, it's Jeff Likia and me for Debian, Vorlin and some other people for Ubuntu have been also doing some changes there. We have some differences between Debian and Ubuntu for mostly historical reasons. They were implementing the upstart detection and feature functions there earlier than we have introduced in Debian and then we kind of have a little difference in some scripts for the exit numbers that we should merge but it's a little tricky so it just was pending work. It's tricky to maintain. It's not a certified implementation. Debian never actually went to the Linux foundation to get Debian certified. Mostly I think because no one was caring about that probably and because no one was always either asking for that. The source package is a little tricky to maintain because if we don't do the check-in then we just assume things work and then we just sometimes we have to do compromises. For example, the LSB41 that is supported in Weezy mandates Qt3 which was removed. So we kind of decided we just add a readme so that if you need that you need to know there is a readme, you need to read it and then you need to go and download the Qt3, the latest Qt3 version compiled from the snapshots. It's not ideal but it's way better than having me or anyone else maintaining Qt3 for the time span of Weezy. The new problem that will probably hit back in some months is that it's probably vastly broken with SystemD because a large part of the LSB norm is about how the inner scripts behave and what exactly you should put in an inner script and how you interact with the inner script. So that's probably broken. Now to the binaries. There are two important binaries in the LSB package. In fact, I think there are 12. The other ones are virtual. They only have dependencies. You can install LSB desktop and you get the dependencies to match what is mandated in the LSB desktop specification. But these two are specific. LSB base is one of the rare packages that are installed on all Devian machines that boot using CCinit and is also run at every boot. So it's shell script that is launched at every boot multiple times. So trust me, when you upload that, you do it carefully. Remember the green hockey blocks on the Weezy boot? That was in that package. It was actually a new thing in Weezy which makes me smile every time I see a Weezy machine boot. But yeah, that's for the anecdote. So basically it has init functions that implements some of the things that are mandated by LSB and that are used either by non-Debian init scripts or by Debian init scripts like the log-demon message and friends are all convenient functions to just output things to the screen and you have one function to tell the first thing and then you have two or three functions that you can use to say this was done, this was done, this was done and add the points or add the return lines and stuff like that. There was also init as upstart. There was added, I think, after that it was added to the policy just to make it easier to integrate the upstart init system in Debian 2. But none of this is used when using systemd unless, actually that's wrong, unless you use the original init script and not the systemd script because they will still run that shell. So unless we manage to transform all init scripts in Debian for jesse to systemd and we drop the ccv init which will not happen we can not drop that package at all. This package has 13 bugs of which 10 won't fix because requests or wish lists are not or just diverge a little from the norm. There is some merging with Ubuntu betting there that we should just do to make sure we have the same, I think it's bit of a proc that has some tiny stupid differences that we just have to fix. The other one is lsb-release. That chips a binary in your serve-in to discriminate distributions. Basically lsb-release will tell you if it's running itself on Red Hat or on Debian or on Ubuntu in which version. I mentioned the fact that it's silly because when you have a new application you should not be checking if you are on a certain distribution. You should be checking for features. So unless you do things for cloud at the distribution level no one should be using lsb-release but 94 service packages are doing that. Use OS-release? No, they should not check for releases at all. But yeah, I mean, it's used so and it's mandated in the lsb and people can assume it's there. lsb-release also returns the lsb-versions that the system is combined with. Exactly, and the modules in which they are and the architectures. Speaking of mic 4. Just leave it there. Pass it around I guess. Yeah, it's easier. The specific thing there is that it's a Python implementation. Quite old. I tried to add some unit testing to be able to migrate that to Python 3 without with a proper code but I just stopped in the middle of that because it works with Python 2 and we have Python 2 anyway in Debin. So I think Ubuntu has probably this automated Python 2-3 thing which probably works most of the thing. But it's a Debin-specific implementation that will guess, build or invent the version number out of either the files from base files or using APD cache smart which is broken apparently currently. So it has 3 bugs that need to be checked but I didn't have time. Yeah, that buff is going very fast, that's good. Now open discussion. What should be kept in Debin? A, nothing. So we just leave it as that. I would then orphan the package just to make it clear for everyone that I'm not caring about it. We would keep lsvbase and lsvrelease and drop the meta packages because they don't have very much interest if we're not certified. Fix the bugs in lsvrelease and lsvbase don't touch the rest so we stay at lsv41 or fix the bugs upgrades to the latest lsv which is 5 with they have released beta 2. But we need to do active checking otherwise it doesn't make much sense. But that would need help because I spend a little time fixing the existing bugs mostly for the latest release and making sure some things were included and making sure lsvbase was kind of useful but I don't have much interest in making non-free software work. I'll open the discussion. I don't have much more to say than that so I welcome opinions, volunteers or whatever. Or we can just stop and go to the beers immediately. Go ahead. I have a question about the systemd stuff. Have you been following as the lsv work groups anything about systemd and what their intent is with the init scripts? I don't know. They have been discussing things. Yeah. They're very good at that too. I think that I just checked while preparing that. I think they had a meeting in March and they said we do a github thing public and since then said pull request there. I don't want to be mean. That's just facts. I think they've been discussing the systemd thing. They've been discussing the dropping of qt3 for years. I think it's been dropping lsv5 but I don't know much more than that. Jeff would know he's involved in the lsv directly. This example you give maybe the qt3 thing mainly makes me think I'm not involved in lsv maintenance of course it's mostly a relic nowadays. Do you know if it's really used in the non-free world or is it some promise we made and we keep because we are good at keeping promises. How important is it to Debian or to any distribution? I think that's the core problem that we don't know but I haven't had any feedback besides some people using trying to install some random thing and having the init I think the script that installs the init is broken or was broken we just reverted something I think the core problem is that we don't know if people are using it and I think we have made a half promise. We promise that we do lsv but there are virus readme files and this is not certified and don't take it granted it will work that's why I think either we do it properly and we make sure we certify it or we stop pretending and drop everything besides the thing that I actually needed and both need work and the no work thing is we just leave it at that for Jesse and just opening and Okay you said about the world more or less the difference in the situation but what kind of thought or effort is given to lsv by other distributions I think but I don't know I think Red Hat manages to get itself certified I think OpenSuzi is getting itself certified too okay but besides that I don't know but does anyone know in the audience if lsv is used to have people or is that an expectation from people I think it was more than just for lsv's part of the intent was to have binary portability between distributions and to ensure that no one distribution broke the avi in such a way that that distros were going to start diverging so to some extent it was to prevent kind of what happened with the unix where everything diverged and we wanted to keep you know one common standard in that regard it's still I think interesting to ensure that Debian maintains avi compliance but in terms of certification and some of the other tools I don't know if it's worth the effort I mean it even mandates things in cups and I think the lsv mandates the support for cups 1.2 and we will have cups 2.0 in the next release and I'm almost sure there are things that are broken in avi compatibility instead and we've not been checking you do have not been checking and it's probably broken so the other thing is at one point we had a bts tag that was associated I think we used devin.lsb at list. devin.org is the bts tag and when we encountered failures in the test suite bugs were filed on the appropriate packages so I'm wondering if how many of those still exist you mentioned the bugs you mentioned the bugs on the lsv packages themselves that were finishing to know how many of those are still open and then also if somebody wanted to run the test again and see what's still failing and if new bugs need to be filed that effort might be kind of interesting I mean yeah patch is welcome in the sense that I think the only way is to run regular Jenkins tests that would run that properly I don't think you'll ever get the lsv test suite to run that way at least unless they've done a lot of improvement is a horrible mess that was inherited from a bunch of the old Unix tests and it's just crazy it took a lot of effort to run yeah so yeah my current feeling is when volunteers I will probably orphan it as is after fixing the easy easy fixing bugs just to make it clear that nothing new will happen we have 5 days to merge the difference with Ubuntu guys and we'll just do that and hmm yeah I'm just reading the devs what we have in Ubuntu and it's not much yeah it's just shell conditions in different orders I think and python 3 support I mean the python 3 is more a question for Debian to decide if whether we want python 3 in the base installation or not and yeah because I mean because it's pulled by lsv release mostly lsv base well lsv release is pulled mostly by in build dds I would say a daily for a lot of these packages you want it to depend on either python 2 or 3 such that at least one of them is sufficient but then obviously shebang needs to re-exact under the correct python that's available and things like that I mean I've done that for a couple of packages where I actually wanted that but does anybody know what's in lsv 5 I've checked rapidly I think just more libraries some updates and yeah I didn't check honestly because that might make a big difference whether you decide to keep maintaining it or not I mean if there's going to be no solution for the systemd stuff and there's other dependencies that are going to be hard for Debian to fulfill then well I mean the other way of looking at it is if they added things that aren't already in current Debian release the problem is with lsv not with Debian because the whole point of the lsv is it's no seriously the whole point of lsv is it's supposed to document the current consensus what already exists in the distros and help the distros maintain that compliance so if they're going off and specifying things that aren't already the reality on the ground then there's nothing we can do about that and I think one way to look at it is to take a problem in the inverse and look at very common non-free tools that people use Skype is providing the bin packages Dropbox is providing the bin packages I don't know what other examples but most of them need to do Valve are sponsors yeah so the question is I suspect they're not using the lsv linker and they're probably doing other things and they probably explicitly test on the platforms that they support rather than count on the binary do we know if we have any of them at our conference? it seems like we should ask them I could just mail them they've come to discuss to see I mean Skype is not using Qt3 it's using Qt4 yeah well because parts of Qt4 were kind of integrated in lsv2 so the convincing factor would more be if a big non-free provider would say yes we do use that and we do expect and we pay people to make sure it happens in Debian or we don't pay but we convince them with beer or something like that but it's up to the beginning because I've missed it not much sorry so any other inputs? do you have any idea how much effort it would need to do the second options which are to keep lsv and fix the things or upgrade how many more ads do you need on a package to get it to a point where I need patches on 5 to 6 bugs not much and if we want to upgrade to lsv5 it's mostly I would say a half day checking which libraries must be adding the dependencies to the virtual packages and then having someone launch the distribution checker somehow and just the problem is that if we run the distribution checker and it says there is a missing symbol in whichever library we can file a bug against that library and the guys will say yes but I need that patch that is changing this for this reason or this bug and then we just have a non-fixed bug and we fall out of the certification so are we filing an exception with the lsv work group? yeah part of the certification thing is that if we have a good reason for why we're doing something then we apply for an exception or we get them to fix the standard yeah but it's a lot of work to it's mostly bureaucratic work going back and forth yeah I must say I kind of expect that from Jeff Likia that is involved in both Debian the lsv package and the lsv process so I was that's the same the producers have been following the printing talk just earlier I'm exactly in the same situation I just ended up being maintaining lsv not because I'm interested in but because it was broken before a stable release so just doing it so if everyone in this room checks the list of bugs and files one patch each then it's solved any other inputs? do you have a web browser? do we check that tag I was talking about and see if there's anything still open? if the wifi is kind of working oh no you need last name as well yeah yes yes yes everyone has read that of course yes I was just wondering do not attempt to use goblin that's kind of why it failed blah blah while we wait for that does Jeff Likia still work for the Linux foundation? I don't know I've seen his rc names in some blog posts they've been released for 5 days or 2 I think but I haven't been in contact with him but I know he's under the bnlsv it's not really a high traffic the rest ok the answer is no it might be a little salt ok I don't know if that's better we'll see if it works with green internet tags how does tags work? I don't know what is it you go to uddd.net and it has a tag search I think it has a tag search like there in ah yeah you might be right it might be faster bugs use attack use wnlsv well you can just search for that was useful they're also good wasn't it a user name can you just search for lv without the user anything that only the tag same is that the only one you filed there were dozens of them if we I guess archive yeah they should be they might still be open to archive because the package got removed yeah package removed all bugs closed I mean it was in like X packages and libc they might weren't removed but maybe renamed 2x will have it yeah so I'll check if I find something I would hope Jeff would be running this on Debian and would know the current state of how many failures there are do they have a website somewhere where they publish these numbers I think they have this infrastructure program blah and then you have a web interface of things that run in the console yeah you don't want to try that I used to see some results somewhere is that I think they had distribution checker yeah I don't I can't find it now I mean they even test moblin me still yeah they started last week yeah over 500 participants it's nice that's just the ABI database I think yeah you get it for architecture so I did mention Valve earlier and it's reasonably likely that they will at some point outstrip them too in terms of sheer number of deployments in terms of being the largest Debian derivative because they have the Steam OS which they are planning on licensing out to hardware manufacturers a standard PC gaming console of sorts that they may be they may care a whole lot about this so maybe a good idea to make sure that they are part of their discussions what happens good idea I just tried to write that looks like somebody ran tests in 2013 I'm not sure whether it was the last UDS but the last physical UDS I think Valve did run a session about ABI stability and the things that they would care about and mostly it was we want the latest graphics drivers but we want ALSA to be stable and then we're like yeah just ship truths with your compile every thing no they can't statically compile because it doesn't link and we don't ship enough libraries to compile statically but yeah things they were asking oh can you keep X stable ABI yet make it work with the latest NVIDIA drivers which are binary only and require specific X ABI you can hit them at buying at NVIDIA yeah and in essence it was kind of very open-ended because in terms of what Ubuntu or Deepin could provide for the lifetime of the game versus what they needed for that game to still be running because in essence they wanted to compile it once only and never recompile it unless they really really have to because they kind of deal with like archive and longer term type of games it doesn't cost much asking yeah LSB alone was obviously not enough I mean part of the problem is just the scope how do you do to check 700 thousand interfaces and the combination between those interfaces of course more than 1500 libraries 30,000 classes looking forward to it so yeah I've added some action points I'll probably start from the top and yeah if anyone's interested in helping feel free other than that I suggest we head out to beers or sleep thank you and have a good night