| Thaodan | mal: yes exactly that | 02:45 |
|---|---|---|
| T4 | d3v4shish was added by: d3v4shish | 05:34 |
| *** ChanServ sets mode: +v teleirc | 07:34 | |
| *** teleirc is now known as T4 | 07:34 | |
| *** OhYash1 is now known as ohyash | 08:38 | |
| mal | @adampigg a small fix request in dhv PR | 13:33 |
| T4 | <adampigg> Mal, i just saw..classic mal nitpicking 😃😆😉 | 14:04 |
| T4 | <adampigg> Will fix later, going to a football match with son | 14:05 |
| mal | @adampigg I'll try to do some camera stuff today | 14:09 |
| * vknecht is on the gallery | 14:10 | |
| T4 | <adampigg> Mal, nokius has been using it | 14:15 |
| T4 | <m_aurel> We have some news from one of our potential ODMs. Their successor model will be based on Octa-Core SC9863 of Spreadtrum. Some experiences with this processor for hardware adaption? It's not Qualcomm. Is this a problem? | 16:12 |
| T4 | <NotKit> It may be a problem since there were no Spreadtrum-based ports yet. MediaTek works, but nobody tried Spreadtrum | 16:21 |
| Mister_Magister | >comming back to porting after some time; >hadk says nuke everything; >say what | 16:21 |
| mal | Mister_Magister: ? | 16:22 |
| Mister_Magister | mal: hadk-hot says to nuke every target and whole sfossdk | 16:22 |
| Mister_Magister | hadk-hot that is | 16:23 |
| T4 | <m_aurel> But it should be the same procedure, if we would get the Android Board Support Packabe with Kernel Source Code, Android Source Tree (Reference) and binaries for drivers? | 16:23 |
| mal | Mister_Magister: ok, I think there were some changes to how targets are handled, not sure if you have tooling target yet | 16:24 |
| Mister_Magister | i do have tooling | 16:24 |
| mal | @m_aurel yes, in theory it goes the same way, different manufacturers may need some additional changes, difficult to say before how many changes | 16:25 |
| T4 | <NotKit> @m_aurel yes, but you would need to get buildable Android source code for ODM | 16:25 |
| T4 | <NotKit> *from | 16:25 |
| Mister_Magister | mal: so i don't have to nuke everything? | 16:26 |
| Mister_Magister | but update would come handy anyway | 16:26 |
| mal | Mister_Magister: not sure, there must be a reason why removing is mentioned, installing those again does not really take any longer than updating | 16:27 |
| Mister_Magister | mal: yee i think i will nuke them | 16:27 |
| Mister_Magister | i have old toolchain anyway | 16:28 |
| mal | Mister_Magister: at least if you download the target package and use the same downloaded one when creating the targets | 16:28 |
| mal | so you don't always have to download the package for each target | 16:28 |
| Mister_Magister | yeye i get it | 16:29 |
| T4 | <m_aurel> I see. I will look for resources to order a poc with a basic hardware adaption, if the commercial negitiation with the ODM is positive. We have already send out an rfp, but software companies, that have skilled developers for hardware adaption are rare. Recommendations from the community are wellcome. If some freelancers are interested, t | 16:34 |
| T4 | hey can send me a private message via Telegram. | 16:34 |
| Mister_Magister | mal: btw any progress with new hybris? | 16:40 |
| mal | I once did a port for a NovaThor device | 16:41 |
| mal | Mister_Magister: sorry, I haven't had time | 16:41 |
| Mister_Magister | mal: don't be sorry thanks for helping me | 16:41 |
| Mister_Magister | mal: lineage is not even out yet so no hurry | 16:42 |
| mal | Mister_Magister: oh, I thought lineage 16 is out | 16:43 |
| Mister_Magister | mal: i mean not for the phone i want to port | 16:44 |
| mal | ok | 16:44 |
| Mister_Magister | now i will be moving motorola x play (lux) to 14.1 base | 16:44 |
| Mister_Magister | i need to catch spiiroin. ping btw | 16:45 |
| T4 | <adampigg> Mal, how goes the focus testing? | 17:12 |
| Mister_Magister | @adampigg i need to finally try ur camera app | 17:13 |
| mal | @adampigg not much done yet, I really start doing it after I have eaten | 17:14 |
| heroic_1 | mal: you online? let's discuss https://github.com/mer-hybris/hybris-boot/pull/161 here, it's easier | 18:23 |
| Mister_Magister | whet there are already changes for treble devices? | 18:26 |
| Mister_Magister | noice that will come handy | 18:26 |
| heroic_1 | what do you mean? android 8 is basically all about treble ^^ | 18:28 |
| Mister_Magister | yeee | 18:28 |
| Mister_Magister | sadly | 18:28 |
| heroic_1 | how so? I find writing glue code for well-defined hals a lot more sane than the insanity that reigned before | 18:29 |
| heroic_1 | I have another question: Is it common practice to use something like droid-system-$DEVICE here? | 18:30 |
| heroic_1 | e.g. https://github.com/marina-bay/droid-system-sony-tone-kagura | 18:30 |
| heroic_1 | I can't find any such repo for latte(which seems to have a lot of dev going on) or fairphone sibon | 18:31 |
| Mister_Magister | first time seeing it | 18:31 |
| heroic_1 | I'm building with it and am wondering how you do without it | 18:31 |
| Mister_Magister | is it just vendor blobs? | 18:32 |
| heroic_1 | How do you structure your partitions and folders e.g. for sibon? | 18:32 |
| heroic_1 | Mister_Magister: no, vendor blobs live on the odm partition for sony devices | 18:32 |
| Mister_Magister | im talking about this repo | 18:33 |
| heroic_1 | the repo is not blobs, none whatsoever | 18:33 |
| heroic_1 | same for droid-system-vendor-tone | 18:33 |
| Mister_Magister | then what is this | 18:33 |
| heroic_1 | you have to get the android libs onto sailfish somehow | 18:33 |
| heroic_1 | In my current config, they end up on the lvm2 image that gets flashed to the userdata partition | 18:34 |
| Mister_Magister | so it is blobs | 18:34 |
| Mister_Magister | https://github.com/marina-bay/droid-system-sony-tone-kagura/tree/sfos-3.0.1.14-android-8.1/sparse/system/lib64 looks like only blobs | 18:34 |
| Mister_Magister | dhd | 18:34 |
| heroic_1 | oh we seem to have a different understanding of blobs | 18:34 |
| Mister_Magister | is for packaging blobs | 18:34 |
| heroic_1 | I guess you mean any android libs or binaries | 18:35 |
| Mister_Magister | ye | 18:35 |
| heroic_1 | when I hear blobs I hear proprietary | 18:35 |
| heroic_1 | ok but I get you | 18:35 |
| mal | heroic_1: I was just wondering if building systemimage will cause some other things to build which we don't need, I started a build for a legacy device and will compare droid-hal rpm sizes to see if there is any size difference | 18:35 |
| heroic_1 | mal: yes, frankly I don't understand what parts of android are really needed | 18:36 |
| Mister_Magister | heroic_1: https://github.com/VerdandiTeam/droid-hal-osprey | 18:36 |
| mal | heroic_1: about commit message naming, please change to commit message to follow the naming as seen in previous commits to that repo (git commit --amend and force push) | 18:36 |
| Mister_Magister | droid-hal-$DEVICE is for packaging android | 18:36 |
| mal | heroic_1: I has some understanding what is needed since I have been involved in creating many of the hybris base repos so far | 18:37 |
| mal | heroic_1: also do we want to build systemimage for all or only for legacy devices | 18:38 |
| heroic_1 | I can only answer that if I know what is needed | 18:38 |
| heroic_1 | On android 8, a lot is spread out over both images | 18:38 |
| heroic_1 | but on 8, systemimage includes vendorimage (under /system/vendor) for legacy | 18:39 |
| heroic_1 | force-pushed, commit msg is now "[hybris-boot] Android.mk: Only build treble targets if needed", is that ok? | 18:39 |
| mal | heroic_1: I also noticed issues with legacy device build that fstab and ueventd.rc were missing from out/ and that caused build scripts to fail | 18:40 |
| heroic_1 | you can build those separately | 18:40 |
| mal | heroic_1: I know but we should make builds generic so people don't need to figure out what extra stuff they might need | 18:41 |
| heroic_1 | fstab.$HABUILD_DEVICE should do it, but there are cases where it's named fstab.qcom or similar | 18:41 |
| mal | heroic_1: Android.mk in the beginning is not really needed, see this for example https://github.com/mer-hybris/hybris-boot/commit/d899c767873b7350e456002487a3ba2d11e5d137 | 18:42 |
| mal | heroic_1: wait a moment, I'll see if I can think of a good commit message | 18:42 |
| heroic_1 | force-pushed already ^^ | 18:43 |
| mal | ok | 18:43 |
| mal | that is probably fine | 18:43 |
| heroic_1 | but to get back again to partitioning: How is a community port supposed to look like? A simply ext4 image for the system partition which holds sailfish rootfs and an ext4 image for the userdata partition to hold /home/nemo? | 18:44 |
| heroic_1 | Mister_Magister: https://github.com/VerdandiTeam/droid-hal-osprey/blob/master/droid-hal-osprey.spec this confuses me a bit | 18:45 |
| Mister_Magister | heroic_1: mal can answer better | 18:45 |
| heroic_1 | How does that spec file get all the needed android libs to the target? | 18:46 |
| heroic_1 | I'm guessing it's https://github.com/mer-hybris/droid-hal-device/blob/9ef33291e1bf598ad42e9b35641e8f0116e90c52/droid-hal-device.inc which explicitly copies a lot of stuff? | 18:46 |
| Mister_Magister | ye | 18:47 |
| heroic_1 | well for that you definitely need to make a systemimage | 18:48 |
| Mister_Magister | well wait | 18:48 |
| Mister_Magister | we use libs from android base | 18:48 |
| Mister_Magister | no need to put them in the sfos image | 18:48 |
| Mister_Magister | official sony ports build systemimage iirc | 18:49 |
| mal | heroic_1: droid-hal rpms contain the needed android libs from out, which were first built using make hybris-hal in the other env | 18:50 |
| Mister_Magister | yee | 18:50 |
| mal | heroic_1: sailfish doesn't really need the systemimage to be built at the same time as hybris-hal, most of the android stuff comes from system.img from a clean android build, droid-hal only contains some patched libs which are used to override the ones in system.img | 18:51 |
| mal | heroic_1: in official device system.img is not used but instead android side libs are packaged separately to rpms, those devices still have droid-hal rpms also, only difference in that all needed android libs are in the sailfish image, not only the modified | 18:53 |
| Mister_Magister | (that is ofc different in official images) | 18:53 |
| mal | heroic_1: sailfish community port is not a ext4 image, it is a zip that you install from recovery, system partition comes from lineageos or aosp | 18:55 |
| mal | heroic_1: so community ports do not contain whole userdata but are instead installed to existing userdata to a special subfolder | 18:56 |
| mal | heroic_1: the xperia x way of building is different and closer to official devices | 18:56 |
| mal | except for the system partition stuff | 18:57 |
| heroic_1 | the way I see it, it would make sense to keep sailfish on the system partition | 18:58 |
| mal | not in community ports | 18:58 |
| heroic_1 | for kagura, it's 7gb. plenty of wasted space otherwise | 18:58 |
| mal | heroic_1: that would mean you would have to package system partition content | 18:59 |
| heroic_1 | right now my port is pretty much oriented on the official nile images, i.e. one lvm2 image for userdata which holds rootfs(sailfish + "system" and "vendor" folders with android libs) and "home" which holds /home/nemo | 19:00 |
| mal | which might in theory cause some license issues if that contain vendor blobs | 19:00 |
| heroic_1 | for sony, you are 100% allowed to package system and vendor | 19:00 |
| heroic_1 | all proprietary content is on /odm | 19:00 |
| mal | on some other devices that may not be the case | 19:01 |
| heroic_1 | hmm I get that. still a waste of storage, but for consistency's sake I can accept it | 19:01 |
| mal | heroic_1: did you really package the system partition already? I assume your device would currently use the system partition for android libs | 19:02 |
| heroic_1 | the system partition is currently unused | 19:02 |
| heroic_1 | it would hold the factory reset images for sailfish x | 19:02 |
| heroic_1 | but I don't need them | 19:02 |
| mal | how did you create the system rpms? | 19:03 |
| heroic_1 | via droid-system-kagura | 19:03 |
| mal | I mean https://github.com/marina-bay/droid-hal-sony-tone/blob/sfos-3.0.1.14-android-8.1/droid-hal-kagura.spec#L59 | 19:03 |
| mal | but how did you build it? | 19:04 |
| heroic_1 | manually | 19:04 |
| mal | using clean sources of what manifest? | 19:05 |
| heroic_1 | "./rpm/dhd/helpers/build_packages.sh -b hybris/droid-system-kagura -s rpm/droid-system-kagura.spec -s rpm/droid-system-kagura-f8331.spec" | 19:05 |
| heroic_1 | I copied all the items manually, because I needed to tweak a lot | 19:05 |
| heroic_1 | Seems the official sailfish images use the helpers from here to do that https://github.com/mer-hybris/droid-system-device/tree/860e7526d705e98f29974890c8fc73725970d7c0/helpers | 19:06 |
| mal | you still are missing my question, which manifest did you use | 19:07 |
| heroic_1 | you need to be careful though, because if you blindly copy, you will have the audioflingerglue and droidmedia libs in your system image | 19:07 |
| heroic_1 | manifest? | 19:07 |
| heroic_1 | mal: you mean the one for repo? | 19:07 |
| mal | heroic_1: usually system rpms would contain unpatched libs, not ones built from hybris manifrst | 19:08 |
| mal | not sure why you didn't use the normal way and just leave the system libs to system partition and use that | 19:08 |
| heroic_1 | oh yeah I already included the patched ones in my repo manifest | 19:08 |
| heroic_1 | https://github.com/marina-bay/sailfish-android-local-manifests-sony/tree/sfos-3.0.1.11-android-8.1 | 19:09 |
| heroic_1 | the patched libs are in https://github.com/marina-bay/sailfish-android-local-manifests-sony/blob/sfos-3.0.1.11-android-8.1/sailfish-aosp.xml | 19:09 |
| heroic_1 | You gotta understand where I'm coming from | 19:10 |
| heroic_1 | It's a lot easier to just build aosp for me than to murk around with a prebuilt lineage image | 19:10 |
| heroic_1 | because the lineage ports for sony are generally not good and use forbidden blobs | 19:10 |
| mal | I find your way very confusing | 19:10 |
| heroic_1 | mal: yes, I am used to the android way of doing things | 19:11 |
| Mister_Magister | heroic_1: can i ask who r u cause ima out of topic | 19:11 |
| heroic_1 | who I am? I am ix5 on github if that's what you wanna know | 19:11 |
| Mister_Magister | naah | 19:11 |
| mal | Mister_Magister: Xperia XZ porter | 19:12 |
| Mister_Magister | oh | 19:12 |
| Mister_Magister | that solves a lot of things | 19:12 |
| heroic_1 | normally I do dev work on sony's open devices project. sailfish and mer and rpm and whatever is completely alien to me | 19:12 |
| heroic_1 | e.g. the way you use git submodules when you have a perfectly working way of using android's repo tool to structure folders | 19:13 |
| heroic_1 | makes a lot more sense to just let repo populate the generic "droid-hal-version" folder https://github.com/marina-bay/sailfish-android-local-manifests-sony/blob/sfos-3.0.1.11-android-8.1/sailfish-sony-nile.xml#L9 | 19:14 |
| mal | heroic_1: but a lot of things are build in OBS | 19:15 |
| Mister_Magister | btw obs needs more workers | 19:15 |
| mal | heroic_1: as separate build, normally droid-hal-version nor droid-config are not needed in manifest if most things are built on OBS | 19:16 |
| heroic_1 | mal: I guess all these things are completely normal for you, but from an outsider's perspective make little sense | 19:16 |
| heroic_1 | I am slowly seeing why things are the way they are, but when I started a lot confused me | 19:16 |
| mal | heroic_1: you probably think from local build point of view | 19:16 |
| heroic_1 | yes | 19:16 |
| mal | if you take into account also OBS then things make more sense | 19:17 |
| heroic_1 | If you have synced your tree, you need no internet connection for building | 19:17 |
| Mister_Magister | heroic_1: once we build droid hal we dont need to touch it | 19:17 |
| heroic_1 | that's how it is done in android | 19:17 |
| heroic_1 | for early porting, you def need local builds | 19:17 |
| heroic_1 | and they need to be fast and fast to rebuild | 19:17 |
| mal | heroic_1: yes, but that is the android lib part, I only do that locally, everything else on OBS | 19:17 |
| Mister_Magister | yep | 19:18 |
| heroic_1 | but why? Mister_Magister just said obs is stretched to the max | 19:18 |
| mal | heroic_1: for reference https://build.merproject.org/project/show/nemo:devel:hw:fairphone:fp2-sibon | 19:18 |
| heroic_1 | I have a good build machine, why not do it locally? | 19:18 |
| mal | heroic_1: OBS is needed for OTA updates | 19:18 |
| Mister_Magister | since im using obs building locally is just pita | 19:19 |
| heroic_1 | makes kinda sense | 19:20 |
| mal | heroic_1: I have plenty of local build power and do locally only test builds | 19:20 |
| heroic_1 | I gotta say, I'm really not a fan of these spec files | 19:20 |
| mal | then finally build stuff on OBS | 19:20 |
| heroic_1 | They're very limiting | 19:20 |
| heroic_1 | and ugly af | 19:20 |
| heroic_1 | so much spagetti | 19:20 |
| mal | heroic_1: what would you need in those? | 19:21 |
| heroic_1 | e.g. a way for global build variables | 19:21 |
| mal | when building what? | 19:21 |
| heroic_1 | e.g. I set a variable in my device-sony-kagura dir | 19:22 |
| Mister_Magister | i think heroic_1 is missing the point | 19:22 |
| heroic_1 | and it gets picked up in the boot image build dir | 19:22 |
| * Mister_Magister global variables are bad btw xd | 19:22 | |
| mal | give a specific example so I can understand | 19:22 |
| heroic_1 | e.g. the created kickstart files | 19:23 |
| heroic_1 | android has a notion of a build system | 19:23 |
| heroic_1 | where you have build stages and then a clearly defined build image is assembled for you | 19:23 |
| heroic_1 | with the kickstart and mic thingy stuff seems to fall apart for me all the time | 19:23 |
| mal | I think most of sfos build is designed for automatic builds | 19:24 |
| heroic_1 | ye, can see it is mostly geared towards oems | 19:24 |
| heroic_1 | which does make sense | 19:24 |
| heroic_1 | not trying to shit on you | 19:24 |
| mal | heroic_1: usually .ks doesn't need to be regenerated once you have it working | 19:24 |
| Mister_Magister | tru | 19:24 |
| heroic_1 | mal: my point would be that you shouldn't even need a ks | 19:25 |
| Mister_Magister | i was building images for my ports like 3 updates with same ks | 19:25 |
| mal | I have used the same .ks for a long long time | 19:25 |
| mal | heroic_1: yes, mic build stuff is not perfect | 19:25 |
| heroic_1 | but since you have so much variety in devices and need to deal with different android-isms and versions, I can see why so much spagetti is needed | 19:25 |
| * Mister_Magister mic is very old | 19:25 | |
| Mister_Magister | heroic_1: i don't really think that it's spaghetti | 19:27 |
| heroic_1 | either way, I have started writing some docs to make sense of it all | 19:27 |
| heroic_1 | you gotta understand, for someone not used to rpm, spec, %%%% stuff it's all very confusing | 19:27 |
| Mister_Magister | in dhd .spec file is super clean most of it is generic for all devices | 19:27 |
| Mister_Magister | and droid-configs are same only device specific configs | 19:28 |
| Mister_Magister | i dont think it's spaghetti | 19:28 |
| heroic_1 | https://build.merproject.org/package/view_file/nemo:devel:hw:fairphone:fp2-sibon/droid-config-fp2-sibon/_service:tar_git:droid-config-fp2-sibon.spec?expand=1 | 19:28 |
| Mister_Magister | heroic_1: it can be confusing but it doesn't mean it's bad | 19:28 |
| heroic_1 | if that isn't spagetti I don't know what is :P | 19:28 |
| heroic_1 | there are bash-style variables ($RPM_BUILD_ROOT) mixed with spec-style (%{_datadir}) mixed with rpm-ish things ("Requires: ") | 19:30 |
| * Mister_Magister android is a poopoo anyway and we wouldn't need it if there was no android | 19:30 | |
| mal | heroic_1: don't count .inc as part of spec, only actual spec part is relevant since that is what user sees | 19:30 |
| mal | heroic_1: also one things in sailfish is that a lot of things are prebuilt and compared to android it's different, android always builds everything | 19:30 |
| heroic_1 | mal: ye I get that you'd want as much shared stuff as possible, but for me a complete rebuild of android with warm ccache is 3 minutes | 19:31 |
| heroic_1 | just the zypper refresh stage in mic is already triple that | 19:31 |
| T4 | <NotKit> @heroic_1 [because the lineage ports for sony are general …], forbidden blobs? are those better then? | 19:32 |
| mal | heroic_1: zypper ref takes no time | 19:32 |
| heroic_1 | Mister_Magister: android is here to stay, like it or not. else you'd have to write all those hw drivers yourself, which, to be honest, you will never be able to do with low manpower | 19:32 |
| mal | heroic_1: this is the fundamental difference between linux and android | 19:33 |
| mal | sailfish does things the linux way using repos and prebuilt stuff | 19:33 |
| heroic_1 | mal: yes, I am familiar with it(arch user myself). still doesn't mean the build system has to be only bash scripts | 19:34 |
| heroic_1 | android is declarative, mer build is mostly writing the code yourself | 19:34 |
| heroic_1 | I think a lot can be learnt from android | 19:35 |
| * Mister_Magister btw i use arch guy heh | 19:35 | |
| * Mister_Magister doesn't think so | 19:35 | |
| heroic_1 | Mister_Magister: that's just silly. every platform has things that it gets right that others might do well to copy | 19:36 |
| Mister_Magister | heroic_1: i'm just android hater don't mind me :P (going afk) | 19:36 |
| TheKit | the problem I should note with Android build system is that now it requires few hundred of GBs and at least 16 GB of RAM | 19:36 |
| * Mister_Magister #### make completed successfully (07:50 (mm:ss)) #### | 19:37 | |
| heroic_1 | TheKit: yes that is true. it's infuriating how bloated it is | 19:37 |
| heroic_1 | you can trim it down if you only include the components you need | 19:37 |
| mal | even then it's very big | 19:37 |
| heroic_1 | see the remove-X xmls here https://github.com/marina-bay/sailfish-android-manifest | 19:37 |
| heroic_1 | lots of people don't know that you can omit stuff and then complain how bloated android is | 19:38 |
| heroic_1 | (which it is, just not as much) | 19:38 |
| mal | heroic_1: on top of which manifest do you use that local manifest? | 19:38 |
| heroic_1 | the manifest I just linked :) | 19:38 |
| mal | ok | 19:39 |
| heroic_1 | I had to assemble it myself, which I am kinda grumpy about | 19:39 |
| heroic_1 | the mer-hybris/android repo is incomplete | 19:39 |
| mal | so you used that for system lib build? | 19:39 |
| mal | heroic_1: how is it incomplete? | 19:39 |
| mal | it works fine | 19:40 |
| mal | for hybris-hal build | 19:40 |
| mal | which it's meant for | 19:40 |
| heroic_1 | https://github.com/mer-hybris/android/blob/hybris-sony-aosp-8.1.0_r52_20190206/default.xml | 19:40 |
| mal | not sure system lib build | 19:40 |
| heroic_1 | it's missing droid-hal-version | 19:40 |
| heroic_1 | and other stuff which I don't remember off the top of my head | 19:40 |
| mal | heroic_1: like I said, those are usually built on OBS | 19:40 |
| heroic_1 | ye I know now | 19:41 |
| heroic_1 | just as a tip | 19:41 |
| heroic_1 | it is much easier to keep the default android manifest and then add other files | 19:41 |
| mal | for local builds you define the needed repos in local manifest | 19:42 |
| heroic_1 | see e.g. how omnirom does it https://github.com/omnirom/android | 19:42 |
| heroic_1 | they keep the default android manifest(handy for when it gets a bump) and the only change they make is to add an "include" directive for their custom stuff | 19:42 |
| mal | but local manifest way is also used in hybris builds | 19:42 |
| mal | that is where people add needed custom repos like additional device repos etc | 19:43 |
| heroic_1 | yes, I would recommend local manifest for device-specific stuff | 19:43 |
| heroic_1 | https://github.com/marina-bay/sailfish-android-local-manifests-sony | 19:43 |
| heroic_1 | right now it is all mashed together in one single xml | 19:43 |
| mal | heroic_1: sony hybris manifests are special | 19:43 |
| mal | heroic_1: check lineage hybris manifests and you can see those don't have device repos or stuff like that | 19:44 |
| heroic_1 | by "lineage" you mean https://github.com/mer-hybris/android/blob/hybris-15.1/default.xml ? | 19:44 |
| mal | yes | 19:44 |
| mal | heroic_1: I think you have somehow misunderstood some things in hybris manifests | 19:45 |
| heroic_1 | all the sailfish-X.xml files can be ripped out if only wanting to build the "hybris-hal" target | 19:45 |
| heroic_1 | I keep them because to me it is saner to use repo to manage my droid-X folders instead of messing with git submodules | 19:46 |
| mal | for multidevice build env I have automatic symlinking in shell script to handle adaptation repos | 19:47 |
| heroic_1 | see how you had to explain so much in irc here? I think it would be better to have an introduction to the "sailfish way" in the docs | 19:49 |
| heroic_1 | it gets especially confusing at the intersection of android and sailfish | 19:49 |
| mal | well that is the HADK pdf | 19:49 |
| mal | in my opinion you are overthinking the whole thing, you are not the first one to do so | 19:50 |
| Mister_Magister | sfos is better with documentation about building. on android noone is gonna help you. on sfos we have mal <3 | 19:51 |
| heroic_1 | mal: could very well be. but improvements are always a possibility | 19:51 |
| mal | of course | 19:52 |
| heroic_1 | and a new perspective is something to be cherished | 19:52 |
| heroic_1 | if you're used to a certain way of things, you might not notice some things that are stupid or broken | 19:52 |
| Mister_Magister | tru | 19:52 |
| heroic_1 | imma go write up some things so we can properly discuss them | 19:53 |
| heroic_1 | irc is not a good medium for this | 19:53 |
| mal | heroic_1: after dropping systemimage we should think a generic way to make sure fstab and eventd.rc are built | 19:53 |
| mal | and build props | 19:53 |
| mal | but build props are not the problem since those come from system partition | 19:55 |
| mal | heroic_1: maybe the reason you needed systemimage in there is because you used the same source tree for all android libs and not just for the stuff used in droid-hal rpms? | 19:56 |
| mal | that is not how it's supposed to be done | 19:56 |
| heroic_1 | yes I pretty much copy the thing wholesale | 19:56 |
| heroic_1 | remember, I started from the nile repos | 19:56 |
| heroic_1 | not the hadk way | 19:56 |
| heroic_1 | Hence my asking how it's normally done | 19:56 |
| mal | yes, but still hybris manifest is used only for hybris-hal build, system.img is built using clean aosp tree | 19:57 |
| mal | or lineage tree dependending on which base is used | 19:57 |
| heroic_1 | Ok so you get a "clean" regular lineage build that goes onto the system part | 19:59 |
| heroic_1 | or aosp for that matter | 19:59 |
| heroic_1 | the difference is the boot.img with the kernel and init | 19:59 |
| heroic_1 | and that you push the sailfish rootfs onto the userdata part under /data/.sailfish | 20:00 |
| mal | hybris manifest has many patched repos | 20:00 |
| heroic_1 | do I have that right? | 20:00 |
| heroic_1 | ah ok so when you're building lineage/aosp you're already building with patched framework/bionic/etc? | 20:01 |
| mal | yes, normal community builds use a clean android base, so system, vendor and such partition, then sailfish creates custom boot image called hybris-boot.img and a zip that is installed via recovery and install the sfos rootfs to userdata partition | 20:01 |
| mal | in official way the difference is that system and vendor are in rpms packages inside a flashable sfos image which contains rootfs | 20:02 |
| mal | heroic_1: no, patched stuff is built in hybris-hal build, the clean lineage/aosp image is different and built separately using upstream manifest | 20:03 |
| mal | it really shouldn't take this long to explain :) | 20:04 |
| mal | it's very simple | 20:04 |
| heroic_1 | eh wait where does the hybris-hal build go? | 20:05 |
| heroic_1 | into /data/.sailfish? | 20:05 |
| heroic_1 | afaics hybris-hal is hybris-boot.img and some other stuff | 20:05 |
| heroic_1 | (sorry for breaking up your flow) I just checked the available build targets("make modules") and I can't see anything related to build.prop or fstab | 20:05 |
| heroic_1 | but you can manually build "fstab.kagura" so now we need a way for uevent.rc and build.prop | 20:06 |
| heroic_1 | the fstab target is reliant on having "LOCAL_MODULE := fstab.$(TARGET_DEVICE)" configured in android's device/vendor/$DEVICE tree makefiles | 20:07 |
| mal | heroic_1: hybris-hal build goes to droid-hal rpms i.e. to sailfish rootfs | 20:08 |
| heroic_1 | ok got it | 20:08 |
| heroic_1 | thank you for all the patience | 20:08 |
| mal | this took longer than expected so I didn't get any development done tonight | 20:08 |
| heroic_1 | btw are any of you affiliated with jolla? | 20:09 |
| heroic_1 | because I think getting sailfish x on kagura is pretty much as easy/difficult as on discovery | 20:09 |
| heroic_1 | they are easy to port but also plagued by the same problems | 20:09 |
| heroic_1 | so if you're developing for one, might as well dev for the other | 20:10 |
| heroic_1 | and get some cash flow easy peasy | 20:10 |
| Mister_Magister | afaik mal isn't a jolla employee | 20:15 |
| Mister_Magister | that's what makes him an angel | 20:15 |
| krnlyng | :D | 20:15 |
| Mister_Magister | krnlyng: ain't i right xd | 20:16 |
| mal | Mister_Magister: not accurate anymore, I work for Jolla | 20:16 |
| Mister_Magister | oh | 20:16 |
| Mister_Magister | mal: but you weren't | 20:16 |
| mal | yep | 20:16 |
| Mister_Magister | mal: since when | 20:16 |
| mal | couple of months | 20:17 |
| Mister_Magister | whew | 20:17 |
| Mister_Magister | i got outdated info | 20:17 |
| Mister_Magister | you changed your job or doing jolla job as second job? | 20:17 |
| mal | well this is the first time I mention that in public | 20:17 |
| mal | changed my job | 20:17 |
| Mister_Magister | whoa | 20:17 |
| Mister_Magister | nice | 20:18 |
| Mister_Magister | you are still an angel for me <3 | 20:18 |
| Mister_Magister | mal: but health problems didn't change like your job? | 20:18 |
| mal | not yet | 20:18 |
| * Mister_Magister sad beep | 20:19 | |
| heroic_1 | whatever it is, get well soon! | 20:19 |
| mal | probably it can't get much worse anymore :D | 20:19 |
| heroic_1 | and don't spend the weekend arguing with fools like me ;) | 20:19 |
| Mister_Magister | heroic_1: so go back with me a couple months ago. imagine single guy doing shitload of work for sfos helping shitload of people even total idiots like me | 20:20 |
| Mister_Magister | ain't that angel | 20:20 |
| Mister_Magister | and doing that just because of passion | 20:21 |
| mal | that was one of the reasons for my problems, helping too much all the time | 20:22 |
| Mister_Magister | and that is both beautiful and sad how helping others hurts you | 20:23 |
| Mister_Magister | i guess there is nothing for free if you want to give something to others (help) something needs to be taken from you (health for example) | 20:23 |
| Mister_Magister | cruel world | 20:23 |
| Mister_Magister | was there someone who was porting huawei p20? | 21:00 |
| piggz | mal: ?! is the majority! :P | 21:39 |
| Mister_Magister | piggz: wdym | 21:40 |
| mal | piggz: ?! is only in vibrator conditionals, of course there are more of those than other probably | 22:04 |
| mal | piggz: doesn't make it any more correct :P | 22:04 |
| Mister_Magister | mal: i see im out of topic :) | 22:19 |
| mal | Mister_Magister: we are talking about ifs here https://github.com/mer-hybris/droid-hal-version/blob/master/droid-hal-version.inc | 22:42 |
| Mister_Magister | kek | 22:42 |
| mal | and the PR in that repo | 22:42 |
Generated by irclog2html.py 2.17.1 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!