Thursday, 2019-03-07

T4austenite was added by: austenite05:35
vknechtMal, Piggz: hello :-) I didn't give up on adding other buttons like eg. "Share", so that's why there's rowBottom06:06
sledgesPSA: SFOS community collab. disucussion in #mer-meeting in just under half-hour08:34
heroic_1Hey, is there an agreed-upon folder location for the hybris parts? For the HABUILD_SDK, there is ANDROID_ROOT="$HOME/hadk", but where are the "rpm/", "rpm/dhd/", "hybris", "hybris/mw/*" etc folders supposed to be?11:56
heroic_1Reason I'm asking is that I'd like to reference a shared helper script from d-h-d in hybris-boot, but I guess I'll have to put the helper script into hybris-boot for now11:57
T4vvreddy was added by: vvreddy13:36
*** OhYash1 is now known as ohyash15:08
heroic_1I have a proposal for pushing the mountpoint info for the fixup-mountpoints operation to the device repos instead: , then add the mapping in the droid-hal-$DEVICE folder like this: , then switch hybris-boot to it as well: https://github19:58
heroic_1It's more of a mockup at this point, but I think it's not sustainable to keep the mountpoint info in one unwieldy bash script in hybris-boot, especially considering no one seems to feel responsible for merging new fixup PRs(thus forcing everyone to use forks)20:00
malheroic_1: you know you can use the existing hybris-boot repo as submodule to add custom fixup?20:02
malso no need to fork it really20:03
heroic_1mal: I did not know that(although I see it in now with the ../fixup-mountpoints inclusion) but I'm not seeing anyone do it20:17
malit's not widely know feature20:18
heroic_1Can we nevertheless add some logic to HABUILD_SDK to let it know about the PLATFORM_SDK side of things?20:18
heroic_1Just advise people to set e.g. PLATFORM_SDK_ROOT or sth20:18
heroic_1Although that may clash with the location of /srv/mer20:19
malnot sure what you mean20:19
heroic_1mal: When droid-hal-* stuff references Android stuff, we can depend on $ANDROID_ROOT being available20:19
heroic_1But no such thing exists(that I know of) to do it in the other direction20:20
malthat is available both in HABUILD and PLATFORM_SDK20:20
malwhat is the exact problem?20:20
heroic_1Say you structure the sailfish/mer side of things in /home/user/sailfish. Let's say that is $PLATFORM_SDK_ROOT20:21
heroic_1And have the HABUILD_SDK stuff in /home/user/hadk20:21
heroic_1Following so far?20:21
heroic_1Ok, where do you put your sailfish stuff when you build locally then? I mean any location will do20:22
heroic_1That's what I personally do too, but there is nothing in the HADK or anywhere that mandates this20:22
malyou are probably overthinking this20:23
heroic_1Can we either have a variable or mandate it20:23
malI really cannot understand what the problem is20:23
malyou can use platform sdk to build anywhere if you want to build some random packages20:23
heroic_1mal, every time I have some suggestion to improve the horribly hack-ish way stuff is done in mer/sailfish, you say stuff is fine as it is20:24
malbut for actual porting stuff you anyway use build_packages.sh20:24
heroic_1Can I convince you that some stuff could be improved, if only we changed a few basic things20:24
malheroic_1: you need to give some problem you want to solve20:24
malwe also need to take into account OBS builds20:25
heroic_1I know OBS complicates stuff, yes20:25
malalso we cannot break compatibility too much20:26
heroic_1There are some other things that I'd like to improve that depend on knowing the root of the PLATFORM_SDK and droid-*-* repos being in certain places20:27
heroic_1But without having such a mechanism I don't really know how to even approach them without lots of "if [ -d ...]" stuff20:28
malI cannot understand why you want something to depend on root of platform_sdk, I mean there is no root in there, ANDROID_ROOT is the only thing20:28
heroic_1Yeah, then let's mandate that people start any sailfish stuff at $ANDROID_ROOT20:29
malwhat do you mean, I'm still completely missing the point20:29
malduring ehat build do you want to change something?20:30
heroic_1during the sailfish build process20:30
malwhich step of it?20:30
heroic_1e.g. d-h-d20:30
heroic_1But I get that you'd want stuff separated20:31
malso what is wrong with the current way of having dhd in ANDROID_ROOT20:31
malI'm probably missing some fundamental part of information20:31
heroic_1My wish would be that for any sailfish build you do, you can depend on droid-config-$DEVICE, droid-hal-$DEVICE and droid-hal-version-$DEVICE being available20:31
heroic_1So you do not have to specify things in every repo again20:32
heroic_1one rpm_device20:32
heroic_1one straggler_files20:32
heroic_1etc etc20:32
heroic_1*available in a static location20:32
malwhat repo?20:32
heroic_1every repo20:32
heroic_1d-h-c defines rpm_device20:33
heroic_1d-h-d defines rpm_device, etc20:33
malyou do know that those are built separately on OBS?20:33
heroic_1I know, but for obs you could still sync the repos to an agreed-upon locatoin20:33
heroic_1*location. The're a few kilobytes max each20:34
heroic_1ok megs but you get the point20:34
malI really don't get it20:34
malthose repos are device specific so obviously you need to define which device it is20:35
heroic_1you wouldn't need to though if you had already defined e.g. rpm_device in droid-config-$DEVICE20:36
heroic_1let your mind run wild with the possibilites20:37
heroic_1not only reduced code duplication, think further20:37
malso then droid-hal would depend on droid-config20:38
heroic_1in a way20:38
heroic_1at build time at least20:38
heroic_1and tbh most droid-* stuff is already highly interdependent already20:39
heroic_1e.g. you cannot build droid-hal-img-boot-$DEVICE without first having built droid-hal-$DEVICE-kernel20:40
malthat would probable require a lot of changes to .inc files probably20:40
heroic_1mal: I guess our philosophical differences come from your background in linux and rpm packaging, whereas I'm used to Android monolithm20:41
heroic_1The latter is more suitable to building device configs imo20:41
heroic_1And yes, we'd have to think of backward compatibility20:41
heroic_1I would write very clear transition guides20:41
malpretty sure we don't want to break official devices20:42
heroic_1The first step would only be to even define some kind of boundaries20:42
malI still find it odd to do so much work because we duplicate few lines20:42
heroic_1would you agree that my change to the fixup-mountpoints is more elagant and declarative?20:44
maldoes it handle this
heroic_1we can change the syntax, e.g. "block" ""20:54
heroic_1or "/block" "/"20:54
heroic_1it's a matter of changing the awk statements20:55
heroic_1hmm you don't even need the quotes, just:20:56
heroic_1 /block/ /20:57
heroic_1And I have a wish for sledges or whoever creates packages for the jolla repos: add "initrd-helpers", "hw-ramdisk" and "yamui" packages21:04
heroic_1I made a PR to build them automatically but I think it would be better if they were available in the repos already21:05

Generated by 2.17.1 by Marius Gedminas - find it at!