[01:09] <a1fa> andyrock: +1 nice!
[02:30] <Trevinho> pitti: patch updated again.
[04:53] <hikiko> hi
[06:06] <pitti> Good morning
[06:16] <seb128> good morning desktopers!
[06:19] <pitti> bonjour seb128 !
[06:20] <seb128> hey pitti, happy friday!
[06:20] <seb128> how are you?
[06:20] <pitti> and to you! I'm fine, thanks, how about yourself?
[06:20] <pitti> whoa, where did all my armhf boxes go
[06:21] <seb128> I'm good thanks ;-)
[06:44] <seb128> happyaron, hey!
[06:44] <happyaron> seb128: hi
[06:44] <seb128> happyaron, how are you? happy friday!
[06:45] <happyaron> great, :)
[06:48] <seb128> happyaron, how are those nm updates going? ;-)
[06:49] <happyaron> met a problem on rebasing the policy patches to nm 1.2.2, still working on that
[06:50] <seb128> k
[06:50] <seb128> maybe it would make sense to do the -gnome update first?
[06:50] <seb128> it fixes some issues and should be more trivial
[06:50] <happyaron> yep I meant the applet package
[06:50] <seb128> oh well, we are not going to SRU things on friday and it's almost w.e time for you
[06:51] <seb128> oh, right, stupid me, 1.2.2 was already uploaded to y- :p
[06:51] <happyaron> already done the merge with nm itself
[06:51] <happyaron> :)
[06:51] <seb128> yeah
[06:51] <seb128> I'm not fully awake yet it seems ;-)
[06:51] <happyaron> haha
[06:51] <seb128> happyaron, k, let me know if you need help with something
[06:54] <happyaron> ty
[07:26] <seb128> time for a coffee break, bbiab
[08:01] <Laney> morning
[08:01] <Laney> it's fririririrday
[08:07] <willcooke> morning
[08:08] <willcooke> appstreamcli is using 100% CPU this morning
[08:08] <davmor2> Morning willcooke
[08:10] <seb128> hey Laney, willcooke
[08:11] <seb128> happy friday!
[08:11] <seb128> how are you?
[08:11] <willcooke> \o/
[08:11] <willcooke> Ready for a weekend
[08:11] <seb128> willcooke, do you use it manually? or are we spawning that command in bg?
[08:11] <willcooke> seb128, must be running it in the bg
[08:11] <seb128> hum, k
[08:12] <willcooke> I killed it, but...
[08:13] <willcooke> ay 20 09:10:50 malfunctioning-eddie sudo: pam_ecryptfs: pam_sm_authenticate: /home/will is already mounted
[08:13] <willcooke> May 20 09:10:50 malfunctioning-eddie org.debian.apt[955]: Terminated
[08:13] <willcooke> May 20 09:10:50 malfunctioning-eddie gnome-session[1981]: (gnome-software:2122): Gs-WARNING **: failed to call gs_plugin_refresh on apt: apt transaction returned result exit-failed
[08:13] <willcooke> May 20 09:10:50 malfunctioning-eddie AptDaemon.Worker: INFO: Finished transaction /org/debian/apt/transaction/09c0faa447d24743841046c745027e17
[08:13] <willcooke> May 20 09:10:50 malfunctioning-eddie org.debian.apt[955]: 09:10:50 AptDaemon.Worker [INFO]: Finished transaction /org/debian/apt/transaction/09c0faa447d24743841046c745027e17
[08:13] <willcooke> May 20 09:10:50 malfunctioning-eddie gnome-session[1981]: (gnome-software:2122): Gs-WARNING **: failed to get updates: no results to show
[08:16] <willcooke> smells like this:  https://bugs.launchpad.net/ubuntu/+source/appstream/+bug/1583845
[08:16] <willcooke> so might have been my internet connection crapping out for a moment
[08:16] <willcooke> correction, this:  https://bugs.launchpad.net/ubuntu/+source/appstream/+bug/1579712
[08:17] <willcooke> which is fixed
[08:17] <willcooke> in proposed
[08:17] <andyrock> morning all
[08:17] <willcooke> hey andyrock
[08:19] <seb128> hey andyrock, happy friday!
[08:20] <seb128> willcooke, if you can reproduce you might want to verify the SRU ;-)
[08:20] <andyrock> seb128: hehe :D
[08:23] <Laney> hey seb128 & willcooke & andyrock
[08:23] <seb128> willcooke, though it seems that bug got enough users verifying it
[08:23] <willcooke> seb128, I think so.  Just trying to recreate it now
[08:24]  * willcooke eyes the dropbox repo
[08:25] <willcooke> hrm, not that
[08:25] <willcooke> ah, backports
[08:25] <willcooke> strange
[08:26] <seb128> that's what others say on the bug as well
[08:26] <willcooke> yeah, just seen that
[08:26] <seb128> I wonder if something changed
[08:26] <seb128> because it's several people who have issues with backports today
[08:26] <willcooke> this could be an issue for upgrading then
[08:27] <seb128> does it block the apt index refresh for ever?.
[08:27] <seb128> in which case it indeed a problem
[08:27] <willcooke> seb128, running it manually now, let's see...
[08:28] <willcooke> sudo appstreamcli refresh --verbose --details --force
[08:28] <willcooke> ** (appstreamcli:5082): DEBUG: Refreshing AppStream cache
[08:28] <willcooke> ** (appstreamcli:5082): DEBUG: Reading: /usr/share/app-info/xmls/org.freedesktop.fwupd.xml
[08:28] <willcooke> ** (appstreamcli:5082): DEBUG: Reading: /var/lib/app-info/yaml/gb.archive.ubuntu.com_ubuntu_dists_xenial-backports_main_dep11_Components-amd64.yml.gz
[08:28] <willcooke> ** (appstreamcli:5082): DEBUG: Reading: /var/lib/app-info/yaml/gb.archive.ubuntu.com_ubuntu_dists_xenial-backports_restricted_dep11_Components-amd64.yml.gz
[08:28] <Laney> debugging a fixed bug?
[08:28] <willcooke> Laney, issue is that I wont get the fix because appstream cli hangs forever(?)
[08:28] <seb128> Laney, no, trying to reproduce to verify the SRU fix
[08:28] <seb128> Laney, also wondering how we get the fix to users if the bug prevent them to get updates
[08:29] <Laney> release it
[08:29] <seb128> well, still
[08:29] <seb128> if they can't apt-get update
[08:29] <seb128> their apt is never going to list the update
[08:29] <seb128> no?
[08:29] <seb128> so they are never going to see/be able to get it
[08:29] <Laney> you prevent updaters from getting it
[08:30] <seb128> you mean?
[08:31] <seb128> well, if people running release can't refresh their package index due to it, how do they get the fix?
[08:31] <Laney> If you release it then nobody new will get the bug
[08:31] <Laney> Don't knwo
[08:31] <seb128> I was wondering if there is a specific issue with backports that triggers the bug
[08:31] <Laney> I doubt it
[08:31] <Laney> they are empty of appstream
[08:32] <seb128> k, just seemed a weird coincidence that several people mention backports as being an issue today
[08:32] <Laney> Maybe it's an interaction with something else
[08:32] <seb128> like there are some on the bugs, willcooke and jtaylor on #ubuntu-devel
[08:32] <Laney> It doesn't mean it's backports itself
[08:33] <seb128> but yeah, the SRU is 7 days old and verified
[08:33] <seb128> need SRU team to copy it over
[08:33] <Laney> Someone who has the bug could find out why
[08:33] <Laney> and then we might be able to manipulate the appstream data somehow
[08:33] <Laney> Otherwise, if it just started today, get the SRU out there
[08:33] <seb128> well those comments on the bug suggest that disabling backport "fixes" it
[08:34] <seb128> pitti, ^ can you get the xenial appstream SRU copied over to updates?
[08:34] <Laney> That doesn't help for an apt update
[08:34] <pitti> seb128: can do; I'm normally not doing SRU releases on Friday, but if that's safe, sure
[08:34] <seb128> pitti, well see backlog
[08:34] <seb128> pitti, we are concerned that the bug hits more users and block them to get updates
[08:34] <pitti> bug 1574896 isn't verified yet
[08:35] <seb128> including the fix
[08:35] <pitti> but I suppose that's ok -- most importantly it shouldn't regress
[08:35] <Laney> looks v-done to me
[08:36] <Laney> but very recently so maybe the report didn't refresh
[08:37] <pitti> right
[08:37] <pitti> released
[08:37] <seb128> pitti, tahnks
[08:37] <Laney> merci
[08:38] <seb128> Laney, I don't understand your " That doesn't help for an apt update" comment
[08:38] <seb128> btw I can confirm here
[08:38] <Laney> You can't make 'update' disable backports
[08:39] <seb128> right, that's not what I meant
[08:39] <seb128> just that backport creates the issue
[08:39] <seb128> confirmed here, enabling backport and I can't finish an apt-get update now
[08:39] <seb128> :-/
[08:39] <seb128> disabling and it's good again
[08:40] <Laney> https://paste.ubuntu.com/16517854/
[08:40] <Laney> backports is empty
[08:41] <seb128> maybe that's what confuses it?
[08:41] <Laney> It's always been empty
[08:41] <seb128> in which case unsure why it started today :-/
[08:41] <Laney> That's what I'm asking to find out :-)
[08:42] <Laney> main was published yesterday so maybe that did something
[08:42] <seb128> unsure how to debug that, but you probably can if you want, just enable backport with the xenial version and try to refresh apt :p
[08:42] <Laney> I have that enabled and it works :(
[08:42] <seb128> you don't have the SRU version?
[08:43] <Laney> 0.9.4-1
[08:43] <seb128> :-(
[08:43] <Laney> mirror is still refreshing
[08:43] <Laney> maybe when that finishes it starts
[08:44] <willcooke> ahh, Laney has a local mirror
[08:44] <seb128> that's cheating :p
[08:44] <Laney> otherwise go gdb for you
[08:44] <seb128> disable your mirror and see if you get it?
[08:44] <seb128> I'm happy to help debugging
[08:44] <seb128> but I've no knowledge of the codebase/project
[08:44] <Laney> could get a trace though
[08:44] <seb128> so learning curve is going to take some time
[08:45] <seb128> yeah, that's easy
[08:45] <seb128> let me do it
[08:48] <willcooke> is this anything?  http://paste.ubuntu.com/16517887/
[08:48]  * willcooke is trying to work gdb 
[08:48] <willcooke> although this is probably just debugging the fixed bug
[08:49] <Laney> might be able to stop it happening for everyone
[08:50] <seb128> willcooke, install libappstream3-dbgsym for bonus points
[08:52] <seb128> #1  0xb732d998 in as_yamldata_parse_distro_data (ydt=0x9c72290 [AsYAMLData], data=0x9c73f88 "---\nFile: DEP-11\nMediaBaseUrl: http://162.213.33.131/media/restricted\nOrigin: ubuntu-xenial-backports-restricted\nVersion: '0.8'\n\210", error=0xbfef1544) at /build/appstream-XJqxY1/appstream-0.9.4/src/as-yamldata.c:1861
[08:52] <seb128> seems to stuck there
[08:53] <Laney> I know how to fix it
[08:53] <seb128> \o/
[08:53] <Laney> edit that file and add "Priority: 40" at the bottom
[08:53] <Laney> see if it fixes it for you
[08:54] <seb128> let me try that
[08:54] <Laney> have to do it for all the backports ones
[09:00] <seb128> Laney, yeah, that works
[09:01] <seb128> did those files change recently/in which way?
[09:01] <Laney> backpots/main got a backport
[09:01] <Laney> which made the file regenerate with a Priority value
[09:02] <Laney> I guess that tickles the bug
[09:02] <Laney> waiting for the current run to finish then will make it regenerate for the other components
[09:37] <seb128> happyaron, do you have a 3g stick or some hardware to have a look to that n-m applet/3g icon issue?
[09:38] <willcooke> if you don't please get one and expense it
[09:39] <willcooke> they're not expensive
[09:41] <seb128> oem team seems to be very eager to see that one moving
[09:41] <seb128> Dell seems to wait on it
[09:41] <seb128> happyaron, that should probably be higher importance that the version updates
[09:42] <seb128> or maybe we can get cyphermox to have a look today
[09:42] <seb128> I'm pretty sure he has hardware for it
[09:44] <seb128> shrug, and of course bugzilla.gnome.org is down when I want to upstream it
[09:46] <willcooke> heh
[09:48] <davmor2> willcooke, seb128: I noticed that my laptop was spinning up still after a hangout and not calming down turns out appstreamcli is running and using 100%cpu
[09:49] <willcooke> davmor2, indeed.  known issue.  Fix in the works
[09:49] <seb128> davmor2, see channel backlog
[09:50] <seb128> ok, since bugzilla is down and I'm done with what I was looking at let's do early lunch and continue with other things after that
[09:50] <seb128> bbiab
[09:50] <davmor2> willcooke, seb128: ah awesome was busy in a meeting so hadn't kept an eye in here :)
[09:50] <willcooke> l8r seb128
[09:50] <willcooke> davmor2, nw
[09:54] <Laney> ok appstream.ubuntu.com is updated
[09:54] <Laney> the archive should get it soon
[09:54] <Laney> hmm, or will it
[10:04] <pitti> Laney: would that affect installs of xenial-release too?
[10:05] <Laney> yes they have backports by default
[10:05] <pitti> Laney: I'm currently tryigng to install it into a VM (final image) and it hangs on apt-get update
[10:05] <Laney> talking in #launchpad about a republish
[10:05] <pitti> ah, ok
[10:05] <happyaron> seb128: no I don't have
[10:12] <willcooke> happyaron, please get one, I think it will be useful
[10:12] <willcooke> just expense it
[10:13] <willcooke> I picked up a ZTE MF112 on ebay for < 10 GBP
[10:15] <happyaron> willcooke: will do, ty
[10:38] <tjaalton> willcooke: hi, is there someone assigned to work on bug 1417980?
[10:38]  * willcooke reads
[10:39] <willcooke> ah, lib input
[10:39] <willcooke> tjaalton, noone assigned yet, but it's on our list:  https://trello.com/c/4F2urkpx
[10:40] <tjaalton> willcooke: ok cool, I'm not on trello but good to know :)
[11:02] <Laney> archive should be fixed now
[11:07] <willcooke> thanks Laney!
[11:08] <willcooke> davmor2, and we are fixed! ^
[11:13] <davmor2> willcooke: we are indeed
[11:24] <seb128> Laney, good job!
[11:27] <Laney> blop
[11:31] <seb128> tjaalton, do we need that to happen? it's on our list but I doubt we are going to get to it this cycle
[11:32] <seb128> well we might
[11:32] <seb128> but we have quite some backlog and resources for y "feature" work is limited
[11:32] <seb128> it's likely going after packagekit 1 and gnome-software improvement and snap work
[11:32] <davmor2> Laney: what caused the issue in the end and is there a safeguard we can put in place to prevent it happening again?
[11:33] <seb128> which means I wouldn't count on it
[11:33] <Laney> the bug is fixed
[11:34] <seb128> davmor2, I'm unsure appstream has a testsuit/an easy way to create and feed him the config that created the bug to make sure that's not coming back in a futur version, if that's what you ask
[11:35] <davmor2> seb128: right okay so we could randomly have this happen any time a new package it uploaded then
[11:36] <seb128> well usually fixed bugs don't reappear
[11:36] <Laney> The same way you could randomly have a bug in anything
[11:36] <seb128> but I guess it's a possibility that some future change lead to new bugs
[11:36] <Laney> This particular bug is fixed
[11:36] <tjaalton> seb128: ok, kde & gnome will have it in y
[11:36] <seb128> tjaalton, good for them
[11:36] <tjaalton> gnome needs to depend on the driver
[11:36] <seb128> they can deal with the early adopter bugs
[11:36] <Laney> If you want to contribute a testsuite I'm sure ximion wouldn't say no
[11:36] <tjaalton> they dropped the old stuff
[11:37] <tjaalton> debian switched already :)
[11:37] <seb128> tjaalton, wasn't that already the case in xenial?
[11:37] <tjaalton> no
[11:37] <tjaalton> 3.20
[11:37] <davmor2> seb128, Laney: ah sorry I thought it was just a broken app profile that broke it
[11:37] <seb128> I though GNOME had dropped !libinput a while ago
[11:37] <Laney> no
[11:37] <tjaalton> xenial has 3.18 still
[11:38] <seb128> tjaalton, ah, they added libinput support a way back but kept the old thing as well, just dropped that in 3.20
[11:38] <seb128> I see
[11:38] <tjaalton> yeah
[11:38] <seb128> thanks for the head up
[11:38] <seb128> if you want to work on the u-c-c fixes that would be welcome
[11:39] <seb128> but if you are too busy then back to what I said before
[11:39] <seb128> it's on the list but low enough that I'm unsure we are going to get to it this cycle
[11:39] <tjaalton> some of it is in mutter now
[11:39] <tjaalton> aiui
[11:39] <seb128> yeah, I expect for us it's going to be u-c-c/u-s-d only
[11:39] <seb128> I hope at least that there are no compiz changes needed
[11:40] <tjaalton> right
[11:42] <Laney> tjaalton: the desktop team is hiring ;-)
[11:42] <Laney> this is my new troll version of patches welcome
[11:42] <tjaalton> Laney: hehe :)
[11:43] <seb128> :-)
[11:44] <tjaalton> is there any syncing done to u-c-c/u-s-d from upstream=
[11:44] <tjaalton> ?
[11:45] <seb128> no
[11:45] <tjaalton> yeah input config is all in mutter now, so it's not easy to port
[11:45] <seb128> well nothing regular/organized
[11:45] <tjaalton> ok
[11:45] <tjaalton> not that it would help here anyway
[11:46] <seb128> we do cherrypick changeset and backport fixes
[11:46] <seb128> in principle those changes shouldn't be too difficult right?
[11:46] <seb128> change some X calls by others
[11:47] <tjaalton> maybe
[12:13] <Trevinho> Laney: hey, could you publish https://requests.ci-train.ubuntu.com/#/ticket/1419 ?
[12:13] <Trevinho> It was blocked by the fact that unity is not built on the s390x again, but I think we need to whitelist this case again for yakkety (who can do that?)
[12:29] <seb128> Trevinho, why is usd still in there?
[12:30] <seb128> Laney, pitti, tedg, https://mail.gnome.org/archives/desktop-devel-list/2016-May/msg00005.html ... good timing ;-)
[12:44] <Trevinho> seb128: is listed, but not in the ppa
[12:45] <Trevinho> seb128: I did remove that from the list, but there are no packages to land
[12:45] <seb128> I think the silo needs to be reconfigured
[12:45] <seb128> you are going to hit an error on publishing
[12:45] <seb128> it still thinks usd is part of it
[12:45] <Trevinho> seb128: I've made a build, but nothing changed and sil2100 told us that there was nothing else to do
[12:45] <Trevinho> let me try to remove it again
[12:46] <seb128> well, maybe it's going to work
[12:46] <seb128> but it looks wrong
[12:47] <Trevinho> seb128: let's see if it works, in case it won't I try to rebuild the whole thing
[12:47] <Trevinho> seb128: you can publish too?
[12:47] <seb128> Trevinho, yeah, but unsure about the s390x issue
[12:47] <seb128> what is that?
[12:47] <Trevinho> seb128: basically unity never built in that arch, because the nux tests aren't passing in that arch
[12:48] <Trevinho> when it comes to use X to do some headless tests
[12:48] <seb128> but https://launchpad.net/ubuntu/+source/unity/7.4.0+16.04.20160415-0ubuntu1 has s390x build/binaries?
[12:48] <seb128> https://launchpad.net/ubuntu/+source/unity/7.4.0+16.04.20160415-0ubuntu1/+build/9586999
[12:48] <Trevinho> so, we could maybe try to disable the tests there, but really thre's no need for unity there...
[12:49] <pitti> seb128: heh yes, I saw that the other day
[12:51] <seb128> Trevinho, https://launchpad.net/ubuntu/+source/nux/4.0.8+16.04.20160209-0ubuntu2
[12:51] <Trevinho> seb128: mh, i see these artifacts http://pastebin.ubuntu.com/16520312/
[12:51] <seb128> Trevinho, when doing what?
[12:51] <seb128> that seems a shotwell issue?
[12:52] <Trevinho> seb128: that's in the brightray excuses
[12:52] <seb128> britney?
[12:52] <Trevinho> seb128: https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-yakkety-ci-train-ppa-service-landing-028/yakkety/s390x/s/shotwell/20160519_160941@/artifacts.tar.gz
[12:52] <Trevinho> yeah, sorry :-D
[12:52] <Trevinho> brightray is something electron related :-D
[12:53] <seb128> where is the britney page for that silo?
[12:53] <Trevinho> seb128: https://requests.ci-train.ubuntu.com/static/britney/yakkety/landing-028/excuses.html
[12:58] <seb128> Trevinho, "s390x: Always failed" so that's not a blocker
[12:59] <seb128> the issue is that you failed to build on s390x
[12:59] <seb128> Trevinho, " Missing build dependencies: libupstart-dev "
[12:59] <Trevinho> seb128: I know, but still I'm getting "red ci-train" which isn't nice :-)
[12:59] <seb128> on https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-028/+build/9756725
[13:00] <seb128> somebody retried upstart on https://launchpad.net/ubuntu/+source/upstart/1.13.2-0ubuntu24
[13:00] <seb128> oh, no, that seems stalled
[13:01] <Trevinho> seb128: oh, actually the error on s390x is different from the one I had in the past: "Missing build dependencies: libupstart-dev"
[13:01] <Trevinho> so it's another thing
[13:01] <seb128> Trevinho, read what I just said
[13:01] <seb128> :p
[13:02] <seb128> see -devel
[13:03] <seb128> Trevinho, seems like you are blocked on xnox/slangasek to fix upstart build on s390x :-/
[13:03] <Trevinho> seb128: yeah, sorry...
[13:04] <Trevinho> in the mean time I noticed that there has been another direct push to nux, without ci-train :-/
[13:05] <seb128> doko, of course
[13:05] <seb128> feel free to tell him off on #ubuntu-devel
[13:06] <Trevinho> seb128: yeah... But sil2100 fixed it in the branch... Same happened for compiz in yakkety. I really would lvoe to be notified before doing this.
[13:06] <Trevinho> ... at least.
[13:06] <seb128> tell them
[13:07] <seb128> maybe if we tell them enough it's going to stick at some point
[13:21] <Laney> um
[13:21] <Laney> so don't do anything then
[13:21] <Laney> works for me!
[13:24] <Laney> just got our poll cards for the referendum
[13:24] <Laney> shit got real
[13:25]  * willcooke is worried by how many brexit people he sees on facebook
[13:25] <Laney> it's because that campaign has a stupid name
[13:25] <Laney> which is catchy
[13:25] <Laney> unlike bremain
[13:27] <seb128> Trevinho, speaking about landing, what's the status of landing the bamf menu fix for xenial?
[13:28] <Trevinho> seb128: I always waited things to go into devel before preparing SRUs... At least that was the policy I was thought, but I can basically prepare the same silo for X right nwo
[13:28] <Trevinho> now*
[13:28] <Trevinho> (almost the same)
[13:28] <seb128> it's the policy yes
[13:28] <seb128> but it's ready for y
[13:28] <seb128> it's just blocked by upstart on s390x
[13:29] <seb128> I think we can talk the SRU team into taking the xenial upload
[13:29] <seb128> though probably not today
[13:29] <seb128> they don't like friday uploads
[13:29] <seb128> monday is fine
[13:30] <Laney> they don't release to updates on friday
[13:30] <Laney> proposed is ok
[13:30] <Laney> afaik
[13:30] <seb128> k
[13:30] <seb128> some SRU team members are a bit conservative with that as well I think
[13:30] <seb128> but anyway we can get it in the queue
[13:30] <seb128> when they review it is their business then ;-)
[13:31] <seb128> Trevinho, also we need to deal better with important issues, that missing menus one should have been more prioritized and probably got its own silo, it doesn't make sense to block it on unity things to get fixed...
[13:31] <seb128> like we could have landed bamf to fix menus in y and x
[13:32] <seb128> it's a much easier thing to land than compiz+unity
[13:33] <Trevinho> seb128: I agree, it's just that the "fix" is probably not complete... And also I got some emails about not using tooo many silos (I had three around, because of trusty SRUs sitting there for months... And really I don't like bothering people about clearing the queue)
[13:33] <Trevinho> basically I did this: silos with 1,2 sru fixes... but this is not liked.
[13:34] <seb128> don't bother about that
[13:34] <seb128> the infra is there to be used
[13:34] <seb128> if they don't want silo to be stucked they can nag SRU team for reviews
[13:34] <seb128> I agree we shouldn't abuse silos
[13:35] <Trevinho> seb128: I'd like to know what's the best way to ping SRU team for reviewing a ci-train branch. Because it seems they don't get properly notified by sync queu elemenents
[13:35] <seb128> but fixing menus of LTS users is for sure justify using some CI resources
[13:35] <Trevinho> and they tend to stay there forever
[13:35] <seb128> they do
[13:35] <seb128> it's just that the diff are not generated by the queue
[13:35] <seb128> so they need to go back to ppa, fetch the package, etc
[13:36] <seb128> more manually work
[13:36] <seb128> pitti, ^ right?
[13:36] <seb128> Trevinho, also we don't need to use CI train to land, we can manually upload and merge
[13:36] <seb128> in fact I did bypass the train for the u-c-c/u-s-d SRUs I did to xenial
[13:37] <seb128> too much annoyance to use it
[13:37] <Trevinho> seb128: eh, yeah... you can. But I don't have the powers
[13:38] <Trevinho> seb128: I would like to use the silo to build, then get someone who can just upload those
[13:38] <seb128> why do you need the silo to build?
[13:38] <seb128> well it's going to have a test build/ppa
[13:38] <seb128> but yeah, we can force merge then and manually dput
[13:39] <seb128> Trevinho, you should apply for a ppu for the unity stack so you could dput ;-)
[13:40] <Trevinho> seb128: Ok, let me see... That isn't included if I apply for ~ubuntu-desktop, right?
[13:42] <seb128> Trevinho,
[13:42] <seb128> ubuntu-archive-tools/edit-acl query -s unity -S xenial
[13:42] <seb128> == All uploaders for package 'unity' ==
[13:42] <seb128> Archive Upload Rights for ubuntu-desktop: archive 'primary', package set 'ubuntu-desktop' in xenial
[13:42] <seb128> Archive Upload Rights for ubuntu-core-dev: archive 'primary', component 'main' in xenial
[13:42] <seb128>  
[13:42] <seb128> Trevinho, it is in desktop set
[13:49] <seb128> tjaalton, do you know how to tell if libinput is enable?
[13:50] <seb128> tjaalton, I'm trying to use the libinput tests and I get "../../src/check_msg.c:80: No messaging setup" errors, unsure why
[14:00] <Trevinho> seb128: that means that if you can get me in, I don't need the ppu, right?
[14:00] <seb128> Trevinho, yes, let's see next week
[14:01] <Trevinho> ok
[14:02] <Laney> Still think that you could become a lander for unity/compiz/bamf just by talking to sil2100
[14:02] <Trevinho> sil2100: ^, make me a lander :-)
[14:02] <seb128> Laney, he can, but we were just saying that we want to not use the train forSRUs maybe
[14:03] <Trevinho> So i can freely break the desktop experience of everyone without having Laney to be my evil accomplice :-D
[14:03] <Trevinho> (without know it)
[14:04] <Laney> k
[14:16] <tjaalton> seb128: the x driver? from the xorg log
[14:17] <tjaalton> and basically just installing it means that it's used for mice/touchpads/touchscreens
[14:18] <seb128> k, any idea why the tests give me that error?
[14:20] <cyphermox> seb128: get me to look at what?
[14:20] <seb128> cyphermox, hey
[14:20] <seb128> cyphermox, bug #1571574
[14:20] <seb128> oem is nervous about it
[14:21] <seb128> and nobody in our team seems to currently have hardware
[14:22] <cyphermox> oh right
[14:23] <cyphermox> yeah, I suppose that might be broken, lemme try it here real quick
[14:25] <cyphermox> indeed, it's broke
[14:26] <seb128> cyphermox, any chance you could try to have a poke to it today?
[14:26] <cyphermox> that's what I'm doing now, I think I know exactly what's wrong
[14:26] <seb128> or do you know if I can easily emulate a 3g connection using dbusmock?
[14:26] <seb128> great
[14:26] <seb128> cyphermox, beer+=3
[14:26] <seb128> :-)
[14:26] <cyphermox> 3?
[14:27] <cyphermox> is that adjusted to drinker size? ;)
[14:27] <Laney> one drink per g
[14:29] <cyphermox> can we go with one mL per g instead?
[14:29] <Laney> but you're only fixing 3G
[14:29] <Laney> go for LTE then you can have a little bit more
[14:30] <cyphermox> it will fix LTE too
[14:30] <Laney> 4 drinks!
[14:30] <cyphermox> eep
[14:30] <cyphermox> OH
[14:30] <cyphermox> *those* Gs.
[14:31] <Laney> haha
[14:31] <cyphermox> I thought you meant the Gs that usually follow ks. :)
[14:32] <Laney> KO follows too many Gs of C2H5OH
[14:32] <cyphermox> looks like I had already spent some of this limited brainpower on my internet issues this morning
[14:32] <cyphermox> Laney: indeed
[14:33] <cyphermox> that applies to most C**OHs anyway.
[14:34] <tjaalton> seb128: no idea
[14:34] <Laney> some funky stuff in there
[14:34] <seb128> tjaalton, no worry, thanks
[14:35] <cyphermox> yeah. for instance C12H22O11 gets you diabetes, which will get you KO too
[14:43] <cyphermox> seb128: ok, fixed it; I'll build to see but it's stuff that was missing upstream from their merge of my indicator patch
[14:43] <seb128> cyphermox, \o/
[14:43] <seb128> cyphermox, going to make oem happy, thanks a lot!
[14:51] <pitti> seb128: silo SRU review> right, takes a bunch of clicks to see the real diff, otherwise the mechanism is the same
[14:54] <cyphermox> seb128: I raise you https://bugs.launchpad.net/ubuntu/+source/network-manager/+bug/1583075
[14:54] <seb128> pitti, k, what I though
[14:55] <cyphermox> was just brought up to me by a friend, it looks like p12 is already in the extensions but something else may be amiss
[14:55] <seb128> cyphermox, https://bugs.launchpad.net/ubuntu/+source/network-manager-applet/+bug/1575614
[14:55] <seb128> cyphermox, backport https://git.gnome.org/browse/network-manager-applet/commit/?h=nma-1-2&id=037c5721d89b20c46ecc53e05d9867fd4d969412 with your fix
[14:55] <seb128> happyaron is looking at updating to 1.2.2 and I asked him to backport that
[14:56] <seb128> but we might want to do an upload with your fix + that
[15:06] <cyphermox> seb128: ok, 3g signal thing fixed although the icons we ship look like wifi, but that's not new.
[15:07] <seb128> cyphermox, \o/
[15:07] <seb128> cyphermox, want to maybe upload to y? we can handle SRU next week
[15:08] <cyphermox> yeah, I'll upload in a moment, just doing the p12 fix now
[15:15] <seb128> cyphermox, you saw the commit I pointed?
[15:16] <seb128> cyphermox, just checking if you "doing" means backporting or redoing :-)
[15:17] <cyphermox> backporting
[15:17] <cyphermox> I don't write code if I can avoid it ;)
[15:19] <ximion> Laney: looks like the strup issue in appstreamcli became a big hit overnight :P
[15:19] <ximion> not sure which cosmic fluke was responsible for users seeing it now, but fortunately the update is out now
[15:20] <seb128> tjaalton, just for the record my issue was permissions, need to use sudo
[15:20] <seb128> ximion, see channel backlog from earlier today if you want some details
[15:21] <seb128> but seems it was triggered by an update being published to backports
[15:21] <Laney> fun one
[15:21] <ximion> seb128: is the backlog stored somewhere?
[15:21] <Laney> ximion: you get your "broke ubuntu" badge :P
[15:21]  * ximion wasn't in the channel earlier
[15:22] <ximion> Laney: I would also need to get a "fixed Ubuntu before he broke it" badge ^^
[15:22] <seb128> ximion, http://irclogs.ubuntu.com/2016/05/20/%23ubuntu-desktop.html#t08:53
[15:22] <seb128> though I guess the discussion doesn't have much details on what Laney did
[15:23] <ximion> Laney: the priority value triggered it? Weird!
[15:24] <ximion> previously, no user experienced this bug, and it was in the code for a long time and run by users at Debian ^^
[15:24] <cyphermox> seb128: fyi: https://mail.gnome.org/archives/networkmanager-list/2016-May/msg00066.html
[15:25] <seb128> cyphermox, https://bugzilla.gnome.org/show_bug.cgi?id=766709 btw
[15:25] <seb128> I had it forward
[15:25] <seb128> sorry I didn't mention, but the launchpad bug had the bug watch
[15:25] <cyphermox> ah, sorry
[15:25] <seb128> cyphermox, thanks :-)
[15:25] <cyphermox> I'm updating the bug
[15:26] <seb128> thanks
[15:28] <ximion> seb128: thanks!
[15:28] <ximion> btw, we have an unittest for this bug upstream for a while now :-)
[15:28] <seb128> davmor2, ^
[15:30] <davmor2> seb128: oh nice
[15:32] <ximion> Laney: maybe important to know: this bug can *still* be triggered, even with the patch, if you feed appstream malformed YAML
[15:32] <ximion> we resolved this upstream too, and Yakkety should be completely safe
[15:33] <Laney> sounds like a good one to backport
[15:33] <ximion> since there usually is no broken YAML, triggering this bug should not happen though (you need to be root to install busted YAML)
[15:34] <ximion> yes, might still be useful to have
[15:34] <Laney> generator bug or third party repo
[15:34] <ximion> background is that the YAML parser wasn't checked correctly for errors which occur due to malformed YAML files, which sends appstreamcli into an infinite loop
[15:35] <ximion> jap
[15:35] <Laney> the apt hooks are a bad place to have a program hanging
[15:35]  * ximion agrees
[15:35] <Laney> since the repository can't give you a package to get you out
[15:35] <ximion> oh, it can - but only if you don't refresh the cache before attempting to upgrade :P
[15:36] <Laney> ._.
[15:36] <ximion> https://github.com/ximion/appstream/commit/f5a2f4da6e1bdce89124858d672e9ddea051b172 is the thing
[15:37] <ximion> it grew a bit bigger, because I wanted to fix other things too
[15:38] <ximion> when that other bug in appstream-glib is fixed, there should be no way to bring AppStream down anymore
[15:54] <ximion> PK >> 1.0 in Yakkety, nice :-)
[15:55] <seb128> not quite yet
[15:55] <seb128> it's in proposed like it was previous cycle
[15:56] <seb128> let's see if doko deals with aptdaemon and the other things in breaks
[16:01] <ximion> seb128: IMHO it would make a lot of sense to just drop the pkcompat layer from aptdaemon
[16:01] <seb128> yeah, probably, we discussed that before xenial
[16:01] <ximion> have stuff which uses PK use PK, and things which use the aptd API use aptd - aptd mimicking PK is just a source of bugs
[16:01] <seb128> I don't remember what issues we had with changing that though
[16:02] <ximion> seb128: those would be interesting to know, because if they are easy to accomodate to on the PK upstream side, we might just do the changes
[16:02] <seb128> I think it was more distro technical debt
[16:03] <seb128> or fixing things that depends on the compat layer
[16:03] <ximion> there's stuff depending on the compat layer?
[16:03] <ximion> that'd be weird... (since everything is using it via libpackagekit-glib2...)
[16:07] <seb128> well, depends in the debian/control sense
[16:07] <ximion> right, that is a different thing
[16:07] <seb128> I think I remeber why we didn't drop it in xenial
[16:08] <seb128> it's because we said it wouldn't make sense to replace it by the outdate/buggy pkgkit 0.8 code
[16:08] <ximion> (but then I would argue that fixing a few packages is less work than adapting aptd - at least in Debian, there is only one package depending on aptd at time, which means everything doing so in Ubuntu must be due to Ubuntu-specific patches)
[16:08] <seb128> and we couldn't update packagkit because of click
[16:09] <seb128> now for y we decided to ignore click
[16:09] <seb128> so we can update packagekit
[16:09] <seb128> and probably drop the aptdaemon compat
[16:09] <ximion> yeah, GNOME Software with PK << 1.0 just doesn't work at all :P
[17:01] <Laney> happy weekend!
[17:01] <Laney> flexiondotorg: I should probably share my CSS changes with you at some point, will give you that soon
[17:01]  * Laney laters
[17:02] <Trevinho> Laney: have nice WE
[17:10] <seb128> Laney, have a good w.e!
[17:13] <flexiondotorg> Laney, great.
[17:13] <flexiondotorg> Laney, https://github.com/flexiondotorg/ubuntu-mate-themes
[17:14] <flexiondotorg> That is where we are adapting the MATE themes to 3.18 for MATE 1.14 built against GTK3.
[17:14] <flexiondotorg> When that is done, we'll branch and start work on 3.20 in the same repo.
[17:40] <willcooke> EOW!  night all, have a great weekend
[17:44] <seb128> have a good w.e desktopers!
[21:12] <Beret> so
[21:12] <Beret> how does one fix the gnome software rubbish in 16.04? :)