[00:32] <flexiondotorg> tjaalton: Will you be syncing libinput 1.10.3-2 from Debian to Ubuntu?
[00:33] <flexiondotorg> Looking at upstream changes, it appears it resolves fixes pointer jitter detection, something I'm seeing people bumping into in the Ubuntu MATE community on some models of trackpad.
[01:19]  * tsimonq2 files bug 1757024
[02:16] <jdonald> For https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1711337
[02:17] <jdonald> Now that we have a diagnosis and a proposed fix to go from Firefox not-running to running, can we get the Importance set to Medium or High?
[05:19] <tjaalton> flexiondotorg: yes
[07:52] <tjaalton> flexiondotorg: why not?
[08:05] <Mirv> tjaalton: bug #1756380 might be interesting to target for fixing for release. if Firefox finally gets VA-API enabled during 18.04 LTS lifetime, this would affect quite a lot of Youtube playback
[08:06] <tjaalton> Mirv: yes, I'm trying to find the debian maintainers..
[08:06] <tjaalton> to update it to 2.1
[08:06] <tjaalton> which is needed for cannonlake anyway
[08:06] <Mirv> I wish it'd be lowNMU
[08:12] <tjaalton> it's team maintained
[09:14] <dja> doko: quick question re: python packaging - the microsoft folk who do walinuxagent want to add a dependency on python3-distro. walinuxagent is in main and python3-distro is in universe - do you think a MIR for python3-distro would be likely to be acceptable?
[09:20] <doko> dja: it's a simple module, why not. but then, why would you add that in a package? sic ...
[09:22] <dja> doko: walinuxgent gets info about the distro to configure itself properly. The python standard library is dropping the functions that walinuxagent uses, and python3-distro is the what they want to use to replace it.
[09:25] <dja> they raised a support case with us - the proposed pull request is https://github.com/Azure/WALinuxAgent/pull/1036 and they wanted to know if that approach would work for us
[09:36] <doko> dja: yes, it took me a long time to get it out of the standard library ;p
[09:56] <themill> slangasek: we talked about ktikz in the context of poppler-qt4 a while back. The new qt5-only version has been released and migrated to buster now. Can you (or someone else) update bionic to that version?
[12:54] <phoenix_firebrd> Hi, can a one line patch on intel vaapi driver be backported to 16.04?
[12:54] <phoenix_firebrd> this is the official intel patch on the vaapi driver https://github.com/intel/intel-vaapi-driver/commit/9d66570032fb02b1e79a883af7697b035d700a8e
[12:55] <phoenix_firebrd> this is the bug report on the issue on the official git page https://github.com/intel/intel-vaapi-driver/issues/297
[13:10] <apw> has anyone mentioned issues with encrypted disks and needing to installl libblkdev-crypto2 ?
[13:12] <jbicha> apw: see LP: #1754422
[13:14] <apw> jbicha, should we not start recommending it too as functionality is broken without it, even if that makes it ping on the components missmatch?
[13:15] <jbicha> what do you mean "broken"? is is broken compared to 17.10?
[13:16] <apw> jbicha, seth just upgraded and lost the ability to mount encrypted sticks, which he had before the upgrade
[13:16] <apw> jbicha, i am assuming from the upgrade list on my box, i will fall into the same hole if i hit return on the upgrade too
[13:18] <apw> jbicha, i am going assume it was the libblockdev which dropped into -release on the 13-mar which was the issue
[13:19] <jbicha> well it's blocked on Security review so if Seth is affected by the issue … ;)
[13:20] <phoenix_firebrd> Hi, can a one line patch on intel vaapi driver be backported to 16.04?
[13:20] <phoenix_firebrd> this is the official intel patch on the vaapi driver https://github.com/intel/intel-vaapi-driver/commit/9d66570032fb02b1e79a883af7697b035d700a8e
[13:20] <phoenix_firebrd> ‎ this is the bug report on the issue on the official git page https://github.com/intel/intel-vaapi-driver/issues/297
[13:21] <juliank> I think there was some discussion about that yesterday
[13:21] <juliank> tjaalton: ^
[13:22] <juliank> phoenix_firebrd: generally though, asking twice in thirty minutes does not improve your chances of getting an answer.
[13:22] <tjaalton> needs an sru bug too
[13:23] <phoenix_firebrd> juliank: I do not intend to , but I was trying to talk to the active persons here
[13:23] <apw> jbicha, that seems backwards, but hey
[13:24] <phoenix_firebrd> juliank: were you tell me that there discussions regarding the bug I addressed?
[13:24] <juliank> phoenix_firebrd: just because some people talk about different things does not mean they want to talk about your thing. IRC is a slow medium
[13:25] <juliank> phoenix_firebrd: I think so, there was a lot of chatter about i965-va-driver yesterday
[13:25] <phoenix_firebrd> juliank: wow, thats great
[13:25] <tjaalton> but not about this
[13:25] <tjaalton> bionic
[13:25] <juliank> I did see a link to it somewhere :D
[13:26] <tjaalton> which I just uploaded
[13:26] <juliank> was it in #debian-devel?
[13:26] <tjaalton> that too :)
[13:26] <tjaalton> and #ubuntu-release
[13:26] <phoenix_firebrd> tjaalton: ya, I updated the bug report and I had been pushing for that for a long time
[13:26] <tjaalton> it's all over the place
[13:27] <juliank> that's https://bugs.launchpad.net/ubuntu/+source/intel-vaapi-driver/+bug/1756459 I think?
[13:28] <phoenix_firebrd> juliank: ya that one's mine
[13:28] <phoenix_firebrd> juliank: also I updated another one pointing to 18.04
[13:29] <phoenix_firebrd> juliank: https://bugs.launchpad.net/ubuntu/+source/intel-vaapi-driver/+bug/1756380
[13:29] <phoenix_firebrd> tjaalton: thanks for the channel names, I missed those
[13:30] <tjaalton> my upload to bionic fixes 1756380
[13:30] <phoenix_firebrd> tjaalton: uploaded?
[13:31] <tjaalton> https://launchpad.net/ubuntu/+source/intel-vaapi-driver/2.1.0-0ubuntu1
[13:31]  * juliank marked the bug as fix committed to keep track of things
[13:32] <phoenix_firebrd> tjaalton: what about backporting a one line patch to 16.04 so that the vlc devs can rebuilt their vlc snap and the bug is gone?
[13:32] <tjaalton> phoenix_firebrd: your bug only mentions 17.10
[13:32] <juliank> xenial runs 1.7, and that's what snaps use
[13:33] <juliank> (xenial)
[13:33] <juliank> So if the VLC developers ship 1.8 in their snap they have to fix it themselves
[13:34] <phoenix_firebrd> tjaalton: aweosme work about fixing bug on 18.04, thank you so much
[13:35] <juliank> unless 1.7 is affected too
[13:35] <jbicha> apw: adding the recommends without the approved mir isn't a very good workaround because my understanding is that it will fix the problem for upgraders but not for new installs from now on
[13:35] <juliank> and they use that
[13:35] <tjaalton> I need to run now, but the bug needs to be properly targeted
[13:35] <tjaalton> and with a SRU header etc so that it won't get rejected from the queue once sponsored etc
[13:35] <juliank> phoenix_firebrd: Please figure out which versions are affected, and provide test cases and stuff according to https://wiki.ubuntu.com/StableReleaseUpdates
[13:35] <eoli3n> Hi
[13:36] <eoli3n> i'm searching for the path of "ubuntu 16.04 LTS" logo printed on 16.04 unity greeter please -> https://ptpb.pw/Qu0L.png
[13:38] <phoenix_firebrd> juliank: tjaalton can you people come to #videolan for a min, we will talk to a dev there? I said I will come back to him/her after talking to you people? You people together talk to and come to a solution
[13:42] <manuelschneid3r> is this the correct channel for 1804 dicussions?
[13:44] <Faux> No, #ubuntu+1.
[13:45]  * thresh waves
[13:47] <phoenix_firebrd> tjaalton: juliank, thresh is a videolan developer. I would like you guys to discuss about backporting a driver patch to 16.04
[13:48] <phoenix_firebrd> tjaalton: juliank thresh ‎ this is the bug report on the issue on the official git page https://github.com/intel/intel-vaapi-driver/issues/297
[13:48] <phoenix_firebrd> tjaalton: juliank thresh ‎ this is the official intel patch on the vaapi driver https://github.com/intel/intel-vaapi-driver/commit/9d66570032fb02b1e79a883af7697b035d700a8e
[13:48]  * juliank preparing lunch. will be back in ~5min
[13:49] <phoenix_firebrd> thresh would like to have you guys backport the above one line patch so that he can rebuild the vlc snap with the fixed driver
[13:52] <juliank> phoenix_firebrd: thresh: As explained before, we need to know which versions are affected. The bug only talks about artful (1.8), but snaps are built from xenial (1.7).
[13:53] <juliank> And apart from figuring out which releases are affected, we need test cases to verify that the uploads fix the bug
[13:53] <juliank> which is all documented in https://wiki.ubuntu.com/StableReleaseUpdates
[13:55] <phoenix_firebrd> do any of you guys have an intel kabylake processor or newer?
[13:56] <thresh> I don't
[13:56] <juliank> I have the lasted and greatest i5-8250u
[13:56] <juliank> :D
[13:56] <phoenix_firebrd> juliank: does it have VP9 decoding profile?
[13:57] <thresh> (still waiting for Lenovo to start selling T480 here)
[13:57] <juliank> phoenix_firebrd: I have no idea
[13:57] <phoenix_firebrd> juliank: vainfo?
[13:58] <phoenix_firebrd> juliank: If it supports, can you try playing a downloaded youtube video(or any video encoded in VP9 codec) using vlc snap?
[13:58] <juliank> does not say anything about vp9 right now, but might need the just uploaded fix (I'm on bionic) - but then it works anyway
[14:01] <phoenix_firebrd> juliank:  can you try playing a downloaded youtube video(or any video encoded in VP9 codec) using vlc snap?
[14:01] <juliank> But its HD620 should support it
[14:02] <Laney> eoli3n: it's generated in unity-greeter itself
[14:02] <Laney> ends up as /usr/share/unity-greeter/logo.png but look at debian/rules
[14:03] <Laney> if you're talking about updating it for 18.04, I think Trevinho has a merge proposal for that
[14:03] <phoenix_firebrd> juliank: I checked the intel page and also the wikipedia page, yours is a kabylake processor and it supports VP9 profile
[14:03] <eoli3n> thx Laney i migrated to slick-greeter on 18.04 daylibuild
[14:03] <Trevinho> Laney: it should be landed no?
[14:04] <Laney> nope
[14:04] <Laney> one of the mps wasn't approved
[14:04] <Laney> going now
[14:04] <eoli3n> is there anyway to generate it outside of unity-greeter, which will probably disapear ?
[14:04] <eoli3n> by the way, slick-greeter is far away better
[14:05] <eoli3n> i can configure with a single conf file
[14:05] <juliank> phoenix_firebrd: probably have to switch from wayland to xorg, because it fails with libva error: va_getDriverName() failed with operation failed,driver_name=i965
[14:05] <Laney> you can get the program that unity-greeter uses from its source probably
[14:05] <jbicha> eoli3n: Unity requires unity-greeter for its lockscreen I believe
[14:05] <Trevinho> Laney: ah ok.. I thought you already published it :-P
[14:05] <Laney> I did but it failed and I didn't notice
[14:06] <eoli3n> jbicha: unity is dead
[14:06] <juliank> In any case a snap is not a valid reproducer for an SRU, we need to validate it some other way anyway
[14:06] <eoli3n> that was my ansible role to configure unity-greeter.... -> https://ptpb.pw/2Vep
[14:06] <eoli3n> what a mess
[14:07] <phoenix_firebrd> juliank: you get that error in vlc or on your host?
[14:07] <jbicha> eoli3n: in that case, why don't you use gdm3?
[14:07] <juliank> phoenix_firebrd: that's the snap
[14:07] <juliank> phoenix_firebrd: host fails with [00007fac7002f150] vaapi generic error: profile(19) is not supported
[14:07] <phoenix_firebrd> juliank: ok, I will test the patch on the 1.7 version of the driver in 16.04
[14:08] <juliank> because broken vaapi driver :D
[14:08] <eoli3n> jbicha: because i don't want to reconfigure entire display manager before 18.04 official release
[14:08] <eoli3n> i will probably
[14:08] <eoli3n> but not for now
[14:08] <jbicha> Trevinho: you might need something like https://github.com/ArcticaProject/arctica-greeter/pull/9 (if you didn't already fix that issue)
[14:08] <phoenix_firebrd> juliank: thats the current bug
[14:08] <juliank> yeah
[14:08] <phoenix_firebrd> juliank: when will the daily iso reflect the fix?
[14:09] <Trevinho> jbicha: that's already fixed
[14:09] <juliank> phoenix_firebrd: first it needs to migrate out of proposed to release, not sure if there are tests to run
[14:10] <juliank> if not, it should be pretty fast.
[14:10] <juliank> not sure when the images are built, but within the next 2 days?
[14:10] <phoenix_firebrd> juliank: ok. If i test the said patch with the 16.04 and update it in a bug report, is there a possibility that it will be backported to 16.04?
[14:10] <phoenix_firebrd> juliank: ok
[14:11] <phoenix_firebrd> thresh: a question was raised that why not the vlc team instead use a patched driver, who do you say?
[14:12] <phoenix_firebrd> *what do you say?
[14:12] <cpaelzer> bdrung: any updates on bug 1753938 - there was a reply yesterday which looked more like a nack still
[14:14] <jbicha> didrocks: I'd like to flip the order of the installer screen https://thishosting.rocks/wp-content/uploads/2017/12/ubuntu-18-04-minimal-installation.jpg
[14:14] <jbicha> to put Download updates at the top (since it's pre-checked), then Install third-party software, then Minimal installation, what do you think?
[14:17] <didrocks> jbicha: something to discuss with mpt, but I think it makes sense
[14:17] <didrocks> jbicha: I would rather be personnaly go with that order: download updates/minimal/3rd party
[14:18] <didrocks> jbicha: also, ask the kubuntu teams to potentially have the same order there
[14:18] <thresh> phoenix_firebrd, I'm not going to build a patch just for that, it's up to Ubuntu to fix it upstream
[14:18] <thresh> s/build a patch/build a driver/
[14:18] <jbicha> I'm fine with that order too
[14:19] <juliank> phoenix_firebrd: please read the wiki page I linked twice and try to follow the layout. I can
[14:19] <juliank> phoenix_firebrd: We can do that too, worst case, but at least figure out that both 16.04 and 17.10 are affected
[14:20] <juliank> [00007fac7002f150] vaapi generic error: profile(19) is not supported
[14:20] <juliank> mpv https://upload.wikimedia.org/wikipedia/commons/8/88/Big_Buck_Bunny_alt.webm
[14:20] <juliank> is a simple test case for me
[14:20] <phoenix_firebrd> juliank: I am very sure it affects 17.10 and I tested the patch too
[14:20] <juliank> same with vlc, but that gets other issues
[14:21] <phoenix_firebrd> juliank: that bug report on bug affecting 17.10 was created by me
[14:21] <juliank> that's not the point
[14:21] <juliank> the point is to figure out whether 16.04 is affected
[14:21] <juliank> the bug only talks about 17.10 and 1.8
[14:21] <juliank> again, xenial ships 1.7
[14:22] <phoenix_firebrd> juliank: ok I will check that out, I will be back with the result later
[14:22] <juliank> Most importantly, we need a test file/link to check against
[14:23] <phoenix_firebrd> juliank: tjaalton thresh thanks a lot you people
[14:23] <mpt> jbicha, making minimal install a checkbox introduces the problem “As opposed to what?” What happens when someone leaves it unchecked? Moving the checkbox doesn’t solve that problem. That’s why I designed it as a pair of ratio buttons instead. <https://goo.gl/DqtvZL>
[14:23] <mpt> *radio buttons
[14:25] <juliank> thresh: don't you want to upgrade the vaapi driver to 2.1 or something anyway to get support for cannonlake? Or just wait for the 18.04 core and rebase on that?
[14:25] <juliank> I guess there's still time :D
[14:26] <jbicha> mpt: ok, that would be a bit better. The current implementation feels to me like it strongly suggests the Minimal installation which I didn't think was our intent
[14:27] <mpt> jbicha, agreed
[14:28] <didrocks> jbicha: are you going to change it to this?
[14:29] <jbicha> it's on my to-do list to take a look at it, yes
[14:30] <thresh> juliank, I cant upgrade to anything newer than 16.04, or my snaps won't be accepted to snap store.
[14:30] <thresh> juliank, I can wait for 18.04, but that's going to take at least half a year, and very likely more than that, for snap core to get 18.04 there.
[14:31] <juliank> I was just curious about cannonlake :D
[14:31] <juliank> but it's still basically a year to go, so by then that should be ready and we focus on fixing VP9 now :-)
[14:34] <ogra_> thresh, you are completely neglecting the advantage of snaps with that ... the good thing about snbaps is that you definitely can do such stuff (and should)
[14:34] <rbasak> thresh: I build snaps in a container, so the release installed on my host doesn't matter.
[14:34] <juliank> thresh: Basically my question is how you want to deal with new hardware that requires newer vaapi drivers in the snap than there exist in the archive. cannonlake end of this year is one example, can probably base snaps on 18.04 by then; but icelake in 2019 might need another driver update. It's something to think about now-ish rather than when it happens
[14:34] <ogra_> thresh, (talking about the "i wont build my own driver" )
[14:35] <Mirv> my guess was that since vlc snap already includes self-compiled whole Qt 5.10, compiling newer libva + i965-va-driver as well would not be a bad idea for the snap
[14:35] <juliank> I don't have any problem with them not building their own driver, but then someone likely needs to do hwe updates for vaapi drivers
[14:36] <thresh> ogra_, with what?
[14:36] <juliank> it might be worthwhile anyway :)
[14:36] <thresh> rbasak, me too, I don't even run Ubuntu on a host that build snaps.
[14:36] <Mirv> hwe updates for vaapi drivers otoh is not a bad idea either, although it's probably not happening for 18.04 either as it's soon finished
[14:36] <thresh> juliank, I rely on Ubuntu to ship fixed stuff for that.
[14:36] <ogra_> thresh, with the "i wont build my own driver" ... this is exactly what snaps offer you ... add another part to your snapcraft.yaml and you can have a better driver than the distro
[14:36] <Mirv> since many apps will use the non-snap base distro drivers
[14:37] <thresh> ogra_, I didnt say I *cant*, I just *wont*, because it's not my bug.
[14:37] <thresh> it's for Ubuntu to fix their packages.
[14:37] <thresh> Seriosly.
[14:37] <thresh> +u
[14:37] <juliank> thresh: currently there are no updates for new hardware, so e.g. no coffee lake for 16.04.
[14:37] <juliank> that's all I am saying.
[14:38] <juliank> It's likely that someone needs to step up and come up with a plan for that and take care of it :)
[14:38] <ogra_> thresh, and they will be fixed, but until then you will have whining users that you could perhaps quieten with 5 lines of yaml ...
[14:38] <thresh> I understand that, and I think someone on HWE team needs to think about that.
[14:39] <thresh> ogra_, it's OK.  I cant fix all bugs instantly, but I cant ship something I can not test.
[14:39] <ogra_> i.e. take a look at https://github.com/3v1n0/telegram-snap/blob/master/snapcraft.yaml ... that doesnt use a single deb for building its binary
[14:39] <ogra_> well, phoenix_firebrd_ can test for you :)
[14:39] <juliank> Well, intel-vaapi-driver is in universe and not supported :)
[14:39] <juliank> I guess
[14:40] <ogra_> and there is forum.snapcraft.io with 100s of users that will happily help testing if you file a request
[14:40] <juliank> ogra_: they do
[14:40] <ogra_> yeah
[14:40] <juliank> ogra_: there are some build-packages in there
[14:40] <juliank> for example,       - libappindicator3-dev
[14:40] <ogra_> yeah, indeed ...
[14:40] <ogra_> they wouldnt need to though :)
[14:41] <ogra_> my point is that snaps allow you an actual archlinux approach (build everything from upstream) without being bound to any distro release ... isf you actually want
[14:41] <ogra_> *if
[14:42] <Mirv> thresh: it's just likely that Ubuntu won't have timely va api driver updates until 2020 at least, since 18.04 LTS is about to be wrapped and its HWE enablement does not include the drivers, and the drivers are only community maintained at the moment. so the choice is of course free, but vlc snap users would be happier with hw acceleration naturally in the coming years.
[14:42] <thresh> So maybe they should be maintained by a company, then.
[14:42] <Mirv> with 18.04 as the basis for snap build in half a year would bump of course hw acceleration support momentarily, but then it would start to lag soon until 20.04 LTS
[14:43] <thresh> It's a basic hardware feature these days, it's not 2005 anymore where we could get away with CPU.
[14:43] <juliank> of course you can get away with CPU :D
[14:43] <juliank> That's what the browsers do
[14:43] <Mirv> thresh: yes, it would be ideal, but as said it's not happening until 2020 at the current rate, so pragmatically speaking users will get a bit subpar experience - although as noted, it will get better when 18.04 LTS can be used as a base until again new CPUs come out
[14:43] <thresh> I understand that.
[14:43] <ogra_> well, i'm running 16.04 on a kabylake here ... i cant get vaapi at all on the normal distro ... the vlc 3.0 snap helps a lot here
[14:44] <juliank> ogra_: how?
[14:44] <ogra_> (i cant enable vaapi witrh the deb but it works well with the 3.0 snap)
[14:44] <juliank> that's odd
[14:44] <Mirv> I've manually upgraded to 1.8.2 on my 16.04 LTS to get a bit fresher experience
[14:44] <ogra_> juliank, by switching to it in the vlc settings
[14:44] <juliank> ogra_: I meant, why can't you get that in the deb? The vaapi driver in the snap is the same
[14:45] <ogra_> juliank, "basic" vaapi works fine, i think it is just vp9 thats not working
[14:45] <Mirv> ogra_: weird though, since the vlc 3.0 snap has the original 16.04 1.7 va-api drivers
[14:45] <Mirv> I don't think that can have kaby lake support for about anything
[14:45] <ogra_> Mirv, that i could never get to work right on any of my machines from the archive
[14:45] <juliank> Mirv: I don't think anybody is preventing anyone from doing the work in 18.04 (or 16.04) and doing a intel-vaapi-driver-hwe package.
[14:46] <juliank> right?
[14:46] <juliank> or intel-vaapi-driver-community-hwe, whatever
[14:46] <Mirv> ogra_: juliank: ah, funny, the 1.7.0 from 15 Mar 2016 did actually add the very first kaby lake support - quite early!
[14:47] <thresh> juliank, browsers are exactly the opposite of what I could ever call a sane thing :)
[14:47] <Mirv> so aside from being buggy and lacking codec support, it's actually supported there, only coffeelake isn't
[14:47] <juliank> All I want is vaapi support in chrome
[14:47] <juliank> and proper mpv windows
[14:47] <ogra_> juliank, Mirv https://paste.ubuntu.com/p/M8gyv4jDrc/
[14:47] <Mirv> juliank: well, feature freeze for one prevents such a landing in 18.04, and adding such after a release is done is maybe unlikely with any process
[14:48] <Mirv> so hence my "probably 2020"
[14:48] <ogra_> (just streaming Tv frm my kodi box though ... no fancy codecs or anything)
[14:49] <Mirv> ogra_: nice! I upgraded to get some VP9 10-bit decoding functional
[14:49] <ogra_> probably the log lies ... but the CPU utilization is definitely less than with the vlc deb
[14:50] <juliank> I switched from vlc to mpv some time ago
[14:51] <juliank> That was the only player I got working in wayland usably I think
[14:51] <juliank> ugh, word order
[14:52] <Mirv> ogra_: right, the original VLC xenial version compiled with only VDPAU, not VAAPI support, even if the va-api drivers would have been recent enough
[14:52] <ogra_> yeah
[14:52] <thresh> ugh, wayland.
[14:52] <thresh> there is a remote chance that VLC from edge snap channel might work under wayland.
[14:53] <ogra_> well, xorg is around for another 5 years at least :)
[14:53] <ogra_> (thanks to 18.04 defaulting to it)
[14:54] <juliank> thresh: Well it works completely fine, but via Xwayland, so some perofrmance loss I guess.
[14:54] <juliank> ogra_: pff, I'll be on 18.10 sooon
[14:54] <ogra_> crazy
[14:55]  * ogra_ will stay on 16.04 until a proper unity replacement comes around :P
[14:55] <juliank> ogra_: Gotta run devel so I notice if stuff breaks
[14:55] <ogra_> yeah
[14:55] <juliank> :D
[14:55] <ogra_> i know ... i used to be in foundations :)
[14:55] <juliank> :D
[14:55] <ogra_> snaps kind of changed my habit ... and dropping unity too
[14:56] <juliank> Basically the same on my Debian machine - it runs testing.
[14:56] <ogra_> (i tried gnome for nearly a year but eventually going back to unity felt like coming home=
[14:56] <slangasek> themill: kitkz synced
[14:56] <juliank> (it used to be unstable, but um it's secondary now, so it's running testing)
[14:58] <juliank> ogra_: I have not used unity a lot.
[14:59] <ogra_> i did since day one
[14:59] <juliank> I think my laptops all ran Debian with GNOME during the unity time
[14:59] <juliank> *Debian unstable
[14:59] <ogra_> to have gnome close to it regarding my use cases i have to install a gazillion of extensions that eat so much ram that it isnt worth it anymore
[15:00] <juliank> I used GNOME 3 from before it was stable IIRC
[15:00] <ogra_> yeah, if you like the usability of it i guess you are fine
[15:01] <juliank> I think I started around 2.31 or so
[15:01] <ogra_> i cant really get along with a lot there
[15:01] <ginggs> ogra_: this is probably the wrong channel, but i herd you like unity :) I have 2 machines running still unity on 18.04, they suspend after 20 minutes if nobody is logged in, they didn't do this on 17.10.  any ideas?
[15:01] <juliank> ginggs: sounds like a bug was fixed? ;)
[15:01] <ogra_> ginggs, heh, no idea ... i'm actually sticking to 16.04 here
[15:01] <ogra_> but yeah perhaps -desktop would be the better channel
[15:02] <ogra_> (unless there is actually a unity dedicated channel somewhere)
[15:02] <juliank> ginggs: 20 mins is the default suspend time out for gnome-power-$thingy
[15:02] <juliank> Is that running?
[15:02] <juliank> for the greeter
[15:02] <ginggs> juliank: i can change that for a logged in user, but don't know how to change it for the greeter
[15:03] <juliank> oh, ok
[15:03] <juliank> you can
[15:03] <juliank> like sudo to the greeter user and change it there with gsettings tool
[15:03] <juliank> Although I think there are drop-in keyfiles too?
[15:03]  * juliank not sure
[15:04] <juliank> ginggs: are you using gdm?
[15:04] <ginggs> juliank: looks like lightdm
[15:04] <juliank> ok
[15:05] <juliank> but I guess the idea is the same
[15:05] <ginggs> juliank: thanks, i will try sudo to the greeter user
[15:05] <juliank> sudo to its user and run gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing'
[15:05] <juliank> though you might need to figure out its dbus socket
[15:21] <tjaalton> Mirv: intel-vaapi-driver could probably just be backported like mesa is, unrenamed
[15:22] <tjaalton> now that it's actually used almost by default
[15:25] <nacc> juliank: tjaalton: shouldn't LP: #1756549 just be duped to LP: #1756380 ?
[15:26] <nacc> and maybe LP: #1751492
[15:27] <tjaalton> 1751492 is probably a bug in mesa
[15:27] <juliank> nacc: one is about shader stuff, the other about a tiny bugfix
[15:27] <juliank> nacc: ah no
[15:27] <nacc> juliank: i think they are the same
[15:27] <nacc> this was the annoying user :)
[15:28] <juliank> nacc: tghe other is GPU hang
[15:28] <tjaalton> 1756549 not found
[15:28] <juliank> 1751492 => it works, but hangs the GPU
[15:28] <nacc> one sec
[15:28] <juliank> bug 1751492 => it works, but hangs the GPU
[15:29] <juliank> bug 1756380 => does not work, missing shaders
[15:30] <tjaalton> well, encoding needs the shaders, doubt he had those installed
[15:30] <nacc> tjaalton: also, supposedly this affects the core snap
[15:30] <nacc> sdupposedly
[15:30] <nacc> i'll ping the snap folks
[15:31] <juliank> nacc: it does not
[15:31] <juliank> that's just silly
[15:31] <nacc> juliank: ok, supposedly the vlc snap says it does
[15:31] <nacc> juliank: as in, it doesn't work ... but i don't know why the user said that
[15:31] <nacc> it's in a few of the bugs and that's what they've said on IRC a few times
[15:31] <juliank> nacc: it does not work, sure, but it's not in there core snap, they ship the driver from the deb
[15:32] <juliank> they install the driver deb into their snap
[15:32] <nacc> juliank: not sure how that would be broken, given it works on xenial?
[15:32] <nacc> juliank: unless they took a different deb?
[15:32] <nacc> again, just my understanding
[15:32] <juliank> who said it works on xenial?
[15:32] <nacc> juliank: that user, again
[15:33] <nacc> juliank: it was broken in 1.8.x
[15:33] <tjaalton> which bug# was that?
[15:33] <nacc> LP: #1756380 comment 1
[15:33] <juliank> it was broken in a kernel update >= 4.13
[15:34] <tjaalton> ah, so just trying to hijack a bug
[15:34] <juliank> nacc: he's also talking about a completely different bug :)
[15:34] <juliank> https://bugs.launchpad.net/ubuntu/+source/intel-vaapi-driver/+bug/1756459
[15:35] <juliank> nacc: if you read the backlog you'll see that I asked him to clarify that
[15:35] <nacc> juliank: ok, well, he duped the text, so i'm not sure how i'd know that :)
[15:35] <nacc> juliank: tjaalton: but as long as you two have a handle on it, i'll drop it
[15:36] <tjaalton> yeah I think it'll calm down now, at least for bionic..
[15:41] <nacc> tjaalton: thanks
[17:22] <tsimonq2> bdmurray: Could I please get a review on this so kdesudo can be removed? https://code.launchpad.net/~tsimonq2/ubuntu-release-upgrader/port-away-from-kdesudo/+merge/34155
[17:22] <tsimonq2> ugh
[17:22] <tsimonq2> https://code.launchpad.net/~tsimonq2/ubuntu-release-upgrader/port-away-from-kdesudo/+merge/341555
[17:22] <tsimonq2> that
[17:30] <bdmurray> tsimonq2: commented
[17:31] <tsimonq2> Thanks bdmurray.
[18:04] <Mirv> tjaalton: oh, right..
[18:49] <sunweaver> flexiondotorg: <others>: can you tell me what the status of notify-osd in Ubuntu is?
[18:49] <sunweaver> tsimonq2: ^
[18:49] <sunweaver> is it actively used in Ubuntu Desktop 18.04?
[18:50] <tsimonq2> sunweaver: seeded-in-ubuntu :)
[18:50] <sunweaver> ...means what?
[18:50] <tsimonq2> sunweaver: Otherwise, try #ubuntu-desktop
[18:50] <tsimonq2> sunweaver: It's a script
[18:50]  * sunweaver starts browsing the code...
[18:51] <sunweaver> tsimonq2: urgh, no... https://bazaar.launchpad.net/~indicator-applet-developers/notify-osd/trunk/files/head:/src/
[18:52] <Odd_Bloke> sunweaver: I believe seeded-in-ubuntu is the script, which will tell you what notify-osd's status is.
[18:52] <sunweaver> ah.
[18:52]  * sunweaver changes to his bionic chroot.
[18:53] <Odd_Bloke> (It's in ubuntu-dev-tools.)
[18:53]  * sunweaver was wondering exactly that...
[18:55] <tsimonq2> Right.
[18:55] <sunweaver> it is not seeded...
[18:55] <sunweaver> means, it is not used in the official set of packages, right?
[18:55]  * sunweaver is more wondering about... is it still maintained as an upstream project?
[18:56] <sunweaver> is it part of a Unity7 installation?
[18:58] <jbicha> sunweaver: yes (I find reverse-depends to be a more useful tool here)
[18:58] <jbicha> yes, it's installed by the Unity metapackage
[18:59] <sunweaver> jbicha: and XDG_CURRENT_DESKTOP is Unity7 right now, not Unity anymore?
[18:59] <jbicha> it's probably as well maintained as the rest of the Unity stack
[18:59] <sunweaver> ok.
[18:59] <sunweaver> I will update it in Debian then from bzr.
[19:00] <sunweaver> is there a #unity(7) channel here on Freenode?
[19:00] <jbicha> I don't have a recent Unity install to check XDG_CURRENT_DESKTOP for you
[19:00] <nacc> !alis | sunweaver
[19:01] <jbicha> sunweaver: I don't think so, you might just need to email the Unity 7 people
[19:01] <sunweaver> nacc: thanks.
[19:02] <sunweaver> which is this? unity7maintainers@lists.launchpad.net
[20:38] <TJ-> Do we have any policykit hackers? On 16.04 at least it looks like the /etc/polkit-1/localauthority.conf.d/ is being parsed in the wrong order, resulting in Ubuntu-shipped policy being replaced by package policy
[20:50] <xnox> TJ-, sigh, maybe try #ubuntu-hardened?
[20:57] <ahasenack> hi, is there any trick to build an autopkgtest image for ppc64el? I have shell on such a host, autopkgtest-buildvm-ubuntu-cloud finishes but I think it falied to run the setup scripts
[20:58] <ahasenack> https://pastebin.ubuntu.com/p/DVry2CPkjr/ bits of the --verbose output
[20:58] <ahasenack> where cloud-init starts to run the stuff sent via user-data
[20:58] <ahasenack> [   33.414880] cloud-init[1247]: sh: 0: Can't open /mnt/setup-testbed
[20:58] <ahasenack> that's the key error I think, that's supposed to be a script
[21:00] <nacc> ahasenack: you might even ask in #cloud-init, possibly
[21:00] <TJ-> xnox: will do... just writing up a bug report :)
[21:00] <nacc> ahasenack: i'm pretty sure i've done that on a ppc64el in the past, but it was a while ago
[21:01] <ahasenack> ok
[21:02] <ahasenack> at this stage I think the problem is bad assumptions made by the autopkgtest-buildvm-ubuntu-cloud script
[21:03] <ahasenack> not strictly a cloud-init problem
[21:03]  * ahasenack adds some debugging to that user-data
[21:07] <ahasenack> cpaelzer probably knows, I'll ask him tomorrow
[21:23] <ahasenack> nacc: hah, got it
[21:23] <ahasenack> nacc: for some reason, vda and vdb are swapped
[21:23] <ahasenack> vdb is the boot disk not vda
[21:23] <nacc> ahasenack: weird
[21:23] <ahasenack> the autopkgtest script assumed the non-boot disk would be vdb
[21:23] <ahasenack> runcmd:
[21:23] <ahasenack>  - sed -i 's/deb-systemd-invoke/true/' /var/lib/dpkg/info/cloud-init.prerm
[21:23] <ahasenack>  - mount -r /dev/vda /mnt
[21:23] <ahasenack> I changed that mount to vda (as displayed) and it's working now
[21:24] <ahasenack> it was vdb
[21:24] <ahasenack> now, other things failed :/
[21:24] <ahasenack> [   55.637935] cloud-init[1285]: E: Failed to fetch http://archive.ubuntu.com/ubuntu/dists/bionic/main/binary-ppc64el/Packages  404  Not Found [IP: 10.245.71.3 8000]
[21:24] <ahasenack> but baby steps
[21:25] <nacc> ahasenack: that seems like maybe it's trying to use an apt proxy?
[21:25] <ahasenack> yeah, but that url is indeed a 404
[21:25] <ahasenack> I tried from home just now
[21:26] <ahasenack> are ppc packages elsewhere? ports.u.c perhaps?
[21:26] <ahasenack> yep
[21:26] <ahasenack> :/
[21:26] <ahasenack> ahasenack@diamond:~⟫ cat /etc/apt/sources.list
[21:26] <ahasenack> deb http://ports.ubuntu.com//ubuntu-ports/ xenial main restricted universe multiverse
[21:26] <ahasenack> let's see
[21:26] <ahasenack> should be able to set a mirror
[21:26] <nacc> http://ports.ubuntu.com/ubuntu-ports/dists/bionic/main/binary-ppc64el/
[21:26] <nacc> ahasenack: yeah, but that's weird that it wasn't done correclty to start
[21:27] <nacc> ahasenack: -m option to buildvm-ubuntu-cloud
[21:27] <ahasenack> yep
[21:27] <ahasenack> am trying that now with your url
[21:27] <ahasenack> i.e., http://ports.ubuntu.com/ubuntu-ports
[21:27] <nacc> yeah
[21:27] <nacc> it's weird, i woudl think if it's arch specific like that, autopkgtest would know about it
[21:28] <nacc> that feels like a bug (to me)
[21:28] <ahasenack> why are some arches in ports.u.c?
[21:28] <ahasenack> i386/amd64 are on the same url
[21:29] <nacc> ahasenack: i don't know; perhaps slangasek can tell us?
[21:29] <slangasek> because the volume of downloads for !x86 arches does not justify distributing them from the primary mirror network
[21:31] <nacc> slangasek: good answer
[21:31] <ahasenack> [   48.513705] cloud-init[1290]: Fetched 3640 kB in 1s (3325 kB/s)
[21:31] <ahasenack> nacc: worked now
[21:31] <nacc> ahasenack: nice
[21:37] <ahasenack> nacc: still getting this though, when starting the actual test run
 failure: The VM does not start a root shell on ttyS1 already. The only other supported login mechanism is through --user and --password on the guest ttyS0
[21:38] <ahasenack> I'll ping cpaelzer tomorrow
[21:38] <nacc> ahasenack: yeah, i don't know what that means, or what is detecting that
[21:38] <ahasenack> I believe it's failing to find a way to login
[21:39] <ahasenack> setup-testbed might set that up somehow
[21:39] <ahasenack> anyway
[21:39] <ahasenack> that's a big shell script
[21:39] <nacc> ahasenack: yeah is that still not running?
[21:39] <ahasenack> no, it fails somewhat quickly
[21:40] <ahasenack> I can try to bring a vm up on that image myself
[21:40] <ahasenack> hah
[21:40] <ahasenack> from the setup script
[21:40] <ahasenack> # set up init script for root shell on ttyS1; necessary for autopkgtest-virt-qemu local
[21:40] <ahasenack> # images
[21:40] <ahasenack> and then it sets up a sysv initscript
[21:41] <ahasenack> looks like I can't resist it
[21:41]  * ahasenack debugs some more
[21:41] <nacc> ahasenack: :)
[22:04] <tsimonq2> bdmurray: Am I missing something or has DistUpgrade/DistUpgradeFetcherKDE.py already been fixed? https://code.launchpad.net/~tsimonq2/ubuntu-release-upgrader/port-away-from-kdesudo/+merge/341555
[22:09] <bdmurray> tsimonq2: I believe you are missing something - https://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu-release-upgrader/trunk/view/head:/DistUpgrade/DistUpgradeFetcherKDE.py#L134
[22:11] <tsimonq2> bdmurray: Are you sure we're looking at the same thing? That says pkexec.
[22:11] <tsimonq2> On my branch it does, at least.
[22:13] <bdmurray> Hmm well okay great. I must have missed that.
[22:13] <tsimonq2> Cool. :)
[22:13] <tsimonq2> Otherwise it looks good?
[22:15] <bdmurray> Yes
[22:16] <tsimonq2> Excellent.
[22:29] <tsimonq2> bdmurray: Sorry if I'm just being impatient but I need a merge + upload. :)