| === chihchun_afk is now known as chihchun | ||
| Mirv | robru: diff:ing errors in publishing https://ci-train.ubuntu.com/job/ubuntu-landing-014-2-publish/120/console | 05:20 |
|---|---|---|
| Mirv | robru: and then it fails apparently on assuming the diff would have packaging diff, while the mir seemingly would not have | 05:22 |
| Mirv | just in case, I try to watch_only build | 05:23 |
| Mirv | robru: yeah the diff:s are zero sized https://ci-train.ubuntu.com/job/ubuntu-landing-014-1-build/248/ | 05:38 |
| robru | Mirv: oh god. Let me look | 05:40 |
| robru | Mirv: oh, I see | 05:44 |
| robru | Mirv: sil asked me to flip the switch so that dual silos always publish to overlay now. so what's happening is those packages aren't in the overlay so it fails to find any old version, which is why the diff is 0 | 05:44 |
| robru | Mirv: if you look at the packaging diff it says it's a new package | 05:45 |
| robru | Mirv: should this silo go to overlay? | 05:45 |
| robru | i guess so if it's just phone stuff | 05:46 |
| robru | I'll whip up some code to make it fall back on main archive if it can't find the package in the ppa. | 05:46 |
| Mirv | robru: ah... | 05:48 |
| Mirv | robru: so. if sil wanted to flip the switch, then yes I guess we want everything to dual land to overlay now. | 05:48 |
| robru | Mirv: hmm actually there's already code that says "if version not found, check main archive", not sure why that didn't trigger... | 05:48 |
| oSoMoN | bzoltan_, Mirv: hey, I fixed webbrowser-app in silo 57 last night, as far as I’m concerned it’s good to go, feel free to publish if you’re not waiting on anything else | 05:49 |
| Mirv | robru: hmmkay. | 05:49 |
| Mirv | oSoMoN: sure, we just have a slight breakage :) | 05:49 |
| Mirv | oSoMoN: plus the UITK has packaging changes so it'll need a core-dev. | 05:49 |
| oSoMoN | right | 05:49 |
| robru | Mirv: check if those packages are already in overlay ppa, it should be publishable if they are | 05:49 |
| oSoMoN | Mirv, where is that breakage? in the train itself? | 05:49 |
| robru | oSoMoN: yeah I broke the train so it can't publish things if they don't already exist in overlay ppa | 05:50 |
| robru | working on it | 05:50 |
| Mirv | robru: they are actually, it's still 0 size | 05:53 |
| Mirv | robru: so it's not the fallback | 05:53 |
| Mirv | robru: oh right but not wily, sorry | 05:53 |
| Mirv | robru: of course there's nothing for wily in the PPA | 05:54 |
| robru | Mirv: oh right, nothing would be there for wily | 05:54 |
| robru | Mirv: yeah the "0 size" is not particularly meaningful, python creates those files first before debdiff gets involved, content diff being 0 size just means "debdiff had unknown errror" | 05:54 |
| robru | Mirv: ok, I think I see what's happening. when it decides whether to use the overlay ppa vs the archive, it doesn't specify the series, so the vivid package says 'yep theres a package in the overlay ppa' then later when trying to diff it specifically says'ok overlay pp, gimme the wily version' and that fails | 05:56 |
| robru | Mirv: so if I specify the series in the initial check it should work | 05:57 |
| Mirv | right! thanks for looking into it. we could have workarounded by manual copying but it'll be good to have train back too. | 05:58 |
| robru | Mirv: you're welcome. ok, fix pushed to trunk, will hit production in 20 minutes, try it again then and ping me if it still doesn't work. | 06:01 |
| Mirv | ok | 06:04 |
| bzoltan_ | Mirv: robru: an we merge the landing MR to the trunk before the package is acked and published to Wily? | 06:20 |
| Mirv | bzoltan_: no, packages aren't going to wily anymore, they go to overlay for wily series too | 06:28 |
| bzoltan_ | Mirv: ohh, how shame | 06:29 |
| robru | Mirv: should be safe to publish now | 06:32 |
| Mirv | robru: hmm, looks good now. but I wonder why ^ without packaging changes and with a MP upload? | 06:35 |
| robru | Mirv: is it in main? | 06:36 |
| Mirv | robru: yes, in main, but I thought the exception still was canonical upstream projects handled with MP:s without packaging changes can be uploaded. | 06:37 |
| Mirv | since I remember being mentioned that manual main uploads always require core dev publishing while MP ones wouldn't | 06:37 |
| robru | Mirv: the artifacts have packaging changes | 06:38 |
| Mirv | robru: sorry for firing so many questions, but I also think that https://ci-train.ubuntu.com/job/ubuntu-landing-057-2-publish/9/console - a main package _with_ packaging changes, used to complain about the need of an "ack" before failing about no right | 06:39 |
| Mirv | robru: yes, but not for mir: https://ci-train.ubuntu.com/job/ubuntu-landing-014-2-publish/ | 06:39 |
| Mirv | robru: the others are universe packages | 06:39 |
| robru | Mirv: packaging changes prevent the whole silo from being published | 06:39 |
| Mirv | robru: yes, but it didn't complain about packaging changes but the upload rights. | 06:40 |
| robru | Mirv: when deciding to publish it doesn't consider each package individually, you need to have permission to upload everything | 06:40 |
| Mirv | robru: I'll try 014 with 'ack' checked, since that's what it'd require for the universe packages. | 06:40 |
| Mirv | robru: yes, but the one main package without packaging changes would also be allowed by current policy. | 06:41 |
| robru | Mirv: that's just how the check works. If there are packaging changes and you don't have rights, it says "not authorized", it only says "need ack" if you have the ability to give an ack | 06:41 |
| Mirv | robru: it seems 014 worked with 'ack', right. I think functionally it's all good, just a bit confusing it complains about no rights to upload mir package while actually there are rights to upload that one, and the real erroring out reason was the lack of an ack for packaging changes in universe package. | 06:42 |
| robru | Mirv: yeah that could be reported better i guess. Right now the error just goes by the first wrong thing it sees | 06:43 |
| Mirv | robru: so in case of 014, I did have the ability to 'ack', and the error it gave was not really a problem since mir didn't have packaging changes itself. | 06:44 |
| robru | 7 silos marked dirty by that, jeez people are really abusing conflicting silos these days. | 06:44 |
| Mirv | robru: but no problem, understood again | 06:44 |
| Mirv | oh really... | 06:44 |
| Mirv | there's also huge amount of webbrowser silos | 06:44 |
| Mirv | robru: aaaaanyway, everything good, logic understood, I'll just need to find a core-dev for 057. | 06:45 |
| robru | When i wrote the dirty logic i expected any silo to have at most one other conflicting one | 06:45 |
| robru | Lol, audit logs are online for a day and we're already up to comment id 397, i should figure out how postgres stores primary keys, check at what point it will integer overflow | 06:49 |
| oSoMoN | robru, Mirv: QA is the bottleneck here, there wouldn’t be so many webbrowser-app silos if there was more throughput | 06:51 |
| oSoMoN | and also the fact that I noticed only yesterday that webbrowser-app was failing to build in silo 57 | 06:52 |
| robru | Mirv: strange that 14 didn't migrate yet, it should copy & merge immediately (no proposed in overlay) | 06:58 |
| robru | Mirv: can you check that all the packages are in overlay and if so, manually merge silo? And file a bug that migration is broken. | 06:58 |
| robru | Mirv: i assumed it would check the dest ppa but i guess something isn't using the right archive property. | 07:01 |
| seb128 | Mirv, is there a way to make packages go to wily rather than the overlay? | 07:01 |
| seb128 | seems weird to force the overlay, some bugfixes can still be useful to wily | 07:02 |
| robru | seb128: i had fixed that but slangasek requested all packages go to overlay. If you really want a train fix in wily you can copy from ppa yourself | 07:03 |
| seb128 | I don't want a train fix, I just discuss the principle behind the decision | 07:04 |
| seb128 | but I guess I should discuss it with slangasek | 07:04 |
| Mirv | robru: seems they are all there, merging + filing | 07:11 |
| robru | seb128: i mean, if you have a bugfix in a train silo and you want this in wily, you can copy the package to wily yourself for now. But yes, take it up with slangasek because i had enabled users choosing where to publish to and then he told me to enforce it train-wide | 07:11 |
| seb128 | k | 07:11 |
| robru | seb128: oh actually also this enforcement is only for dual silos, so if you are just working on some desktop only stuff you can just have a wily silo and publish to wily, i forgot about that | 07:12 |
| jibel | robru, thanks for the auditable logs. One more thing though bug 1502018 | 07:12 |
| ubot5` | bug 1502018 in Bileto "Differentiate automated comments from user comments" [Undecided,New] https://launchpad.net/bugs/1502018 | 07:12 |
| seb128 | yeah, that makes sense | 07:12 |
| robru | jibel: the ones that have the "log" link are generated ones ;-) | 07:13 |
| jibel | robru, nope | 07:13 |
| robru | jibel: is it enough to make the user comments bold or something? Man you're picky! | 07:14 |
| jibel | robru, if it's a status change there is no indication | 07:14 |
| robru | jibel: but the status change is always just "Updated x" it's short... | 07:14 |
| jibel | robru, I think this comments are useful to understand what happens with a landing but most of the time they are not useful to the lander and could be hidden | 07:14 |
| Mirv | seb128: if you have time, please check the UITK diff and publish 057 since it's a main package https://ci-train.ubuntu.com/job/ubuntu-landing-057-2-publish/9/ (adds dependency on liblttng-ust-dev which is in main, and adds two new binary packages) | 07:16 |
| jibel | robru, like, it is a bit like it's very useful to have a syslog but you don't want it all time on your terminal :) | 07:16 |
| robru | jibel: well I'm halfway through a full site redesign so i guess it's a good time to consider these things. I'll have a live demo up next week, we can iterate on it before going live | 07:16 |
| jibel | robru, sure | 07:16 |
| jibel | robru, sounds good to me | 07:17 |
| robru | Alright goodnight everybody! | 07:17 |
| Mirv | robru: good night! | 07:17 |
| Mirv | and thanks for the fixes and features! | 07:17 |
| jibel | godd night robru | 07:17 |
| jibel | good* | 07:18 |
| seb128 | Mirv, looks fine to me | 07:18 |
| robru | You're welcome! | 07:18 |
| Mirv | seb128: you need to run the publish job too, nowadays just verbal ack is not enough | 07:19 |
| Mirv | seb128: train checks whether the person would have archive rights for the packages in question (if their MP:s have packaging changes) | 07:19 |
| seb128 | Mirv, even if you don't upload to the archive? | 07:20 |
| seb128 | Mirv, done | 07:20 |
| seb128 | looks like oSoMoN and dbarth like to claim silos for webbrowser ;-) | 07:23 |
| bzoltan_ | seb128: Thank you a bunch :) | 07:26 |
| seb128 | bzoltan_, yw! | 07:26 |
| dbarth | yeah | 07:30 |
| dbarth | cool, so now i go first for the next webbrowser-app landing ;) | 07:31 |
| bzoltan_ | dbarth: sorry mate :) I had to push a fix for the browser to prevent AP breakage with the new UITK. I take all blames :) | 07:33 |
| oSoMoN | dbarth, yep, silo 25 then 59 | 07:34 |
| dbarth | yup; bzoltan: nw | 07:38 |
| Mirv | seb128: thanks a lot! yes, it's enforced even for overlay which is thus treated like on archive (even though in reality we could copy packages there manually). | 07:41 |
| Mirv | sil2100: hey just FYI auto-mergeclean is busted at the moment probably due to the switch to overlay-only, so one needs to check everything landed to overlay and run merge & clean manually | 07:42 |
| Mirv | dbarth: hey, the webbrowser-app trunk was not pushed yet... | 07:43 |
| Mirv | dbarth: now it is, aborting your 025 build and rerunning | 07:44 |
| jibel | dbarth, silo 16 is for OTA7? | 07:44 |
| dbarth | trying, but just in the middle of a call | 07:52 |
| dbarth | ok, so i need to wait a bit still | 07:53 |
| dbarth | jibel: hopefully, silo 16 contains the memory limits improvements | 07:53 |
| dbarth | we need to test it a bit, but based on initial reports, that's the one to take | 07:54 |
| sil2100 | Mirv: ACK! | 07:56 |
| jibel | dbarth, very nice, thanks! | 08:01 |
| bzoltan_ | Mirv: we need this project on the train and land it on the Vivid Overlay PPA - https://launchpad.net/ubuntu-sdk-qmake-extras What should I do? | 08:42 |
| Mirv | bzoltan_: set owners/managers/members correctly, I can do that after this hangout | 08:46 |
| Mirv | (if there's something to do) | 08:46 |
| Mirv | bzoltan_: + packaging with .bzr-builddeb etc from https://wiki.ubuntu.com/DailyRelease/InlinePackaging in the code | 08:46 |
| bzoltan_ | Mirv: Ok, thanks for reminding me :) | 08:47 |
| Mirv | bzoltan_: the .bzr-builddeb needs to be in /, not debian/ | 08:54 |
| bzoltan_ | Mirv: Of course | 08:55 |
| Mirv | bzoltan_: so.. I think the project might be just good to go as is. I think it's better to try and see if anything fails, but the ci-train user that's needed is in SDK team so it should be ok. | 09:04 |
| sil2100 | Oh no, the buteo silo has a lot NEW packages | 09:07 |
| Mirv | sil2100: I've saved a note from cjwatson "I think we should stop bothering with preNEW for new sources, and only keep it for new binaries" | 09:08 |
| Mirv | since train does not bypass src NEW queue | 09:08 |
| Mirv | I don't at least misquote him, hopefully also I don't misuse the quote :D | 09:08 |
| Mirv | sil2100: but the packagings should be reviewed normally as for universe packages of course | 09:09 |
| sil2100 | ;) | 09:09 |
| sil2100 | Indeed, yeah | 09:09 |
| sil2100 | Most of the packaging was prepared by kenvandine, so this should be relatively fast | 09:11 |
| Mirv_ | dbarth: 025 is now ready (just one i386 still building), please hand it over to QA swiftly so that the big webbrowser queue can be processed... | 09:20 |
| dbarth | Mirv_: cool; thanks for that | 09:21 |
| dbarth | i know webbrowser-app builds take some manual care currently | 09:21 |
| Mirv_ | jibel: I bootstrap flashed latest rc-proposed and upgraded to a silo (which dist-upgraded, so new mir etc too), and I've Unity 8 restart loop now even after purging my PPA. Care to double-check? | 09:25 |
| sil2100 | Mirv_: I'm still thinking about requesting a preNEW review here though | 09:25 |
| cjwatson | Mirv_: you do not misquote me | 09:25 |
| sil2100 | Mirv_: since... it's a dual silo, so the change gets directly to the overlay | 09:25 |
| sil2100 | It bypasses the NEW queue and will be picked up only when we copy to W+1 | 09:25 |
| cjwatson | right, preNEW is for cases where NEW ought to exist but doesn't | 09:25 |
| jibel | Mirv_, sure, which silo? which device? | 09:26 |
| Saviq | sil2100, wily images don't have overlay enabled yet? | 09:26 |
| Mirv_ | sil2100: does the copy to W+1 bypass the queue any more than train? | 09:26 |
| Mirv_ | jibel: what I meant is: use current rc-proposed and dist-upgrade (to get today's landings like 014) and try that. I'm on mako. | 09:26 |
| sil2100 | Saviq: no, not yet, but will be now - Robert was switching to overlay-only landings when I was EOD already | 09:26 |
| Saviq | kk | 09:27 |
| sil2100 | Mirv_: ok, the packaging looks okay to me so far, it's been worked on/reviewed by kenvandine and seb128 for most cases too | 09:27 |
| jibel | Mirv_, yeah but I'd also like to check if any leftover from the silo would cause the reboot loop | 09:27 |
| sil2100 | seb128: hey! Could you perform a few preNEW reviews in the buteo silo for us? :) | 09:27 |
| Mirv_ | jibel: well it's my 032 which is not going to land any time soon (if ever, before Qt 5.5) | 09:28 |
| sil2100 | seb128: the links are: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-034 for the PPA and https://ci-train.ubuntu.com/job/ubuntu-landing-034-2-publish/6/ for the artifacts | 09:28 |
| Mirv_ | sil2100: ok then | 09:28 |
| jibel | Mirv_, which channel exactly rc-proposed/ubuntu? | 09:29 |
| Mirv_ | jibel: ubuntu-touch/rc-proposed/ubuntu | 09:29 |
| seb128 | sil2100, can try this afternoon yes | 09:30 |
| sil2100 | seb128: thanks! | 09:30 |
| sil2100 | davmor2: ^ the buteo silo will wait a bit before landing, we need a preNEW review | 09:31 |
| sil2100 | But I think it should still be ok to test it live today | 09:31 |
| davmor2 | sil2100: sure just give me a ping I'll make sure I have images ready | 09:31 |
| jibel | sil2100, we are already far past feature freeze, if it doesn't land today, it will be for OTA8 | 09:32 |
| dbarth | jibel, davmor2: ticket 412 / silo 25 re-tested here; on to you now | 09:32 |
| seb128 | yw! | 09:32 |
| jibel | dbarth, thanks, unblocking | 09:32 |
| dbarth | jibel: however oxide 1.9.4 has a regression; we're investigating :/ | 09:32 |
| dbarth | but memory usage doesn't balloon as high as before | 09:33 |
| sil2100 | jibel: +1 on that | 09:34 |
| jibel | Mirv_, it looks bad, unity8 crashes apparently | 09:51 |
| jibel | sil2100, don't rebuild any image yet there is something broken in the ovelay | 09:52 |
| jibel | overlay* | 09:52 |
| sil2100 | Oh | 09:52 |
| jibel | sil2100, it would be the last unity8/mir/powerd landing | 09:53 |
| jibel | https://requests.ci-train.ubuntu.com/#/ticket/343 | 09:53 |
| jibel | Mirv_, did you collect any info about the crash? | 09:53 |
| jibel | I'll try on krillin | 09:53 |
| sil2100 | Do you know already which image was the one first broken? | 09:54 |
| jibel | sil2100, the broken image doesn't exist yet, it'll be next one | 09:54 |
| rvr | jibel: I approved last night silo 15, which contains unity8, powerd, mir, system-compositor | 09:55 |
| jibel | rvr, on which device | 09:55 |
| jibel | ? | 09:55 |
| rvr | jibel: arale | 09:55 |
| jibel | maybe it's only a problem on mako | 09:56 |
| jibel | I'm trying krillin now | 09:56 |
| rvr | Remember that powerd needs manual fix to properly install | 09:57 |
| rvr | the ppa packages may not finish installing | 09:58 |
| Mirv_ | jibel: I tried looking at the logs but reflashed already (but obviously can easily get it back to broken state) | 09:58 |
| Mirv_ | rvr: jibel: rvr's point might be the thing, I just used citrain tool | 09:58 |
| Mirv_ | so it might be all resolved with the next image | 09:59 |
| === Mirv_ is now known as Mirv | ||
| Mirv | sil2100: if ^ that's the thing, it might be useful to have a new rc-proposed image since otherwise people flashing latest image + upgrading to their newest silo will experience that | 09:59 |
| Mirv | but let's confirm first | 10:00 |
| sil2100 | Ok, once you confirm we'll kick a new image | 10:00 |
| * Mirv has to eat late lunch | 10:08 | |
| sil2100 | ogra_: hey hey, could you review+merge https://code.launchpad.net/~sil2100/livecd-rootfs/fix-apt-lists-rm-hook/+merge/273117 ? This is the hook that works ;p | 10:23 |
| sil2100 | cjwatson: hey! Could you take a look in a free moment at https://code.launchpad.net/~sil2100/ubuntu-cdimage/enable_wily_overlay/+merge/273208 ? | 10:29 |
| cjwatson | sil2100: isn't there somebody else who could be the routine cdimage reviewer? | 10:30 |
| cjwatson | I'm not a good candidate | 10:31 |
| cjwatson | because I don't do most of the day-to-day stuff of keeping cdimage running any more | 10:31 |
| sil2100 | cjwatson: not sure, I guess I might poke infinity as he has the most commits (but he's a different TZ) - not sure if stgraber is still working on it anymore | 10:31 |
| cjwatson | sil2100: I'll do it this time, but please try to find somebody who isn't me for the next one | 10:33 |
| sil2100 | cjwatson: will do, thanks! | 10:33 |
| jibel | sil2100, Mirv krillin is not affected by the shell crash, only mako apparently | 10:34 |
| cjwatson | sil2100: merged and deployed, thanks | 10:35 |
| cjwatson | including manual crontab edit | 10:35 |
| sil2100 | Thank you again! | 10:35 |
| sil2100 | jibel: so it's unrelated to powerd? | 10:55 |
| rvr | sil2100: Apparently not | 10:56 |
| jibel | sil2100, there is no problem with the upgrade of powerd on mako because the configuration file is not mounted | 10:56 |
| jibel | unlike krillin or arale | 10:57 |
| jibel | sil2100, Mirv bug 1502093 | 10:57 |
| ubot5` | bug 1502093 in unity8 (Ubuntu) "unity8 crash on mako rc-proposed/ubuntu with latest unity8/mir/powerd" [Undecided,New] https://launchpad.net/bugs/1502093 | 10:57 |
| jibel | kgunn, ^ with silo 15 that landed yesterday on mako only | 10:57 |
| rvr | Mode argument was not provided or was set to an illegal value. Using default value of --mode= "full-greeter" | 10:58 |
| Mirv | jibel: thanks! right, so mako only which probably explains why it wasn't caught. | 10:58 |
| jibel | Mirv, thanks for catching it! | 10:58 |
| sil2100 | Still, we'll need this fixed | 10:58 |
| === chihchun is now known as chihchun_afk | ||
| oSoMoN | seb128, is it known and on purpose that https://code.launchpad.net/~seb128/ubuntu-system-settings/location-desktop-usr/+merge/272711 is in two silos? | 11:20 |
| kgunn | jibel: ack getting someone on it | 11:30 |
| jibel | kgunn, I didn't find anything useful but the phone is still in this state if someone needs more info | 11:32 |
| kgunn | jibel: but bascially we can just do a dist-upgrade and see the same thing right | 11:32 |
| kgunn | on rc-proposed | 11:32 |
| kgunn | rvr: is this relevant "Mode argument was not provided or was set to an illegal value. Using default value of --mode= "full-greeter"" | 11:33 |
| jibel | kgunn, yes | 11:34 |
| jibel | yes to install latest rc-proposed on mako + dist-upgrade | 11:34 |
| sil2100 | jibel, kgunn: I poked alf_ on ubuntu-mir already | 11:36 |
| kgunn | sil2100: thanks | 11:38 |
| seb128 | oSoMoN, unsure, to check with kenvandine, but if you want to land a silo with it feel free, we can rebuild the other one | 11:39 |
| Mirv | davmor2: trello claims 025 was moved to Under Testing in the Activity, but still it's in "Ready for Testing" on the board. it also has Blocked tag, and you mentioned it's working fine. Can you try to fix the status of the card? | 11:40 |
| davmor2 | Mirv: we will move the card once we know it is working with the ota test if that fails it needs to move over to failed | 11:41 |
| oSoMoN | seb128, none of them is mine, just saw it and I thought I would ask | 11:41 |
| Mirv | davmor2: thanks, I was just puzzled by the Trello showing contradicting information | 11:42 |
| oSoMoN | seb128, but I would need to add the branch to silo 59 if it didn’t land before that | 11:42 |
| davmor2 | Mirv: no worries there is a comment on the card but I'm happy to clarify :) | 11:42 |
| seb128 | oSoMoN, let's wait for kenvandine, we can maybe land the settings one today | 11:42 |
| oSoMoN | seb128, that’d be great | 11:43 |
| seb128 | unsure about the unity8-dash profile | 11:43 |
| seb128 | pstolowski, ^ what's the status of silo 3? | 11:43 |
| pstolowski | seb128, we need bigger fix as it uncovered an issue with location. tvoss is going to work on location service changes | 11:47 |
| seb128 | k | 11:47 |
| seb128 | so settings is going to be ready first most likely | 11:48 |
| === _salem is now known as salem_ | ||
| pstolowski | seb128, yeah, but we cannot release it as is. feel free to land you change at any point though | 11:56 |
| seb128 | right | 11:56 |
| davmor2 | Mirv: sorry I think we were talking at cross purposes, silo025 is under test now, silo 34 is the one that should have the mixed state | 12:04 |
| === alan_g is now known as alan_g|lunch | ||
| davmor2 | Mirv: silo34 is the one that is good and sil2100 will be landing in an image asap for me to test upgrades | 12:05 |
| sil2100 | Yeah, waiting on a preNEW review for 34 | 12:06 |
| Mirv | davmor2: no, I just meant that on my trello view 025 was in a different place than the activity showed, now it's corrcet | 12:08 |
| davmor2 | Mirv: so the blocked tag was removed because it has been rebuilt, it was therefore ready to test so I moved it to under testing because I'm testing it | 12:09 |
| Saviq | sil2100, should we pull the silo before it reaches an image? | 12:16 |
| Saviq | https://requests.ci-train.ubuntu.com/#/ticket/433 is the offending landing | 12:17 |
| sil2100 | Saviq: I think we could soft revert this, it only touches 2 projects | 12:23 |
| sil2100 | Let me try that, need to check if webbrowser-app is revertable still | 12:23 |
| * sil2100 got back from lunch | 12:23 | |
| Saviq | sil2100, no need to revert webbrowser even I think, it doesn't depend on new UITK it doesn't seem | 12:24 |
| sil2100 | I was worried by the merge description though, it being: "Do not select labels by their class name, as this is changing in the newest UITK." | 12:24 |
| Saviq | sil2100, I think the change (in webbrowser) is backwards compatible, and if it's not, someone's missing deps | 12:25 |
| sil2100 | Saviq: I guess anyway even if the AP test suddenly fails it's still better than having a broken image | 12:27 |
| Saviq | indeed | 12:27 |
| pmcgowan | Saviq, whats the deal? | 12:28 |
| Saviq | pmcgowan, latest UITK crashes QML (so unity8) on mako and flo | 12:29 |
| pmcgowan | thats bad | 12:29 |
| Saviq | https://launchpad.net/bugs/1502093 | 12:29 |
| ubot5` | Ubuntu bug 1502093 in ubuntu-ui-toolkit (Ubuntu) "UbuntuShape crash with latest UITK on mako/flo" [Undecided,Confirmed] | 12:29 |
| pmcgowan | that would have been my guess | 12:29 |
| Saviq | pmcgowan, greyback_'s suspecting driver bug at that point | 12:29 |
| pmcgowan | yep | 12:29 |
| Saviq | OTOH wily is fine | 12:31 |
| sil2100 | Good, then I'll only have to revert it for the overlay then? | 12:32 |
| sil2100 | I mean, for vivid-overlay | 12:32 |
| Saviq | sil2100, it's in wily overlay, too, let me verify quickly wily is indeed fine | 12:33 |
| sil2100 | Ah, right, this was already after the switch | 12:33 |
| pmcgowan | that wouldn't make sense to me | 12:34 |
| Saviq | +1, but that's what it looked like before, I was focused on unity8 at that point, so might've not paid enough attention | 12:36 |
| Saviq | so confirming on flo now | 12:36 |
| Saviq | and mako for good measure | 12:37 |
| Saviq | pmcgowan, off topic, did you hear about anyone losing the ability to adb into recovery on a manta (and hence the ability to flash it)? | 12:37 |
| * Saviq can sideload, flash in fastboot, and adb to android, but no adb to recovery :/ | 12:38 | |
| pmcgowan | Saviq, I have not | 12:38 |
| pmcgowan | Saviq, my manta goes into a funny loop witht he screenn flashing, and will never shut down | 12:38 |
| Saviq | pmcgowan, yup, saw that with flo as well | 12:38 |
| Saviq | as if some input caused it to wake up | 12:39 |
| pmcgowan | I suspect it needs an udpated device tarball | 12:39 |
| pmcgowan | if I could find someone to update them | 12:40 |
| Saviq | sil2100, pmcgowan, ah d'oh, no overlay on wily images yet, is why it was fine | 12:48 |
| Saviq | greyback_, ↑ | 12:51 |
| Saviq | sil2100, yup, wily+overlay broken, too | 12:51 |
| * sil2100 sighs | 12:54 | |
| sil2100 | Ok, I'll revert it too | 12:54 |
| sil2100 | First, vivid | 12:54 |
| === alan_g|lunch is now known as alan_g | ||
| === marcusto_ is now known as marcustomlinson | ||
| sil2100 | Saviq, Mirv, pmcgowan: reverting UITK vivid | 13:03 |
| Saviq | bzoltan_, ↑ | 13:04 |
| sil2100 | bzoltan_: ^ | 13:04 |
| sil2100 | hmmm, some strange things with the wily part I see | 13:09 |
| Mirv | sil2100: ok | 13:11 |
| kenvandine | oSoMoN, it shouldn't be in 2 silos :) | 13:15 |
| jhodapp | sil2100, can you please dput qtmultimedia source package from ppa:jhodapp/ubuntu/ppa to the silo 29 PPA? | 13:16 |
| sil2100 | jhodapp: sure, any re-versioning needed? | 13:16 |
| jhodapp | sil2100, also, is it possible to remove qtmultimedia from the silo 55 PPA? | 13:16 |
| kenvandine | oSoMoN, i created silo 49 for it yesterday | 13:16 |
| jhodapp | sil2100, shouldn't be any need | 13:16 |
| sil2100 | jhodapp: sure | 13:16 |
| oSoMoN | kenvandine, are you planning on landing silo 49 soon-ish ? | 13:17 |
| kenvandine | yes... after 41 | 13:17 |
| kenvandine | which is being verified right now | 13:17 |
| jhodapp | sil2100, trying to craft things in such a way that we can build indicator-sound and the source package for qtmultimedia in silo 29, then sync those two to silo 55 | 13:17 |
| Saviq | Mirv, sil2100, any updates on bug #1378245? with overlay citrain just dist-upgrades everything from the overlay ppa | 13:17 |
| ubot5` | bug 1378245 in phablet-tools (Ubuntu) "citrain could use a more accurate way to upgrade from silos" [High,In progress] https://launchpad.net/bugs/1378245 | 13:17 |
| oSoMoN | kenvandine, ok, thanks, so definitely in time for ota7, right? | 13:17 |
| kenvandine | oSoMoN, oh, it's in a silo with unity8 too | 13:18 |
| kenvandine | yeah, assuming qa verifies it in time :) | 13:18 |
| oSoMoN | kenvandine, yes, that’s why I was asking, it currently is in two silos… | 13:18 |
| kenvandine | oSoMoN, i'll make sure it's in ready for qa today | 13:18 |
| oSoMoN | cheers | 13:18 |
| kenvandine | it's unrelated to the unity8 fix in silo 3, so i'll remove it from that | 13:19 |
| rvr | kenvandine: Hey. Does adb reboot recovery work for you in arale? I'm trying to install lxc-android-config, and after adb reboot recovery, I can't adb shell to the device | 13:19 |
| kenvandine | rvr, no... you need to boot a special recovery | 13:19 |
| Saviq | kenvandine, what's in silo with unity8? | 13:19 |
| kenvandine | saviq some apparmor profile ? | 13:20 |
| kenvandine | rvr, but... jibel pointed out you can install lxc-android-config without recovery | 13:20 |
| rvr | kenvandine: jibel: With citrain or using another trick? | 13:21 |
| sil2100 | jhodapp: package removed and copied | 13:21 |
| sil2100 | Saviq: I don't have any news regarding that one sadly... | 13:21 |
| Saviq | kenvandine, I'm worried the package in silo 41 conflicted with a landing from yesterday | 13:21 |
| jibel | rvr, you unmount the file that breaks on upgrade then use citrin | 13:21 |
| kenvandine | just unmount something... | 13:21 |
| jibel | citrin | 13:21 |
| jibel | citrain* | 13:21 |
| rvr | jibel: Ok | 13:21 |
| Saviq | kenvandine, train says unity8 is dirty, and I'd say it's likely true | 13:21 |
| kenvandine | jibel, which file does he need to umount? | 13:21 |
| Saviq | there's too many peoples landing unity8 at the same time... | 13:22 |
| kenvandine | saviq: i'll rebuild unity8 in silo 41 | 13:22 |
| kenvandine | i already did that a couple times :) | 13:22 |
| kenvandine | we have to get that wizard fix in | 13:22 |
| kenvandine | Saviq, can i have a unity8 landing lock until rvr is done testing? :-D | 13:23 |
| jibel | kenvandine, I never remember which one is powerd which one is lxc-android-config, let me check | 13:23 |
| Saviq | kenvandine, yeah, sure, /me needs to start looking at silos in flight apparently | 13:23 |
| Saviq | robru, what's the workflow with conflicting silos these days? | 13:23 |
| kenvandine | /lib/udev/rules.d/70-android.rules | 13:24 |
| kenvandine | maybe that one? | 13:24 |
| jibel | kenvandine, /lib/udev/rules.d/70-android.rules | 13:24 |
| jhodapp | sil2100, thanks! | 13:24 |
| sil2100 | Saviq: I think everything is now handled by the 'silo is dirty' feature | 13:24 |
| kenvandine | rvr, sudo umount /lib/udev/rules.d/70-android.rules | 13:24 |
| Saviq | sil2100, /me worried that's too late | 13:25 |
| kenvandine | it won't let us publish if it's dirty | 13:25 |
| Saviq | yeah | 13:25 |
| Saviq | but that means you have to re-test | 13:25 |
| Saviq | and potentially QA, too | 13:25 |
| kenvandine | potentially | 13:25 |
| kenvandine | but depends on the change too | 13:25 |
| kenvandine | like silo 41 only changes one page of the wizard | 13:26 |
| pmcgowan | sil2100, dont bother with the change to the watchdog until I talk to tony | 13:26 |
| Saviq | kenvandine, well, sure, but what if the landing in the mean time changed it too, not even in a way that it conflicted VCS-wise, but runtime | 13:26 |
| kenvandine | sure | 13:26 |
| kenvandine | there is risk especially when APIs change, etc | 13:26 |
| Saviq | which is why I mean "silo dirty" is too late | 13:27 |
| Saviq | like with silo 22 it's not even dirty atm | 13:27 |
| kenvandine | rvr, so after you umount that file, you can use citrain to install | 13:28 |
| rvr | kenvandine: Thanks | 13:28 |
| sil2100 | Mirv, bzoltan_: hmmm... do you guys know what happened to the 1.3.1641+15.10.20150922-0ubuntu1 landing of UITK for wily? | 13:28 |
| Saviq | but we've spent a good hour testing it, and we'd conflict with you if we wanted to put it under QA | 13:28 |
| Saviq | now we're just gonna wait instead | 13:29 |
| Saviq | it's fine in this case because we investigated a UITK breakage most of the time | 13:29 |
| Saviq | but I'd be unhappy if we actually wanted to put it in under QA and only then realized there's another unity8 landing there first | 13:29 |
| kenvandine | Saviq, i guess you can search for silos with unity8 and check the status | 13:30 |
| kenvandine | and see there's another in ready for qa | 13:30 |
| kenvandine | but... maybe that should be kind of like the dirty flag | 13:30 |
| kenvandine | so you don't have to look for it | 13:30 |
| Saviq | kenvandine, not even ready for qa, anything in flight | 13:30 |
| Saviq | because someone else might be testing it by now | 13:30 |
| sil2100 | Mirv, bzoltan_: yyh, so it seems that landing was only released to vivid? | 13:30 |
| kenvandine | just show another silo is in the qa queue | 13:31 |
| Saviq | sil2100, ? | 13:31 |
| kenvandine | Saviq, true | 13:31 |
| Saviq | sil2100, https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay?field.series_filter=wily | 13:31 |
| Saviq | (if that's about uitk still) | 13:31 |
| sil2100 | Saviq: unrelated to the UITK regression, I'm talking about the previous UITK version | 13:31 |
| kenvandine | Saviq, but even more of an issue for silos that have already been tested, like 41 has been in ready for qa for 24 hours | 13:31 |
| Saviq | sil2100, right ok sry :) | 13:31 |
| sil2100 | Saviq: the previous one was a dual landing and only released to vivid (probably manually, I see errors in the publish job and a manual m&c) | 13:32 |
| sil2100 | And that makes me a sad panda! | 13:32 |
| Saviq | kenvandine, yeah, which is why I will be manually looking for conflicting silos from now on, but feels like some wasted manhours | 13:32 |
| sil2100 | Mirv, bzoltan_: uuuh, and I see that the latest UITK-gles version is older than the UTIK main version that got released! | 13:34 |
| sil2100 | Mirv, bzoltan_: that's bad | 13:34 |
| bzoltan_ | sil2100: I am no sure what does that happen? | 13:35 |
| sil2100 | Mirv, bzoltan_: generally it's safer when normal and -gles packages have the same versions, as some packages can hard-dep on the specific version | 13:35 |
| sil2100 | And if -gles has a lower one, it can cause a FTBFS | 13:36 |
| sil2100 | Anyway, trying to revert it as well | 13:36 |
| sil2100 | bzoltan_: anyway, this means that whenever you rebuild UITK in a silo, be sure to also re-build the -gles version | 13:38 |
| Mirv | sil2100: it might be this was the webbrowser-app rebuild that bzoltan_ didn't do | 13:40 |
| Mirv | sil2100: if it wasn't run by specifying webbrowser-app only | 13:40 |
| Mirv | sil2100: 20150922 was when gcc was broken, so it was on purpose only released to vivid, to catch up with the next release | 13:41 |
| sil2100 | Ok | 13:41 |
| sil2100 | Actually | 13:42 |
| sil2100 | hah, I'll revert the wily versions by removing the wily packages from the overlay! | 13:42 |
| sil2100 | Since it's the first wily-overlay release | 13:42 |
| sil2100 | phew, saves me some time | 13:42 |
| kenvandine | seb128, i'm about to land the silo with all those new packages i had you review months ago :) | 13:42 |
| seb128 | kenvandine, \o/ | 13:42 |
| seb128 | kenvandine, lucasz pinged me to preNEW review earlier | 13:43 |
| seb128 | trying to have a look today still | 13:43 |
| kenvandine | seb128, you already did that :) | 13:43 |
| sil2100 | kenvandine: the buteo silo? | 13:43 |
| kenvandine | you've reviewed all of these already :) | 13:43 |
| seb128 | yeah, unsure if things changed since | 13:43 |
| kenvandine | sil2100, yes | 13:43 |
| kenvandine | not packaging | 13:43 |
| seb128 | good | 13:43 |
| sil2100 | Yeah, I asked seb128 to do a preNEW review :) | 13:43 |
| seb128 | so one thing less to do ;-) | 13:43 |
| kenvandine | really what's changed was our existing packages using it | 13:43 |
| sil2100 | If it's good, then please release! | 13:43 |
| kenvandine | i am :) | 13:44 |
| kenvandine | bfiller, renatu: i clicked publish on silo 34! long time coming :) | 13:44 |
| bfiller | kenvandine: woohooo! | 13:45 |
| renatu | kenvandine, \o/, thanks | 13:45 |
| kenvandine | DON! | 13:45 |
| kenvandine | DOH! | 13:45 |
| * renatu runs | 13:45 | |
| kenvandine | one package has an unbuilt revision :) | 13:45 |
| kenvandine | indicator-transfer-buteo | 13:45 |
| renatu | kenvandine, what is that? | 13:46 |
| kenvandine | Revert cmake-extras usage. | 13:46 |
| kenvandine | is the commit message | 13:46 |
| kenvandine | not built in the silo | 13:46 |
| * kenvandine rebuilds | 13:46 | |
| brendand | kenvandine, who's don and what did he do? | 13:49 |
| kenvandine | haha | 13:49 |
| Trevinho | trainguards, what's wrong here https://ci-train.ubuntu.com/job/ubuntu-landing-008-1-build/304/consoleFull ? network issues? | 13:49 |
| sil2100 | Trevinho: hm, no, that looks like an error when building the package | 13:54 |
| sil2100 | I'll look at it in a moment | 13:54 |
| Trevinho | sil2100: thanks, it went fine on previous rebuilds, not sure what happened | 13:55 |
| rvr | kenvandine: Did you see this when installing lxc-android-config? http://paste.ubuntu.com/12638463/ | 13:55 |
| sil2100 | Trevinho: you didn't change anything in the packaging, right? | 13:56 |
| kenvandine | cp: cannot stat ‘/usr/lib/lxc-android-config/70-arale.rules’: No such file or directory | 13:56 |
| kenvandine | not sure about that, i tested on mako | 13:56 |
| kenvandine | the other messages are normal | 13:57 |
| Trevinho | sil2100: nope, I just triggered a rebuild since mesa fixed an issue that caused us to fail testing on ppc64el | 13:57 |
| kenvandine | jibel, ^^ thoughts? sorry, you seem to know more about testing lxc-android-config than i do :) | 13:57 |
| sil2100 | Trevinho: could you re-build again? I suppose it might be something transient - if not, I'll then dig deeper | 13:58 |
| Trevinho | ok | 13:58 |
| jibel | kenvandine, you don't need that on mako only krillin and arale | 14:00 |
| kenvandine | right | 14:00 |
| kenvandine | just what should rvr do about that error? | 14:01 |
| jibel | kenvandine, when you upgrade lxc-android-config on mako how does it fail? | 14:01 |
| kenvandine | nope | 14:01 |
| kenvandine | it doesn't fail | 14:01 |
| kenvandine | although i did it in recovery | 14:01 |
| jibel | it's all good then :) | 14:01 |
| kenvandine | rvr saw that in his testing on arale | 14:01 |
| rvr | Yup | 14:01 |
| rvr | jibel: That was doing a manual pinning and apt-get upgrade | 14:01 |
| jibel | rvr, silo 41? | 14:02 |
| rvr | jibel: Yes | 14:02 |
| jibel | rvr, that pastebin is when you installed from recovery? | 14:04 |
| jibel | rvr, or a full session | 14:04 |
| jibel | ? | 14:04 |
| rvr | jibel: Nope, pinning and upgrade | 14:04 |
| rvr | full session | 14:05 |
| jibel | let me try | 14:05 |
| Trevinho | sil2100: went good ^ | 14:07 |
| sil2100 | \o/ | 14:10 |
| jibel | rvr, your pastebin is strange, this is error you should get if the file is still mounted http://paste.ubuntu.com/12638536/ | 14:12 |
| rvr | jibel: I unmounted the file | 14:12 |
| rvr | That error is expected | 14:13 |
| jibel | rvr, yeah, what is the problem then? | 14:15 |
| rvr | jibel: If you unmount the file and install the package, do you see the warnings that I got? | 14:15 |
| jibel | rvr, yes | 14:16 |
| rvr | Ok. So my question is if they are harmless or not. | 14:16 |
| jibel | rvr, it's telling you that it doesn't remove non-existing diversions and doesn't touch already existing diversions | 14:19 |
| rvr | jibel: There is also "cp: cannot stat ‘/usr/lib/lxc-android-config/70-arale.rules’: No such file or directory" | 14:20 |
| Saviq | Ursinha, hey, are you guys having stakeholder meetings these days? | 14:42 |
| Ursinha | Saviq: nope; we have two different squads now: tanuki, that works on snappy product integration, and kitsune, that works on jenkaas and legacy CI | 14:43 |
| Ursinha | Saviq: what would you need? | 14:43 |
| Saviq | Ursinha, I'd need kitsune, then, wanted to bump the heat on staging branch support in ci-train and legacy CI / jenkaas in the future | 14:45 |
| Saviq | smaller projects like qtmir get bitten by conflicts between MPs quite a lot | 14:45 |
| Ursinha | Saviq: ci-train isn't really kitsune, for legacy CI we're not taking feature requests, but focusing on handing over jenkaas instances to teams so they can fix the problems they understand way better than we do :) btw, mir is the next one in line | 14:46 |
| Ursinha | I'll be sending weekly emails for the people waiting for jenkaas so it's clearer what's up next | 14:47 |
| Saviq | Ursinha, must say I don't agree with the idea of jenkaas, not outside of quite specific environment requirements | 14:47 |
| Ursinha | Saviq: why so? | 14:48 |
| Saviq | we were supposed to converge on autopkgtests for all that it can be used for, I don't see why we'd need to maintain our own CI jobs for that | 14:48 |
| Saviq | and everyone will be solving the same problems separately | 14:49 |
| Ursinha | Saviq: we are providing example jobs for whoever is using jenkaas, what we finally acknowledged is that the former CI team was a bottleneck and it just couldn't scale for the number of teams using the infrastructure | 14:51 |
| Saviq | Ursinha, well, sure, but the example jobs are one-off, then every team will solve their problems for themselves, when other teams could benefit from that | 14:52 |
| Ursinha | we noticed all jobs *look* the same but they actually aren't :) most have specifics for testing and it creates a lot of overhead | 14:52 |
| Saviq | Ursinha, that's likely because we never had a common denominator, which autopkgtests are supposed to be | 14:53 |
| Ursinha | (not that I'm in a position to change jenkaas plans, this is my understanding of the reasoning for this -- the best person for that is beuno (that isn't here)) | 14:53 |
| === chihchun_afk is now known as chihchun | ||
| Saviq | anyway, I understand this is basically a done deal, we'll just have to agree to disagree | 14:54 |
| Saviq | IMO it will cause more troubles than solve | 14:54 |
| Ursinha | Saviq: some tests require different slave configurations, and it's really hard to be reliable and diverse | 14:54 |
| Saviq | Ursinha, key word is "some" | 14:55 |
| Saviq | Ursinha, for those, jenkaas is probably a solution, for *most* projects we just need some CPU | 14:55 |
| Ursinha | Saviq: I hope not (cause more troubles than solve), I think it's a bet to try and solve the previous problem we already knew existed, that is CI not being as close as acceptable to attend all stakeholders | 14:55 |
| Saviq | Ursinha, dumping the work on the stakeholders, which is what jenkaas feels to be, isn't a solution IMO | 14:56 |
| Ursinha | not saying is perfect | 14:56 |
| Ursinha | Saviq: do you have any suggestions? honestly asking | 14:56 |
| Saviq | Ursinha, I probably don't have enough background (didn't hear all the requirements you did), but doesn't autopkgtest fall under the same exact problem? and we've not dropped that, but consequently extend it to cater for more and more common needs? | 14:58 |
| Ursinha | it's not really dumping work on stakeholders because we're not turning our backs to the existing situation; we're making sure we can move the existing setting to a more reliable setup, that can be IS maintained | 14:58 |
| Ursinha | we're just not committing to new feature work | 14:58 |
| abeato__ | Laney, hey, I need some help to upload a source package to silo 28 | 14:59 |
| abeato__ | Laney, concretely https://chinstrap.canonical.com/~abeato/gst-plugins-bad1.0/ | 14:59 |
| Saviq | Ursinha, that's hardware, but maintaining what runs on that hardware, above jenkins instances, you're ultimately leaving to respective teams | 15:00 |
| Saviq | Ursinha, unless I misunderstand and you'll be maintaining the jobs running on jenkaas | 15:00 |
| Saviq | I'm just worried this will lead to even more fragmentation and we'll never get testing on silos, images, every project will just test themselves without a holistic approach | 15:01 |
| Saviq | I just was under the impression that our target was autopkgtests as a standard wherever possible | 15:02 |
| Ursinha | Saviq: hardware is maintained by the certification team | 15:03 |
| Ursinha | Saviq: the whole idea is to separate the concerns as close to the expertise as possible | 15:03 |
| Saviq | Ursinha, and I disagree with that idea, because that makes me effectively unable to test another project without learning how they do it | 15:04 |
| charles | Wellark, does ^ have the more-cleanups branch? | 15:04 |
| Ursinha | this means we're handling the "testing silos" around the products, so you can ensure the tests will cover the desired product, not the isolated parts like happens now | 15:04 |
| Saviq | not sure I understand | 15:05 |
| Ursinha | the tests are currently conflated in a way we think they are cohesive but they are only sharing the same jenkins | 15:05 |
| Saviq | Ursinha, in a jenkaas world, if I want to release 10 MPs for unity8 along with 5 MPs for mir and 1 for UITK, how do I test that silo coherently? | 15:05 |
| Ursinha | Saviq: you're talking about ci-train, right? how do you do that today? | 15:06 |
| Saviq | Ursinha, I can't, that's the problem | 15:06 |
| Saviq | Ursinha, I need to run all the test suites manually, following the manual test plans | 15:06 |
| Ursinha | so jenkaas won't cause a problem, it will only not solve it (ultimately, I'm not saying this is entirely true) | 15:07 |
| Saviq | Ursinha, there's no auto-testing done on silos, and I can't see how it will happen with jenkaas, where every team has separate jobs that don't think about the world | 15:07 |
| Saviq | Ursinha, oh it will totally cause problems, because it will fragment how we run tests even more | 15:07 |
| Ursinha | Saviq: ci-train is apart from what we're doing with jenkaas, I think this is the misunderstanding | 15:07 |
| Saviq | Ursinha, no, don't think about ci-train, just think about testing multiple projects that need to be released together | 15:08 |
| Ursinha | that's what ci-train is about, no? | 15:08 |
| Ursinha | integrating changes into the product? | 15:08 |
| Saviq | it's just one solution that we currently use | 15:08 |
| Saviq | Ursinha, what I'm asking is, after building (today in citrain, later in ciairline or some other solution) | 15:09 |
| Ursinha | Saviq: I can appreciate the problems you understand exist and I don't, I don't want to give you the impression I'm disregarding what you're saying | 15:09 |
| Saviq | Ursinha, what I want to convey is that I think the jenkaas approach will have a detrimental effect on our testing abilities | 15:09 |
| Saviq | because with every team maintaining their own testing environment, there will be no way of putting multiple teams' projects to test in one go | 15:10 |
| Ursinha | and I can understand that | 15:10 |
| Ursinha | but there are other problems that exist that we have to fix, and jenkaas is a tentative solution for some of them, I don't think we ever thought we would be fixing all of the existing missing features with that | 15:11 |
| Saviq | Ursinha, but you say that jenkaas is effectively the only road planned going forward (as legacy ci jobs will not be developed, just maintained) | 15:12 |
| abeato__ | robru, could you upload a rource package to silo 28 ? | 15:13 |
| abeato__ | *source | 15:13 |
| Ursinha | Saviq: for the legacy CI yes | 15:13 |
| Ursinha | Saviq: that's beuno plan | 15:13 |
| Ursinha | Saviq: jenkaas is ultimately a self-service jenkins, that gives you the ability to use hardware from the lab if needed; thinking now I don't see a reason not to have a jenkaas instance to run such integration jobs | 15:13 |
| abeato__ | robru, https://chinstrap.canonical.com/~abeato/gst-plugins-bad1.0/ | 15:13 |
| Saviq | Ursinha, ok I'll raise this with other folk, thanks | 15:15 |
| Ursinha | Saviq: more than that I think we need to involve beuno in the conversation | 15:15 |
| Saviq | yeah, that's my plan | 15:15 |
| charles | :P | 15:16 |
| Wellark | charles: no idea | 15:18 |
| rvr | kenvandine: There is something fishy | 15:18 |
| kenvandine | :/ | 15:18 |
| rvr | kenvandine: Do you have silo 41 installed? | 15:19 |
| kenvandine | yes | 15:19 |
| rvr | kenvandine: Ok, reboot the phone. Then, go to bluetooth indicator and tap on "Bluetooth settings" | 15:19 |
| rvr | kenvandine: Then, open the network indicator and tap on "Wifi settings" | 15:20 |
| kenvandine | rvr, done... both worked fine | 15:20 |
| rvr | kenvandine: The second time it is opened, the title is gone from system settings | 15:20 |
| kenvandine | not for me | 15:20 |
| rvr | kenvandine: Which image are you using? | 15:20 |
| kenvandine | and that really couldn't be from silo 41 | 15:20 |
| kenvandine | rvr, mako r41 | 15:21 |
| rvr | kenvandine: the report switch works fine | 15:21 |
| kenvandine | rvr, the only change to settings in this silo is fixing the property used for setting auto reporting of crashes | 15:21 |
| kenvandine | it was using canReportCrashes instead of AutoReportCrashes | 15:22 |
| kenvandine | nothing else changed in settings | 15:22 |
| jibel | rvr, btw the error message when you install lxc-android-config is harmless. It is not displayed in recovery because the script doesn't even reach this line, and with the session it fails. So the result is the same | 15:22 |
| rvr | jibel: Ok, thanks | 15:22 |
| kenvandine | rvr, but let me try the same steps on my arale | 15:22 |
| rvr | kenvandine: I'm going to investigate this without the silo | 15:22 |
| kenvandine | also fine on my arale | 15:23 |
| kenvandine | title is showing | 15:23 |
| kenvandine | arale r128 | 15:23 |
| kenvandine | rvr, thx | 15:23 |
| kenvandine | so you get to the wifi page, just the title is blank? | 15:23 |
| rvr | kenvandine: At some point, the indicators don't even open system settings | 15:23 |
| rvr | kenvandine: sound indicator | 15:24 |
| kenvandine | url-dispatcher problems? | 15:24 |
| kenvandine | dunno | 15:24 |
| kenvandine | sound indicator just launched it here | 15:24 |
| rvr | kenvandine: I had crashes from the indicators | 15:24 |
| kenvandine | good, so crash files? | 15:24 |
| kenvandine | that would be super useful | 15:24 |
| kenvandine | and what crashed? the indicator services? url-dispathcer? settings? | 15:25 |
| rvr | services | 15:25 |
| rvr | _usr_lib_arm-linux-gnueabihf_indicator-sound_indicator-sound-service.32011.crash | 15:25 |
| kenvandine | ok, i haven't seen those crash | 15:25 |
| rvr | _usr_lib_arm-linux-gnueabihf_indicator-power_indicator-power-service.32011.crash | 15:25 |
| kenvandine | interesting | 15:25 |
| rvr | _usr_lib_arm-linux-gnueabihf_indicator-network_indicator-network-service.32011.crash | 15:25 |
| kenvandine | file those bugs | 15:26 |
| rvr | DuplicateSignature: /usr/lib/arm-linux-gnueabihf/indicator-network/indicator-net | 15:26 |
| rvr | work-service:url-dispatcher-bad-url | 15:26 |
| kenvandine | ah, i think maybe your url-dispatcher db might be hosed | 15:27 |
| kenvandine | rvr, so silo 41 is good? | 15:27 |
| jibel | rvr, did you try to enable apport, remove the flag ( kenvandine will tell you which) replace rc-proposed by stable in channel.ini and reboot, then change the autoreporting setting and reboot again | 15:27 |
| kenvandine | rvr, i think there's a bug about that db getting out of whack | 15:27 |
| jibel | rvr, there is specific code if the channel is stable or rc-proposed | 15:28 |
| kenvandine | you can edit /etc/system-image/channel.ini and replace rc-proposed with stable | 15:28 |
| rvr | jibel: kenvandine: The test that I did was to enable/disable appport switch in system settings and SIGSEGV gallery app, and looked whether appport was triggered or not | 15:29 |
| kenvandine | then remove /var/lib/apport/.apport-config-has-run | 15:29 |
| kenvandine | that's a good test too | 15:29 |
| kenvandine | but testing the default when on stable is good | 15:29 |
| kenvandine | after removing the file, reboot | 15:29 |
| kenvandine | when the device boots, you should see only one file in that dir | 15:30 |
| kenvandine | /var/lib/apport/.apport-config-has-run | 15:30 |
| kenvandine | not /var/lib/apport/autoreport | 15:30 |
| rvr | Looking | 15:31 |
| rvr | kenvandine: Only that file | 15:32 |
| rvr | -rw-r--r-- 1 root root 0 Oct 2 15:32 .apport-config-has-run | 15:32 |
| kenvandine | great | 15:32 |
| kenvandine | :) | 15:32 |
| kenvandine | also | 15:32 |
| kenvandine | cat /proc/sys/kernel/core_pattern | 15:32 |
| kenvandine | should just contain "core" | 15:33 |
| rvr | /bad_core_pattern | 15:33 |
| kenvandine | rvr, it shouldn't container apport | 15:33 |
| jibel | rvr, /bad_core_pattern is fine, it means apport didn't set it up | 15:34 |
| kenvandine | yeah | 15:35 |
| kenvandine | good to go! | 15:35 |
| rvr | Ok | 15:35 |
| kenvandine | sil2100, exception publishing 34 :( | 15:35 |
| jibel | sil2100, did you revert uitk? | 15:35 |
| sil2100 | jibel: yeah, I hope so | 15:35 |
| sil2100 | kenvandine: uuuh? | 15:35 |
| sil2100 | robru: ^ | 15:35 |
| jibel | davmor2, how far are you from laindg 25? | 15:36 |
| sil2100 | kenvandine: I think it published good, just the final status steps failed | 15:36 |
| jibel | landing* | 15:36 |
| dobey | trainguards: isn't there some way to force ci train to merge branches in the order listed in the request? | 15:49 |
| jhodapp | sil2100, to build the two packages in silo 55 and then to sync silo 29's contents into 55, what do I need to do? | 15:58 |
| Laney | abeato__: can do in a bit | 16:04 |
| Laney | abeato__: I'm getting build failures from the arm-dev PPA, is that related? | 16:04 |
| Laney | also, can you put it somewhere that's not behind SSO please? | 16:04 |
| Laney | annoying to download it from there | 16:04 |
| Laney | and presumably not secret if you want it on a public PPA :) | 16:05 |
| sil2100 | jibel, davmor2: since it's close to EOD... let me maybe build the buteo stuff in rc-proposed, since I don't think I'll be around to switch the channels back once it's built | 16:05 |
| kenvandine | sil2100, so you think silo 34 published fine? | 16:05 |
| kenvandine | looks like it's all there in the overlay ppa | 16:05 |
| sil2100 | kenvandine: yeah, I think it only didn't get merged - I see all the packages in the overlay | 16:05 |
| kenvandine | ok | 16:06 |
| kenvandine | i'll merge | 16:06 |
| sil2100 | jhodapp: once you build all the packages in silo 29 then I a simple build should build everything | 16:06 |
| sil2100 | jhodapp: but I would do that when the -gles packages are inside as well | 16:06 |
| jhodapp | sil2100, yeah I don't fully understand the -gles part | 16:07 |
| rvr | kenvandine: jibel: I can't reproduce the crashes. But there is problem opening system-settings from indicators in image 129. Filling bug report. | 16:08 |
| rvr | kenvandine: jibel: It's related, some how, to report settings page. | 16:08 |
| sil2100 | jhodapp: the -gles packages have usually the same contents as the main ones but different packaging - those are used for x86/amd64 systems | 16:08 |
| jhodapp | sil2100, yeah, so last time I did a qtmultimedia landing I didn't have to do anything with -gles | 16:10 |
| davmor2 | jibel: 25 passed on arale now I`m testing on krillin it is looking god here too so not too long | 16:10 |
| jhodapp | should be the same for this landing | 16:10 |
| sil2100 | jhodapp: usually Mirv handled the -gles bits for Qt packages I suppose | 16:11 |
| kenvandine | rvr, oh i see something weird with the indicators on 129 | 16:11 |
| jhodapp | sil2100, that's probably what happened, yeah | 16:11 |
| kenvandine | rvr, when i open any of the settings pages, it doesn't hide he indicator | 16:12 |
| rvr | kenvandine: o_O | 16:12 |
| kenvandine | but under the indicator, it is switching to the right settings page | 16:12 |
| kenvandine | that isn't happening on my mako with image 41 | 16:12 |
| rvr | kenvandine: Doesn't hide indicator or doesn't show settings? | 16:12 |
| kenvandine | that has to be an indicator bug, in unity8 | 16:12 |
| kenvandine | doesn't hide the indicator | 16:12 |
| rvr | kenvandine: Oh, haven't seen that | 16:12 |
| kenvandine | settings changes to the right page under the indicator | 16:12 |
| kenvandine | but the indicator is over top | 16:13 |
| kenvandine | if i swipe the indicator away, settings is showing the right page | 16:13 |
| kenvandine | it's happening on all of them | 16:13 |
| kenvandine | rvr, ok.. weird | 16:14 |
| kenvandine | i rebooted | 16:14 |
| kenvandine | now it's working properly again | 16:14 |
| kenvandine | indicator hides when the page changes in settings | 16:15 |
| kenvandine | so the shell must have been in some funky state or something | 16:15 |
| === chihchun is now known as chihchun_afk | ||
| kenvandine | rvr, but none of that weirdness is related to silo 41 | 16:18 |
| rvr | https://bugs.launchpad.net/canonical-devices-system-image/+bug/1502223 | 16:19 |
| ubot5` | Ubuntu bug 1502223 in ubuntu-system-settings (Ubuntu) "Delay in opening system-settings from indicators" [Undecided,New] | 16:19 |
| rvr | kenvandine: Yeah, I don't think so | 16:19 |
| abeato__ | Laney, well, I did not have any other place to upload :) | 16:19 |
| rvr | kenvandine: But it's weird that, for me, to trigger this bad behavior, I have to go to report settings page | 16:20 |
| abeato__ | Laney, yes the failures are related: the problem is that it won't build in vivid, only in vivid+overlay ppa | 16:20 |
| abeato__ | Laney, which is really annoying | 16:20 |
| kenvandine | rvr, it's possible the crash report settings page has some bugs, i don't think it's been used much | 16:21 |
| kenvandine | considering before my fix in silo 41, it was reading the wrong property on dbus :) | 16:21 |
| kenvandine | it changed the correct property, but read the wrong one :) | 16:22 |
| jibel | sil2100, once silo 25 and 41 land can you trigger an image so we have a build with all the fixes for the week end? | 16:22 |
| rvr | kenvandine: How can the report settings page interfere with the url-dispatcher or indicators? | 16:22 |
| Laney | abeato__: lillypilly.canonical.com:public_html/ | 16:22 |
| abeato__ | Laney, but nonetheless you can download it from ppa:canonical-arm-dev | 16:22 |
| Laney | that's people.canonical.com | 16:22 |
| kenvandine | rvr, it can't | 16:22 |
| kenvandine | nothing in system-settings can really | 16:22 |
| Laney | but I suppose I can scp it | 16:22 |
| sil2100 | jibel: sure, I should be around for a quick image build - I already kicked one for buteo | 16:23 |
| rvr | kenvandine: But I can reproduce this problem | 16:23 |
| sil2100 | But I can kick one later | 16:23 |
| abeato__ | Laney, thanks, I'll try uploading to that other place too anyway | 16:23 |
| kenvandine | rvr, that other bug you has to be url-dispatcher | 16:23 |
| rvr | kenvandine: So something is going on :-/ | 16:23 |
| kenvandine | yeah, i think your url-dispatcher db is messed up somehow | 16:23 |
| kenvandine | it's been happening more and more lately, it seems | 16:23 |
| rvr | kenvandine: I have reflashed the phone | 16:23 |
| rvr | kenvandine: There is no silo 41 here | 16:23 |
| kenvandine | with wipe? | 16:24 |
| rvr | kenvandine: Yes | 16:24 |
| kenvandine | but since then you aren't getting the crash caused by url-dispatcher | 16:24 |
| kenvandine | i think the other thing you reported is different | 16:24 |
| davmor2 | jibel: I found my first issue using the tablet as a desktop replacement I can`t move tickets on the trello board :( | 16:24 |
| kenvandine | the crashes you were seeing was because it couldn't looking the handler in url-dispatcher | 16:24 |
| kenvandine | this delay thing is different | 16:25 |
| rvr | kenvandine: Yeah, I see no title disappearance problem | 16:25 |
| abeato__ | Laney, http://people.canonical.com/~abeato/gst-plugins-bad1.0/ | 16:25 |
| rvr | There aren't crashes now | 16:25 |
| kenvandine | because the db got wiped :) | 16:25 |
| Laney | thx | 16:25 |
| jibel | davmor2, are you logged into trello? | 16:26 |
| jhodapp | sil2100, ok package version number issue here, why does it have an issue with the standard qtmultimedia version format? https://ci-train.ubuntu.com/job/ubuntu-landing-055-1-build/39/console | 16:27 |
| sil2100 | jhodapp: argh, crap, yeah... damn, manual uploads aren't handled by syncs, we'll need someone to copy the package there for you | 16:27 |
| sil2100 | But in this case it needs to be re-versioned | 16:28 |
| Laney | abeato__: can you remember where ubuntu7 is? | 16:28 |
| Laney | doesn't appear to be in the overlay ppa | 16:28 |
| jhodapp | sil2100, yeah ugg, in which case I should probably just move everything into silo 55 if I'm going to bump the version number of qtmultimedia | 16:28 |
| abeato__ | Laney, never arrived there, only in wily | 16:28 |
| jhodapp | sil2100, let me just do that | 16:28 |
| sil2100 | jhodapp: I'm a bit EODish right now - I can help you with that but only in some minutes sadly | 16:28 |
| jhodapp | and you can dput qtmultimedia into silo 55 | 16:28 |
| kenvandine | rvr, so can we pass silo 41? | 16:28 |
| abeato__ | Laney, latest in vivid and overlay is ubuntu2 I think | 16:29 |
| jhodapp | sil2100, sure no worries, I'll ping you when I've bumped the version | 16:29 |
| abeato__ | Laney, this updates to ubuntu7 + a bug fix | 16:29 |
| sil2100 | jhodapp: thanks :) I can do the copies then and assist you with the landing itself | 16:29 |
| jhodapp | sil2100, awesome thanks | 16:29 |
| abeato__ | Laney, the update is needed to get these changes in ubuntu-platform | 16:29 |
| Laney | ok | 16:29 |
| abeato__ | Laney, ubuntu2 does not compile now in the ppa because of that change | 16:29 |
| Laney | I just wanted to see the diff | 16:30 |
| jhodapp | sil2100, ok version bumped, you can dput from here ppa:jhodapp/ubuntu/ppa into silo 55 when you get a chance | 16:32 |
| davmor2 | jibel: sorted I can move it via the ticket itself it does however add it to the bottom of the queue :) | 16:41 |
| davmor2 | jibel: so 25 passed, I have no issue with the proximety sensor here though | 16:42 |
| davmor2 | jibel: on dogfood or rc-proposed | 16:42 |
| Mirv | (lurking) so which was the next webbrowser-app landing to land? 059 seems ota-8? | 16:44 |
| Mirv | there's still 5 webbrowser landings... | 16:45 |
| Mirv | dbarth_: is there a rough order for silos 059, 044, 005, 017 and 001 webbrowser landings? | 16:46 |
| Laney | abeato__: landing-028 yes? | 16:47 |
| abeato__ | Laney, yes | 16:48 |
| rvr | kenvandine: Approving silo 41 | 16:49 |
| kenvandine | rvr, thx | 16:49 |
| rvr | kenvandine: No crashes after reinstalling the silo | 16:49 |
| rvr | kenvandine: But there is something weird with the Report settings page, take a look to the bug report | 16:50 |
| kenvandine | yeah, those crashes were caused by a corrupt db, i'm quite sure... no idea how they got messed up though so quickly | 16:50 |
| kenvandine | rvr, will do | 16:50 |
| kenvandine | or maybe jgdx can look at it, since i'll be gone next week :) | 16:50 |
| rvr | kenvandine: Holidays? | 16:50 |
| kenvandine | yup! | 16:50 |
| rvr | kenvandine: Enjoy!! | 16:50 |
| davmor2 | sil2100: so building in rc-proposed then dude right? | 16:51 |
| kenvandine | heading to universal studios for a week! | 16:51 |
| * kenvandine is excited | 16:51 | |
| sil2100 | davmor2: yeah, it's still building tho! | 16:51 |
| rvr | kenvandine: Greetings to Harry Potter! ;) | 16:51 |
| kenvandine | indeed | 16:51 |
| kenvandine | jgdx, can you take a peek at bug 1502223 ? | 16:51 |
| ubot5` | bug 1502223 in ubuntu-system-settings (Ubuntu) "Delay in opening system-settings from indicators" [Undecided,New] https://launchpad.net/bugs/1502223 | 16:51 |
| kenvandine | while i'm out | 16:51 |
| jhodapp | sil2100, just let me know when you've done the dput into silo 55 so I can kick off the build | 16:52 |
| sil2100 | jhodapp: doing it now :) One moment | 16:52 |
| sil2100 | jhodapp: hm, ok, you bumped the version but built it for vivid? | 16:53 |
| sil2100 | jhodapp: you wanted this package in wily, right? | 16:53 |
| jhodapp | sil2100, no, vivid | 16:53 |
| sil2100 | jhodapp: ah, ok | 16:54 |
| davmor2 | sil2100 no worries just checking I have a horrible feeling that I might be end of day, which I hope isn`t the case | 16:54 |
| dobey | i guess not? | 16:55 |
| sil2100 | jhodapp: ok, copy done, it should pop up soon | 16:57 |
| jhodapp | sil2100, nice thanks! | 16:58 |
| jhodapp | hopefully everything is happy now | 16:58 |
| sil2100 | yw :) | 16:59 |
| === alan_g is now known as alan_g|EOW | ||
| Laney | abeato__: done | 17:02 |
| Laney | goodnight! | 17:02 |
| abeato__ | Laney, thanks! | 17:02 |
| * Mirv -> movie | 17:03 | |
| dobey | hmm | 17:20 |
| kenvandine | trainguards: silo 41 is in the abyss, but it's dual landing and all the packages are in the overlay ppa for both wily and vivid | 17:38 |
| kenvandine | is citrain waiting for them in wily-proposed? | 17:38 |
| === pat__ is now known as pmcgowan | ||
| sil2100 | kenvandine: I think that's a bug in the train still after yesterday's changes | 17:46 |
| sil2100 | robru: ^ | 17:46 |
| kenvandine | that's my thinking too | 17:47 |
| * kenvandine merges | 17:47 | |
| robru | sil2100: kenvandine: yeah I'm not sure why that's happening, will take a look | 18:36 |
| dobey | trainguards: isn't there some way to force ci train to merge branches in the order listed in the request? | 18:40 |
| robru | dobey: no. if you are not happy with the order the branches are being merged, remove the prerequisites from your MPs | 18:48 |
| dobey | the prerequisites are there for a reason. what i'm not happy with is having added a new branch, and rebuilding, and it gets merged before a much earlier branch, and causes a conflict. | 18:50 |
| dobey | i guess i'm going to have to merge them all into one big branch and use that for the silo then | 18:50 |
| robru | dobey: the merge-ordering logic just merges prerequisites before the ones that require them. | 18:54 |
| robru | dobey: does the new branch not have any prerequisites? maybe define the earlier one as a prerequisite then | 18:55 |
| dobey | it does have it defined | 18:55 |
| robru | dobey: you must have two independent chains of prerequisites then | 18:55 |
| dobey | the problem is when you end up with two branches of prerequisites, and they're not all in one single chain | 18:55 |
| robru | dobey: if you switch the order of the "leaf" nodes the rest should fall into line | 18:56 |
| dobey | it'll probably be easier for me to just make a new branch that contains all the others at this point | 18:57 |
| robru | dobey: I'm considering just ripping this sorting logic out since this is the second complaint I've had in 2 days (after a year of nobody complaining, sigh) | 18:58 |
| dobey | we have like 35 MPs now :-/ | 18:58 |
| dobey | robru: i'm not really complaining. i just thought there used to be some way to force it to use the order listed in the request | 18:58 |
| dobey | and my case is hardly the norm (at least, it shouldn't be. if it is, we have much larger problems than the prerequisite ordering) | 18:59 |
| robru | dobey: there did used to be a way to force that, but only because the sorting algo used to be so bad that it would randomly shuffle your merges if you didn't define any prereqs. when I cleaned up the algo to preserve the order of branches that don't define prereqs, I took away that option. that was a whole year ago | 18:59 |
| dobey | oh | 19:00 |
| dobey | i'm not sure it would fix my issues here, but i think it would have made them clearer if i could have done that | 19:00 |
| robru | dobey: you may not be "complaining" but I'm getting the impression that the train is hurting more than it's helping. the algo is only there to "help" you get your merges in the right order. | 19:01 |
| dobey | anywya, i guess i'll just make one big MP for this, as it will make it easier, especially since i'm sure we'll have a few more changes | 19:01 |
| robru | ok, sorry that didn't work out | 19:01 |
| dobey | well, if you have multiple MPs that should have prerequisites, but you didn't define them, then that's not the ci train's fault | 19:02 |
| dobey | doing that only makes life harder for the people reviewing the branches | 19:02 |
| dobey | or if you screw up and get into a criss-cross merge situation, again, ci train can't fix that | 19:03 |
| dobey | and it shouldn't try to. it requires manual intervention | 19:03 |
| robru | kenvandine: hmmm I'm not sure why the train is failing to track migration of wily packages to overlay, the code says that it's looking at the "dest" archive (which would be the overlay PPA in this case...) | 19:08 |
| kenvandine | robru: dunno, i just went ahead and merged it | 19:14 |
| kenvandine | but it was in the abyss for quite a long time | 19:14 |
| robru | kenvandine: yes copying to overlay should be basically instant, so manual merging is fine. I'm just troubleshooting why it's doing this, there's nothing in the code that obviously indicates why it would fail to notice the copy to overlay ppa | 19:15 |
| boiko | robru: would it be possible to have the audit lot information in an expandable box or in a separate page? for silos that require lots of iterations until landing it starts to get noisy | 19:30 |
| boiko | robru: s/lot/log/ | 19:30 |
| robru | boiko: yes I'm working on that | 19:30 |
| boiko | robru: cool! :) | 19:30 |
| dobey | robru: ugh, weird changelog again: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-026/+sourcepub/5474358/+listing-archive-extra | 19:50 |
| robru | dobey: yep, train only knows how to make changelogs when you have small branches. it can't handle megabranches, you have to make your own changelog | 19:52 |
| dobey | why can't it use the commit message for the branch like it does when i have 35 branches? | 19:54 |
| robru | dobey: because it doesn't use the commit message from the branch, it uses the commit message for the MPs. | 19:54 |
| robru | which it no longer has because you took those away | 19:54 |
| robru | dobey: that changelog is definitely a bug, if you file it I'll look into it later, I'm swamped with other stuff right now. for now the workaround is to write your own changelog into your megabranch | 19:55 |
| dobey | that's what i meant, from the MP | 19:55 |
| dobey | i didn't take them away | 19:55 |
| dobey | there is one MP, and it has a commit message | 19:56 |
| dobey | ok | 19:56 |
| dobey | i think i did file a bug already about this | 19:56 |
| robru | kenvandine: finally figured it out, there's a bug in the publish job that makes it record the vivid version over the wily version, so it's correctly looking at the overlay PPA but it's expecting to find the vivid version in wily, and fails, that's why it's in the abyss forever | 20:06 |
| dobey | trainguards: ping, hi, can i get some retries clicked for a few builds? | 20:08 |
| dobey | https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-026/+build/8082507 | 20:08 |
| robru | dobey: sure, which ppa / which builds? | 20:08 |
| dobey | https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-026/+build/8082509 | 20:08 |
| dobey | https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-026/+build/8082510 | 20:08 |
| robru | dobey: done, feel free to WATCH_ONLY build | 20:09 |
| dobey | those three. the arm64/ppc builds will fail anyway | 20:09 |
| dobey | robru: thanks | 20:09 |
| robru | dobey: your'e welcome | 20:09 |
| dobey | robru: can you retry https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-026/+build/8082509 again? seems it's dep wasn't actually published yet when it ran, for some reason, so it managed to get an older version. | 20:44 |
| dobey | thanks | 20:45 |
| robru | dobey: done | 20:45 |
| robru | brb | 20:45 |
| === salem_ is now known as _salem | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!