[00:28] <mhall119> new loco-directory has gone live!
[00:28] <mhall119> \o/
[00:51] <pleia2> woohoo!
[00:51] <pleia2> ooh, to .4
[00:52] <mhall119> we can arbitrarily start calling it 3.0, but it'll still be just an evolutionary release :P
[00:52] <pleia2> well, it was 0.3.2 before today :)
[01:02] <mhall119> see, you get 2 releases for the price of 1
[01:06] <mhall119> also, meetings now support timezones!
[01:10] <pleia2> yes! that's the part I'm excitedest about the most :)
[01:10]  * pleia2 told cjohnston she'd write a blog post about it, taking screenshots and doing so now
[01:18] <pleia2> oh bother, I broke it
[01:18] <mhall119> no, doctormo broke it
[01:18] <pleia2> oh, phew
[01:18] <mhall119> I assume you were adding an event?
[01:19] <pleia2> yeah
[01:19] <pleia2> checking out new virtual events thingy
[01:19] <mhall119> yeah, doctormo's code, not working for some reason
[01:30] <mhall119> pleia2: fixed
[01:30] <pleia2> \o/
[01:31] <mhall119> hope that's all that's broken, cause I'm out of vangards
[01:31] <pleia2> :)
[01:32] <pleia2> bugs are easy, but if people had questions about the functionality what is the best way to get in touch with you guys, #ubuntu-website? mailing list?
[01:32] <mhall119> either
[01:32] <mhall119> #ubuntu-website is fastest when we're awake
[01:32] <pleia2> ok
[02:20] <mhall119> pleia2: ping
[02:21] <pleia2> mhall119: pong
[02:21] <mhall119> pleia2: was it you that brought up the fact that the ical had broken timezone info?
[02:21] <pleia2> mhall119: no, it was someone on the loco-contacts mailing list
[02:22] <mhall119> ok, thanks
[02:22] <pleia2> https://lists.ubuntu.com/archives/loco-contacts/2011-June/005439.html
[02:22] <pleia2> magicfab
[02:23] <mhall119> thanks
[02:27] <cjohnston> pleia2: would you fridge the blog post please?
[02:28] <pleia2> cjohnston: it's there!
[02:28] <pleia2> oh, fridge
[02:28] <pleia2> sure :)
[02:28] <cjohnston> :-P
[02:28] <cjohnston> publicity is key ;-)
[02:28]  * pleia2 is kind of slow
[02:28] <pleia2> hehe
[02:28] <cjohnston> you got a blog post out in less than two hours... thats not really slow
[02:34] <mhall119> pleia2: awesome writeup, thanks
[02:35] <pleia2> ok, it's up on ubuntu-news.org now too
[02:35] <pleia2> sure, thanks for all your work guys :)
[02:36]  * pleia2 made meeting event \o/
[02:38] <cjohnston> lol
[02:38] <mhall119> yay!
[02:38] <cjohnston> did it work all good and stuffs
[02:38] <mhall119> pleia2: can you check your team's ical to see if the timezone info on that is correct?
[02:41] <pleia2> X-WR-TIMEZONE:UTC
[02:41] <cjohnston> is that on your brand new event?
[02:41] <pleia2> yes
[02:41] <pleia2> DTSTART:20110704T020000Z
[02:41] <pleia2> DTEND:20110704T030000Z
[02:41] <pleia2> this is a 07/03 event at 19:00 PDT, still in UTC on ical
[02:45] <cjohnston> link to the event
[02:45] <pleia2> http://loco.ubuntu.com/meetings/ubuntu-california/120/detail/
[02:45] <pleia2> we can take this over to -website if you want
[02:46] <cjohnston> uggh
[02:47] <cjohnston> pleia2: would you mind too horribly much updating the "my teams" screenshot
[02:47] <cjohnston> that one doesnt look right
[02:47] <pleia2> ooh, prettier now
[02:47] <cjohnston> ya.. there was a lil problem
[02:47] <mhall119> pleia2: the ical is correct then
[02:48] <mhall119> 7/4 0200 UTC == 7/3 1900 PDT
[02:48] <cjohnston> I see the meeting as 2200 in google calendars pleia2
[02:49] <mhall119> cjohnston: because your google calendar is in EDT
[02:49] <cjohnston> the calendar app should change it to your tz
[02:49] <mhall119> 2200 EDT == 19 PDT == 0200 UTC
[02:49] <cjohnston> yup
[02:49] <cjohnston> mhall119: we do have one bug
[02:49] <mhall119> what was missing before was the bit where the ical specified that it's times are in UTC, so your calendar would assume it was in local time
[02:49] <mhall119> cjohnston: what's that?
[02:49] <cjohnston> maybe i can talk lyz into filing it.. hehe
[02:50] <cjohnston> with the addition of the virtual event support, a virtual event that does not have a venue will not have a time zone... so a time zone needs to be able to be picked in the create an event...
[02:50] <pleia2> k, updated My Teams screenshot in both places, much better :)
[02:50] <mhall119> cjohnston: wrong!
[02:50] <cjohnston> and then we need to figure out how to determine if we will use the venue tz or the event tz
[02:51] <cjohnston> ty pl
[02:51] <mhall119> cjohnston: when an event doesn't have a venue, it's time will be in the timezone of the first team associated with it
[02:51] <pleia2> oh wow, the my teams page itself looks much better too
[02:51] <pleia2> I should update all these screenshots
[02:52] <mhall119> pleia2: I noticed that, yeah, was going to say something
[02:52] <cjohnston> that rocks mhall119
[02:52] <cjohnston> http://loco.ubuntu.com/events/ubuntu-us-florida/1041/detail/
[02:52] <cjohnston> there is an issue irc channel
[02:53] <mhall119> cjohnston: yeah, it's wrapped in  tags, not sure why
[02:55] <cjohnston> {% trans "Where:" %}
[02:55] <cjohnston> nm
[02:55] <mhall119> wrong line
[02:56] <cjohnston> I thought they were the same
[02:56] <cjohnston> I saw it now tho
[09:07] <head_victim> Nice work on the new loco.u.c update one and all involved.
[14:56] <mhall119> thanks head_victim
[15:21] <locodir-user> 有人不？
[15:22] <jpds> !cn | locodir-user
[15:22] <ubot4> locodir-user: 如欲獲得中文的協助，請輸入 /join #ubuntu-cn /join #ubuntu-tw 或 /join #ubuntu-hk
[18:01] <Ddpbf> hi to all
[18:01] <Ddpbf> I would like to ask few things
[18:01] <Ddpbf> we, serbian LoCo
[18:03] <Ddpbf> have requests from users to support facebook page
[18:03] <Ddpbf> Ubuntu Serbia
[18:03] <Ddpbf> afaik
[18:03] <Ddpbf> ubuntu does not have official fb page and does not promoted in oficcial manner on facebook
[18:04] <Ddpbf> what to answer?
[18:04] <Ddpbf> btw I am new owner of #ubuntu-rs irc channel
[18:07] <leoquant> linkedin maybe Ddpbf  ubuntu is present there afaik
[18:08] <Ddpbf> i saw page
[18:08] <leoquant> maybe google+ gives you more then facebook can by the way
[18:09] <pleia2> there is facebook.com/ubuntulinux that the community maintains ("official" is hard to say with community run things)
[18:09] <Ddpbf> but there is no any mention of it on any of *buntu sites
[18:09] <Ddpbf> it would be officila support
[18:09] <pleia2> and a lot of loco teams have facebook pages too (my team does)
[18:09] <Ddpbf> i said it is terra incognita for us
[18:09] <Ddpbf> ok
[18:10] <Ddpbf> so some LoCo teams does have fb pages?
[18:11] <pleia2> yes
[18:11] <pleia2> for instance: https://www.facebook.com/ubuntu.california
[18:11] <Ddpbf> and they put links to fb pages on their sites?
[18:12] <pleia2> we do
[18:12] <Ddpbf> ok
[18:12] <pleia2> every team is different though :)
[18:12] <Ddpbf> thanks for info
[18:12] <Ddpbf> i see
[18:12] <Ddpbf> :)
[18:12] <pleia2> we found it was a good way to reach out to people we might not usually find online through mailing lists and chat and things
[18:13] <Ddpbf> i guess we in serbian LoCo could be described as floss zealots
[18:13] <Ddpbf> :)
[19:21] <AlanBell> we just set up http://facebook.com/UbuntuUK


[09:46] <ogra_> ppisati, whats that about dropping arm board support ?
[09:46] <ogra_> (why dont you just leave them idle ... so people can potentially use them)
[09:50] <ppisati> ogra_: because we don't need them
[09:50] <ogra_> well, users might use them :)
[09:51] <ppisati> ogra_: if we find someone actually using them, they can send a req to turn them on again
[09:51] <ogra_> that would save them from having to roll their own
[09:51] <ppisati> ogra_: we already have enough dead crap in it
[09:51] <ogra_> heh, ok
[09:52] <rtg> ppisati, aren't these for platforms that don't support LPAE ?
[09:52] <ppisati> rtg: both of them
[09:52] <rtg> ah
[09:52] <ppisati> rtg: in the lpae case we just support calxeda and vexpress a15
[09:53] <ppisati> rtg: for the non-lpae case, we support omap3/4, imx, calxeda and vexpress
[09:53] <ppisati> if anyone is willing to support (aka test) exynos5, st, omap5, etcetc i'm happy to turn them on
[09:54]  * ogra_ thinks am43xx (beaglebone) would be more intresting than omap3
[09:54] <ogra_> omap5 devices are rare and hard to find
[09:54] <ogra_> (was born dead after omap4 was discontinued)
[09:55] <ppisati> ogra_: don;t you have an exynos5 laptop?
[09:55] <ppisati> ogra_: are you willing to test a kernel?
[09:56] <ogra_> yes as my main work machine with a highly hacked up GLES setup
[09:56] <ppisati> ah, right
[09:56] <ogra_> dont really want to risk that
[09:56] <ppisati> the GL bound...
[09:56] <ogra_> yeah
[09:56] <ppisati> :(
[09:57] <ogra_> i would have said ask hrw, but he is all fedora now
[09:57] <ppisati> fedora?
[09:57] <ogra_> EH hired him
[09:57] <ogra_> *RH
[09:57]  * ppisati thinks should ask to expense one and add exynos5 support to out generic multiplatform kernel
[09:57] <ogra_> ++
[09:57] <ogra_> you should really have a chromebook
[09:58] <ppisati> well, problem is that they were talking about a refreshment soon, so i was waiting for that to happen
[09:58] <ogra_> enoxys5 + USB 3.0  + 2GB = priceless
[09:58] <ppisati> ah, and i would go for a GL-less kernel :)
[09:59] <ogra_> my last refreshment paid for 3 ac100s and the chromebook :)
[09:59] <ogra_> (well, technically i got one ac100 for free)
[09:59] <ppisati> ogra_: i mean refreshment of the chromebook line
[09:59] <ogra_> ah
[09:59] <ogra_> not sure if they will do an arm one again
[10:00] <ppisati> http://gigaom.com/2013/05/31/new-samsung-chromebook-may-use-8-core-chip-for-power-and-performance-boost/
[10:00] <ppisati> it was all over the internet
[10:00] <ogra_> oh, then it must be true :)
[10:00] <ppisati> LOL :)
[10:00]  * ogra_ goes reading
[21:54] <anon^_^> Hi, I'm sure this topic has been discussed or covered before, I can't seem to find an answer.  Has the kernel team considered including BFQ in a kernel package? possibly in linux-lowlatency?
[22:56] <infinity> anon^_^: We build in all the mainline schedulers.  There's not much interested in pulling in out-of-tree ones, AFAIK.
[22:57] <anon^_^> inifinity, the main reason I brought it up is there are still some desktop responsiveness issues with deadline and multi-tasking
[22:57] <anon^_^> specifically when initiating and maintaining sustained file transfers
[22:58] <anon^_^> BFQ seems to handle those scenarios well and could be more suitable for desktop use
[23:01] <anon^_^> including BFQ (but not set as default), would at least allow users to switch schedulers and still maintain the use of ubuntu kernel in repo
[23:07] <infinity> Convincing zequence to pull it into lowlatency might be an easier sell.  Still, maintaining out-of-tree patches can be a pain, especially if we want to move befre BFQ upstream does (he doesn't seem to release patches against RC kernels, for instance)
[23:08] <infinity> Honestly, the best answer for everyone is, instead of evangelizing how awesome it is for years, and asking distros to carry it as a patch, get it cleaned up and in mainline.
[23:09] <anon^_^> Unfortunately, my magic wand can't make that happen, but I can petition the ubuntu kernel team
[23:09] <infinity> You could also petition upstream.  Just sayin'.


[14:26] <seb128> here there
[14:26] <seb128> is launchpad known to have trouble atm? I'm getting timeout when trying to edit bugs
[14:29] <seb128> ah, it's working again it seems


[00:00] <bdmurray> okay, I was / am considering a bug pattern
[00:21] <bdmurray> slangasek: I noticed there is no update-manager apport hook in Lucid and thought the best way to get it in there would be an SRU of update-manager.  However, I'm confused about how far behind the lucid bzr branch for update-manager is.
[00:22] <bdmurray> ah, its me
[00:22] <slangasek> mmk
[00:49] <psusi> wait... when a package is synced from debian, it's just the source right, the binaries are still rebuilt for ubuntu right?
[00:50] <micahg> psusi: correct
[01:36] <YokoZar> slangasek: What do you think of apt automatically transitioning users of amd64 packages to i386 packages on dist-upgrade if 1) the i386 is higher version, and 2) the currently used architecture is not available in any pool ?
[01:37] <YokoZar> I'm thinking of issues where we, say, delete zsnes:amd64 from the archive and the amd64 lucid user needs to be migrated to zsnes:i386.
[01:40]  * micahg debates taking an axe to zsnes
[02:02] <slangasek> YokoZar: I reserve judgement; we'd have to have a good long think about whether this is always the right thing to do
[02:04] <slangasek> YokoZar: btw, are you planning to complete the work item from https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-64bit-by-default that you accepted at UDS? (announce intentions to move to 64-bit by default)
[02:06] <infinity> YokoZar: That would fail pretty spectacularly if Packages-amd64.gz got corrupted in transit or something, leaving you with "no amd64 packages in the pool".
[02:06] <YokoZar> slangasek: infinity: Yeah I suspect we'll run into questions about manually installed debs and what if we can't figure out the "available pool" properly and so on
[02:07] <YokoZar> slangasek: ~ work items, thank you for reminding me.  I was trying to check on the work items I might have missed and for some reason I wasn't coming up in the work item tracker
[02:07] <infinity> YokoZar: I think the saner (for some value of "sane") option for now is to take it case-by-case and provide cross-arch transitional packages.
[02:08] <slangasek> YokoZar: tracker> ah, that'll be my fault for not getting the blueprint shoved along to "approved" state
[02:08] <slangasek> infinity: but you can't have a transitional package depending of a foreign package of a *specific* architecture presently, so each one of those would require a package name change
[02:08] <slangasek> which isn't pleasant
[02:08] <YokoZar> infinity: but we can't have specific arch dependencies, so the transitional package would have to be a different name than the existing package....
[02:08] <infinity> YokoZar: Not that I find the cross-arch deps particularly elegant, but they're much more fool-proof.  And the corner cases surrounding how dpkg and apt determine "availability" are many.
[02:09] <YokoZar> The uglier solution is just a big manual hard-coded list in update-manager :/
[02:09] <infinity> YokoZar: Well, the transitional package would be the old name, and it would depend on zsnes-i386, I guess?
[02:09] <YokoZar> (which doesn't work for dist-upgrade, which is why I suggested modifying the apt resolver)
[02:09] <YokoZar> infinity: right, and then we'd have to rename zsnes to zsnes-i386 :/
[02:10] <infinity> Yup.
[02:10] <infinity> I did note that it fails the elegance test.
[02:10] <infinity> But it's at least easy to spot-check for correctness.
[02:10] <YokoZar> infinity: you can look at the new wine1.4 package for a similar setup
[02:10] <infinity> The proposed apt change is immediately incorrect in several corner cases, without looking for weirder ones.
[02:10] <micahg> YokoZar: alternatively, you can fix the amd64 build so that it builds the arch specific parts if there are any
[02:11] <YokoZar> micahg: but there aren't any, zsnes is a good example because it's an i386 only package that we had a fake ia32-libs solution for in the past
[02:11] <infinity> (Out of curiosity, why would this be done to zsnes?  Does the 64-bit build not work?)
[02:11] <infinity> Oh, there isn't a 64-bit build, I see.  That seems odd, given that it's an emulator. :P
[02:11] <YokoZar> infinity: zsnes does not and will not build on amd64 ever, I think it's full of assembly code or some such.
[02:12] <infinity> Fair enough.
[02:12] <micahg> YokoZar: you can do what we did with flash, if you can get it to compile again :)
[02:12] <infinity> Still sounds like it should just be dealt with the same way flash is.
[02:12] <infinity> The same way we did flash in oneiric, that is.
[02:12] <infinity> Before we had a 64-bit one.
[02:12] <ScottK> Burn it with fire/
[02:12] <ScottK> ?
[02:13] <ScottK> Oh, that's not what you meant.
[02:13] <micahg> zsnes:amd64 depends zsnes-i386 (i386 only) which depends on zsnes:i386
[02:13] <infinity> micahg: Makes the packaging a bit more complex, since zsnes.install differs on the two arches.
[02:14] <infinity> micahg: I don't see the point in the last dependency.  Just put the binaries in zsnes-i386 and have it replace zsnes (<< pre-split-version).
[02:14] <YokoZar> micahg: yeah that would work, I suppose, but then we're left carrying two dummy packages for an indeterminate amount of time.  Especially because there's no way for zsnes:i386 to declare that it replaces and obsoletes zsnes:amd64 (and indeed apt will try to keep them in sync at the same version and complain about any change that removes empty zsnes:amd64)
[02:15] <micahg> infinity: that works too, but I hate the idea of having a zsnes-i386 package in perpetuity
[02:15] <YokoZar> infinity's solution is a bit better but leaves us with dumb names forever
[02:15] <infinity> micahg: Who cares?  Package names are often weird.
[02:15] <micahg> it's a diff from Debian
[02:15] <infinity> So, convince the Debian maintainer to do the same thing.
[02:15] <infinity> But it's not actually a large diff.
[02:15] <YokoZar> OR, we could implement specific arch relationships in control fields...
[02:16] <micahg> well, now that Debian will soon have a multiarch capable dpkg, that might be possible :)
[02:17] <YokoZar> By the way I didn't really appreciate how far ahead we were with multiarch than Debian until now.  I had been waiting for multiarch for a long time to make a proper wine64 package, and it finally got accepted today :)
[02:18] <infinity> There's a certain advantage in not having individual package maintainers, yes.
[02:18] <infinity> Downside: Lots of universe bugs go ignored.  Upside: When we want to move on something, we MOVE.
[02:25] <ScottK> infinity: Lots of Main bugs go ignored too.
[02:29] <justgord> Any ubuntu dev working groups focussed on tablets and/or wayland  ?
[05:02] <nidsub> hola, i hope there someone out there who could help me :)
[05:02] <nidsub> im sorry ,but im really new to irc
[05:02] <nidsub> should i just post my problem here?
[05:03] <nidsub> im trying to build linux kernel
[05:03] <nidsub> here is the error i get,please  point out what did i do wrong
[05:04] <nidsub> -VirtualBox:/opt/codesourcery/linux-2.6-xlnx$ make ARCH=arm
[05:04] <nidsub> mkdir: cannot create directory `include/generated': Permission denied
[05:04] <nidsub> make[2]: *** [silentoldconfig] Error 1
[05:04] <nidsub> make[1]: *** [silentoldconfig] Error 2
[05:04] <nidsub> make: *** No rule to make target `include/config/auto.conf', needed by `include/config/kernel.release'.  Stop.
[05:04] <nidsub> nidhal@nidhal-VirtualBox:/opt/codesourcery/linux-2.6-xlnx$ sudo make ARCH=arm
[05:04] <nidsub> scripts/kconfig/conf --silentoldconfig Kconfig
[05:04] <nidsub>   CHK     include/linux/version.h
[05:04] <nidsub>   UPD     include/linux/version.h
[05:04] <nidsub>   CHK     include/generated/utsrelease.h
[05:04] <nidsub>   UPD     include/generated/utsrelease.h
[05:04] <nidsub>   Generating include/generated/mach-types.h
[05:04] <nidsub>   CC      kernel/bounds.s
[05:04] <nidsub> cc1: error: unrecognized command line option ‘-mlittle-endian’
[05:04] <nidsub> cc1: error: unrecognized command line option ‘-mno-thumb-interwork’
[05:04] <nidsub> kernel/bounds.c:1:0: error: unknown ABI (aapcs-linux) for -mabi= switch
[05:04] <nidsub> kernel/bounds.c:1:0: error: bad value (armv5t) for -march= switch
[05:04] <nidsub> make[1]: *** [kernel/bounds.s] Error 1
[05:04] <nidsub> make: *** [prepare0] Error 2
[05:04] <nidsub> please :(
[05:05] <micahg> nidsub: first error is you didn't use a pastebin for that
[05:06] <micahg> as for the rest, is this on an arm system or are you cross compiling
[05:06] <nidsub> thank you :),yerp im trying to cross compile
[05:07] <nidsub> is on arm qemu
[05:08] <nidsub> here the detail on the step i took ..from this webpage
[05:09] <nidsub> http://wiki.xilinx.com/zynq-linux
[05:12] <micahg> well, this isn't a general support channel, #ubuntu-arm might be better suited
[05:12] <micahg> #ubuntu would be for general support, but I don't see this working out too well in there
[05:15] <nidsub> Thanks you so much for the tips
[07:10] <goddard> I'm trying to use debuilder but it doesn't seem to be creating my deb file although i get no errors
[07:32] <pitti> Good morning
[07:40] <Sweetshark> Morning everyone!
[07:44] <Sweetshark> http://twitter.com/#!/gregkh/status/166644258831478784 <- yay, gregkh -- of kernel fame -- contributing to LibreOffice ...
[10:00] <pitti> Daviey: mariadb> as it is 100% binary compatible, I think there is some good grounds for a FFE on this one
[10:00] <pitti> Daviey: my bigger concern there would be how much commercial backing mariadb has, i. e. whether there are stakeholders which we can believe are still active in 5 years
[10:01] <Daviey> pitti: need to discuss this in a bit. :)
[10:13] <seb128> - /usr/lib/debug/usr/lib/i386-linux-gnu/libsoup-2.4.so.1.5.0
[10:13] <seb128> + /usr/lib/debug/.build-id/5e/d483e11d8dbaff9929c94ad6b9b05a174c7685.debug
[10:13] <pitti> I noticed the new /usr/lib/debug/.build-id/ gibberish recently, too
[10:13] <seb128> is that something which changed in our toolchain (it's libsoup2.4-dbg new version)
[10:14] <pitti> I have no idea what changed there
[10:15] <seb128> hum, k
[10:15] <seb128> well I will assume it's not a bug on my side then ;-)
[10:17] <debfx> seb128: it's a new debhelper 9 behavior
[10:17] <seb128> debfx, ok, thanks
[10:18] <seb128>   * dh_strip: In v9, pass --compress-debug-sections to objcopy.
[10:18] <seb128> I guess
[10:18] <seb128> that source is v9
[10:18] <pitti> so this stuff is actually valid?
[10:18] <seb128> debian bug 631985
[10:18] <pitti> it seems a ridiculously bad design to put this in a hidden  directory
[10:19] <seb128> with useless names...
[12:06] <pitti> cking: FYI, I'm currently working on https://launchpad.net/fatrace
[12:06] <pitti> cking: as powertop seems to do a rather bad job at catching disk events (and even reports them wrongly, too)
[12:06] <pitti> cking: once it's ready and in the archive, I'll update https://wiki.ubuntu.com/Kernel/PowerManagement/IdentifyingIssues accordingly
[12:06] <cking> pitti, wow, this is excellent!
[12:07] <pitti> cking: fanotify is quite nice for this :)
[12:08] <pitti> cking: if you are interested in trying, it's in lp:fatrace; make && sudo ./fatrace
[12:08] <cking> yep, this is an excellent tool to track down these offending wakeups!
[12:08] <pitti> it has --time and --output options, and I'm going to add some filtering, too
[12:08] <pitti> cking: well, it's not process wakeups (that's powertop), just disk events
[12:09] <pitti> "f"ile "a"ccess trace
[12:09] <pitti> cking: if you want it to do something more (new option, etc.), please let me know
[12:12] <cking> pitti, does the -o option interfere with the results - i.e. it could write the output to disk and hence change the stats
[12:13] <pitti> cking: no, it ignores its own events
[12:13] <cking> sweet
[12:13] <pitti> cking: without -o, gnome-terminal touches a tempfile in /tmp/ with every output, and thus generates a feedback loop
[12:14] <pitti> -o avoids this, but I'm trying to add something more clever
[12:14] <cking> yep, I saw that and wonder what was happening
[12:14] <pitti> well /tmp tmpfs definitively helps
[12:14] <pitti> but we don't have that by default
[12:14] <pitti> cking: --ignore-pid could work
[12:15] <pitti> --ignore-path /tmp/ sounds a bit pointless
[12:15] <pitti> (but might make sense for other contexts)
[12:15] <pitti> by default it watches all "real" mounts
[12:15] <pitti> it could grow an option to only watch the mount of current cwd
[12:16] <cking> perhaps adding a timestamp to the output so we can figure out if events occur periodically may help
[12:16] <seb128> pitti, bug #928212 hate gzip hate
[12:17] <pitti> argh
[12:18] <pitti> cking: ah, good idea
[12:19] <cking> pitti, it does generate quite a bit of data on a busy machine - perhaps producing a summary sorted on the worse behaving process could be handy too
[12:20] <pitti> cking: it's not supposed to be the preferred frontend
[12:20] <pitti> cking: I have another WI to write a script that calls powertop, fatrace, and generate a report out of it
[12:20] <pitti> with worst offenders, sorted, etc.
[12:20] <cking> pitti, ah, I understand - good idea!
[12:21] <pitti> cking: I really don't want to do all this in plain C :)
[12:28] <cking> pitti, if we are going to use tools like powertop perhaps we need to ensure they work correctly - anecdotal evidence seems to tell me that some of the data may not be trustworthy
[12:28] <pitti> cking: yes, like the file accesses
[12:28] <pitti> wakeups seem to be quite reliable, though?
[12:28] <cking> and battery power consumption too
[12:29] <cking> wakeups work well as it does cater for a wide range - I looked at a specific case of wakeups and wrote eventstat to do the more focused monitoring for my testing
[12:31] <pitti> cking: pushed --current-mount option; might be useful for some finer-grained debugging
[12:32] <pitti> cking: I'll add timestamps and an --ignore-pid option still to avoid this gnome-terminal loop, but I think the rest of the filtering/reporting should happen with higher level tools
[12:33]  * cking nods - yep, makes sense
[12:34] <MacSlow> seb128, hey there... I think you'll be happier with https://code.launchpad.net/~macslow/notify-osd/fix.810325-2/+merge/91807 regarding the avg. color-tinting of the notification-bubbles
[12:34] <seb128> MacSlow, hey, let me have a look
[12:34] <MacSlow> seb128, it checks at runtime for the schema and key... if they are missing, it just falls back to the old behaviour/color
[12:35] <seb128> MacSlow, that sounds good
[12:35] <seb128> MacSlow, hum, launchpad gives and empty diff?
[12:35] <MacSlow> seb128, I'd be happy if you could review it
[12:35] <MacSlow> seb128, yeah... hold on a minute... I accidentally pushed to trunk instead of the correct branch *cough*
[12:36] <MacSlow> seb128, fixed/reverted it in trunk already... but needs some time to pick that up
[12:36] <seb128> MacSlow, ok
[12:43] <lamont> Processing triggers for libc-bin ...
[12:43] <lamont> ldconfig deferred processing now taking place
[12:43] <lamont> sh: 1: /usr/bin/gdbus: not found
[12:43] <lamont> neat
[13:00] <pitti> cking: ok, timestamps available now; -t is now -s
[13:02] <cking> pitti, \o/
[13:03] <jacekmigacz> how to prevent lightdm respawning Xorg session?
[13:03] <jacekmigacz> i'd like X once killed, stay killed
[13:07] <jacekmigacz> other words I'd like to kill,remove seat.
[13:12] <jacekmigacz> lightdm has SeatRemoved signal but no Remove seat method
[14:23] <pitti> cking: it's quite unbelievable how much disk activity chatter even my bash prompt uses..
[14:23] <cking> bashing the oxide off the platter..
[14:23] <pitti> well, my fault mostly, of course; it calls git, sed, and whatnot
[14:24] <cking> this is where we find most of the disk events are due to our tools
[14:25] <pitti> cking: I added an --ignore-pid option now, so gnome-terminal can be silenced
[14:25] <pitti> cking: from my POV this should be good enough for a first release; do you still see something major missing?
[14:25] <pitti> oh, I should document theh flags in the manpage
[14:26] <cking> pitti, lemme have one more look
[14:30] <cking> pitti, perhaps it should check it needs to be run with suitable root privilege rather than just failing with "fanotify_init: Operation not permitted"
[14:30] <pitti> I'm not actually sure which capability that is
[14:30] <pitti> CAP_SYS_ADMIN?
[14:31] <pitti> cking: doing that properly is a bit nontrivial, so I didn't so far
[14:31] <pitti> cking: uid==0 is not quite sufficient, I think
[14:31] <pitti> apparmor might restrict it, and other systems might allow it even to non-root processes
[14:31] <cking> ah, true
[14:34] <cking> pitti, its surprising how much unity-panel-service is doing really
[14:35] <pitti> cking: I'll rename 'M' to 'W' and 'A' to 'R'; that's a bit clearer IMHO
[14:35] <cking> pitti, heh, I can't valgrind the fanotify_* calls
[14:35] <pitti> valgrind?
[14:36] <cking> yeah, I run valgrind on all apps to see if they are leaky
[14:36] <pitti> I don't use any dynamic memory allocation
[14:36] <pitti> in small C programs I try not to, both to guard against leaks and also because it's more efficient
[14:37] <pitti> (not copying stuff around, etc.)
[14:37] <pitti> well, there's one strdup() for the --output argument
[14:37] <pitti> that could be freed, but it's only a single allocation
[14:37] <cking> ..just me being anal ;-)
[14:37] <pitti> but I like my global variables to be valid all the time
[14:37] <pitti> cking: right, appreciated :)
[14:38] <pitti> cking: so, valgrind doesn't know about fanotify?
[14:38] <cking> so, as for features and functionality it looks most excellent
[14:38] <cking> pitti, well, valgrind on my precise box didn't like the fanotify_init()
[14:40] <cking> goodness knows how that's implemented
[14:46] <pitti> cking: manpage updated as well now
[14:50] <jamespage> micahg, OK if I merge maven-repo-helper? a couple of bug fixes only...
[15:01] <cking> pitti, looks all good to me
[15:01] <pitti> Cannot initialize fanotify: Operation not permitted
[15:01] <pitti> You need to run this program as root.
[15:01] <pitti> cking: ^ slightly more friendly now
[15:02] <cking> pitti, yay
[15:02] <pitti> cking: ok, thanks; off to a 0.1, and packaging :)
[15:04] <pitti> cking: https://launchpad.net/fatrace -> gotta love how LP says that I released the 0.1 tarball 15 hours ago :)
[15:05] <cking> pitti, LP now a time machine too?
[15:09] <smoser> superm1, around ? i've some questions about dkms.
[15:23] <dholbach> if a new binary package gets added, do the existing packages get published after the new upload or do they all wait until the binary new package is processed?
[15:23] <pitti> dholbach: they all wait
[15:23] <dholbach> (I'm asking because of fcitx)
[15:23] <dholbach> ah ok
[15:24] <smoser> superm1, never mind. i think i got it sorted.
[15:24] <pitti> otherwise we'd end up with broken dependencies very often
[15:24] <dholbach> yeah, I guess
[15:24] <dholbach> stupid question, but I just wanted to be sure ;-)
[15:24] <pitti> cking: uploaded; now I need to bribe an archive admin to process it :)
[15:25] <dholbach> pitti, have you bribed yourself before? ;-)
[15:25] <pitti> I can't review my own stuff :)
[15:26]  * dholbach can totally see pitti go back and forth between "ok, how about I have some beer later after reviewing this stuff?", "yeah, beer would make the pain go away", "yeah, why not", "ok, deal" himself
[15:26] <pitti> dholbach: nice "sponsorship Friday" idea
[15:26]  * dholbach hugs pitti
[15:27]  * dholbach just dealt with a bunch of sync requests - we were up to 80+ earlier :)
[15:27]  * pitti hugs dholbach
[15:27] <dholbach> that's also why I asked about the fcitx one :)
[15:37]  * Sweetshark should lurk more, to be able to make grow the casual hugs into grouphugs ....
[15:46] <dholbach> seb128, Laney: to move forward with the glom story, I just uploaded a new goocanvasmm-2.0 package to https://launchpad.net/~dholbach/+archive/ppa - if you could take a look and just sponsor if it's good enough for you, I'd appreciate it :)
[15:47] <Laney> are these parallel installable?
[15:47] <seb128> dholbach, thanks!
[15:47] <Laney> also NICE
[15:47] <seb128> dholbach, will you do gdamm5 as well? ;-)
[15:50] <dholbach> seb128, on it
[15:50] <seb128> dholbach, you rock, you make me want to spend some time on the sponsoring queue ;-)
[15:50] <dholbach> seb128, uploading it right now
[15:51] <dholbach> there's something funny with a devhelp file
[15:51] <seb128> dholbach, I will not wait friday though, I'm concerned that too many people hitting on it together will lead to duplication ;-)
[15:51] <dholbach> but I think it's more important we get glom up and running and fix the other stuff later
[15:51] <Laney> has the sover changed? shver is still the same
[15:51] <dholbach> seb128, if you want to do a bit of sponsoring before - do it :)
[15:52] <dholbach> Laney, hm? it seems like no goocanvasmm-2.0 is available right now at all?
[15:52] <seb128> dholbach, right
[15:54] <Laney> well, indeed, but I think it probably wants to be 1.90
[15:54] <Laney> anyway I will have a proper look later
[15:54] <Laney> glom depends on this version now?
[15:54] <dholbach> yes
[15:54] <Laney> grand
[15:55] <dholbach> it's all in the openismus ppa
[15:55] <dholbach> I just had to make a few very very small changes
[15:55] <Laney> this neatly steps around jsogo
[15:55] <Laney> would anyone be interested in maintaining?
[15:56] <dholbach> seb128, and I are in discussions with the openismus people
[15:56] <dholbach> they maintain it in their ppa already
[15:56] <dholbach> and some time further down the line, it'd be nice if they could maintain the whole stack in ubuntu
[15:57]  * Laney will sponsor to Debian if they want it (and would consider DM at some point)
[16:25] <kelemengabor> mvo: hi, do you have time a slightly offtopic question? How does one submit a translation for upstream apt?
[16:26] <kelemengabor> I tried the BTS, without much success: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=655238
[16:28] <mvo> kelemengabor: sure, always! the debian bts is the right place, if noone has merged it  yet I can do that
[16:29] <mvo> kelemengabor: fwiw, its in debians bzr already
[16:29] <mvo> kelemengabor: just not released or taged in the bug
[16:29] <slangasek> pitti: fatrace> very nice :)
[16:30] <mvo> kelemengabor: sorry for that, there should be anohter upload to stable I guess
[16:30] <pitti> slangasek: I have a half-written blog post about it, will finish after our meeting
[16:30] <pitti> slangasek: thanks :)
[16:30] <slangasek> pitti: as far as a tool to collect the information and report it, I think 1 minute is a little too short... for me the goal is to have the disk to wake up no more than once per 10 minutes when idle
[16:30] <pitti> slangasek: it's indeed quite surprising what enormous disk chatter we have during a normal session
[16:30] <pitti> slangasek: 10 mins sounds fine
[16:30] <slangasek> well, it doesn't surprise me :/
[16:30] <slangasek> because we know we have a longstanding bug about parking cycles destroying disks
[16:31] <kelemengabor> mvo: oh, that's nice. I should read bzr logs more :). Thanks!
[16:33] <mvo> kelemengabor: well, someone should have simply told you :) so no worries
[16:37] <pitti> directhex: hey! do you know thhe status of the banshee gtk3 port?
[16:38] <directhex> pitti, i saw it demonstrated at fosdem this weekend. i'm not sure what release blockers there are, if any
[16:40] <tkamppeter> pitti, hi
[16:41] <tkamppeter> pitti, I will push CUPS 1.5.2 in some minutes, can you upload it then? Forgot to update the debian/patches/series file and so the new patches are not applied.
[16:43] <pitti> directhex: ah, thanks; nice to hear that there's good progress
[16:54] <micahg> jamespage: sure, wasn't sure if we needed it
[16:56] <tjaalton> slomo: more quiet here, so http://paste.ubuntu.com/832840/
[16:57] <tkamppeter> pitti, I have pushed up CUPS 1.5.2-2 now, can you upload it to Debian and Ubuntu? Thanks.
[16:57] <pitti> tkamppeter: ok, thanks
[17:03] <bdmurray> pitti: with regards to bug 856975 that traceback shows up in almost all ubiquity syslog files
[17:03] <pitti> it seems dbus is not running in that environment
[17:04] <pitti> I think we need to fix that
[17:06] <slangasek> pitti: seems more likely to me that this would be some sort of /run transition issue... not sure how we would've gotten that far with dbus not being started
[17:06] <pitti> anyway, I'll have a closer look in the live session (and ubiquity-only)
[17:06] <pitti> put on my todo list
[17:07] <bdmurray> thanks
[17:08] <cr3> hi folks, if I have a project mostly in Python with some C++, is it reasonable to have setup.py call make? or, should I use a Makefile instead that calls setup.py?
[17:11] <slangasek> cr3: no autoconf?
[17:11] <pitti> tkamppeter: uploaded
[17:12] <slangasek> cr3: I'm not sure one way is better than the other, anyway; both will have rough spots
[17:14] <cr3> slangasek: no autoconf, there's very little C++ and it's actually Qt code so the process is qmake + make in a small subdirectory
[17:14]  * slangasek nods
[17:18] <tkamppeter> pitti, thanks.
[17:24] <jamespage> micahg, ta
[17:52] <micahg> do I have to worry about an upgrade from a non-release version of a package in oneiric to precise?  I'm looking at ca-certificates and the only possible thing left is the conflicts on the pre-release ca-certificates-java
[18:29] <SpamapS> @pilot in
[18:35] <slangasek> micahg: I wouldn't keep transitional code from release-1-ε, no
[18:36] <micahg> slangasek: well, the rest of the code said drop after oneiric, that's part of why I'm asking
[18:36] <slangasek> not if there's a question of being in sync or something - if it's cheap to keep then meh, but in general users shouldn't expect things to work if they don't at least upgrade to the release first
[18:36] <micahg> the other part is, do we assume upgrade to release packages before upgrading to the next release
[18:36] <slangasek> *I* certainly assume that :)
[18:36] <micahg> ok, yeah, it's the only diff
[18:39] <micahg> mvo: BTW, synaptic still FTBFS in Ubuntu
[19:38] <mvo> micahg: meh, thanks! let me look
[19:39] <micahg> mvo: it seems weird, the patch applied in Debian, but not Ubunut
[19:39] <micahg> *Ubuntu
[19:40] <mvo> micahg: I also wonder why I did not get the ftbfs mail :/
[19:43] <mvo> micahg: at least I can reproduce it here, I work on it now
[19:59] <doko> micahg, did you already care about all gnat related packages?
[20:12] <SpamapS> smoser: just reviewed your patch for bug 915215
[20:13] <TiMiDo> man this sucks,
[20:15] <slangasek> SpamapS, smoser: eew?  this is rc.local, it's *supposed* to be edited by the admin
[20:15] <slangasek> packages should *never* be adding anything to it
[20:15] <SpamapS> slangasek: welcome to the world of automation
[20:16] <slangasek> why would you use *that* interface for automating anything?
[20:16] <SpamapS> slangasek: if not rc.local.d , something with a .d makes sense so users can comfortably put things there without worrying about conflicting w/ system level startup scripts.
[20:19] <SpamapS> slangasek: people use rc.local all the time in automation because it is reliable and simple to implement.
[20:19] <slangasek> SpamapS: so why not just *clobber* /etc/rc.local?
[20:19] <slangasek> it's rc.local
[20:20] <slangasek> why worry about its default contents at all?
[20:21] <slangasek> also, why is using /etc/init.d + /etc/rcN.d, or /etc/init, a practical concern?  dpkg won't overwrite any local files in these directories on package install without prompting, so even if someone does mistakenly install a package that overlaps something local, it shouldn't blow up?
[20:21] <jtaylor> doko: do you have an opinion on getting numpy 1.6 into precise before the feature freeze?
[20:22] <jtaylor> it is backward compatible with 1.5, and only 18 packages that need rebuild
[20:22] <jtaylor> debian is going to transition very soon too but probably after feature freeze
[20:22] <doko> jtaylor, no. do you want to prepare packages?
[20:23] <jtaylor> doko: I'm currently just looking for helpers and getting an overview, if people approve I'll prepare packages
[20:23] <slangasek> hallyn: bug #928432 says spice should only be enabled on 64-bit builds; can you confirm?
[20:24] <doko> jtaylor, I don't see a reason not to do that. so if you have packages for numpy, scipy, and maybe others, let me know
[20:27] <jtaylor> doko: great, I'll let you know on the progress
[20:29] <smoser> SpamapS, thank you. i dont mind it being upstart.
[20:29] <smoser> i actually went looking for you one day to read the suggested upstart script htat i put int he bug
[20:29] <micahg> doko: well, I think I've got the ada related failures fixed/sync'd, gnat is still and issue on armhf, but I was going to look at the diffs with Debian at some point
[20:29] <SpamapS> slangasek: clobbering rc.local makes sense if you have one thing influencing rc.local, but not if you have multiple things that you want to start late in the boot...
[20:29] <smoser> i backed away as it was just more intrusive.
[20:30] <smoser> i agree with SpamapS .
[20:30] <SpamapS> slangasek: and its still simpler than using /etc/init.d + update-rc.d or upstart (though upstart *does* help a lot)
[20:30] <slangasek> SpamapS: rc.local is not defined as "late in boot", it's defined as "last thing run via sysvinit" which is no longer the same thing ;)
[20:30] <hallyn> slangasek:  hm,  http://spice-space.org/faq.html
[20:30] <hallyn>  says only server isnt supported on 32bit, client is
[20:30] <smoser> slangasek, well, rc.local is back to being "relatively" late in boot
[20:31] <smoser> wel...
[20:31] <hallyn> slangasek: d'oh, so yeah
[20:31] <smoser> err.. anyway i think that is a separate issue entirely.
[20:31] <SpamapS> but the 'start on stopped rc RUNLEVEL=[2345]' is still a lot more obscure than 'echo /usr/local/sbin/dbdaemon' > /etc/rc.local.d/dbdaemon && chmod +x /etc/rc.local.d/dbdaemon
[20:31] <micahg> doko: also, wanted to ask you about the icedtea-plugin situation, it seems that there should be a breaks/replaces instead of a conflict/replaces there, just wanted to know if you did that on purpose or not
[20:32] <SpamapS> slangasek: most people define it as late in boot.. evidence that we have not documented its new place in the boot very effectively. :-/
[20:32] <smoser> well, if its not "late in boot", then really, thats a bug.
[20:32] <smoser> we re-defined it
[20:33] <smoser> (yes, i realize we did, but currenlty its *so* much better than it was in 10.04)
[20:33] <doko> micahg, there are no diffs, just a bootstrap is needed
[20:35] <micahg> doko: ah, Debian has a patch in 4.4 that lets it bootstrap from 4.6 which is built now
[20:35] <smoser> so anyway, i only proposed it and didn't upload it because i wanted to give people like slangasek the opportunity to say "yuck, no way"
[20:35] <smoser> i only decided to try it because i came across a need/desicre to run something late in boot without screwing up someone's changs to rc.local.
[20:36] <doko> micahg, neither 4.4 nor 4.6 are built on armhf
[20:36] <micahg>       gnat | 4.6ubuntu1 | precise/universe | source, amd64, armel, armhf, i386, powerpc
[20:36] <micahg> ah, it's empty :)
[20:36] <micahg> doko: ok, I don't know how to bootstrap that offhand
[20:40] <broder> SpamapS, smoser: i always thought people liked rc.local because it was cross-distro. that wouldn't be the case with rc.local.d, no? it'd be ubuntu-specific? or are other distros picking it up too?
[20:40] <smoser> broder, no. unless by coincidence
[20:43] <SpamapS> broder: I'm sure thats one reason people use it, because it is ubiquitous, elminating the need for chkconfig users to learn update-rc.d
[21:03] <smoser> SpamapS, wel... commented on post there.
[21:04] <slangasek> smoser: udev redefined it; we just made that redefinition manifest :)
[21:04] <slangasek> hallyn: I don't know which end of spice is the client or server ;)  Does that mean we need to not be building qemu-spice on 32-bit archs?
[21:05] <slangasek> SpamapS, smoser: so fundamentally, I think that having an rc.local /framework/ is something that's not the sysvinit package's job to solve
[21:06] <slangasek> rc.local is "the admin can edit it"
[21:06] <smoser> admins dont edit things any more
[21:06] <slangasek> and that editing could very well include dropping in a copy of some template that looks at /etc/rc.local.d
[21:07] <slangasek> the admin can edit it in as automated a fashion as they wish, but either way, it's not the package's problem :)
[21:07] <smoser> if rc.local.d is not the packages problem, then really, rc.local is not either. they are the same problem.
[21:07] <smoser> one is just older.
[21:07] <slangasek> yes, rc.local is an interface from the package
[21:08] <smoser> i really think that it adds a large usefulness at the cost of 2 forks in the boot
[21:08] <slangasek> any interfaces beyond that, such as a hypothetical rc.local.d, are not the problem of sysvinit
[21:08] <smoser> with, extremely low mantainence issues.
[21:08] <hallyn> slangasek: yeah i confused myself at first too :)  but yes qemu is the server, spicec or spicy is the client, so qemu-kvm-spice should not be built for 32-bit
[21:12] <smoser> slangasek, so is that a definitive "NO" ?
[21:12] <smoser> i'm willing to accept that it is.
[21:12] <slangasek> smoser: nothing is ever settled and I don't have the last word; but my opinion is firm :)
[21:13] <slangasek> this is something that's easy to design and implement without ever touching the sysvinit package
[21:13] <slangasek> because *by definition* the package won't mess with whatever changes you make to rc.local - including tweaking it to use rc.local.d
[21:14] <smoser> right. and thats fine.
[21:14] <smoser> so its easy to add
[21:14] <smoser> but its not easy to determine if modifying rc.local is going to stomp on someone else's already modified rc.local
[21:14] <smoser> so you have to assume that youc an't do that if you're trying to be a good tenant.
[21:15] <slangasek> mkdir /etc/rc.local.d; mv /etc/rc.local /etc/rc.local.d/reallylocal; echo > /etc/rc.local <<EOF.. :)
[21:15] <slangasek> and besides, I thought admins didn't edit files anymore, so why would there be anything in /etc/rc.local to preserve ;)
[21:16] <mbiebl> slangasek: /etc/rc.local.d, really? Isn't that what /etc/init.d is for...
[21:16] <hallyn> slangasek: i'm not sure offhand what the best place is to tell the pkg not to build for 32-bit...
[21:16] <slangasek> mbiebl: not my idea :-)
[21:16] <mbiebl> (I probably miss the context, so feel free to ignore me)
[21:16] <hallyn> (and i frankly find it disturbing...)
[21:16] <slangasek> hallyn: debian/control + debian/rules - build-dependencies, architecture fields, and the target can all be annotated by architecture
[21:17] <smoser> "I just want to run something late in boot". we've all come across that. mbiebl . wanting to deal with upstart or sysv init scripts and symlinks and run levels is something entierly different.
[21:17] <mbiebl> from a package pov or sysadmin?
[21:18] <mbiebl> and no, I don't think it's a good idea, fwiw
[21:19] <SpamapS> slangasek: admins don't modify files.. but they do work collaboratively on automation .. and having to first agree on the framework for rc.local.d is a barrier to system usage. If we called it '/etc/lateboot.d' and just made it a convenience dir, would that make more sense?
[21:21] <slangasek> mbiebl: /etc/rc.local.d obviously wouldn't belong in a package
[21:21] <slangasek> since it extends /etc/rc.local, which is not for packages
[21:22] <slangasek> SpamapS: again, how late is late
[21:22] <slangasek> I think this is underspecified at the moment
[21:23] <smoser> slangasek, i dont think that arguing "rc.local is unknown" is really relevant.
[21:24] <slangasek> hmm?
[21:24] <slangasek> if you want to define something that extends rc.local with rc.local.d, then obviously you'll get the same semantics
[21:25] <smoser> you stated that the time frame in which rc.local runs is unknown, which is true. but implying that something that runs right after that is therefore less valuable is i think not relevant.
[21:25] <slangasek> but I don't think rc.local is actually defined with a guarantee that it happens "at the end of boot", and if it is defined that way, the definition itself is broken thanks to event-based systems
[21:25] <slangasek> smoser: I'm saying that we shouldn't create something called "/etc/lateboot.d" without first definining what we actually mean by "late boot" and ensuring we can deliver
[21:25] <hallyn> slangasek: ok thanks, i'll try and get a fix for qemu-linaro
[21:25] <smoser> slangasek, then we should use rc.local.d because that invents nothing new.
[21:26] <smoser> it re-uses a broken definition with the same definition
[21:26] <smoser> :)
[21:26] <slangasek> smoser: if you wish :)  I'm not opposed to /etc/lateboot.d, I just think it has a prereq
[21:27] <slangasek> hallyn: I'm already elbow-deep in the package - I can take care of it if you want
[21:27] <SpamapS> Or fix rc.local to be truly "after runlevel 2 is fully started" by trying to define an event which is emitted after all things started by the transition to runlevel 2 have either changed goals back to stop or emitted 'started'
[21:28] <SpamapS> But really, I think thats orthogonal to the desire to make it easier to have non-conflicting rc.local modifications by putting in a .d directory.
[21:29] <smoser> SpamapS, i agree with that (bug so is the transition to upstart ;)
[21:29] <SpamapS> Though I have to agree that the *right* way is to have an upstart job that is start on stopped rc RUNLEVEL=[2345] .. user education on that may be harder than "look at shiny new /etc/rc.local.d"
[21:30] <mbiebl> SpamapS: the rc.local concept is broken (especially with an event based init), so I don't get why you want to extend a broken concept.
[21:31] <mbiebl> but I better just shut up now...
[21:31]  * micahg is syncing ca-certificates and crossing his fingers
[21:33] <mbiebl> SpamapS: that is rc.boot all over again...
[21:34] <hallyn> slangasek: oh, missed that - that'd be terrific, and i'll look at how you did it and learn :)  thanks
[21:35] <SpamapS> mbiebl: its crap. I agree. But its not going away. rc.local *is not* going away, ever.. busy admins without time to learn the intricate event interactions will always want to run something "late".
[21:37] <slangasek> SpamapS, mbiebl: we could certainly do away with /etc/init.d/rc.local in favor of an /etc/init/rc.local that's 'start on stopped rc [...]', in any case
[21:37] <slangasek> but that's not actually a material difference from what we currently do
[21:38] <mbiebl> SpamapS: that's the crux, what exactly is "late"? imho that just makes it easier for admins to shoot themselves in the foot
[21:43] <slangasek> mbiebl, SpamapS: right; as more jobs move to upstart, rc.local is likely to be running *before* most services have started
[21:43] <SpamapS> slangasek: indeed, thats basically a wait() call later. ;)
[21:45] <SpamapS> slangasek: so how do we simplify their life. Could we have a job which lists all of the expected events a system will receive and have that be the sync point..
[21:46] <SpamapS> actually.. hm
[21:46] <SpamapS> this is where the 'network-services' job comes in handy
[21:46] <SpamapS> if we make all things follow that, instead of runlevel 2, then we can say when it transitions to 'started', all normal network services are ready.
[21:47] <SpamapS> something to think about for 12.10 (assuming the systemd flying monkies don't carry us away)
[21:47] <slangasek> SpamapS: so jobs would be 'start on starting network-services', and rc.local would be 'start on started network-services'?
[21:50] <SpamapS> slangasek: and stopped rc RUNLEVEL=[2345]
[21:51]  * slangasek nods
[22:18] <quadrispro> eh-ehy! hi all!
[22:23] <soren> Is there anything about the (PPA) buildd's that might prevent me from readlink()ing /proc/<PID>/exe ?
[22:24] <soren> infinity: You'd probably know? ^
[22:38] <hallyn> SpamapS: perhaps i could get you to pick a good start on for libvirt?  bc i've not followed this whole conversation
[22:39] <SpamapS> start on (runlevel [2345] and stopped networking RESULT=ok)
[22:39] <SpamapS> hallyn: thats a bit explicit given 11.10+'s guarantee that all of /etc/network/interfaces will be up
[22:40] <SpamapS> hallyn: until we have the network-services job in place, runlevel [2345] is good
[22:40] <hallyn> SpamapS: so to be clear, you're saying make it jsut "start on runlevel [2345]" ?
[22:41] <SpamapS> hallyn: yes if all it requires is all network interfaces and filesystems to be up and mounted.
[22:41] <hallyn> SpamapS: thanks, put that in my "to do on next push" list
[22:51] <infinity> soren: Nope, should work fine.
[22:52] <bdmurray> um, how do you start an ssh server?
[22:52] <StevenK> sudo start ssh ?
[22:52] <infinity> (after installing it)
[22:53] <bdmurray> right and I'm still seeing 'Unknown job: ssh'
[22:53] <bdmurray> on a precise live cd
[22:53] <infinity> bdmurray: It's not on the livecd.
[22:53] <infinity> bdmurray: apt-get install ssh
[22:53] <infinity> (or openssh-server, which ssh depends on)
[22:54] <bdmurray> yes when I said right I meant I've installed openssh-server
[22:54] <bdmurray> and I see ssh in /etc/init.d/
[22:54] <infinity> So start it from init.d
[22:54] <soren> infinity: Ok, cool. Thanks.
[22:55] <infinity> Though installing it should have started it.
[22:55] <infinity> Unless you had/have no interfaces up.
[22:55] <bdmurray> how could I have installed it then?
[22:55] <infinity> Fair point. :P
[22:56] <StevenK> Via a USB key and dpkg -i :-P
[22:57] <bdmurray> with /etc/init.d/ssh start I see use service and then 'start: Unknown job: ssh' again
[22:57] <broder> "service ssh start"
[22:57] <broder> oh, on lucid you still needed to do "initctl reload-configuration"
[22:57] <broder> whenever something changed /etc/init
[22:57] <bdmurray> this is just a precise live cd
[22:58] <broder> yes, you've installed the server, but because /etc/init/ssh.conf wasn't there at bootup, upstart doesn't know about it
[22:58] <broder> so run "initctl reload-configuration" to pick up the changes
[22:58] <infinity> ... really?
[22:58] <broder> that was definitely the case with upstart for some number of releases
[22:58] <infinity> Oh, wait, does upstart rely on inotify to scan for new services?
[22:59] <RAOF> I'm *pretty* sure upstart watches /etc/init with inotify.
[22:59] <bdmurray> broder: okay that worked thanks
[22:59] <infinity> If so, overlayfs's lack of inotify support would break that.
[22:59] <broder> infinity: hahaha. yes, yes it does
[22:59] <bdmurray> great
[22:59] <bdmurray> does anybody know of a bug about that being reported yet?
[23:00] <infinity> apw: Say, have we ever escalated the important of inotify in overlayfs? :P
[23:00] <infinity> bdmurray: I think Andy has a bug, no idea what sort of movement it has.
[23:00] <infinity> apw: s/important/importance/
[23:01] <bdmurray> bug 882147 right?
[23:02] <infinity> bdmurray: Should do.
[23:39] <slangasek> hallyn: pushed my qemu-linaro changes to the UDD branch, if you want to have a gander
[23:40] <hallyn> slangasek: fetching
[23:57] <hallyn> slangasek: so will simply not building a new i386 package DTRT?  ( I was expecting to have to create an empty package to invalidate the last one)
[23:57] <hallyn> (or does it just not matter bc we're still in alpha)
[23:59] <slangasek> hallyn: oh, I would never do a transitional package for a case where the package was never meant to exist on an arch and can't be used
[23:59] <slangasek> so this DTRT in the sense that once it's published, I'll yank the i386 binary out of the archive with my AA hat on
[23:59] <hallyn> slangasek: cool :)  thanks


[02:48] <patg_> How can I get some osx icons on my do dock? Ugly icons scare me
[02:53] <holstein> patg_: gnome-do?
[02:53] <patg_> holstein: Yes :)
[02:53] <holstein> AFAIK
[02:54] <holstein> gnome-do uses your system icons
[02:54] <holstein> SO you could try different themes
[02:54] <holstein> maybe your using a theme that has non-scalable icons
[02:55] <patg_> holstein: Defualt theme for ubuntu studio
[02:55] <holstein> karmic?
[02:56] <holstein> you could try another theme easily
[02:56] <holstein> and switch back
[02:56] <holstein> see if that is the issue
[02:56] <holstein> im not sure if the ubuntusudio icons are scalable
[02:57] <holstein> should be all kinds of icons @ http://gnome-look.org/
[02:58] <holstein> http://gnome-look.org/content/show.php?content=31618
[02:58] <patg_> holstein: Can I replace them
[02:58] <patg_> Indiidually
[03:00] <holstein> hmm
[03:00] <holstein> sure
[03:00] <holstein> dont know how easy that would be though
[03:00] <holstein> ALSO
[03:00] <holstein> i prefer the AWN dock
[03:01] <patg_> holstein: Individually?
[03:01] <holstein> http://wiki.awn-project.org/
[03:01] <holstein> AWN doesnt use your system icons
[03:01] <holstein> and looks nice
[03:01] <patg_> holstein: Is it as easy as do?
[03:01] <patg_> I'm coming from osx.
[03:01] <holstein> looks more like OSX
[03:02] <holstein> and has more functionality than both -do and OSX's dock
[03:02] <holstein> it can be as easy, or easier
[03:02] <holstein> BUT you can make it do whatever
[03:02] <holstein> i havent used it in a while
[03:02] <patg_> holstein: Is it drag and drop? I thought I tried it before. And I had trouble adding things. Had to use applets or something I couldn't figure out lol
[03:02] <holstein> BUT AWN has something like stacks or whatever its called
[03:03] <holstein> OH yeah
[03:03] <holstein> i dont think so
[03:03] <holstein> BUT it has a menu you add apps with
[03:03] <holstein> and you can choose whatever icon you want
[03:03] <holstein> even a .png you make AFAIK
[03:04] <patg_> Stacks are sick. I'll give it a shot. I wish it were drag and drop though.
[03:06] <patg_> holstein: Thanks.
[03:07] <holstein> patg_: :) np
[03:07] <holstein> let me know how it goes
[03:07] <holstein> i use gnome-do
[03:07] <holstein> but not the dock
[03:08] <patg_> holstein: Will do later. Currently on my iPhone lol
[03:08] <holstein> laterz
[03:35] <Zenker> can someone tell me the formats that ubuntu will allow as background images?
[03:38] <holstein> hey Zenker
[03:38] <holstein> you mean wallpaper?
[03:38] <holstein> desktop wallpaper?
[03:38] <Zenker> yep
[03:38] <holstein> ive used jpegs and pngs
[03:39] <holstein> as far as size, you can stretch or whatever
[03:39] <holstein> might look funky though
[03:40] <Zenker> ahh, i knew of those. what im doing is trying to find a way to use a transparent background for gnome, and use the multiple background image option in compiz but still have icons drawn ...hmmm...
[03:41] <Zenker> what happens is it draws a solid color under the background. i wonder if there is a way to make that transparent
[03:43] <holstein> Zenker: COOL
[03:44] <holstein> i havenet messed with the multiple background options yet
[03:45] <holstein> i know
[03:45] <holstein> if i remove my wallpaper file from the pictures dir
[03:45] <holstein> my background truns brown
[03:45] <holstein> like thats whats going on behind it
[03:45]  * holstein shrugs
[03:46] <Zenker> yeah, the thing is for the compiz option to work u have to uncheck the draw background option, which also draws the icons, so if u do that it dosent draw the icons. . .
[03:47] <holstein> that would be a deal-breaker for me
[03:47] <holstein> i like having the USB drives show up on the desktop
[03:47] <Zenker> yep, i agree. i like the clean look myself but as u said the usb drives n others are usefull
[03:55] <Zenker> ahh i see, the transparent backgrounds work, however, for the compiz backgrounds to show u MUST disable background draw-gives background controll to compiz, so this means that the compiz backgrounds are not "under" the gnome's backgorund layers, geez. ah well
[03:56] <holstein> cool idea though
[03:58] <Zenker> but a workaround.. for this 2 work. find backgrounds u like, make pictures for icons and place those (using a pic editor) on the backgrounds then at least youll have a representation of the area of the corresponding to the icons, drawback, if the icons get moved :(
[03:58] <Zenker> i think im callin "uncle" on this one rofl
[03:58] <holstein> hehe
[03:59] <Zenker> well... i could re-write the gnome gui ...yeah right! rofl
[04:00]  * holstein puts on a pot of coffee for Zenker ... lol
[04:00] <Zenker> well have 2 see what ubuntu 10 has 2 offer when its done. hopefully they saw all the requests to seperate the icons from the backgorunds or a related suggestion
[04:01] <Zenker> have you checkout 10.4 yet?
[04:01] <holstein> im running it
[04:01] <holstein> on an EEEpc
[04:02] <holstein> got a couple installs on SD cards
[04:02] <holstein> one fresh install, and one upgrade
[04:02] <Zenker> oh, thats right, u already told me that :) did u ever get sound working?
[04:02] <holstein> AND a server install
[04:02] <holstein> running an icecast server
[04:02]  * Zenker dont know nuttin bout no servers rofl
[04:02] <holstein> Zenker: sound is fine, i still got an X crash after resmume from standby
[04:03] <holstein> i had my icecast server running on fedora
[04:03] <Zenker> what do u use a server for?
[04:03] <holstein> i was stoked to learn how to get it running in ubuntu server
[04:03] <holstein> Zenker: i use my icecast server to stream audio
[04:03] <holstein> from gigs or whatever
[04:04] <holstein> OR if im teaching someone something about theory
[04:04] <holstein> i can stream my piano to them
[04:04] <Zenker> oh cool ure a piano teacher :)) i play a little
[04:04] <holstein> cool
[04:04] <holstein> i play bass
[04:04] <holstein> upright bass
[04:05] <holstein> proffesionally
[04:05] <holstein> but i play piano to teach/learn/compose
[04:05] <holstein> just enough to be trouble ;)
[04:05] <holstein> Zenker: when are you going to upgrade to lucid?
[04:06] <holstein> i thought about doing a update-manager -d on my studio box
[04:06] <Zenker> i dl'd the iso and ran it, ,i didnt have any sound and couldnt get a connection to wireless
[04:06] <holstein> i have a laptop i like to test on first though
[04:07] <holstein> you need a restricted wireless driver?
[04:07] <holstein> broadcom or something?
[04:07] <Zenker> no its just a regular sound card umm i forget the name though
[04:07] <holstein> hmm
[04:07] <holstein> strange
[04:07] <Zenker> its onboard i have a dell laptop
[04:08] <holstein> i hope thats a bug
[04:08] <holstein> something that gets sorted out
[04:08] <Zenker> possibly, what im gonna do is install it to a flash drive so i can play with it a while, i dont have the hd space to do a 3rd os
[04:10] <Zenker> itll be cool 2 have a carry along os :) that'll really impress some of my frineds i often take my lappid over to their house to show them how 2 do stuff, when i show up with just a flash rofl
[04:11]  * Blank__ still doesnt bother with bootable usb because of incompatibility with older computers
[04:12] <Zenker> i wish i could just uninstall windows. stupid vista, but then i couldnt play some of my fav games :(
[04:12] <holstein> Blank__: i dont feel like i can haul a bootable USB stick around
[04:12] <holstein> and be prepared
[04:13] <Blank__> i could easily lug a cd or two around in my satchel thing
[04:13] <Blank__> problem is, i haven't...
[04:13] <Blank__> also another problem is that i always grab the alternate iso instead of the desktop
[04:13] <holstein> i do both, a few CD's and a USB stick
[04:13] <Zenker> idont think you can install/uninstall progs n such on a live cd.. but i guess theres a way to install it to cd ?
[04:14] <holstein> Zenker: you could roll up your own live CD
[04:14] <Zenker> maybe ill go all the way and get a portable hd w like a tb or so rofl
[04:14] <holstein> a guy in my LUG is suppose to show me how he does that soon
[04:15] <Zenker> ive herd that u can, sounds very complicated however
[04:15] <holstein> my friend says its easy
[04:15] <holstein> he does it in the CLI too
[04:15] <holstein> i was looking at remastersys
[04:16] <holstein> SUSE has an iso builder, im surprised theres not an ubuntu equivavlent
[04:18] <Zenker> what is SUSE for anyhow? i mean, how is it diff from ubuntu?
[04:19] <holstein> hmmm
[04:19] <holstein> fair question
[04:19] <holstein> i didnt find it as easy
[04:19] <holstein> personally
[04:19] <Blank__> yumm instead of apt/pkg?
[04:19] <holstein> nice distro though
[04:19] <holstein> OH yeah
[04:19]  * holstein misses apt
[04:19] <holstein> real quick
[04:20] <Blank__> i havent been able to cache rpms for opensuse, but apt-cacher works very well so thats further cemented me in debian territory
[04:20] <holstein> ubuntu repos are fast too
[04:20] <holstein> i find
[04:20] <holstein> for installing, and updating
[04:21] <Blank__> the main reason i need to cache for my entire lan is because of my internet plan
[04:21] <holstein> OH
[04:21] <Blank__> in short, i live in australia, enough said
[04:21] <holstein> a ca;
[04:21] <holstein> cap*
[04:21] <Zenker> eww ouch. i couldnt stand a slow internet connection
[04:21] <Blank__> mine is 512k/512k
[04:21] <holstein> drag
[04:22] <Blank__> we could be getting 1.5mbps for the same price though
[04:22] <Blank__> 1.5m/256k
[04:22] <holstein> and i complain about my 2meg upload ;)
[04:22] <Blank__> yep, that's the way people always are
[04:22] <holstein> hehe
[04:22] <holstein> its never fast enough
[04:22] <Zenker> i get the 3meg from charter and i still get frustrated sometimes
[04:23] <holstein> i got the 10mb from charter
[04:23] <holstein> had the 20
[04:23] <Zenker> err.. 10 meg rofl, but they say i can go all the way up 2 50 r smtin, ...at a PRICE
[04:23] <holstein> im looking for something with matching up/down
[04:23] <holstein> thats not charter
[04:23] <Blank__> i go to an adult educational facility of sorts here in aus, right, and their internet is about 75mbit down
[04:24] <Zenker> try diff dns
[04:24] <Blank__> they seem to limit single connections to 4mbit though
[04:24] <holstein> i bet thats pretty cool
[04:24] <holstein> they might throttle it
[04:24] <Blank__> yeah, i downloaded a 700MB iso in about 4 mins?
[04:24] <holstein> w00t
[04:25] <Blank__> i dont know if im going to get in trouble for grabbing isos, but hell, ive already grabbed about 3
[04:26] <holstein> they shouldnt care
[04:26] <Blank__> only problem is, they have a rather draconian proxy
[04:26] <Blank__> they block a hell of a lot of sites
[04:26] <holstein> got plenty of bandwidth to spare
[04:26] <Blank__> and in particular, specific files like the openvpn installer
[04:26] <holstein> hmmm
[04:27] <Blank__> and "file hosting sites" like megaupload/rapidshare
[04:27] <holstein> i guess some sys-admin has a reason
[04:27] <holstein> maybe when the logs are checked
[04:27] <holstein> ubuntu.com will be blocked too ;)
[04:28] <Blank__> i tried using phproxy through my server and they blocked it within 3 mins :(
[04:28] <Blank__> oh, i think ubuntu was fine
[04:28] <Blank__> i went straight to a mirror site anyway
[04:31] <Zenker> have you tried beemp3.com or torrents?
[04:31] <Blank__> nope
[04:31] <Blank__> not sure if i want to try my luck either
[04:32] <Zenker> i missed it, who did u say was blocking everything?
[04:33] <Blank__> the adult ed place i go to
[04:33] <Blank__> it's part of the whole education network
[04:34] <Zenker> ahh i see. yeah i wouldnt mess wit it either
[04:34] <Blank__> it's kinda like uni but more casual
[04:34] <Zenker> at first i ws thinking it was the government, like they do in some other places
[04:35] <Blank__> it is essentially government
[04:35] <Blank__> as in, it's part of the government's whole education system
[04:36] <Zenker> ahh but i mean like in umm i forget where, but the entire internet blocks certain sites from other countries, and they make it seriously illegal to even attempt to find a way to connect to them
[04:37] <Zenker> think it was china or japan r somewhere like that
[04:37] <Blank__> china
[04:37] <Blank__> the great firewall of china
[04:38] <Zenker> im sure at some point itll be that way everywhere, but, also im sure someone will find a way :)
[04:41] <Zenker> heay holstein, would you mind if i started a side bar with you and asked u a couple of q's about piano playing?
[04:46] <holstein> Zenker: sure
[04:47] <holstein> anytime
[19:49] <rainc> howdy. having some trouble getting jack running realtime, been sifting through forum posts
[19:50] <rainc> i'm running plain ubuntu on the realtime kernel
[19:51] <rainc> jack tells me "cannot use real-time scheduling" but i have those things set in /etc/security/limits.conf
[19:51] <rainc> rtprio, memlock, and nice
[19:52] <rainc> oh i don't have pam_limits module
[20:00] <rainc> it exists but won't load?
[20:02] <AnAnt> Hello
[20:02] <AnAnt> the ubuntustudio-plymouth-theme package is empty (except for stuff in /usr/share/doc/ubuntustudio-plymouth-theme)


[00:06] <sil2100> hm
[00:21] <sil2100> bfiller: I'll be going to sleep soon as I see no new landings/actions needed from me
[00:21] <sil2100> bfiller: if you could prepare everything so that we can get the camera-app click released tomorrow it would be great
[00:21] <sil2100> We would then build a new image
[00:31] <sil2100> If anything urgent pops up, feel free to call me on my mobile - or at least send a few signals
[00:32] <sil2100> o/
[00:32] <sil2100> See you tomorrow
[01:39] <bfiller> I will push the camera-app click to the store now
[01:47] <bfiller> popey: when you have a chance please review/approve new camera-app in store, version <IP_ADDRESS>8
[02:10] <imgbot> [03:10] <imgbot> [03:30] <imgbot> [03:30] <imgbot> [04:15] <imgbot> [04:15] <imgbot> [08:23] <Kaleo> bfiller, thanks!
[08:34] <popey> bfiller: dont
[08:34] <popey> bfiller: *done :)
[08:42] <sil2100> jibel, davmor2: hey! Once you guys are online, if you could pick up silo 004 with priority it would be awesome
[08:42] <sil2100> We would upload it to the store and kick a new image
[08:43] <jibel> sil2100, Ill do it this morning. I'm playing with SD cards and to make the scopes crash ATM
[08:46] <sil2100> jibel: thanks! btw. scopes crashing? Is there any problem with those?
[08:46] <sil2100> Ah, as per e-mail
[08:48] <jibel> sil2100, and now mtp server crashed :(
[08:50] <jibel> bug 1414570
[08:50] <jibel> cyphermox, ^
[08:54] <bzoltan> sil2100:  in the"Archive" tab of the CI sheet the line number 2428 says that the MR is landed .. but is not marked as merged. What could be the reason?
[08:54] <sil2100> bzoltan: let me check the line - you mean the merge is not marked as merged?
[08:54] <bzoltan> sil2100: and it is merged
[08:55] <ogra_> hmm, still no smoketests
[08:56] <ogra_> subprocess.CalledProcessError: Command '['bzr', 'checkout', '--lightweight', u'lp:ubuntu-calculator-app', '-r', u'339', 'work']' returned non-zero exit status 3
[08:56] <ogra_> hmm, i wonder if that "u" should be in front of the lp url
[08:56] <sil2100> bzoltan: hm, I see the merge has the 'Merged' status
[08:56] <bzoltan> sil2100:  I flipped it manually. It is OK
[08:57] <bzoltan> ogra_:  I hit the same yesterday ... the command fails when you try in terminal. It works if you do not force the revision
[08:58] <ogra_> well,, thats from the smoke test log
[08:58] <ogra_> seems something underneath changed
[09:00] <ogra_> cihelp, so while adb seems to work fine again in krillin rtm smoke tests now fetching of the tests fails in phablet-click-test-setup
[09:03] <vila> ogra_: sorry, I'm a bit lost, job url ?
[09:04] <ogra_> http://dev-jenkins.ubuntu-ci:8080/job/utopic-touch_stable-krillin-smoke-daily/778/consoleFull
[09:04] <ogra_> vila, heh, i though i'd highligth psivaa_ with cihelp :) he was on the adb case with me on the weekend
[09:05] <vila> ogra_: np, he will probably be around very soon now
[09:05] <psivaa_> ogra_:  bzr: ERROR: Requested revision: 'latest' does not exist in branch: bzr+ssh://bazaar.launchpad.net/+branch/ubuntu-terminal-app/
[09:06] <psivaa_> is the error that I see in all the runs
[09:06] <vila> psivaa_: hmpf, where do you see that in the url above ?
[09:06] <ogra_> bzr: ERROR: Server sent an unexpected error: ('error', 'ValueError', 'requested revno (339) is later than given known revno (77)')
[09:06] <ogra_> thats what i see above
[09:06] <vila> ha, damn, looked too far
[09:07] <ogra_> (install-and-boot Console log from last krillin rtm smoke run)
[09:07] <sil2100> bzoltan: what might have happened is that not all revisions from the merge branch got merged
[09:07] <psivaa_> vila: ogra_: sorry, bad cache in my browser.. that was an old error
[09:08] <ogra_> it looks like it passes the image revision to bzr for whatever reason
[09:08] <sil2100> bzoltan: it's hard to see that and find proof, but probably what happened is that CI Train built a package out of revision 330 of the branch, the package was tested and then someone pushed rev 331 (a mark commit) to the same branch which wasn't built
[09:08] <ogra_> hmm, no, it is 77 in the former testrun too
[09:08] <davmor2> sil2100: NO!
[09:08] <sil2100> bzoltan: so even after releasing the package and pushing the changes to trunk, LP doesn't think the merge is merged because it has commit 331 and it only merged up to 330
[09:09] <sil2100> davmor2: I take that as a yes
[09:09] <sil2100> :D
[09:09] <sil2100> bzoltan: anyway, nothing to be worried about in this case, it happened once for a different project (but to a bigger extreme)
[09:10] <davmor2> sil2100: NOOOOOOOOO!!!!!!!!!!!
[09:11] <sil2100> davmor2: geez Dave don't be so eager on doing it!
[09:12] <jibel> sil2100, the new gallery app is a huge improvement.
[09:12] <davmor2> people used up all their favours over the weekend no more favours now till next year :P
[09:12] <sil2100> jibel: from silo 4 you mean?
[09:12] <jibel> sil2100, yes
[09:13] <ogra_> jibel, hmm, hangs for me
[09:13] <ogra_> ah, now it moves
[09:13] <ogra_> that was a ~30sec hang
[09:13] <jibel> ogra_, how many photos/videos did you try to load?
[09:13] <satoris> For some reason mediascanner2's rtm branch has gone out of sync. lp:mediascanner2/rtm-14.09 does not have a commit that is on the device, which seems to be lp:~ps-jenkins/mediascanner2/ubuntu-vivid-proposed. How should I go about getting that fixed?
[09:15] <sil2100> satoris: let me look, maybe the bot was unable to push it there
[09:15] <ogra_> jibel, it had all my photos cached, the thumbnails were visible ... seems it scanned the videos though (but thats only ~6 short test trailers in ~/Videos)
[09:15] <sil2100> satoris: hm, wait, strange
[09:16]  * ogra_ checks his Videos dir
[09:16] <satoris> sil2100: thanks, if you need anything further just let me know.
[09:16] <jibel> ogra_, I tried with 3000 photos and 15 videos on the SD card, it takes a moment to start (few seconds) then the gallery starts displaying the thumbnails.
[09:17] <sil2100> satoris: ok, all is clear
[09:17] <ogra_> jibel, i dont have any video or photo files on the SD
[09:17] <ogra_> all local
[09:17] <sil2100> satoris: the rtm-14.09 branch is out of sync because thostr_ released the last ubuntu-rtm mediascanner2 package as a sync from vivid
[09:18] <ogra_> but i just noticed i have a *.3gp video there, could be that it choked on that
[09:18] <sil2100> satoris: so in other words it just released the vivid version of mediascanner to ubuntu-rtm - and whenever that happens, no merges are merged (bzr is not used, just the source package copied)
[09:18] <bzoltan> ogra_:  is there a chance to push out the new ubuntu-sdk-libs-tools to Vivid? Very important SDK updates are blocked by that change
[09:19] <satoris> ogra_: what does .cache/upstart/mediascanner-2.0.log say.
[09:19] <ogra_> bzoltan, yeah, sorry to much rtm stuff going on, we all worked through the weekend ... i'll get to it today
[09:19] <sil2100> satoris: to get the branch back up-to-date you would have to probably have to copy once again trunk to the 14.09 branch all up to the 0.105+15.04.20141030.1 version commit (as this is the state of the package in rtm)
[09:20] <bzoltan> ogra_: Sorry to be pushy, but can we get it now? Like not sometimes later today... I am really sorry, but I have key features collecting dust in MRs
[09:21] <ogra_> bzoltan, after the meeting, but i told you already, every core-dev can do that,. i'm not the only one
[09:21] <ogra_> there are ~100 others
[09:21] <satoris> sil2100: so if I had a new patch to put in, the correct way would be to make a branch from trunk that starts from that particular point in time, add the new commit and then MR that to trunk?
[09:21] <Kaleo> heeeeeeeeeeko
[09:21] <Kaleo> helpppppppp :)
[09:22] <nerochiaro> what Kaleo means is that we have an unit test failing with an exception in a silo, but running ok on devices and on the desktop
[09:22] <satoris> Trunk of 14/09 that is.
[09:22] <Kaleo> what he said :)
[09:22] <ogra_> satoris, funny, i dont have .cache/upstart/mediascanner-2.0.log ... only compressed files there
[09:23] <popey> ogra_: looks like calculator focus was switched to reboot from trunk...]
[09:23] <popey> which may have caused the bzr issue you linked above
[09:23] <sil2100> satoris: something like that (if I understand you correctly) - what I think needs doing is: creating a new rtm-specific branch that is based from trunk from the specyfic point of time (the version I pasted in), creating a merge with your patch for that branch and submitting it to CI Train
[09:23] <ogra_> popey, oh
[09:23] <popey> I _think_
[09:23] <ogra_> popey, can we get that fixed ?
[09:23] <satoris> sil2100: yes, exactly. Will do. Thanks.
[09:23] <popey> well, jenkins needs fixing I think...
[09:24] <satoris> ogra_: yeah sometimes that happens but nobody knows why. Maybe upstart is caching it? Do verify that the process is running, though.
[09:24] <ogra_> yup, running
[09:25] <ogra_> lots of errors in the 1.gz file
[09:25] <ogra_> and as i thought, it couldnt decode the .3gp video file
[09:25] <ogra_> oh
[09:25] <ogra_> and i seem ot have a bunch of .ts files on the SD card ... where do these come from
[09:26] <ogra_> ok, myth solved, there are broken movie files on the SD ... not sure how i got them there though
[09:39] <Chipaca> davmor2: i consider myself pung
[09:40] <davmor2> Chipaca: yeah I can't remember why though
[09:40] <Chipaca> davmor2: something about verifying silo 7?
[09:41] <davmor2> Chipaca: ah yes om26er has some logs he needs you to look at so we can pass it.
[09:41] <Chipaca> ok
[09:42] <psivaa_> ogra_: sil2100: just to make sure that you're not waiting on us on the version mismatches for calculator app, during phablet-click-test-setup
[09:42] <psivaa_> none of them are under our control
[09:42] <ogra_> psivaa_, right, see what popey said above
[09:43] <ogra_> seems the branch focus for it changed to -reboot
[09:43] <sil2100> psivaa_: I think jenkins needs to somehow stop looking for a different revision in the current trunk
[09:43] <Chipaca> davmor2: i guess i wait for om26er
[09:45] <davmor2> Chipaca: yeah I did clock that he had the logs already just that it was blocked on you.
[09:45] <psivaa_> sil2100: ogra_: ok, if that's on us, i'd like to see the job url :)
[09:45]  * Chipaca hopes it's the "are these logs ok?" "yes" kind of deal
[09:45] <psivaa_> popey: ^
[09:46] <popey> the what what?
[09:54] <popey> davmor2: http://pad.ubuntu.com/MusicAppManualTesting & http://pad.ubuntu.com/MusicAppReadMe updated with click - 2.0.814
[09:55] <davmor2> popey: ta
[10:09] <sil2100> popey: psivaa_ wanted to get the job url of the jenkins failure to fetch the right revision of calculator I think
[10:16] <popey> sil2100: I didnt find the failure, ogra_ did.
[10:25] <sil2100> pstolowski, thostr_: the rtm branch needs to have the MRs changed
[10:25] <sil2100> So that they're not the same as in the vivid landing
[10:26] <thostr_> sil2100: yes, just noticed
[10:26] <thostr_> working on it
[10:26] <sil2100> Thanks
[10:27] <nerochiaro> sil2100: not sure if you are the right person to ask to, but we need help with a package which has unit tests failing with exceptions when built by CI, but working fine when built on desktop or device
[10:28] <nerochiaro> sil2100: it is in silo 7: https://launchpadlibrarian.net/195797645/buildlog_ubuntu-vivid-armhf.camera-app_3.0.0%2B15.04.20150125.1-0ubuntu1_FAILEDTOBUILD.txt.gz
[10:29] <sil2100> nerochiaro: you saying that it builds fine locally and on the devices?
[10:29] <nerochiaro> sil2100: yes
[10:34] <sil2100> nerochiaro: out of curiosity - did you try rebuilding it in the PPA to see if it's something transient?
[10:35] <sil2100> Anyway, strange, since the builders run non-virtualized hardware
[10:35] <jibel> sil2100, Kaleo bfiller gallery-app crashes if it's open and the user removes the SD Card.
[10:35] <sil2100> So it should be more or less same as with building on a device
[10:35] <sil2100> jibel: crap...
[10:36] <nerochiaro> sil2100: i am going to test this again on the device. the build has been ran twice in the jenkins MR
[10:36] <Kaleo> jibel, excellent
[10:36] <Kaleo> jibel, that will teach these users
[10:36] <Kaleo> jibel, :)
[10:41] <nerochiaro> sil2100: hmm, retying now the build on devices with the latest image generates the same crash. I will look into it.
[10:45] <sil2100> nerochiaro: maybe something landed inbetween that started causing those issues (just a possibility)
[10:57] <jibel> bfiller, bug 1414601
[10:59] <sil2100> popey: did the reboot of the calculator get published to the store already? I mean, which calculator is the one on the devices now?
[11:00] <sil2100> Looks like the old one for me
[11:06] <popey> sil2100: the old one, the new one is "Calculator Reboot" as it's not done yet
[11:07] <sil2100> popey: so I think the switch of ubuntu-calculator-app's trunk to the reboot happened too soon
[11:07] <popey> rpadovani: ^
[11:07] <popey> rpadovani: was that a switch you flipped?
[11:07] <sil2100> popey: I think we'd need trunk to be back to the old branch for now, as otherwise phablet-click-test-setup won't work
[11:07] <popey> right.
[11:09] <nerochiaro> sil2100: it was an error in the unittest itself. i pushed to the branch a fix. the silo should pick the changes up automatically, and rebuild, right ?
[11:09] <rpadovani> sil2100, popey oh, ok. I asked to fginther and he said that was ok, but probably I didn't say we haven't published the app yet - sorry!
[11:09] <rpadovani> sil2100, do I revert the change or do you do it?
[11:10] <popey> rpadovani: could you revert for now, and we'll plan for it when we switch the app in the store.
[11:11] <rpadovani> popey, sil2100 done! sorry for the inconvenience
[11:11] <popey> thanks rpadovani :)
[11:12] <sil2100> nerochiaro: you need to rebuild the silo - let me do that for you in a moment
[11:12] <nerochiaro> sil2100: thank you
[11:12] <sil2100> rpadovani, popey: thanks, this will fix the world :)
[11:12] <rpadovani> \o/
[11:22] <mzanetti> sil2100: so seems there is still an issue with silo 14. I've tested and acked it, but it seems to still believe that some packages failed to build
[11:22] <sil2100> mzanetti: I'll look at it in a moment
[11:23] <mzanetti> sil2100: cool, thanks. no rush...
[11:38] <sil2100> Kaleo: you looking at bug https://bugs.launchpad.net/gallery-app/+bug/1414601 by any chance? :)
[11:38] <Kaleo> sil2100, a little
[11:38] <Kaleo> sil2100, but the official dev (arthur) will be on it shortly
[11:39] <Kaleo> sil2100, he needs to be awake :)
[11:46] <sil2100> ACK
[11:50] <brendand> sil2100, i just realised that i need the request_id as a dictionary key :/
[11:50] <brendand> sil2100, or some alternative
[11:50] <brendand> sil2100, which obviously needs to be unique
[11:51] <sil2100> hmmm, ok, then I'll have to make it more complicated
[11:52] <brendand> sil2100, what about assigned-silo? will click packages have one?
[11:52] <brendand> sil2100, they won't need one so i'd be surprised
[11:53] <sil2100> brendand: no they won't, and that's the problem
[11:53] <brendand> sil2100, well i need a key of some kind
[11:53] <sil2100> brendand: since all machinery in the spreadsheet assumes that is an entry has an UID and no silo assigned, it will clear out the UID after a timeout
[11:53] <sil2100> brendand: I can change that, but you know how risky it is to touch the spreadsheet mechanics ;)
[11:54] <brendand> sil2100, i do
[11:54] <sil2100> brendand: let's continue looking at this after this milestone, I don't want the train to drop dead
[11:55] <brendand> sil2100, ok any time just let me know
[12:02] <sil2100> mzanetti: eh, the silo must be busted somehow
[12:02] <sil2100> mzanetti: I mean, CI Train-wise
[12:02] <sil2100> Let my try fixing that
[12:02] <mzanetti> sil2100: that means? cleaning it and start again?
[12:03] <sil2100> mzanetti: no no, I'll try to hack it with hacks
[12:03] <mzanetti> ok. let me know if there's something I can/should do
[12:06] <sil2100> mzanetti: not sure why but the main reconfigure job no longer removes unneeded .project files, which is bad
[12:06] <sil2100> mzanetti: but I fixed it in the silo and maybe now it should be all ok
[12:06] <mzanetti> sil2100: ok, thanks. let's see how that build goes
[12:11] <pstolowski> trainguards hey, may i ask for a silo for row #55?
[12:12] <sil2100> pstolowski: ah, proper merges added? SUre
[12:12] <sil2100> jibel: since Victor went missing, after lunch someone else from the PT should be around and I'll discuss with them closing the gates
[12:13] <sil2100> And we'll announce it proper
[12:29]  * sil2100 off to lunch
[14:13] <pstolowski> trainguards hey, may i ask for a silo for #42?
[14:22] <sil2100> pstolowski: sure!
[14:33] <pstolowski> sil2100, thanks!
[14:42] <om26er> Chipaca, Hi!
[14:42] <om26er> Chipaca, I sent you the logs on friday, with the config flags you suggested. Here is the link again: https://pastebin.canonical.com/124147/
[14:43] <Chipaca> om26er: \o/ !
[14:43] <tedg> davmor2, So the url-dispatcher branch adds the feature there. There are other branches that need to land from the maps app itself.
[14:44] <tedg> davmor2, Trying to land what can land early to avoid the end of the week rush.
[14:45] <davmor2> tedg: right unfortunately there is no way to currently test it so it fails on the description of the bug alone :(
[14:45] <sil2100> bfiller: hey! Any news on bug LP: #1414601?
[14:45] <tedg> davmor2, It has automated tests included.
[14:45] <tedg> davmor2, There's no way to *manually* test it, but it is tested.
[14:46] <davmor2> jibel: ^ whats the best course of action with this ?
[14:46] <bfiller> sil2100: working on a fix, don't have an eta yet
[14:47] <Chipaca> om26er: and by that i mean: those logs are of a working client
[14:48] <om26er> Chipaca, oh, didn't get that. That sounds super cool
[14:48] <jibel> davmor2, which silo?
[14:48] <sil2100> bfiller: thanks :)
[14:48] <davmor2> jibel: silo 002
[14:49] <om26er> Chipaca, I'll make sure to run the TestPlan now and if that works ok then we can probably land it.
[14:49] <bfiller> sil2100: will keep you posted artmello working on the fix
[14:51] <jibel> davmor2, it's medium importance, no way to manually test it and the diff is not trivial. Don't land it
[14:52] <davmor2> jibel: so hold it back till the other bits land to test it manually?
[14:52] <jibel> davmor2, yes
[14:52] <davmor2> jibel: thanks
[15:00] <john-mcaleely> sil2100, just a heads up, I should have a device tarball later today (RTM)
[15:03] <om26er> Chipaca, Hey! Is this the TestPlan for push ? https://wiki.ubuntu.com/Process/Merges/TestPlan/ubuntu-push
[15:03] <om26er> only have two testcases...
[15:04] <tedg> Okay, I'll just deallocate silo 2 then: "Too much automated testing"
[15:12] <pmcgowan> john-mcaleely, whats in it?
[15:15] <john-mcaleely> factory version string changes. pmcgowan
[15:15] <john-mcaleely> (those are run-time, sadly, not just constants)
[15:15] <sil2100> john-mcaleely: hey, will we get a changelog for that?
[15:16] <sil2100> john-mcaleely: I suppose it's important to have before release, right?
[15:23] <john-mcaleely> sil2100, you will, and yes, it is
[15:24] <sil2100> jibel, davmor2: ^
[15:26] <davmor2> sil2100: I don't care :P I'm not listening, LALALALALALALALALA! I can't hear you ;)
[15:26] <sil2100> ;p
[15:26] <davmor2> john-mcaleely: when is it landing?
[15:27] <davmor2> john-mcaleely: I am knocking off at 18:00 today
[15:28] <john-mcaleely> davmor2, pushing hard to get in the next hour or so
[15:29] <davmor2> john-mcaleely: oh that'll be tight but doable
[15:35] <sil2100> jibel, pmcgowan: since the gallery-app silo still needs some love (same for camera-app), I would propose building a new image now
[15:36] <elopio> ping plars: I'm wondering why jenkins has not run for https://code.launchpad.net/~canonical-platform-qa/autopilot/unskipping_ci_test_1384957/+merge/247543
[15:36] <elopio> do you know?
[15:36] <sil2100> jibel, pmcgowan: we didn't have smoketesting results for the last images, so this would at least give us some understanding how automation fares
[15:36] <pmcgowan> sil2100, ok, did camera land in the store
[15:37] <sil2100> pmcgowan: right, but not with the low-disk-space fix, as that one is still in testing for vivis
[15:37] <plars> elopio: let me look into it, I know we have a bunch of devices down right now, so there could be a delay from that
[15:37] <sil2100> *vivid
[15:37] <sil2100> I suppose this might still take some time
[15:37] <elopio> ok, thanks.
[15:40] <jibel> sil2100, can you wait until we have an answer for location-service and may be revert it
[15:40] <sil2100> jibel: ok
[15:41] <pmcgowan> sil2100, is that music app likely to land soon?
[15:41] <pmcgowan> just wondering if we wait a few
[15:41] <sil2100> pmcgowan: it will land tomorrow, since only tomorrow it would have the translations imported
[15:41] <pmcgowan> sil2100, ok so then its just gallery in silo 4
[15:42] <sil2100> pmcgowan: yeah, gallery for today and maybe that revert of location-service (or other) as per the location problems
[15:51] <pmcgowan> jibel, I will add silo 0 to approved list as it seems it fixes a usability issue with the scopes independent of the security issues
[15:52] <pmcgowan> per innput from thostr_
[15:52] <pmcgowan> sil2100, so you will kick an image for the dashboard then?
[15:53] <sil2100> pmcgowan: I'm still waiting for some more info regarding the location-regression
[15:53] <sil2100> But if get no additional info about a possible revert I'll just request an image in ~30 minutes
[15:54] <pmcgowan> sil2100, ack
[15:54] <jibel> pmcgowan, sil2100 bug 1414610
[15:55] <jibel> pmcgowan, sil2100 it's a regression introduced by location-service, was silo 17
[15:55] <pmcgowan> jibel, question is whether there is a proper fix to the indicator thats better than a revert?
[15:56] <jibel> pmcgowan, inded
[15:56] <jibel> indeed*
[15:56] <sil2100> jibel: did brendand confirm that reverting location-service fixes the bug?
[15:57] <jibel> a revert would reintroduce the bug where the states are not remembered on reboot
[15:57] <brendand> sil2100, yeah it works
[15:57] <brendand> sil2100, but as jibel said we lose a bug fix
[15:57] <jibel> sil2100, I did, but didn't revert lxc-android-config. So the state is correct in the wizard, but the shell doesn't start
[16:01] <Chipaca> om26er: looks like the right one yes
[16:02] <plars> elopio: The job is back on and I forced it to go ahead and run now
[16:02] <elopio> plars: thank you very much.
[16:02] <plars> elopio: anytime!
[16:02] <rhuddie> popey, davmor2, I tested music-app 2.0.814, no issues from testing
[16:15] <bfiller> sil2100: can you please reconfigure ubuntu silo 7, had to add a package
[16:15] <sil2100> bfiller: sure
[16:24] <sil2100> ogra_: hey! Could you kick a new ubuntu-rtm image for us?
[16:25] <ogra_> sure
[16:25] <sil2100> It seems I still don't have the power
[16:25] <ogra_> did you talk to cjwatson ?
[16:25] <ogra_> kicked
[16:27] <popey> rhuddie: awesome, thank you!
[16:27] <sil2100> ogra_: thanks!
[16:30] <imgbot> [16:34] <om26er> Chipaca, I send the message to myself from the testplan and it says ":ERROR: invalid"
[16:34] <om26er> whats up with that ?
[16:35] <Chipaca> om26er: wrong token?
[16:36] <om26er> Chipaca, oh it worked now, I had to send it like "nickname:message" the testplan was not clear :)
[16:36] <Chipaca> om26er: ah!
[16:55] <ogra_> om26er, happy birthday !!
[16:56] <om26er> aaah, Thanks ogra_ :-)
[17:01] <bfiller> sil2100: can you reconfigure rtm silo 4. It's not longer going to be a sync silo instead we added an MR so we can land in rtm first. then I'll land it in vivid
[17:02] <popey> no landing call?
[17:03] <sil2100> bfiller: sure
[17:03] <sil2100> hmm
[17:03] <sil2100> Ok
[17:03] <ogra_> popey, we're all in
[17:04] <sil2100> bfiller: just make sure to release it on vivid after that instantly
[17:04] <popey> odd
[17:04] <bfiller> sil2100: will do, the deb is not even used so it's not too important but will make sure
[17:04] <bfiller> sil2100: only relevant for desktop
[17:05] <sil2100> ogra_, jibel: internet problems still...
[17:16] <pmcgowan> jibel, this one needs to land with other camera disk fixes https://bugs.launchpad.net/canonical-devices-system-image/+bug/1385302
[17:20] <jibel> pmcgowan, OK
[17:23] <sil2100> plars: hey! Did you just erase my topic? ;)
[17:23] <plars> sil2100: doh, sorry about that, I didn't see the change
[17:24] <sil2100> plars: how cruel!
[17:24] <sil2100> ;)
[17:24] <plars> sil2100: I'll fix it, sorry about that :)
[17:24] <plars> sil2100: better? :)
[17:24] <sil2100> Much better, phew, thanks!
[17:24] <sil2100> ;p
[17:25] <plars> sil2100: I was just trying to change the vanguard and didn't see someone changed the topic in the middle.
[17:45] <imgbot> [17:45] <imgbot> [17:47] <sil2100> robru: how are you feeling today?
[17:48] <robru> sil2100: oh not bad. just eating some breakfast and waking up
[17:48] <robru> thanks
[17:49] <robru> sil2100: managed to have a restful weekend somehow
[17:49] <kenvandine> wait times for ppc builds keep increasing :/
[17:52] <sil2100> robru: good to hear :)
[18:23] <john-mcaleely> http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-20150126-cb82dc1.tar.xz
[18:23] <john-mcaleely> http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-20150126-cb82dc1.changes
[18:23] <john-mcaleely> http://people.canonical.com/~jhm/barajas/ubuntu-rtm-14.09/device_krillin-testresults-20150126-cb82dc1.ods
[18:23] <john-mcaleely> sil2100, pmcgowan ^ device tarball
[18:23] <john-mcaleely> (rtm)
[18:24] <pmcgowan> okedoke
[18:24] <john-mcaleely> changes permit factory line tools to read the expected ubuntu release version via android properties
[18:32] <Chipaca> om26er: any news?
[18:33] <om26er> Chipaca, approved it on the trello board.
[18:33] <om26er> Chipaca, I was asked by jibel to no approve further landings unless they are super "critical"
[18:40] <Chipaca> pmcgowan: is the fix for push getting stuck "super critical"?
[18:59] <pmcgowan> Chipaca, I was not considering it so, but perhaps I misunderstand the symptom
[19:01] <pmcgowan> Chipaca, from your last comment I would say no
[19:01] <pmcgowan> we can ota
[19:03] <Chipaca> drat. but ok.
[19:04] <pmcgowan> Chipaca, whats the status of your silo?
[19:04] <Chipaca> that is: i don't disagree, but i would've liked to have realised it wasn't going to make it before, because this was a rush job for it to make it, which we're going to throw away for the "real" fix as soon as we've finished working on this one
[19:04] <pmcgowan> Chipaca, oh its approved
[19:05] <pmcgowan> Chipaca, what would you recommend given its not the "real" fix
[19:05] <Chipaca> pmcgowan: i think this is better than what's there already
[19:05] <Chipaca> pmcgowan: and i also think it's a safe diff
[19:05] <pmcgowan> Chipaca, got an mr?
[19:05] <Chipaca> that is, i consider it fairly low risk
[19:05] <Chipaca> pmcgowan: https://code.launchpad.net/~chipaca/ubuntu-push/fix-1390663-for-rtm/+merge/247328
[19:06] <pmcgowan> btw it needs approval or it wont publish
[19:06] <Chipaca> pmcgowan: it's not approved on the board afaik
[19:07] <pmcgowan> Chipaca, qa passed it but your MR is not approved
[19:08] <Chipaca> I've asked noise to +1 the MR, 1 sec
[19:08] <Chipaca> pmcgowan: done
[19:08] <Chipaca> *top* approve
[19:08] <Chipaca> 1 sec more
[19:09] <Chipaca> my mouse pointer is clicking 8 pixesl to the right today
[19:09] <Chipaca> anyway, pmcgowan, done
[19:09] <pmcgowan> jibel, ok to publish silo 7 as approved by om26er ?
[19:14] <pmcgowan> Chipaca, I expect it should land, we agreed this morning the queued highs could do so
[19:14] <Chipaca> pmcgowan: ok, thank you
[19:20] <tvoss> trainguards, can I get a silo for line 59?
[19:21] <robru> tvoss: vivid 30
[19:21] <tvoss> robru, ack & thx
[19:21] <robru> tvoss: you're welcome
[19:22] <tvoss> robru, and for line 60, please?
[19:23] <robru> tvoss: well, that was the last one. let me see if there's any idle ones I can free up
[19:24] <tvoss> robru, 60 is for rtm
[19:24] <robru> oh, heh
[19:24] <tvoss> robru, 59 is vivid, 60 is sync to rtm
[19:25] <robru> tvoss: ok rtm 2
[19:25] <jibel> pmcgowan, +1 to publish 7
[19:27] <pmcgowan> jibel, very good, seems it needs to be marked as passed
[19:28] <robru> bfiller: what's up with silo 9? hasn't moved since december 17.
[19:29] <jibel> done
[19:31] <robru> pmcgowan: k, publishing
[19:32] <pmcgowan> thanks
[19:32] <bfiller> robru: it's on hold
[19:32] <bfiller> robru: will be looking back at it soon as rtm is out
[19:33] <robru> bfiller: ah, k. thought maybe you forgot about it.
[19:33] <bfiller> pmcgowan, jibel: silo 4 is ready for testing again, fixes the SD card crash
[19:33] <bfiller> robru: you can delete if need the space
[19:33] <robru> bfiller: ah, thanks. yeah we're right out, I won' free it just now, but if anybody asks for one that'll be first on the chopping block.
[19:36] <jibel> bfiller, are you sure the link to the click package is correct? The version is the same than previous build.
[19:36] <jibel> <IP_ADDRESS>4
[19:36] <bfiller> jibel: yeah, it's not the final click (which we won't build until the changes land on trunk) but it has the fix
[19:37] <jibel> bfiller, OK thanks.
[20:20] <rsalveti> oh, no silos left for vivid
[20:20] <rsalveti> let me free the system-settings one for now
[20:33] <camako> fginther, I made a small change to : ~mir-team/+junk/mir-medium-test-runner-for-jenkins . Is this the authoritative location for it, or does it need to be deployed/copied somewhere?
[20:34] <fginther> camako, that branch is currently the authoritative location
[20:44] <robru> bfiller: once silo 7 merges I can assign it back to you for line 62.
[20:45] <bfiller> robru: ack, line 62 is for rtm though
[20:45] <bfiller> 7 was vivid
[20:45] <robru> bfiller: bah, gotta check these things before talking ;-)
[20:46] <robru> bfiller: ok, you got rtm 6
[20:46] <bfiller> robru: thank you sir :)
[20:46] <robru> bfiller: you're welcome
[21:11] <ricmm> robru: hey, could I get one for ^
[21:12] <robru> ricmm: there aren't any ;-) but there's one I can free up for you, hang on
[21:12] <ricmm> wow :) busy days
[21:12] <ricmm> thakns
[22:03] <tedg> trainguards, could I get a vivid silo for line 65 please?
[22:04] <robru> tedg: silo 27
[22:05] <tedg> robru, Great, thank you.
[22:05] <robru> tedg: you're welcome
[22:23] <jhodapp> robru, can I get a silo for line 120 please?
[22:24] <robru> jhodapp: sure can't! we are right out.
[22:24] <jhodapp> robru, bummer
[22:24] <robru> jhodapp: oh sorry, looks like one freed up. hang on
[22:24] <jhodapp> lol
[22:24] <jhodapp> :)
[22:25] <jhodapp> robru, actually line 66, my spreadsheet view was out of date
[22:25] <robru> jhodapp: k, it'll be silo 29
[22:25] <jhodapp> thanks
[22:25] <robru> jhodapp: you're welcome
[22:42] <cyphermox> oh, good :)
[22:43] <pmcgowan> awesome