=== ChanServ changed the topic of #ubuntu-uds-core-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/core-1/ - http://irclogs.ubuntu.com/2013/11/20/%23ubuntu-uds-core-1.html [13:47] Hello [13:49] spineau: hi, assuming you'll be in the hangout -> https://plus.google.com/hangouts/_/7ecpjuqe1doh2dm5butsstsudo?authuser=0&hl=en [13:49] spineau: no hurry though [13:50] hi === ChanServ changed the topic of #ubuntu-uds-core-1 to: Track: Core | CheckBox (based on PlainBox) in 14.04 | Url: http://summit.ubuntu.com/uds-1311/meeting/21988/core-1311-checkbox-rebirth/ [13:53] ara: fyi https://plus.google.com/hangouts/_/7ecpjuqe1doh2dm5butsstsudo?authuser=0&hl=en [13:56] ogasawara, thanks [14:01] hi [14:05] hello! could someone please share the hangout link with me? [14:06] roadmr: according to the url above it's : https://plus.google.com/hangouts/_/7ecpjuqe1doh2dm5butsstsudo?authuser=0&hl=en [14:06] https://docs.google.com/drawings/d/1PayxVkGOICZXlaaq1Cln0FcMW2LfiJOF-jTmIm6x79Q/edit?usp=sharing [14:07] sfeole: thanks! [14:07] roadmr: the url in above the video [14:07] :) [14:49] https://plainbox.readthedocs.org/en/latest/author/index.html [14:58] woot [14:58] great session spineau [14:59] \o/ [14:59] ogasawara, feel free to end the broadcast [14:59] spineau, thanks for the session! [14:59] ara: yep, done. thanks [14:59] great session thanks everyone === ChanServ changed the topic of #ubuntu-uds-core-1 to: Track: App Development | System framework for apps | Url: http://summit.ubuntu.com/uds-1311/meeting/22111/core-1311-app-framework/ === alex-abreu|afk is now known as alex-abreu [15:06] Hangout URL? [15:07] same question [15:09] lool: ping? if you're running the hg, can you make sure to send me the link and to zaspire as well for the cordova aspects [15:10] anybody listening? :) [15:10] lool: and alex-abreu as well obviously [15:11] Hello? The hangout URL should just be pasted into channel [15:11] Who's running this session? [15:11] ?? [15:11] ogasawara,slangasek: ^- [15:11] ? [15:11] nobody is running it it seems :) [15:11] pmcgowan: are you running it? [15:11] yeek, is there a core 1 now, I thought we only had a core 2 session this slot [15:12] ogasawara: someone stuck a non-core session in our track [15:12] KaleoF: I'm happy to lead the discussion [15:12] ogasawara: it's on the appdev track but overflowing into a core "room" [15:12] lool, sorry which? [15:12] I am on another call [15:12] ah, my bad then [15:12] pmcgowan: System framework for apps [15:12] ogasawara: can you run it? I have upstart roadmap right now [15:12] KaleoF: let's take it [15:12] https://plus.google.com/hangouts/_/76cpiq0bih9a1oa0r2ojicncv4?authuser=0&hl=en [15:12] lool, oh, sorry please carry o without me, I just logged the bp [15:12] slangasek: yep, firing up now [15:13] KaleoF: joining? [15:13] asac: joining? [15:14] cjwatson: you joining? [15:14] yes, just cleaning up from firefighting [15:14] sergiusens: you want to join? [15:15] https://plus.google.com/hangouts/_/76cpiq0bih9a1oa0r2ojicncv4?authuser=0&hl=en [15:16] * ogra_ is listening in [15:28] * ogra_ remembers that asac had an opinion aboout frameworks and support cycle too [15:29] ogra_, yeah, that's what lool is saying without giving names ;-) [15:29] ah [15:29] heh [15:30] * ogra_ is getting distracted by IRC pings [15:30] sergiusens: I did name asac! [15:30] sorry [15:40] err I have lost the hangout [15:40] did I do anything wrong? [15:42] i still see you [15:42] ogra_, he dropped off for a bit :-) [15:43] ah [15:47] lool, i think asac said he wanted to be able to support forever [15:48] * ogra_ doesnt see how thats tecnically possible ... but i know that was the desire [15:49] ogra_: right, I passed that on into the hangout [15:49] k [15:49] but I expected, this is not an universally shared opinion [15:49] yeah === ChanServ changed the topic of #ubuntu-uds-core-1 to: Track: Core | Explore ways in which we can make package builds faster | Url: http://summit.ubuntu.com/uds-1311/meeting/21971/make-it-possible-to-build-cmake-packages-with-ninja/ [16:03] https://plus.google.com/hangouts/_/7ecpj4qupqkej6sm9o4gmh48eo?authuser=0&hl=en [16:03] there doesn't appear to be a blueprint for this next session [16:06] The link should be live, please join. :) [16:07] which packages is thi sabout? [16:07] yes [16:07] Any. [16:11] -fuse-ld=gold [16:11] So isn't that solved by cross-compilation on x86? [16:11] (the slowness of ARM) [16:11] dpkg-buildflags [16:12] jtaylor, ? [16:12] DEB_MAINT_LDFLAGS_APPEND or something [16:12] assumes the package supports overriding them of course [16:20] but those are few extreme cases [16:26] doesn't it also go over the alternatives system? [16:26] hm no it doesn't [16:27] jtaylor, maybe change the dpkg-buildflags default for LDFLAGS [16:28] or upload a changed binutils to a ppa and use that one for test builds [16:33] for package build that should only be relevant if ccache is also enabled, normally compilation dwarfs the time spent in make [16:33] DEB_BUILD_OPTIONS=parallel=8 [16:35] there are examples for parsing it in the policy [16:38] you can share the cache between buildd [16:38] its useful for the stable CI tests, where the compiler doe not change often [16:39] not for ubuntu+1 main archivee builds [16:39] jtaylor, sure? at least it's something which currently is not supported [16:40] the manpage states it as supported to share cache [16:40] never tried it [16:42] its even more significant if autoreconf is used, thats even slower than configure [16:43] sure, then just start multiple buildds on one machine [16:44] documentation builds are also mostly single process [16:44] e.g. all the python doc builds [16:47] can'T load on buildds be used to get a statistic? [16:47] if only one job is run per buildd [16:53] ogasawara: feel free to close down the stream now. Thanks. === ChanServ changed the topic of #ubuntu-uds-core-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/core-1/ - http://irclogs.ubuntu.com/2013/11/20/%23ubuntu-uds-core-1.html === ChanServ changed the topic of #ubuntu-uds-core-1 to: Track: Core | Kernel Topics 14.04 | Url: http://summit.ubuntu.com/uds-1311/meeting/21990/core-1311-kernel/ [17:57] for anyone interested https://plus.google.com/hangouts/_/7ecpj63sbfnc04m21g2t72g88k?authuser=0&hl=en [18:00] ogasawara: fyi I've already closed bug #1247784. It's already enabled in trusty, the bug was just complaining about it not being enabled in the mainline builds. [18:00] Ubuntu bug 1247784 in linux (Debian) "please enable CONFIG_RT2800USB_RT3573 in kernel 3.12" [Unknown,New] https://launchpad.net/bugs/1247784 [18:01] sforshee: awesome, thanks [18:02] for any late joiners -> https://plus.google.com/hangouts/_/7ecpj63sbfnc04m21g2t72g88k?authuser=0&hl=en [18:14] +1 no gray area. that's not necessarily a +1 for either version though. [18:15] https://wiki.ubuntu.com/KernelTeam/Specs/TrustyKernelDeltaReview [18:15] just makes it easier for me to talk to partners by saying "use this versin" or "we will make a decision at this time" [18:15] (where "this time" is a specific date/milestone) [18:17] show [18:21] minus probably the pieces of imsm as you (just for me ) said [18:21] will enabling transparent anonymous huge pages by default be considered for 14.04? [18:21] currently its only madvise [18:22] ext4 should be able to mount ext[23], right? [18:22] sforshee, yeah hsould be, and that is the point of the request [18:22] sforshee: I like this theory. [18:22] sforshee, we need to benchmark it and see how well it performs [18:22] I have lots of ext3 and ext2 around so... [18:25] * cking up to check it out [18:25] keep up the good work everybody [18:26] : ) [18:27] :( [18:30] it's a wrap [18:33] jtaylor, hey sorry your Q had scrolled off the top of my window, so we missed it. feel free to come over to #ubuntu-kernel and make a case -- we don't stand on ceremony much [18:37] jtaylor: yeek, sorry we missed that [18:38] jtaylor: ogasawara@sharkbay:~/ubuntu-trusty/debian.master/config$ grep -rn "TRANSPARENT_HUGEPAGE" * [18:38] config.common.ubuntu:2170:CONFIG_HAVE_ARCH_TRANSPARENT_HUGEPAGE=y [18:38] config.common.ubuntu:6143:CONFIG_TRANSPARENT_HUGEPAGE=y [18:38] jtaylor: ^^ although I'm seeing that enabled in trusty [18:38] < moving to -kernel [18:58] slangasek, hi, who is setting up the next hangout? [18:58] janimo: bdmurray is [18:58] for core1 [18:58] thanks === ChanServ changed the topic of #ubuntu-uds-core-1 to: Track: Core | Ubuntu Touch for x86 emulator | Url: http://summit.ubuntu.com/uds-1311/meeting/22116/core-1311-ubuntu-touch-for-x86/ [19:03] hangout link? [19:04] * ogra_ twiddles thumbs [19:04] ocsOBsEp4 [19:04] bdmurray: ? :-) [19:04] secret language [19:04] http://youtu.be/4-ocsOBsEp4 [19:04] keeps the NSA out [19:04] :) [19:04] slangasek, can you join the go session on the hangout? [19:04] right, I want the hangout one :-) [19:05] yeah [19:05] but thanks anyway [19:05] tvoss_: hum, I'm running a separate call [19:05] slangasek, okay [19:05] tvoss_, was the go session moved btw? [19:05] sergiusens, nope [19:05] the hangout URL isn't super-secret (unlike previous UDSes), should just be pasted here [19:05] sergiusens: that's in client-2 [19:05] tvoss_: if doko is around (i.e., not currently having network problems), he should be there [19:05] sergiusens, don't go ... stay ! [19:05] https://plus.google.com/hangouts/_/7acpja7ujvguc5nn4l8il5e2c4?authuser=0&hl=en <- this one then? [19:05] rsalveti, yeah, I'm just sad I have a conflict with this one now :-) [19:06] sergiusens: yeah :-( [19:06] ah, perfect [19:06] whereas I originally didn't see the conflict [19:06] so I was thinking one of these sessions was moved [19:06] (mind you I might just watch the youtube stream for now) [19:06] janimo, ... [19:06] janimo, your session ... join the hangout [19:07] bdmurray: thanks [19:07] yep, sorry about that === victorp_ is now known as victorp [19:12] rsalveti: is it just question of flicking a compile flag or is there a more deep reason for it [19:12] i.e. x86 = desktop version and not optimise for mobile or something [19:12] is the streaming youtube broken for anyone else? [19:12] victorp: thing is, you can flip a switch and get either opengl or opengles, but not sure what you get is co-installable [19:13] achiang:wfm [19:13] (or just me :-/) [19:13] achiang: wfm [19:13] victorp: speaking Qt-wise [19:13] tsdgeos_uds:fair enough [19:13] cjwatson, can you come to the go on the client side session? [19:14] victorp: yeah, that's why we only have gl for desktop and gles for armhf, just because it was the easier to support it [19:14] QUESTION can you guys confirm that, only GLES for Mir? somehow Gerry told me today that EGL+OpenGL should workt oo [19:14] on the desktop [19:16] yeah, a few projects use EGL api provided by OpenGL. (there are code tutorials online on how to do that) [19:16] (we do want GLES on the virtualbox / goldfish-emulators because GLES is accelerated) [19:17] tsdgeos_uds: Mir internally uses GLES2 for compositing etc, but clients are free to use either desktop GL or ES 1.0/2.0 [19:17] alf_: ah, thanks :-) [19:19] janimo:do we know for sure that x86 android BSP provide GLES vs GL? [19:20] victorp, not sure what the emulator target provdes [19:20] AOSP 4.4 is GLES 2.0 by default, so I do not think plain GL is suppored [19:20] since the emulator runs android i would expect it to be GLES [19:21] no one from AMD or Intel in the room? :) [19:21] victorp, well, the mobile intel CPUs use PVR ... which means largely the same as maguro [19:22] (galaxy nexus) [19:22] ogra_:good point [19:22] (or pandaboard ...) [19:22] and i would expect the emulator to emulate something along these lines ... so we shold be safe [19:24] so if android/x86 supports GLES... how does that relate to the open question about GL vs GLES backend for Qt? [19:24] janimo: rsalveti ogra_ ^^ [19:24] achiang, Qt on the desktop uses GL [19:25] achiang, so there is an assumption that x86 == GL [19:25] ogra_: yes, i understand that [19:25] ogra_: but we want Qt + x86 + android to use GLES [19:25] right? [19:25] achiang, it means QT on x86 has to build for LES not GL s it does now [19:25] achiang, while the assumption for Qt in touch is Qt == GLES [19:25] achiang, we need QT on all arches to use GLES [19:25] vs Qt + x86 + desktop == GL [19:25] there is no distinction [19:26] ogra_: ok, i missed the session yesterday. what did upstream say to that yesterday? [19:26] no idea [19:26] or not upstream, but folks like scottK [19:26] i had a session i ran that conflicted [19:26] we want qt with whichever GL that is accelerated. [19:26] rsalveti:is there an impact on libhybris [19:26] achiang, well, no matter what ScottK said, there are vendors using Qt that will expect GL ... i.e. Skype as an example [19:27] most of the time it is GLES on armhf, and GL on intel. [19:27] but [19:27] achiang, it seemed it will be possible to build two sets of binaries for GL and GLES on x86 [19:27] atom itel, virtualbox/android, goldfish/qemu are GLES accerated. [19:27] janimo: oh! ok, that solves our problems then [19:27] right, we will have to maintain a fork [19:27] janimo: I think that is another one that would be good to build it and see what happends [19:27] to have both [19:27] janimo, mute yourself :-) [19:27] it would be nice, if unity8 could use EGL with OpenGL, for convergence with desktop later on. [19:27] ogra - ah [19:27] your auto mute isn't working [19:28] ogra_ you dont think that upstream would have an interest on have Qt running on x86 android in the future? [19:28] victorp, not with hybris [19:28] victorp: they have that now. but it's compile time option. [19:28] hybris is considered a hack by most upstreams [19:28] xnox:right, so not really a fork [19:29] victorp, no, but our maintenance burden [19:29] ogra_: or you meant a fork for hybris? [19:29] victorp, we will need two sets of binaries [19:29] victorp: right, ti's just at the moment we will have duplicate binary packages, e.g. qt-gl qt-gles, etc. [19:29] xnox:ack [19:29] xnox: can we get that with the same source package/ [19:29] ? [19:29] and we need to maintain the second set [19:29] achiang, yes [19:29] hybris -felt- like a hack when I MIR reviewed it. I'd love to be rid of it. [19:29] achiang: should be possible. more maintainance burden, but yes. [19:30] ogra_: xnox: in the archive, or in a PPA somewhere? [19:30] victorp: achiang: but further down the line, it doesn't look like GLES is comming to desktop (but one vendor) [19:30] sarnold , realistically , we are very far from that [19:30] sarnold, wont happen though :) [19:30] achiang: only in the archive. [19:30] achiang, in the archive indeed [19:30] xnox: ok, that works for me,thanks [19:30] xnox, maybe less main burden if we do not want to apply all fixes to two sets of sourcs? [19:30] victorp: achiang: so one day we will need unity8 on top of OpenGL for normal powerful desktops/laptops. [19:30] why would we put something we need tio support officially in a PPA [19:31] ogra_:so we dont think linhybris will be a problem porting to x86 [19:31] xnox, only if Mir supports that :) [19:31] rsalveti ^^ [19:31] ogra_: well my question (about archive) was another way of asking, "is 2 binary packages an official solution" [19:31] can people assign some people to make mir/unity8 work on top of EGL powered by OpenGL ? [19:31] victorp: nops, should work (and afaik it was already tested with x86) [19:31] delaying that work, will only bite us later. [19:32] xnox, how hard would it be to build the android package for x86 too ? [19:32] ogra_: i'll try that today. [19:32] ogra_: should be ok, unless something is not ported, then I'll come back with build failures. [19:33] k [19:33] ogra_: rsalveti: package supports dynamically additional targets =) [19:33] xnox: right [19:33] ogra_: do we need a WI for actually publishing stuff on cdimage? [19:33] (it autogenerates install files et.al.) [19:33] achiang, nahg [19:33] rsalveti: oh yeah, i want to do this with kitkat only =) [19:33] achiang, ogra_ we need WI for anything that has to be done imho [19:34] xnox: yeah [19:34] xnox: mmm... :-/ [19:34] rsalveti: you are right i think on not investing on 4.2 for x86. we want to focus on armel and do the x86 when brining up 4.4. in january or so [19:34] armhf:) [19:34] rsalveti:that sounds reasonable, I guess x86 android support must have come a long way from 4.2 :) [19:34] victorp: yeah [19:34] asac: yup [19:35] rsalveti: ogra_: do we want x86-virtualbox, or x86-goldfish, or both? [19:35] asac, well, depends how you look at it, android *is* armel ;) [19:35] rootfs is armhf [19:35] xnox: i assume goldfish if thats the thing that gives us SIM card emulation etc. :L) [19:35] asac: correct. goldfish is the same emulator as currently demoed used with armhf. [19:35] ogra_: yeah i know... didnt replace... just add :) [19:35] just kidding [19:36] :) [19:36] xnox: right. i believe we want that [19:36] asac: virtualbox is known to be much faster (native speed) [19:36] if it comes for free then i dont mind. otherwise, lets first get the "right" thing done :) [19:36] rsalveti: asac: goldfish/x86 supposedly can do kvm speed. [19:36] but that's unknown. [19:36] right [19:36] ok, [19:36] afaik google feels its super fast now [19:36] if virtualbox is removed, then goldfish only. [19:36] so i wont worry too much :) [19:38] rsalveti: ogra_: by the way goldfish i386 kernel is in the linux-goldfish already. [19:38] neat [19:38] .. [19:39] wow =) if gles finally comming to desktop, than that's great! But i don't think that's available on the desktop already. [19:39] it should be [19:39] xnox: cool [19:41] rsalveti: hm, we are building "cm_goldfish-eng" at the moment, and there is no "cm_goldfish-x86-eng" target, only the google's "full-eng" / "full_x86-eng". So some enabled needs to be done. [19:41] at adding the device tree. [19:41] xnox: did you check 4.4? [19:42] janimo: =) [19:42] rsalveti: ah, not yet. [19:42] rsalveti: do we want to move to android's "full-eng" / "full_x86-eng" builds then? [19:43] xnox: probably [19:43] xnox, it is full-eng I thik indeed [19:43] rsalveti: the cm_goldfish target was easier at the time. [19:43] rsalveti: janimo: in that case I'll need to look into switching to that one. [19:43] (needs products tweaks, et. al.) [19:46] bdmurray, you can stop the recording [19:46] thanks :) [19:46] yep [19:46] janimo: rsalveti: yeah best to move to #ubuntu-touch. [19:47] =) [19:47] thanks for the session guys [19:47] crap, did I miss it? [19:47] rsalveti: lol the "i need to follow up with the qt folks" was cut :D [19:47] did yuo discuss the CONFIG_EXT[23]=n? [19:49] psusi, it think thats not actually x86 emulator specific [19:50] bring it up tomorrow, there is a general emulator session iirc [19:50] ogra: eh? has nothing to do with emulation? [19:50] psusi: you're an hour late [19:50] psusi, though i think we actually want to keep ext2 for performance reasons (the loop mounted images are a lot faster with that) [19:50] psusi: the kernel topics session was an hour ago [19:51] oh, kernel ... [19:51] ohh shoot [19:51] we're only using ext4 now [19:51] rsalveti, sure ? [19:51] psusi: CONFIG_EXT[23]=n definatly wrong session =) this was emulator for ubuntu touch on x86 session. [19:51] * ogra_ hasnt checked ... i thought the initrd still uses ext2 [19:51] yea, I'm trying to get the ext2/3 drivers disabled in the kernel... ext4 driver will handle those filesystems instead and do a better job of it and give a smaller kernel [19:52] ogra_: oh, talking about rootfs, sorry [19:52] yeah, we dont care about that kernel :) [19:52] ;) [19:52] ours are all android based [19:52] (who cares about desktops nowadays :P ) [19:52] problem is using rw when you have an ext2 fs :-) [19:53] yeah [19:53] damn daylight savings... never can remember if I'm -4 or -5 [19:54] psusi: here's what you're looking for: http://www.youtube.com/watch?v=SrMTosj1Ikg#t=972 === ChanServ changed the topic of #ubuntu-uds-core-1 to: Currently no events are active in this room - http://summit.ubuntu.com/uds-1311/core-1/ - http://irclogs.ubuntu.com/2013/11/20/%23ubuntu-uds-core-1.html === Ursinha is now known as Ursinha-afk === Ursinha-afk is now known as Ursinha [21:51] * fabio slaps alex-abreu around a bit with a large trout