[02:05] I am now using Wily, how can I upgrade to 16.04 LTS? [02:07] liuxg: You need to load update-manager and tell it to look for the development release. [02:07] liuxg: update-manager -d should do it. [02:07] TheMuso, thanks. [02:07] np === meetingology` is now known as meetingology === xnox_ is now known as xnox === dkessel_ is now known as dkessel === Drac0 is now known as Guest44713 [05:17] Hi [05:25] hi hikiko [07:00] hi happyaron [07:00] how are you [07:00] ? [07:01] good, :) [07:01] :D === maclin1 is now known as maclin [08:04] 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] Uh, I forgot to greet this morning -- hello everyone, how are you? [08:37] Hi, is the "Black Corners Around CSD Windows" going to be fixed before the final release of 16.04 [08:39] morning === Drac0 is now known as Guest49724 === hikiko is now known as hikiko|ln [11:23] hikiko|ln, any progress on fixing bug 1555237? [11:23] 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] it's blocking all the upgrade tests [11:24] cyphermox, ^ === hikiko|ln is now known as hikiko [11:33] ricotz: libreoffice 5.1.2 tarballs in my personal staging ppa -- not tested/verified yet in any way, use at own risk ;) [11:34] jibel, if you read the comments you ll see it's not related to compiz, the packagers are working on it [11:39] Sweet5hark1, thanks (although no ~xenial1 suffix!) [11:40] ricotz: urgh yeah [11:40] hikiko, who is working on it? [11:41] Sweet5hark1, you know about the consequences doing so [11:41] slangasek afaik [11:46] Trevinho, ^ is anyone from desktop working on this upgrade bug or is slangasek alone? [11:48] jibel, it [11:48] it's not related to the desktop [11:48] a systemd postupgrade script sends the sigkill to xserver [11:48] the packagers must find out which and why [11:49] it's not a desktop app that stops xserver [11:50] infinity, is also aware of the bug I think [11:50] 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] no, systemd sends a signal to xserver and all the desktop crashes but it's systemd that must be debugged [11:51] we are not familar to that [11:51] a package upgrades [11:51] and a script of it [11:51] kills xserver [11:52] someone who knows about packaging etc [11:52] must find out what happens and fix it [11:53] see slangasek comments [11:53] maybe it should be reassigned [11:53] but there's not something compiz side or desktop side that is involved [11:54] these applications die because xserver dies [11:54] and xserver dies because he receives a kill signal from something that is part of systemd [11:54] Sweet5hark1, do you have a lo upload in the queue? [11:55] doko: currently building an rc -- no new final from upstream yet. Why? [11:55] https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-xenial/xenial/amd64/libr/libreoffice/20160331_112249@/log.gz [11:56] Sweet5hark1, I removed openjdk-7, but apparently a bit early [12:03] 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] Sweet5hark1, are there any hardcoded paths? [12:06] 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] doko: that subsquenttestbase stuff is only used to enable running the autopkgtests, no enduser should ever use it. [12:07] pitti, Sweet5hark1: so please ignore the libreoffice autopkg test failures for now, until we get a new libreoffice [12:08] doko: k. [12:08] Sweet5hark1, but please target it for this week if possible [12:09] and change the dep to default-jdk === alan_g is now known as alan_g|lunch [12:12] 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] doko: anyway will try to find someone foolish enough to sponsor it .. [12:13] Sweet5hark1, new upstream? [12:16] 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] or we can do just this dependency change [12:20] doko: sure -- would be playing it safe. TBH as we are quite late already and this is a LTS, Id prefer that. [12:22] 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] we can see if we need/can do another LO upload later still... === Guest51083 is now known as fredp === fredp is now known as Guest41123 [12:53] hikiko: how did you reach that conclusion? [12:54] cyphermox, gdb output of xserver shows that xserver stops by sigkill and that's why there's no error in the logs [12:54] plus syslog has some suspicious errors (see the bug comments) [12:54] that point out udisk2 upgrade [12:55] plus metacity crashes too and every wm [12:55] because the crash is caused *after* xserver is killed and it's normal [12:55] see slangansek comments and mine in the description cyphermox === alan_g|lunch is now known as alan_g [13:13] ok, so no reason to say it's systemd then. [13:16] 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] popey: possible, I haven't changed it in any way, only sponsored uploads [13:32] ah, looks like Will changed some bits but not all [13:32] Software Center is still accurate, depends if there is "Ubuntu" in front [13:32] I think upstream will be a bit upset with that [13:32] he might have only changed ubuntu, not the flavors [13:32] well, I know they will. :) [13:32] they already noticed. [13:32] oh, true, good point [13:33] well, I can run a big sed through it [13:33] :) [13:33] That'd be a good start. [13:37] popey: someone complained already? [13:40] popey: I can't update everything, software-center still is in the archive, flavors may be using that rather than gnome-software [13:40] cyphermox: yeah, the upstream maintainer not so much complained but "noticed" [13:45] 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] anyway [13:45] even if it's not that [13:45] it's certainly not compiz [13:46] so I can't help much :/ [13:46] hikiko: I know [13:46] 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] upstart is the currently used init system on trusty [13:47] oh, yes sorry I meant the init system :s/systemd/whatever init system is running at that time/ [13:47] right [13:47] :) [13:48] cyphermox, [13:49] I don't know if that info helps: [13:49] we only see the problem in amd64 never in i386 [13:51] that seems quite unlikely, but if you say so [13:51] I'll give it a try later [13:51] fwiw the compiz crash I already fixed [13:52] 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] 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] Sweet5hark1, and there is a reason for another build, there is still the hard-dep on openjdk-7-jdk [14:00] ricotz: in subsequenttestbase or elsewhere? [14:00] Sweet5hark1, just there [14:01] ricotz: see backlog [14:01] Sweet5hark1, I see, I pinged you yesterday about it too [14:25] 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] Sweet5hark1, are you still looking into updating some lo deps? e.g. liborcus and libpagemager are outdated [14:44] *libpagemaker [15:10] ricotz, liborcus is up to date [15:13] doko, I see, seems 0.11.x (in exp) is targeted for lo 5.2 [15:14] ricotz, please file a FFe then [15:15] doko, meaning xenial will have lo 5.1, and upstream is using orcus 0.9.x for 5.1 too [15:34] Trevinho, Hi! [15:34] om26er_: hey [15:35] Trevinho, Did you see bug 1559748 ? [15:35] bug 1559748 in compiz (Ubuntu) "Windows content appears transparent before fully being created" [Undecided,New] https://launchpad.net/bugs/1559748 [15:36] its like an empty frame is filled after the surface is created completely [15:43] 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] new gtk would love to get some frame infos from WM, maybe but we don't support it so... [15:44] ochosi: sorry, that was for om26er :P === alan_g is now known as alan_g|EOD === muktupavels is now known as muktupavels_ [18:13] 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] Sweet5hark1, looks like the tests are not built in parallel, but sequentially ... [18:40] doko: thx, great. no further fixup needed on LibreOffice side then? [18:41] will put your change in git and rebase on top of it then ... [18:41] Sweet5hark1, I hope so. btw, why are the tests built sequentially? [18:41] Sweet5hark1, remember, there are two changes ... [18:42] doko: IIRC there was some race condition with high paralellisation. would need to look at the git log for the details. [18:43] Sweet5hark1, well, maybe for running, but not building the tests? [18:44] doko: ah, yeah. building in parallel shouldnt be an issue, I guess. [18:44] rene tells me that he disabled building the tests during the build ... === Texa is now known as Texou [20:51] attente, how goes the updating? [20:53] robert_ancell: contemplating just making a single patch for each branch tbh... [20:54] attente, you mean merging wip/ubuntu-changes into one patch? [20:55] because wip/rancell/apt and wip/rancell/reviews should be a patch each [20:57] 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] attente, it just seemed like a lot of random things that didn't really relate to eachother [20:58] I was worried that it would make it harder to upstream / drop the various change [20:58] s [20:58] But obviously it makes it harder to deploy [20:59] (harder to deploy as separate patches) [20:59] yeah, makes sense actually [21:00] Was wondering if you had any clever ideas for bug 1564209 [21:00] bug 1564209 in gnome-software (Ubuntu) "Doesn't recognise own reviews" [Medium,Triaged] https://launchpad.net/bugs/1564209 [21:01] 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] It's not documented however [21:10] attente, ^ [21:16] robert_ancell: maybe we could just cache the username instead [21:16] you're trying to figure out how to get the e-mail address for the u1 account? [21:16] oh to compare reviews? [21:17] dobey: yeah, just to know which ones are ours. i guess we can just store it somewhere in libaccounts [21:17] it is the consumer_key you need to compare [21:17] at least, that is what we do in click scope [21:18] oh. is it? then we already have the consumer_key stored in libaccounts [21:19] i don't know if the old reviews api has that in the json though [21:19] what API are you using? [21:19] dobey, no, it's not the consumer key [21:20] dobey, so for my review my username is "robert-ancell" i.e. my launchpad account name [21:20] My consumer key is something like Ch8J3d [21:20] robert_ancell: the consumer_key value should be the same as the open_id for your account [21:20] dobey, that's what I thought [21:20] the review json should have the open_id in it too [21:21] well, it is in the click reviews, at least [21:22] dobey, ah, so perhaps I need to port that change across [21:22] there is no "username" for the u1 account actually. that "username" is your launchpad id [21:22] yeah [21:23] 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] dobey, the click reviews seem to set reviewer_username / reviewer_displayname the same as the old reviews system [21:26] robert_ancell: yes [21:26] robert_ancell: it's the same system, just different API endpoint, afaik [21:26] dobey, so a review response is http://paste.ubuntu.com/15571366/ . There's no cosumer_key there [21:27] let me see what we're actually using in the click scope [21:31] robert_ancell: hmm, looks like the server is sticking the consumer_key value in reviewer_username for the click reviews [21:32] robert_ancell: oh, and it looks like it's doing that for most people there [21:33] yeah, that's what I first thought. But mine is not [21:33] robert_ancell: maybe we can just ask for it to be changed to always return the consumer key there [21:36] dobey, so how does click scope match them? It works on my phone [21:38] robert_ancell: it does consumer_key == reviewer_username [21:38] robert_ancell: what app package name on the phone? [21:38] dobey, unav for example [21:38] What's the URL to get reviews for click? [21:39] robert_ancell: https://reviews.ubuntu.com/click/api/1.0/reviews/?package_name=navigator.costales [21:39] huh, so that's doing it correctly [21:40] does software-center do editing correctly? [21:40] I *think* it remembers them locally by id, so it's cheating [21:41] But I haven't looked yet [21:41] oh [21:41] well if that's true, then we can change the server side without breaking software-center [21:41] so that'd be a win [21:43] 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] i am not [21:44] but i added it to your bug [21:44] models.ForeignKey(User) is where it hits django and I'm lost [21:44] and i'm asking if we can change the server to do this on the API [21:45] Which makes me worried that the database entries might sometimes have a username and sometimes a consumer_key? [21:45] 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] robert_ancell: anyone without a launchpad username will presumably have it be the consumer key when submitting a review [21:46] yeah [21:46] 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] hmm, software-center seems to be making that comparison. I'll check what is does for me [21:47] oh? [21:47] that's interesting [21:49] dobey, aha, it seems to get the username after sending a review (in the json response) [21:50] so I guess that handles the case it is a LP username [21:50] But means it wont work on first run [21:51] huh [21:51] and it caches that value somewhere? [21:52] ah it does [21:53] I'm sure someone told me that s-c doesn't recognise your reviews on reinstall, which would explain that [21:53] 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] yeah [21:53] it stores the "username" in a config file [21:53] yep [21:54] so it also won't recognize your reviews on a different machine if you don't submit one on it [21:54] yes [21:55] so it's broken anyway [21:55] I can't work out in lp:rnrserver where it's deciding to override consumer_key with launchpad ID [21:56] 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] yeah i don't know [21:56] but i added rnr-server to the bug report, and pinged those people on irc :) [21:57] noodles, since he's around now [21:59] dobey, ta [22:00] 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] attente, or tomorrow, I forgot you're still on Thursday [22:01] heh [22:01] it's nigh time for dinner over on this side of the spheere [22:04] robert_ancell: sure, i'll do it. i'm just going to squash those other branches though [22:04] attente, how will you generate the patch? [22:06] robert_ancell: pretty much will just git diff gnome-3-20 against the branches (except wip/ubuntu-changes) [22:06] attente, not going to use git format-patch? [22:06] 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] dobey, ok, thanks [22:07] and plenty of comments on that bug now :) [22:08] and now i have to go :) [22:08] later [22:49] 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] attente, I made a local branch and rebased all the changes into one commit [23:47] attente, but that was the first time, then I just cherry-picked the changes to my main rebased branch [23:48] robert_ancell: i think i'm just going to create a new commit that contains the diff, and format-patch that instead [23:48] attente, a commit to what? [23:49] 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] but trying to git-format-patch those merges results in a large number of patches [23:49] attente, so that's the same as gnome-3-20 + debian/patches/*.patch then? [23:50] almost the same [23:58] robert_ancell: ok, i think that worked