| robru | bfiller: please approve: https://code.launchpad.net/~michael-sheldon/ubuntu-keyboard/fix-1448019/+merge/257783 | 00:10 |
|---|---|---|
| bfiller | robru: done | 00:52 |
| bfiller | sorry about that | 00:53 |
| robru | bfiller: thanks | 00:53 |
| imgbot | === IMAGE 190 building (started: 20150505-02:05) === | 02:05 |
| imgbot | === IMAGE 190 DONE (finished: 20150505-03:40) === | 03:40 |
| imgbot | === changelog: http://people.canonical.com/~ogra/touch-image-stats/190.changes === | 03:40 |
| bzoltan | Mirv: it seems that the overlay PPA's QtC plugin is out of sync https://ci-train.ubuntu.com/job/ubuntu-landing-016-1-build/149/console | 04:20 |
| Mirv | bzoltan: there is no q-p-u in overlay, but you need to sync that ubuntu2 from archives to your trunk | 04:28 |
| bzoltan | Mirv: Ahh... of course. So we had a release to the archive what was not merged to the trunk... I see | 04:29 |
| bzoltan | sergiusens: would you mind to give me the patch you applied on the qtcreator-plugin-ubuntu and pushed to the archive? It would make easier to fix the trunk. | 04:37 |
| bzoltan | sergiusens: I see that you habe added a distro patch to the archive packge. It now blocks the CI process for the lp:qtcreator-plugin-ubuntu | 04:42 |
| oSoMoN | trainguards: good morning, can silo 3 be published, please? | 05:44 |
| Mirv | oSoMoN: sure, I'll just make sure it's configured to go to the overlay | 05:50 |
| Mirv | oh, this's the old silo, great :) | 05:50 |
| Mirv | pedronis: hi! regarding line 27 in the spreadsheet, what should be done about it, removing? the two MP:s listed there are 404 like I wrote in there 2 weeks ago. | 05:57 |
| Mirv | https://code.launchpad.net/~pedronis/account-polld/supp-sha384-512-certs/+merge/256477 + https://code.launchpad.net/~pedronis/ubuntu-push/automatic-into-vivid/+merge/256535 | 05:57 |
| oSoMoN | Mirv, thanks! | 06:09 |
| tvoss | good morning | 06:17 |
| Mirv | good morning tvoss | 06:25 |
| tvoss | Mirv, hey there :) | 06:26 |
| Mirv | fixing your "MP" to be MP instead of branch | 06:29 |
| pedronis | Mirv: yes, they can be removed | 07:10 |
| Mirv | pedronis: thanks | 07:34 |
| mzanetti | sil2100, hey there. Do you know whom I have to ping to grant permissions for silo building/landing to someone? | 08:41 |
| sil2100 | mzanetti: hey, I can add that person if anything | 08:43 |
| sil2100 | Is that person trained in the train? ( ;) ) | 08:44 |
| mzanetti | sil2100, I gave him a walkthrough, not sure if there's a requirement to get a walkthrough from you guys | 08:44 |
| mzanetti | sil2100, talking about tsdgeos (aacid on launchpad) here | 08:44 |
| sil2100 | Ah, sure, let me add him | 08:45 |
| mzanetti | perfect, thanks | 08:45 |
| mzanetti | I'll assist his first few landings | 08:45 |
| sil2100 | mzanetti: he should be now train-enabled | 08:46 |
| mzanetti | nice. thanks :) | 08:46 |
| sil2100 | yw ;) | 08:46 |
| alan_g | trainguards I'm working through the release process for Mir 0.13 and have reached the point of adding a line to the CI spreadsheet. But it seems to be read-only and I note the topic says there are problems. Am I blocked? Or can you help? | 08:49 |
| === sil2100 changed the topic of #ubuntu-ci-eng to: Need a silo or CI Train support? ping trainguards | Need help with something else? ping cihelp | Train Dashboard: http://bit.ly/1mDv1FS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: low on vivid silos | ||
| sil2100 | alan_g: hey! So, to have access to the spreadsheet you need to be added as a lander | 08:52 |
| alan_g | sil2100: ok, how does that happen? | 08:52 |
| sil2100 | alan_g: I can do that for you - have you been trained on the usage by someone? | 08:52 |
| sil2100 | The usage of the CI Train | 08:53 |
| alan_g | I have document I'm fixing as I go | 08:53 |
| sil2100 | alan_g: you should be added now, remember about the https://wiki.ubuntu.com/citrain/LandingProcess documentation | 08:54 |
| sil2100 | I'll try browsing through it today and making sure it's 100% up to date | 08:55 |
| alan_g | sil2100: thanks, have access and am adding that step (and reference) to the Mir doc | 08:56 |
| Mirv | sil2100: can you join #ubuntu-app-devel? | 08:56 |
| sil2100 | Mirv: what's up? | 09:00 |
| Mirv | sil2100: see there, a developer having a problem on desktop | 09:01 |
| Mirv | (14.04) | 09:01 |
| Mirv | ogra_: is "allow whoopsie to be permanently turned off" goind to land to rtm-14.09 or can the line be removed? | 09:20 |
| Mirv | rsalveti: will "Upstream fixes and optimizations" (libhybris) land to rtm-14.09 or can the line be removed? | 09:22 |
| Mirv | I'd guess not but checking before removing | 09:22 |
| ogra_ | Mirv, thjats waiting fro a fix to whoopsie ... seb128 kind of led that bug in the end ... not sure where we stand, but i suspect whoopsie wont be fixed before the hotfix OTA anymore | 09:22 |
| seb128 | ogra_, yeah, not likely going to be fixed before the next ota update | 09:23 |
| ogra_ | Mirv, kick it :) | 09:24 |
| Mirv | ogra_: thanks! | 09:24 |
| Mirv | sil2100: somehow we seem to hit a cap at silo 037, ie claims that no silos left | 09:27 |
| sil2100 | huh | 09:27 |
| sil2100 | Let me check that | 09:28 |
| Mirv | I just changed 30 -> 40 the number of production silos in metadata... | 09:30 |
| === jamesh_ is now known as jamesh | ||
| Mirv | it's probably not affecting anything as it was at just 30 | 09:30 |
| sil2100 | Ah, I think I know what's wrong | 09:31 |
| sil2100 | Uh oh, I think I see a bug in the train code | 09:36 |
| rvr | pstolowski: ping | 09:40 |
| sil2100 | wtf | 09:44 |
| pstolowski | rvr, pong | 09:54 |
| rvr | pstolowski: Hey | 09:55 |
| pstolowski | rvr, hi! what's up? | 09:55 |
| rvr | pstolowski: I cannot downgrade libunity-scopes3 | 09:55 |
| rvr | *** 0.6.9+15.04.20150429~rtm-0ubuntu1 0 | 09:55 |
| rvr | 500 http://ppa.launchpad.net/ci-train-ppa-service/landing-003/ubuntu-rtm/ 14.09/main armhf Packages | 09:55 |
| rvr | pstolowski: I guess the original package is only available in the image and not in the archives :-/ | 09:56 |
| pstolowski | rvr, sudo apt-get install libunity-scopes3=0.6.9+15.04.20150126~rtm-0ubuntu1 did this for me (on clean image + rtm silo 3; not dist-upgraded) | 09:56 |
| pstolowski | rvr, (I had to apt-get update) | 09:57 |
| pstolowski | rvr, ^ that's what you miss I think | 09:57 |
| rvr | Ahhh, that's it | 09:57 |
| rvr | Yeah | 09:57 |
| greyback_ | sil2100: hey, is train ready for landing to wiley yet? | 10:00 |
| greyback_ | if not, should I just wait? Or do we land to an overlay ppa of some kind? | 10:00 |
| mzanetti | also, if I select "vivid" in the spreadsheet now, this will go to the vivid phone image afaict. in which case, do we need QA signoff? | 10:05 |
| sil2100 | greyback_: it's not open for wily yet... but there are chances the phone will stay focused only on vivid | 10:06 |
| sil2100 | But I need more info to confim that | 10:06 |
| sil2100 | mzanetti: if you target vivid the it's targetted for the nearest vivid OTA release | 10:07 |
| greyback_ | sil2100: ok, thanks for clarifying | 10:07 |
| greyback_ | sil2100: vivid need QA signoff? | 10:10 |
| sil2100 | greyback_: yeah... | 10:10 |
| greyback_ | sil2100: ack | 10:10 |
| sil2100 | Mirv: this prepare_silo issue is absurd | 10:43 |
| sil2100 | Mirv: I checked the code, checked with cyphermox-test and every test I make shows that find_first_available should just properly return silo 38 | 10:44 |
| sil2100 | Mirv: I even ran a python snippet from find_first_available and it just worked | 10:45 |
| Mirv | sil2100: hmm, is it possible 38/39/40 would be marked as allocated even though according to spreadsheet they're not? | 10:45 |
| Mirv | sil2100: oh, but find_first_available returns 38.. | 10:46 |
| sil2100 | Mirv: no, I checked that too, the dirs are empty | 10:46 |
| Mirv | weird | 10:46 |
| Mirv | someone has decided 37 should be enough for everybody | 10:46 |
| sil2100 | Mirv: well, it *should* return 38 - the snippet I ran returns 38, all code shows it should but in prepare_silo it just seems to return None or '' | 10:46 |
| sil2100 | Still looking | 10:46 |
| tsdgeos | trainguards: i'm going to need a silo for row 64 if possible to drive my first landing \o/ | 10:49 |
| sil2100 | tsdgeos: the train is misbehaving and doesn't want to assign moar silos ;) Debugging it now | 10:51 |
| tsdgeos | sil2100: i see, thanks :) | 10:51 |
| === MacSlow is now known as MacSlow|lunch | ||
| didrocks | cihelp: hey! since yesterday ps-trusty-desktop-i386-1 is stopped, and I can't get it restarted, mind having a look? (it's a jenkins node used in s-jenkins) | 11:12 |
| sil2100 | Mirv: so, to get a better understanding of what is going on, I added some debug info to the train but now of course we need to wait for webops to redeploy it | 11:29 |
| sil2100 | Mirv: and they don't have time right now | 11:29 |
| * sil2100 loves how swift the debugging is with the current model | 11:29 | |
| Mirv | sil2100: ok... | 11:37 |
| * sil2100 needs to go for lunch | 11:38 | |
| sil2100 | Mirv: in the meantime there's not much we can do | 11:39 |
| Mirv | right | 11:50 |
| cwayne | sil2100, davmor2 heya, just added a line to the spreadsheet for clicks/tarballs for the twitter trending scope to be updated in the store | 11:56 |
| cwayne | should be really fast to test, all that was changed was some error checking | 11:56 |
| jibel | cwayne, thanks, I'll create a card | 11:56 |
| mzanetti | cihelp: I think I'd need a new exception for the licensecheck: https://code.launchpad.net/~mzanetti/unity8/inputinfo-plugin/+merge/258241 | 12:05 |
| jibel | cwayne, re twitter-trends LGTM, I get a completely blank scope for some hashtags but it's the same behaviour with 1.0.9 | 12:24 |
| jibel | cwayne, when do you plan to release a new custom tarball for RTM? | 12:24 |
| cwayne | jibel, today :) just building and writing up what's changed | 12:25 |
| cwayne | jibel, also thanks, I'll upload new twitter to the store | 12:25 |
| rsalveti | sil2100: yes, feel free to remove it (libhybris) | 12:49 |
| rsalveti | Mirv: ^ | 12:49 |
| Mirv | rsalveti: thanks | 13:11 |
| === MacSlow|lunch is now known as MacSlow | ||
| === elopio_ is now known as elopio | ||
| bzoltan | sergiusens: ping | 13:34 |
| sergiusens | bzoltan: pong | 13:35 |
| bzoltan | sergiusens: I have merged your ninja upload of the qtc plugin :) to our trunk and we have pushed 6 important usability and security fixes. Would you be able to help us to SRU the latest release to 15.04? In a way or an other the app devs will get this change. | 13:37 |
| bzoltan | sergiusens: because if I do not SRU these fixes then I have to push itto the SDK PPA and direct the developers on Vivivd to use the PPA | 13:37 |
| sergiusens | bzoltan: I can't SRU, I'm not a core dev | 13:39 |
| ogra_ | you really have to fix that | 13:39 |
| cjwatson | err that's entirely orthogonal | 13:39 |
| ogra_ | that too :) | 13:39 |
| cjwatson | although ubuntu-ui-toolkit is in main, so in this specific case it does matter :) | 13:40 |
| sergiusens | cjwatson: oh, nice; I need to learn the process then; but that means bzoltan can also do that | 13:40 |
| sergiusens | ah, there | 13:40 |
| * sergiusens needs to read that wiki page again | 13:40 | |
| bzoltan | cjwatson: it is the qtcreatot-plugin-ubuntu in this case... the austin sprinters have found couple of issues | 13:41 |
| * cjwatson tries to view /~sergiusens/+participation, gets annoyed enough to go and attack https://bugs.launchpad.net/launchpad/+bug/1409680 | 13:41 | |
| ubot5 | Ubuntu bug 1409680 in Launchpad itself "Person:+participation is Forbidden if the person participates in a visible team via an invisible one" [Critical,Triaged] | 13:41 |
| === jgdxx is now known as jgdx | ||
| mzanetti | cihelp, ping :) | 13:50 |
| ev | mzanetti: please don't use contextless pings | 13:51 |
| ev | don't ask to ask :) | 13:51 |
| mzanetti | ev, well, I asked before and didn't get a reply. | 13:52 |
| mzanetti | so I wanted to find out if someone is actually subscribed to this | 13:52 |
| mzanetti | ev, so my question was if I could get an exception added to the licensecheck in jenkins | 13:53 |
| mzanetti | https://jenkins.qa.ubuntu.com/job/unity8-vivid-amd64-ci/840/console | 13:53 |
| om26er | rsalveti, re: silo 30 for push. Does it strictly need to be tested on krillin or Arale is fine ? | 14:00 |
| ev | mzanetti: is that legally compatible? | 14:02 |
| mzanetti | ev, it's upstream Qt | 14:03 |
| mzanetti | ev, basically I coped code from a merge proposal to Qt because we need it now already | 14:03 |
| mzanetti | copied | 14:03 |
| didrocks | cihelp: 2nd try: since yesterday ps-trusty-desktop-i386-1 is stopped, and I can't get it restarted, mind having a look? (it's a jenkins node used in s-jenkins) | 14:03 |
| mzanetti | ev, here's the diff: https://code.launchpad.net/~mzanetti/unity8/inputinfo-plugin/+merge/258241 | 14:03 |
| rsalveti | om26er: arale is fine | 14:04 |
| mzanetti | ev, I *think* it's fine, as the Qt packages we use have the same things in them. That said, IANAL | 14:04 |
| * didrocks feels ignored… | 14:15 | |
| ogra_ | /ignore didrocks | 14:16 |
| didrocks | ogra_: see! :) | 14:16 |
| ogra_ | heh | 14:17 |
| greyback_ | trainguards: can I get a reconfigure on vivid silo 37 plz (spreadsheet row 12) | 14:18 |
| sil2100 | greyback_: on it | 14:18 |
| greyback_ | cheers | 14:18 |
| sil2100 | greyback_: did you guys abort the silo build? Just be sure not to abort the jenkins build jobs before the packages are uploaded to the PPA | 14:19 |
| sil2100 | The train is fragile in that regard ;) | 14:19 |
| greyback_ | sil2100: guilty as charged ;) | 14:20 |
| greyback_ | but no packages were generated, I aborte pretty quickly | 14:20 |
| sil2100 | greyback_: let's hope nothing got broken, since if it's cancelled during package preparation then it leaves stale files that can get in the way of building again ;) But a reconfigure should wipe things clean for us I guess | 14:21 |
| didrocks | sil2100: hum, that's handled, isn't it? (aborting the jenkins build, the transaction is committed at the end and all uploads happen in the end) | 14:21 |
| didrocks | and all states files are removed | 14:21 |
| greyback_ | sil2100: let's hope so. I'll let you know :) | 14:22 |
| sil2100 | didrocks: right now it's a bit fragile, the build job gets confused when the scripts are killed in the middle of preparing source packages, before their upload | 14:23 |
| didrocks | sil2100: argh, it was done before to be transactional on that regard and generate stamped files at the end (while cleaning everything which didn't get stamped and cleaning), that changed, ok | 14:23 |
| om26er | rsalveti, also any other TestPlan you want to be run except for ubuntu-push ? The testing instructions are missing on the Spreadsheet | 14:25 |
| rsalveti | om26er: just ubuntu-push | 14:25 |
| ev | mzanetti: cool, I've confirmed that it is a licence compatible change, and have created a task for it on our vanguard board | 14:29 |
| ev | we're a bit shorthanded on that today, so it may be a little while, but rest assured the request is with us | 14:30 |
| fginther | didrocks, someone will have a look before too long and back to you | 14:30 |
| mzanetti | ev, awesome, thanks. | 14:30 |
| didrocks | fginther: thanks! | 14:30 |
| sil2100 | Mirv: ...aaand it seems that it suddenly magically works, now it sees the other silos | 14:31 |
| sil2100 | Mirv: I didn't touch anything even | 14:31 |
| pete-woods | sil2100: FYI the network indicator RTM silo from earlier is tested now. just waiting on QA | 14:37 |
| sil2100 | pete-woods: \o/ excellent, thanks | 14:37 |
| sil2100 | john-mcaleely: hey! How's the device tarball going? | 14:37 |
| john-mcaleely | sil2100, still in progress | 14:38 |
| sil2100 | cwayne: I see the twitter trend scope passed QA - is that the only change that would land in the new custom tarball? | 14:43 |
| cwayne | sil2100, nope, see the line below that in the spreadsheet :) | 14:45 |
| sil2100 | cwayne: ah! :) No question then! | 14:46 |
| cwayne | sil2100, :) | 14:46 |
| om26er | pedronis, Hi! How long is it normally supposed to take for a Telegram push notification to appear ? | 14:54 |
| pedronis | om26er: should be quick | 14:54 |
| pedronis | ralsina_: ^ | 14:54 |
| ralsina_ | om26er: seconds | 14:55 |
| om26er | ralsina_, hmm take ~10-15 seconds. That normal I guess ? | 14:56 |
| ralsina_ | om26er: that's more or less what it takes, yes | 14:56 |
| ralsina_ | om26er: some days it's a bit faster :-) | 14:56 |
| om26er | ralsina_, would love to see it faster :) | 14:57 |
| ralsina_ | om26er: the bottleneck is usually between telegram server's and ours, IIRC | 14:57 |
| om26er | ralsina_, right, the notifications in the app are instant, so probably the problem is on our end | 14:58 |
| ralsina_ | om26er: to get the push, telegram has a server that forwards the message to ours. That extra step takes a few seconds, karni knows best | 14:59 |
| jibel | rvr, what is the status of rtm/silo 0 | 15:02 |
| jibel | ? | 15:02 |
| om26er | pedronis, how can I verify bug 1446584 fix ? | 15:04 |
| ubot5 | bug 1446584 in ubuntu-push (Ubuntu) "[krillin] On airplane mode battery discharge more rapidly than with airplane mode off" [Undecided,In progress] https://launchpad.net/bugs/1446584 | 15:05 |
| pedronis | om26er: I need to go afk, rsalveti can explain that as well | 15:05 |
| rsalveti | om26er: you can verify via syslog, if powerd got a lock or not (in a delta of 5 minutes) | 15:11 |
| rsalveti | I added that info to the bug | 15:11 |
| rsalveti | Easy way to check for the bug: | 15:11 |
| rsalveti | $ tail -f /var/log/syslog | grep powerd | 15:11 |
| rsalveti | Then look for acquire/release SysState. It shouldn't happen when flight mode is enabled. When either cellular data or wifi is enable, you should see that at every 5 minutes, as it's the default delta for push-client. | 15:11 |
| om26er | rsalveti, ok, thanks. | 15:12 |
| Mirv | sil2100: hmmm.. | 15:46 |
| om26er | sil2100, is spreadsheet functional again or do we need to request manual landings ? | 15:47 |
| sil2100 | om26er: it's ok now... at least for now | 15:47 |
| sil2100 | ;) | 15:47 |
| sil2100 | Mirv: yeah, anyway the bug itself was completely crazy, looked like something not really code related | 15:47 |
| === marcusto_ is now known as marcustomlinson | ||
| rvr | mandel: ping | 15:57 |
| sil2100 | cwayne: any news on the custom tarball? :) | 16:01 |
| cwayne | davmor2, ^ | 16:02 |
| davmor2 | sil2100: yes it's custom and a tarball | 16:02 |
| sil2100 | Custom tarball for RTM? The queue only mentiones vivid | 16:03 |
| cwayne | this ball of tar is quite custom indeed | 16:04 |
| cwayne | yeah, it's RTM, i built the same for vivid as well though, so that we could do a 2-for-1 :) | 16:04 |
| davmor2 | sil2100: happy now | 16:04 |
| sil2100 | hm, ok, since I was confused since the spreadsheet said 'not ready yet' still ;) | 16:05 |
| cwayne | oops sorry, ill edit | 16:05 |
| cwayne | i swear i'd changed it already | 16:06 |
| cwayne | guess not | 16:06 |
| tedg | Are their wily silos? It doesn't seem a selection in the spreadsheet. | 16:14 |
| tedg | Can I just write in ubuntu/wily ? | 16:15 |
| rvr | jibel: Approving silo 0 | 16:20 |
| * tedg just did it | 16:20 | |
| jibel | rvr, thanks, only bit missing is a device tarball now | 16:21 |
| sil2100 | Damn | 16:24 |
| sil2100 | mandel: ping | 16:24 |
| sil2100 | mandel: we have a problem - silo 000 in RTM was built from https://code.launchpad.net/~mandel/location-service/back-port-1441619/+merge/258072 , which is Rejected | 16:25 |
| sil2100 | mandel: we would need the silo rebuilt with https://code.launchpad.net/~rsalveti/location-service/syncing-vivid/+merge/258127 instead ;/ | 16:25 |
| jibel | sil2100, does that mean we have to retest it? | 16:25 |
| sil2100 | We just probably wasted QA cycles damn it | 16:25 |
| sil2100 | jibel: I would have to do a comparison to see if they're source-identical | 16:26 |
| sil2100 | Let me check that | 16:26 |
| sil2100 | But I'm a bit irritated | 16:26 |
| jibel | sil2100, could this check be done *before* the silo can even be marked ready for QA? | 16:26 |
| jibel | sil2100, and if it is not fully approved, then it cannot be marked for QA. | 16:27 |
| sil2100 | jibel: I think it was in the past, but people protested since their workflow was to sometimes test stuff in the silo before top-approving branches | 16:27 |
| sil2100 | jibel: well, the perfect solution would be hard to do with the spreadsheet | 16:28 |
| jibel | sil2100, it wouldn't block dev workflow | 16:28 |
| sil2100 | What we could do is add a check for Rejected merges | 16:28 |
| sil2100 | Rejected or Superseeded | 16:28 |
| jibel | sil2100, it would just prevent people from marking a silo ready for QA while it isn"t | 16:28 |
| sil2100 | And inform during build-time about those | 16:28 |
| sil2100 | jibel: yeah, you can't easily do that with the spreadsheet | 16:28 |
| jibel | sil2100, I don't want to add an extra manual task for such a thing that is clearly what computer are good at. | 16:29 |
| jibel | plus a bunch of 's' in the sentence :) | 16:29 |
| rsalveti | sil2100: I did rebuitl with that | 16:30 |
| rsalveti | maybe the spreadsheet reverted something | 16:30 |
| sil2100 | rsalveti: you did? Did you reconfigure after changing in the spreadsheet? | 16:30 |
| sil2100 | Since the config still shows the old MR | 16:31 |
| rsalveti | weird | 16:31 |
| sil2100 | rsalveti: are the two branches code-identical? | 16:32 |
| rsalveti | sil2100: nops | 16:32 |
| rsalveti | https://code.launchpad.net/~rsalveti/location-service/syncing-vivid/+merge/258127 is the right one | 16:32 |
| sil2100 | Crap | 16:33 |
| rsalveti | and is the one that produced the package that is in that ppa | 16:33 |
| sil2100 | rsalveti: ah, indeed, the build log says so too | 16:34 |
| sil2100 | rsalveti: now this is a mystery | 16:34 |
| sil2100 | rsalveti: ok, so the silo is configured with the old branch but the build job indeed used the new branch | 16:35 |
| sil2100 | rsalveti: maybe someone reconfigured the silo after your build and at that time the spreadsheet reverted itself, so it reconfigured it to the old branch | 16:36 |
| sil2100 | rsalveti: could you make sure the spreadsheet row for this landing has the correct MPs and source pkgs? I'll reconfigure it then, watch-only and publish | 16:37 |
| jibel | sil2100, so it's all good and no retest, right? | 16:37 |
| rsalveti | sil2100: it's just this MR | 16:41 |
| rsalveti | so just use that | 16:41 |
| rsalveti | no more src package | 16:41 |
| sil2100 | ACK | 16:42 |
| sil2100 | jibel: yeah | 16:42 |
| jibel | sil2100, now we really need a device tarball | 16:42 |
| jibel | john-mcaleely, ^ any news? | 16:42 |
| sil2100 | john-mcaleely: ping ^ | 16:42 |
| sil2100 | rsalveti: thanks for clearing it up o/ | 16:43 |
| john-mcaleely | jibel, sil2100 fixed build running on capomastro now | 16:43 |
| sil2100 | \o/ | 16:43 |
| john-mcaleely | so, 45 mins away | 16:43 |
| jibel | john-mcaleely, good, thanks! | 16:43 |
| pmcgowan | nice | 16:43 |
| sil2100 | john-mcaleely: you still need to test it then, right? | 16:43 |
| john-mcaleely | that's in the 45 min eta | 16:43 |
| john-mcaleely | takes around 30 mins to do the testplan :-) | 16:44 |
| jibel | sil2100, when there is a device tarball, davmor2 will be done with the validation of the custom, can you start a build and will do the validation device bits directly on the promotion candidate | 16:44 |
| john-mcaleely | (if this build fails, I have a tested, locally built, tarball ready to go | 16:44 |
| jibel | s/will/we will/ | 16:44 |
| sil2100 | jibel: yeah, I'll just build a new image once we have silo 000 in the archives | 16:45 |
| sil2100 | Actually... | 16:45 |
| sil2100 | hm | 16:45 |
| robru | tedg: congrats on getting the first wily silo: http://people.canonical.com/~platform/citrain_dashboard/#?q=wily | 16:45 |
| robru | (14) | 16:45 |
| sil2100 | slangasek, cjwatson: I published indicator-network to 14.09 a while ago and it didn't appear in -proposed | 16:45 |
| * tedg does a wily dance | 16:46 | |
| tedg | robru, Thanks! | 16:46 |
| robru | tedg: you're welcome | 16:46 |
| jibel | sil2100, well, wait until we have the 2 tarballs | 16:46 |
| sil2100 | jibel: those can land afterwards, they're not part of the rootfs anyway | 16:46 |
| jibel | sil2100, fine | 16:46 |
| cjwatson | indicator-network 0.5.1+15.04.20150505~rtm-0ubuntu1 in 14.09 (Cannot copy DDEBs to a primary archive) | 16:46 |
| sil2100 | huh? | 16:47 |
| cjwatson | that's odd, I thought we removed that check recently | 16:47 |
| cjwatson | oh, not entirely | 16:48 |
| sil2100 | cjwatson: strange, since we published packages today to rtm already, maybe infinity re-enabled something when he was working on wily? | 16:48 |
| cjwatson | no, that was re-enabled a while back | 16:48 |
| cjwatson | you probably published stuff that was built before we switched that back on | 16:48 |
| slangasek | cjwatson: does that mean the silo will need to be rebuilt? | 16:49 |
| cjwatson | no | 16:49 |
| cjwatson | but it needs somebody to reconfigure the ubuntu-rtm archive | 16:49 |
| sil2100 | cjwatson: it's a new silo, it got built today actually | 16:49 |
| cjwatson | which would be, let's see | 16:49 |
| sil2100 | cjwatson: assigned and built today | 16:49 |
| cjwatson | oh look, techboard | 16:50 |
| cjwatson | slangasek: oh hai | 16:50 |
| slangasek | :-) | 16:50 |
| slangasek | point me at the button | 16:50 |
| cjwatson | slangasek: archive = lp.distributions['ubuntu-rtm'].main_archive; archive.build_debug_symbols = True; archive.lp_save() | 16:50 |
| cjwatson | in "lp-shell production devel" | 16:50 |
| sil2100 | devel rulz | 16:51 |
| sil2100 | Why is it still devel, I never had any issues with that right now, would love it to become the new stable version | 16:51 |
| cjwatson | sil2100: then I guess we might need to redo the publish step manually, or can you retrigger that from your end nowadays? | 16:51 |
| cjwatson | API guarantee, although basically the whole system is broken there | 16:51 |
| sil2100 | cjwatson: I think we can retrigger it from the train, since I think it would just re-publish then | 16:51 |
| slangasek | cjwatson: http://pastebin.ubuntu.com/10990880/ | 16:51 |
| cjwatson | wut | 16:52 |
| slangasek | you tell me ;) | 16:52 |
| cjwatson | slangasek: could you 'rm ~/.launchpadlib/api.launchpad.net/cache/*wadl*' and try again? possibly old cached wadl | 16:52 |
| slangasek | old cached wadl, not the finest of whiskeys | 16:53 |
| slangasek | cjwatson: same error | 16:53 |
| cjwatson | slangasek: you're definitely using devel? | 16:53 |
| slangasek | I'm definitely typing 'lp-shell production devel' :) | 16:53 |
| slangasek | $ lp-shell production devel | 16:54 |
| slangasek | E: ipython not available. Using normal python shell. | 16:54 |
| slangasek | Connected to LP service "https://api.launchpad.net/" with API version "devel": | 16:54 |
| slangasek | Note: LP can be accessed through the "lp" object. | 16:54 |
| slangasek | >>> | 16:54 |
| cjwatson | slangasek: ok, sod it, try https://launchpad.net/ubuntu-rtm/+archive/primary/+admin | 16:54 |
| cjwatson | check "Build debug symbols", save | 16:54 |
| slangasek | Not allowed here | 16:54 |
| sil2100 | Uh oh | 16:55 |
| cjwatson | ah, I totally misread the security adapter | 16:55 |
| cjwatson | needs webops | 16:55 |
| slangasek | ok :) | 16:55 |
| cjwatson | or wgrant when he wakes up, but that probably won't be for a few hours | 16:55 |
| cjwatson | so you can point them at either of those methods, but the web UI is probably less confusing | 16:56 |
| slangasek | cjwatson, sil2100: 09:58 < seelaman> slangasek: done | 16:58 |
| sil2100 | \o/ | 16:59 |
| sil2100 | Thanks, let me try a re-publish | 16:59 |
| om26er | Mirv, re qtdeclarative silo, did you compare autopilot test results with previous version ? | 17:01 |
| === alan_g is now known as alan_g|EOD | ||
| sil2100 | cjwatson, slangasek: could you check if the packages got published correctly this time? | 17:08 |
| om26er | sil2100, do you know ? ^ | 17:08 |
| sil2100 | om26er: hm, I have no info regarding that, I guess only Mirv would know | 17:09 |
| cjwatson | sil2100: seems to have been | 17:09 |
| om26er | sil2100, is he EOD ? | 17:09 |
| sil2100 | om26er: but usually he does that | 17:09 |
| sil2100 | om26er: yes, it's around 20-21 at his place now | 17:09 |
| cjwatson | wgrant: I have a branch in progress to fix the reason the above was a problem, but I'm about to EOD. Will submit it tomorrow | 17:11 |
| slangasek | sil2100: I've committed the changes for daily phone builds, now fixing up the live crontab | 17:23 |
| slangasek | sil2100, ogra: now, whose local change to the crontab is this?: | 17:24 |
| slangasek | # do not build RTM on weekends, so we get two days of testing without forced reboots | 17:24 |
| slangasek | #02 3 * * 1-5 DIST=ubuntu-rtm/14.09 for-project ubuntu-touch cron.daily-preinstalled --live | 17:25 |
| slangasek | the crontab is in VCS, please make changes there | 17:25 |
| john-mcaleely | http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-20150505-db7b5bd.changes | 17:25 |
| john-mcaleely | http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-20150505-db7b5bd.tar.xz | 17:25 |
| john-mcaleely | http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-testresults-20150505-db7b5bd.ods | 17:25 |
| john-mcaleely | sil2100, jibel ^ | 17:25 |
| john-mcaleely | for your QA pleasure | 17:25 |
| slangasek | (for everything except temporary disabling of jobs during milestone builds) | 17:25 |
| sil2100 | jibel: ^ | 17:26 |
| sil2100 | slangasek: ah, hm, it's an old change | 17:26 |
| john-mcaleely | i remember that being introduced | 17:27 |
| john-mcaleely | ages ago | 17:27 |
| john-mcaleely | ~August last year? | 17:27 |
| sil2100 | slangasek: but yeah, all the other changes I was always editing it directly on nusakan, had no knowledge of a VCS | 17:27 |
| slangasek | yeah, improperly ;) if this is the policy, somebody should commit it to lp:ubuntu-cdimage | 17:27 |
| ogra_ | slangasek, please dont ! | 17:27 |
| slangasek | ogra_: don't what? | 17:28 |
| ogra_ | the crontab ion VCS is only an example one | 17:28 |
| slangasek | ogra_: that is false | 17:28 |
| ogra_ | dont merge them | 17:28 |
| ogra_ | no, that is how it was always handled | 17:28 |
| slangasek | ogra_: no, it is *not* | 17:28 |
| slangasek | and if this was the impression that you had, that explains why the live instance is so badly out of sync | 17:29 |
| john-mcaleely | sil2100, if you need the tarball pushing, ping me on telegram if I'm |away | 17:29 |
| ogra_ | slangasek, well ... ask infinity or cjwatson | 17:29 |
| sil2100 | john-mcaleely: uh oh I don't have a telegram account! Maybe davmor2 could do that though! | 17:29 |
| ogra_ | cronab is the one thing weher the live version supesedes the one in the branch | 17:29 |
| john-mcaleely | there's always an sms to the mobile in the corp. dir then :-) | 17:29 |
| ogra_ | because it might have ad-hoc changes for milestones etc | 17:30 |
| slangasek | infinity, cjwatson: can you please either confirm my understanding of nusakan's crontab, or refute it? :) | 17:30 |
| slangasek | infinity, cjwatson: since ogra_ and I seem to have a very different understanding of the intended crontab management | 17:30 |
| ogra_ | we used to sync it every now and then, but the production one is always been master | 17:30 |
| ogra_ | (oh, and no, i dont know who commented the line ) | 17:31 |
| sil2100 | ogra_: I commented it the line of RTM auto-builds some time ago | 17:33 |
| sil2100 | Once we stopped landing stuff there | 17:33 |
| ogra_ | sil2100, yeah, i surely commented it too at some point :) | 17:33 |
| infinity | slangasek: I think that in theory you're right, but years of practice going back several machines probably mirrors ogra's understanding better. | 17:33 |
| ogra_ | but i dont know if in this particular case since it was an on/off thing for the last weeks | 17:33 |
| infinity | slangasek: I certainly don't commit temp changes (like commenting during milestones), but adding/removing things should definitely be committed so they're not lost. | 17:33 |
| ogra_ | right | 17:34 |
| slangasek | right | 17:34 |
| ogra_ | thats what i meant with "syncing every now and then" | 17:34 |
| slangasek | and "it's been that way since August" is not a temp change | 17:34 |
| ogra_ | surely not :) | 17:35 |
| ogra_ | and it should have been synced | 17:35 |
| infinity | We have a lot more cooks dangling limbs in that pot than we used to, so a firmer policy wouldn't hurt at this point. | 17:35 |
| slangasek | ogra_: ok, so I'm not sure what you were telling me to "don't" do | 17:35 |
| dobey | cihelp: can we get lp:unity-scope-click landing/MP configuration updated to land on wily now? | 17:35 |
| slangasek | I never said I was overwriting the crontab, I said I was fixing it :P | 17:36 |
| ogra_ | slangasek, i thought you asked about the line being commented | 17:36 |
| sil2100 | Just to come out of this clean: I did not have access to nusakan back then ;p | 17:36 |
| ogra_ | that bit shouldnt go into VCS | 17:36 |
| slangasek | ogra_: ah. no, I was asking about the schedule change | 17:36 |
| * sil2100 is innocent | 17:36 | |
| ogra_ | i wasnt aware the additions to the line had not landed | 17:36 |
| slangasek | infinity, sil2100: btw we have three different branches we want phone dailies of for the moment (14.09, vivid+overlay, and shortly wily), and the crontab is rather full as far as scheduling goes; I'm proposing that we just build them all in parallel at the same time, I think launchpad should be able to scale out fine to handle it and it beats me having to pick arbitrary different times for each bu | 17:38 |
| slangasek | ild | 17:38 |
| fginther | dobey, I expect this to be done today. We're in the middle of the process of adding the wily chroots and updating the job configs to use wily | 17:38 |
| sil2100 | slangasek: makes sense if launchpad can handle that by itself | 17:39 |
| ogra_ | slangasek, yeah, that scheduling is surely overruled by LP nowadays, it stems still from having only one builder | 17:39 |
| infinity | slangasek: Yeah, timing really doesn't matter anymore, except for when people want the images to appear. | 17:39 |
| sil2100 | We don't really care about the specific time and/or priority what builds first I suppose | 17:39 |
| dobey | fginther: ok | 17:39 |
| infinity | slangasek: Pick a time that's good for the people who'll be testing them and jam them all in together, IMO. | 17:39 |
| slangasek | sil2100: this way they should all build in parallel, and all appear within a half hour of each other | 17:40 |
| ogra_ | yeah, we used to pick it in a way that the autopilot tests had run when we started the landing team meeting in the past | 17:40 |
| infinity | slangasek: Maybe delay by a minute or two, so the slightly-broken locking protocol in cdimage doesn't get more broken. :P | 17:40 |
| slangasek | infinity: I thought the locking protocol was sane between different images | 17:40 |
| ogra_ | but given we only do that twice a week now it isnt that important anymore when these tests show up ... i guess thats a QA question now | 17:41 |
| infinity | slangasek: There's one specific lock that's a bit touchy, and I've not hunted down why. It doesn't actually break images, but it does end up with a counter being off-by-one, which hitches up the mirror sync (a non-issue for touch, but then it breaks server builds later). | 17:41 |
| infinity | Well, it doesn't break the image it's building when the lock/unlock fails, I mean. It obviously breaks anything that relies on mirror consistency. | 17:42 |
| infinity | slangasek: I'm about 99% sure it's an uncaught exception or something, but on the off chance that it's also racy, I'd rather stagger the starts by a minute just to be safe until I know what's wrong and know it's fixed. | 17:43 |
| slangasek | sil2100: crontab mangling done. The vivid daily builds will start immediately, but the importer isn't yet set up to pull them in; I assume that we are going to want to point ubuntu-touch/rc-proposed at these as soon as OTA 3.5 is done | 17:43 |
| slangasek | (when is that done?) | 17:43 |
| sil2100 | slangasek: OTA-3.5 will be done this week, we're closing the gates in a few minutes and building our first promotion candidate | 17:45 |
| slangasek | infinity: ok, done | 17:45 |
| slangasek | sil2100: ok. as soon as ota 3.5 is out the door, let me know and I can help finagle the channel configs | 17:46 |
| ogra_ | sil2100, oh, i guess you want wily support for the bot too ? | 17:46 |
| sil2100 | slangasek: sure thing, thanks for making this happen ;) | 17:46 |
| * ogra_ will try to make up some time for that tomorrow | 17:46 | |
| sil2100 | ogra_: hm, I wonder, we could but I wouldn't say it's top priority as per what olli said we're all concentrating on vivid as there are no plans for wily phones | 17:47 |
| sil2100 | Ok, maybe I'll rephrase it | 17:47 |
| ogra_ | well, there will be wily snappy phone builds i guess | 17:47 |
| ogra_ | not really for usage though | 17:47 |
| sil2100 | I'll be good to have for sure, but not a priority ;) | 17:48 |
| ogra_ | ok :) | 17:48 |
| tedg | sil2100, and thinks should land in wily before landing on vivid. | 17:48 |
| tedg | things | 17:48 |
| ogra_ | tedg, i fear that wont always work | 17:48 |
| sil2100 | tedg: yeah, it's not so easy... | 17:48 |
| ogra_ | i.e. if you have dependencies on something thats only in wily | 17:48 |
| slangasek | we won't release a phone from wily, but it's still better to keep the trunk from getting completely overgrown with weeds | 17:48 |
| ogra_ | for sure | 17:48 |
| davmor2 | john-mcaleely: sil2100 I can ping john on telegram :) | 17:49 |
| sil2100 | davmor2: thanks ;) | 17:49 |
| ogra_ | but you shouldnt focus your trunk on wily featuresets | 17:49 |
| ogra_ | (which might be hard for the Qt bits) | 17:49 |
| sil2100 | slangasek: we need to finally discuss what to do with landings, if we do that auto-dual-landing thing for projects where we can | 17:49 |
| sil2100 | Or we just again allow 2 trunks to form - one for stable and one for devel | 17:50 |
| * sil2100 needs either a clear decision from higher-ups or the decision power here | 17:50 | |
| sil2100 | ;) | 17:50 |
| sil2100 | ogra_, jibel: kicking off the rtm image | 17:51 |
| tedg | Doesn't every project already have a stable branch? | 17:51 |
| tedg | I mean, that seems like standard operation... | 17:51 |
| sil2100 | tedg: yes, the RTM one | 17:51 |
| pmcgowan | sil2100, woot | 17:51 |
| tedg | sil2100, Heh, for really new projects I guess :-) | 17:52 |
| tedg | Most of mine have a set for LTSes and the such as well. | 17:52 |
| sil2100 | pmcgowan: once this image builds QA should be done with device tarball sign-off, so john-mcaleely can then press the button and we'll have the first promotion candidate ready for QA | 17:52 |
| pmcgowan | ack | 17:54 |
| infinity | cjwatson: When you wrote the EXTRA_PPAS integration for cdimage, was there a reason you opted for first_ppa = archive, instead of a separate BUILD_ARCHIVE variable or something? | 17:54 |
| imgbot | === IMAGE RTM 273 building (started: 20150505-17:55) === | 17:55 |
| ogra_ | \o/ | 17:55 |
| infinity | cjwatson: It seems a bit unintuitive that a build in the primary archive will stay in the primary archive if I use extra_ppas in the json config, but will build in a PPA if I used EXTRA_PPAS on cdimage. | 17:55 |
| slangasek | sil2100: yes, we certainly do need to get that sorted out | 17:58 |
| slangasek | infinity: so I need to set EXTRA_PPAS=ci-train-ppa-service/stable-phone-overlay:1000 now for the pinning, right? | 18:30 |
| infinity | slangasek: 1001 | 18:32 |
| slangasek | ok | 18:32 |
| sil2100 | Ok, I need to go away now or I lose my head | 18:42 |
| sil2100 | See you o/ | 18:42 |
| sil2100 | davmor2: please ping john-mcaleely once the tarball passes sign-off ;) | 18:43 |
| sil2100 | davmor2: I see the rootfs for #273 finished, but the image still needs some time to appear | 18:43 |
| sil2100 | But he can push it whenever you're ready | 18:43 |
| davmor2 | sil2100: I might | 18:44 |
| sil2100 | (the tarball that is) | 18:44 |
| davmor2 | om26er: is testing it when he get's it flashed he took it while I was at tea :) | 18:44 |
| davmor2 | sil2100: so om26er is pinging john-mcaleely via telegram \o/ my work here is done | 19:02 |
| sil2100 | \o/ | 19:03 |
| sil2100 | john-mcaleely: tarball can be released \o/ | 19:03 |
| john-mcaleely | davmor2, om26er thank you | 19:03 |
| sil2100 | davmor2, om26er: thanks guys! | 19:03 |
| john-mcaleely | sil2100, want the device tarball pushed then ? :-) | 19:03 |
| sil2100 | john-mcaleely: hm, wait | 19:03 |
| sil2100 | It should be safe now, right? | 19:03 |
| * john-mcaleely waiting | 19:03 | |
| sil2100 | Since the rootfs finished building, but the image wasn't imported yet | 19:03 |
| sil2100 | ogra_: you think it would be safe to push a new device tarball at such a state? I'm always worried about some races or such | 19:04 |
| ogra_ | sil2100, well, check if the importer already runs | 19:06 |
| ogra_ | i usually stop the importer in such cases to not accidentially cause havoc | 19:06 |
| ogra_ | if it already runs i wouldnt challenge it and wait the few mins | 19:07 |
| sil2100 | Yeah, it's running | 19:12 |
| john-mcaleely | aha | 19:12 |
| sil2100 | john-mcaleely: let's wait for the importer to stop running | 19:12 |
| john-mcaleely | ok | 19:12 |
| john-mcaleely | ping me here when it's done sil2100 | 19:12 |
| sil2100 | Shouldn't take long | 19:12 |
| ogra_ | usually it doesnt run more than 30min | 19:12 |
| sil2100 | john-mcaleely: sure, thanks :) | 19:12 |
| ogra_ | 1258 ? R 15:29 /usr/bin/python /srv/system-image.ubuntu.com/bin/import-images | 19:13 |
| ogra_ | already 15 min in ... | 19:13 |
| imgbot | === IMAGE RTM 273 DONE (finished: 20150505-19:20) === | 19:20 |
| imgbot | === changelog: http://people.canonical.com/~ogra/touch-image-stats/rtm/273.changes === | 19:20 |
| ogra_ | sil2100, go wild | 19:20 |
| ogra_ | or rather john-mcaleely ^^^ | 19:20 |
| charles | heh | 19:20 |
| sil2100 | john-mcaleely: ! | 19:28 |
| sil2100 | john-mcaleely: as ogra_ said, importer finished - please push teh buttonz | 19:28 |
| sil2100 | :) | 19:28 |
| john-mcaleely | sil2100, button pushed | 19:31 |
| john-mcaleely | sil2100, tarball published | 19:31 |
| sil2100 | \o/ | 19:31 |
| sil2100 | john-mcaleely: thanks! | 19:31 |
| john-mcaleely | yw | 19:31 |
| sil2100 | om26er, ToyKeeper, davmor2, alesage: #274 should be available soon, which is the promotion candidate for this week :) | 19:32 |
| * sil2100 goes off | 19:32 | |
| sil2100 | See you tomorrow | 19:32 |
| om26er | sil2100, thanks | 19:32 |
| ToyKeeper | Thanks. | 19:33 |
| fginther | slangasek, I need to pick up a conversation we started earlier. Generally when opening a new release, CI updates all of the pre-merge CI jobs to test trunk with the new devel release (i.e. lp:unity8 will go from vivid builds to wily), but it sounds like we need to take a much different approach now? | 22:01 |
| wgrant | cjwatson: Huh, I didn't know that check existed :/ | 22:01 |
| === salem_ is now known as _salem | ||
| slangasek | fginther: hmm yes. going to the wiki to refresh my memory on prior art | 22:15 |
| fginther | slangasek, for some more backgroun: the approach in the past was to automatically move trunks to the new release and then if necessary create an SRU branch on demand. For utopic, we only had 1 SRU branch. | 22:27 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!