=== xiinotulp is now known as plutoniix === zequence_ is now known as zequence [14:16] Hi. I'm interested in porting UbuTouch to a new device. I have the stock Android rom for this device, and it's Lollipop 5.1. Porting page on the wiki, says that last UbuntuTouch is based on low-level parts of Android KitKat. If I should be able to create a lollipop source repo, could I use it to build UbuTouch, or stock kernel and binary drivers would result incompatible? [15:04] Hello. I'm looking for a guide how to build ubuntu touch rootfs. In https://wiki.ubuntu.com/Touch/Contribute there's written 'Images are currently built in the Canonical data center. Full builds are published on cdimage.ubuntu.com.' Does that mean that we cannot build it locally? [15:14] Grawp, it means that there is quite some image build infrastructure involved ... you can indeed do it locally but it is rather complex [15:14] why woulld you do that though ? [15:14] (the rootfs is identical on all devices,, there is never any need to build it your own) [15:23] I was just curious whether it can be done. You can see CM build servers galore on XDA forums, but no one is building (complete) ubuntu. Besides, if you can't build it on your own, it's not really opensource [15:24] you can surely try to replicate the ubuntu build infrastructure ... setting up cdimage machines, lp-buildd machines to roll the rootfs and a system-image server [15:24] its definitely all open source ... its just very hard to set up and a rather useless attempt ... [15:24] if you want to submit a fix you can always to it against the debian package the code is in [15:25] the rootfs is completely built from deb's [15:25] iif you develop you rather make the system writable and install your changed deb than building the world from scratch ... like in any ubuntu install [15:26] (note though that making the system writable means you will have to re-flash at some point, upgrading via apt is not supported afetr all) [15:28] hmm.. rootstock-ng seems to be just wrapped debootstrap. nice :) Thanks for the answer btw. I really was just curious. [15:29] right, rootstock-ng is trying to replicate the actual build env ... but will always slightly differ [15:29] (simply because it isnt the actul build env) [15:29] anyway, for porting or any device specific bits you never ever touch the rootfs anyway [15:30] ubuntu keeps all device specific bits distinct [15:30] (from the os itself) [15:31] Yep. I get that. Btw. what ubuntu-desktop version would recommend for building the kernel&CM bits? [15:31] Should I go for the LTS or the newest one? [15:34] i'd actually go for the newest and upgrade to the new LTS in april [15:34] (release is only 4 weeks away) [15:35] thanks [15:40] Any answer for my previous question? Can I port UbuTouch from an Android Lollipop 5.1 rom? [15:42] javier4, wait til the workweek starts ... there is a 5.x branch somewhere but the guys that know where are not around on weekends [15:45] also check ubports.com (perhaps there is a link somewhere, i havent checked) === shuduo is now known as shuduo-afk === shuduo-afk is now known as shuduo [18:04] hey is ther any documentation on what parts of ubuntu touch cme from android and what is ubuntu [18:04] I understand the driver management system and drivers are borrowed from android, but what else? [18:15] rap, things like the camera service, video codecs, gps backend ... all in all there is an ~150MB install inside the lxc container [18:15] has anyone looked at https://android.googlesource.com/kernel/common/+/android-4.4 ? [18:34] ogra_, thanks man. Anybody has a link to some documentation useful to identify binary blobs from a rom? [18:40] github.com/TheMuppets [18:40] but you didn't hear it from me [18:43] n1cky: nice [18:51] n1cky, wonderful link. But it doesn't help me. I need to know how to learn to identify binaries on a device still not examined by anyone. [18:52] javier4: what's the device? [18:53] n1cky: it should be an elephone based on Helio X10 [18:56] the vowney? [18:56] xda thread says sources aren't going to be released [18:57] which is orthogonal from getting blobs, but is still a big issue [18:58] recognizing what blobs are necessary is outside of my ability, sorry. [18:58] there exist scripts in cyanogenmod device directories which extract them via adb-- you might look for another MTK6795 phone with cm support and see what you can do [18:59] but i wouldn't be too hopeful. [18:59] (I think your first step should be to get cm running on it) [19:00] If sources would be going to be released, I shoudln't need to learn how to extract blobs. :D [19:00] the problem to run cm, is that the first step is extract binaries. :) [19:01] firmware is not the same thing as sources [19:03] for "sources" I mean cm or aosp repo. [19:11] javier4: right, but an aosp repo doesn't necessarily mean all the required binary blobs will be included. :) [19:14] dobey, if it's the vendor_device_repo it must include the binaries also. At most it cannot have the classic proprietary_blob.txt and extract_proprietary.sh [19:45] Hi. I'm trying to port Allegro game programming library to Ubuntu Touch (with SDL as backend, for now). I managed to create drawing surface and load a bitmap from reosurces. However, after that, strange things happen: the first frame is drawn correctly. However, after that bitmap is not visible, even though I call draw function. But I can, for example, clear backbuffer to various colors in main loop. What tools are available for [20:03] MaxEd: neat! [20:45] popey: I hope it will be :) But for now, all I get is corrupted framebuffers :( [20:53] MaxEd: SDL2 on Mir is a touch unstable [21:00] popey: I guess it can be the source of my problems, then. I was thinking using SDL as backend was an easy, to avoid writing all the code for Mir in Allegro right now, but maybe that's what I should be doing. [21:00] Yeah, i have a bunch of SDl2 things which don't behave on ubuntu phone [21:01] But dammit, initializing display and drawing a single bitmap shouldn't be one of them! :) [21:01] (But I guess with TWO layers between me and OpenGL, the number of things that could go wrong is just too large) [21:41] hi