[07:16] <pstolowski> hey trainguards, can somebody help me understand the cause of silo 35 failure; i've debhelper in my dependencies? i'm generating debian/control from debian/rules on the fly, following the solution we recently succesfuly established in another project. i know that robru made some changes to CI train to make it possible, but I'd hope it was a generic change, not just for per-project?
[07:42] <Mirv> sil2100: pstolowski is asking some really hard questions :D
[07:42] <Mirv> sil2100: http://pastebin.ubuntu.com/12446862/ - any idea?
[07:43] <pstolowski> Mirv, sil2100 looks like we've just found the problem, there was an empty line in debian/control
[07:43] <Mirv> pstolowski: oh, great!
[07:43] <Mirv> sil2100: unping!
[07:43] <Mirv> pstolowski: let us know if it still fails
[07:47] <Mirv> pstolowski: looking good!
[07:49] <Mirv> that gen-debian-files.sh really feels like "things could be better", but I'm glad that there's at least _a_ solution
[07:51] <sil2100> pstolowski: did the empty line removal help?
[07:51] <sil2100> I tried that locally yesterday and it didn't
[07:59] <Mirv> ah, no landing meeting
[08:02] <pstolowski> sil2100, the build is in progress, built successfuly for some archs already
[08:13] <pstolowski> sil2100, yeah, it should work fine; built for wily, failed for vivid because we need uhm, silo 10 landed first
[08:14] <sil2100> pstolowski: seb128 is on it! But I really thought that maybe Steve would have time this time
[08:14] <sil2100> Or maybe he even did review but didn't press teh buttonz
[08:16] <pstolowski> sil2100, okay
[08:21] <seb128> sil2100, pstolowski, that libunity-scopes3 already existed
[08:21] <seb128> it's sort of bad test to reuser a lib name/soname that existed for a different version/api
[08:23] <pstolowski> seb128, in vivid we need to release the same exact so we had, so that existing scopes don't break. there are no api changes in this branch, just packaging. not sure if that answers your question..?
[08:23] <seb128> well, I was more pointing a detail
[08:23] <seb128> pstolowski, is that silo 24 we are talking about?
[08:24] <seb128> I just got pointed to https://ci-train.ubuntu.com/job/ubuntu-landing-010-2-publish/80/artifact/unity-scopes-api_packaging_changes.diff
[08:24] <pstolowski> seb128, i'm talking about silo 10
[08:24] <sil2100> hmmm
[08:24] <seb128> I'm talking about 24
[08:24] <seb128> which one needs a binNEW review?
[08:25] <pstolowski> seb128, 24 is not ready to be reviewed, it will be simpilified and rebuilt one 10 lands.
[08:25] <sil2100> ogra_: hey! I actually checked the cdimage code just now and it looks like there's actually no ubuntu-rtm-related code there (for the subproject) but many many lines for ubuntu-touch (the project) - from the code I glimpsed it seems subprojects just work out-of-the-box, without much configuration
[08:25] <pstolowski> seb128, i was asking sil2100 to land silo 10
[08:25] <sil2100> ogra_: they're just using everything from the main project + append the subproject name
[08:25] <seb128> ok
[08:26] <sil2100> seb128: yeah, silo 10 needs landing as it introduces those new bin packages (at least in theory)
[08:26] <ogra_> sil2100, ah, cool
[08:27] <sil2100> ogra_: I'll look into it more, but that's what I saw after the first greps and looks
[08:27] <ogra_> yeah, as i said, i wasnt sure
[08:28] <seb128> sil2100, pstolowski, it's buggy
[08:28] <seb128> -Package: libunity-scopes-qt0.1
[08:28] <seb128> +Package: libunity-scopes-qt2
[08:28] <seb128> but on https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-010/+build/7907984
[08:28] <seb128> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-010/+build/7907984/+files/libunity-scopes-qt0.2_1.0.1%2B15.10.20150915.1-0ubuntu1_amd64.deb
[08:28] <seb128> 2 vs 0.2
[08:29] <seb128> the diff suggests your binary should be -qt2
[08:29] <seb128> not -qt0.2
[08:30] <seb128> since when do we have dot so numbers?
[08:35] <sil2100> uh
[08:36] <seb128> the diff is confusing, the unpacked source uses 0.2 in its control
[08:36] <sil2100> pstolowski: could you poke michi about that?
[08:36] <seb128> unsure what's going on
[08:36] <sil2100> Would be good to decide on one
[08:37] <seb128> otherwise the new binaries seem fine
[08:37] <seb128> if you are happy with the 0.2 soname +1
[08:37] <pstolowski> seb128, hmm, i will pass these remarks to michi. can this be landed regardless of the problem with this particular lib package and we will deal with it separately? this library is not used by anyone, all it has is in experimental namespace still
[08:37] <seb128> just feels weird
[08:38] <seb128> pstolowski, ^
[08:38] <pstolowski> seb128, unfortunately michi is not around anymore today (he is from australia), and we have silos for ota that need scopes lib from this silo
[08:39] <pstolowski> seb128, yes, i'm happy with this lib for now, there are no Qt scopes yet
[08:40] <seb128> k, so +1 from the NEW review side
[08:41] <pstolowski> seb128, thanks
[08:41] <seb128> yw
[08:53] <ogra_> sil2100, do you know why the sensors api was dropped ? seems all sensors are gone now, i got no haptic feedback on my phone anywhere anymore ...
[08:54] <ogra_> (and the sensorstatus app from the store doesnt find anything either for any sensors)
[09:00] <sil2100> huh, indeed it got dropped, maybe it wasn't seeded and the dependency that was pulling it got removed
[09:00] <sil2100> Let me look into that
[09:02] <sil2100> ogra_: yeah, the qtubuntu landing from yesterday dropped it...
[09:02] <sil2100> Let me add it to the seeds
[09:02] <sil2100> I'll rebuild an image then
[09:05] <ogra_> +1
[09:05] <ogra_> feels weird ...
[09:06]  * ogra_ notes how much he got used to the vibration
[09:06] <sil2100> hah ;)
[09:08] <davmor2> sil2100: I wonder why that didn't show up in testing.....Oh of course old packages are not removed are they, I wonder if we can add apt-get autoremove to citrains instruction set maybe?
[09:10] <sil2100> https://code.launchpad.net/~sil2100/ubuntu-seeds/ubuntu-touch.wily-add_sensors/+merge/271622 <- I'm uploading the vivid package now
[09:11] <sil2100> I'll kick a new image once that builds
[09:11] <pstolowski> sil2100, hey, so silo 10 is good to land?
[09:14] <sil2100> pstolowski: yes! Noooow we need someone to still push teh buttonz, since I can't because of a train bug ;p
[09:14] <sil2100> seb128: can you push teh button on the silo 10 publish?
[09:15] <sil2100> seb128: I can't publish dual-silos right now since the permission check is wrong (fix in a MP)
[09:15] <seb128> sil2100, k
[09:15] <sil2100> Thanks!
[09:16] <sil2100> :)
[09:16] <seb128> yw
[09:16] <sil2100> pstolowski: ^ \o/
[09:16] <pstolowski> phew
[09:16] <seb128> done
[09:16] <jibel> davmor2, we should definitely do an autoremove or check for orphan packages after installing a silo. It is not the first time this hits us.
[09:18] <davmor2> jibel: I'm just looking at it now it seems like I can copy the format of the other package instructions to add an autoremove maybe
[09:28] <sil2100> Kicking new image
[09:29] <sil2100> brb
[10:00] <Saviq> cihelp, hey, something went wrong in the last two jobs for unity-api, jenkins failed to mkdirs somewhere https://jenkins.qa.ubuntu.com/job/unity-api-ci/
[10:01] <psivaa> Saviq: let me take a look
[10:01] <Saviq> tx
[10:37] <brendand> jibel, are we sure the autoremove is desirable in every case?
[10:39] <jibel> brendand, I don't know any other way to find and remove dropped dependencies
[10:39] <jibel> deborphan would work too but it is not on the image
[10:40] <brendand> jibel, i just get the feeling if it was straightforward we would have done it a long time ago
[10:40] <brendand> jibel, i seem to recall some objections when it was proposed originally
[10:46] <brendand> jibel, we should at least get a bug in phablet-tools
[10:48] <pstolowski> sil2100, huh, merge failed in silo 10?
[10:48] <jibel> davmor2 was about to file a bug
[10:49] <davmor2> jibel: proposed a merge instead :)
[10:49] <jibel> brendand, https://code.launchpad.net/~davmor2/phablet-tools/add-autoremove/+merge/271631 :)
[10:50] <jibel> davmor2, can you file a bug too and link it to the MP so discussion can happen there
[10:50] <davmor2> jibel: filing
[10:51] <brendand> davmor2, i just did
[10:51] <davmor2> brendand: where
[10:51] <brendand> davmor2, in phablet-tools...
[10:52] <brendand> davmor2, just linked it
[10:52] <brendand> jibel, i think the tricky thing is we need a way to test this in a realistic way, usually when these issues are discovered the situation has passed
[10:53] <brendand> davmor2, i'm not positive your change will do the trick, since SourceList is set to /dev/null at the point when you do the autoremove
[10:53] <jibel> brendand, since it a dependency that move from a package dependency to the seed, the only way to realistically test it is to build an image
[10:53] <brendand> davmor2, so apt only 'sees' what's in the PPA i believe
[10:54] <brendand> jibel, yeah citrain will never be perfect
[10:54] <brendand> jibel, the main question is whether this change would catch the issue in question
[10:55] <brendand> jibel, can we arrange for a silo to be created that reproduces the issue in question?
[10:55] <jibel> brendand, only way to know is to try. flash 108, upgrade qtubuntu and run autoremove
[10:55] <jibel> brendand, just upgrade qtubuntu on 108
[10:56] <jibel> brendand, 115 sorry
[10:56] <jibel> well latest -1 :)
[10:56] <brendand> jibel, still doesn't tell us what the effect is of SourceList being /dev/null at that point
[10:56] <brendand> jibel, but it would be a start
[10:56] <brendand> jibel, is that 115 on krillin?
[10:57] <jibel> brendand, on arale
[10:57] <jibel> brendand, on krillin it would be 127
[10:57] <brendand> jibel, sure? i'm on 127 now
[10:57] <brendand> jibel, 126?
[10:58] <jibel> brendand, 126 you're right, 128 has just been released with the fix
[10:59]  * ogra_ gives sil2100 a vibrating hug 
[10:59] <ogra_> all back to normal with the new image :)
[11:01] <pstolowski> seb128, hey, any idea what's wrong with silo 10 now?
[11:02] <seb128> no idea no, sorry
[11:03] <seb128> https://ci-train.ubuntu.com/job/check-publication-migration/14715/consoleFull
[11:03] <seb128> that states there are merge conflicts
[11:03] <pstolowski> seb128, yes i saw that, but it merges cleanly here
[11:03] <seb128> no idea, sorry
[11:06] <brendand> jibel, maybe it would be more effective if we could somehow pre-validate the changes going into an image?
[11:06] <brendand> jibel, although i guess the archive is constantly moving, so
[11:10] <pstolowski> seb128, is it possible to examine /srv/juju/8cf85e56-3fc7-4e9b-97df-423d87ebb8f5/var/lib/jenkins/silos/ubuntu/landing-010/unity-scopes-api/ ?
[11:15] <sil2100> ogra_: \o/ ;)
[11:16] <sil2100> pstolowski: I'll check in a moment
[11:17] <brendand> jibel, those steps certainly do result in qtubuntu-sensors being removed
[11:17] <pstolowski> sil2100, thanks. bbiab
[11:24] <sil2100> pstolowski: something strange happened in this silo indeed
[11:25] <sil2100> pstolowski: looking at the CI Train contents, it seems it didn't commit some changes... I better take a look at the package
[11:41] <sil2100> pstolowski: I think, to avoid confusion, we should really just merge it in manually
[11:41] <sil2100> I'll try to do it the right way
[11:53] <pstolowski> sil2100, hmm okay... is there any way to ensure that it was rebuilt after all the commits? shall we rebuild just in case?
[11:53] <sil2100> pstolowski: no no, all is ok it seems
[11:53] <sil2100> I just checked, it's just the train having problems
[11:53] <sil2100> Pushing manually
[11:54] <pstolowski> sil2100, uff, thanks
[11:54] <sil2100> pstolowski: ok, silo freed and branches pushed ;)
[11:54] <pstolowski> \o/
[11:55] <Saviq> psivaa, something bad happened with devices as well https://jenkins.qa.ubuntu.com/job/generic-deb-autopilot-runner-wily-mako/390/console
[11:55] <pstolowski> that was quite a battle. i'm sure michi will open a champagne
[11:56]  * alecu opens a diet coke
[11:56] <alecu> now, where's my 12yo rum...
[11:57] <alecu> pstolowski: this means that we'll be able to land "social interactions" soon, right?
[11:57] <pstolowski> sil2100, is to going to be immediately available to other silos, or do i need to wait?
[11:57] <pstolowski> alecu, yes, hopefully! if nothing unexpected happens (such as last events related to silo 10)
[11:58] <pstolowski> alecu, i.e. the coming landing will have single-tree branch for shell plugin, so i expect some bumps
[11:59] <alecu> pstolowski: so, we'll need another packaging ack from the ubuntu devs, like with silo 10, right?
[12:00] <pstolowski> alecu, probably, yes, although it's going to be less important change than with scopes api
[12:01] <psivaa> Saviq: https://jenkins.qa.ubuntu.com/job/unity-api-ci/337/ has now succeded
[12:01] <psivaa> Saviq: regarding the failure in the devices, i'll add a card for the team to look at.
[12:01] <Saviq> psivaa, thanks
[12:02] <psivaa> i'm about to go for my lunch, i'll take a look when i return if that is not picked up
[12:05] <sil2100> pstolowski: you can now prepare other landings, since the change is now in your trunk :)
[12:18] <pstolowski> sil2100, joy of joys, thanks for help! :)
[12:21] <sil2100> pstolowski: yw! Sorry this was such a bumpy ride ;)
[13:07] <sil2100> kenvandine: ugh!
[13:08] <kenvandine> sil2100, ?
[13:08] <sil2100> kenvandine: soooo... I just pushed a package to silo 009
[13:09] <sil2100> kenvandine: I'm testing something in staging and thought that it allocates silos the right way
[13:10] <sil2100> But it seems it was your silo ;p
[13:10] <sil2100> Anyway, let me remove it
[13:10] <sil2100> kenvandine: sorry about that ;p
[13:11] <kenvandine> sil2100, no... somethings wrong there
[13:11] <kenvandine> silo 9 has landed
[13:12] <kenvandine> sil2100, and those branches have been merged
[13:12] <kenvandine> not sure why it's lingering in bileto
[13:17] <sil2100> hmmm
[13:17] <sil2100> kenvandine: those are landed, yes?
[13:18] <sil2100> kenvandine: ok, so let me use that, I'll abandon it in a moment
[13:18] <kenvandine> sil2100, thx
[13:18] <sil2100> kenvandine: I'll test the silo in this case
[13:18] <kenvandine> no idea why it's still there
[13:18] <kenvandine> definitely landed though
[13:19] <sil2100> kenvandine: probably because of my staging assignment... it assigned it in the staging bileto, and the production one got confused
[13:29] <dobey> cihelp: does jenkins not understand @replaceme@ in the symbols files?
[13:30] <dobey> the jobs for MP verification, not silo builds, that is
[13:40] <rvr> jamesh: Approving silo 15
[13:45] <kenvandine> tar: ./control: Cannot write: No space left on device
[13:45] <kenvandine> sil2100,  trying to rebuild silo 53
[13:45] <sil2100> geh...
[13:50] <kenvandine> https://ci-train.ubuntu.com/job/ubuntu-landing-053-1-build/29/console
[13:50] <kenvandine> sil2100, ^^
[13:51] <kenvandine> jgdx, i tried rebuilding silo 53, which was dirty... but jenkins is angry with us :)
[13:51] <sil2100> Eh, the pbuilder seems to be full
[13:52] <sil2100> Since the instance itself has a lot of space
[13:52] <sil2100> Let me check what we can do about this situatio
[13:52] <sil2100> n
[13:52] <kenvandine> sil2100, thx
[13:55] <jgdx> kenvandine, right, because of the ofono landing.
[13:55] <jgdx> kenvandine, and a new build failed?
[13:55] <kenvandine> jgdx, yeah... but now we can't build
[13:55] <kenvandine> out of space
[13:55] <kenvandine> sil2100's going to get us going again :)
[13:55]  * sil2100 still looking
[13:56] <jgdx> kenvandine, out in space? like LEO?
[13:56] <kenvandine> lol
[13:58] <oSoMoN> sil2100, I’m affected too with the no space left on device issue: https://ci-train.ubuntu.com/job/ubuntu-landing-035-1-build/64/console
[14:15] <barry_> trainguards: testing
[14:15] <sil2100> barry_: what's up?
[14:15] <sil2100> kenvandine: try now :)
[14:15] <barry> sil2100: just testing my erc notification setting :)
[14:16] <sil2100> hah
[14:16] <sil2100> ;)
[14:17] <Mirv> barry: hmm :D
[14:18] <barry> emacs ftw
[14:19]  * kenvandine tries
[14:35] <kenvandine> sil2100, that worked :)
[14:35] <sil2100> phew
[14:35] <kenvandine> sil2100, thx
[14:36] <sil2100> yw ;)
[14:43] <jgdx> sil2100, thanks!
[14:45] <jgdx> kenvandine, you started a build of the whole whack?
[14:45] <kenvandine> jgdx, just settings
[14:45] <kenvandine> jgdx, did indicator-network need a rebuild too?
[14:46] <jgdx> kenvandine, don't think so, just curious
[14:46] <jgdx> thanks!
[14:46] <kenvandine> ok
[14:50] <Saviq> trainguards, ENOSPC during source package build: https://ci-train.ubuntu.com/job/ubuntu-landing-010-1-build/231/consoleFull
[14:50] <Saviq> should I just try again?
[15:00] <fginther> dobey, can you provide an example of the @replaceme@ problem? I think the answer is no, but I'd like to verify
[15:01] <dobey> fginther: https://jenkins.qa.ubuntu.com/job/pay-service-15.04-vivid-amd64-ci/30/console
[15:01] <dobey> dpkg-gensymbols: error: @replaceme@ is not a valid version
[15:03] <pstolowski> sil2100, hey, may i ask you to purge unity-scopes-api from https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-024 ?
[15:04] <mterry> robru, I am in no way trying to poke you to push something along.  I just want to confirm I did the process correctly, since I don't think I've requested a silo using bileto yet.  Is silo ticket 381 ready from my side?
[15:09] <fginther> dobey, do you know where this is documented? From looking at the ci-train code, it looks like the correct string should be "0replaceme". But I could be missing something
[15:09] <sil2100> pstolowski: sure, on it
[15:10] <sil2100> Saviq: try again, I just recenly cleaned the pbuilders
[15:10] <sil2100> mterry: let me take a look, robru is on holidays ;)
[15:10] <mterry> sil2100, ah thanks  :)  dang leaving IRC on
[15:11] <sil2100> pstolowski: deleted
[15:11] <pstolowski> sil2100, ty
[15:12] <dobey> fginther: oh ok. so the closing @ is not supposed to be there?
[15:12] <sil2100> mterry: almost perfect ;) You need to switch the last drop-down to 'QA Required'
[15:12] <sil2100> mterry: you can do that by editing the request
[15:12] <sil2100> mterry: once you're done, try assigning the silo :)
[15:12] <fginther> dobey, and the first character is a '0' (zero), not an '@'
[15:13] <dobey> fginther: oh
[15:15] <mterry> sil2100, aha did it
[15:15] <mterry> sil2100, now I have LP permission to upload to landing-051 PPA?  will try that
[15:17] <dobey> fginther: is that documented somewhere?
[15:17] <sil2100> mterry: you should have, you're a core-dev
[15:17] <mterry> cool
[15:17] <sil2100> :)
[15:18] <mterry> indeed, i"m in that team
[15:18] <mterry> That was a surprise.  But I'm in so many teams it's hard to keep track
[15:18] <fginther> dobey, I was able to find this which still appears to apply: https://wiki.ubuntu.com/DailyRelease/FAQ#I.27m_exposing_a_new_C.2BAC8-C.2B-.2B-_symbols_in_my_library.2C_it_seems_that_some_packaging_changes_are_needed.2BICY-
[15:40] <rvr> kgunn: Approving silo 60
[15:42] <kgunn> rvr: awesome!
[15:42] <kgunn> thanks
[15:47] <fginther> Saviq, FYI, I restarted the MPs that were impacted by the failure of one of the mako devices.
[15:47] <Saviq> fginther, thanks
[15:56] <robru> sil2100: nothing you can do in staging has any ability to touch anything in production. The only "confusion" i can think of is that the staging bileto ppa links to production PPAs. But it's just a link, it would be up to you to copy packages into production by mistake
[15:58] <sil2100> robru: all is good, I noticed that already when testing ;)
[16:02] <robru> sil2100: OK, some scrollback is making me nervous
[16:49] <kgunn> trainguards: strangely...i've got me first chance to land something with bileto...if i have QA approaved, is it "publish" & then "merge & clean" ?
[16:52] <robru> kgunn: yes except merge & clean is automatic and you don't have permission to publish. I'm afk but perhaps barry is around to publish that for you. Just tell him what request it is
[16:52] <rvr> bfiller: ping
[16:52] <barry> kgunn: you will be my guinea pig
[16:52] <kgunn> :) barry it's silo 60 thanks
[16:53] <barry> kgunn: you want me to publish that silo, right?
[16:54] <kgunn> barry: please sir
[16:55] <barry> kgunn: i need to ack packaging changes, so let me take a quick look at the mp
[16:55] <kgunn> you bet
[16:58] <barry> kgunn: um, now i'm not sure which request this is.  if i search for Publishable i see landing-022 and landing-053, neither of which is yours
[16:59] <barry> ah, wait
[16:59] <barry> ubuntu/landing-60 right?
[16:59] <barry> it's in a different bucket now i think
[17:01] <barry> kgunn, robru i admit i am confused trying to find the landing you want to publish
[17:38] <fginther> Saviq, The requested changes for lp:unity8, lp:unity-api and lp:qtmir have all been deployed (since late yesterday)
[17:38] <fginther> Saviq, please let us know if something is not quite right
[17:45] <Saviq> fginther, oh yeah we're very happy :)
[17:46] <Saviq> fginther, there were some issues today but they seem resolved now (unrelated to job configs, the broken mako and some weird mkdirs problem psivaa solved)
[17:49] <ChrisTownsend> trainguards: I'm ready for landing-015 to go into the Publishing phase.  Do I click Publish in my landing request or do one of you do it?
[17:53] <Saviq> ChrisTownsend, they need to, we've no rights
[17:54] <ChrisTownsend> Saviq: Oh ok.  So we always ping when we are to publish?
[17:55] <Saviq> ChrisTownsend, generally they monitor the queue and will publish if they see one that's ready
[17:55] <ChrisTownsend> Saviq: Sorry for the questions, but how to I set it that it is ready?
[17:55] <Saviq> ChrisTownsend, QA does
[17:56] <Saviq> ChrisTownsend, and in your case you set it to "publish without QA"
[17:56] <Saviq> since you didn't require QA
[17:57] <ChrisTownsend> Saviq: Ah, ok.  "No QA needed" is not the correct one.
[17:57] <Saviq> ChrisTownsend, it is, before you verify it
[17:57] <Saviq> ChrisTownsend, basically, it has to show up in https://requests.ci-train.ubuntu.com/#/trainguards
[17:57] <ChrisTownsend> Saviq: Ok, now I got it.  Thanks!
[17:58] <ChrisTownsend> Saviq: This is the first time I've done a release since the change away from the spreadsheet.
[17:58] <Saviq> ChrisTownsend, nw, I'm only doing my own first landing after being back, too
[17:59] <ChrisTownsend> Saviq: lol, you seem to have The Knowledge:)
[17:59] <Saviq> ChrisTownsend, likely I've just been through the process so many times I know the levers to pull by now ;)
[18:00] <ChrisTownsend> Saviq: heh
[18:01] <kgunn> barry: still confused? afaik it's this one
[18:01] <kgunn> https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-060
[18:02] <barry> kgunn: yeah, sorry, i got pulled into a meeting.  give me a few minutes to wrap that up and i'll take a look again
[18:08] <barry> kgunn: okay, i think i've got it.  i should talk to robru about the ui.  i find it difficult to go from an irc request that says "landing-60" to finding the actual line in the ui that refers to that.  really my first use of the new ui
[18:09] <barry> kgunn: there ya go ^^
[18:14] <kgunn> thanks barry! have a great weekend
[18:15] <Saviq> hmm is citrain tool supposed to prevent overlay packages from getting installed? not happening here
[19:09] <kgunn> trainguards i know it's late on a friday but i just hit assign on bileto, but it gave me an assignment error
[19:09] <kgunn> https://ci-train.ubuntu.com/job/prepare-silo/6198/console
[19:09] <kgunn> mentioning silo 60...which ironically was the silo i had earlier today
[19:09] <kgunn> just a weird bug getting the same silo twice ?
[19:10] <kgunn> the landing i had in silo 60 earlier says "landed"
[19:10] <kgunn> so i would assume it's free
[19:46] <robru> barry: can you file a bug against lp:bileto? "Publishable" page should include silos needing ack but doesn't
[19:51] <barry> robru: yep.  i think i'll file another bug which is that it should be possible to search for something like 'landing-60' and get the silo needing attention.  i think 'landing-60' didn't turn up anything, but i found it by searching for '60'
[19:52] <robru> barry: weird it should work if you search by landing-xxx
[19:52] <robru> Except that it would show every request that ever went through that silo
[19:53] <barry> robru: maybe that was the problem.  it's too hard to find the thing i need to poke when someone ask for help with "landing-60"
[19:53] <robru> kgunn: can you send me the exact request you had when you got that prepare error? I've seen that before but haven't been able to reproduce it, also the error makes no sense as there are checks in place to prevent that situation
[19:54] <robru> barry: yeah people should probably just be trained to use the requestid or just send links
[19:54] <barry> yeah
[19:54] <barry> robru: but that's human nature :)
[19:55] <robru> barry: saying "silo x" was OK when there were only 20 but it hasn't really scaled
[19:56] <barry> robru: agreed
[19:56] <robru> barry: but there are definitely growing pains where bileto could be better, in trying to iterate on it
[19:56] <kgunn> robru: i gotta run, but i actually abandoned that...it's a qtmir request
[19:56] <kgunn> i started another one, but now it says "out of silos"
[19:56] <robru> Blast
[19:57] <barry> robru: what?  the first release wasn't perfect?  madness
[19:57] <kgunn> how dear he
[19:57] <kgunn> try to improve and not achieve perfection on mark 1
[19:57] <kgunn> hmpf
[19:57] <robru> kgunn: well i could have left you with the spreadsheet while i perfected bileto :-P
[19:59] <barry> robru: LP: #1497434
[20:00] <robru> barry: thanks, next week will see a bunch of fun improvements i think
[20:02] <barry> robru: LP: #1497435 is the other one.  see if that makes sense
[20:04] <robru> barry: yeah I think I"ll have to implement a new search just for silonumbers that hides older landings.
[20:04] <barry> robru: +1
[20:28] <robru> kgunn: ah, the issue with your latest request is that you had a branch instead of a merge in there. I'll have to clean up that traceback
[20:49] <oSoMoN> trainguards: can silo 59 be published, please?
[20:50] <barry> oSoMoN: yep
[20:53] <robru> oh goody
[20:54] <oSoMoN> what is this "'NoneType' object is not iterable" error?
[20:54] <robru> oSoMoN: somebody else's silo has a branch instead of a merge and the train explodes while trying to mark other silos dirty
[20:54] <robru> oSoMoN: the publish was successful
[20:55] <oSoMoN> robru, ok
[20:55] <barry> well, i've reached my destination for the week, so i'll no longer be guarding the train today
[20:55] <robru> barry: thanks for filling in
[20:56] <barry> robru: so much nicer than the spreadsheet! :)
[20:56] <robru> barry: glad you like it! it's only going to get better!
[20:56] <robru> oSoMoN: ^^ that's a better status
[20:57] <oSoMoN> robru, yeah, that’s better indeed :)