Monday, 2022-12-12

T42<elros34> hm maybe you could  somehow extract GPT  from original firmware. Sometimes you can find  parted or simply ls -l /dev/block/*by-name/* from output on some android forums00:07
T42<elros34> or make everything dynamic generated at first boot and forget about fixup-mountpoints:)00:08
T42<edp_17> Can you show me how to do this dynamic thingy? (How can I build hybris-hal with that?)00:17
T42<elros34> I do not have ready to use instruction. You build hybris-hal like always. First you would have to figure out whether external/busybox  have CONFIG_FEATURE_GPT_LABEL enabled for android base you use. This wasn't enabled on older android bases. Here is how I handle /system and /cache partitions at first boot using fdisk  (but gpt labels can be retrieved also form sysfs instead ):
T42<edp_17> Okay, I'll try. I thought mountpoints were needed for be able to build hybris-hal.00:33
T42<elros34> maybe /boot (data too?) entry is needed to complete build but still hybris-installer uses by-name path so you do not need to know blocke device00:35
T42<elros34> block*00:35
T42<elros34> I think it will be hard to make it without any mistake so it will work at first boot so not sure it's really worth00:39
T42<edp_17> Okay, I'll wait until I receive the device and check the partitions on Android side to make fixup-mountpoints.00:43
T42<edp_17> Currently, it seems there is a problem with the build environment because getting error when building hybris-hal. :D00:44
T42<adampigg> Neat, a pinephone user reported that with the latest kernel, mce and dsme reverted, phone has beeb rock solid for 2 days, waking instantly :)08:46
xmnthis is awesome!08:57
T42<edp_17> 👏 Congrats for the pinephone. I may replace sxmo with your sfos port. :)08:59
xmnnow that is a surprise statement. Most sxmo folk are pretty entrenched. :)09:00
xmnI just need to get it working again. One update left me locked out. And a new install left me with no background or ambiance (forgetting the name at the moment)09:01
T42<edp_17> I don't use that phone much for only pulling out from my drawer and updating the system on it. Sometimes, I put a different os onto it. So, I wouldn't describe myself as an entrenched sxmo fanatic. :D09:02
T42<adampigg> Whats  sxmo, second time ive seen it mentioned today!09:02
xmnhaha, I see edp_1709:02
xmnit a gesture based if all you had was terminal-ish for the ui09:03
T42<edp_17> @adampigg : Sxmo is a gesture based linux distro that uses mostly shell scripts for mobile phones:
xmnI've got to figure out why I'm having trouble with my installs. User error I'm sure. question is it easier if I install sfos onto the emmc? I've been doing sdcard and after the encrypted home dir, I just can seem to get it right.09:05
xmnAh, "Ambiences".09:06
xmnsilly name09:06
xmnTime for sleep. have a great day/night adam, edp_1709:09
T42<edp_17> Have a good sleep!09:14
T42<edp_17> Hi all! Building hybris-hal fails :
T42<edp_17> Any idea what's missing?09:20
T42<edp_17> I meant, the log shows what's missing, just Idk where from get it. :D09:20
maldo you have all repo dependencies, check the lineage.dependencies files (or something like that) in the device repos10:36
T42<edp_17> mal : I am not sure. Already found/add a few missing repos but there could be more. I'll check what you recommended.10:39
malalso do you have the vendor repo added, some devices might need it also10:40
T42<edp_17> Yes, from The Muppets I've added the missing proprietary blobs into vendor/motorola/sdm632-common. (This was the missing repo I referred to it earlier.)10:44
T42<edp_17> I've found another proprietary blob folder (ocean) that I added but still the same error.10:54
T42<elros34> first error you must fix is missing /boot entry in fstab11:03
T42<edp_17> The /boot should come from fixup-mountpoints, no?11:07
T42<elros34> I am talking about missing critical for hybris installer entry in fstab, not really related to fixup-mountpoints11:08
T42<edp_17> So, in device/motorola/sdm632-common/rootdir/etc/fstab.qccom, I should add /boot (that is missing), shouldn't I? How could I know what the /boot partition would be? (I don't have the device with me yet.)11:13
T42<elros34> it will be same as other partitions in fstab like /system */by-name/system11:16
T42<edp_17> I see. There were /dev/block/bootdevice/by-name/* so I added /dev/block/bootdevice/by-name/boot.11:19
T42<edp_17> @elros34 : Thanks, that warning is gone now :
T42<edp_17> Or at least /boot looks okay-ish now.11:23
T42<elros34> last erro is about missing lib so make sure you have added needed repos from lineage dependencies11:25
mal@edp_17 do you have all of these in local manifest
malthat android_system_qcom provides the missing dependency afaik11:27
T42<edp_17> The last three are missing.11:28
T42<edp_17> Adding them now.11:28
T42<edp_17> Ops, there is no lineage-17.1 branch in android_hardware_motorola!11:34
T42<edp_17> There is, I just didn't fork! :(11:34
T42<edp_17> Now, the mountpoint fixup data is missing :
T42<edp_17> Can I create fixup-mointpoints from the fstab.qcom I mentioned above?11:44
T42<elros34> obviously no unless you provide some dummy block device just to complete build12:52
T42<edp_17> I see. This is what I've done and hybris-hal building has completed. (I'll fix it once I got the device.)12:59
T42<edp_17> Hmm, when building hal packages, it thows an error about CONFIG_DUMMY being invalidly set to y. However, if I check my defconfig and .config, in both I have # CONFIG_DUMMY is not set. How is this possible?13:54
T42<elros34> check what .config file is really used in droid-hal-device.log14:00
T42<edp_17> It seems the .config is used from ./out/target/product/$DEVICE/obj/DTBO_OBJ/.config rather than ./out/target/product/$DEVICE/obj/KERNEL_OBJ/.config. At least based on this log:
T42<elros34> Fix is wrong but you got the idea what to to do
T42<elros34> I meant PR is wrong but you can use this for your device14:11
T42<edp_17> I see. It worked. Thanks.14:16
T42<edp_17> I just wonder why this worked for my other ports.14:16
T42<elros34> not every device have this DTBO_OBJ/.config14:17
T42<edp_17> Oh, I see. Now hal packages and droidmedia have built. :)14:22
T42<edp_17> Now I just need the real block device name and can try to package an image for this new device. :) Cool!14:23
T42<edp_17> mal : On OBS the droid-config package goes unresolvable with an error: nothing provides pkgconfig(android-headers) Is this something I can fix?14:38
T42<edp_17> I think because of hal packages were built as armv7hl however I need them aarch64. :(14:42
malare you sure you setup build env locally with correct PORT_ARCH etc14:44
T42<edp_17> Yes. This is my .hadk.env :
malhmm, what could then cause the arch to be incorrect14:46
T42<edp_17> targets are both *aarch6414:46
T42<edp_17> Droidmedia has built as aarch64, but all the rest hal packages as armv7hl14:47
mal this also has issue, it has armv7hl not aarch6414:47
T42<edp_17> Oh, yes. :(14:48
T42<edp_17> In rpm/droid-hal-$DEVICE.spec, I also have the %define droid_target_aarch64 115:11
T42<edp_17> So, I am a bit puzzled why only droidmedia is built as aarch6415:12
T42<elros34> echo $PORT_ARCH in platform sdk?15:13
T42<edp_17> On Platform the echo $PORT_ARCH gives me aarch6415:13
T42<elros34> I think you have arm sdk target, check it15:16
T42<edp_17> Yes, you are correct as I copied the url from other ports. :( Nice thought!15:20
T42<edp_17> It seems now there is a problem with toolings :
T42<edp_17> That is not achitectura specific, so I shouldn't need to re-create, should I?15:37
T42<elros34> looks like some build leftovers15:40
T42<edp_17> Yeah, somewhere. How can I tidy up?15:41
T42<elros34> look at the log you provided, search for building files, git status15:43
T42<edp_17> Hmm, I've removed all *.o files from system/core/libsparse/ and system/core/base/ but still getting the same error. :(15:59
T42<elros34> apparently not all from SIMG2IMG_SOURCES16:08
T42<edp_17> I think found that. It was rpm/dhd/helpers/usergroupgen.16:08
T42<edp_17> It was arm32 format. I've removed and then hal packages has built.16:09
T42<edp_17> Thanks!16:15
T42<edp_17> On OBS, building droid-hal-version-$DEVICE fails with this :
T42<edp_17> Do you have idea for fixing? Thanks.16:43
T42<edp_17> (Repo: devel motorola ocean)16:44
malyou seem to have some binaries in config repo, why do you need those?17:16
T42<edp_17> Oh, great! :( I've forgot them. They are for other ports (arm32). This is my first aarch64 port. I should stop copying over stuff from other ports.18:10
T42<edp_17> Thanks for looking into this.18:10
T42<edp_17> Those binaries for updatedb and locate, compiled for arm32.18:11
T42<elros34> there is mlocate in chum for armv7hl18:34
T42<edp_17> Back in time when I started building my ports with locate, chum and mlocate didn't exits. Then, when they came, I didn't remove locate from my ports.19:33
T42<edp_17> Then, I copied configs over from an arm32 port. I've spotted/fixed a few similar issues but missed this one.19:34
T42<edp_17> After removal of arm32 binaries from droid-config (surprisingly) droid-hal-version has built. :)22:50
T42<edp_17> Do you have idea on what could have caused the following? On my hammerhead, I spotted that it didn't connect to gsm network. Restarting ofono didn't help. Then, I've seen that ofono-binder-plugin was installed instead of ofono-ril-plugin. Once I installed ofono-ril-plugin, ofono started and the device connected GSM network.22:52
T42<edp_17> I am quite certain that didn't tampered the device, so I don't know how the plugin got replaced. It is strange. Oh, and I don't use pkcon, I always use zypper to install packages. The last app I installed was Whisperfish, but I don't think that could cause this. Any idea?22:55
malofono-binder-plugin is for devices with relatively new android base, at least android 8 based23:28
mal@edp_17 make sure you have something like this in your patterns
maland make sure patterns don't pull in the binder plugin23:29

Generated by 2.17.1 by Marius Gedminas - find it at!