=== mhall119_ is now known as mhall119
=== chihchun_afk is now known as chihchun
=== chihchun is now known as chihchun_afk
[07:17] <bzoltan_> jibel: brendand is not online, but I think somebody from the Mir team should know about this http://pastebin.ubuntu.com/13245871/
[07:18] <bzoltan_> Mirv:  do you know anybody early bird from the MIr team?
[07:23] <Mirv> bzoltan_: RAOF is a late bird
=== chihchun_afk is now known as chihchun
[07:29] <bzoltan_> Mirv:  I wonder if it is related to the testtools problem brendad was talking about
[08:36] <jibel> robru, hey, I tried to trigger an autopkgtest run with https://ci-train.ubuntu.com/job/ubuntu-landing-057-2.5-autopkgtests/build but it does nothing
[08:36] <jibel> robru, any clue?
[08:37] <jibel> it returns immediately, no job in the queue
[09:05] <robru> jibel: doesn't look like you triggered the job... Did you click "build" on that page?
[09:06] <jibel> robru, I did :)
[09:06] <jibel> robru, several times
[09:06] <jibel> robru, I did it again and it worked
[09:06] <jibel> weird
[09:07] <robru> jibel: it's the same as all the rest of the Jenkins jobs, you have to click once to log in then click again to actually trigger it
[09:08] <jibel> robru, yeah I know jenkins a little bit, but pressing the button did nothing
[09:08] <jibel> anyway now it's running
[09:09] <robru> jibel: yeah "did nothing" means "redirected through sso then redirected back to the same form you were looking at before".
[09:09] <robru> jibel: looks like it exploded pretty bad
[09:10] <jibel> robru, nothing nothing, and I pressed several times. but it okay now it's running
[09:11] <jibel> robru, heh, I picked the wrong package apparently :)
[09:11] <robru> jibel: you may have better results if you run it on a silo that exists :-P
[09:11] <jibel> robru, man, it existed half an hour ago
[09:12] <jibel> does it mean it is not the day to test autopkgtest on silos and I should do something else?
[09:16] <robru> jibel: you can test it, it just has to be a request that isn't already landed
[09:17] <jibel> robru, so after requesting an autopkgtest I wait 15 min for the result?
[09:18] <robru> jibel: I'm not sure how long it takes but the train will poll for results every 15 minutes
[09:18] <jibel> robru, ack
[09:20] <robru> jibel: i expect the current code will be plagued with false negatives (failures that aren't real failures) because it doesn't distinguish between regressions and "always failed" the way proposed migration currently does. We're working out how to get that up to par for the next iteration
[09:20] <jibel> sil2100, apparently silos 3, 57 and 0 landed but I don't see any message in vivid overlay's changelist, is change bot dead?
[09:21] <sil2100> jibel: hm, let me check what happened
[09:21] <jibel> robru, yeah we need that, triggering a test must be automated not manual and we also need to test rdeps
[09:21] <sil2100> jibel: by silo 0 you mean the libphonenumber thing?
[09:22] <jibel> but it is a start
[09:22] <jibel> sil2100, yes
[09:22] <jibel> no
[09:22] <sil2100> jibel: I see a message about it from 2 days ago
[09:22] <jibel> sil2100, I mean dialler-app
[09:22] <jibel> sil2100, https://requests.ci-train.ubuntu.com/#/ticket/648
[09:22] <jibel> sil2100, https://requests.ci-train.ubuntu.com/#/ticket/647
[09:23] <robru> jibel: we decided not to do automatic tests in case it would overburden the test infra, but i think ultimately the plan is to have landers submit autopkgtests prior to submitting for qa so it at least doesn't waste your time.
[09:23] <jibel> sil2100, and https://requests.ci-train.ubuntu.com/#/ticket/644
[09:23] <sil2100> Ok, need to check
[09:23] <sil2100> Aww come ooon, looks like my instance died
[09:24] <jibel> robru, if it triggers a test when it's marked ready for qa it won't overburden the infra
[09:25] <jibel> robru, on average it's less than 20 silos a week with peaks at 30
[09:25] <jibel> that won't kill the infra
[09:25] <jibel> even if you run them 3 times per silo
[09:25] <robru> jibel: i was envisioning the other way, landers must get passing autopkgtest before at cab be marked ready for qa. Like bileto would only mark it ready after successful testing
[09:26] <robru> jibel: the concern was from pitti, if we auto test after every build it's too much, the test infra is quite weak and overburdened already
[09:27] <jibel> robru, I agree with pitti and it's why I think running once when the lander thinks it's ready for QA is a good compromise
[09:27] <jibel> it's what we'll do manually anyway
[09:27] <jibel> so if we can save this button pressing task it's all good
[09:28] <robru> jibel: yeah it's in the plans, lots of rough edges need to be polished up still
[09:29] <robru> jibel: for now though the feature is there, you can poke at the autopkgtest and see what happens. Hopefully we'll get it smoother soon and landers can start doing it
[09:30] <jibel> robru, although what we really need is reverse dependencies testing. not all packages have autopkgtest but frequently rdeps do have tests and proposed-migration finds lot of regressions this way
[09:33] <robru> jibel: yeah the next step is to enable full britney, it will do rdeps and everything just like proposed migration. But that's a big task to enable in the train, will be some time for that to go live.
=== michihenning is now known as michi
[09:50] <robru> jibel: oh for silo 51 it looks like it didn't have any tests, the log shows it skipped submitting anything
[09:51] <jibel> robru, right, I just picked a random silo to see if the build was working
[09:56] <robru> jibel: yeah it seems i need to rework this quite a bit, the silo status makes it sound like it's doing something. I'm working on a major overhaul of the silo status reporting that should clarify what is actually going on, but could be a few days before i finish
[10:05] <xavigarcia> sil2100: ping
[10:05] <sil2100> xavigarcia: pong
[10:06] <xavigarcia> sil2100: hi! I have a question... I would need to move libuntiy-api-dev to main repository, as it is a dependency for a new project we are planning to land and that will be a dependency of the sound indicator
[10:06] <xavigarcia> sil2100: can you help me with that?
[10:07] <sil2100> xavigarcia: it's already handled :)
[10:07] <sil2100> xavigarcia: I did that last week actually
[10:07] <xavigarcia> sil2100: ah, ok...cool!
[10:07] <sil2100> https://bugs.launchpad.net/ubuntu/+source/unity-api/+bug/1512784
[10:07] <ubot5> Ubuntu bug 1512784 in unity-api (Ubuntu) "[MIR] unity-api" [Undecided,Fix released]
[10:07] <xavigarcia> sil2100: great!, then I guess silo 51 should be good to go
[10:08] <xavigarcia> sil2100: and now a second question. I need to add the project gmenuharness to the repository
[10:08] <xavigarcia> sil2100: it's a new project, and contains the base to implement integration tests for all indicators
[10:09] <xavigarcia> sil2100: this is the url: https://launchpad.net/gmenuharness
[10:10] <xavigarcia> sil2100: we'd need to land this asap to avoid having the issues we've got for ota-8 and the indicator-sound silo
[10:10] <sil2100> xavigarcia: ok, in that case you'll need to prepare the packaging and go through the normal landing procedures, after which the package will need to be preNEWed and then NEWed by someone from the archive team
[10:11] <sil2100> xavigarcia: a preNEW procedure is getting some archive admin review your silo after it passes QA
[10:11] <sil2100> To check the packaging etc.
[10:11] <jibel> sil2100, I forgot to ask during the meeting, can you 'enable' the OTA version in the RC channel so we can test before the image is promoted to stable?
[10:11] <xavigarcia> sil2100: ok... the packaging should be ready, so I will create a silo for it
[10:11] <xavigarcia> sil2100: thanks!
[10:11] <sil2100> Normally we wouldn't need a preNEW procedure, but since overlay landings go directly to the overlay PPA I would prefer someone to check it early
[10:12] <xavigarcia> sil2100: sure
[10:12] <sil2100> jibel: ok, yeah, that's my priority today, will give you a sign once it's done
[10:13] <jibel> sil2100, thanks
[11:07] <jibel> sil2100, can you check if you can restart your instance, it should be fixed
[11:07] <sil2100> jibel: yeah, the e-mails got sent, the instance restarted
[11:18] <brendand> sil2100, hey dude
[11:20] <sil2100> brendand: hey
[11:21] <brendand> sil2100, do you know what happens to old version of e.g. messaging-app when a new one lands in the overlay ppa?
[11:21] <brendand> sil2100, is it just 'disappeared'
[11:21] <sil2100> brendand: no, it's still there, you can download it if needed but it's not super trivial - it's superseeded by the new version but still there
[11:22] <sil2100> I have a script that downloads selected versions from the overlay
[11:23] <brendand> sil2100, but in terms of being available for install using apt etc?
[11:23] <sil2100> brendand: bzr branch lp:landing-team-tools and use the overlay-ppa-dl-package script - you can download either .deb binaries (by default), or grab the source by giving the -s options
[11:23] <sil2100> apt also should be able to install it if you explicitly give it a version number
[11:24] <sil2100> hm, or let me think
[11:24] <sil2100> Actually hm, no, apt won't see it I think
[11:25] <sil2100> brendand: I suppose the only option is to download the .deb's directly and installing with dpkg I think
[11:25] <sil2100> brendand: but I would have to check if apt won't find the package if you give the version number directly
[11:29] <sil2100> brendand: ok, so as I thought, it seems that apt just wont see it
[11:32] <brendand> sil2100, ok
[11:35] <brendand> sil2100, makes it a bit more difficult but at least its possible
=== _salem is now known as salem_
[13:08] <xavigarcia> sil2100: ping again :)
[13:08] <xavigarcia> sil2100: could you please take a quick look to this build? https://ci-train.ubuntu.com/job/ubuntu-landing-000-1-build/540/console
[13:09] <xavigarcia> sil2100: I think something is wrong in the project configuration
[13:09] <xavigarcia> sil2100: for example: https://launchpad.net/ubuntu/+source/libgmenuharness does not exist
[13:11] <sil2100> xavigarcia: is the branch configured as bzr split?
[13:12] <sil2100> xavigarcia: yeah, so I don't see the .bzr-builddeb directory
[13:12] <sil2100> xavigarcia: check how other projects are done and be sure to include the same things in .bzr-builddeb of your bzr branch, since otherwise it won't generate the tarball from the source tree
[13:13] <xavigarcia> sil2100: oh, ok... will do that
[13:13] <xavigarcia> sil2100: thanks!
=== salem_ is now known as _salem
=== _salem is now known as salem_
=== balloons is now known as Guest56507
=== Guest56507 is now known as balloons_
=== balloons_ is now known as balloons
=== ev 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-8 preparation in progress
[14:44] <sil2100> rvr: ping
[15:05] <rvr> sil2100: pong
[15:06] <sil2100> rvr: hey! Is your krillin free right now?
[15:06] <rvr> sil2100: Yes
[15:32] <AlbertA> trainguards: so this says landed, but I only see the packages released into stable-phone-overlay
[15:32] <AlbertA> https://requests.ci-train.ubuntu.com/#/ticket/604
[15:32] <AlbertA> and not in xenial or xenial proposed
[15:32] <AlbertA> did I not configure the entry properly for dual landing?
[15:41] <greyback> trainguards: hey, this is to fix a ftbfs on armhf xenial: https://requests.ci-train.ubuntu.com/#/ticket/646 can someone hit merge please?
[15:52] <Mirv> greyback: publish? it's not set to "Publish without QA"?
[15:53] <greyback> Mirv: ah boo, I chose the wrong option
[15:54] <greyback> Mirv: okay, now I can press buttons
[16:10] <AlbertA> Mirv: any idea why this didn't make it to xenial ? https://requests.ci-train.ubuntu.com/#/ticket/604
[16:27] <Mirv> AlbertA: the silo was configured to use overlay PPA (dual landings should have the field empty - vivid will go to overlay anyway), so the mir is in... overlay PPA also for xenial dput ppa:ci-train-ppa-service/landing-012 ../build-area/qtpim-opensource-src_5.0~git20140515~29475884-0ubuntu16~xenial1~test1_source.changes
[16:27] <Mirv> AlbertA: s/wrongcopypaste/https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/stable-phone-overlay/+packages?field.name_filter=&field.status_filter=published&field.series_filter=xenial
[16:27] <Mirv> also some unity-scopes-shell it seems :P
[16:30] <Mirv> as I'm MOTU I was able to copy the unity-scopes-shell to archives, but the mir is in main so needs core-dev
[16:31] <greyback> Mirv: hey, I've a qtmir bug fix I want to land fairly soon (https://requests.ci-train.ubuntu.com/#/ticket/654) - think I should wait for https://requests.ci-train.ubuntu.com/#/ticket/646 to migrate? Will a dual landing work after a xenial-only landing?
=== jhodapp is now known as jhodapp|intervie
[16:39] <Mirv> greyback: OTA8 blocker is good enough reason, so I'll merge&clean 646. it has at least built so it will probably migrate. dual landing should work fine since the trunk is always xenial/dev anyway. and if not we'll just do some manual publishing once.
[16:39] <Mirv> noting to myself I shouldn't be here, but it seems no other trainguards are here either right at the moment
[16:41] <greyback> Mirv: nice , thank you for the help
[16:42] <Mirv> greyback: ok go ahead in building 654
[16:42] <greyback> Mirv: just kicked off
=== greyback is now known as greyback|eow
[16:43] <AlbertA> Mirv: thanks, so should I just make a sync from overlay entry to get it into xenial?
[16:45] <Mirv> AlbertA: either that or just get some core dev like RAOF to copy-package it to xenial-proposed
[16:47] <AlbertA> Mirv: cool thanks
[17:23] <robru> AlbertA: that is strange
[17:25] <robru> Oh I see, hmm I should make the train just ignore that field for dual silos
[17:29] <AlbertA> robru: yeah sorry, I didn't catch that you are not to supposed to use that field anymore...
[17:33] <robru> AlbertA: I recommend just getting a core dev to copy manually. If you make a sync request you still need a core dev anyway so it's a bit pointless for you
[17:33] <AlbertA> robru: yeah I'll ask RAOF on his monday
=== jhodapp|intervie is now known as jhodapp
=== salem_ is now known as _salem