=== chriadam|away is now known as chriadam === LarrySteeze is now known as LarrySteeze|Away === SkavenXXI is now known as SkavenXXI-[OFF] [02:18] hello all [02:19] Can anyone tell me if the nexus 4 has any issues being detected on a phablet-flash -b ? [02:20] mine shows as a 'unsupported device, autodetect dails device' [02:21] should work [02:21] I believe there is just the one model world wide [02:22] yep - Model Nexus 4 Ver 4.2.2 [02:22] this one seems to be running AOKP [02:23] shouldn't matter. [02:23] you can just flash via recovery [02:24] hi! there i way i can change the OS of my android phone into Ubuntu Mobile? [02:24] do you mean a manual install from here: https://wiki.ubuntu.com/Touch/Install [02:25] yup [02:25] just download, adb push to /sdcard/autodeploy.zip [02:25] I just did it as we speak :) [02:25] ack. it's being pushed to /sdcard/ now. [02:25] should work :) [02:25] boydoy, which android? [02:26] im using o+ 8.52 [02:26] its that ok to change [02:26] no idea what that is, but check this ported list here: https://wiki.ubuntu.com/Touch/Devices [02:26] and ubuntu they have also like google play [02:27] i can download a free games [02:27] boydoy, not yet, the os is still in developer preview mode [02:27] about half a year from regular user interaction. [02:27] ahh ok.. but if ever i try they have a way i can back to original OS? [02:28] I don't see why not [02:28] :) [02:35] wow - how large is the armhf? [02:35] still pushing. [02:37] takes me like 3-4 minutes [02:37] I did raring which is 523M [02:43] still pushing. [03:18] Robby - still here? [03:19] I did the armhf push to /sdcard/autodeploy.zip and did the reboot recovery.... as per the wiki. [03:20] I'm in the recovery project menu. If I reboot, I go back to the AOKP android OS. Is there a step I'm missing? [03:20] oh duh/.... [03:26] that did it - It's loaded. [03:27] that;s a big flash... [03:27] hmmm.... i have the wallpaper - but phone is unresponsive.... [03:28] CimmerianX: swipe from the left or right edge in to the center [03:29] oic === DrCode_ is now known as DrCode [03:29] ALL the way to the center [03:31] well, no, but "to the center" it easier that "a little way in from the left for the launcher, follow through for the Apps lens, swipe from the right a little to peak at the next window, follow through to switch to it" [05:15] hi all [05:15] dose ubuntu-tuch have support for samsung s3? [05:48] hi ppl [05:48] i have a droid razer m ,and i been working on getting full ubuntu installed on it but i need some help [05:50] dose ubuntu touch support in samsung s3? [05:50] so is there anyone that can help [05:50] yes it dose [05:50] just need to get the driver stacks for ur hardware [05:50] stacks cdma gsm wifi cpu gpu and etc [05:53] drcode what arm do u have [05:53] v6-v7? [05:59] so the droid razer m running ubuntu ,but i wanna get the full ubuntu on my test phone [06:17] lool: hate to ask, but I don't find a trace of the new ubuntu-ui-toolkit upload, in queues or elsewhere in LP [06:30] Mirv: it's in the unapproved queue [06:30] Mirv: https://launchpad.net/ubuntu/raring/+queue?queue_state=1&queue_text= [06:31] Mirv: you probably need to talk on #ubuntu-release to get it in [06:31] didrocks: oh, funny, I thought I checked that but apparently I was in a different section [06:32] Mirv: maybe you check NEW? [06:32] probably.. [06:38] didrocks: that getting raring is btw the only remaining part I know of required to have the different aspects of the documentation being wrong fixed [06:38] in both web and archives [06:38] Mirv: oh, even the tutorial? excellent! [06:39] didrocks: I'm not sure if dpm has updated everything yet, but at least from my point of view the package/trunk is fixed and the other things are on the move by michael and david [06:39] ok [06:39] great ;) [06:40] didrocks, Mirv, on it, sorry for the delay. The documentation is up to date, the tutorial I'm working on [06:41] dpm: great! the important thing IMHO was identifying what things needed to be fixed and where. [06:44] good morning [07:37] mhall119, lol [08:15] fginther: is there a way to know if the jenkins autolanding system is back online? [08:20] didrocks: so, a follow-up to the topic of integration tests for qtubuntu-camera, as I had a quick chat with gusch [08:21] didrocks: right now there are no real plans for introducing explicit integration tests for that package, but what we could theoretically do is to install and execute camera-app integration tests for qtubuntu-camera [08:21] As those are practically doing the integration testing [08:21] sil2100: so similar to what we've done for indicators up to now? [08:23] sil2100: they are both on the same stack already, so integration tests will be run and everything will be in or rejected :) [08:25] sil2100: gallery-app FTBFS in the daily-build-next ppa, so not integration tests will be run, mind having a look? [08:36] ACK [08:39] tmoenicke: hey Thomas, would you mind reviewing/testing https://code.launchpad.net/~osomon/webbrowser-app/addressbar-behind-osk/+merge/159382 ? [08:40] oSoMoN: checking [08:40] thx [08:42] oSoMoN: great thx [08:42] oSoMoN: is it invisible? [08:43] tmoenicke: I was hoping you could test on your device(s), but yes, in theory the address bar is not visible below the osk anymore [08:43] oSoMoN: i will test it [08:44] thx [08:48] didrocks: hm, it seems that python -c "from distutils.sysconfig import get_python_lib; print get_python_lib()" returns none in the PPA during the gallery-app build? [08:49] didrocks: python should be already on the chroot, right? [08:49] Maybe we need a dep [08:50] sil2100: no, it's not part of the chroot [08:50] contrarly to CI that adds some deps for nothing unfortunately :/ [08:51] So ok, I think the dep needs to be added ;p [08:51] sil2100: yep, nice catch! :) [08:51] sil2100: btw, how did you spot it from the logs? /me curious [08:52] didrocks: I checked that it said no DESTINATION is given, while the DESTINATION is ${PYTHON_PACKAGE_DIR} in this case, which is fetch through execute_process and the python command in the CMakeLists.txt file [08:53] sil2100: interesting, nice work :) [08:55] https://code.launchpad.net/~sil2100/gallery-app/build_dep_on_python/+merge/159570 [08:55] brb in a moment [09:52] sil2100: I'm rerunning gallery-app and the app stack build === SkavenXXI-[OFF] is now known as SkavenXXI [10:10] hi all [10:10] any support for samsung galaxy s3 or only nexus? [10:11] !devices | DrCide [10:11] DrCide: You can find the full list of devices, official images, community images, and works in progress at https://wiki.ubuntu.com/Touch/Devices [10:11] DrCode: check the link to see if your device is supported [10:11] I realylike to test ubuntu-tuch [10:12] dose ubuntu0tuch come with all pkgs in ubuntu [10:12] DrCode: The S3 international is not supported...but there are version for verizon I think [10:12] like aircrack-ng? [10:12] I see [10:12] DrCode: not sure. [10:12] what I love in s3 is that I can use microsd [10:12] didn't found it in nexus [10:13] DrCode: I have a S3 international as well, but not supported yet :( [10:13] when a stable release will be of ubuntu-tauch? [10:13] I see [10:13] I realy love this mobile [10:13] DrCode: the beta should be available this october hopefully... [10:14] wow, nice [10:14] DrCode: I think they are targetting first quarter of 2014 for final release [10:14] it will be very intersting [10:14] DrCode: You can already try out some core apps like calendar, clock, calculator, facebook etc on your computer [10:14] dose thay plan to support most devices? [10:15] or only spcifics? [10:15] Officially canonical are supporting the nexus devices, but the community or any one can port to any device you want. [10:15] ok [10:16] mardy: you about? [10:16] excuse === Neo is now known as Guest13130 [10:17] does ubuntu touch support restoring your old android ? [10:17] on HTC Desire hd or htc one x [10:17] ? [10:30] didrocks: hmmm, my branch with the explicit list of packages was merged, right? Since I see that the hud stack generic job failed because of extra packages wanting to be installed [10:31] Was all correctly deployed? === ara_ is now known as ara [10:32] sil2100: yeah, it's in and deployed [10:32] sil2100: the stacks are running with those now [11:11] didrocks: in what moment is the packages list used? You once said it's being used as a comparison table - that if an extra package is installed and not in the packages list, the warning gets emitted, right? [11:12] sil2100: indeed, it's when we install the machine which will run autopilot [11:12] didrocks: is there an easy way to check what 'packages' were in the config during a generic build that has been fired? [11:13] In the packages parameter? [11:13] Since it looks as if it was ignoring all the packages we put there recently : [11:13] :| [11:13] sil2100: what are you looking at exactly? [11:15] didrocks: http://10.97.0.1:8080/job/ps-generic-autopilot-release-testing/98/label=autopilot-ati/console [11:16] sil2100: yeah, I told you to discare those and looking at what we are going to run :) [11:16] sil2100: so run 102 for instance [11:16] I redeployed this morning [11:16] Ah, so there's no up-to-date results right now ;p? [11:17] I think I misunderstood and thought that since you re-deployed in the morning, those should he the 'latest' [11:17] Ok, so I go back to my HUD-hunting then [11:21] sil2100: not yet :) [11:21] sil2100: yep ;) [11:25] hmm [11:25] * sil2100 wonders how we got that test passing for armhf in HUD in the past [11:29] sil2100: was it passing when we were building with the platform api? [11:34] didrocks: not sure now, maybe you're right and it never did - need to poke the platform-api people, since I think I know what's wrong but need to check with them on if I'm right [11:34] ok :) === chriadam is now known as chriadam|away [12:00] ricmm: ping [12:16] rsalveti, i managed to drop another 700M (unpacked) from the tarball === msorvig_ is now known as msorvig [12:29] trying to build /ubuntu in another AOSP here, but keep receiving failure [12:29] checked files under /build but I can't really find what did I missed [12:31] here is the log http://pastebin.ubuntu.com/5718645/, please advice if you have any idea :( [12:35] janimo, lol ... see above ... i removed most of the superfluous toolchains in my testing [12:35] funny that we always sectretly look at the same stuff without the other knowing [12:40] hey Taiten987 how are you [12:40] pmcgowan, working on the patches :) [12:40] pmcgowan, a bit stuck here [12:41] if rsalveti is around he may be able to help [12:41] pmcgowan, I just figured out it was surfaceflinger API changes [12:41] pmcgowan, yes, I had pinged him [12:41] pmcgowan, hopefully he can see it [12:41] Taiten987: can you use the same version of AOSP? did you see my email? [12:42] pmcgowan, yes I do === olli__ is now known as olli === _salem is now known as salem_ [12:46] ogra_, heh :) [12:47] i just answered your mail [12:47] not usre where' above to look, will check the email [12:47] we want to actually start building the android stuff on the package builders [12:48] to do that the source tree needs quite some cleanup though ... so you dont have to upload a 1.4G tarball for every change [12:48] ogra_, the problem with removing some of all prebuilts is that some kernels only build with a specific one [12:48] http://phablet.ubuntu.com/export/ [12:48] so mako kernel did not build for me with raring gcc a while ago [12:48] ogra_, also I tried building for a huawei device and that to only built with an inlcuded 4.6 [12:48] well, rsalveti added a patch to actually use the packaged binary instaed [12:48] so you dont need to build the kernel at all [12:49] if we expect people to contribute ubuntu touch ports they may have an additional hurdle if they need to find a toolchain [12:49] for porters we will have to keep the full tree around [12:49] although not sure how we could move stuff to cdimage and support many crazy toolchains [12:49] but for building for something supported we want a cut down set [12:49] so I hope we can make all work with stock gcc [12:49] janimo: thats a valid concner [12:49] concern [12:50] well, you need to shuffle a lot ... gcc, and gcc-cross need to work [12:50] ogra_, well we only have packaged kernels for nexus 7 [12:50] but since yesterdays desaster with image builds we decided we want a very small tree and use the package builders for rolling images [12:50] a lot of the rest of devices are either 3rd patry hacked up OEM kernels or too new SoCs we do not package yet [12:50] hopefully multiARM kernels will come to the rescue soooooon [12:51] didrocks: the phone-app with the changes made works like a charm on my desktop [12:51] * ogra_ tried to implement image building on the livefs builder ... that resulted in the machine to die for a full day [12:51] didrocks: there's one merge that needs to go in though [12:51] sil2100: \o/ excellent news ;) [12:51] sil2100: ah? [12:51] luvefs builders arent designed for cross compiling :P [12:51] *livefs [12:52] janimo, we also plan to package the android bionic toolchain for cross building [12:52] thats a long term plan though [12:52] in the short term using the packaged toolchains (or packaging linaros android cross chain) is the plan [12:53] didrocks: https://code.launchpad.net/~mterry/phone-app/hud1/+merge/158201 <- waiting for CI to finish the re-build [12:55] sil2100: mediumtests failed === jelatta_away is now known as jelatta [12:55] mhall119: Hey ! My branch seam to be clean now. I want to work on the package but can't do it still your branch "package-fixes" isn't merged [12:55] *seem [12:57] eeek, all of them! === Julien is now known as Guest87519 [12:57] hmmm [12:57] Strange, since HUD 1.0 is in the daily PPA already [12:58] use the large tests then, not the mediumtests :P [12:58] didrocks: what PPA is CI using when running the autopilot tests, do you know by any chance? [12:59] sil2100: I think they start using your daily-build-next ppa, but better to check with fghinter [12:59] ogra_: tsss :p [13:00] I would like to know if it is possible to contribute as a tester, I mean not only for bugs but also to describe things that can be improve (for example, I suggest to blcok the switch between apps from the top and the bottom corner of the right part of the screen) === juicyjones|away is now known as juicyjones [13:16] ;) [13:22] nik90, the best way to know if jenkins is back online is to check the url: http://91.189.93.125:8080/ [13:23] nik90, The server is online at the moment (Hooray!) but it's a little more work to setup the jobs for each project. [13:30] \o/ === vrruiz_ is now known as rvr [13:39] lool, I don't see anyone from the indicator/settings team? [13:41] cyphermox: ping [13:43] mhall119: ping === dandrader is now known as dandrader|afk [13:45] mzanetti: pong [13:45] cyphermox: hi [13:45] cyphermox: regarding https://code.launchpad.net/~mzanetti/autopilot-qt/add-tests/+merge/153695 [13:45] cyphermox: I guess its now or never [13:46] rock on! [13:46] Oranger: pong [13:47] cyphermox: its still on Needs Fixing from you [13:47] mhall119: 1 point [13:47] you mind approving? [13:47] mhall119: Hum sorry ^^ [13:47] mhall119: Hum so I did what you ask me yesterday, the directory is clean [13:47] Oranger: checking it out now, thanks [13:47] mhall119: And I want to finish the package but actually I can't until your branch isn't marge [13:47] *merge [13:48] mzanetti: done. [13:48] cyphermox: thanks a bunch [13:49] note that this won't land in raring as-is; you'd need to file it against lp:autopilot-qt/0.8 [13:49] that said, does it need to be in raring? [13:49] actually, ignore me [13:49] cyphermox: no... just need to get it merged because other work that requires adding more tests is pending [13:49] you got the FFE ack anyway, so might as well if we have the chance [13:50] once that gets merged I'll re-run the qa stack [13:50] could you file it against the 0.8 branch too? [13:51] Oranger: can you review my package-fixes branch? [13:51] mhall119: Yes I do it now [13:51] thanks [13:54] cyphermox: https://code.launchpad.net/~mzanetti/autopilot-qt/add-tests/+merge/159636 [13:55] Oranger: your branch is approved [13:55] mhall119: Thanks [13:55] fginther: so is jenkins back on the job, or still recovering? [13:58] mhall119, It looks to be alive. I'm checking to make sure the build tools are in place before I deploy the jobs [13:59] thanks fginther === dandrader|afk is now known as dandrader [14:00] sergiusens: you noticed already but I pushed your stuff yesterday [14:01] and sent the kernel one after doing the 4 builds and also producing a test grouper one based on the ubuntu package as well [14:01] mhall119: I approved [14:03] thanks Oranger [14:08] mhall119, I've pinged martin about the jenkins server. There is still a little more work to do that I can't complete. [14:08] fginther, thanks for bringing Jenkins back to life. While you're at it, and if there isn't one already, would it be possible to add a job to run the autopilot tests in the core apps branches? [14:10] dpm, the test infrastructure is currently insufficient to do this, but I'll discuss this with my team to see if we can get it on the roadmap [14:10] rsalveti: yes, I am reviewing now... and I did check as I mentioned it in the gcc email thread :-) [14:10] rsalveti: I can only test build the mako and grouper, those are the two devices I don't have ;-) [14:10] * sergiusens just noticed he was marked away [14:11] sergiusens: that's fine, we can request someone else to test mako if needed [14:11] rsalveti: I will review, I trust you did the testing I will review [14:11] rsalveti: who has a mako? I can build and send [14:11] oh plars :-) [14:12] * sergiusens thinks he might be abusing plars' devices [14:12] yesss? :) [14:12] thanks a lot fginther. Just asking to have some more context: why is the test infrastructure currently insufficient? Is e.g. the number of jobs that the jenkins instance limited and we've reached the limit? Or is it related to autopilot not playing well with jenkins... ? [14:13] sorry, I meant "that the jenkins instance can run" [14:14] plars: give me a couple and I'll create a mako image... still reviewing the code ;-) [14:14] sergiusens: sounds good [14:15] mterry: FYI, sil2100 did some progress on touch today, and we are almost being able to build and test everything. Do you mind checking with him if you have time for finishing up the autopilot things? [14:16] sil2100, talk to me! :) [14:16] dpm, the main reason is that autopilot tests can't run inside a pbuilder, they need a real desktop environment. The likely solution is to do this in a dedicated VM, which isn't too difficult, but there may be some resource constraints that I'm not aware of. [14:17] rsalveti: I take that in 2 weeks time that raring in the BoardConfig will change to slug? [14:17] ! [14:18] anyone got an ETA for GSM in Ubuntu Touch (e.g. data) [14:18] mterry, didrocks: so... I had a talk with fginther, and soon we should be able to get both the phone-app HUD version bump and qtvideo-node arches merges in, those are required for us to carry on [14:18] thanks fginther, understood [14:18] sergiusens: yeah [14:18] I'm trying to figure out now with the help of rsalveti on how to deal with the armhf test failure on HUD, as it's a problem with android-specific bits [14:20] sil2100, yay [14:20] anyone? gsm ETA? === juicyjones is now known as juicyjones|away [14:43] sergiusens, so i looked into removing the oggs and mp4's, seems there are a bunch of changes needed for the build system to get rid of them (and i'm also not sure if we use something like i.e. the camera sound from teh android side when taking pics) [14:43] ogra_: that's already done [14:43] ogra_: update and see [14:43] oh [14:43] well, i'm playing with the tarball here :) [14:44] but havent pulled todays yet [14:44] ogra_: or just look at http://phablet.ubuntu.com/gitweb?p=CyanogenMod/android_frameworks_base.git;a=shortlog;h=refs/heads/phablet-10.1 [14:44] * ogra_ hugs sergiusens [14:44] ogra_: also made the changes to the makefiles as necessary in vendor/cm [14:44] yay [14:45] so now the toolchains and kernels and we should have a sweet 500M tarball :) [14:45] ogra_: after getting this kernel review in, I'll be looking into making it smaller [14:45] or even less [14:45] yes [14:45] yeah, sadly the gcc-cross one doesnt work [14:45] not sure if slangasek got it solved [14:45] ogra_: this would of been done sooner if we ever had this git repo in place for more than 2 months :-) [14:46] no hurry [14:46] anyone can tellme if that tablet support touch http://www.efox.com.pt/envios-da-europa-vido-n101-ii-android-4-1-rk3066-dual-core-10-1-1280-x-800-ips-32gb-3g-wifimara-dupla-tablet-pc-p-300356 ? [14:46] thank you [14:46] after all i'm happy that i can skip raring :) [14:46] and concentrate fully on S [14:46] (for the image builds) [14:47] MalMen, your link has a bad wot popup [14:47] Hello! Sorry for the interruption. I bought a Vaio T13 touchscreen ultrabook hoping that Windows 8 is a usable os. This isn't so, I found Windows 8 very user unfriendly and slow OS. So I installed Ubuntu 13.04 on my ultrabook. The problem is that the multitouch is not supported. I mean I cant click, drag with the touchscreen. I read that I need to install some kind of touchscreen driver. Could you please explain where do [14:48] wilee-nilee what specs i can give you to know if is compatible ? [14:48] MalMen, none I'm just on the channel. [14:51] ogra_: the reduced toolchain and pre-built set should happen later today as well [14:52] ogra_: today's tarball is also xz [14:52] with -6e [14:52] rsalveti, yup seen :) [14:52] takes quite a while to generate it hehe :-) [14:52] only 1.4G [14:52] yeah, step by step [14:52] yeah [14:52] 500M or so in the end would be good [14:54] rsalveti, did you talk to slangasek ? i didnt see him comment anything after the linker error [14:54] ogra_: nop, and as I said, I'm not convinced we should remove all pre-built toolchains at this point yet [14:54] so I'll just remove the stuff we're not using at least [14:55] rsalveti, if we can se should ... from the tarball ... i would say lets keep the git tree completely untouched [14:55] s/se/we/ [14:55] rsalveti: any reason why cm.dependencies for mako still lists the kernel? [14:56] sergiusens: the kernel source is needed still for the headers [14:56] the tarball will be used for autobuilds and we only need the bits for building the supported sets ... [14:56] sergiusens: it's used by some hardware/qcom components [14:56] the git tree should have as much as possible for porters [14:56] ogra_: well, we can create a separated tarball with the toolchain once we get a working toolchain from the archive [14:56] rsalveti: let's keep it for now and figure out how to get just the headers in [14:56] rsalveti, thats what i mean ;) [14:57] iirc aosp doesn't install the kernel headers by default [14:57] sergiusens: hm, iirc this qcom component is the same from aosp [14:57] might be something cm specific though [14:57] we have a headers package as well :) [14:57] but yeah, to be investigated [14:57] sure [14:57] rsalveti: and we do have external/kernel_headers as well [14:57] but I believe these headers are mako specific [14:58] we might try to reuse the headers available from the kernel package as well [14:58] rsalveti: typo in the previous comment, aosp doesn't install kernel sources by default [14:58] will see if I can get something to work based on that later today [14:58] rsalveti: I won't block the patch in any case, just wondering what the result was of the conversation from yesterday :-) [14:59] sergiusens: right, yeah, this will follow, just wanted to get something that works first [15:00] ogra_: problem is that if it's indeed mako specific, it might not be available at the headers package [15:00] had similar issues with panda in the past [15:00] that's why I decided to investigate this later :-) [15:00] ah [15:00] well, no hurry :) [15:01] (you two seem to do everything *right now* .... we're not on a race :) [15:20] hello? [15:24] gusch: saw your updates to the bug... I recall the issue and a workaround jhodapp made to get it going (I'm pretty sure it was him). But yeah, the crash has been there for some time.... :-/ [15:25] rsalveti: code looks good, building now (had to wait for meeting to end) [15:25] sergiusens: sure [15:26] sergiusens: the crash is there since the beginning, but the side effect of the flipped preview occured somewhen after the MWC demo image [15:27] gusch: yup, which brings up the question if we should focus on the crash instead [15:29] sergiusens: that's what I do now ;) [15:29] ogra_: I got past the linker error (just needed to add -fuse-ld=gold in the right place), then ran into problems because of libgcc references - which is kind of what I was expecting to find. We need to build an -> armel cross-compiler to target android specifically [15:29] ogra_, rsalveti [15:29] yeah [15:29] ogra_, rsalveti: and at least for upload to the archive, we would need to solve the use of prebuilt compilers... as distributing those without source is a GPL violation [15:30] right [15:30] i doubt we need to build it ... since linaro has one :) [15:30] yes we do. [15:30] ah, we cant use the linaro one ? [15:30] we can probably use if we grab the sources used to built it [15:30] *build [15:30] right [15:31] but yeah, at the archive it'd be better to use our own toolchain === dandrader is now known as dandrader|lunch [15:42] rsalveti: given that we are already building cross-toolchains in the archive for other targets, and we track the Linaro patches for the arm builds, we should build the android toolchain the same way rather than introducing a parallel toolchain source [15:43] sergiusens: yeah, I was helping gusch figure out how to use gdb on the android side [15:43] slangasek: sure, no question about that [15:43] just saying that it's doable to use the prebuilt one if really needed [15:43] just need to find the sources [15:44] slangasek: who can be allocated to do that work? [15:44] well, if we're putting it in the archive we also need to *build* the toolchain, not use the prebuilt [15:44] anyway [15:45] sure, it'll just force ogra_ to wait until the toolchain is in place [15:45] as i said, i'm not in a hurry [15:45] lets discuss it at the sprint and do proper planning [15:46] sure, we'd need to get someone to work on this [15:46] we wont start raring builds based on that right now ... so it is S material [15:46] yup [15:46] but it's a high prio to be able to spin builds based o S, right? [15:46] i personally would prefer if doko could do it, everyone else will need double the time [15:46] at least via cdimage [15:46] but i dont know how heavily booked he is [15:47] rsalveti, right, but even in S we can live with the jenkins builds in the beginning [15:47] i expect the S builds to be bumpy in the beginning anyway [15:47] mhall119: You don't do something in particular for core apps to merge branches than "merge + commit + push" ? [15:47] ogra_: right, that's why I said if we want to build them at cdimage [15:47] doesnt make them less bumpy :) [15:48] we'll have to keep raring building for a while in parallel if we want usable images ... important is that by S release we will not have two parallel builds anymore but can smoothly transition to T this time [15:49] thats my major target ... [15:50] while i want S builds as early as possible they dont need to be in place on day one imho [15:50] (would be a nice to have ... but i have no illusions here) [15:51] plars: http://people.canonical.com/~sergiusens/cm-10.1-20130418-UNOFFICIAL-mako.zip [15:52] rsalveti: I need to talk to doko yet about the cross-toolchain requirements and when we can have this done; if you have anyone on your team who can help doko identify the necessary configure arguments for gcc, that will probably let us get it done faster [15:52]