[06:28] <hackurx> please make "ubuntu pro" with ubuntu LTS + Mate desktop + compiz + Firefox + thunderbird ! This is the end of Windows XP, it's time to release a simple, light version for businesses. Follow the model of the desktop version 10.04.
[13:56] <tvoss_> slangasek, ping
[13:59]  * apw waits
[13:59] <tvoss_> apw, likewise
[14:00]  * xnox o/
[14:01] <tvoss_> apw, xnox slangasek is trying to start the hangout
[14:04] <slangasek> 'snot working so well
[14:04] <slangasek> ah, looks like it might be a pulseaudio issue of some kind; let's see if I can jumpstart it
[14:07] <slangasek> tvoss_, apw, xnox: https://plus.google.com/hangouts/_/d525b6d071a23950810c98c7af9a26800980efa1
[14:08] <slangasek> sforshee: https://plus.google.com/hangouts/_/d525b6d071a23950810c98c7af9a26800980efa1
[14:08] <tvoss_> sforshee, wanna join us?
[14:09] <sforshee> tvoss_: I doubt I'll have much to say, but if I find that I do I'll hop in
[14:09] <danjared> has the video feed started?
[14:09] <xnox> yes.
[14:10] <danjared> oh, it just started playing
[14:22] <xnox> tvoss_: try http://pad.ubuntu.com/uds-1308-foundations-1308-revocable-memory ?
[14:22] <xnox> direct, cause it works for me.
[14:30] <alecu> I can't understand the word. Is it "brace" ?
[14:32] <tvoss_> alecu, yeah, brace :)
[14:32] <tvoss_> xnox, hah, that works
[14:32] <alecu> so, will this mean that each access to this memory has to go thru userspace code to check that the memory is still available?
[14:33] <alecu> As I understand it, CPU page faults seems like a better model than checking each access in userspace
[14:34] <alecu> QUESTION: ^ (sorry, if this has been discussed, I missed the first 10 minutes of the session)
[14:38] <arges> so is this API going to be an opt-in kind of thing? For example will existing programs that use libc/malloc just have non-revocable memory?
[14:38] <alecu> perhaps it makes sense to have a list of use cases for how client side apps will use this?
[14:39] <xnox> arges: yeah, .... and getting killed by the OOM-killer
[14:39] <arges> xnox: gotcha. so the ones using revocable memory will have memory de-allocated more gracefully
[14:40] <xnox> arges: so I guess high-memory using apps will opt into "kill my caches instead of killing all of me"
[14:40] <sforshee> arges: I suspect reclaiming revocable memory would be something that the kernel would invoke at an earlier stage than OOM
[14:40] <sforshee> so OOM killer would only kick in if not enough memory could be reclaimed
[14:41] <arges> so first we try to reclaim memory, if that still doesn't work then we OOM kill
[14:41] <sforshee> that's my guess, I haven't studied the proposed implementations in detail
[14:43] <alecu> well, large sound files, and bitmaps can be memory mapped instead directly from storage, and that does not need this kind of revocable memory
[14:44] <alecu> this kind of memory needs to be somehow "rebuilt" each time
[14:45] <alecu> oh, the session finished :-(
[14:45] <slangasek> tvoss_: ^^
[14:46] <tvoss_> alecu, yeah, sorry, happy to continue it here :)
[14:46] <tvoss_> alecu, yup, the idea is that the application provides a re-init handler
[14:46] <alecu> ah, good
[14:47] <alecu> then perhaps I'm not getting the right idea on how the "braces" would work
[14:47] <alecu> but I'm happy to wait for more doc, I'll keep watching the blueprint.
[14:48] <alecu> This was a very interesting session, from my userspace POV, thanks a lot for having it!
[14:48] <tvoss_> alecu, yup
[14:48] <slangasek> alecu: the braces indicate the section where the objects are "in use" and should not be freed by the kernel out from under the app.  But outside those braces, the memory can be freed at any time, which means when *entering* the braced section, the app may need a callback to recreate the objects
[14:48] <tvoss_> alecu, thanks for your questions. and as I said: I need to have a play with the api, too :)
[14:49] <alecu> slangasek: ah, I understand it now. Thanks!
[14:57] <zyga> how do I get the hangout started, do I do it or does the track lead do it?
[14:57] <tvoss_> zyga, usually the track lead
[14:58] <zyga> thanks
[14:58] <roadmr> hey
[14:59] <seb128> hey
[14:59] <seb128> next session starts in 6 minutes
[14:59] <seb128> the hangout is open: https://plus.google.com/hangouts/_/4f360dd2df74af68b7df94cd0bb4204570efbf4a?authuser=0
[14:59] <seb128> I'm away a few minutes but don't worry, back to start the stream in 5 mins
[15:00] <zyga> roadmr, ara, spineau: ^^
[15:05] <seb128> http://youtu.be/jpd4guGqhSo
[15:05] <seb128> ^ cast url
[15:34] <bladernr> is this where I ask you to fix server? ;-)
[15:35] <bladernr> three sets: things that are server specific set for checkbox-cli, things that are desktop are set for checkbox-qt and things that apply to both to the checkbox meta package
[15:36] <bladernr> python3 stuff would be for both
[15:37] <bladernr> we could go back to where "checkbox" has jobs that are universal and checkbox-qt would have desktop jobs and checkbox-cli would have server jobs... like we used to do with cehckbox, checkbox-ready and checkbox-cert
[15:37] <ara> bladernr, why don't you join the hangout? ;-)
[15:40] <spineau> bladernr: https://plus.google.com/hangouts/_/4f360dd2df74af68b7df94cd0bb4204570efbf4a?authuser=0
[16:03] <beuno> o/
[16:03] <beuno> link?  :)
[16:03] <slangasek> shortly
[16:04] <slangasek> https://plus.google.com/hangouts/_/896ceb8c962fa06a273acfe7b451cb8cfa4a31f7
[16:07] <slangasek> https://plus.google.com/hangouts/_/896ceb8c962fa06a273acfe7b451cb8cfa4a31f7
[16:07] <slangasek> beuno: ^^
[16:07] <sergiusens> slangasek: is there room for me?
[16:07] <cjwatson> plenty
[16:08] <slangasek> sergiusens: always! don't be shy :)
[16:08] <cjwatson> we have 5
[16:09] <xnox> live \o/
[16:09] <wellsb> The session I've been waiting for
[16:09] <dholbach> previous session notes: http://pad.ubuntu.com/uds-1308-community-1308-qml-extensions
[16:10] <alecu> o/
[16:11] <cjwatson> if somebody could take notes, that would be helpful
[16:12] <beuno> alecu, how easy would it be to pass in the architecture from the scope to filter?
[16:12] <lool> joining slowly
[16:12] <alecu> beuno: from the scope to the webservice? I think it would be trivial
[16:13] <dholbach> would http://paste.ubuntu.com/6039969/ be a reasonable summary of what would need to happen to make this work generally? or can anyone else see anything that's missing?
[16:14] <alecu> dholbach: sounds reasonable, yes
[16:19] <jdstrand> fyi, evilapp might be a good realworld use case. ie, I'm waiting for what is decided here before applying for it to be in the app store
[16:19] <xnox> cjwatson: bin/x86_64-linux-gnu/hello    &     lib/x86_64-linu-gnu/libhello.so
[16:19] <jdstrand> I'm happy to work with people to test things with it
[16:20] <xnox> jdstrand: what's the evilapp?
[16:20] <xnox> jdstrand: https://plus.google.com/hangouts/_/896ceb8c962fa06a273acfe7b451cb8cfa4a31f7
[16:20] <jdstrand> xnox: it is something that makes sure that various parts of application confinement are working correctly
[16:20] <xnox> ah, ack.
[16:20] <xnox> jdstrand: your team "app" =)
[16:20] <jdstrand> I'll join if I need to. at this point I don't think I have anything to add
[16:21] <jdstrand> xnox: yes :)
[16:21] <cjwatson> xnox: e.g., yeah
[16:22] <jdstrand> lool: we already do that
[16:22] <xnox> cjwatson: note the bin/ arch qualified, which well doesn't exists in normal multiarch yet.
[16:23] <lool> jdstrand: cool
[16:23] <jdstrand> lool: we verify the arch as its declared all over. is is in the lint check
[16:23] <jdstrand> (ie, filename, DEBIAN/*, etc)
[16:23] <cjwatson> xnox: right, but that's partly due to problems that don't exist with click ($PATH)
[16:24] <xnox> true.
[16:26] <xnox> cjwatson: click mk-sbuild =)
[16:27] <beedub> sbuild chroots can persist
[16:27]  * xnox laptop arrived! =)
[16:28] <cjwatson> beedub: oh, indeed.  I think we might even be able to use sbuild or at least some of its libraries
[16:29] <cjwatson> (I have sbuild commit access)
[16:29] <beedub> cjwatson: i will have to keep that in mind :)
[16:29] <beedub> (that you have commit)
[16:30] <cjwatson> for my sins
[16:38] <doko> cjwatson, plus todos for build systems
[16:38] <doko> qmake ...
[16:38] <xnox> doko: https://plus.google.com/hangouts/_/896ceb8c962fa06a273acfe7b451cb8cfa4a31f7
[16:39] <cjwatson> doko: right
[16:44]  * sergiusens never had issues with cmake for x-compile
[16:45] <doko> if the cmake modules are cleanly written for cross builds ...
[16:45] <cjwatson> cmake modules do sometimes need some work, indeed, but that's more tractable
[16:46] <cjwatson> (a lot of them try to outsmart the compiler and turn out not to be as smart)
[16:46] <cjwatson> fixing it is often a matter of deleting code :-)
[16:46] <cjwatson> (ok, I simplify slightly)
[16:47] <xnox> doko: depends what sdk generates.... and at the moment it doesn't have it.
[16:50] <cjwatson> xnox: is what I wrote in the pad right?
[16:52] <xnox> cjwatson: yes.
[16:52] <slangasek> xnox: note that doko and tvoss_ have also been doing some work around cross-buildability of cmake projects for the daily-release stacks, please check that you're aligned with anything they're doing and we don't wind up with duplicated cmake abstractions everywhere :)
[16:52] <xnox> slangasek: ack.
[16:52] <bzoltan> http://bazaar.launchpad.net/~ubuntu-sdk-team/qtcreator-plugin-ubuntu/trunk/files/head:/share/qtcreator/templates/wizards/ubuntu/backend/
[16:53] <tvoss_> doko, did you have a chance to look at the mir cmake modules?
[16:53] <jdstrand> cjwatson: that would be via the architecture field in the manifest, or something new?
[16:53] <bzoltan> xnox: ^^^
[16:53] <xnox> bzoltan: yeap.
[16:54] <doko> tvoss_, no, not yet
[16:54] <xnox> tvoss_: slangasek: are the cross-compile cmake achievements, daily landed yet? e.g. dpkg-buildpackage -aarmhf builds stuff?
[16:55] <xnox> tvoss_: doko: are the cross-compile cmake achievements, daily landed yet? e.g. dpkg-buildpackage -aarmhf builds stuff?
[16:55] <xnox> slangasek: unping.
[16:55] <tvoss_> xnox, don't know tbh, but mir is cross-compiled for every commit
[16:55] <xnox> tvoss_: cool.
[16:55] <tvoss_> xnox, would need to check the jenkins job
[16:55] <slangasek> tvoss_: where do we find the jenkins job? :)
[16:55] <tvoss_> xnox, there are some setup scripts to bootstrap a chroot in there, too
[16:55] <cjwatson> jdstrand: probably need to extend it to be multivalued
[16:55] <xnox> tvoss_: if you can send me a link to the job, that would be nice. I suspect it might be in the other jenkins instance(s) i don't usually see =)
[16:56] <tvoss_> slangasek, if I only knew ;) somewhere in limbo :)
[16:56] <slangasek> heh
[16:56] <jdstrand> cjwatson: right, that was what I was going to mention
[16:56] <xnox>  =)))))
[16:56] <tvoss_> xnox, true
[16:56] <doko> xnox, tvoss_ is speaking about cross builds using a chroot.  the unity package itself cross builds (with a few hacks)
[16:56] <cjwatson> jdstrand: the current one is basically a placeholder which is why it's undocumented
[16:56] <slangasek> sergiusens: ^^ do you know how to find the jenkins config for the daily-release mir build?
[16:56]  * jdstrand nods
[16:56] <wellsb> If this is not available before the showdown ends, we'll need some help getting compiled apps into .click for the store.  Should be fairly easy since we can just build on device in the interim. We just need documentation for the process
[16:57] <jdstrand> yes, there is some degree of urgency due to the showdown. several people seemed to indicate wanted C++ from what I've read on the mailing list
[16:58] <jdstrand> s/wanted/wanting/
[16:58] <cjwatson> when's the end of the showdown
[16:58] <cjwatson> ?
[16:58] <jdstrand> dholbach: ^ ?
[16:59] <cjwatson> for those of us who don't religiously read the community team's many blog posts :-)
[16:59]  * cjwatson has trouble keeping up sometimes
[16:59] <wellsb> 15 Sept
[16:59] <cjwatson> hm, not completely implausible but not sure
[16:59] <cjwatson> may require some assembly
[16:59] <sergiusens> slangasek: one sec
[17:00] <jdstrand> I think it would be sufficient that if people can build locally on the target device, and that the app store can handle _armhf.click files fine, and there is documentation on how to do that, then probably ok
[17:00] <bzoltan> I like the bell
[17:00] <slangasek> :)
[17:00] <xnox> dholbach: mk-sbuild --arch armhf
[17:01] <jdstrand> some-assembly-required seems reasonable so long as it is documented :)
[17:01] <sergiusens> slangasek: http://bazaar.launchpad.net/~cupstream2distro-maintainers/cupstream2distro-config/trunk/view/head:/stacks/head/mir.cfg#L27
[17:01] <slangasek> xnox: ^^
[17:01] <wellsb> Yes, that's no problem.  We just need documentation
[17:01] <wellsb> For the structure of a .click
[17:01] <sergiusens> it's not really a config
[17:01] <jdstrand> I actually use a diffenent method. so long as its documented :)
[17:02] <xnox> bzoltan: =)
[17:02] <doko> xnox, London is not Europe ....
[17:02] <xnox> doko: ++
[17:02] <dholbach> awesome
[17:02] <jdstrand> wellsb: structure of click is not hard. put what you want to ship into a dir, cd to the dir and do 'click build .'
[17:02] <bzoltan> thanks guys
[17:02] <dholbach> thanks a bunch everyone - I'm super excited about this :-)
[17:02] <bzoltan> lots of progress, lots of work :)
[17:03] <alecu> lunch!
[17:03] <slangasek> sergiusens: "not really a config"?  well, I want to understand how the jenkins job invokes the mir build, and the goal is to minimize the amount of actual config in jenkins in favor of wrapping standard interfaces (dpkg-buildpackage) that can also be invoked locally
[17:03] <slangasek> so the less config, the better :)
[17:03] <cjwatson> and details of the structure are in click/doc/file-format.rst
[17:03] <slangasek> s/lunch/breakfast/!
[17:05] <wellsb> Good info.  Thanks
[17:05] <sergiusens> slangasek: ack, so this is piggybacking on didiers daily relase config
[17:06] <sergiusens> slangasek: xnox http://10.97.2.10:8080/view/Phablet/job/mir-autolanding/
[17:08] <sergiusens> you want to talk to fginther though, seems the setup for mir is outside of what we standarized on
[18:01] <beedub> slangasek: do you have a url yet?
[18:03] <slangasek> https://plus.google.com/hangouts/_/5fd5313ab1492f07808af88c2a452bc0118e6491
[18:04] <stgraber> slangasek: can you send me the url?
[18:04] <slangasek> stgraber: https://plus.google.com/hangouts/_/5fd5313ab1492f07808af88c2a452bc0118e6491
[18:05] <slangasek> lool: are you joining the OS updates session?
[18:06] <lool> slangasek: yes
[18:07] <dholbach> did the hangout start already?
[18:07] <lool> yes
[18:08] <dholbach> hum
[18:08] <lool> ah not the broadcastr no
[18:08] <stgraber> dholbach: nope, still off air, waiting for lool to join
[18:08] <dholbach> go go go :)
[18:12] <sergiusens> stgraber: you can phablet-flash ubuntu-system --channel daily-proposed
[18:13] <cjwatson> "if we accidentally manage to get all the tests to pass"
[18:14] <apw> cjwatson, we should call the tool that :)  iwamtgattp
[18:15] <cjwatson> catchy
[18:15] <lool> cjwatson: lol
[18:15] <stgraber> well, looking at cdimage, the last two images that passed the tests were the one from the 22nd and the 28th, there was over a dozen images built between those two :)
[18:16] <slangasek> "passed" the tests
[18:16] <stgraber> and yeah, we call the resulting channel "daily" (the current day being of around 145 hours)
[18:19] <slangasek> right - but that's a problem that needs to be solved on the quality side ASAP, at which point we will have regular updates
[18:19] <ogra_> the last few days were crazy
[18:19] <ogra_> FF pressure etc
[18:20] <slangasek> that's mostly unrelated to the ongoing test failures
[18:20] <ogra_> so some bits went in with broken tests or changed underneath their tests
[18:20] <ogra_> (many actually)
[18:20] <slangasek> a lot of those tests have been failing intermittently for weeks
[18:20] <ogra_> only the community app ones
[18:20] <ogra_> we tend to ignore these ....
[18:21] <slangasek> ... which is broken
[18:21] <slangasek> they're part of the Touch install, they need to be tested, they need to pass their tests
[18:21] <ogra_> slangasek, well, the community apps are simply on a slower (volunteer) schedule
[18:22] <slangasek> then let's pull them out of the phone
[18:22] <slangasek> if they can't keep up with the basic quality requirements
[18:22] <ogra_> not my decision
[18:22] <sergiusens> +1
[18:22]  * ogra_ will happily change whats needed 
[18:22] <ogra_> but i wont push comminuty stuff off the image :)
[18:22] <ogra_> unless i'm told so
[18:23] <slangasek> that was intended to be an outrageous strawman that you could shoot down, not a serious proposal people would agree to ;)
[18:23] <ogra_> hehe
[18:23] <slangasek> my actual point is, being "community" does not justify being held to a more lax standard
[18:23] <ogra_> it is indeed clear that the tests need fixing
[18:23] <ogra_> no but we dont hold the images back for community app breakage
[18:23] <slangasek> either they're not of a quality that should be included; or we are *collectively* responsible for making the tests pass
[18:24] <apw> slangasek, perhaps we need a touch+1-maint team
[18:24] <cjohnston> then they should be tested elsewhere
[18:24] <ogra_> they will be of the quality once we release ... might be that we included them prematurely
[18:25] <cjohnston> slangasek: IIRC there was talk at another session about changing the size of the partitions for the RO images. any idea on a timeframe for that?
[18:26] <slangasek> cjohnston: no, I hoped to have it done pre-UDS and I keep getting derailed :(
[18:26] <cjohnston> ok
[18:36] <ogra_> http://reports.qa.ubuntu.com/smokeng/saucy/touch_ro/
[18:37] <cjohnston> lool: what switch
[18:37] <lool> cjohnston: recommending ro images by default
[18:43] <alecu_lunch> group downloads is about to land on trunk, so I guess it might be on tomorrow's image
[18:45] <alecu> mandel: here
[18:48] <xnox> stgraber: dots that flash back & forth
[18:48] <xnox> =)
[18:49] <beedub> alecu, mandel: excellet
[18:57] <xnox> use hexadecimal.
[18:57] <xnox> =)
[18:57] <ogra_> octal !
[18:57] <xnox> stgraber: ^
[18:57] <xnox> also barry is not in the irc channel =((((
[18:58] <xnox> but then you will have shadow effect, as a few existing numbers have been already used in the 201308* space =)
[18:59] <apw> stgraber, you need an epoch
[19:00]  * ogra_ throws stuff at apw 
[19:00] <apw> ogra_, tell me they are cookies and tins of beer
[19:00] <ogra_> you said the evil word !