| === _salem is now known as salem_ | ||
| === salem_ is now known as _salem | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| morphis | Mirv, robru: anyone time for an upload? | 08:21 |
|---|---|---|
| Mirv | morphis: sure | 08:22 |
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| === chihchun_afk is now known as chihchun | ||
| === chihchun is now known as chihchun_afk | ||
| Trevinho | robru: for some reason https://requests.ci-train.ubuntu.com/#/ticket/735 says that I've to rebuild unity... While I already did that... Not sure why. | 10:36 |
| === _salem is now known as salem_ | ||
| rvr | Elleo: ping | 11:14 |
| Elleo | rvr: pong? | 11:25 |
| rvr | Elleo: Hi | 11:25 |
| rvr | Elleo: There is a failing autopilot test in silo 2 (keyboard) | 11:25 |
| rvr | Elleo: https://trello.com/c/O6WgMzXS/2534-712-ubuntu-landing-002-ubuntu-keyboard-michael-sheldon | 11:25 |
| Elleo | rvr: ah, hadn't spotted that, wasn't failing when I ran the tests locally :/ | 11:25 |
| Elleo | might be flaky will see if I can reproduce it | 11:25 |
| rvr | Elleo: Ok | 11:25 |
| bzoltan_ | sil2100: ping | 12:08 |
| bzoltan_ | sil2100: somebody has landed something with OTA8 that forced ssh to accept only 1024 long keys... that practically broke all SDK IDE where the developers had paired devices with the QtCreator. I would love to see that change reverter :) kind of... | 12:10 |
| sil2100 | bzoltan_: pong | 12:15 |
| sil2100 | bzoltan_: oh! hm, do you know which package upload caused that? | 12:16 |
| sil2100 | Was that a security update, or an overlay landing? | 12:16 |
| bzoltan_ | sil2100: i assume it was the openssh-server | 12:16 |
| Elleo | rvr: haven't been able to reproduce this locally at all, after rerunning that test a couple of dozen times on a krillin :/ | 12:17 |
| sil2100 | bzoltan_: I'm asking since I didn't see any offending change in the latest openssh for vivid, but let me dig deeper | 12:17 |
| Elleo | rvr: can't seem to connect to s-jenkins to kick of a retry there though, not sure why general VPN stuff is working; guessing something got messed up when I upgraded to wily the other day | 12:18 |
| bzoltan_ | sil2100: afaik there is no ssh server in the Overlay PPA | 12:18 |
| Mirv | bzoltan_: sil2100: right it doesn't say anything at https://launchpad.net/ubuntu/vivid/+source/openssh/+changelog | 12:18 |
| rvr | Elleo: Ok | 12:18 |
| rvr | Elleo: Maybe some race condition | 12:18 |
| sil2100 | It might have been the previous one, but I don't see much related things in the changelog there too | 12:19 |
| bzoltan_ | Mirv: sil2100: silly me, it was on the rc-poposed image | 12:19 |
| Elleo | rvr: maybe, the krillins are a bit slower than the makos which might be why it hasn't triggered in jenkins before | 12:19 |
| Elleo | rvr: but haven't been able to hit it on my krillin yet | 12:19 |
| bzoltan_ | sil2100: it happened with kaleo's device what he flashed with rc-proposed | 12:21 |
| sil2100 | bzoltan_: could you guys try to bisect with which rc-proposed image it started being like that? We could then check which upload is guilty | 12:23 |
| sil2100 | Since openssh was updated last 1.5 month ago | 12:23 |
| bzoltan_ | sil2100: the 1:6.7p1-5ubuntu1.3 does 1024 key length | 12:28 |
| sil2100 | http://launchpadlibrarian.net/214762531/openssh_1%3A6.7p1-5ubuntu1.2_1%3A6.7p1-5ubuntu1.3.diff.gz <- this is the diff, I doubt that this change causes issues | 12:29 |
| cjwatson | bzoltan_: ssh -vvv output would be helpful I'm sure | 12:29 |
| cjwatson | because I'm the openssh maintainer and I can't parse your complaint about it | 12:30 |
| cjwatson | certainly no vivid update has intentionally changed any key length policy | 12:30 |
| cjwatson | but you may be misconstruing the problem in some way, so debug output | 12:31 |
| bzoltan_ | cjwatson: one of us has flashed his device what was paired with his desktop and got this -> http://pastebin.ubuntu.com/13643148/ | 12:31 |
| bzoltan_ | cjwatson: sil2100: http://changelogs.ubuntu.com/changelogs/pool/main/o/openssh/openssh_6.7p1-5ubuntu1.3/changelog | 12:32 |
| cjwatson | bzoltan_: what version of openssh-client is on the desktop system in question? | 12:32 |
| bzoltan_ | cjwatson: 1:7.1p1-1 | 12:34 |
| cjwatson | bzoltan_: this is a client-side problem, not a server-side problem | 12:34 |
| cjwatson | bzoltan_: and relates to an upgrade in xenial, not in vivid | 12:34 |
| bzoltan_ | cjwatson: good to hear :) | 12:34 |
| cjwatson | bzoltan_: just change ./share/qtcreator/ubuntu/scripts/openssh_publickey to use -b 1024 rather than -b 768 | 12:34 |
| cjwatson | I'm not going to back this out, 768 bits is ridiculously short | 12:35 |
| bzoltan_ | cjwatson: that is fine, but what to do with the existing keys.. there are 10k+ users out there with SDK IDE installed. Maybe we push a release to force a key recreation. | 12:36 |
| cjwatson | bzoltan_: uh, this error comes from ssh-keygen, while generating keys | 12:37 |
| cjwatson | bzoltan_: before you invent problems maybe check that they are actually problems :) | 12:37 |
| zbenjamin | cjwatson: so the existing keys will continue to work? | 12:39 |
| cjwatson | though let's see, just checking | 12:39 |
| cjwatson | https://anongit.mindrot.org/openssh.git/commit/?id=933935ce was the commit in question | 12:40 |
| cjwatson | I cannot guarantee that ssh will in general continue to accept insecurely short host keys | 12:40 |
| cjwatson | it would be negligent to do so | 12:40 |
| cjwatson | http://www.openssh.com/txt/release-7.0 makes it clear that they will refuse such keys in future | 12:40 |
| cjwatson | zbenjamin: I *think* it's still accepted for the time being, though you can fairly easily check by just sshing to a device with such a host key. however, I'd advise pushing some kind of update to force generating less weak host keys in any case | 12:44 |
| zbenjamin | cjwatson: ok thanks , we will figure something out | 12:44 |
| cjwatson | since you're generating the key on the client, I highly doubt that there's a substantial performance justification for going with extremely weak keys | 12:46 |
| bzoltan_ | cjwatson: thanks for the help and updates... one possible lame but edcational question. When you talk about "extremely weak keys", what do you actually mean? | 12:51 |
| cjwatson | bzoltan_: 768-bit RSA keys are completely insecure and broken | 12:52 |
| cjwatson | bzoltan_: even 1024-bit is shaky; maybe in this specific case it doesn't matter too much but it's ssh's responsibility to consider more general security | 12:53 |
| bzoltan_ | cjwatson: What does that mean in practice? What calculating power needed to break a 768bits key in T time? | 12:53 |
| bzoltan_ | cjwatson: I am not challenging :) just wish to understand. | 12:53 |
| cjwatson | bzoltan_: I don't recall the current figures, it's not something I keep track of | 12:54 |
| cjwatson | but 768-bit RSA was first factored in 2010 or so, and this sort of thing tends to be exponential | 12:55 |
| bzoltan_ | cjwatson: I mean that I would differeciate between "a layman can break it with a laptop in hours" and "institutional organizations can brak it in weeks with M$ costing hw" | 12:55 |
| cjwatson | I believe it's probably still closer to the latter | 12:59 |
| bzoltan_ | cjwatson: thanks | 13:02 |
| cjwatson | in 2003 RSA Labs were recommending a minimum RSA key size of 1024 bits for applications that needed to be secure until 2010, and larger key sizes beyond that | 13:04 |
| === alan_g is now known as alan_g|lunch | ||
| cjwatson | bzoltan_: NIST SP 800-131A recommendation from 2011 said for RSA 1024-bit keys: "acceptable through 2010, deprecated from 2011 through 2013, disallowed after 2013" - so if anything ssh has been quite generous here | 13:07 |
| cjwatson | given that it still accepts 1024-bit | 13:07 |
| bzoltan_ | cjwatson: sounds fair. I have read somewhere that the encription time is like 10x higher with duble length key. Do you think it could be an issue? | 13:07 |
| cjwatson | current recommendations are http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf | 13:07 |
| cjwatson | bzoltan_: I find it pretty hard to believe that even phone hardware would have a problem with 1024-bit keys, but profile before guesswork | 13:08 |
| cjwatson | bzoltan_: note that RSA is used for authentication, but faster ciphers are used for bulk transport once the session has been established | 13:09 |
| bzoltan_ | cjwatson: that sounds logical | 13:14 |
| cjwatson | bzoltan_: (my crypto friends reckon a back-of-the-envelope estimate of about a thousand pounds to break 768-bit RSA at the moment) | 13:21 |
| bzoltan_ | cjwatson: shit :) that is not much | 13:23 |
| cjwatson | that's the friend who has a shed full of computers where he does recreational number theory | 13:24 |
| cjwatson | so I'd be inclined to trust his estimates on this, if not entirely on sensible things to spend one's money on :-) | 13:24 |
| bzoltan_ | :D | 13:27 |
| === Ursinha_ is now known as Ursinha | ||
| sil2100 | robru, jibel, davmor2, rvr, ToyKeeper, Mirv: sorry for the google calendar spam, google had some issues when I tried re-organizing the landing meetings | 14:13 |
| rvr | sil2100: No problem | 14:13 |
| davmor2 | sil2100: I'll give you spam in a minute, throw at speed and left in the tin ;) | 14:14 |
| davmor2 | thrown even | 14:14 |
| === marcusto_ is now known as marcustomlinson_ | ||
| === marcustomlinson_ is now known as marcustomlinson | ||
| popey | pmcgowan, heya, https://bugs.launchpad.net/music-app/+bug/1518764 is currently targetted to OTA-9, any chance we can get it in for OTA-8.5? Music app (due to qtmir bug) can cause really bad battery drain. | 14:46 |
| ubot5 | Ubuntu bug 1518764 in unity8 (Ubuntu) "Music app high power consumption when paused" [High,Triaged] | 14:46 |
| pmcgowan | popey, ok with me, does it have the new playlist stuff since it looks like that has to land | 14:47 |
| popey | pmcgowan, this is separate from the playlist stuff. | 14:48 |
| pmcgowan | popey, I know but the underlying support is landing in 8.5 | 14:48 |
| pmcgowan | so we could get that early maybe, but not required | 14:49 |
| popey | pmcgowan, just asked ahayzen and he's discussing with jhodapp AIUI | 14:50 |
| popey | still an outstanding issue. | 14:50 |
| pmcgowan | ok | 14:50 |
| popey | seems two blockers right now, which the guys are discussing | 14:54 |
| popey | so we may or may not have bg playlists ready by ota-8.5, but can at least try. | 14:54 |
| === pat_ is now known as Guest71267 | ||
| === Guest71267 is now known as pmcgowan | ||
| jhodapp | popey, pmcgowan yeah I made ahayzen aware that as soon as the hotfix lands they could release the new music-app with bgplaylist support any time they're ready after that | 14:56 |
| pmcgowan | popey, there is no fix for that issue yet it seems | 14:56 |
| pmcgowan | jhodapp, ok | 14:57 |
| ahayzen | jhodapp, i think there are at least two issues that need fixing first though? | 14:57 |
| popey | pmcgowan, the qtmir one? mzanetti mentioned earlier he's tasking someone on it. | 14:57 |
| jhodapp | ahayzen, in the backend part or you mean in music-app? | 14:57 |
| ahayzen | jhodapp, the removeItems() thing (breaking multiselect delete)... and the trackClicked issue when selecting the same index i still need to investigate if it is us or you | 14:57 |
| ahayzen | jhodapp, backend | 14:57 |
| ahayzen | jhodapp, bug 1518152 | 14:58 |
| ubot5 | bug 1518152 in qtubuntu-media (Ubuntu RTM) "removeItem is slow and causes issues due to async, therefore requesting removeItems(list)" [High,Triaged] https://launchpad.net/bugs/1518152 | 14:58 |
| pmcgowan | popey, need a fix quick to make the ota | 14:58 |
| jhodapp | ahayzen, yeah I knew you were looking into the trackClicked stuff and let me know if you end up thinking it's a backend issue as soon as you can | 14:58 |
| ahayzen | jhodapp, will do :-) | 14:59 |
| === alan_g|lunch is now known as alan_g | ||
| jhodapp | ahayzen, and yes we'll add the small patch to qtmultimedia for removeItems()...let me know when you're ready with the other parts and a code review and I'll add the patch to a silo | 14:59 |
| ahayzen | jhodapp, coolio :-) | 15:00 |
| davidbarth | jibel: hey; new tested silos on their way to you guys; with accepted merge proposals, for a change ;) | 15:17 |
| === barry` is now known as barry_ | ||
| Mirv | sil2100: robru: ooookayy after a really long day I have upstream fixes for two KDE (kwin, marble) Qt 5.5 autopkgtests regressions. after those are done everything should migrate, so please currently don't accept any new landings to be published that conflict with the Qt landing's packages since it should/could be all done within a couple of hours or so. | 15:56 |
| Mirv | sil2100: robru: Qt 5.5 landings silos are currently 012, 059, 008 and 035. sorry :D | 16:01 |
| sil2100 | Mirv: \o/ ACK | 16:01 |
| sil2100 | Wow, that's a lot of silos | 16:01 |
| sil2100 | ;) | 16:01 |
| awe | tvoss, have you had a chance to discuss the hotfix with sil2100? | 16:25 |
| tvoss | awe, yup, left comment on silo, silo is good as is | 16:25 |
| awe | ok, also discussed with davmor2 this morning. When QA tests the silo, they should do so with rc-proposed. Then when the hot-fix is staged, the two extra packages from the overlay PPA will also need to be copied | 16:27 |
| Saviq | cihelp, hey, any chance you could tell us what plugins are installed on s-jenkins so we can bootstrap our Jenkaas request? | 16:27 |
| awe | also, should we defer landing silo-013 till silo-26 lands and the hotfix staged? | 16:27 |
| awe | tvoss, ^^ | 16:29 |
| tvoss | awe, hence the reminder to sil on the silo :) | 16:30 |
| tvoss | awe, +1 on holding back 13 | 16:30 |
| tvoss | awe, that's the reason it still says qa required | 16:30 |
| tvoss | awe, much like 47 | 16:31 |
| awe | thanks tvoss | 16:31 |
| tvoss | awe, with that, we should be good to hand to qa | 16:31 |
| awe | +1 | 16:31 |
| tvoss | awe, I'm grabbing dinner | 16:31 |
| tvoss | back later | 16:31 |
| awe | k | 16:31 |
| awe | tvoss, I updated silo-013 to 'Ready for QA' | 16:37 |
| psivaa | Saviq: http://paste.ubuntu.com/13647332/ is the list, but please note that all of the plugins may not be needed for all the requirements. | 16:43 |
| Saviq | psivaa, of course, thanks | 16:43 |
| psivaa | Saviq: https://wiki.canonical.com/InformationInfrastructure/Jenkaas/UserDocs contains information about the need of IS involvement and best practices regarding that | 16:43 |
| Saviq | psivaa, yeah, just going through that, but there's no list of "interesting" plugins there unfortunately | 16:44 |
| Saviq | psivaa, btw, care to join #jenkaas on irc.c.c? | 16:44 |
| dobey | hmm | 17:19 |
| * dobey wonders how long until qt 5.5 makes it into xenial archive | 17:21 | |
| bfiller | sil2100: silo 48 is in xenial proposed.. can you tell if its' stuck? and if so can we force merge | 17:27 |
| === alan_g is now known as alan_g|EOD | ||
| tvoss | awe, but we are holding it back, right? | 18:58 |
| tvoss | awe, @silo 13 | 18:58 |
| awe | tvoss, silo-13? yes, we're holding it back | 19:01 |
| awe | I updated silo-26 | 19:01 |
| awe | ( hope that wasn't incorrect ) | 19:01 |
| awe | as it was still 'QA Required', and I thought we'd all ack'd it | 19:01 |
| salem_ | trainguards: I am getting "No space left on device" on silo 52, is this a known issue? | 19:08 |
| mzanetti | trainguards: seems we're out of space: https://ci-train.ubuntu.com/job/ubuntu-landing-001-1-build/10/console | 19:08 |
| mzanetti | heh | 19:08 |
| robru | It is now | 19:09 |
| robru | One sec guys | 19:09 |
| robru | huh that's weird, it says 1.3GB available | 19:11 |
| mzanetti | hmm... had 2 runs in a row with this error | 19:11 |
| robru | mzanetti: ok I just freed up a little bit more, try again | 19:12 |
| boiko | robru: same thing (no space left) on silo 52, should I try rebuilding? | 19:16 |
| robru | boiko: hang on a sec let's see if mzanetti's works first. could be that there's enough disk space for one but not both | 19:16 |
| boiko | robru: yep, ok | 19:17 |
| salem_ | robru, sorry, I just triggered a rebuild, want me to cancel? | 19:17 |
| robru | salem_: nah let's see what happens | 19:17 |
| salem_ | robru, ok | 19:18 |
| robru | 1G free still... | 19:20 |
| robru | 1.4G | 19:20 |
| mzanetti | mine did go further than before... but will still be a while until it's done (unity8) | 19:21 |
| mterry | mzanetti, stop hogging all the space, some of us have silos to build! ;) | 19:24 |
| mterry | mzanetti, just saw that mine failed for same reason. let me know when yours is done | 19:24 |
| mzanetti | mterry, I'm building dednick's one... it's not even for me :D | 19:25 |
| robru | hmm 700M | 19:25 |
| mterry | heh | 19:25 |
| mzanetti | success! | 19:25 |
| mzanetti | at least they're uploaded to the ppa now | 19:25 |
| robru | oh god 500M u guise | 19:25 |
| robru | oh 1.8G now, nice | 19:25 |
| mzanetti | that makes 1.3G per unity8 build I guess | 19:26 |
| robru | turns out 10GB disk isn't big enough to fit pbuilders for all supported ubuntu releases, whodathunkit? | 19:26 |
| boiko | robru: what is this diff missing state? | 19:36 |
| boiko | robru: nevermind, the state changed to preparing packages :) | 19:37 |
| ChrisTownsend | robru: There is a new version of fakechroot in Xenial that we need in Overlay. What is the best way to get it in there? | 19:38 |
| ChrisTownsend | robru: Or maybe Vivid SRU? Not sure about that though. | 19:39 |
| tvoss | awe, ah, because you said: you set silo 13 to ready for qa:) | 19:45 |
| awe | tvoss, sorry for the confusion; I thought I typed 26, but it's long gone in the scrollback | 19:46 |
| awe | ;/ | 19:46 |
| tvoss | awe, admittedly, 13 * 2 = 26 | 19:47 |
| awe | haha | 19:48 |
| ssweeny | that's just science | 19:48 |
| awe | no scott | 19:48 |
| awe | it's math | 19:48 |
| awe | ;D | 19:48 |
| awe | tvoss, sorry to be the bearer of bad news, however I just noticed that the versions of the Qt base packages were never changed to strip the "~testX" version suffixes | 19:55 |
| awe | in silo-26 | 19:55 |
| awe | ;(- | 19:56 |
| tvoss | ffs | 19:56 |
| awe | Mirv mentioned needed to change this at some point once we blessed the changes to Qt | 19:56 |
| tvoss | Mirv, you around? | 19:56 |
| awe | but it apparently didn't get done | 19:56 |
| * tvoss crosses fingers | 19:56 | |
| * awe sighs | 19:57 | |
| awe | so close... | 19:57 |
| robru | ChrisTownsend: do you need it only on phones or do you need it on vivid desktops too? | 19:58 |
| Saviq | tvoss, unlikely for Mirv to be here (he's in Helsinki on a SDK sprint), but any of the trainguards should be able to help if it's just a matter of fixing the version number | 19:59 |
| awe | Saviq, pretty sure qtbase is not under CI, and has to be manually dput to a silo | 20:00 |
| tvoss | right, what awe said. It's a little more involved as I understand it | 20:00 |
| Saviq | awe, sure, but it's there already | 20:00 |
| Saviq | awe, so just a download, modify version, upload, any trainguard can do :) | 20:00 |
| robru | awe: tvoss: Saviq: i have dput powers, just tell me exactly what you need (what package/ppa) | 20:00 |
| awe | ok; that's some voodoo I've never done | 20:01 |
| awe | cool | 20:01 |
| awe | https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-026 | 20:01 |
| tvoss | robru, what saviq said ^ | 20:01 |
| awe | the "~testX" versions suffixes need to be removed from | 20:01 |
| awe | qtbase-opensource-src | 20:01 |
| robru | OK gimme a minute | 20:02 |
| awe | and qtbase-opensource-src-gles | 20:02 |
| awe | np | 20:02 |
| awe | and robru, I think earlier problem I saw was related to my network dropping out | 20:02 |
| ChrisTownsend | robru: Really, only for phones, but for me, I have the overlay enabled on a Vivid desktop system for development. | 20:02 |
| awe | ChrisTownsend, brave man | 20:02 |
| robru | ChrisTownsend: then overlay is fine | 20:03 |
| ChrisTownsend | awe: lol, that's how I roll;-) | 20:03 |
| awe | just don't report any ofono bugs please | 20:03 |
| robru | ChrisTownsend: you can do sync silo to copy the xenial version to vivid. i can help you with that in a minute, just doing this qt thing first | 20:03 |
| ChrisTownsend | awe: No need to make calls on my laptop, so I think I'm good. | 20:03 |
| ChrisTownsend | robru: Cool, thanks | 20:03 |
| robru | awe: tvoss: Saviq: so just to confirm, you guys want the version number to be "5.4.1+dfsg-2ubuntu11~vivid1" | 20:04 |
| robru | (just drop the 'test' part and not change anything else) | 20:04 |
| Saviq | robru, yup | 20:04 |
| tvoss | hah, gotta love the random ICEs that gcc5 is producing | 20:07 |
| ogra_ | tvoss, its a feature ... "added developer entertainment" | 20:10 |
| tvoss | yeah, like don't get used to stuff just working, care for us | 20:10 |
| tvoss | it's a bit like a tamagotchi, occasionally, you have to call the ninja twice | 20:10 |
| ogra_ | heh | 20:11 |
| robru | awe: tvoss: Saviq: ok uploaded, will take some time to build | 20:15 |
| awe | yes, it will | 20:15 |
| awe | ;D | 20:15 |
| awe | thanks much robru! | 20:15 |
| robru | awe: you're welcome | 20:15 |
| robru | ChrisTownsend: ok, you ever done a sync silo before? | 20:16 |
| ChrisTownsend | robru: Nope | 20:16 |
| tvoss | thanks a lot robru | 20:16 |
| robru | ChrisTownsend: ok I'll set it up. there's some magic | 20:16 |
| robru | tvoss: you're welcome! | 20:16 |
| ChrisTownsend | robru: Ok, thanks! | 20:16 |
| robru | ChrisTownsend: actually I just realized a sync won't work automatically, I'll have to manually prepare the package, one sec. | 20:20 |
| robru | ChrisTownsend: https://requests.ci-train.ubuntu.com/#/ticket/745 ok here's the request, I just uploaded the package to ppa 6. the bot should ping when the build completes, then you can test on your device that it does what you need. | 20:23 |
| ChrisTownsend | robru: Ok, thank you very much! | 20:23 |
| robru | ChrisTownsend: you're welcome! | 20:24 |
| robru | ChrisTownsend: ^ ok that's ready for testing | 21:03 |
| ChrisTownsend | robru: Yep, testing it now. | 21:04 |
| robru | ChrisTownsend: also here's the diff between what's in the silo and what's in vivid currently: https://ci-train.ubuntu.com/job/ubuntu-landing-006-1-build/lastSuccessfulBuild/artifact/fakechroot_vivid_content.diff/*view*/ maybe give that a look over and make sure it's what you expect | 21:05 |
| ChrisTownsend | robru: It's a pretty large diff, so I'm guessing it's what I expect, but I can tell you the diff definitely has the fix I'm looking for:) | 21:07 |
| ChrisTownsend | robru: Also, I have confirmed the package does fix the issue in practice as well. | 21:07 |
| robru | ChrisTownsend: great, so just mark the request 'ready for qa' and they can confirm it doesn't make the phones explode, then we can get a core dev to release it | 21:08 |
| ChrisTownsend | robru: Ok, will do. | 21:08 |
| robru | ChrisTownsend: oh, also, please fill out the test plan with steps that qa people can take to confirm that this change doesn't break anything (indicate affected phone bits, etc) | 21:08 |
| ChrisTownsend | robru: Well, that package is not included by default in any normal phone image, only in the PD image. | 21:09 |
| robru | ChrisTownsend: pd? | 21:10 |
| ChrisTownsend | robru: ubuntu-pd, ie, pocket desktop | 21:10 |
| robru | ChrisTownsend: oh well if it's not in phone images then i guess it doesn't need qa | 21:12 |
| robru | ChrisTownsend: pd is just experimental right? like it hasn't shipped to any customers yet? | 21:13 |
| ChrisTownsend | robru: Yes, it's still only experimental. | 21:13 |
| robru | ChrisTownsend: ok, I don't think we need qa then. you confirmed the fix is working for you? | 21:13 |
| ChrisTownsend | robru: Yes, confirmed it's all good and doesn't break any other functionality that I need. | 21:14 |
| robru | ChrisTownsend: ok I'll copy it to the overlay, one sec | 21:14 |
| ChrisTownsend | robru: Thanks | 21:14 |
| robru | ChrisTownsend: you're welcome | 21:14 |
| ChrisTownsend | robru: Also, silo 044 is ready to be published and I don't have permission to do so, I'm guessing because of package changes. I need a motu to ack, right? | 21:15 |
| ChrisTownsend | I say motu because it's in universe. | 21:15 |
| robru | ChrisTownsend: assuming all packages are in universe, you need a motu, yeah | 21:16 |
| ChrisTownsend | robru: Ok, just making sure, thanks again | 21:16 |
| robru | ChrisTownsend: don't know any motus in this tz, usually kenvandine or mterry are my go-to core devs for publishing | 21:16 |
| robru | ChrisTownsend: you're welcome | 21:16 |
| ChrisTownsend | robru: Well, I imagine a core dev can ack as well:) | 21:17 |
| robru | yes | 21:17 |
| * kenvandine waves | 21:17 | |
| ChrisTownsend | kenvandine: :) | 21:18 |
| ChrisTownsend | kenvandine: You care to ack silo 044 for me? | 21:18 |
| * robru --> lucnh | 21:18 | |
| ChrisTownsend | kenvandine: Thanks! | 21:22 |
| kenvandine | ChrisTownsend, np | 21:22 |
| === salem_ is now known as _salem | ||
| Saviq | bregma, hey, I've a weird status in https://requests.ci-train.ubuntu.com/#/ticket/29 - unity8/xenial says it needs rebuild because of new commits... but why wouldn't it say that for unity8/vivid, too? | 21:33 |
| Saviq | bregma, and I've no idea why I pung you about it ;P | 21:34 |
| Saviq | robru, ↑↑ | 21:34 |
| Saviq | or well, I have an idea, been thinking about you :P | 21:34 |
| bregma | :) | 21:34 |
| Saviq | robru, this looks real weird https://ci-train.ubuntu.com/job/ubuntu-landing-004-0-status/163/console | 21:57 |
| robru | Saviq: when that happens you can run the job with 'debug' enabled to see the raw 'bzr missing' data that it used to come to that conclusion | 21:58 |
| robru | Saviq: actually I've been noticing some buggy bzr missing results, could be a transient failure | 21:58 |
| * Saviq does | 21:59 | |
| robru | Saviq: the part about not saying new commits for vivid isn't weird, it's because vivid isn't built from cmmits, vivid is built by munging the xenial build, so when it checks for new commits it only knows about xenial's commits | 21:59 |
| Saviq | robru, ack | 21:59 |
| === _salem is now known as salem_ | ||
| robru | Saviq: oh you ran build with debug, I mean to run status with debug. | 22:02 |
| Saviq | robru, right, will stop | 22:02 |
| robru | Saviq: wait | 22:02 |
| robru | Saviq: it has the same info ;-) | 22:02 |
| Saviq | yeah I know | 22:02 |
| robru | at least for bzr missing | 22:02 |
| Saviq | robru, it just goes "You have 19 extra revisions:" and then "ERROR New commits:" | 22:03 |
| robru | Saviq: looking | 22:03 |
| Saviq | looks wrong IMO | 22:03 |
| robru | Saviq: hmmmm | 22:04 |
| robru | Saviq: it's because of timo's direct trunk commit | 22:04 |
| robru | Saviq: train isn't expecting that and it's not in any of your branches so the train thinks it's a commit you've deleted from your branches. | 22:04 |
| robru | Saviq: second time today I've seen this issue. the "fix" is to merge trunk into all your branches. let me think on it for a second, maybe I can make the train smarter... | 22:05 |
| Saviq | robru, LP commits translations periodically, so that's not really a solution | 22:06 |
| Saviq | which I imagine would result in the same situation? and if not - why? | 22:06 |
| robru | Saviq: no no it ignores lp translations commits. this issue is specifically because *timo* made a trunk commit | 22:06 |
| Saviq | robru, ok understood | 22:06 |
| robru | Saviq: so, wait. did you actually rebuild since timo's trunk commit? | 22:13 |
| Saviq | robru, yeah | 22:14 |
| Saviq | robru, rebuild's 1.5h ago, trunk commit was like 2 days ago | 22:14 |
| robru | slangasek: ^^ yeah I don't understand this, he says he rebuilt since the trunk commit | 22:14 |
| Saviq | there's even a translations commit from yesterday on top of it | 22:15 |
| dobey | huh | 22:16 |
| dobey | for unity8? | 22:16 |
| slangasek | robru: when someone does a rebuild, what do you do on the bzr side wrt the silo branch in lp that's being landed? | 22:16 |
| robru | slangasek: first build and rebuilds are the same: we branch trunk, merge the input branches into it, build it, upload to ppa, then push branch to lp. the previous branch is simply discarded (we push with --overwrite) | 22:18 |
| slangasek | ok | 22:18 |
| slangasek | then my guess was wrong ;) | 22:18 |
| dobey | the bzr --missing output is a bit weird | 22:22 |
| dobey | i can't tell what's going on there | 22:22 |
| robru | dobey: you mean like, in general, or you're finding something strange in this case? | 22:22 |
| robru | dobey: what's happening is that the silo has a dozen MPs, and we merge them all into one branch. so when it says "you have 20 extra revisions" it's talking about other branches we merged in. it's ignoring that correctly, but it's getting caught up on a trunk commit that isn't merged into any of the branches htough | 22:23 |
| dobey | robru: maybe i'm reading it wrong, but somehow it looks like it's complaining about commits in the temporary branch missing from trunk | 22:23 |
| dobey | it shouldn't care if there are commits to trunk that aren't in those branches though | 22:24 |
| dobey | as long as the branches can be merged into trunk, all is fine | 22:24 |
| robru | dobey: yeah you're reading it wrong, it's only comparing the train's merged branch against the trunk branch and input branches, looking for new commits that haven't been built. | 22:26 |
| dobey | but why does it care? | 22:27 |
| dobey | granted, there is *way* too much going on in that log | 22:28 |
| robru | dobey: it cares because it's trying to inform you if you need to rebuild your silo or not. In this case it's got a false positive caused by a non-train trunk commit | 22:30 |
| dobey | i don't think that's the cause | 22:30 |
| dobey | at least it shouldn't be. i've done non-train trunk commits and never hit this issue before | 22:30 |
| dobey | ie, never saw this during all the gcc5 insanity | 22:31 |
| robru | dobey: this code changed recently from "just record tip commit id" to "parse bzr missing output" and so far it's been great as long as you don't do non-train commits to trunk ;-) | 22:35 |
| dobey | well even if train does the commits, shouldn't it also fail if train commiets something, and i try to make a silo from another branch that was branched from trunk prior to that commit? | 22:36 |
| dobey | are you doiong "bzr missing" before committing to the temp train branch? | 22:37 |
| robru | Saviq: are you in a hurry to land this silo? steve and I have a plan but it may take me some time to implement properly. | 22:42 |
| dobey | well, qt 5.5 still going nowhere i guess, which blocks my other silo from getting through to release pocket, and blocks me from getting my new silo rebuilt | 22:44 |
| Saviq | robru, not before tomorrow, no | 22:44 |
| dobey | so i'm off | 22:45 |
| === salem_ is now known as _salem | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!