[02:02] ToyKeeper: i have the AP logs if you need [02:03] robru: ToyKeeper: i will check with zsombi the cursor issue, but i agree that it is a small thing [02:09] === trainguard: IMAGE 18 building (started: 20140509 02:10) === [02:26] bzoltan: BTW, where are the autopilot tests for things like the music app, calculator, clock, file manager, terminal, weather app, etc? [02:27] I found the AP tests for some of the items in the ui-toolkit test plan, but wasn't able to find at least half of them. [02:27] ToyKeeper: I use them from their packages [02:28] ToyKeeper: apt-get install -y ubuntu-ui-toolkit-autopilot gallery-app-autopilot share-app-autopilot address-book-app-autopilot messaging-app-autopilot dialer-app-autopilot camera-app-autopilot notes-app-autopilot friends-app-autopilot webbrowser-app-autopilot mediaplayer-app-autopilot unity8-autopilot ubuntu-system-settings-online-accounts-autopilot [02:29] Yes, I found the ones which had a corresponding -autopilot package. Not sure about the ones which don't, though. [02:29] ToyKeeper: they are click packages, right? [02:29] Yes, I think so. [02:30] ToyKeeper: that is how those are done -> phablet-config autopilot --dbus-probe enable;phablet-click-test-setup --click com.ubuntu.calculator; phablet-test-run ubuntu_calculator_app [02:32] Hmm, okay. Thanks. I've only had minimal direct exposure to AP, but that should change during the upcoming sprint. [02:32] ToyKeeper: consider yourself lucky :) [02:34] ToyKeeper: I see the UITK package in the queue here https://launchpad.net/ubuntu/utopic/+queue?queue_state=0&queue_text= [02:34] ToyKeeper: is there anybody I could ping to push it? [02:35] bzoltan: Sorry, I'm not sure who has control of that. [02:36] ToyKeeper: I will look around ... because that seems to be the slowest part of the process [03:15] ToyKeeper: do you know wthat is the -gles ending in the UITK package names? like qtdeclarative5-ubuntu-ui-toolkit-plugin-gles here https://launchpad.net/ubuntu/utopic/+queue?queue_state=0&queue_text= [03:15] Nope, haven't seen that suffix before. [03:19] === trainguard: IMAGE 18 DONE (finished: 20140509 03:20) === [03:19] === changelog: http://people.canonical.com/~ogra/touch-image-stats/18.changes === [03:20] ToyKeeper: i wonder if I should be worried about it ... [03:21] ToyKeeper: I just crosschecked that I have not changed anything in the debian/control ... so no idea [06:50] ogra_: I think we'd need #19 to get https://launchpad.net/ubuntu/utopic/+source/ubuntu-system-settings-online-accounts/0.3+14.10.20140506.1-0ubuntu1 in that finally migrated to release pocket, to fix Friends [07:32] sil2100: hello [07:32] dbarth: morning! [07:32] sil2100: i'm trying to resolve the landing of that online account settings module [07:32] what type of change or config do we need to push? [07:33] appparently the branch got merged, but then autopkgtest rejected the upload [07:33] now if we ty to push a fix in the same silo it blocks [07:33] do we need a new silo for uploading that change and unblocking the upload further down? [07:33] Let me take a look [07:33] But I guess we'll only have to force things in [07:34] Let me just double check things [07:34] sure [07:35] dbarth: are you sure it got rejected from -proposed? [07:36] dbarth: since I see 0.3+14.10.20140506.1-0ubuntu1 in the archive (saying it came from silo 18) [07:36] https://launchpad.net/ubuntu/+source/ubuntu-system-settings-online-accounts/0.3+14.10.20140506.1-0ubuntu1 <- wasn't that the thing that was blocked on autopkgtests? [07:37] sil2100: checking, hold on [07:38] mardy: ^^ [07:39] dbarth, sil2100: mmm... yes, I think that's what was blocked [07:39] mardy, dbarth: so, what could have happened... [07:39] sil2100: I'm quite confused of what happened and also what's the current state [07:40] mardy, dbarth: in overall there were some issues with autopkgtests lately, and yesterday even with the migration... so most probably the autopkgtests simply failed as a false-positive [07:40] but in the end it's uploaded [07:40] ah [07:40] right, that may be it [07:40] mardy: but your change can still be added as a new upload [07:40] And maybe someone (or the migrator) re-ran the test and it passed (had the same case yesterday) [07:40] since it makes things better wrt to autopkgtests [07:41] Need to think of a nice way to resolve this [07:41] Since I see 2 options: [07:42] 1) You include this 'released' changelog entry in a merge request which you add to the list of MRs [07:42] 2) We 'release' the old version (merge to trunk) and we prepare a new landing for all the other stuff [07:43] 2 is more time consuming, but it seems a bit better than 1 - as with 1, we won't have the release tagged correctly [07:43] Which I guess is not a big deal [07:43] But still [07:43] sil2100: either is fine with me; dbarth? [07:44] 2 is better right? [07:44] so let's do that [07:44] sil2100: mardy: yes, I noticed in the morning that the release had migrated to -release. so the silo should have been merge & clean:d. [07:45] do i need to m&c it still? [07:45] dbarth: if something is stuck in -proposed, it needs to be waited to know whether it will be really rejected or not [07:45] dbarth: yes, I would say it would be the best way, if you could just move the new MRs to a different landing and leave only the one that was there before, I will take care of cleaning it up ;) [07:45] ok, perfect [07:45] As I guess it might require some additional 'mojo';p [07:46] mardy: i guess you have that single branch from yesterday [07:46] sil2100: yeah ;) [07:46] yep, I agree. I was waiting for you to come online, but I was a bit worried first about the build error since a rebuild had been triggered, but luckily the CI Train had blocked the build so the PPA is still intact [07:46] Thanks! Just give me a sign ;) [07:46] dbarth: if the the PPA rebuild would have succeeded yesterday, the PPA contents would have differed from the archives so this would have been trickier [07:47] Mirv: yes, it all should be ok - and well, we don't even care abotu the PPA state right now, only thing that matters is the utopic-proposed branch [07:47] Mirv: which should have stayed intact, ready to be merged [07:47] sil2100: oh, right, utopic-proposed being the "real thing" makes it easier, a build wouldn't have even harmed that directly, only another publish [07:48] so m&c it is [07:49] dbarth: https://code.launchpad.net/~mardy/ubuntu-system-settings-online-accounts/autopilot/+merge/218777 [07:51] sil2100: i'm on line 35 now [07:56] dbarth: thanks :) [07:57] sil2100: so are you running the m&c for the 018 silo? [07:57] In a moment [07:57] Need to make sure all is ok [07:57] yeah, just checking [07:59] Ok, all seems ok, let me try now [08:00] hmm where dig ogra drop [08:00] did [08:01] I'd like him to launch an image build [08:01] didrocks: do you remember if packages are in destination and utopic-proposed branches are prepared, if I press m&c with 'ignore step' - will it merge in the old utopic-proposed branch to trunk? :) [08:01] Mirv: something important landed? :) [08:02] sil2100: it will merge whatever is in the silo (so, the latest that you prepared) [08:02] sil2100: yes, the friends would work now because of the migration [08:02] \o/ [08:02] 2x \o/ [08:03] I just love didrocks's CITrain, it's so smart o/ [08:03] sil2100: hum, not sur eyou got it right :p [08:03] so, if you rebuilt [08:03] in the same silo [08:03] that's what it will merge [08:03] not what's in proposed [08:04] Well, it never processed the build correctly, as it was bailing out on the build job [08:05] oh [08:05] Ouch [08:06] well, if it started to consider the component, that's a start of preparation [08:07] I might have to fix trunk manually, oh well ;/ [08:07] you just have to bzr pull -proposed [08:07] from LP [08:07] and get that to trunk [08:09] anyone else ( ogra_ ?) get this when their phone does alarms? https://www.youtube.com/watch?v=vRQI8DnTEIg (it's only 22s long) [08:09] Well, bzr pull is not enough, need to merge it ;/ [08:10] popey, yes, had that once [08:10] sil2100: i also have line 36 with an SRU request [08:10] ogra_: you dropped off but if image would be built now, Friends app would work again [08:10] sil2100, ^^^ do you want an image ? [08:12] ogra_: yes :) as per Mirv's request [08:13] The more images, the merrier [08:13] triggered [08:13] :) [08:14] thanks! [08:19] === trainguard: IMAGE 19 building (started: 20140509 08:20) === [08:21] dbarth: phew, it should be ok - the system worked differently then I expected so it took some manual tinkering, but we should be fine now [08:21] Time to put on some daily clothes [08:26] dbarth: continuing from above, line 35 now has landing-001 for it [08:32] sil2100: nice, thanks for bringing us back to clear here [08:32] Mirv: thank you sir! :) [08:34] Accidentally pressed the suspend button while in a hangout. Started PC back up and the hangout carried on. Phew! [08:38] popey: I've needed some hunting for my OpenWRT Barrier Breaker running secondary WiFi AP (combined with possible utopic wifi issues on my laptop), and I've noticed Hangouts quite nicely recovers from anything that lasts for short enough amount of time === oSoMoN_ is now known as oSoMoN [09:07] sil2100: around? [09:09] sil2100: I now added libconnectivity-cpp-dev (>=0.0.1+14.10.20140509) to the build-deps of indicator-network [09:09] that should now get it to dependency-wait in the silo [09:11] thostr_, taking care of the issue in 009? [09:11] mhr3: which issue? [09:11] Wellark, no gcc4.7 on utopic ppc64 [09:11] we don't care about ppc64 [09:12] Wellark, previous upload of indicator-network worked on it [09:12] so you're dropping it? [09:13] well, if gcc-4.7 is not available then it's not available [09:14] why do you force build with it? [09:14] because all of the -cpp libs are forced to be built with 4.7 [09:14] because platform api is built with 4.7 [09:14] and there is a ABI breakage between 4.7 and 4.8 [09:15] so platform api won't be buildable either? [09:15] Wellark: \o/ [09:15] Wellark: thanks, will rebuild this component in the silo to get it into the PPA [09:15] sounds like a problem that should be fixed, anyone let foundations know? [09:15] they know [09:16] sil2100: already asked thostr to do a complete rebuild [09:16] Wellark: excellent [09:16] sil2100: but didn't get reply from him, so could you hit the build button? [09:16] sil2100: also to make sure it works correctly, could the ppa be cleared first? [09:17] I don't know if reconfigure does that [09:17] mhr3: they know [09:17] mhr3: tvoss knows [09:17] on their TODO list [09:17] g++-4.7 sucks on multiple counts [09:19] sil2100, thostr_: I let you guys figure it out. :) [09:19] Wellark, thostr_: running a build for those ;) [09:20] sil2100: you mean 4.8? [09:21] sil2100: or 4.7 for ppc [09:21] thostr_: I mean, I ran a re-build of silo's 009 connectivity-api and indicator-network so that the new dep-version change is picked up [09:22] sil2100: ah [09:22] Since we need those two rebuilt so that the new build-dep version makes sense [09:24] The standard practice in other packages is to use gcc-4.8 on only ppc64el [09:24] You'll find this in several of the *-cpp packages [09:25] the only real fix is that we get rid of g++-4.7 [09:25] Nevertheless, this is a fix [09:26] I mean, I agree it would be good to upgrade, but there's no need to block on that (complex) change for this [09:28] ok, I see dbus-cpp now has some magic to select between 4.7 and 4.8 [09:28] will add that later to indicator-network and connectivity-api as well [09:32] Right, same thing should work [09:33] Is the failure in https://launchpad.net/~ci-train-ppa-service/+archive/landing-009/+build/5989594 likely to be racy, i.e. worth retrying? [09:34] never seen that before [09:34] it might be racy if the builder is really really slow [09:34] or under exterme load [09:34] let's see how the rebuild goes [09:34] cjwatson: there is already a rebuild happening [09:34] i need to run some errands [09:35] I'll be back later [09:36] davmor2, popey, do we have a bug for the clock being always halted/behind on resume of the phone ? [09:36] i haven't seen that [09:37] popey, your clock is not several minuted behind and jumps to the right time when you unlock (after it was off for a while) ? [09:37] *minutes [09:38] i think that is what makes me miss the alarms all the time [09:39] (when it appens that the alarms are missed i usually see it being 1-2 mins before the alarm and when i unlock it jumps past the alarm time so the app never sees the marker to actually trigger the alarm) [09:39] * ogra_ notes his french accent today ... [09:39] *happens [09:39] === trainguard: IMAGE 19 DONE (finished: 20140509 09:40) === [09:39] === changelog: http://people.canonical.com/~ogra/touch-image-stats/19.changes === [09:41] * ogra_ notes that ToyKeeper silently dropped the "haptics are audible during calls" bug from her list [09:59] ogra_: do you know who needs to click on a button to move this queue: https://launchpad.net/ubuntu/utopic/+queue?queue_state=0&queue_text= The UITK seems to be blocked for 10 hours [10:00] bzoltan1, ubuntu archive ... best to ask in the #ubuntu-release channel that an archive admin gets active on it [10:01] bzoltan1, the package ships new binary packages, these need manual approval [10:01] !test [10:01] Testing... Testing... 1. 2.. 3... ( by the way, remember that you can use /join #test ) [10:01] you win ! [10:01] :) [10:01] popey: you are welcome :) [10:02] \o/ [10:02] thanks [10:02] ogra_: it is not my package, I did not do that ... I did not touch the debian/control .. this is for the x86 emulator image [10:02] ogra_: no [10:02] bzoltan1, sure, but if you want it to move now instead of waiting for ricardo, poke an archive admin [10:03] ogra_: I wonder why ricardo put me in this place ... [10:04] bzoltan1, surely because there is an evil conspiracy against you :P [10:04] (i bet he just forgot about that) [10:05] ogra_: I do not say that :) But it is uncool to hijack other peoples landings and block them for whatever reason... Ricardo could have made a separate integration round [10:06] well, he announced it various times on the ML that he rebuilds everything for gles for emulator use ... [10:06] ogra_: that does not sound like "hey I will hijack your MRs and block them for a day" [10:08] ogra_: I am not against the -gles packages... me too need it for the emulator. But at the same time core app devs are waiting for the UITK fixes. These -gles rebuilds should be on a different track [10:08] come on, we all have to do our work and at times there is no other way for you but block others ... and he properly announced the work [10:09] ogra_: no, that is a different thing... [10:09] you would be as well screwed if we had issues with the images ad would stop all landings ... even if the image breakage wouldnt be your fault [10:09] ogra_: creating a new binary package and landing a fix for apps are two different tracks... I would not even mix these, because even I know, that landing new packages are slow [10:09] that is what happens in big teams [10:10] no need to get upset about it [10:10] ogra_: I am not upset :) I just do not agree that it is OK to hijak a landing and block it for a totally different purpose than the landing was initiated [10:11] you *do not own* a package in ubuntu ... [10:12] while it is nice from the upload to notify you there is no requirement at all ... i could right now upload your package and completely break it if i wanted ... (indeed i wont do that) ... we have explicitly no package ownership in the archive for anything [10:12] ogra_: häh ... wait a sec :) Mirv says that this -gles packaging does not actually block te UITK landing ... [10:12] *uploader [10:13] ogra_: I though that the UITK back merging is blocked by this https://launchpad.net/ubuntu/utopic/+queue?queue_state=0&queue_text= [10:13] if foundations does a low level library transition and your package needs touching (and gets a new dep that prevents it from publishing) they can do that ... [10:14] ogra_: sure, of course [10:14] bzoltan1, yes, i know what you thought :) i'm just saying you cant claim ownership of that package and if someone else uploads and breaks it you have to live with that ... [10:15] no policy that forces anyone to notify you about an upload of y package you work most on (it is simply good practice, but doesnt need to happen oor some such) [10:16] ogra_: those people who have license to upload are in some way on a different trust level. That is natural and good [10:16] * bzoltan1 got the point :D no need for further punishment [10:17] heh, i didnt mean to "punish" :P [10:18] (though popey accused me of being "hulky" yesterday :P ...) [10:18] not understanding something and realizing that I was talking crap feels like punishment :) [10:19] you, ogra_ being hulky ... LOL [10:19] well, you werent talking crap ... what you assumed *could* happen all the time [10:19] yeah so the gles is not related to the normal uitk landing, instead it looks like autopkg tests are stuck or something [10:19] yeah ... say "new toolbar" and i'll turn green :) [10:21] * didrocks missed ogra_'s hulk moment? [10:29] I've forced the autopkgtests that were blocking ubuntu-ui-toolkit; one had never passed (though I'll see if I can fix it, looks easy enough) and the other actually did pass but our buggy integration code didn't notice [10:29] didrocks: and bzoltan1's double facepalm monent ... nothing new here :D [10:29] bzoltan1: ahah :) [10:53] bzoltan1: ubuntu-ui-toolkit is migrating to the release pocket now [10:53] cjwatson: thanks a lot [11:05] that's great indeed, now there [11:34] * sil2100 goes to prepare lunch [11:38] guys, I need to get CI to run on this MP https://code.launchpad.net/~andrew-hayzen/ubuntu-ui-toolkit/fix-1315775/+merge/218206 [11:39] psivaa, see the last comment on bug 1316978 ... do we have some product i can open a bugtask for that reflects "hey we need this new test in the test suite" [11:39] bug 1316978 in ubuntu-touch-session (Ubuntu) "ubuntu-touch-session needs to be able to start even if the homedir is filled to 100%" [Critical,Confirmed] https://launchpad.net/bugs/1316978 [11:40] fginther: can someone enable CI on https://code.launchpad.net/~andrew-hayzen/ubuntu-ui-toolkit/fix-1315775/+merge/218206 [11:41] ogra_: let me take a look. missing a bit of context. will go through the bug report [11:52] ogra_: ok, now i understood the question :), that's 'Ubuntu CI Services' : https://bugs.launchpad.net/ubuntu-ci-services-itself [11:52] ah, thanks :) [12:03] sil2100: ok, I'm back [12:03] but I see no new packages in the silo.. [12:04] are the builders under such load atm that the uploads are queued? [12:06] No, there's plenty of spare capacity in the build farm used by silos [12:06] https://launchpad.net/builders/ - silos use the "Official distributions" bit [12:07] ug, oh.. [12:07] https://ci-train.ubuntu.com/job/landing-009-1-build/68/console [12:07] File "/srv/juju/vol-0000005d/var/lib/jenkins/citrain/citrain/cupstream2distro/branchhandling.py", line 302, in grab_committers_compared_to [12:07] raise Exception("bzr missing on {} returned a failure: {}".format(lp_branch_to_scan, stderr.decode("utf-8").strip())) [12:07] Exception: bzr missing on lp:~unity-api-team/indicator-network/indicator-network-cpp returned a failure: Permission denied (publickey). [12:08] help... [12:09] didrocks: ^ [12:10] Wellark: as the logs says, seems bzr missing lp:~unity-api-team/indicator-network/indicator-network-cpp failed [12:10] didrocks: nothing to do with my branch [12:10] Wellark: well, nothing to do with the train either :p [12:11] psivaa, hmm, seems one mako went astray in the recent test run for image 19 [12:11] Wellark: seems it's working, can be a hickup [12:11] Wellark: so you should just retry a build on that one [12:11] didrocks: well, the reason is that citrain public key got Permission denied from LP [12:11] so yes, it's a citrain issue :) [12:11] ogra_: yea, i've kicked them on another device, which is flashing now [12:11] I don't have permissions to rebuild.. [12:11] psivaa, thanks [12:12] didrocks: could you hit the button on the sheet? [12:12] Wellark: what is the citrain public key? it's just calling bzr [12:12] the earlier one was stuck in fastboot btw. the same device twice this week [12:12] so can be a network hickup with LP [12:12] Wellark: but it's between bzr and LP [12:12] sigh .. [12:12] Wellark: there is no "CI Train public key" [12:12] ok, so ci train can't access private repos then? [12:12] roger. [12:13] (not that my repo would be private) [12:13] Wellark: is ps-jenkins part of the ~unity-api-team team? [12:13] Wellark: it's the only consideration for getting bzr working [12:13] Wellark: if it was a hikcupp, I can rerun [12:13] didrocks: it most probably is a hickup, as the train already built those repos once [12:14] ok, /me retries [12:14] with the same parameter that sil2100 setup [12:14] didrocks: o/ Thanks, I'm still in the middle of lunch preparation [12:14] Wellark: restarted [12:14] didrocks: thanks! === josepht changed the topic of #ubuntu-ci-eng to: Ubuntu CI Engineering Team | Vanguard: josepht | CI Train support - US: robru, cyphermox, rsalveti - EU: sil2100, Mirv, didrocks | CITrain support no answer: use mup bot after 30 minutes, but choose right timezone === alan_g is now known as alan_g|lunch === alan_g|lunch is now known as alan_g === jhodapp|afk is now known as jhodapp [12:35] sil2100, good morning, do you know the status of silo4? [12:35] renato: let me check in a moment :) [12:36] sil2100, thanks === alan_g is now known as alan_g|lunch [12:38] renato: ok, so, I guess we'll have to ask someone to remove address-book-app for the non-supported archs [12:39] Did my patch not help? [12:40] cjwatson, didrocks: could anyone of you get rid of address-book-app and address-book-app-dbg from the archive for archs for arm64, powerpc and ppc64el? With the patch the archs are out-of-date now [12:40] Oh, it did, yes I can just remove the binaries - but please copy it to -proposed first [12:40] cjwatson: I might be misunderstanding update_excuses ;) [12:40] Ah, it's in -proposed, OK [12:40] I'll deal with it [12:40] cjwatson: those seem to be in -proposed already [12:40] cjwatson: thank you! [12:40] :) [12:41] hi josepht, I've seen a couple of failures on https://code.launchpad.net/~rpadovani/reminders-app/1316950/+merge/218829 and https://code.launchpad.net/~reminders-app-dev/reminders-app/new-design/+merge/218341 I couldn't understand. As far as I can see, they're not related to the tests. Could you give me a hand figuring them out or retriggering the jobs? [12:41] sil2100, how important is have the addres-book-app in other arch? Maybe we can split the qml keyboard plugin in a individual projects that not depend on keyboard code [12:42] sil2100: it works! https://launchpad.net/~ci-train-ppa-service/+archive/landing-009/+build/5992875 [12:42] dpm: sure, looking [12:42] sil2100: done [12:42] cool, thanks [12:42] renato: it's dealt with [12:43] renato: it's not particularly important to have the app itself - I just wanted to minimise the amount of fallout from reverse-dependencies [12:43] renato: so if you think splitting it would be a better design, by all means, but you shouldn't feel obliged and there are probably more important things to do [12:44] cjwatson, ok lets keep this for now [12:44] thank you guys [12:45] (and really, I'd rather get platform-api building everywhere so that we don't have to care about this in lots of individual packages, but that's not this week's project ...) [12:46] * didrocks goes for a run === jhodapp is now known as jhodapp|brb [12:47] cjwatson, how would you do that without having android bindings ? with fake packages that do not work ? [12:49] sil2100: although, now it seems indicator-network got stuck to that dependency-wait [12:50] there are packages available of the connectivity-api for i386 and amd64 to satisfy the dependency, but the builds are not starting.. [12:50] or is it just a really slow cron job that checks the dependency-wait tasks only ever so often? [12:52] ogra_: yeah, I'm not sure [12:52] Wellark: dep-waits are checked every 30 minutes [12:53] cjwatson: sweet [12:54] Wellark: I'll prod them for you now [12:54] (done) [12:55] Wellark: there's a lot of reverse-dependency fallout from connectivity-api/ppc64el though - would it help if I put together a patch for that? [12:56] cjwatson: should only affect indicator-network if connectivity-api is not available [12:56] which it isn't [12:56] needs the gcc-4.8 fix [12:57] cjwatson: well, if you are offering your help how could I refuse :) [12:57] heh [12:57] although I could cook it up myself during the weekend also [12:57] you probably have better things to do.. [12:57] right now [12:58] eh, I've already written the patch, just need to build-test it [12:59] just make sure to crosscompile it then [12:59] build time tests wont work if you compile with g++-4.8 [12:59] rather than native compile? [12:59] if you have a ppc64el at hand then you can do a native compilation as well :) [13:00] which I do [13:00] oh [13:00] ok [13:00] carry on then! :D [13:00] cjwatson: just remind me again, why is it a priority right now to get the unity8 stack compiling on ppc64el [13:00] I though it is a server architecture [13:01] (don't mean to be a dick, just honestly curious about this) [13:01] it's not in itself, but our dependency stacks are very tightly interwoven in many places [13:01] in this case indicator-network was already built on ppc64el [13:01] right. ok. [13:01] undoing that would mean tearing out the UOA stack, which is really painful to make arch-specific, we've been there before and I would rather not go back [13:02] lots of explicit architecture annotations - it's easier to just make it build everywhere [13:02] but just to point out indicator-network it's totally useless wihtout unity8 [13:02] sure, I know [13:02] as I say the rdeps are more of an annoyance [13:02] just wait til apple announced the iphone 9 with ppc64el CPU ;) [13:03] the general rule is that packages must build on all architectures where they used to build [13:03] and we generally try to build all packages everywhere, insofar as it's possible - our dependency stack is really a tremendously messy graph and things you might not expect to be useful on a server arch wind up in the oddest places when sorting out build-deps [13:04] yep [13:04] which tells about a different kind of a problem to solve, but let's not go there [13:04] also having high build percentages makes us look good to the client :) [13:04] :D [13:05] (and while i was joking above, nobody would have predicted an arm64 phone two years ago, so you never know ...) [13:05] and once we do the whole convergence thing, we might want things like unity8 for remote sessions [13:06] ogra_: well, Apple does have quite some history with ppc, but I think the breakup was so bad that they will never go back :) [13:06] if for nothing else then just on plain principle [13:06] lenovo builds phones too and still stands pretty close to IBM ;) === jhodapp|brb is now known as jhodapp [13:07] (though i admit ppc64el is probably not designed for mobile power consumption) [13:07] nope.. [13:07] clouds.. [13:07] yep [13:08] "who cares about power concuption.. We have our own power plant just to run this data center. Give me calculation power." [13:08] anyway mostly my motivation is not having to do evil things to reverse-dependencies elsewhere. I don't really care horribly much if stuff that never built continues to not build [13:08] Wellark: https://code.launchpad.net/~cjwatson/connectivity-api/ppc64el-gcc-4.8/+merge/218984, build-tested cleanly on ppc64el [13:09] basically copied and pasted from dbus-cpp [13:09] well, IMO indicator-network should never have been built for ppc64el, but "mistakes" happen ;) [13:09] cjwatson: cool. I will merge that in [13:09] thanks [13:09] cjwatson: thanks! [13:09] cjwatson: I need to do the same for indicator-network also [13:09] or do you have a branch for it, too? :) [13:10] I can make one for you if you can point me to the branch I need to base it on [13:11] dpm: the job is running now [13:11] although I'm not sure if I can land something that involves a prerequisite branch through the ci train, so it might be easier if I gave you a patch [13:11] https://code.launchpad.net/~unity-api-team/indicator-network/indicator-network-cpp [13:11] josepht, great, thanks! [13:11] cjwatson: if you could just propose a MP against that one [13:12] I can then merge it directly in if any other modifications are needed to the -cpp branch [13:15] Wellark: ok, https://code.launchpad.net/~cjwatson/indicator-network/ppc64el-gcc-4.8/+merge/218986 - can't easily test that until connectivity-api lands, but it's not very complicated so should be fine [13:16] cjwatson: thanks! [13:16] oh, one more thing [13:16] could you make this: https://code.launchpad.net/~cjwatson/connectivity-api/ppc64el-gcc-4.8/+merge/218984 [13:16] proposed to be merged to this: [13:17] sil2100: any update on my changelog issue? [13:17] https://code.launchpad.net/~unity-api-team/connectivity-api/devel [13:17] sil2100: should I just dput myself? [13:17] Wellark: done, resubmitted as https://code.launchpad.net/~cjwatson/connectivity-api/ppc64el-gcc-4.8/+merge/218987 [13:18] cjwatson: it has merge conflict [13:19] sigh, one sec [13:19] cjwatson: also, is this outdated? https://wiki.debian.org/CrossBuildPackagingGuidelines [13:20] as it says that DEB_HOST_GNU_TYPE is not always available [13:20] where does it say that? [13:21] cjwatson: "Sadly we can't just set $(DEB_HOST_GNU_TYPE)-gcc always because that doesn't work natively" [13:21] oh, I think that *may* have changed in Ubuntu very very recently [13:21] therefor /dev already had that ifeq ($(DEB_BUILD_GNU_TYPE),$(DEB_HOST_GNU_TYPE)) [13:22] cjwatson: ok. feel free to remove the ifeq else endif then :) [13:22] it's not harmful to use that, so I'll just leave it [13:22] I'm not going back [13:22]