/srv/irclogs.ubuntu.com/2015/12/03/#ubuntu-ci-eng.txt

=== _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
morphisMirv, robru: anyone time for an upload?08:21
Mirvmorphis: sure08: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
Trevinhorobru: 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_
rvrElleo: ping11:14
Elleorvr: pong?11:25
rvrElleo: Hi11:25
rvrElleo: There is a failing autopilot test in silo 2 (keyboard)11:25
rvrElleo: https://trello.com/c/O6WgMzXS/2534-712-ubuntu-landing-002-ubuntu-keyboard-michael-sheldon11:25
Elleorvr: ah, hadn't spotted that, wasn't failing when I ran the tests locally :/11:25
Elleomight be flaky will see if I can reproduce it11:25
rvrElleo: Ok11:25
bzoltan_sil2100: ping12: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
sil2100bzoltan_: pong12:15
sil2100bzoltan_: oh! hm, do you know which package upload caused that?12:16
sil2100Was that a security update, or an overlay landing?12:16
bzoltan_sil2100: i assume it was the openssh-server12:16
Elleorvr: haven't been able to reproduce this locally at all, after rerunning that test a couple of dozen times on a krillin :/12:17
sil2100bzoltan_: I'm asking since I didn't see any offending change in the latest openssh for vivid, but let me dig deeper12:17
Elleorvr: 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 day12:18
bzoltan_sil2100: afaik there is no ssh server in the Overlay PPA12:18
Mirvbzoltan_: sil2100: right it doesn't say anything at https://launchpad.net/ubuntu/vivid/+source/openssh/+changelog12:18
rvrElleo: Ok12:18
rvrElleo: Maybe some race condition12:18
sil2100It might have been the previous one, but I don't see much related things in the changelog there too12:19
bzoltan_Mirv: sil2100: silly me, it was on the rc-poposed image12:19
Elleorvr: maybe, the krillins are a bit slower than the makos which might be why it hasn't triggered in jenkins before12:19
Elleorvr: but haven't been able to hit it on my krillin yet12:19
bzoltan_sil2100:  it happened with kaleo's device what he flashed with rc-proposed12:21
sil2100bzoltan_: could you guys try to bisect with which rc-proposed image it started being like that? We could then check which upload is guilty12:23
sil2100Since openssh was updated last 1.5 month ago12:23
bzoltan_sil2100:  the 1:6.7p1-5ubuntu1.3 does 1024 key length12:28
sil2100http://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 issues12:29
cjwatsonbzoltan_: ssh -vvv output would be helpful I'm sure12:29
cjwatsonbecause I'm the openssh maintainer and I can't parse your complaint about it12:30
cjwatsoncertainly no vivid update has intentionally changed any key length policy12:30
cjwatsonbut you may be misconstruing the problem in some way, so debug output12: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/changelog12:32
cjwatsonbzoltan_: what version of openssh-client is on the desktop system in question?12:32
bzoltan_cjwatson: 1:7.1p1-112:34
cjwatsonbzoltan_: this is a client-side problem, not a server-side problem12:34
cjwatsonbzoltan_: and relates to an upgrade in xenial, not in vivid12:34
bzoltan_cjwatson: good to hear :)12:34
cjwatsonbzoltan_: just change ./share/qtcreator/ubuntu/scripts/openssh_publickey to use -b 1024 rather than -b 76812:34
cjwatsonI'm not going to back this out, 768 bits is ridiculously short12: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
cjwatsonbzoltan_: uh, this error comes from ssh-keygen, while generating keys12:37
cjwatsonbzoltan_: before you invent problems maybe check that they are actually problems :)12:37
zbenjamincjwatson: so the existing keys will continue to work?12:39
cjwatsonthough let's see, just checking12:39
cjwatsonhttps://anongit.mindrot.org/openssh.git/commit/?id=933935ce was the commit in question12:40
cjwatsonI cannot guarantee that ssh will in general continue to accept insecurely short host keys12:40
cjwatsonit would be negligent to do so12:40
cjwatsonhttp://www.openssh.com/txt/release-7.0 makes it clear that they will refuse such keys in future12:40
cjwatsonzbenjamin: 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 case12:44
zbenjamincjwatson: ok thanks , we will figure something out12:44
cjwatsonsince you're generating the key on the client, I highly doubt that there's a substantial performance justification for going with extremely weak keys12: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
cjwatsonbzoltan_: 768-bit RSA keys are completely insecure and broken12:52
cjwatsonbzoltan_: 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 security12: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
cjwatsonbzoltan_: I don't recall the current figures, it's not something I keep track of12:54
cjwatsonbut 768-bit RSA was first factored in 2010 or so, and this sort of thing tends to be exponential12: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
cjwatsonI believe it's probably still closer to the latter12:59
bzoltan_cjwatson: thanks13:02
cjwatsonin 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 that13:04
=== alan_g is now known as alan_g|lunch
cjwatsonbzoltan_: 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 here13:07
cjwatsongiven that it still accepts 1024-bit13: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
cjwatsoncurrent recommendations are http://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-131Ar1.pdf13:07
cjwatsonbzoltan_: I find it pretty hard to believe that even phone hardware would have a problem with 1024-bit keys, but profile before guesswork13:08
cjwatsonbzoltan_: note that RSA is used for authentication, but faster ciphers are used for bulk transport once the session has been established13:09
bzoltan_cjwatson:  that sounds logical13:14
cjwatsonbzoltan_: (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 much13:23
cjwatsonthat's the friend who has a shed full of computers where he does recreational number theory13:24
cjwatsonso 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_:D13:27
=== Ursinha_ is now known as Ursinha
sil2100robru, jibel, davmor2, rvr, ToyKeeper, Mirv: sorry for the google calendar spam, google had some issues when I tried re-organizing the landing meetings14:13
rvrsil2100: No problem14:13
davmor2sil2100: I'll give you spam in a minute, throw at speed and left in the tin ;)14:14
davmor2thrown even14:14
=== marcusto_ is now known as marcustomlinson_
=== marcustomlinson_ is now known as marcustomlinson
popeypmcgowan, 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
ubot5Ubuntu bug 1518764 in unity8 (Ubuntu) "Music app high power consumption when paused" [High,Triaged]14:46
pmcgowanpopey, ok with me, does it have the new playlist stuff since it looks like that has to land14:47
popeypmcgowan, this is separate from the playlist stuff.14:48
pmcgowanpopey, I know but the underlying support is landing in 8.514:48
pmcgowanso we could get that early maybe, but not required14:49
popeypmcgowan, just asked ahayzen and he's discussing with jhodapp AIUI14:50
popeystill an outstanding issue.14:50
pmcgowanok14:50
popeyseems two blockers right now, which the guys are discussing14:54
popeyso 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
jhodapppopey, 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 that14:56
pmcgowanpopey, there is no fix for that issue yet it seems14:56
pmcgowanjhodapp, ok14:57
ahayzenjhodapp, i think there are at least two issues that need fixing first though?14:57
popeypmcgowan, the qtmir one? mzanetti mentioned earlier he's tasking someone on it.14:57
jhodappahayzen, in the backend part or you mean in music-app?14:57
ahayzenjhodapp, 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 you14:57
ahayzenjhodapp, backend14:57
ahayzenjhodapp, bug 151815214:58
ubot5bug 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/151815214:58
pmcgowanpopey, need a fix quick to make the ota14:58
jhodappahayzen, 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 can14:58
ahayzenjhodapp, will do :-)14:59
=== alan_g|lunch is now known as alan_g
jhodappahayzen, 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 silo14:59
ahayzenjhodapp, coolio :-)15:00
davidbarthjibel: 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_
Mirvsil2100: 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
Mirvsil2100: robru: Qt 5.5 landings silos are currently 012, 059, 008 and 035. sorry :D16:01
sil2100Mirv: \o/ ACK16:01
sil2100Wow, that's a lot of silos16:01
sil2100;)16:01
awetvoss, have you had a chance to discuss the hotfix with sil2100?16:25
tvossawe, yup, left comment on silo, silo is good as is16:25
aweok, 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 copied16:27
Saviqcihelp, hey, any chance you could tell us what plugins are installed on s-jenkins so we can bootstrap our Jenkaas request?16:27
awealso, should we defer landing silo-013 till silo-26 lands and the hotfix staged?16:27
awetvoss, ^^16:29
tvossawe, hence the reminder to sil on the silo :)16:30
tvossawe, +1 on holding back 1316:30
tvossawe, that's the reason it still says qa required16:30
tvossawe, much like 4716:31
awethanks tvoss16:31
tvossawe, with that, we should be good to hand to qa16:31
awe+116:31
tvossawe, I'm grabbing dinner16:31
tvossback later16:31
awek16:31
awetvoss, I updated silo-013 to 'Ready for QA'16:37
psivaaSaviq: 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
Saviqpsivaa, of course, thanks16:43
psivaaSaviq: https://wiki.canonical.com/InformationInfrastructure/Jenkaas/UserDocs contains information about the need of IS involvement and best practices regarding that16:43
Saviqpsivaa, yeah, just going through that, but there's no list of "interesting" plugins there unfortunately16:44
Saviqpsivaa, btw, care to join #jenkaas on irc.c.c?16:44
dobeyhmm17:19
* dobey wonders how long until qt 5.5 makes it into xenial archive17:21
bfillersil2100: silo 48 is in xenial proposed.. can you tell if its' stuck? and if so can we force merge17:27
=== alan_g is now known as alan_g|EOD
tvossawe, but we are holding it back, right?18:58
tvossawe, @silo 1318:58
awetvoss, silo-13?  yes, we're holding it back19:01
aweI updated silo-2619:01
awe( hope that wasn't incorrect )19:01
aweas it was still 'QA Required', and I thought we'd all ack'd it19:01
salem_trainguards: I am getting  "No space left on device" on silo 52, is this a known issue?19:08
mzanettitrainguards: seems we're out of space: https://ci-train.ubuntu.com/job/ubuntu-landing-001-1-build/10/console19:08
mzanettiheh19:08
robruIt is now19:09
robruOne sec guys19:09
robruhuh that's weird, it says 1.3GB available19:11
mzanettihmm... had 2 runs in a row with this error19:11
robrumzanetti: ok I just freed up a little bit more, try again19:12
boikorobru: same thing (no space left) on silo 52, should I try rebuilding?19:16
robruboiko: hang on a sec let's see if mzanetti's works first. could be that there's enough disk space for one but not both19:16
boikorobru: yep, ok19:17
salem_robru, sorry, I just triggered a rebuild, want me to cancel?19:17
robrusalem_: nah let's see what happens19:17
salem_robru, ok19:18
robru1G free still...19:20
robru1.4G19:20
mzanettimine did go further than before... but will still be a while until it's done (unity8)19:21
mterrymzanetti, stop hogging all the space, some of us have silos to build!  ;)19:24
mterrymzanetti, just saw that mine failed for same reason.  let me know when yours is done19:24
mzanettimterry, I'm building dednick's one... it's not even for me :D19:25
robruhmm 700M19:25
mterryheh19:25
mzanettisuccess!19:25
mzanettiat least they're uploaded to the ppa now19:25
robruoh god 500M u guise19:25
robruoh 1.8G now, nice19:25
mzanettithat makes 1.3G per unity8 build I guess19:26
robruturns out 10GB disk isn't big enough to fit pbuilders for all supported ubuntu releases, whodathunkit?19:26
boikorobru: what is this diff missing state?19:36
boikorobru: nevermind, the state changed to preparing packages :)19:37
ChrisTownsendrobru: 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
ChrisTownsendrobru: Or maybe Vivid SRU?  Not sure about that though.19:39
tvossawe, ah, because you said: you set silo 13 to ready for qa:)19:45
awetvoss, sorry for the confusion; I thought I typed 26, but it's long gone in the scrollback19:46
awe;/19:46
tvossawe, admittedly, 13 * 2 = 2619:47
awehaha19:48
ssweenythat's just science19:48
aweno scott19:48
aweit's math19:48
awe;D19:48
awetvoss, 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 suffixes19:55
awein silo-2619:55
awe;(-19:56
tvossffs19:56
aweMirv mentioned needed to change this at some point once we blessed the changes to Qt19:56
tvossMirv, you around?19:56
awebut it apparently didn't get done19:56
* tvoss crosses fingers19:56
* awe sighs19:57
aweso close...19:57
robruChrisTownsend: do you need it only on phones or do you need it on vivid desktops too?19:58
Saviqtvoss, 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 number19:59
aweSaviq, pretty sure qtbase is not under CI, and has to be manually dput to a silo20:00
tvossright, what awe said. It's a little more involved as I understand it20:00
Saviqawe, sure, but it's there already20:00
Saviqawe, so just a download, modify version, upload, any trainguard can do :)20:00
robruawe: tvoss: Saviq: i have dput powers, just tell me exactly what you need (what package/ppa)20:00
aweok; that's some voodoo I've never done20:01
awecool20:01
awehttps://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-02620:01
tvossrobru, what saviq said ^20:01
awethe "~testX" versions suffixes need to be removed from20:01
awe qtbase-opensource-src20:01
robruOK gimme a minute20:02
aweand qtbase-opensource-src-gles20:02
awenp20:02
aweand robru, I think earlier problem I saw was related to my network dropping out20:02
ChrisTownsendrobru: Really, only for phones, but for me, I have the overlay enabled on a Vivid desktop system for development.20:02
aweChrisTownsend, brave man20:02
robruChrisTownsend: then overlay is fine20:03
ChrisTownsendawe: lol, that's how I roll;-)20:03
awejust don't report any ofono bugs please20:03
robruChrisTownsend: 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 first20:03
ChrisTownsendawe: No need to make calls on my laptop, so I think I'm good.20:03
ChrisTownsendrobru: Cool, thanks20:03
robruawe: 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
Saviqrobru, yup20:04
tvosshah, gotta love the random ICEs that gcc5 is producing20:07
ogra_tvoss, its a feature ... "added developer entertainment"20:10
tvossyeah, like don't get used to stuff just working, care for us20:10
tvossit's a bit like a tamagotchi, occasionally, you have to call the ninja twice20:10
ogra_heh20:11
robruawe: tvoss: Saviq: ok uploaded, will take some time to build20:15
aweyes, it will20:15
awe;D20:15
awethanks much robru!20:15
robruawe: you're welcome20:15
robruChrisTownsend: ok, you ever done a sync silo before?20:16
ChrisTownsendrobru: Nope20:16
tvossthanks a lot robru20:16
robruChrisTownsend: ok I'll set it up. there's some magic20:16
robrutvoss: you're welcome!20:16
ChrisTownsendrobru: Ok, thanks!20:16
robruChrisTownsend: actually I just realized a sync won't work automatically, I'll have to manually prepare the package, one sec.20:20
robruChrisTownsend: 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
ChrisTownsendrobru: Ok, thank you very much!20:23
robruChrisTownsend: you're welcome!20:24
robruChrisTownsend: ^ ok that's ready for testing21:03
ChrisTownsendrobru: Yep, testing it now.21:04
robruChrisTownsend: 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 expect21:05
ChrisTownsendrobru: 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
ChrisTownsendrobru: Also, I have confirmed the package does fix the issue in practice as well.21:07
robruChrisTownsend: 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 it21:08
ChrisTownsendrobru: Ok, will do.21:08
robruChrisTownsend: 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
ChrisTownsendrobru: Well, that package is not included by default in any normal phone image, only in the PD image.21:09
robruChrisTownsend: pd?21:10
ChrisTownsendrobru: ubuntu-pd, ie, pocket desktop21:10
robruChrisTownsend: oh well if it's not in phone images then i guess it doesn't need qa21:12
robruChrisTownsend: pd is just experimental right? like it hasn't shipped to any customers yet?21:13
ChrisTownsendrobru: Yes, it's still only experimental.21:13
robruChrisTownsend: ok, I don't think we need qa then. you confirmed the fix is working for you?21:13
ChrisTownsendrobru: Yes, confirmed it's all good and doesn't break any other functionality that I need.21:14
robruChrisTownsend: ok I'll copy it to the overlay, one sec21:14
ChrisTownsendrobru: Thanks21:14
robruChrisTownsend: you're welcome21:14
ChrisTownsendrobru: 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
ChrisTownsendI say motu because it's in universe.21:15
robruChrisTownsend: assuming all packages are in universe, you need a motu, yeah21:16
ChrisTownsendrobru: Ok, just making sure, thanks again21:16
robruChrisTownsend:  don't know any motus in this tz, usually kenvandine or mterry are my go-to core devs for publishing21:16
robruChrisTownsend: you're welcome21:16
ChrisTownsendrobru: Well, I imagine a core dev can ack as well:)21:17
robruyes21:17
* kenvandine waves21:17
ChrisTownsendkenvandine: :)21:18
ChrisTownsendkenvandine: You care to ack silo 044 for me?21:18
* robru --> lucnh21:18
ChrisTownsendkenvandine: Thanks!21:22
kenvandineChrisTownsend, np21:22
=== salem_ is now known as _salem
Saviqbregma, 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
Saviqbregma, and I've no idea why I pung you about it ;P21:34
Saviqrobru, ↑↑21:34
Saviqor well, I have an idea, been thinking about you :P21:34
bregma:)21:34
Saviqrobru, this looks real weird https://ci-train.ubuntu.com/job/ubuntu-landing-004-0-status/163/console21:57
robruSaviq: 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 conclusion21:58
robruSaviq: actually I've been noticing some buggy bzr missing results, could be a transient failure21:58
* Saviq does21:59
robruSaviq: 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 commits21:59
Saviqrobru, ack21:59
=== _salem is now known as salem_
robruSaviq: oh you ran build with debug, I mean to run status with debug.22:02
Saviqrobru, right, will stop22:02
robruSaviq: wait22:02
robruSaviq: it has the same info ;-)22:02
Saviqyeah I know22:02
robruat least for bzr missing22:02
Saviqrobru, it just goes "You have 19 extra revisions:" and then "ERROR New commits:"22:03
robruSaviq: looking22:03
Saviqlooks wrong IMO22:03
robruSaviq: hmmmm22:04
robruSaviq: it's because of timo's direct trunk commit22:04
robruSaviq: 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
robruSaviq: 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
Saviqrobru, LP commits translations periodically, so that's not really a solution22:06
Saviqwhich I imagine would result in the same situation? and if not - why?22:06
robruSaviq: no no it ignores lp translations commits. this issue is specifically because *timo* made a trunk commit22:06
Saviqrobru, ok understood22:06
robruSaviq: so, wait. did you actually rebuild since timo's trunk commit?22:13
Saviqrobru, yeah22:14
Saviqrobru, rebuild's 1.5h ago, trunk commit was like 2 days ago22:14
robruslangasek: ^^ yeah I don't understand this, he says he rebuilt since the trunk commit22:14
Saviqthere's even a translations commit from yesterday on top of it22:15
dobeyhuh22:16
dobeyfor unity8?22:16
slangasekrobru: 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
robruslangasek: 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
slangasekok22:18
slangasekthen my guess was wrong ;)22:18
dobeythe bzr --missing output is a bit weird22:22
dobeyi can't tell what's going on there22:22
robrudobey: you mean like, in general, or you're finding something strange in this case?22:22
robrudobey: 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 htough22:23
dobeyrobru: maybe i'm reading it wrong, but somehow it looks like it's complaining about commits in the temporary branch missing from trunk22:23
dobeyit shouldn't care if there are commits to trunk that aren't in those branches though22:24
dobeyas long as the branches can be merged into trunk, all is fine22:24
robrudobey: 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
dobeybut why does it care?22:27
dobeygranted, there is *way* too much going on in that log22:28
robrudobey: 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 commit22:30
dobeyi don't think that's the cause22:30
dobeyat least it shouldn't be. i've done non-train trunk commits and never hit this issue before22:30
dobeyie, never saw this during all the gcc5 insanity22:31
robrudobey: 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
dobeywell 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
dobeyare you doiong "bzr missing" before committing to the temp train branch?22:37
robruSaviq: 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
dobeywell, 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 rebuilt22:44
Saviqrobru, not before tomorrow, no22:44
dobeyso i'm off22:45
=== salem_ is now known as _salem

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!