[02:05] <liuxg> I am now using Wily, how can I upgrade to 16.04 LTS?
[02:07] <TheMuso> liuxg: You need to load update-manager and tell it to look for the development release.
[02:07] <TheMuso> liuxg: update-manager -d should do it.
[02:07] <liuxg> TheMuso, thanks.
[02:07] <TheMuso> np
[05:17] <hikiko> Hi
[05:25] <happyaron> hi hikiko
[07:00] <hikiko> hi happyaron
[07:00] <hikiko> how are you
[07:00] <hikiko> ?
[07:01] <happyaron> good, :)
[07:01] <hikiko> :D
[08:04] <flexiondotorg> Trevinho, Morning. Can I draw your attention to this merge proposal - https://code.launchpad.net/~ubuntu-mate-dev/compiz/fix-1559371/+merge/289588
[08:19] <pitti> Uh, I forgot to greet this morning -- hello everyone, how are you?
[08:37] <nrosvall> Hi, is the "Black Corners Around CSD Windows" going to be fixed before the final release of 16.04
[08:39] <andyrock> morning
[11:23] <jibel> hikiko|ln, any progress on fixing bug 1555237?
[11:23] <ubot5`> bug 1555237 in ubuntu-release-upgrader (Ubuntu) "Upgrade from 14.04.4→ 16.04 dies midway taking out the session." [Critical,In progress] https://launchpad.net/bugs/1555237
[11:24] <jibel> it's blocking all the upgrade tests
[11:24] <jibel> cyphermox, ^
[11:33] <Sweet5hark1> ricotz: libreoffice 5.1.2 tarballs in my personal staging ppa -- not tested/verified yet in any way, use at own risk ;)
[11:34] <hikiko> jibel, if you read the comments you ll see it's not related to compiz, the packagers are working on it
[11:39] <ricotz> Sweet5hark1, thanks (although no ~xenial1 suffix!)
[11:40] <Sweet5hark1> ricotz: urgh yeah
[11:40] <jibel> hikiko, who is working on it?
[11:41] <ricotz> Sweet5hark1, you know about the consequences doing so
[11:41] <hikiko> slangasek afaik
[11:46] <jibel> Trevinho, ^ is anyone from desktop working on this upgrade bug or is slangasek alone?
[11:48] <hikiko> jibel, it
[11:48] <hikiko> it's not related to the desktop
[11:48] <hikiko> a systemd postupgrade script sends the sigkill to xserver
[11:48] <hikiko> the packagers must find out which and why
[11:49] <hikiko> it's not a desktop app that stops xserver
[11:50] <hikiko> infinity, is also aware of the bug I think
[11:50] <jibel> hikiko, it's a desktop upgrade bug, someone from desktop must be leading it, isn't it? I see it's still assigned to the release upgrader and cyphermox, but it seems inaccurate
[11:51] <hikiko> no, systemd sends a signal to xserver and all the desktop crashes but it's systemd that must be debugged
[11:51] <hikiko> we are not familar to that
[11:51] <hikiko> a package upgrades
[11:51] <hikiko> and a script of it
[11:51] <hikiko> kills xserver
[11:52] <hikiko> someone who knows about packaging etc
[11:52] <hikiko> must find out what happens and fix it
[11:53] <hikiko> see slangasek comments
[11:53] <hikiko> maybe it should be reassigned
[11:53] <hikiko> but there's not something compiz side or desktop side that is involved
[11:54] <hikiko> these applications die because xserver dies
[11:54] <hikiko> and xserver dies because he receives a kill signal from something that is part of systemd
[11:54] <doko> Sweet5hark1, do you have a lo upload in the queue?
[11:55] <Sweet5hark1> doko: currently building an rc -- no new final from upstream yet. Why?
[11:55] <doko> https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/libr/libreoffice/20160331_112249@/log.gz
[11:56] <doko> Sweet5hark1, I removed openjdk-7, but apparently a bit early
[12:03] <Sweet5hark1> doko: yeah, subsequentcheckbase is partially containing manual deps for $reasons. I bumped the dep to openjdk-8 -- dunno when/how we still want to push that to the archive still though :/
[12:03] <doko> Sweet5hark1, are there any hardcoded paths?
[12:06] <Sweet5hark1> doko: https://git.launchpad.net/~libreoffice/ubuntu/+source/libreoffice/tree/tests/junit-subsequentcheck?h=ubuntu-xenial-5.1&id=d0554fda24a621fd2cb5bcc208469cd6987ae6e4 <- I dont think so.
[12:06] <Sweet5hark1> doko: that subsquenttestbase stuff is only used to enable running the autopkgtests, no enduser should ever use it.
[12:07] <doko> pitti, Sweet5hark1: so please ignore the libreoffice autopkg test failures for now, until we get a new libreoffice
[12:08] <Sweet5hark1> doko: k.
[12:08] <doko> Sweet5hark1, but please target it for this week if possible
[12:09] <doko> and change the dep to default-jdk
[12:12] <Sweet5hark1> doko: default-jdk -> done (locally). trying to get this in this week -> possible, but essentially would mean skipping all staged testing in the ppa, which is somewhat meh after beta ...
[12:12] <Sweet5hark1> doko: anyway will try to find someone foolish enough to sponsor it ..
[12:13] <doko> Sweet5hark1, new upstream?
[12:16] <Sweet5hark1> archive has 5.1.1~rc3=5.1.1 final. upstream status is 5.1.2~rc2 was tagged 44 hours ago, will likely be called rc2=final mid next week unless there is some horror story coming up (which is rare with these bugfix only minor releases)
[12:16] <doko> or we can do just this dependency change
[12:20] <Sweet5hark1> doko: sure -- would be playing it safe. TBH as we are quite late already and this is a LTS, Id prefer that.
[12:22] <Sweet5hark1> doko: Ill prepare a 5.1.1 with the dep changed for direct sponsoring to the archive. 5.1.2 is for the ppa for now -- and w
[12:22] <Sweet5hark1> we can see if we need/can do another LO upload later still...
[12:53] <cyphermox> hikiko: how did you reach that conclusion?
[12:54] <hikiko> cyphermox, gdb output of xserver shows that xserver stops by sigkill and that's why there's no error in the logs
[12:54] <hikiko> plus syslog has some suspicious errors (see the bug comments)
[12:54] <hikiko> that point out udisk2 upgrade
[12:55] <hikiko> plus metacity crashes too and every wm
[12:55] <hikiko> because the crash is caused *after* xserver is killed and it's normal
[12:55] <hikiko> see slangansek comments and mine in the description cyphermox
[13:13] <cyphermox> ok, so no reason to say it's systemd then.
[13:16] <popey> cyphermox: i see you recently updated ubiquity slideshow - it's been noticed that we still refer to "Ubuntu Software Centre" when we probably should refer to "GNOME Software" - seems like some strings haven't been updated yet?
[13:32] <cyphermox> popey: possible, I haven't changed it in any way, only sponsored uploads
[13:32] <popey> ah, looks like Will changed some bits but not all
[13:32] <cyphermox> Software Center is still accurate, depends if there is "Ubuntu" in front
[13:32] <popey> I think upstream will be a bit upset with that
[13:32] <cyphermox> he might have only changed ubuntu, not the flavors
[13:32] <popey> well, I know they will. :)
[13:32] <popey> they already noticed.
[13:32] <cyphermox> oh, true, good point
[13:33] <cyphermox> well, I can run a big sed through it
[13:33] <popey> :)
[13:33] <popey> That'd be a good start.
[13:37] <cyphermox> popey: someone complained already?
[13:40] <cyphermox> popey: I can't update everything, software-center still is in the archive, flavors may be using that rather than gnome-software
[13:40] <popey> cyphermox: yeah, the upstream maintainer not so much complained but "noticed"
[13:45] <hikiko> cyphermox, because systemd is the most possible program that has the rights/access to kill xserver and because udisks2  (slangancek's syslog paste) are controlled by systemd
[13:45] <hikiko> anyway
[13:45] <hikiko> even if it's not that
[13:45] <hikiko> it's certainly not compiz
[13:46] <hikiko> so I can't help much :/
[13:46] <cyphermox> hikiko: I know
[13:46] <cyphermox> hikiko: but you also can't say it's systemd without checking, because it could just as well be upstart in this case.
[13:46] <cyphermox> upstart is the currently used init system on trusty
[13:47] <hikiko> oh, yes sorry I meant the init system :s/systemd/whatever init system is running at that time/
[13:47] <hikiko> right
[13:47] <hikiko> :)
[13:48] <hikiko> cyphermox,
[13:49] <hikiko> I don't know if that info helps:
[13:49] <hikiko> we only see the problem in amd64 never in i386
[13:51] <cyphermox> that seems quite unlikely, but if you say so
[13:51] <cyphermox> I'll give it a try later
[13:51] <cyphermox> fwiw the compiz crash I already fixed
[13:52] <cyphermox> compiz or lightdm or whatever was crashing in part because it would ask dbus to fire login1, which it couldn't because of bad permissions on a setuid helper program -- I posit that failing to find logind around to confirm users and passwords, things exploded
[13:52] <cyphermox> I no longer see the crash when a screensaver starts, but X still crashes, due to some other thing (the KILLs slangasek saw)
[13:59] <ricotz> Sweet5hark1, and there is a reason for another build, there is still the hard-dep on openjdk-7-jdk
[14:00] <Sweet5hark1> ricotz: in subsequenttestbase or elsewhere?
[14:00] <ricotz> Sweet5hark1, just there
[14:01] <Sweet5hark1> ricotz: see backlog
[14:01] <ricotz> Sweet5hark1, I see, I pinged you yesterday about it too
[14:25] <ricotz> Sweet5hark1, so if you are going to fix it please use a version like 1:5.1.2~rc2-0ubuntu2~ , I need to copy the successful build anyway for the backport builds
[14:44] <ricotz> Sweet5hark1, are you still looking into updating some lo deps? e.g. liborcus and libpagemager are outdated
[14:44] <ricotz> *libpagemaker
[15:10] <doko> ricotz, liborcus is up to date
[15:13] <ricotz> doko, I see, seems 0.11.x (in exp) is targeted for lo 5.2
[15:14] <doko> ricotz, please file a FFe then
[15:15] <ricotz> doko, meaning xenial will have lo 5.1, and upstream is using orcus 0.9.x for 5.1 too
[15:34] <om26er_> Trevinho, Hi!
[15:34] <Trevinho> om26er_: hey
[15:35] <om26er_> Trevinho, Did you see bug 1559748 ?
[15:35] <ubot5`> bug 1559748 in compiz (Ubuntu) "Windows content appears transparent before fully being created" [Undecided,New] https://launchpad.net/bugs/1559748
[15:36] <om26er_> its like an empty frame is filled after the surface is created completely
[15:43] <Trevinho> ochosi: yeah, I've noticed that sometimes, but I'm not sure whether we can do much... It's up to the window to draw its content, and it seems it's like "late"... on doing that
[15:43] <Trevinho> new gtk would love to get some frame infos from WM, maybe but we don't support it so...
[15:44] <Trevinho> ochosi: sorry, that was for om26er :P
[18:13] <doko> Sweet5hark1, that's a build fix for glibc-2.23: https://launchpad.net/ubuntu/+source/libreoffice/1:5.1.1-0ubuntu3   and -0ubuntu2 has the openjdk-7 removal
[18:22] <doko> Sweet5hark1, looks like the tests are not built in parallel, but sequentially ...
[18:40] <Sweet5hark1> doko: thx, great. no further fixup needed on LibreOffice side then?
[18:41] <Sweet5hark1> will put your change in git and rebase on top of it then ...
[18:41] <doko> Sweet5hark1, I hope so. btw, why are the tests built sequentially?
[18:41] <doko> Sweet5hark1, remember, there are two changes ...
[18:42] <Sweet5hark1> doko: IIRC there was some race condition with high paralellisation. would need to look at the git log for the details.
[18:43] <doko> Sweet5hark1, well, maybe for running, but not building the tests?
[18:44] <Sweet5hark1> doko: ah, yeah. building in parallel shouldnt be an issue, I guess.
[18:44] <doko> rene tells me that he disabled building the tests during the build ...
[20:51] <robert_ancell> attente, how goes the updating?
[20:53] <attente> robert_ancell: contemplating just making a single patch for each branch tbh...
[20:54] <robert_ancell> attente, you mean merging wip/ubuntu-changes into one patch?
[20:55] <robert_ancell> because wip/rancell/apt and wip/rancell/reviews should be a patch each
[20:57] <attente> robert_ancell: okay, that makes life a lot easier. is there a reason why we're not flattening the ubuntu-changes patches in the first place?
[20:58] <robert_ancell> attente, it just seemed like a lot of random things that didn't really relate to eachother
[20:58] <robert_ancell> I was worried that it would make it harder to upstream / drop the various change
[20:58] <robert_ancell> s
[20:58] <robert_ancell> But obviously it makes it harder to deploy
[20:59] <robert_ancell> (harder to deploy as separate patches)
[20:59] <attente> yeah, makes sense actually
[21:00] <robert_ancell> Was wondering if you had any clever ideas for bug 1564209
[21:00] <ubot5`> bug 1564209 in gnome-software (Ubuntu) "Doesn't recognise own reviews" [Medium,Triaged] https://launchpad.net/bugs/1564209
[21:01] <robert_ancell> We don't seem to be able to know the U1 username, but I *think* you might be able to use GET on /api/v2/accounts and that might give it
[21:01] <robert_ancell> It's not documented however
[21:10] <robert_ancell> attente, ^
[21:16] <attente> robert_ancell: maybe we could just cache the username instead
[21:16] <dobey> you're trying to figure out how to get the e-mail address for the u1 account?
[21:16] <dobey> oh to compare reviews?
[21:17] <attente> dobey: yeah, just to know which ones are ours. i guess we can just store it somewhere in libaccounts
[21:17] <dobey> it is the consumer_key you need to compare
[21:17] <dobey> at least, that is what we do in click scope
[21:18] <attente> oh. is it? then we already have the consumer_key stored in libaccounts
[21:19] <dobey> i don't know if the old reviews api has that in the json though
[21:19] <dobey> what API are you using?
[21:19] <robert_ancell> dobey, no, it's not the consumer key
[21:20] <robert_ancell> dobey, so for my review my username is "robert-ancell" i.e. my launchpad account name
[21:20] <robert_ancell> My consumer key is something like Ch8J3d
[21:20] <dobey> robert_ancell: the consumer_key value should be the same as the open_id for your account
[21:20] <robert_ancell> dobey, that's what I thought
[21:20] <dobey> the review json should have the open_id in it too
[21:21] <dobey> well, it is in the click reviews, at least
[21:22] <robert_ancell> dobey, ah, so perhaps I need to port that change across
[21:22] <dobey> there is no "username" for the u1 account actually. that "username" is your launchpad id
[21:22] <robert_ancell> yeah
[21:23] <dobey> so you either have to compare the openid/consumer_key (best way), or e-mail address (will work until you change your address)
[21:25] <robert_ancell> dobey, the click reviews seem to set reviewer_username / reviewer_displayname the same as the old reviews system
[21:26] <dobey> robert_ancell: yes
[21:26] <dobey> robert_ancell: it's the same system, just different API endpoint, afaik
[21:26] <robert_ancell> dobey, so a review response is http://paste.ubuntu.com/15571366/ . There's no cosumer_key there
[21:27] <dobey> let me see what we're actually using in the click scope
[21:31] <dobey> robert_ancell: hmm, looks like the server is sticking the consumer_key value in reviewer_username for the click reviews
[21:32] <dobey> robert_ancell: oh, and it looks like it's doing that for most people there
[21:33] <robert_ancell> yeah, that's what I first thought. But mine is not
[21:33] <dobey> robert_ancell: maybe we can just ask for it to be changed to always return the consumer key there
[21:36] <robert_ancell> dobey, so how does click scope match them? It works on my phone
[21:38] <dobey> robert_ancell: it does consumer_key == reviewer_username
[21:38] <dobey> robert_ancell: what app package name on the phone?
[21:38] <robert_ancell> dobey, unav for example
[21:38] <robert_ancell> What's the URL to get reviews for click?
[21:39] <dobey> robert_ancell: https://reviews.ubuntu.com/click/api/1.0/reviews/?package_name=navigator.costales
[21:39] <robert_ancell> huh, so that's doing it correctly
[21:40] <dobey> does software-center do editing correctly?
[21:40] <robert_ancell> I *think* it remembers them locally by id, so it's cheating
[21:41] <robert_ancell> But I haven't looked yet
[21:41] <dobey> oh
[21:41] <dobey> well if that's true, then we can change the server side without breaking software-center
[21:41] <dobey> so that'd be a win
[21:43] <robert_ancell> dobey, are you familiar with lp:rnrserver ? It just seems to be getting the username from a database afaict. Which is a worry...
[21:44] <dobey> i am not
[21:44] <dobey> but i added it to your bug
[21:44] <robert_ancell> models.ForeignKey(User) is where it hits django and I'm lost
[21:44] <dobey> and i'm asking if we can change the server to do this on the API
[21:45] <robert_ancell> Which makes me worried that the database entries might sometimes have a username and sometimes a consumer_key?
[21:45] <dobey> robert_ancell: if it is just pulling the value from the db, then i guess we'd just need to do something to sync all the consumer_key values in, and change the edit/create API calls to end up doing that
[21:46] <dobey> robert_ancell: anyone without a launchpad username will presumably have it be the consumer key when submitting a review
[21:46] <robert_ancell> yeah
[21:46] <dobey> robert_ancell: the only thing i'd worry about is if software-center would be broken in this case, but i suppose probably not
[21:47] <robert_ancell> hmm, software-center seems to be making that comparison. I'll check what is does for me
[21:47] <dobey> oh?
[21:47] <dobey> that's interesting
[21:49] <robert_ancell> dobey, aha, it seems to get the username after sending a review (in the json response)
[21:50] <robert_ancell> so I guess that handles the case it is a LP username
[21:50] <robert_ancell> But means it wont work on first run
[21:51] <dobey> huh
[21:51] <dobey> and it caches that value somewhere?
[21:52] <dobey> ah it does
[21:53] <robert_ancell> I'm sure someone told me that s-c doesn't recognise your reviews on reinstall, which would explain that
[21:53] <dobey> but we could also SRU a change to software-center to make it use the consumer_key from the u1 account; or we could just have a different open_id="" in the server json
[21:53] <dobey> yeah
[21:53] <dobey> it stores the "username" in a config file
[21:53] <robert_ancell> yep
[21:54] <dobey> so it also won't recognize your reviews on a different machine if you don't submit one on it
[21:54] <robert_ancell> yes
[21:55] <dobey> so it's broken anyway
[21:55] <robert_ancell> I can't work out in lp:rnrserver where it's deciding to override consumer_key with launchpad ID
[21:56] <dobey> so i think changing reviewr_name to always be the consumer key on the server would be the best option; and then we can maybe do a software-center SRU patch to make it use the consumer_key from the account
[21:56] <dobey> yeah i don't know
[21:56] <dobey> but i added rnr-server to the bug report, and pinged those people on irc :)
[21:57] <dobey> noodles, since he's around now
[21:59] <robert_ancell> dobey, ta
[22:00] <robert_ancell> attente, do you think you'll get a gnome-software update done today? If not I'm keen to do one because there's some important fixes.
[22:00] <robert_ancell> attente, or tomorrow, I forgot you're still on Thursday
[22:01] <dobey> heh
[22:01] <dobey> it's nigh time for dinner over on this side of the spheere
[22:04] <attente> robert_ancell: sure, i'll do it. i'm just going to squash those other branches though
[22:04] <robert_ancell> attente, how will you generate the patch?
[22:06] <attente> robert_ancell: pretty much will just git diff gnome-3-20 against the branches (except wip/ubuntu-changes)
[22:06] <robert_ancell> attente, not going to use git format-patch?
[22:06] <dobey> robert_ancell, attente: i'd say go ahead and do the consumer_key == reviewer_username in gnome-software, and it will work for a very large number of people already, and we can fix the server behind the scenes to improve it for those who do have lp usernames currently
[22:06] <robert_ancell> dobey, ok, thanks
[22:07] <dobey> and plenty of comments on that bug now :)
[22:08] <dobey> and now i have to go :)
[22:08] <dobey> later
[22:49] <attente> robert_ancell: how did you format the merge commits for wip/rancell/(apt|reviews)? when i try to, it tries to format patches for every single commit responsible for the merge
[23:47] <robert_ancell> attente, I made a local branch and rebased all the changes into one commit
[23:47] <robert_ancell> attente, but that was the first time, then I just cherry-picked the changes to my main rebased branch
[23:48] <attente> robert_ancell: i think i'm just going to create a new commit that contains the diff, and format-patch that instead
[23:48] <robert_ancell> attente, a commit to what?
[23:49] <attente> robert_ancell: i've got a new branch that has all of the wip/ubuntu-changes cherry-picked, as well as merges of the other branches
[23:49] <attente> but trying to git-format-patch those merges results in a large number of patches
[23:49] <robert_ancell> attente, so that's the same as gnome-3-20 + debian/patches/*.patch then?
[23:50] <attente> almost the same
[23:58] <attente> robert_ancell: ok, i think that worked