[00:25] veebers: force is fine. Or if you just want to rebuild one you can specify which one. [01:10] robru: coolio, thanks [01:18] veebers: you're welcome [01:18] kgunn: "invalid package" means your silo isn't configured to include that package in the sync. [01:19] robru: i'm not familiar with syncing like that, do you guys do that upload of the src pkg? or how does it work ? [01:19] kgunn: what request is it? [01:20] robru: sorry, silo 54 alberta's sync of mir to vivid+o [01:20] kgunn: well for starters this request is totally wrong in every possible way [01:20] lol [01:20] good to know [01:20] kgunn: you can't mix MPs and syncs. those are different things [01:21] robru: what's your recommendation in this instance ? [01:21] kgunn: the sync syntax changed a bit but "sync:mir" isn't valid the new way or the old way, that's totally out to lunch. [01:21] kgunn: what are you trying to do? [01:21] so here's what we got [01:21] mir, usc, qtmir are all in wily properly...and i think we just want to promote all those into vivid+o [01:22] kgunn: so you just want to copy those three packages from wily to vivid+o without any changes at all? [01:22] robru: correct, rebuilt of course.... [01:22] for gcc considerations [01:23] kgunn: right [01:23] robru: and actually...i think usc and qtmir can simply be rebuilt [01:23] kgunn: ok, those MPs are empty. I'm not sure where he got the idea to do that. [01:23] i don't think they differ [01:23] right [01:23] he was flying unguided i think [01:23] kgunn: empty MPs are only needed if you're doing a no change release of trunk (eg if you landed changes in trunk without using the train). not for syncs. [01:24] kgunn: ok so here's what you do. empty out the merges field. put the source names you want in the sources field (WITHOUT the 'sync:' bit) [01:24] kgunn: the rest of the fields look good [01:25] kgunn: then click assign to configure the silo, then click build and it'll do a source copy that rebuilds against the appropriate gcc [01:25] robru: and if i am syncing like this, even tho there's no diff for qtmir/usc....do i still list those as pkgs in the "manual src" block ? [01:25] which will in effect rebuild them [01:25] ? [01:26] kgunn: yes, if you don't include them in the sources field then the train won't know what packages to copy in the sync. [01:26] robru: oh and for qtmir-gles...it's kinda weird [01:26] does it autoknow ? [01:27] kgunn: it auto knows that what you put in the sources field are the names of the packages it's going to sync for you. [01:27] robru: right but as i recall qtmir-gles links to the pkg biuld version from qtmir....which is why we always built it last, unless someone automated that [01:28] e.g. i guess i may need a ppa for qtmir-gles [01:28] kgunn: ok, you might need an MP for the -gles that updates the debian/watch [01:28] i'll at least get mir/usc/qtmir built...and i can sort the qtmir-gles in the morning [01:29] kgunn: it's worth trying. I'm not sure off the top of my head how sync code will handle a -gles package. if the PPA accepts the orig.tar it should be fine, if it uses debian/watch it'll get confused. unless you get lucky and get the same silo, lol ;-) [01:30] thanks for the help tho [01:30] kgunn: you're welcome [01:30] kgunn: but you can't have any MPs in the silo config, you have to remove the -gles one too [01:31] kgunn: syncs and MPs are totally incompatible within the same silo [01:31] kgunn: if -gles doesn't work as a sync you'll have to do it in a separate silo later. [01:32] kgunn: and you should file a bug about that, that should be supported by the train. in fact the train could go so far as to automatically set debian/watch for you each time so you don't have to worry about it. [01:32] oh...i would like that very much [01:32] kgunn: file the bug against lp:cupstream2distro [01:32] shouldn't even be hard, but I have some other priorities first. [01:33] robru: fwiw...i just read scrollback...i left the gles mp in there, and the sync seemed to work ? [01:33] or did i just do something undefined [01:34] kgunn: it might be working since you specified which packages to build in a way that excluded the -gles mp but generally the behavior of MPs and syncs together in a silo is undefined, I'm not sure what'll happen when you try to build the MP === chihchun_afk is now known as chihchun === chihchun is now known as chihchun_afk [04:45] who is doing QA at this hour? [04:45] oh, veebers, it's you [04:45] you want i should publish that? [04:46] robru: heh :-) yes please [04:46] robru: speaking of 'at this hour' are you ever offline? ;-) [04:47] veebers: I usually sleep between 4AM and 4:15AM. [04:47] robru: lol ^_^ [04:47] veebers: just kidding, I usually sleep in actually, but it's only 10pm here! [04:48] veebers: oooh, look at Mr Fancy Pants fixing his build by ignoring errors! === chihchun_afk is now known as chihchun [04:59] robru: hah, that's due to new flake8/pep8 rules coming along which I disagree with, but perhaps I will come around to liking them and remove those ignores [05:00] veebers: heh, yeah, I think dobey got hit by something similar as well, I'm not sure what the new errors are personally [07:07] chihelp: Hi! We have been consistently getting failures in job 'mir-android-vivid-i386-build' for the last day or so: " libboost-all-dev : Depends: libboost-python-dev but it is not going to be installed" [07:07] cihelp: Hi! We have been consistently getting failures in job 'mir-android-vivid-i386-build' for the last day or so: " libboost-all-dev : Depends: libboost-python-dev but it is not going to be installed" [07:08] cihelp: Any idea how we can fix this? It's blocking all mir CI jobs [07:15] bfiller: renatu charles: I got permission to publish 024, but you will need to fix bug #1491255 for the next release, to track API [07:15] bug 1491255 in indicator-transfer (Ubuntu) "Add .symbols file for tracking API" [High,New] https://launchpad.net/bugs/1491255 [07:16] ogra_: could you merge + publish both https://code.launchpad.net/~timo-jyrinki/ubuntu-seeds/ubuntu-touch.wily_remove_friends/+merge/267648 and https://code.launchpad.net/~timo-jyrinki/ubuntu-seeds/ubuntu-touch.wily_add_indicator-transfer-download-manager/+merge/269846 (latter needs approval, but it's related to this 024 landing now, adding a plugin package) [07:16] I can upload the vivid overlay meta package change [07:18] Mirv: thanks for publishing silo 9 [07:23] Mirv: when I setup a sync silo to get something from wily, does it fetch that from the proposed pocket too? [07:24] morphis: no problem. yes I'd say it'd fetch from proposed pocket too, but remains to be seen :) [07:24] ok [07:24] lets try it [07:26] dbarth__: hi, repeating from yesterday, did you see robert's comments on 052 silo about it being a dual silo but configured for wily for some reason? it's QA granted, so if you want I can reconfigure it as dual again and publish, but we just want to understand why it's marked as 'wily' at the moment. [07:28] bregma: did you see sil2100's comment in bileto last week about additional changes needed to silo 027 / Libertine before it can be published? a symbol file would be best added (the archive admins will want it), and an arch:all correction. [07:32] Mirv: seems that this doesn't work: 0.229 does not seem to be a CI Train generated version number, series version change is not supported for non-train uploads. [07:33] I remember ... non train upload can't be changed in their release version ... [07:33] lets do this different then === zbenjamin_ is now known as zbenjamin [07:34] morphis: ah right again, we need to just continue doing manual uploads [07:34] zbenjamin: would you have time today to verify the silo 025 / QtC so that I could publish it? [07:34] would be the best if we change lxc-android-config to be citrain based finally ... [07:35] morphis: well that would be something, yes [07:35] Mirv: meh i totally forgot about that... multitasking pretty heavily atm :D === chihchun is now known as chihchun_afk [07:36] zbenjamin: I know the feeling, no problem :) [07:43] Mirv: who to quick ask to double the size of this PPA? https://launchpad.net/~ubuntu-sdk-team/+archive/ubuntu/tools-development [07:44] Mirv: any idea what I have to change for that? never did that before [07:44] bzoltan_: file an internal RT ticket and refer to that on webops channel [07:44] Mirv: OMG .. .really? Still? [07:45] Mirv: I need it in a minute... [07:45] bzoltan_: well that's my guess, they probably get some karma for closing tickets [07:46] morphis: take .bzr-builddeb from eg http://bazaar.launchpad.net/~phablet-team/camera-app/trunk/files - that's probably about it. for the first release, add a manual new changelog entry in your MP with UNRELEASED as status. with those the train might be able to build it. [07:46] morphis: oh right, we need project :D [07:47] right [07:47] just a moment [07:47] bzoltan_: well ask the vanguard on webops directly then [07:47] Mirv: let me check with ogra_ too [07:47] ogra_: is there anything which prevents us from switching lxc-android-config to be citrain based? [07:48] yeah, that should be useful [07:48] morphis, except of my lazyness to do the fiddling for it there never was one :) [07:49] ogra_: ok, me and morphis can fiddle it then :) [07:49] :D [07:51] ogra_: great! [07:51] morphis: ok you can now push branches against lp:lxc-android-config [07:51] Mirv: so is that fine even if we have a version gap between vivid-overlay and wily atm? [07:51] starting with eg the addition of .bzr-builddeb and a new changelog entry, and that can then be tried to be built [07:52] morphis: we could do a vivid branch for overlay [07:52] ok [07:52] well, I can do that now too [07:52] hm [07:52] I would try to prevent us from doing that [07:52] just takes more time to merge things etc. [07:53] there is one change in wily I need to double check if that causes regressions on vivid [07:53] morphis: well sure, if you think we can land to trunk to overlay, that's always the best === chihchun_afk is now known as chihchun [08:08] alf_: do you have the link for the job? [08:23] psivaa: https://jenkins.qa.ubuntu.com/job/mir-android-vivid-i386-build/ [08:25] alf_: ack, thanks. I'm in the middle of debugging something else. will take a look at this in a bit [08:26] psivaa: Great thanks [08:32] Mirv: but looks good [08:33] alf_: generally depending on boost-all-dev is frowned upon, you might be able to make some progress by selecting the individual boost packages you really need. [08:34] alf_: but other than that i dunno [08:37] Mirv: there we go: https://code.launchpad.net/~morphis/lxc-android-config/add-citrain-support/+merge/269859 [08:37] Mirv: I'm surprised to see 52 in the NEW queue, i thought there was a bug that made publishes skip that [08:38] robru, might be very late, but does the ci bot use wily, is it using gcc 5? I'm getting diff symbols in my wily machine than in the bot :-/ [08:39] mandel: the train uses a pbuilder that matches the series is building for. So you get gcc5 in wily and 4.9 in vivid [08:39] robru, hm.. I wonder what is going on :-/ [08:39] mandel: not sure, I'm not a symbols expert [08:40] morphis: did you check your packaging against https://wiki.ubuntu.com/DailyRelease/InlinePackaging ? [08:40] robru: no [08:41] robru, don't worry, at least I'm 100% sure that it is not the bot, that is enough info [08:41] morphis: those are the official train packaging guidelines, you should probably look it over. Review looks good for what's there but there might be other things missing [08:41] robru: it looks so [08:42] atleast the build failed [08:46] abeato: you can't release a wily trunk to vivid, either do a dual silo or branch for vivid [08:48] morphis: not sure about that error there, can't find the orig.tar... It might be because your trying to change the version from native to nonnative... Try pushing those changes to trunk and then putting a null mp in the silo. [08:48] robru, I was trying to see if I could create 2 MPs from one branch, with one MP targeting vivid and the other wily [08:49] robru, but does not seem possible [08:49] morphis: ah, you found the wiki page thanks to robert too! [08:49] yeah [08:49] abeato: no, that's a horrible idea. What would happen when they merge to trunk? You'd have conflicting changelogs [08:49] robru: my latest info is that source NEW:s go to the queue (and that's why we don't need to ask preNEW-review for them), while binary new:s are skipped so we need to manually ask for the reviews [08:49] abeato: if you want to release to both from one trunk you need to do a dual silo [08:50] robru: I just changed the packaging bits, but if I understand you right we have to merge my MP now first before going ahead, right? [08:50] robru, my idea is that CI train might be able to handle that [08:50] abeato: is there a reason that you can't use a dual silo? [08:50] robru, well after the gcc5 switch we have many projects branched [08:50] so I was experimenting a bit [08:50] morphis: I think there's a possibility that train doesn't support native packages anymore, meaning that you need "0.230-0ubuntu1" version number instead [08:51] let me try that [08:51] native packages did work at one point but it was more of a bug probably [08:51] and now that lxc-android-config has an upstream project, it's not native anymore to Ubuntu :) [08:51] "kind of" [08:53] abeato: there is a way to do it from one trunk and keep using dual silo, but it takes a bunch of packaging voodoo. Talk to michi about it he has a proof of concept that works [08:53] I should get some documentation together for that... === Mirv changed the topic of #ubuntu-ci-eng to: Train trouble? ping trainguards | CI problems? ping cihelp | Train: http://bit.ly/1hGZsfS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: OTA-6 final freeze in effect, but the vivid-overlay landing gates opened. sil2100 away, small trainguard gap between EEST & RDT (robru daylight saving time) timezones [08:54] robru, I had actually noticed that there is a silo from him that generates the dependencies dynamically apparently [08:54] robru, it would be great if michi or somebody shares that in the mailing list :) [08:54] Mirv: lol [08:56] abeato: it's 2 AM for me, I'm afk can't get the details. But michi has a good example if you just read what he did. You can make an override_dh_auto_build that generates the correct debian/control with correct values per distro [08:57] robru, thanks, and take some rest [08:57] abeato: i mean override_dh_auto_clean, grep his source for that and you can see how it works [08:58] great [08:58] abeato: can't sleep, clowns'll eat me [08:58] :D [08:59] Mirv, robru: just adding -0ubuntu1 doesn't seem to be enough [08:59] still asking for the tarball [09:01] ah I see [09:01] used - instead of + [09:01] morphis: that is really strange, the whole point of split mode is that it makes thr tarball by dropping the debian dir. Double check you have it set right? I don't see anything obviously wrong... [09:01] morphis: - should be good, I'm testing something on my own [09:01] I don't see anything wrong anymore either [09:02] if I used + with a local bzr bd run it doesn't ask anymore for the tarball [09:02] and the info "This package has a Debian revision number but there does not seem to be..." goes away [09:02] Hm [09:03] citrain correctly notes: "dch warning: Previous package version was Debian native whilst new version is not" [09:05] I wonder what I managed to do when I get build success without it trying to merge the MP in the first place :D https://ci-train.ubuntu.com/job/ubuntu-landing-002-1-build/213/console [09:06] I was just experimenting based on morphis' branch https://code.launchpad.net/~timo-jyrinki/lxc-android-config/randomtest/+merge/269866 [09:07] morphis: I don't know what's going on in my test silo, but I was trying to add a fake non-native entry plus use a date code (which includes + in upstream version and the - for being a non-native package) [09:07] Mirv: silo 2 is a manual source...? Force rebuild means it watches the ppa twice as hard i guess. [09:08] morphis: ah, now I notice. delete the debian/bzr-builddeb.conf [09:08] robru: it is not, that's the fun of it. https://requests.ci-train.ubuntu.com/#/ticket/298 [09:08] morphis: and don't change the rest of it, that'll probably fix it [09:08] morphis: uh "+0ubuntu1" is not a thing that makes sense, if that works it's only by accident. You should try to ape a real version with the date stamp and the train will run with it [09:09] morphis: just keep the 0.230-0ubuntu1 and bzr rm debian/bzr-builddeb.conf [09:09] Mirv: the console log you linked was silo 2 not 24. [09:10] Mirv, robru: done, let me try this now [09:10] robru: wow, quite a coincidence that I actually run a build job for a wrong silo that has the same package :D [09:13] robru, hey, a small bug report for bileto: when there's a merge conflict in a branch, it prints that with a link to the branch, but the link includes a dot at the end which breaks it [09:14] morphis: well that looks good, both uploads accepted [09:14] yeah! [09:14] robru, here's an example: https://requests.ci-train.ubuntu.com/#/ticket/285 [09:14] mzanetti: oh haha. Can you email me with a link to the log that has that? I'll fix it during my shift tomorrow [09:15] robru, ack === greyback__ is now known as greyback [09:45] robru, so, this mr https://code.launchpad.net/~mandel/ubuntu-download-manager/wily-add-appid-metadata/+merge/269364 is building on vivid, yet is aiming for wily.. at lets so it says here => https://jenkins.qa.ubuntu.com/job/ubuntu-download-manager-vivid-armhf-ci/28/console [09:46] robru, any idea? [09:47] mandel: yeah that's not the train you looked to there, nothing to do with me [09:47] mandel: it's 2.45am for hi.. okay, he's there [09:48] robru, sorry sorry! [09:48] Mirv, do you know anything about that? The ci bot using the wrong release.. :-/ [09:48] Mirv: for some reason at 11 pm i put on a 4 hour YouTube video thinking that was a good idea [09:48] mandel: try highlighting cihelp for that ^ [09:48] robru: sounds wise [09:51] mandel: i'll take a look at this. i'd need some time. digging some other issues at the moment. but i'll make a record of your issue and come back to you [09:52] psivaa, ok, is not a show stopper, I'll add a comment in the MR [09:52] psivaa, moving to gcc 5 has this problems === alan_g is now known as alan_g|llunch === chihchun is now known as chihchun_afk [10:02] Mirv,bzoltan_: for future reference, the place to ask for PPA changes is https://answers.launchpad.net/launchpad, preferably not RT or webops [10:03] webops can do it of course but we prefer to distribute load away from them where possible [10:11] trainguards so in silo 54, i was doing a src sync from wily to vivid+o, mir and u-s-c built fine, but qtmir just seems to wait and time out [10:11] is something with a twin not capable of being sync'd at all ? [10:12] kgunn: I'm not aware of any limitations on the non-gles one being synced. Should be the same... [10:13] robru: dude...you're up too :) [10:13] kgunn: i need help [10:14] robru: so you were helping me last night....and qtmir is the only pkg refusing to build [10:14] as i watched the output file, it just spins saying "qtmir...waiting" [10:14] or no "watching" [10:15] cjwatson: OK [10:17] kgunn: the fact that it's trying to upload "0ubuntu2" is quite suspect, can you confirm you didn't already sync this version? 0ubuntu1 is either already in the PPA or the archive [10:18] robru: ah...i just found out....someone did something naughty [10:18] vivid+o is ahead of wily [10:18] Ooh good [10:18] so i just need to land qtmir latest in wily and rebuild....i think [10:18] crap [10:18] this is gonna be a mess [10:18] cause then i think unity-api is involved somehow [10:19] kgunn: not sure, sorry. [10:20] robru: ok, my teams mess thos [10:20] sorry to bother [10:20] kgunn: no worries [10:22] kgunn: the train now supports a way to have dual landings even for packages affected by gcc5 abi but it's a little experimental, you should coordinate with michi, he has a working proof of concept. [10:22] robru: thanks [10:22] kgunn: it's a little bit voodoo but a nice dual landing would clean up your mess ;-) [10:23] it seems it doesn't hurt I'm having this very late lunch since you two are a fit for each other regarding working hours :) [10:24] Mirv: send help... I need sleep therapy [10:24] yeah you both do [10:25] this google result seems to be on the topic, but I'm not sure if it's sane https://www.reddit.com/comments/meaq9/the_real_quick_fix_to_get_your_fucked_up_sleep/ [10:25] Mirv, how can I abandon a silo? I don't see the option anymore [10:26] abeato: if you have a silo assigned, ask a trainguard to free that up, it also makes the request abandoned [10:26] abeato: Mirv ONLY_FREE_SILO. [10:27] Mirv: landers can free their own [10:27] robru: oh! [10:27] Mirv, ok please free silo 16 then [10:28] abeato: so, click the Merge & Clean and select ONLY_FREE_SILO [10:28] abeato: new instructions, do not ping but free it up yourself :) [10:28] ah, ok [10:28] hehe [10:28] nice [10:28] Mirv: i thought you knew, this isn't something that changed recently, landers could always free their own [10:28] the train is really good nowadays, all the features coming together [10:29] robru: I simply didn't know.. [10:30] Mirv: maybe skim the landingprocess page, i overhauled it last week [10:30] * Mirv opens https://wiki.ubuntu.com/citrain/LandingProcess [10:32] Mirv: there was a hilarious part that used to say "ci airline will be ready ~july 2014" so that was in need of updating ;-) [10:33] robru: any day now! [10:37] Mirv: OK I'm fading... Goodnight! [10:40] robru: goodnight! === chihchun_afk is now known as chihchun === alan_g|llunch is now known as alan_g [11:55] cjwatson: how those requests are picked up? [11:56] bzoltan_: mailed to answer contacts for Launchpad, which includes Launchpad staff [11:58] cjwatson: OK, so eventually somebody will pick up. I managed to fill up the PPA :( I somehow feel that PPAs are not designed to host such content... [11:59] bzoltan_: how do you mean eventually? you have no pending requests [11:59] oh, six minutes ago [11:59] cjwatson: just got two uploads rejected [12:00] bzoltan_: would you mind adding me temporarily to ~ubuntu-sdk-team? then I can make this change (and leave the team immediately afterwards) without having to wait for William to be around [12:01] I should get round to getting commercial admin privileges for myself :) [12:02] cjwatson: welcome to the team :) i will show you later our backlogs... [12:03] bzoltan_: ok, sorted (and left :-) ) [12:03] cjwatson: so quickly? I was already looking for a suitable task :D [12:04] cjwatson: Thank you [12:04] I suspect the LP bug queue is longer than yours, just because it's been around for longer :-) [12:07] cjwatson: Yeps... I admit, we have a decent bug queue... but you know, I think like with kids It is already big enough for being left out without our control. [13:05] ubuntu-qa: all webbrowser-app generic-deb-autopilot-runner-vivid-mako CI jobs are failing, they apparently fail to flash the device, is that a known issue?' [13:06] (see e.g. https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/3242/console) [13:17] oSoMoN, maybe plars knows ^^ === chihchun is now known as chihchun_afk [13:42] trainguard so, I have a very very interesting question, anyone wants to hear my idea? [13:43] Mirv, thanks, for landing silo 24. About the bug #1491255, how do you suggest us to maintain that since the symbols could be different in wily and vivid [13:43] bug 1491255 in indicator-transfer (Ubuntu) "Add .symbols file for tracking API" [High,New] https://launchpad.net/bugs/1491255 [13:43] Mirv, until now we are using the same branch (trunk) for both [13:43] Mirv, creating new branches just because of the symbols files does not look good [13:46] Mirv, mandel is having this problem right now with download-manager API, [13:47] renatu, Mirv so, as I mentioned, my idea is to have packging branches per distro and just keep the symbol issues there [13:48] renatu, Mirv and keep the same source in trunk. Then when we create a silo we provide the mr for trun and the mr for the pacaking [13:54] renatu: mandel: right, and it was mentioned michi has a solution for differing symbols too (maybe similar) [13:55] Mirv, would be nice to have a hang out, brain storm and get this fix asap [13:55] Mirv, I hate to have to do crazy backport branches just for the symbols, and yes, is no ones fault except for cpp [13:56] mandel, Mirv: have a look at the gen-debian-files script and the rules file in the debian directory in silo 10. [13:56] That’s pretty much all you need. [13:56] It’s just the usual substition grind with sed and what not. [14:02] mandel: michi: I haven't done this myself yet, but thanks to michi I've added now https://wiki.ubuntu.com/citrain/LandingProcess#Dual-landing_and_handling_symbols [14:02] renatu: ^ [14:02] Mirv: reading... [14:03] I think some more documentation on the usage might be handy :) [14:03] Mirv: The trick with the symbols file is to have only one of them. [14:03] Either wily or vivid, it doesn’t matter. [14:03] But don’t try to do a symbols file for both, you’ll go mad that way. [14:04] Basically, if a symbols file on vivid passes, and the same code is compiled for both vivid and wily, there is no point in having a symbols file for wily too. [14:04] That’s because, if a vivid symbols file is good, the only differences in the wily symbols file will be due to compiler differences. [14:04] Different symbol mangling with the new ABI, and differences in inlining. [14:04] So, adding a symbols file for wily too won’t show anything that a vivid build won’t show. [14:05] Longer term, the goal is to get rid of symbols files completely because they are the wrong tool for the job. [14:05] The catch some ABI breaks, but only some. [14:06] Even in C, there are many ways to break ABI that won’t show up in the symbols file. [14:06] In C++, there are many more [14:06] michi, well, I was told that QA wants them for OTA7 [14:06] abi-compliance-checker is the way to go for C++ and, if we are honest about it, for C as well. [14:06] QA needs to learn that symbols files don’t do what they are meant to do. [14:06] It’s an education campaign. [14:07] If a symbols file doesn’t pass, that means the ABI is broken. [14:07] michi, if we ditch them, we should tell QA, get a company rule and deal with it without symbol files [14:07] That, by not means, implies that, if a symbols file passes, that the ABI is not broken. [14:07] abi-compliance-checker. [14:07] Catches everything a symbols file with catch, plus dozens more cases that a symbols file won’t catch. [14:08] It’s a far better way to establish whether the ABI is still intact. [14:08] michi, I;m also a little worried about upstream projects, in ours we can drop them and then add abi-compliece-checker [14:08] The problem with acc is that it’s cumbersome to use and difficult to integrate into our CI story [14:08] michi, for me, as long as we do not have to mantain two files etc.. I'm ok [14:08] I’m working on making it more bearable. [14:08] For now, if you have a symbols file for either wily or vivid, that’s cool. [14:09] Just don’t try and add a second one. [14:09] It won’t show you anything new. [14:09] Maintaining the bloody symbols file has been the bane of our lives for the past two years. [14:10] There are an unbelievably stupid number of ways in which that can break, with no ABI in danger whatsoever. [14:10] That’s for C++. [14:10] For C, it’s not as bad. [14:11] Check out silo 10, it’l give you the general gist of things. [14:11] debian/rules and all the .install files are generated on the fly. [14:11] michi, so, abi-change-checker, I'm never heard about it, is it new, did we build that? [14:11] michi, I'd like to know how it works [14:11] For scopes-api, it’s more complex than it will be for most projects because we changed the way we name our soversion recently. [14:11] abi-compliance-checker [14:12] It’s in the archives. [14:12] michi, what I understood is that the symbol files will be mandatory now [14:12] perl script that reads the symbol table and the headers and does a fairly deep inspection of the ABI *at the source code level*. [14:12] renatu: the symbols files are useless (mostly) to establish that the ABI is still intact. [14:12] They don’t do what they are meant to do. [14:13] Sticking to a policy such as this is not productive. [14:13] Symbols files catch *some* ABI issues, but nowhere near enough of them to matter. [14:13] but the QA team are asking us to create it on the projects to accept our MR [14:13] They are simply the wrong mechanism to establish ABI compliance. [14:13] michi: renatu: mandel: I have to stop for today but I updated https://wiki.ubuntu.com/citrain/LandingProcess#Dual-landing_and_handling_symbols by parsing the contents of silo 10 + reading michi's initial explanation above [14:14] Mirv, good starting point [14:14] the QA team needs to learn that they are asking for something that causes a lot of maintenance overhead for very little return on investment. [14:14] michi, I do not have problems with my .install files the problem will start with symbol files [14:14] Mirv: [14:14] Just skimming. [14:14] hold back on the publishing of this please. [14:15] the Vivid special-casing is rather unique to our project and won’t apply to most other projects. [14:15] I’m about to hack this up a little bit more to get rid of the vivid special case altogether. [14:16] Anyway, the basic idea is simple: have the hook in debian/rules that calls a shell script (or python, whatever). [14:16] michi: it's a wiki :) added a note at the top that it's a bit WIP [14:16] Then make that script adjust all the soversion stuff, rename files, substitute the first line into the symbols file, generate a shlibs file, and so on. [14:17] the idea is that, if you compile the exact same source for both vivid and wily, the only differences that matter are in the debian files. [14:17] So, generate the debian files instead of coddling two different series along. [14:18] In the end, for identical source, there should be only two things that differ in the final packages: the soname, and the package name. [14:19] Use a symbols file for vivid, and a shlibs file for wily (until we get abi-compliance-checker working nicely) [14:19] That way, we are no worse off than we are now, but we don’t have to maintain two series and two symbols files. [14:28] ogra_: can you review https://ci-train.ubuntu.com/job/ubuntu-landing-046-2-publish/lastSuccessfulBuild/artifact/ubuntu-app-launch_content.diff it adds liblibertine-dev dependency and changes to depend on upstart instead of transitional upstart-bin. changelog entry funniness is because of different order wily/vivid landings but seem correct otherwise. [14:29] tedg: you will need to MIR request libertine when you eventually land the new ubuntu-app-launch to wily, even though 046 is vivid overlay only [14:29] depending on the point of view it might be wanted to be done already before 046 can be published to overlay [14:30] bregma: ^ [14:33] bregma: tedg: so regarding wily 1. get archive admin to approve it from https://launchpad.net/ubuntu/wily/+queue?queue_state=0&queue_text= 2. file a https://wiki.ubuntu.com/MainInclusionProcess at https://bugs.launchpad.net/ubuntu/+source/libertine 3. when approved, arrange for ubuntu-app-launch release and alert also trainguard so that when publishing it archive admin:s need to be once more contacted [14:33] to do the actual (approved) promotion to main of libertine once ubuntu-app-launch starts needing it [14:33] trainguards long story short, due to proj deps branching (or not) and debian dep numbers....i think i want to do one of 2 things [14:34] 1) can i have 1 silo with MPs and 1 silo with src sync rebuild, and guarantee those go together ? [14:35] or 2) have 1 silo with mp's, then create another silo for the src sync...copy over the binaries from that 2nd silo into the first to make it a guarantee ? [14:37] Mirv, looks fine ... if it breaks tedg will get no beer at the next sprint ... so ACK ... [14:39] ogra_: serious enough threat, ok! [14:40] kgunn: not understanding the why still, but I'd use 2) ie use a temporary throwaway silo from where you copy when everything is ready to the first silo. it's also easier for QA to test when there's only one final silo. [14:42] I need to go now like I probably said a long time ago :) so please wait for robert to wake up for trainguardings [14:46] Wait, wait. Perhaps bregma should be in charge here, I'm not willing to take those risks! [14:46] Thanks ogra_ ! [15:26] cihelp: does anyone know why this is failing ? looks like infrastructure problems: https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-vivid-mako/3244/console [15:38] psivaa: Hi! Did you get a chance to look at the https://jenkins.qa.ubuntu.com/job/mir-android-vivid-i386-build/ failures? Seems like an archive problem? [15:39] alf_: not yet, that's still in the list. sorry being consumed by something else [15:55] nerochiaro, it looks like a couple of mako devices have failed. Not sure the cause yet. [15:58] nerochiaro, I've triggered a rebuild on that branch [15:59] cihelp: all the qmluitests jobs are stuck http://s-jenkins.ubuntu-ci:8080/job/unity-phablet-qmluitests-vivid/ [16:00] fginther: ok. if it happens on other branches should I alert you ? [16:07] nerochiaro, the failed devices have been taken offline, so new runs should be ok for now. But if this caused other runs to fail, we can restart those too [16:07] nerochiaro, but at the moment, there is a shortage of working devices [16:07] psivaa, what tsdgeos tried to say above is that all the slaves are offline and can't be started by jenkins: http://s-jenkins.ubuntu-ci:8080/label/vivid&&amd64/? [16:12] psivaa, the restart of the libvirt service may have broken the connection to s-jenkins. We may have to restart s-jenkins to correct it [16:13] fginther: hmm yea, that could probably be the reason.. [16:26] s-jenkins.ubuntu-ci needs a restart, sorry for the short notice === fginther changed the topic of #ubuntu-ci-eng to: Train trouble? ping trainguards | CI problems? ping cihelp | Train: http://bit.ly/1hGZsfS | QA Signoffs: http://bit.ly/1qMAKYd | Known Issues: OTA-6 final freeze in effect, but the vivid-overlay landing gates opened. sil2100 away, small trainguard gap between EEST & RDT (robru daylight saving time) timezones, s-jenkins.ubuntu-ci needs a restart [17:20] kgunn: alright, what's the plan? you want two silos? [17:58] crap [18:11] * popey creates https://requests.ci-train.ubuntu.com/#/ticket/306 and wonders what happens next.. some bot? [18:15] yes, some bot. [18:24] robru: yep, so question is....do you have magical powers to copy over the pkgs from the silo 24 ppa into the silo 54 ppa ? and do i need to add something else to the silo 54 entry in the train ? [18:25] e.g. mir listed in some text block entry to tell the silo 54 configuration that will be there [18:26] kgunn: I do have magical powers. [18:26] kgunn: one sec [18:27] mzanetti, tsdgeos, the unity-phablet-qmluitests-vivid have been restored [18:27] fginther, thanks :) [18:29] kgunn: ok I did the copy. you should now add 'mir' to the sources field of silo 54, do the 'assign' and then do a build with WATCH_ONLY [18:35] popey: presumably qa will pick that up [18:40] robru: i must be missing something ^ [18:42] kgunn: yep, you ran a build that deleted all your files but then failed to build anything: https://ci-train.ubuntu.com/job/ubuntu-landing-054-1-build/16/consoleFull so you'll need to rebuild the whole silo now. [18:43] robru: but i marked it as watch? [18:43] kgunn: but there's nothing to watch, because everything in your silo was previously deleted. you have nothing. you need to rebuild. [18:44] kgunn: look at the log I pasted, it literally says "deleting everything" and then when it tries to build it fails and stops. [18:47] robru: maybe i misunderstood...i thot silo54 would already be empty, except for mir that you just copied in from silo 24, meaning it [18:47] would "watch" and see mir, but then build the mp's [18:48]