[00:27] thomi, pong? [00:30] thomi, I'll should be back in 60-90 minutes [01:26] thomi, are you there? [01:28] fginther: am now - you? [01:32] thomi, yo [01:33] thomi, sorry about me email short on details. I'm trying to determine if there is a general pattern for what the ubuntu-ui-toolkit is doing. [01:34] thomi, I know that the retry code I used is not the way to go. [01:34] fginther: hey [01:34] thomi, good evening [01:34] fginther: I looked at your branch, but it wasn't clear to me exactly what the problem was you were trying to solve [01:34] fginther: so maybe we ought to have a hangout about this tomorrow first thing? [01:35] thomi, sorry about that, was a little rushed trying to send you something before I had to leave the house [01:35] thomi, hangout tomorrow would be good [01:36] fginther: yeah no worries [01:36] fginther: it'll have to be first thing tomorrow though, since I have an appt in town afterwards [01:36] fginther: I'll create a calendar event, so we both know when we're free [01:36] thomi, that works for me, please schedule what works for you [01:37] fginther: scheduled. [01:37] fginther: our clocks have changed, which means NZ + US now have more overlap [01:37] thomi, \o/ [01:38] presumably the US clocks will change soon as well, which should make it even easier :) [01:39] thanks for offering to help, hopefully I'll understand the problem a little better tomorrow as well [01:39] have a good night [01:39] no worries [06:48] heya [06:50] didrocks: hangout? [06:50] lool: still answering emails, ok in ~20 minutes? [06:52] sure [07:06] didrocks: I'm on [07:07] lool: coffee and I'll be there [07:24] https://code.launchpad.net/~bfiller/mediaplayer-app/remove-no-display/+merge/188092 [07:52] didrocks: LP #1232588 [07:52] Launchpad bug 1232588 in upstart-app-launch (Ubuntu) "--desktop_file_hint still seems required for Mir" [High,New] https://launchpad.net/bugs/1232588 [08:33] vila: https://plus.google.com/hangouts/_/b31c28f31fcf9e093dc094c78119b1080db93ff7 [08:35] didrocks: sry, can't right now, [08:35] no worry ;) [08:36] didrocks, lool: some notes about the issue you mentioned during the week end: http://paste.ubuntu.com/6174698/ [08:36] didrocks, lool: i.e. I looked, it could be fixed, do we want to or is it overkill ? [08:37] didrocks: no news about dns migration, will check later [08:41] damn, my daily DLS reconnect seems to now fall exactly into the meeting :( [08:41] *DSL === vila is now known as vila-afk-biab [08:58] vila-afk-biab: There was some news about DNS migation somewhere [08:58] I heard we were switching DNS/DHCP in some lab since last friday, but can't remember where [08:58] vila-afk-biab: fixing the changelog: up to you, I just thought I'd pass it on since you had recently fixed the "-" handling [08:59] vila-afk-biab: There are certainly more urgent things to do though ;-) [08:59] ogra_: lol [08:59] ogra_: perhaps you can reboot it in the morning? [08:59] well, or late at night [08:59] some folks here have a cron to reboot their cable connection in the middle of the night to have a stable IP during the day [09:00] yeah, my reconnect used to be around 4 or 5am ... not sure why it moved [09:00] it's tired of waking up so early, like me? [09:00] i guess i'll set up a cronjob [09:00] heh, likely [09:02] didrocks: Ah there was landing 51 for some click updater stuff already and I was pinned on it, probably when I got pinged by ralsina last week [09:02] lool: yeah, I wondered if it's the same [09:02] lool: please feel free to remove my duplicate if it's the same ;) [09:03] didrocks: I think yours covers slightly more, so will keep both [09:03] ok [09:07] sil2100: while I'm busy doing other things, do you mind landing friends? [09:07] sil2100: no need for testing, it's just a Standards-Version bump [09:08] (juts to clean the page) [09:08] didrocks: any testing needed? ACK [09:09] didrocks: done! [09:09] AFK for a quick momen [09:09] t [09:10] Mirv: I added request #58, can you look and test that with psivaa? [09:10] Mirv: divide the work as you wish, I think someone should take desktop, the other phone [09:10] (the changelog sounds good) [09:13] didrocks: ok! [09:14] didrocks: Mirv: let me know either way [09:14] didrocks: there's a blocker bug though since libusermetrics doesn't build, I filed a bug today [09:15] Mirv: ok, please ping upstream as well so that they know of it [09:15] but if excluding libusermetrics, then ok [09:15] Mirv: and we can publish without that one [09:15] yep ;) [09:15] didrocks: I'm planning to, ted is not line yet [09:16] ok ;) [09:18] psivaa: can you the the phone, upgrade the indicators stack and run tests there? the desktop - Unity7 tests - is a bit tricky but so I'm thinking I could run it because I know the pitfalls there and how to interpret the results because we've been releasing unity7 for a long time... [09:18] my sentences suck today [09:19] Mirv: ack will test the phone :) [09:19] psivaa: thanks! [09:19] yw :) [09:37] sil2100: Mirv: lool: ok, found out why the customization project wasn't listed. (configuration branch was not refreshed). Should be fine now [09:37] sil2100: please work on landing the customization one as well as discussed [09:37] Mirv: ok, so I just branch qtsystems and review? [09:40] Mirv: ah, we'll need a DEP5 format (so that we know if it's reported upstream) please [09:40] ping me once done === vrruiz_ is now known as rvr === vila-afk-biab is now known as vila [10:06] didrocks: why don't we just bzr pull the config regularly from jk? [10:07] lool: jibel convinced me to not do it, but TBH, I don't see anything block it (on that side at least) [10:08] lool: the whitelist still need to be manual (on snakefruit), but on magners, I think we could [10:10] lool, didrocks IIRC the problem is that if you reconfigure jobs while they are running, jenkins aborts them (if that's what your referring to) [10:11] you're [10:11] jibel: this is just about bzr pull on magners I guess [10:11] not deploying the config I guess [10:11] if it is just a pull that's fine [10:11] let's cronify that then [10:11] but at some point we talked about reconfiguring automatically [10:12] (done) [10:12] yeah [10:13] for that we need to pull out of jenkins a bunch of stuff [10:13] but I think this plan is now dead… [10:15] sil2100: back? [10:15] why don't we do that as part of starting the tasks or something? [10:15] or just change the jobs to read from the config [10:16] e.g. instead of a "complex" job definition, you just make a thin wrapper around config/$job-name [10:16] lool: at first, we didn't want to rely on the config files, but yeah, it happens it's what needed now [10:16] lool: but TBH, this is not something we can tackle on anymore before V1, we are pulled in a lot of other directions ;) [10:21] didrocks: what's V1 here ? [10:21] cu2d V1 ? [10:21] vila: phone version 1? [10:21] oh, bah, silly me [10:21] :) [10:24] didrocks, lool: I know fginther takes care of having no jobs in flight while reconfiguring for upstream-merger. That's certainly something the CI engine should do transparently in any case, I for one will push for it, as well as leaving as little control to jenkins as possible for scheduling (been there, suffered from that, don't want to try again ;) [10:30] sil2100: how was friends published? Did you check? I see everything in red on that stack [10:30] didrocks: DEP5 added to qtsystems. [10:30] * vila catches up backlog [10:31] * cjwatson adds landing ask 123 for click 0.4.9 [10:31] lool: yeah retoaded said he will attempt to further test the dns migration during the week end but I got no feedback so I'll re-check later and will relay the feedback here [10:34] cjwatson: I guess this is backward compatible and tested against all the other click packages, even if some were not yet landed? (http://people.canonical.com/~platform/cu2d/results) [10:34] Mirv: sponsored, thanks! [10:34] thanks! [10:34] didrocks: Should be entirely backward-compatible, though I'm reflashing now to run tests [10:35] cjwatson: ok, feel free to upload once the tests are done (filing landing ID 60) [10:35] didrocks: Are the .click files for the unlanded packages available anywhere? (Though TBH I think it would be fine to test against the ones in http://people.canonical.com/~ubuntu-archive/click_packages/ - AFAIK they're constructed the same way) [10:36] cjwatson: ah, I only know about the .debs that are waiting (see the *-click-* packages in http://people.canonical.com/~platform/cu2d/results), not sure about the .click one TBH [10:36] Mirv: yw ;) [10:37] didrocks: Oh, it won't affect that at all, but I'll run what tests I can find [10:38] thanks ;) [10:38] sil2100: also, have you disabled autopilot the other day for real? I see still some builds in the ppa [10:39] seb128: mind merging back your changes to indicator-keyboard trunk please? ;) [10:43] didrocks, waiting for somebody to approve https://code.launchpad.net/~seb128/indicator-keyboard/saucy-manual-upload/+merge/188065 since friday... [10:44] didrocks, not sure why the CI didn't kick in again after I pushed the new revision though [10:44] seb128: ah, you proposed that back, thanks! seems upstream isn't responsive then. [10:44] didrocks, well, I think they were waiting for CI [10:44] seb128: what about kick in? it doesn't find the latest revision in the archive [10:44] ah [10:44] upstream merger [10:44] right [10:44] let's just approve it [10:44] yeah [10:44] can you do that? [10:44] thanks ;-) [10:45] done ;) [10:45] thanks to you! [11:01] sil2100: I'll go soon exercising, I hope you will be back once I'm back so that you can process friends + ubuntu-touch-customization-hooks updates (also see my other questions) [11:01] sil2100: also, it will be nice if you can evaluate the settings stack at the same time [11:26] ACK [11:27] didrocks: I published the friends stack, as when I was publishing the stack it was still waitonstacks [11:28] sil2100: maybe try rerunning it? [11:28] or restoring the .bak [11:28] hmmm [11:29] I wonder what happened [11:30] cp: cannot stat `/var/lib/jenkins/cu2d/work/saucy/friends/*_friends-app.xml': No such file or directory [11:31] sil2100: interesting, maybe you just got unlucky and published just after the stack was unlock? [11:31] unlocked* [11:34] didrocks: should I re-run the whole stack normally or just do a force publish again? [11:34] sil2100: I think restore the previous .bak [11:34] and then try publishing [11:39] sil2100: better? [11:40] didrocks: tried restoring the .bak, but it seems I don't have some perms like: cp: cannot open `friends.bak/libfriends_0.1.2+13.10.20130929.1-0ubuntu1_source.changes' for reading: Permission denied [11:40] didrocks: is it ok without those? [11:40] sil2100: should be [11:40] as long as you have the .project [11:44] hmmm [11:45] http://10.97.0.1:8080/view/cu2d/view/Saucy/view/Friends/job/cu2d-friends-saucy-3.0publish/42/console [11:45] I wonder whatsapp [11:45] sil2100: bzr: ERROR: Cannot lock LockDir(file:///var/lib/jenkins/cu2d/work/saucy/friends/libfriends/.bzr/branch/lock): Permission denied: "/var/lib/jenkins/cu2d/work/saucy/friends/libfriends/.bzr/branch/lock/yyzntm7kvu.tmp": [Errno 13] Permission denied: '/var/lib/jenkins/cu2d/work/saucy/friends/libfriends/.bzr/branch/lock/yyzntm7kvu.tmp' [11:45] Permissions look ok, [11:47] sil2100: are you connected to mangers? I can't apparently [11:47] didrocks: it takes around 1 minute to connect ;/ [11:47] So you need patience [11:47] drwxrwxr-x+ 2 desktop-team jenkins 4096 Sep 29 21:23 lock [11:48] oh [11:48] you did cp [11:48] why not mv? [11:48] (or even cp -p :p) [11:48] I did a mv of the old one, and then cp -a ;) [11:48] Ok, so I'll do a mv then! [11:49] weird, if you cp -a, desktop-team shouldn't be the owner [11:49] so yeah, rm -r friends [11:49] mv friends.bak friends [11:49] cp -a friends.bak/ friends [11:49] k ;) [11:58] sil2100: so, we're good now? [12:01] didrocks: with friends, yes! Waiting for misc to finish [12:01] sil2100: ok, did you read about AP which seems to still be in the ppa and building? [12:01] sil2100: did you forgot to deploy the backout on Friday? [12:01] (I think we should remove it again and remove it) [12:02] sil2100: while you are waiting on misc stack, maybe you can start the settings one? (running AP tests for ubuntu-system-settings-online-accounts + some dogfooding for system-settings?) [12:04] Aye aye! I was almost sure I was deploying *something*, but I guess I didn't! [12:04] heh [12:04] Maybe I redeployed the wrong branch === alan_g is now known as alan_g|lunch [12:07] maybe… [12:10] Mirv: psivaa: how are the indicators tests looking? [12:10] didrocks: argh! I just figured out you said 'changelog' looked fine, not the 'changes' (packaging changes) regarding indicators! [12:11] didrocks: so published, a moment ago, but.. [12:11] oh? [12:11] ok, let me look at the FS [12:11] didrocks: so this's because the cu2d was read, and it didn't show the packaging changes under the publish stack [12:11] s/read/red/ [12:11] Mirv: yeah, there is a trick for that [12:11] (foo + AUTO_PUBLICATION) [12:11] Mirv: it was red because of the tests? [12:11] it's http://10.97.0.1:8080/view/cu2d/view/Saucy/view/Indicators/job/cu2d-indicators-saucy-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_indicator-bluetooth_0.0.6+13.10.20130927-0ubuntu1.diff + http://10.97.0.1:8080/view/cu2d/view/Saucy/view/Indicators/job/cu2d-indicators-saucy-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_indicator-datetime_13.10.0+13.10.20130927-0ubuntu1.diff + http://10.97.0.1:8080/view/cu2d/view/Saucy/vi [12:12] ok, let me look :) [12:12] didrocks: red because of libusermetrics build failure. I did autopilot locally and so did psivaa [12:12] ah ok ;) [12:13] Mirv: ok, it seems to be the same thing everytime, so yeah, looking good [12:15] yeah it looked good to me too, but sad still to me. I'm writing a note about special case handling with foo + AUTO_PUBLICATION. [12:17] ralsina: around? [12:17] Mirv: yeah, this one is really tricky ;) [12:17] didrocks: "do no use manually" says the hint for that :) [12:17] Mirv: when you run it, ensure that the stack is not running at all [12:17] there is no safety net [12:17] hence this "do not use manually" :p [12:18] lool: here, good morning! [12:18] ralsina: good morning! [12:18] ralsina: we would like to land click-package stack, that is everything listed in the first section of http://people.canonical.com/~platform/cu2d/results [12:18] right. I tend to not to ever do anything if stack is running anyhow (or stop it before). [12:19] ralsina: a) are you aware of any issue b) do you miss anything there before it may land c) any suggested tests we should focus on? [12:19] my plan was to update to these, test installing + running + removing a click, and checking for click updates, albeit I always get "No updates found" [12:19] lool: the main thing bugging me there is that testing click-updater gave us conflicting results. But since it was totally broken, even the worst case is an improvement [12:20] lool: well, to test for updates, we are installing some old clicks via pkcon then checking [12:20] can I download old clicks from somewhere? [12:20] lool: we have a few, let me get you the URLs [12:21] thanks [12:21] one is enough I guess [12:21] small :-) [12:21] lool: there is a copy of old hello world somewhere, gatox is loking for it [12:22] lool, hi, ralsina asked me to give you this old clicks: http://ubuntuone.com/0mHE7D9wQLkd2DXBJROxTi - http://ubuntuone.com/3KnGeEQjvt9nXul0JLLDew [12:23] gatox: ty [12:24] lool, ralsina can I propose landing a critical fix first in the ubuntu-download-manager (that was there for a long time but had no reviews?) [12:25] lool, ralsina ideally, files should not cleaned after they have been downloaded, yet in case they are not I added => https://code.launchpad.net/~mandel/ubuntu-download-manager/throw-error-exists/+merge/187527 [12:28] didrocks: eh, it seems cordova-doc build is hanged ;/ [12:28] didrocks: "Started 6 hours ago" [12:28] didrocks: and it doesn't move at all [12:28] I'll abort it maybe? [12:28] Ok, no, wait, it moves [12:29] But why 6 hours? [12:31] Can someone make the CI re-run on https://code.launchpad.net/~laney/ubuntu-system-settings/measure-size-critical-fix/+merge/188020 ? [12:32] mandel: looking [12:32] lool, take into account that in the case where the file is not removed by the client we are appending to it, and that is a terrible idea. It is also the possible cause to see those 200% progress results [12:33] Laney: done [12:33] merci [12:34] lool: let's land that as well, but it has no correlation with the click stack, it can go in any order (if that helps) [12:36] sil2100: (if this didn't get resolved while my connection was bouncing) Have you checked that the logtail isn't progressing? [12:37] mandel: hmm looking at the diff, I'm not too convinced with the file handling stuff [12:37] sil2100: In fact, it looks like the logtail *is* progressing, so it's not huge, just slow due to png compression [12:37] *not hung [12:37] lool, what worries you? [12:37] mandel: that the download service itself is running unconfined and writing to computed pathnames [12:38] like appending an id at the end of a filename to create a new one [12:38] cjwatson: as I mentioned: "Ok, no, wait, it moves", but I wonder why it takes 6 hours already [12:38] I'm not sure how secure and private the ids are, but it seems like this could be abused with a symlink created by a malicious app to write outside of its app dir [12:38] cjwatson: since damn, it's i386, 6 hours for one package is a LOT [12:39] sil2100: png compression can be enormously slow on systems with lots of pngs [12:39] unfortunately [12:39] s/systems/packages/ [12:39] lool, the downloader is, when running as a system app, writing anywhere it wants, hence the error, the appending is just happening when we are running for a request of a confined app, in that case we are writing to XDG_DATA/APP_ID/filepath(uuid if needed) [12:39] cjwatson: thanks [12:40] sil2100: you can make sure all pngs are already optimised in the source (or that it doesn't make enough of a difference in size to be worth it), and then export NO_PNG_PKG_MANGLE=1 while running dh_builddeb [12:40] mandel: exactly, so if I'm app==APP)ID, what happens if I create a filepath-uuid -> ~/.upstart/my-job.conf symlink and make download manager download an upstart job? [12:40] e.g. override_dh_builddeb:\n\tNO_PNG_PKG_MANGLE=1 dh_builddeb === thostr_ is now known as thostr_brb [12:42] mandel: anyway, to box this I propose we land whatever you think are good fixes that pass the testsuite and aren't regressing click downloads or system-image testsuite; we can worry about the confined app use case later and get a security review [12:42] we need to ask security team about apparmor profiles anyway [12:43] lool, so, you mean that you point me to download an upstartjob, then if you are confined I'll write it to XDG_DATA/APPID/my-job.conf [12:43] lool, what is wrong with that? [12:43] lool, then, I think we should land that branch [12:50] mandel: the symlink part was that it would write the download to ~/.upstart/my-job.conf for an unconfined app [12:50] lool, we can always return an error if the file is present [12:51] lool, and let app developers deal with it [12:51] mandel: right; you need to do the write in a secure way, race free [12:51] lool, can you add a comment and I'll update the branch so that if present, we raise an exception [12:51] mandel: typically if(!exists(file)) {write(file)} is racy [12:52] lool, I fear that the click scope is not cleaning the files and that will break it :-/ === alan_g|lunch is now known as alan_g [12:52] mandel: anyway, I dont think this relates, reading the diff just made me realize this isn't ready for prime time for the confined apps [12:52] lool, so, I'll add that fix and we won't land it 'til I have checked that the click-scope is doing things correctly [12:52] morning [12:52] will log a bug [12:52] lool, thx [12:52] mandel: let's land your fix though [12:53] lool, ok, I'll pay attention to that, we need to ask security, I'd like their input for this [12:54] mandel: it's non-trivial to get it right, e.g. that applies when creating the download directory too [12:54] mandel: I believe you're right; I've noticed in the past that if I use the click scope to install a package, then manually make it look like a lower version on the filesystem, then use click-updatemanager to try to upgrade it, that the download manager creates a download file consisting of two copies of the package concatenated, and the click-updatemanager reports 200% progress and then fails to install the invalid file [12:55] cjwatson, yeah, that is an issue, both in the downloader and the scope, that branch fixes it just changing the downloader side [12:55] mandel: https://bugs.launchpad.net/ubuntu-download-manager/+bug/1233149 [12:55] Ubuntu bug 1233149 in ubuntu-download-manager "Must write downloads of confined apps securely" [Undecided,New] [12:55] lool, thx [12:55] * mandel goes to have some food [12:58] didrocks: so the above important bugfix from https://code.launchpad.net/~mandel/ubuntu-download-manager/throw-error-exists/+merge/187527 is pending merging, but is part of click-package stack; I'd like to get it in too, that way we update all packages of the click-package stack today ;-) [12:58] my only problem is that I'm falling asleep [13:07] ralsina: gah, would you please a) top approve https://code.launchpad.net/~mandel/ubuntu-download-manager/throw-error-exists/+merge/187527 b) tell your team to top approve stuff and not just approve it or upstream merger doesn't merge c) give me / others permissions to top approve your branches? Thanks! :-) [13:07] lool: approved, mandel forgot to do it after it was agreed to land it [13:09] asac: ping [13:09] cwayne: He's on holiday [13:10] cjwatson: ah, thanks.. a /nick asac-holiday could've been helpful :) [13:10] didrocks: ping [13:13] ogra_: hi! Do you have a moment ;)? [13:14] sil2100, shoot [13:14] ogra_: I need core-dev ACKs for: http://10.97.0.1:8080/view/cu2d/view/Saucy/view/Settings/job/cu2d-settings-saucy-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-system-settings_0.1+13.10.20130930-0ubuntu1.diff and http://10.97.0.1:8080/view/cu2d/view/Saucy/view/Settings/job/cu2d-settings-saucy-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-system-settings-online-accounts_0.2~+13.10.20130930-0ubu [13:16] sil2100: ack on the first, nack on the second [13:16] sil2100: Shouldn't be "Section: debug" [13:16] Hah, other packages are like that, but it's still wrong :) [13:16] thanks for checking cjwatson ... i seem to not be able to reach that machine [13:17] cjwatson: will you give a conditional ACK if I promise to prepare a merge for changing that? ;) [13:18] sil2100: I'd suggest just deleting the Section: line [13:18] sil2100: I'm just checking some context for the rest of it [13:19] sil2100: Surely you need to handle dh_python2/dh_python3 integration too? [13:19] sil2100: It's not generally OK to just dump files into /usr/lib/python*/dist-packages/ without the use of any Python helper [13:21] cjwatson: well, sorry, but that's what 90% of our touch -autopilot packages do right now, so even if it's not really ok, that's the standard that is currently used [13:21] cjwatson: ;) [13:21] I'm afraid that doesn't convince me to ack it [13:22] cjwatson: I'm not the one doing the packaging here [13:22] sil2100: I think you basically need (a) Build-Depends: python (>= 2.7); (b) dh $@ --with=python2; (c) add ${python:Depends} to Depends [13:22] That still doesn't convince me to ack it :) [13:22] You aren't going to convine me to ack something incorrect [13:22] *convince [13:22] cjwatson: ok then, I'll wait for didrocks to decide on what to do with this release [13:22] cjwatson: then why didn't the release team reject all the other packages if they are incorrect? [13:22] The above sequence should be basically all you need, simple enough [13:22] sil2100: I didn't see them :-P [13:22] cjwatson: right [13:23] the wonderful world of auto-approval [13:23] didrocks: ping, the settings stack is blocked for now, see ^ for context [13:24] Might also need "X-Python-Version: 2.7" since autopilot.pro hardcodes 2.7 [13:24] In which case Build-Depends: python (>= 2.6.6-3~) is actually more correct [13:25] Given that this is a five-minute build, this should take about ten minutes to fix [13:26] I'll go and fix overrides for the other autopilot packages in the archive; that "Section: debug" has a good chance of causing problems once ddeb support is fully implemented in Launchpad [13:26] (As in, the packages will probably vanish from the primary archive) [13:28] Oh good grief, all *-dbg are in debug. I wonder if I misunderstood that section ... [13:28] Looks like I did. Hmm. [13:30] sil2100: I withdraw the "Section: debug" part of my comment; I think it might perhaps be better for *-autopilot to be in some other section, but we can override it in the archive if we so choose and it isn't a blocker of any kind at the package's end [13:35] lool: ack [13:35] sil2100: cordova-doc: please abort I guess [13:36] sil2100: oh, no, it doesn't. Hum, the build seems very long [13:36] sil2100: so, let's try to release it so that we don't have it again [13:37] didrocks: so we should wait for it to finish? (7 hours running already) [13:38] sil2100: yeah, and then, we ensure it's in [13:38] ACK [13:40] sil2100: keeping a look on that? [13:41] didrocks: I'll keep a tab opened, hope it will finish building till the end of the day! [13:43] sil2100: cjwatson: we have examples in other packages how we handle building with python [13:43] sil2100: look at unity8 (debian/rules) [13:43] sil2100: so I doubt 90% of the packages are doing that, for those I looked at least… [13:44] I'm preparing a patch for friends-app now by way of example [13:44] didrocks: well, notes-app, gallery-app, friends-app [13:44] didrocks: messaging-app as well [13:44] And yeah, unity8 is better [13:44] didrocks: I would say that all *-app packages that we daily release have that [13:44] So let's fix them and not get it wrong in new code [13:45] didrocks: so it's no wonder someone added the autopilot packaging in the same way [13:45] Like I say, it's really not hard, I'm preparing a patch that people can crib from [13:45] sil2100: yeah, same issues than autotools… [13:46] cjwatson: +1 [13:48] didrocks: if you guys say it's invalid, well, I won't argue as yes, it's a bit strange to not use setup.py - I only wonder how we were able to push so many packages with this into the archive, I thought that it's acceptable since that happened [13:49] sil2100: for unity8, I've implemented a setup.py upstream for this [13:49] Not using setup.py is also weird, but it wasn't what I commented on. [13:51] sil2100: https://code.launchpad.net/~cjwatson/friends-app/dh-python2/+merge/188338 - shouldn't be harder than that for the others [13:51] (Of course some other core dev should probably eyeball that) [13:53] cjwatson: is python:any valid? Just asking since somehow somewhere I remember we had a problem with using that (I might me mixing up problems though) [13:55] sil2100, https://launchpad.net/ubuntu/+source/qtbase-opensource-src/5.0.2+dfsg1-7ubuntu5 is what you remember [13:56] seb128: thanks! heh, something similar was echoing in my ears and I couldn't differentiate it from the noise [14:01] Is there a hidden point to the libfriends upload that just bumps standards-version? [14:04] retoaded, dns resolution is failing on the qa machines (i.e. ps-saucy-server-amd64-1, ps-android-sandybridge). Is this a known issue? [14:04] sil2100: Yes, it is valid. Some details of it were only fixed up in the last few months [14:05] cjwatson: I get a lintian error on your branch - is that normal? [14:05] cjwatson: E: friends-app source: missing-build-dependency-for-dh-addon python2 => python | python-all | python-dev | python-all-dev [14:05] fginther, let me poke but it may be related to me changing the DHS/DHCP services for those networks. [14:05] Er, by which I mean "two weeks ago" [14:05] sil2100: Yes, that's Lintian being out of date and can be ignored [14:07] sil2100: FWIW, while the change seb128 pointed to would have been blocked by the infrastructure bug that I fixed on 16 September, it would have been blocked anyway because the previous state was just wrong; you can only use :any dependencies if the target of the dependency is Multi-Arch: allowed [14:07] sil2100: But python is Multi-Arch: allowed, and is indeed the canonical example of this kind of dependency [14:07] We have quite a few of these in the archive now [14:15] ACK, awesome [14:22] cjwatson: https://code.launchpad.net/~sil2100/ubuntu-system-settings-online-accounts/dh_python2/+merge/188340 <- is the same change ok here? [14:24] sil2100: Yep, looks fine [14:24] sil2100: That has my ack with that merge [14:24] cjwatson: thanks [14:25] mfisch: next day or two according to pete-woods [14:28] * cjwatson sees that security has taken over the build farm for a while [14:28] == Building click-package stack == [14:28] ralsina, lool I just top approve when I have two reviews, that is why that branch was not merged, let me know if you want me to change that :) [14:28] Uploaded click 0.4.9 [14:28] to pick up the ubuntu-download-manager rev that got merged a couple of minutes after the tick [14:28] great ;) [14:28] mandel: I top-approved it anyway [14:29] mandel: If you have a stricter policy than one review that's fine; usually folks reviewing just approve + top approve things when they are happy with it, and the upstream merger jenkins does another approve if it builds and passes the configured tests [14:30] lool, we usually do 2 human reviews + jenkins bot, if all those 3 are ok then the person that proposes the branch does the top approve (in case the mp had comments for non blocking changes for example) [14:33] mandel: ok; nervermind then, this is special to your team, and I cant blame you guys for doing one more review than what others do [14:35] sil2100: apart from that, testing the settings went ok? so you can publish them both once rebuilt? [14:35] sil2100: also, I feel cordova-docs is *almost* merged ;) [14:35] built* [14:36] sil2100: also, the customization hooks have progressed? [14:36] (not sure if you followed, but I got why it didn't show up this morning) [14:37] didrocks: testing went fine, ran the AP tests on the device as well, but some of the tests are actually desktop-only [14:37] didrocks: did some dogfooding, all green [14:37] Yeah, cordova-docs is built now [14:38] sil2100: please publish whatever you can, will be helpful before the meeting to know what's still needed for image 71 [14:38] I think I'll rebalance the i386/amd64 builders back to 4/4, since there's a bit of a queue [14:39] didrocks: the customization hooks were updated last week but haven't landed yet [14:39] 10 pending amd64 builds [14:39] cwayne: yeah, we are working on publishing it [14:39] didrocks: cool, thanks. just saw customization-hooks and figured i'd give some context :) [14:40] didrocks: will rebuild settings once my merge gets in [14:40]