**** BEGIN LOGGING AT Tue Mar 26 02:59:56 2019
Mar 26 06:17:44 <ubptgbot> aa_sokolov was added by: aa_sokolov
Mar 26 11:48:06 <ubptgbot> <Tygerpro> (Sticker, 512x512) https://irc.ubports.com/trMAOHLC.webp
Mar 26 11:48:57 <ubptgbot> <aa_sokolov> (Sticker, 512x512) https://irc.ubports.com/0Uad81Ri.webp
Mar 26 18:33:48 <Tofe> question: apart for the "partname" information, does halium-boot really need udev for anything else?
Mar 26 18:35:48 <ubptgbot> <UniversalSuperBox> I don't believe so
Mar 26 18:36:24 <ubptgbot> <UniversalSuperBox> But it's been a while since I was in it every day
Mar 26 18:37:04 <Tofe> because on our side, we're going to switch to mdev for our initrd with a little patch to add the partname symlinks; and indeed, it would be really simple to handle the uevent information by hand in halium's init script
Mar 26 18:37:59 <ubptgbot> <UniversalSuperBox> I'm definitely open to it
Mar 26 18:38:10 <Tofe> (the reason is, with recent udev we got some weird delays when udev is started; and I have always be annoyed by this big dependency just for some little aliases)
Mar 26 18:38:22 <Tofe> s/be/been/
Mar 26 18:39:16 <ubptgbot> <UniversalSuperBox> However it was always nice to have a sane Busybox and coreutils coming along for the ride, unlike with the Android tree sometimes
Mar 26 18:40:42 <Tofe> Well, I can give you my little mdev script which does the symlinks ( https://paste.ubuntu.com/p/TtPdjPmyV8/ basically ), but I don't want to remoe the call to "udevadm settle" as long as someone uses udev
Mar 26 18:42:19 <ubptgbot> <UniversalSuperBox> I'm sure that someone presented something similar while I was trying to get us over to halium-boot but I ignored them. Maybe because I didn't understand mdev.
Mar 26 18:43:05 <Tofe> btw, mdev is part of busybox - not sure if that fits the "sane busybox" definition :)
Mar 26 18:43:33 <ubptgbot> <UniversalSuperBox> sane busybox meaning Debian's, not a vendored version from 2014 with patches omitted
Mar 26 18:43:55 <Tofe> ah, yes, I see :)
Mar 26 18:44:18 <ubptgbot> <UniversalSuperBox> https://github.com/Halium/projectmanagement/issues/33 … https://github.com/Halium/projectmanagement/issues/55
Mar 26 18:45:33 <ubptgbot> <UniversalSuperBox> Basically meet those things and we're golden
Mar 26 18:46:41 <Tofe> basically what I could propose would be to browse /sys/class/block/*/uevent to find the needed PARTNAME=xxx
Mar 26 18:46:55 <ubptgbot> <UniversalSuperBox> I also started to try and standardize the halium-boot behavior in a way it could be reimplemented in a simpler way: https://github.com/Halium/docs/pull/77
Mar 26 18:48:53 <Tofe> ah, interesting !
Mar 26 18:49:15 <ubptgbot> <UniversalSuperBox> The kernel module stuff can be ignored
Mar 26 18:49:46 <ubptgbot> <Thespartann> (Sticker, 512x347) https://irc.ubports.com/0NHn0E6A.webp
Mar 26 18:50:13 <ubptgbot> <UniversalSuperBox> It's not implemented and I don't think it can be implemented
Mar 26 18:50:44 <ubptgbot> <UniversalSuperBox> sanely at least
Mar 26 18:52:16 <Tofe> it could be a bit complex yes; and most of the time we're already deep in userland when we want some modules (like wlan) to be loaded
Mar 26 18:52:31 <ubptgbot> <UniversalSuperBox> Well, you need to put the modules in the right place
Mar 26 18:52:44 <ubptgbot> <NotKit> that could be handled by init system instead?
Mar 26 18:52:45 <ubptgbot> <UniversalSuperBox> But realistically Android can handle loading its own modules
Mar 26 18:54:37 <ubptgbot> <UniversalSuperBox> @NotKit, Point of the macro-initramfs is allowing the distro to care about roughly the same things it cares about on the desktop
Mar 26 18:55:24 <ubptgbot> <NotKit> but it doesn't work this way in reality since you have to care about of tons other things, so it just complicates the initramfs and other matters instead
Mar 26 18:56:35 <ubptgbot> <UniversalSuperBox> @UniversalSuperBox, That is to say, these never went away
Mar 26 18:59:34 <Tofe> @UniversalSuperBox: doing it like a desktop initrd will probably quickly become a bit too specialized for the distribs
Mar 26 19:00:50 <Tofe> today, in LuneOS, we can simply include the main halium script and overload one or two functions, and it can be integrated smoothly in our main toolchain
Mar 26 19:02:37 <Tofe> (it's not really a designed usage of hybris-boot though :) , but it works well !)
Mar 26 19:02:56 <ubptgbot> <UniversalSuperBox> Wait, what are you doing again?
Mar 26 19:03:54 <Tofe> we build our own boot.img, with our main toolchain, directly: kernel, initrd... all is done with OpenEmbedded.
Mar 26 19:04:31 <ubptgbot> <UniversalSuperBox> I see
Mar 26 19:04:41 <ubptgbot> <UniversalSuperBox> What was it about the halium script then?
Mar 26 19:05:43 <ubptgbot> <UniversalSuperBox> Also, does OE install a Debian rootfs? Is that a way we can raise the white flag? :P
Mar 26 19:05:52 <Tofe> well we do want Halium's init too, which does some wonderful things; so we initialize the bare minimum (/proc,/sys,/dev) and we call mountroot from our main init script
Mar 26 19:06:13 <ubptgbot> <UniversalSuperBox> What are those wonderful things? :)
Mar 26 19:06:43 <Tofe> all the mounts logic, mainly
Mar 26 19:07:04 <ubptgbot> <UniversalSuperBox> Well, glad it's useful for something then
Mar 26 19:08:01 <Tofe> also it prepares the rootfs in a way that fits the Halium android image, so we really don't want to duplicate this
Mar 26 19:09:12 <Tofe> OE doesn't install a Debian rootfs, no; there might be some pre-made images out there, but we just use the minimal one
Mar 26 19:10:28 <Tofe> on our side, we just need busybox, some e2fs utils, an init script, and that's all; so that's what our image contains
Mar 26 19:11:05 <ubptgbot> <UniversalSuperBox> Well, basically everything that is done by the halium script is specified in the document I proposed, so comments there are much appreciated
Mar 26 19:13:25 <Tofe> sure
Mar 26 19:14:47 <ubptgbot> <UniversalSuperBox> It's been over a year since the PR was proposed 😓
Mar 26 19:15:41 <Tofe> halium-boot is a bit in-between, in the sense that it's both generic, but in a context (i.e. smartphones) that is usually quite specialized per device or per OS
Mar 26 19:16:26 <Tofe> I'll see what I can contribute to the discussion :)
Mar 26 21:08:24 <ubptgbot> <nanu_c> @NotKit can you help to find what's wrong with hw composer?
Mar 26 21:09:44 <ubptgbot> <NotKit> what is the device?
Mar 26 21:10:09 <ubptgbot> <Thespartann> @nanu_c, Send da logs brah
Mar 26 21:11:29 <ubptgbot> <nanu_c> moto g5s plus
Mar 26 21:11:36 <ubptgbot> <nanu_c> sanders https://pastebin.com/i3Mk3CWw
Mar 26 21:14:41 <ubptgbot> <nanu_c> and this is strace https://pastebin.com/Pz6Mecet
Mar 26 21:35:40 <ubptgbot> <nanu_c> there is no /system/lib/libtinyxml.so /system/lib/libgui.so
Mar 26 21:36:50 <ubptgbot> <Thespartann> What about trying to get those from stock?
Mar 26 21:38:22 <ubptgbot> <NotKit> which rootfs is that? device is caf
Mar 26 21:38:52 <ubptgbot> <nanu_c> halium-rootfs-20170630-151006.tar.gz
Mar 26 21:40:09 <ubptgbot> <nanu_c> And I found the files in stock and building now. Do i need another roofs for caf?
Mar 26 21:49:22 <ubptgbot> <NotKit> I do not know for Halium reference rootfs, but there should be a link to CAF repository for it somewhere
Mar 26 21:51:41 <ubptgbot> <nanu_c> so it's better to try pm-caf?
Mar 26 21:52:30 <ubptgbot> <NotKit> no idea about reference or pm-caf, worked only with ubports one recently
Mar 26 23:07:57 <ubptgbot> <nanu_c> ``` … binding file /usr/lib/arm-linux-gnueabihf/libhybris/eglplatform_hwcomposer.so [0] to /usr/lib/arm-linux-gnueabihf/libhybris-hwcomposerwindow.so.1 [0]: normal symbol `_ZN22HWComposerNativeWindow5setupEP16gralloc_module_tP14alloc_device_t' … Segmentation fault … ``
Mar 26 23:08:03 <ubptgbot> <nanu_c> [Edit] ```binding file /usr/lib/arm-linux-gnueabihf/libhybris/eglplatform_hwcomposer.so [0] to /usr/lib/arm-linux-gnueabihf/libhybris-hwcomposerwindow.so.1 [0]: normal symbol `_ZN22HWComposerNativeWindow5setupEP16gralloc_module_tP14alloc_device_t' … Segmentation fault```
Mar 26 23:20:04 <ubptgbot> <K31j0> what's the state of halium-8.0?
**** ENDING LOGGING AT Wed Mar 27 02:59:57 2019