/srv/irclogs.ubuntu.com/2015/09/07/#ubuntu-ci-eng.txt

=== michihenning is now known as michi
Mirvanpok_: 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:07
Mirvanpok_: except that it's not compatible with the mir it seems?05:26
=== chihchun_afk is now known as chihchun
anpok_Mirv: ok I need to take a look06:26
anpok_Mirv: oh yes .. becaue vivid uses an older mir release before the deprecated api was removed. Will fix and come back.06:30
=== chihchun is now known as chihchun_afk
Mirvanpok_: ok06:42
=== slangase` is now known as slangasek
=== davmor2_HOLS is now known as davmor2
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.08:42
Mirvanpok_: morphis: uploading all things :)09:05
anpok_Mirv: thx09:06
morphisMirv: great09:07
popeycihelp: any reason https://code.launchpad.net/~popey/ubuntu-filemanager-app/add-click-deps/+merge/270287 isn't being picked up by jenkins?12:05
=== alan_g is now known as alan_g|lunch
popeyit seemed to work on 29th Aug.. http://91.189.93.70:8080/job/ubuntu-filemanager-app-vivid-amd64-ci/?12:06
Mirvcyphermox: a main package with packaging changes would need publishing https://ci-train.ubuntu.com/job/ubuntu-landing-035-2-publish/17/13:06
=== alan_g|lunch is now known as alan_g
psivaapopey: this has now been picked up, right? https://code.launchpad.net/~popey/ubuntu-filemanager-app/add-click-deps/+merge/27028713:59
popeypsivaa: yes, it seems to, thanks!14:00
psivaanp14:00
pete-woodskyrofa: hey. was starting to type up that mailing list post about not being able to flash my mediatek devices14:16
pete-woodskyrofa: these are my logs http://paste.ubuntu.com/12307383/14:16
pete-woodswondered if there was anything from your machine I could add, to try and avoid turning it into a anti-MacBook thread14:16
=== alan_g is now known as alan_g|EOD
slangasekmichi: 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:15
robruslangasek: the silo isn't published https://requests.ci-train.ubuntu.com/#/ticket/29518:20
robruslangasek: also archive version seems old18:25
robruslangasek: 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*/ ? ;-)18:30
slangasekrobru: can you give me the link to what it is that needs published? this isn't exactly discoverable from the jenkins url you gave me19:28
slangasekrobru: is https://requests.ci-train.ubuntu.com/#/ticket/309 the one?19:29
slangasekright, that seems to be the one; publishing19:31
robruslangasek: oh sorry, it's discoverable if you truncate the url and change "1-build" to "2-publish" ;-)21:03
cjwatsonrobru: I must remember that excuse for LP21:05
michislangasek: Yes, I got someone else to review it, but it’s only gone into our devel branch.21:06
michiIt’s not in the archives.21:06
michislangasek: Pawel was going to put together another MR (identical) that targets trunk.21:09
robrucjwatson: well it's obvious to /me/, cmon get with the program here21:14
robruI suppose i could change the diff generation to include a link to the publish job.21:15
slangasekrobru: or you could provide a link to the landing instead of to the diff :)21:49
robruslangasek: but then it wouldn't be clear where to get the diff from21:50
robrueither way you're hunting21:51
slangasekrobru: follow the 'build' link, click on the latest build, look at the artifacts...?  that's much more intuitive than playing url regexp bingo21:51
robruslangasek: 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 that21:52
robru"hadn't been built" of course meaning "nobody thought to run the jenkins build job"21:53
robruslangasek: 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 silo21:56
robrujenkins is really a mess ere21:56
robruhere21:56
robruslangasek: 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 not21:58
michirobru: ping23:04
robrumichi: pong23:04
michiHi, thanks for getting back!23:05
robrumichi: it is a holiday but I'm around for a bit23:05
michiI’d like to build a branch in a silo, but in debug mode. Is that possible?23:05
robrumichi: what do you mean by debug mode?23:05
robrumichi: you mean you want the ddebs?23:05
michiA debug build instead of a release build23:05
michiThe silo builds the cmake project with -DCMAKE_BUILD_TYPE=release, I believe.23:06
michiI’d like debug instead.23:06
robrumichi: what? the silo absolutely has no knowledge of cmake.23:06
michiOK, yes...23:06
robrumichi: if your debian/rules is setting that variable, just push a commit that sets it to somethng else23:07
michiSo, what debian magic do I need to perform to end up with packages built in debug mode?23:07
michiI’m not setting anything in rules.23:07
michiI guess my real question is: what do I need to change in rules to get the build setting I need?23:07
michiI still don’t know anywhere near enough about debian :(23:07
robrumichi: like "override_dh_build: make CMAKE_BUILD_TYPE=debug" or something then23:07
robrumichi: what silo?23:08
michiOK, cook, thank you!23:08
michi2723:08
robrumichi: replace "make" with whatever is actually necessary to build, so probably "cmake" or somethng23:08
michiOK, I’ll have a tinker, thanks!23:08
robrumichi: 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/rules23:09
michiWill try, thanks!23:10
robrumichi: 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 control23:10
michiOK, I’m abusing the silo :)23:10
michiI need to generate ABI baselines for all architectures.23:10
michiI don’t have all the machines I would need to do it locally.23:11
robrumichi: that I have no idea about23:11
michiSo, the plan is to use the silo to generate all the ABI baselines.23:11
michiThen I can pull the debs, pull the ABI files out them, and check them into the source tree.23:11
michiBut that only works if the lib is built in debug mode.23:11
robrumichi: that sounds like something that would work assuming that the *.install files know to include these ABI files in the final build.23:12
michiIt’s all about automating the ABI compliance checks so they run every time we build/test on Jenkins and a silo.23:12
michiYes, that’s the plan.23:12
michiIt’s all just a temporary setup so I can get the files generated for each architecture.23:12
michiOnce I have them, I can just throw the branch and the silo away23:12
robrumichi: 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 later23:12
michiOK, cool, thanks!23:12
robrumichi: you're welcome23:13

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!