[05:07] <Mirv> anpok_: it seems you got it uploaded by robert. let me run a watch_only build on the silo to get the status right, someone has erronously clicked on that silo.
[05:26] <Mirv> anpok_: except that it's not compatible with the mir it seems?
[06:26] <anpok_> Mirv: ok I need to take a look
[06:30] <anpok_> Mirv: oh yes .. becaue vivid uses an older mir release before the deprecated api was removed. Will fix and come back.
[06:42] <Mirv> anpok_: ok
[08:42] <anpok_> Mirv: had to re-add the patches from the 0.14 landing, can you use the link I sent you?
[08:42] <anpok_> I cannot upload it on my own.
[09:05] <Mirv> anpok_: morphis: uploading all things :)
[09:06] <anpok_> Mirv: thx
[09:07] <morphis> Mirv: great
[12:05] <popey> cihelp: any reason https://code.launchpad.net/~popey/ubuntu-filemanager-app/add-click-deps/+merge/270287 isn't being picked up by jenkins?
[12:06] <popey> it seemed to work on 29th Aug.. http://91.189.93.70:8080/job/ubuntu-filemanager-app-vivid-amd64-ci/?
[13:06] <Mirv> cyphermox: a main package with packaging changes would need publishing https://ci-train.ubuntu.com/job/ubuntu-landing-035-2-publish/17/
[13:59] <psivaa> popey: this has now been picked up, right? https://code.launchpad.net/~popey/ubuntu-filemanager-app/add-click-deps/+merge/270287
[14:00] <popey> psivaa: yes, it seems to, thanks!
[14:00] <psivaa> np
[14:16] <pete-woods> kyrofa: hey. was starting to type up that mailing list post about not being able to flash my mediatek devices
[14:16] <pete-woods> kyrofa: these are my logs http://paste.ubuntu.com/12307383/
[14:16] <pete-woods> wondered if there was anything from your machine I could add, to try and avoid turning it into a anti-MacBook thread
[18:15] <slangasek> michi: I saw that your single tree packaging changes are now marked as "merged"; does that mean you got another core dev to review the packaging changes and they've now landed in the archive?
[18:20] <robru> slangasek: the silo isn't published https://requests.ci-train.ubuntu.com/#/ticket/295
[18:25] <robru> slangasek: also archive version seems old
[18:30] <robru> slangasek: if you're around can you ack & publish https://ci-train.ubuntu.com/job/ubuntu-landing-040-1-build/53/artifact/ubuntu-settings-components_packaging_changes.diff/*view*/ ? ;-)
[19:28] <slangasek> robru: can you give me the link to what it is that needs published? this isn't exactly discoverable from the jenkins url you gave me
[19:29] <slangasek> robru: is https://requests.ci-train.ubuntu.com/#/ticket/309 the one?
[19:31] <slangasek> right, that seems to be the one; publishing
[21:03] <robru> slangasek: oh sorry, it's discoverable if you truncate the url and change "1-build" to "2-publish" ;-)
[21:05] <cjwatson> robru: I must remember that excuse for LP
[21:06] <michi> slangasek: Yes, I got someone else to review it, but it’s only gone into our devel branch.
[21:06] <michi> It’s not in the archives.
[21:09] <michi> slangasek: Pawel was going to put together another MR (identical) that targets trunk.
[21:14] <robru> cjwatson: well it's obvious to /me/, cmon get with the program here
[21:15] <robru> I suppose i could change the diff generation to include a link to the publish job.
[21:49] <slangasek> robru: or you could provide a link to the landing instead of to the diff :)
[21:50] <robru> slangasek: but then it wouldn't be clear where to get the diff from
[21:51] <robru> either way you're hunting
[21:51] <slangasek> robru: follow the 'build' link, click on the latest build, look at the artifacts...?  that's much more intuitive than playing url regexp bingo
[21:52] <robru> slangasek: in some cases the diff is on the publish job, if you recall we had that issue where a silo was "built" but certain manual sources hadn't been built and thus had no diffs. the publish job regenerates all diffs before publishing to get around that
[21:53] <robru> "hadn't been built" of course meaning "nobody thought to run the jenkins build job"
[21:56] <robru> slangasek: also super confusing is that the jenkins job lists the artifacts only for the most successful run, so when I click publish and it fails, and you go to the publish job, the artifacts it shows are not at all for the thing I'm trying to publish but for whatever was previously published from that silo
[21:56] <robru> jenkins is really a mess ere
[21:56] <robru> here
[21:58] <robru> slangasek: when I get to replacing jenkins I'll have to make a point of developing a silo summary page that includes the "built-ness" of individual packages rather than the whole silo, and offers all "artifacts" in one place, regardless of whether they're build artifacts or publish artifacts, or whether the job was successful or not
[23:04] <michi> robru: ping
[23:04] <robru> michi: pong
[23:05] <michi> Hi, thanks for getting back!
[23:05] <robru> michi: it is a holiday but I'm around for a bit
[23:05] <michi> I’d like to build a branch in a silo, but in debug mode. Is that possible?
[23:05] <robru> michi: what do you mean by debug mode?
[23:05] <robru> michi: you mean you want the ddebs?
[23:05] <michi> A debug build instead of a release build
[23:06] <michi> The silo builds the cmake project with -DCMAKE_BUILD_TYPE=release, I believe.
[23:06] <michi> I’d like debug instead.
[23:06] <robru> michi: what? the silo absolutely has no knowledge of cmake.
[23:06] <michi> OK, yes...
[23:07] <robru> michi: if your debian/rules is setting that variable, just push a commit that sets it to somethng else
[23:07] <michi> So, what debian magic do I need to perform to end up with packages built in debug mode?
[23:07] <michi> I’m not setting anything in rules.
[23:07] <michi> I guess my real question is: what do I need to change in rules to get the build setting I need?
[23:07] <michi> I still don’t know anywhere near enough about debian :(
[23:07] <robru> michi: like "override_dh_build: make CMAKE_BUILD_TYPE=debug" or something then
[23:08] <robru> michi: what silo?
[23:08] <michi> OK, cook, thank you!
[23:08] <michi> 27
[23:08] <robru> michi: replace "make" with whatever is actually necessary to build, so probably "cmake" or somethng
[23:08] <michi> OK, I’ll have a tinker, thanks!
[23:09] <robru> michi: you're welcome. you might also try exporting the variable at the top here: http://bazaar.launchpad.net/~michihenning/unity-scopes-api/abi-compliance/view/head:/debian/rules
[23:10] <michi> Will try, thanks!
[23:10] <robru> michi: what's your goal though? to have a package where the symbols aren't stripped out? because that happens deep in the debian tooling, probably not something that cmake can control
[23:10] <michi> OK, I’m abusing the silo :)
[23:10] <michi> I need to generate ABI baselines for all architectures.
[23:11] <michi> I don’t have all the machines I would need to do it locally.
[23:11] <robru> michi: that I have no idea about
[23:11] <michi> So, the plan is to use the silo to generate all the ABI baselines.
[23:11] <michi> Then I can pull the debs, pull the ABI files out them, and check them into the source tree.
[23:11] <michi> But that only works if the lib is built in debug mode.
[23:12] <robru> michi: that sounds like something that would work assuming that the *.install files know to include these ABI files in the final build.
[23:12] <michi> It’s all about automating the ABI compliance checks so they run every time we build/test on Jenkins and a silo.
[23:12] <michi> Yes, that’s the plan.
[23:12] <michi> It’s all just a temporary setup so I can get the files generated for each architecture.
[23:12] <michi> Once I have them, I can just throw the branch and the silo away
[23:12] <robru> michi: ok sounds like you know what to try then. I'm gone in about an hour so if you have any questions better to ask sooner than later
[23:12] <michi> OK, cool, thanks!
[23:13] <robru> michi: you're welcome