[10:12] <ogra_> sil2100, where do i commitr system image config changes, i see the etc/ dir is a bzr branch, is it only there or is there a matching external one
[10:30] <sil2100> ogra_: commit your changes and just do a bzr push
[10:32] <ogra_> sil2100, so no external LP branch then, ok
[10:34] <morphis> sil2100: can you drop the wily packages from silo 52 for me?
[10:34] <ogra_> sil2100, eeek, there are uncommited changes
[10:37] <sil2100> ogra_: yeah, temporary stuff usually is left uncommited
[10:37] <morphis> sil2100: or is that anymore true that we should lands things also for wily?
[10:37] <sil2100> But I suppose you can just commit that
[10:37] <sil2100> morphis: on it, removing
[10:37] <ogra_> sil2100, well, how do i commit my stuff then ?
[10:37] <morphis> sil2100: thanks!
[10:37] <ogra_> ah ok
[10:37] <sil2100> xenial should be the focus now
[10:38] <sil2100> ogra_: those 'temporary changes' are usually changes that have no relevence if they're reverted or not ;)
[10:38] <sil2100> At least that's the overall idea
[10:39] <ogra_> sil2100, well the prob is that you have no history if every now and then youor log has "committed uncommited changes that someone did"
[10:39] <ogra_> i.e. you dont now what they were for
[10:39] <sil2100> morphis: deleted
[10:39] <sil2100> ogra_: yeah, I guess we'll have to make sure to keep the config clean next time
[10:39] <sil2100> hm, I think I might have had some uncommited changes there
[10:40] <ogra_> or just commit the temporaray stuff too ...then you have proper explanation ...
[10:40] <sil2100> But those, as I said, were irrelevant things - will commit them next time
[10:40] <sil2100> Sorry about that ;)
[10:40] <ogra_> no prob
[10:55] <Saviq> sil2100, is there a xenial channel yet?
[11:00] <jibel> Saviq, it'll be devel-proposed once there is a build for it which sil2100 said he would work on today
[11:01] <Saviq> jibel, ack, thanks
[11:01] <sil2100> Yeah, actually my expectation was it would switch automatically, but seems it needs a bit manual love
[11:01] <sil2100> On my plate today
[11:05] <rvr> jgdx: ping
[11:44] <pstolowski> trainguards, hey, what's happening to silo 24? it's been in a weird state for 2-3 days
[11:46] <sil2100> Let me take a look
[11:47] <sil2100> hm, looks like it got rejected
[12:36] <jgdx> rvr, ponmg
[12:36] <rvr> jgdx: Hey
[12:37] <rvr> jgdx: Silo 47. How do I check the OTA version in ubuntu-system-settings?
[12:37] <rvr> jgdx: I see no info in the About page
[12:37] <jgdx> rvr, i think you have to have ota8, but I'm not sure. sil2100 ^ do you know?
[12:38] <rvr> jgdx: Phone was flashed in rc-proposed channel
[12:38] <jgdx> rvr, if not, let me know if you want me to create a mock for this.
[12:38] <jgdx> command line that will give you an ota
[12:39] <rvr> jgdx: How did you test the feature?
[12:39] <jgdx> rvr, using a mock
[12:40] <jgdx> sil2100, if you flash ota7 now, will you get a tag=ota7 in version_details? You know?
[12:40] <rvr> version_detail: ubuntu=20151028,device=20150911,custom=20151028,version=274
[12:52] <sil2100> jgdx: no, we won't be supporting tags from the past
[12:52] <sil2100> jgdx: since this requires an image to be re-created (with the new tag)
[12:52] <jgdx> sil2100, yup. Thanks!
[12:52] <jgdx> rvr, so impossible to test w/o trickery
[12:53] <sil2100> If you need it for testing, I can prepare a private system-image server
[12:53] <sil2100> I mean, hm, I would need to find a public place first
[12:53] <jgdx> sil2100, I was going to suggest a mocked s-i, but whatever's fine with me.
[12:54] <sil2100> jgdx, rvr: let me quickly take a look if I can export my s-i somewhere, you guys could then flash from there for testing
[12:54] <rvr> I tried to add the tag to the file, but no luck
[12:54] <jgdx> sil2100, thanks
[13:21] <pstolowski> sil2100, rejected? why?
[13:25] <pstolowski> sil2100, also.. are the builders overloaded atm or something? i'm rebuild the mediascanner scope in silo 4 and it has been over 2,5 hrs already
[13:26] <cjwatson> pstolowski: arm64 still has a day or so left of a test rebuild
[13:26] <cjwatson> pstolowski: I've scored up your builds, though they were pretty close already
[13:27] <pstolowski> cjwatson, ah i see
[13:33] <pstolowski> sil2100, anything i can do about silo 24? it would be great to land it as i have another one in the pipeline :)
[13:35] <sil2100> pstolowski: let me take care of it now, had a busy afternoon today ;/
[13:37] <sil2100> pstolowski: ah, I think I see why it failed!
[13:37] <sil2100> Let me publish it by hand
[13:37] <pstolowski> uhm
[13:38] <pmcgowan> mterry, Saviq silo21 still dirty :(
[13:39] <mterry> pmcgowan, looks like it got some builds in last night though -- you can try it and it should have the shutdown dialog fix
[13:40] <pmcgowan> mterry, I was thinking, are we doing too little in powerd and too much in unity? seems it should be simple to have two distinct events
[13:42] <mterry> pmcgowan, yeah it might make more sense to have USC/powerd emit a "long power press" signal that u8 consumes
[13:42] <mterry> I think there are still intentions to review that whole power signaling mess
[13:43] <pmcgowan> mterry, exactly, insteaad now there are multiple button pressed and released signals
[13:43] <pmcgowan> should just be short and long
[13:43] <pmcgowan> then filter multiple presses that are too frequent
[13:49] <dobey> rvr: ping
[13:58] <rvr> dobey: pong
[14:05] <dobey> rvr: so, the issue with the online-accounts is very improbable to be hit by pay-ui in real production devices, as once it lands in the store, and new images get built, the new version will already be installed, and anyway installing it as an update through system-settings will likely not have done an immediate --wipe flash of their device after the new click was built, as the click which will land in the store will be built b
[14:05] <dobey> rvr: so i'm wondering if we could please move forward with the landings
[14:09] <rvr> dobey: As I commented on the trello card, the plan is to land silo 1 first, then pay-ui, and then 26.
[14:10] <rvr> mardy is already working on it, so seems it won't take too long
[14:13] <Saviq> pmcgowan, it's dirty because there were new commits, but it's sane
[14:14] <pmcgowan> Saviq, ack
[14:46] <mardy> cjwatson: is it possible to score up https://ci-train.ubuntu.com/job/ubuntu-landing-056-1-build/33/console and https://ci-train.ubuntu.com/job/ubuntu-landing-001-1-build/231/console too?
[14:48] <cjwatson> mardy: the first is already building; done the second
[14:49] <alan_g> cihelp: we're seeing consistent problems on krillin in CI (https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-touch/) that we're having trouble reproducing locally. What image is installed on these runners?
[14:50] <fginther> alan_g, one moment
[14:51] <oSoMoN> trainguards: is https://requests.ci-train.ubuntu.com/#/ticket/576 correctly configured so that vivid packages will land in the overlay PPA and xenial packages in the archive?
[14:53] <fginther> alan_g, ubuntu-touch/rc-proposed/ubuntu
[14:53] <fginther> alan_g, which currently appears to be image 312
[14:54] <alan_g> fginther: thanks.
[14:55] <rvr> xavigarcia: ping
[14:55] <mardy> cjwatson: thanks a lot!
[14:56] <sil2100> oSoMoN: looking
[14:58] <sil2100> oSoMoN: looks ok, although I'm not sure if the Destination PPA shouldn't be empty
[14:58] <sil2100> oSoMoN: since dual silos anyway by default land the vivid part to the overlay
[14:58] <sil2100> But I need to check the code as robru made a lot of modifications in the past few weeks ;)
[14:58] <oSoMoN> yeah, that’s what I’m unsure about too
[15:03] <xavigarcia> rvr pong
[15:04] <rvr> xavigarcia: Hi
[15:05] <rvr> xavigarcia: I'm taking a look at silo 46, I think it contains new strings, right?
[15:05] <rvr> xavigarcia: I plugged my headphones and a notification appeared with "Headphones" as title
[15:05] <xavigarcia> rvr: yeah, it has new string to show the output device
[15:06] <rvr> xavigarcia: Ok. I think we are blocking it, we are in string freeze.
[15:06] <xavigarcia> rvr: ok :(
[15:12] <rvr> sil2100: Any news about the s-i for OTA tag?
[15:13] <sil2100> rvr: I'm testing my local s-i on my krillin right now to see if it flashes/works correctly from the local server
[15:14] <rvr> sil2100: Ack
[15:14] <sil2100> rvr: once that's done I'll export it for you to test for a moment
[15:14] <rvr> sil2100: Cool, thanks
[15:16] <barry> robru: ping
[15:17] <sil2100> rvr: how can I get my krillin into recovery?
[15:17] <rvr> sil2100: Power + Volume Up for 20 seconds or so
[15:18] <rvr> When you see a red light, release Power
[15:18] <rvr> With Up select Recovery and with Volume Down enter that option
[15:18] <sil2100> rvr: thanks!
[15:19] <sil2100> I suspect the GPG keys might be causing problems
[15:33] <sil2100> Ah, I think I see what's broken
[15:36] <dbarth__> uh, sorry if that a faq, but how do i transition an old silo to xenial?
[15:36] <dbarth__> https://requests.ci-train.ubuntu.com/#/ticket/446
[15:36] <dbarth__> hi trainguards ^^
[15:49] <sil2100> dbarth__: hey!
[15:52] <dbarth__> sil2100: hi
[15:52] <sil2100> dbarth__: so first of all, you need to switch the silo type to xenial+vivid
[15:53] <sil2100> dbarth__: so edit the 'Target Series' field and save
[15:53] <sil2100> Next, rebuild your silo
[15:53] <sil2100> I'll remove the wily binaries from the PPA
[15:53] <sil2100> rvr: still investigating, my phone doesn't want to properly update to any image from my local s-i instance
[15:55] <rvr> sil2100: Ack
[15:55] <sil2100> (unrelated to the tag= syntax, simply issues with the local server or my flashing mechanisms)
[15:56] <sil2100> dbarth__: should I remove the wily binaries now? :)
[15:57] <dbarth__> sil2100: ok done
[16:09] <sil2100> dbarth__: packages removed
[16:10] <dbarth__> sil2100: thank you
[16:15] <jgdx> sil2100, any progress on the private s-i-s for rvr ?
[16:15] <jgdx> anything I can do before I eod?
[16:15] <pete-woods> trainguards: hi folks, we have a new project we want to get into xenial, and indeed vivid overlay (https://launchpad.net/gmenuharness), I can't remember the process to do it, though :$ (been a while)
[16:27] <pete-woods> name of the right person to ping is all I'm after, really :)
[16:39] <rvr> mardy: dobey: Great, pay-ui can be installed with silo 1 :))
[16:40] <rvr> and it shows the Ubuntu One login screen in the Store
[16:43] <dobey> rvr: good
[16:55] <Saviq> robru, any reason for the silo branches having $source-name duplicated? like ~ci-train-bot/unity8/unity8-...?
[16:57] <rvr> mardy: jgdx: There is a problem in the online accounts page in System Settings
[16:57] <rvr> mardy: jgdx: When editing an account (Google, Facebook), there is no bar with button to go back
[16:58] <rvr> jgdx: Maybe related to components 1.3 migration
[17:19] <jgdx> rvr, hm, right.. mardy, was online accounts migrated to 1.3?
[17:20] <rvr> https://bugs.launchpad.net/canonical-devices-system-image/+bug/1511055
[17:26] <sil2100> rvr: ok, I flashed my device from my local s-i instance and confirmed that the tag= field is there
[17:26] <sil2100> rvr: how long will you work today still?
[17:27] <rvr> sil2100: I will finish current silo
[17:27] <rvr> sil2100: Can we check it tomorrow morning?
[17:28] <sil2100> rvr: sure, all is ready, I'll just open it up for you tomorrow then
[17:28] <rvr> Thanks
[17:28] <sil2100> rvr: but please note you'll need to flash with a script for disabling GPG verification and the adb unlocking recovery...
[17:28] <rvr> sil2100: Ok
[17:29] <rvr> --run-script=/home/vrruiz/bin/disable-gpg.sh
[17:29] <sil2100> hah ;)
[17:29] <rvr> I'm already disabling gpg
[17:29] <sil2100> Prepared already I see!
[17:43] <robru> barry: pong
[17:44] <robru> Saviq: yes, because the first one is the project name and the second one is the source package name, they're not always the same (mostly it's so gles twins don't clobber the main trunks but there's other cases too)
[17:46] <robru> sil2100: it's always been the case that vivid goes to overlay and dest ppa controls only where primary series goes (wily or xenial).
[17:46] <Saviq> robru, ack
[17:51] <robru> dbarth__: rebuild wasn't necessary, especially since you already had qa approval, sorry sil2100 gave bad info.
[17:52] <robru> My email announcing xenial switch explained the correct steps
[17:52] <robru> Too late to go back now though!
[17:52] <dbarth__> robru: uh, my bad; it had the info, i just forgot
[17:53] <dbarth__> note for others: read robru's email !
[17:53] <robru> Yes!
[18:05] <sil2100> Sometimes I copy existing wily binaries to xential, yes
[18:05] <sil2100> But I usually noticed that people anyway want to rebuild since there are toolchain changes etc.
[18:05] <sil2100> So sorry if you had to rebuild without any reason
[18:21] <robru> sil2100: oh did the toolchain stuff land already? I didn't think it had yet.
[18:23] <robru> barry: with regards to deadlocking, how likely is it for python to exit without closing it's fd's? In my (limited) testing i wasn't able to see a deadlock, it always freed the lock on process exit
[18:25] <barry> robru: well, i'd have to go to my stevens to remind myself of generic process semantics, but python itself won't do anything special.  you can always set an atexit handler to explicitly close fds (or do whatever), but of course those handlers running are subject to the usual caveats, e.g. os._exit() or kill -9 won't run them
[18:27] <robru> barry: Hmmmmmmm OK I'll need to test further in order to decide if it's worth switching.
[18:28] <robru> barry: never heard of os._exit but sys.exit gets called in some cases. Most common signal will be 15 of user cancelled job in Jenkins
[18:30] <barry> robru: sys.exit is fine; it raises an exception and if uncaught, it does a normal shutdown procedure.  same with catchable signals
[18:30] <barry> robru: https://docs.python.org/3/library/os.html#os._exit
[18:31] <robru> barry: OK great, the signal handler i have for signal 15 calls sys.exit
[18:31] <sil2100> Xenial is now open for development, so the most important stuff is in
[18:54] <rvr> mardy: Silo 1 approved
[19:13] <dobey> hmm
[19:24] <robru> barry: what's 'stevens'?
[19:25] <barry> robru: http://tinyurl.com/ndcpys3  - it's the definitive book on unix semantics
[19:26] <robru> barry: oooh
[19:26] <barry> every *nix developer should own a copy (i really need to get the 3rd edition)
[19:26] <barry> w. richard stevens died a long while ago, but i believe it's been updated by other pepole and is still relevant
[19:26] <robru> barry: yikes, $30 even on kindle
[19:27] <barry> he also has books on network programming which are really excellent too
[19:27] <robru> barry: must be printed with golden electrons
[19:27] <barry> yeah, but worth every penny :)
[19:27] <robru> barry: maybe I'll pick it up then ;-)
[19:28] <barry> looks liked 3rd ed even covers "ubuntu 12.04 (based on linux 3.2)"
[19:33] <sil2100> robru: uh: https://ci-train.ubuntu.com/job/ubuntu-landing-001-2-publish/123/console <- you saw anything like this before?
[19:34] <robru> sil2100: yeah, the silo is locked
[19:34] <robru> sil2100: that should only happen if you try to run two jobs simultaneously.
[19:35] <sil2100> The silo was ready for publish and built, maybe some lock that's left-over?
[19:35] <robru> sil2100: not sure, the train has code to check that locks are stale but if you feel it's in error you can delete ~/silos/$SILONAME/lock
[19:35] <sil2100> https://requests.ci-train.ubuntu.com/#/ticket/573 <- the silo looks fine here
[19:36] <robru> sil2100: that is weird
[19:36] <robru> sil2100: I'm working on a refactor of locking that should hopefully eliminate these issues
[19:38] <sil2100> robru: ok, thanks :)
[19:47] <robru> barry: I have a question about generators
[19:47] <barry> robru: sure
[19:48] <renatu> robru, do you know what is the problem with this silo? https://ci-train.ubuntu.com/job/ubuntu-landing-002-1-build/241/console
[19:48] <robru> barry: let's say I'm iterating on a generator and it takes a long time (~5 minutes total).
[19:48] <renatu> I am getting silo locked too, on silo 2
[19:48] <robru> barry: if the generator instantiates an object for each iteration, what's the lifecycle of the object? is the object freed when the next iteration starts? no reference to the objects is kept as far as I know
[19:49] <robru> renatu: looking
[19:51] <barry> robru: the generator is a closure so if the object is referenced by a local variable in the generator, that reference will keep the object alive.  from there, it's normal python lifecycle semantics.  if you reassign or del the name binding and the object's refcount goes to zero, it gets freed.  if the object participates in a cycle, the cyclic garbage collector will eventually break the cycle, subject to those semantics (e.g. based on
[19:51] <barry> the presence of __del__'s)
[19:52] <robru> renatu: sil2100: oh apparently i goofed up and rolled out a half-finished merge to production, awesome.
[19:52] <robru> will fix that asap
[19:53] <robru> barry: so like this: http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro/trunk/view/head:/cupstream2distro/silomanager.py#L163 it just yeilds the object without assigning it, those'll be freed after each iteration right? or does python hang onto them until the full generation is complete?
[19:59] <robru> renatu: sil2100: ok trunk is fixed, should hit production in ~20 minutes
[20:02] <barry> robru: here's a good boiled down example which should explain what's going on: http://paste.ubuntu.com/12992694/
[20:02] <barry> but yes, they should get freed
[20:04] <barry> robru: er, try this instead: http://paste.ubuntu.com/12992722/
[20:07] <robru> barry: seems to work even without the del at the end
[20:07] <barry> robru: right, the del is just for printing a message when the object is collected
[20:07] <barry> robru: if the del created a cycle, then you'd have problems :)
[20:07] <barry> *or resurrected the object
[20:07] <barry> __del__'s can be evil :)
[20:08] <robru> barry: but I mean I dropped the del and it still prints 'freed' in each iteration instead of all at the nd
[20:08] <barry> robru: impossible :)
[20:08] <barry> well, if you replace the def with a pass
[20:08] <robru> barry: what?
[20:09] <barry> robru: what does "dropped the del" mean?
[20:09] <barry> oh, you mean `del obj`
[20:09] <barry> robru: that makes sense
[20:09] <robru> barry: http://paste.ubuntu.com/12992782/
[20:09] <robru> yeah
[20:10] <robru> barry: that's great though, that answers my question and it's the behavior I wanted ;-)
[20:10] <barry> right?  "obj" gets rebound to a new Foo instance, and rc() returns so both refcounts are dropped, and the object's refcount goes to 0 so it gets del'd.  at the end of the for loop, obj gets unbound
[20:10] <barry> s/end of the for loop/script exits/
[20:11] <robru> barry: right
[20:12] <robru> barry: this means that the generator loop should only lock each object for 5 seconds each instead of locking them all for the full 5 minutes, so that's perfect ;-)
[20:12] <barry> cool :)
[20:21] <robru> sil2100: renatu: ok try again?
[21:00] <robru> Saviq: oh btw, not sure if you noticed yet, but "bug NNN" and "# NNN" are both linkified now. You don't need to use pad.lv anymore if you don't want to
[21:00] <Saviq> robru, oh good, thanks
[21:01] <robru> Saviq: you're welcome!