[08:39] <seb128> wgrant, cjwatson, hey, is there a way to know who is tweaking the translation template sharing details on launchpad? or to lock those settings down? looks like the "sharing with main serie" has been enabled for most desktop packages again, but that points to buggy/outdated code import on launchpad and prevent source package templates/translations to be imported, which result in outdated/buggy ubuntu translations :/
[08:40] <seb128> I'm chasing down those manually now, which is tedious and leading to no change rebuilds
[08:41] <didrocks> seb128: speaking of which (and maybe related to your question), I guess you noted as well that GNOME Shell has some part of the UI in English, correct?
[08:42] <seb128> didrocks, yeah, that was discussed on the desktop channel some days ago and an upstream bug in gnome-shell, we need to get the .1 update
[08:42] <didrocks> ok, great :)
[08:44] <sbraz> hi, can someone explain what the +esm1 stands for here? https://people.canonical.com/~ubuntu-security/cve/2016/CVE-2016-7099.html
[08:45] <sbraz> my currently installed version is "4.2.6~dfsg-1ubuntu4.2" without the +esm1 part, which makes pakiti think that my system is vulnerable
[08:46] <sbraz> Extended Security Maintenance i guess? still, why doesn't the installed version match the version in the advisory?
[08:46] <cjwatson> seb128: I don't really know the details of this but AFAIK none of that kind of thing has a very useful audit log
[08:47] <cjwatson> sorry
[08:47] <seb128> cjwatson, no worry, I was sort of expecting it was the case based on the previous cycles conversations with William when that sort of issues happen
[08:47] <seb128> I'm probably going to write a script that goes through the pages (or use the launchpad api if it works for that, I need to have a look) and dump the sharing status
[10:15] <xnox> sbraz, hi. What's published in ubuntu can be seen here https://launchpad.net/ubuntu/+source/nodejs
[10:15] <xnox> sbraz, i don't know how Extended Security Maintenance works, you'd need to contact ESM support if you have that, and something is missing.
[10:16] <sbraz> xnox: yes and this page doesn't list the version https://packages.ubuntu.com/xenial/nodejs doesn't either
[10:17] <sbraz> xnox: and https://people.canonical.com/%7Eubuntu-security/cve/2015/CVE-2015-8860.html says "released-esm" for ubuntu 16 which doesn't make sense, 16 is still fully supported, isn't it?
[10:18] <xnox> sbraz, fully supported, but we only provide security support for main.
[10:18] <xnox> sbraz, node-tar and nodejs are from universe.
[10:20] <sbraz> xnox: so that ESM feature can be useful for xenial too?
[10:20] <xnox> sbraz, looks like it, it seems to cover more. you should contact canonical sales about ESM.
[10:21] <xnox> sbraz, i.e. https://buy.ubuntu.com/ has a chat thing and phone numbers too.
[10:26] <sbraz> xnox: what bothers me is that those esm packages which are not free are listed in https://people.canonical.com/~ubuntu-security/oval/com.ubuntu.xenial.cve.oval.xml
[13:06] <jdstrand> sbraz: Ubuntu 16.04 is still officially supported by Canonical for main/restricted and community supported for universe/multiverse. UA customers may receive updates beyond what is officially supported
[13:08] <jdstrand> sbraz: can you clarify why their inclusion in the oval data bothers you?
[13:16] <sbraz> jdstrand: it's always a bit frustrating to see vulnerable packages on my servers, i didn't even know ESM was a thing until today
[13:16] <sbraz> i thought a vanilla up-to-date ubuntu to have no vulnerable packages
[13:17] <sbraz> i assume if i were to run bionic, this wouldn't be an issue?
[13:18] <JamieBennett> sbraz: right
[13:18] <jdstrand> sbraz: nodejs is in universe and thus community maintained. packages that are community supported are kept up to date to the level that the community has invested time in them
[13:19] <jdstrand> sbraz: you might be interested in https://wiki.ubuntu.com/SecurityTeam/FAQ#Official_Support
[13:20] <jdstrand> how does that page not say anything about esm... /me adjusts
[13:24] <sbraz> jdstrand: i understand, it's just that i never had to think about all this before; it just worked as expected in the past, it's the first time i stumble on that kind of package/vulnerability
[13:26] <rbasak> Nothing has been taken away. You're just noticing more because Canonical are publishing more information for their customers and making some of that information public.
[13:28] <jdstrand> right
[13:29] <xnox> sbraz, "in the past" you had vulnerable packages in universe installed and there were no updates for those available - neither gratis, nor paid. And well, was vulnerable to CVEs applicable to universe.
[13:36] <sbraz> xnox: i'm not saying it was better, just that i hadn't noticed :)
[13:41] <xnox> =))))))
[18:17] <sforshee> LocutusOfBorg: so I just got told about shared folders not working in Vagrant because of removing the vbox-guest-dkms modules from the kernel, bug 1796647
[18:17] <sforshee> the kernel packaging continues to say that it provides virtualbox-guest-modules, which it shouldn't
[18:18] <LocutusOfBorg> sforshee, the kernel should contain them... why did it drop them=
[18:18] <LocutusOfBorg> ?
[18:18] <LocutusOfBorg> it has been using vboxvideo from the intree driver, and everything else from vbox modules
[18:18] <LocutusOfBorg> IIRC
[18:19] <sforshee> LocutusOfBorg: we've talked about this several times ... we're using the upstream drivers now, you said you didn't want to seed vbox-guest
[18:20] <sforshee> there should still be time to pull them back in though
[18:20] <LocutusOfBorg> ok but only vboxvideo is upstream right now
[18:20] <LocutusOfBorg> I remember some of them being upstreamed IIRC
[18:20] <sforshee> we must have gotten some wires crossed, I thought you said the others weren't important to ship in the kernel
[18:21] <LocutusOfBorg> vboxvideo is important if you want a good resolution
[18:21] <LocutusOfBorg> and yes, others are not fundamental, unless you want copy-paste from guest to host and such features
[18:23] <Odd_Bloke> sforshee: As a sidenote, we do need these drivers in the official Ubuntu Vagrant image, which I think would preferably not rely on the DKMS modules.  (Not a hard requirement AFAIK, but would maybe nudge us more to retaining them.)
[18:23] <sforshee> right ... I'm also now recalling that there was a conflict because the modules shipped upstream and in the dkms package have duplicated names
[18:23] <sforshee> both ship vboxguest.ko iirc
[18:24] <sforshee> so probably we'll need to rename vboxguest that comes from the dkms package, is that going to cause issues?
[18:25] <LocutusOfBorg> why? is it causing problems?
[18:25] <LocutusOfBorg> they have different directories, so there is no clash wrt apt side
[18:25] <LocutusOfBorg> and my vboxvideo has higher priority, something I want to have :)
[18:26] <sforshee> the kernel build infrastructure does not expect modules with the same name when it is building, and does not handle it properly. I can't remember the specifics off the top of my head
[18:26] <sforshee> I'm thinking it can't find symbols exported from one or the other
[18:26] <LocutusOfBorg> mmm so you are talking about the build farm...
[18:26] <LocutusOfBorg> interesting
[18:27] <sforshee> not the build farm, all the makefiles and scripts which build the kernel
[18:28] <sforshee> it may be some kind of namespacing thing, like I said I can't remember the exact details now
[18:28] <LocutusOfBorg> but you don't have to copypaste my vboxvideo from vbox source tree, just the others
[18:29] <sforshee> but I am thinking that something failed to link because it wanted exported symbols from one of the vboxgues modules but wasn't seeing them because they were masked by the other vboxguest module
[18:29] <LocutusOfBorg> I don't know...
[18:29] <sforshee> the simple way to avoid it though is to rename one of them
[18:29] <LocutusOfBorg> what about providing "virtualbox-guest-video" kernel module?
[18:30] <LocutusOfBorg> and let the others come from my vbox source package?
[18:30]  * LocutusOfBorg has to leave shortly
[18:31] <sforshee> that doesn't fix it, we were already doing that
[18:31] <sforshee> anyway, let me look into it
[18:32] <LocutusOfBorg> ok
[18:32]  * LocutusOfBorg leaves
[18:46] <caravena> Hello... What does it mean?: 'rls-cc-incoming'
[18:46] <caravena> ^ Trevinho: Hello :-)
[18:46] <caravena> -> https://bugs.launchpad.net/bugs/1796422 You added the tag 'rls-cc-incoming'
[19:00] <infinity> vorlon, mdeslaur, kees, stgraber: Tee Bee.
[19:00] <mdeslaur> infinity: ack
[19:04] <jbicha> caravena: it's used to suggest that that bug should be a priority for fixing for the CC (Cosmic) release
[19:05] <jbicha> bugs with that tag will show up on http://reqorts.qa.ubuntu.com/reports/rls-mgr/rls-cc-incoming-bug-tasks.html
[19:05] <jbicha> bugs can be fixed without that tag too
[19:15] <caravena> jbicha: Excellent! Thank you