**** BEGIN LOGGING AT Sat Feb 03 03:00:01 2018
Feb 03 07:49:46 <tgBot1> <Progromizd> by running: … ./mer_verify_kernel_config '/kernel/doogee/x5pro/arch/arm/configs/X5PRO_6735m_defconfig' … it returns 31 warnings and 14 errors. I have to fix manually all missed wariables which mentioned as an ERROR. Is is necessary/recommended to do the same to fix ALL WARNINGS ? … WARNING: CONFIG_NET_NS is invalid, It is unset … ERROR: CONFIG_TIMERFD is invalid, It is unset  and so on
Feb 03 07:50:01 <tgBot1> <theimpulson> @Progromizd, yes
Feb 03 07:50:11 <tgBot1> <theimpulson> some might be optional though!
Feb 03 08:15:48 <tgBot1> <Progromizd> @theimpulson ERRORs fixed, Now I have 31 WARNINGs (25 optional). Is it bad idea to enable they all?
Feb 03 08:20:39 <tgBot1> <JBBgameich> You should fix the warnings too
Feb 03 08:21:06 <tgBot1> <Progromizd> WARNING: CONFIG_UEVENT_HELPER_PATH is invalid … It is unset … Allowed values : "", ! … Comment says: should be empty, if you want to use systemd without initramfs. … - What is correct value for this param? Do i need initramfs (though, yes)?
Feb 03 08:21:42 <tgBot1> <JBBgameich> CONFIG_UEVENT_HELPER_PATH=""
Feb 03 08:22:01 <tgBot1> <JBBgameich> @JBBgameich, Just do not enable CONFIG_USER_NS on kernel 3.4 or 3.10
Feb 03 08:23:25 <tgBot1> <Progromizd> kernel is 3.18
Feb 03 08:31:34 <tgBot1> <Progromizd> what means "!"  for allowed variants?
Feb 03 08:43:15 <tgBot1> <Progromizd> @JBBgameich, what this means? … ./fixup-mountpoints … ./fixup-mountpoints: 12: shift: can't shift that many
Feb 03 08:44:18 <tgBot1> <Progromizd> file contains lines … DEVICE=$1 … shift (12 line)
Feb 03 08:46:47 <tgBot1> <Progromizd> looks like I need to replace  … DEVICE=$1 with DEVICE=xpro, right?
Feb 03 09:03:25 <tgBot1> <Progromizd> (Photo, 1280x756) https://irc.ubports.com/MW0i0oUi/file_4018.jpg what if I have no ETC folder where it is expected to be?
Feb 03 09:03:30 <tgBot1> <Progromizd> @JBBgameich
Feb 03 09:08:25 <tgBot1> <maharudra108> @Progromizd, Nope
Feb 03 09:08:43 <tgBot1> <maharudra108> Add ur mount points as others added
Feb 03 09:16:48 <tgBot1> <Progromizd> @maharudra108 thanks, understood.
Feb 03 09:17:14 <tgBot1> <maharudra108> Np
Feb 03 09:17:17 <tgBot1> <maharudra108> :)
Feb 03 10:39:03 <tgBot1> <NotKit> *** I had packed struct size mismatch due to single accidentaly copied * after compat_uptr_t
Feb 03 10:39:05 <tgBot1> <NotKit> auch
Feb 03 10:58:05 <tgBot1> <NotKit> (Photo, 1280x961) https://irc.ubports.com/mUZJvGTD/file_4021.jpg
Feb 03 10:58:21 <tgBot1> <NotKit> I fixed that damn 32-bit compat layer, yay
Feb 03 11:40:02 <tgBot1> win8linux was added by: win8linux
Feb 03 11:53:46 <tgBot1> <Flohack> @Progromizd, That means either config line is empty, or not existing ;
Feb 03 14:31:48 <tgBot1> <win8linux> In the case of Nexus devices, is it Google or HTC/Huawei/LG/Samsung/Motorola who should be designated as the manufacturer in the manifest?
Feb 03 14:32:23 <tgBot1> <bhushanshah> depends on how repo is named in lineageos
Feb 03 14:32:30 <tgBot1> <bhushanshah> if it's google_codename then google
Feb 03 14:32:41 <tgBot1> <bhushanshah> if it's lg_hammerhead then lg
Feb 03 14:33:15 <tgBot1> <vanyasem> @bhushanshah, its lge for lg electronics iirc
Feb 03 14:33:29 <tgBot1> <bhushanshah> ah right
Feb 03 15:42:25 <ZeroPointEnergy> is there a way to reboot directly into recovery from a booted halium rootfs?
Feb 03 15:57:13 <tgBot1> <UniversalSuperBox> in theory you should be able to do something like `reboot recovery`
Feb 03 15:57:18 <tgBot1> <UniversalSuperBox> In practice it doesn't always work
Feb 03 16:01:28 <tgBot1> <Progromizd> (Photo, 1280x588) https://irc.ubports.com/EUH7WQnv/file_4031.jpg what is wrong here?
Feb 03 16:02:21 <tgBot1> <Progromizd> @JBBgameich
Feb 03 16:02:35 <tgBot1> <UniversalSuperBox> Please don't ping people out of the blue for troubleshooting. it gets really annoying.
Feb 03 16:02:53 <tgBot1> <Progromizd> ok
Feb 03 16:03:11 <ZeroPointEnergy> @UniversalSuperBox yes, googled a bit around and it seams that there are some register flags it reads, which are set by a Linux systemcall. And systemd seams to use it. "systemctl reboot recovery" did indeed work
Feb 03 16:03:12 <tgBot1> <NotKit> check /nvram line
Feb 03 16:03:17 <tgBot1> <NotKit> maybe extra space after \?
Feb 03 16:03:34 <tgBot1> <UniversalSuperBox> I think you need to check the other devices in that file to see what it's supposed to look like
Feb 03 16:03:36 <tgBot1> <UniversalSuperBox> http://docs.halium.org/en/latest/porting/build-sources.html#include-your-device-in-fixup-mountpoints
Feb 03 16:03:55 <tgBot1> <NotKit> oh, and yes, contents are wrong
Feb 03 16:03:56 <tgBot1> <UniversalSuperBox> You don't put the whole fstab line in there.
Feb 03 16:04:20 <tgBot1> <NotKit> let me pastebin my example from MTK
Feb 03 16:04:24 <tgBot1> <UniversalSuperBox> @ZeroPointEnergy, Cool.
Feb 03 16:04:58 <tgBot1> <NotKit> https://bpaste.net/show/53935d524d08
Feb 03 16:05:05 <tgBot1> <NotKit> you don't need all those partitions though
Feb 03 16:05:13 <tgBot1> <NotKit> userdata and boot should be enough in theory?
Feb 03 16:06:46 <tgBot1> <UniversalSuperBox> In reality, only userdata should be enough
Feb 03 16:06:59 <tgBot1> <UniversalSuperBox> But the script requires boot
Feb 03 16:07:13 <ZeroPointEnergy> I'm still stuck with systemd blocking. Will probably write a script which is multi-user.target is not reached within 5min dumps as much info about the state to somewhere in the rootfs or data and reboots to recovery
Feb 03 16:07:47 <tgBot1> <maharudra108> Want to ask i want to create ota package instead of .img so how to do with halium
Feb 03 16:07:54 <tgBot1> <UniversalSuperBox> You don't.
Feb 03 16:08:12 <tgBot1> <maharudra108> Why?
Feb 03 16:08:24 <tgBot1> <UniversalSuperBox> Because that's not how Halium is flashed. Use the official tools.
Feb 03 16:08:47 <tgBot1> <maharudra108> Any workaround without pc
Feb 03 16:09:04 <tgBot1> <UniversalSuperBox> How are you building it without a PC?
Feb 03 16:09:16 <tgBot1> <maharudra108> Hahaha vps
Feb 03 16:09:46 <tgBot1> <UniversalSuperBox> You can download just the system.img, hybris-boot.img, and the rootfs. That's all you'll need to flash
Feb 03 16:09:52 <tgBot1> <NotKit> how are you going to debug it without PC though?
Feb 03 16:10:00 <tgBot1> <maharudra108> @UniversalSuperBox, Hmm
Feb 03 16:10:12 <tgBot1> <maharudra108> @NotKit, If it boots then i can use adb over ssh
Feb 03 16:10:34 <tgBot1> <NotKit> em?
Feb 03 16:10:36 <tgBot1> <UniversalSuperBox> We don't run adb at all.
Feb 03 16:10:37 <tgBot1> <UniversalSuperBox> Ever.
Feb 03 16:11:07 <tgBot1> <UniversalSuperBox> So you're building Halium on a VPS
Feb 03 16:11:15 <tgBot1> <UniversalSuperBox> And you have no computer whatsoever, just the phone
Feb 03 16:11:27 <tgBot1> <UniversalSuperBox> Correct?
Feb 03 16:11:57 <tgBot1> <Progromizd> what means  "mmcblk0pXX" ? can it be random?
Feb 03 16:12:10 <tgBot1> <Progromizd> it used very often in configuration for another phones
Feb 03 16:12:12 <ZeroPointEnergy> How do you work with a VPS without a PC?
Feb 03 16:12:18 <tgBot1> <maharudra108> @UniversalSuperBox, Partially i don't have pc right now but after somedays i will on my pc
Feb 03 16:12:39 <tgBot1> <UniversalSuperBox> @Progromizd, http://docs.halium.org/en/latest/porting/build-sources.html#include-your-device-in-fixup-mountpoints
Feb 03 16:12:40 <tgBot1> <maharudra108> @Progromizd, Block address
Feb 03 16:13:07 <tgBot1> <maharudra108> @maharudra108, Assigned a permanent unique id for system partitions
Feb 03 16:13:43 <tgBot1> <UniversalSuperBox> @maharudra108, 1. Don't build Halium for your main phone. You don't want to lose data, it's just not worth it. … 2. You need a local PC to build and debug Halium.
Feb 03 16:14:30 <tgBot1> <maharudra108> @UniversalSuperBox, Abt 1st point i don't care i will recover my phone
Feb 03 16:14:39 <tgBot1> <maharudra108> 2nd seems important
Feb 03 16:15:01 <tgBot1> <NotKit> basically Halium reference rootfs won't have any UI even if it boots, since it's just for testing
Feb 03 16:15:17 <tgBot1> <NotKit> and usually you have to do fair amount of debugging before being able to run any UI
Feb 03 16:15:38 <tgBot1> <maharudra108> @NotKit, I want ubuntu touch
Feb 03 16:15:56 <tgBot1> <maharudra108> So important thing is to boot halium
Feb 03 16:20:16 <tgBot1> <Progromizd> (Photo, 878x531) https://irc.ubports.com/xduD6sNK/file_4033.jpg Fixing mount-points for device x5pro … sed: no input files
Feb 03 16:20:41 <tgBot1> <NotKit> partition numbers are wrong
Feb 03 16:21:31 <tgBot1> <maharudra108> @NotKit, Whyhe added usb
Feb 03 16:21:42 <tgBot1> <NotKit> see my pastebin for entry example, but you need to find out your mmcblk0px numbers
Feb 03 16:23:36 <tgBot1> <Progromizd> I saw, but have no idea how to define correct values for partition numbers
Feb 03 16:23:47 <tgBot1> <UniversalSuperBox> Did you read the document
Feb 03 16:24:07 <tgBot1> <Progromizd> yes, few times
Feb 03 16:24:08 <tgBot1> <NotKit> https://bpaste.net/show/2723784ba4d9 - did fixup-mountpoints not work though?
Feb 03 16:24:26 <tgBot1> <NotKit> @Progromizd, ls -la /dev/block/platform/*/*/by-name on Android
Feb 03 16:34:02 <tgBot1> <NotKit> @UniversalSuperBox why ubports-boot doesn't call fixup-mountpoints to get UBPORTS_DATA_PART?
Feb 03 16:34:15 <tgBot1> <NotKit> I noticed that it adds datapart=$(UBPORTS_DATA_PART)
Feb 03 16:34:28 <tgBot1> <UniversalSuperBox> Because that's in another directory
Feb 03 16:34:38 <tgBot1> <UniversalSuperBox> I've removed that logic from `halium-boot` entirely.
Feb 03 16:35:06 <tgBot1> <UniversalSuperBox> With udev, we can find the data partition without issues.
Feb 03 16:35:49 <tgBot1> <UniversalSuperBox> https://github.com/Halium/projectmanagement/issues/55
Feb 03 16:37:09 <tgBot1> <Progromizd> @NotKit, run this cmd on physical device ?
Feb 03 16:37:15 <tgBot1> <NotKit> yes
Feb 03 16:57:31 <tgBot1> <Progromizd> that, worked. I have found all partiotions number, but is it ok that my current phone Android version is 5.1 ?
Feb 03 16:57:42 <tgBot1> <UniversalSuperBox> If you're using halium-5.1 sure
Feb 03 17:00:27 <Tofe> Oh, I just noticed a typo here: https://github.com/JBBgameich/initramfs-tools-halium/blob/halium/scripts/halium#L227
Feb 03 17:00:50 <Tofe> The "partition" mode is probably not used yet, but it'd still be good to fix it :)
Feb 03 17:02:24 <tgBot1> <UniversalSuperBox> damn it
Feb 03 17:02:27 <tgBot1> <UniversalSuperBox> I knew I'd do that
Feb 03 17:02:42 <tgBot1> <UniversalSuperBox> Thanks
Feb 03 17:03:27 <tgBot1> <UniversalSuperBox> Fixed
Feb 03 17:03:38 <Tofe> Great :)
Feb 03 17:05:50 <Tofe> I was having a look at halium-boot (from a LuneOS point of view), and how to integrate initramfs-tools-halium into our build toolchain
Feb 03 17:06:46 <Tofe> As we use OpenEmbedded/Yocto and not a Debian-like build environment, it may require a bit of work
Feb 03 17:07:19 <tgBot1> <UniversalSuperBox> Do you guys update the boot and initrd partitions?
Feb 03 17:08:08 <Tofe> mmh not sure what you mean; we do flash the boot partition, and build our own initrd
Feb 03 17:08:35 <tgBot1> <UniversalSuperBox> Aha, so you're looking at replacing your own with halium-boot?
Feb 03 17:08:48 <Tofe> Yes, I'm investigating :)
Feb 03 17:08:55 <tgBot1> <UniversalSuperBox> Well, there's no need to worry about any of the Debian packaging for the initrd.
Feb 03 17:09:19 <tgBot1> <UniversalSuperBox> But you do need to have a working `debootstrap` in your PATH.
Feb 03 17:09:27 <tgBot1> <UniversalSuperBox> Actually not that bad, it runs just about anywhere
Feb 03 17:09:58 <Tofe> There are things like script/local-bottom, local-top... aren't they part of the debian "way" of building an initrd ?
Feb 03 17:10:17 <tgBot1> <UniversalSuperBox> They are. The initrd is built in a Debian environment
Feb 03 17:11:13 <tgBot1> <JBBgameich> The initrd is built in a debian stretch chroot, using initramfs-tools and a special hook for halium. But it should work with all rootfs
Feb 03 17:11:30 <Tofe> I'm not sure yet which level of integration would be the best for us; we are already in a chrooted environment, we already have our initrd dependencies and so on
Feb 03 17:14:15 <Tofe> But well, that's why I'm looking into it; I'm just at the very beginning, so I'll continue my study
Feb 03 17:14:35 <tgBot1> <UniversalSuperBox> If you need anything else from it, just toss it in the issue and we'll see what we can do
Feb 03 17:14:51 <Tofe> ok thanks
Feb 03 17:15:01 <tgBot1> <UniversalSuperBox> Oh! Is your boot image not built in an Android tree?
Feb 03 17:15:51 <Tofe> hehe, nope :)
Feb 03 17:16:07 <tgBot1> <UniversalSuperBox> Oh.
Feb 03 17:16:37 <tgBot1> <UniversalSuperBox> We don't build the whole initrd; rather we grab it from GitHub Releases
Feb 03 17:16:50 <Tofe> But that's open to discussion too. Today we try to integrate what makes sense in our toolchain, so that we have a consistent output image
Feb 03 17:19:15 <Tofe> From what I can see, we could either delegate completely boot.img's build, or we could continue to build our own, just reusing halium's initrd scripts
Feb 03 17:19:56 <Tofe> Either way it would mean a few changes in term of naming and "flashing" on our side
Feb 03 17:20:22 <tgBot1> <UniversalSuperBox> I'd say it'd be better if we could agree on one way to do the bootimg
Feb 03 17:21:01 <tgBot1> <UniversalSuperBox> Simply because we're looking at "The Way" to make a GNU/Linux for Android device
Feb 03 17:21:02 <tgBot1> <UniversalSuperBox> s
Feb 03 17:22:37 <Tofe> Yes, I agree; and on our side we are not interested in redoing the Android integration work you've already done :)
Feb 03 17:24:11 <tgBot1> <UniversalSuperBox> I'm not sure I understand... which Android integration work?
Feb 03 17:24:52 <Tofe> well, for instance, the initrd scripts here, with all the mounts, etc
Feb 03 17:25:18 <tgBot1> <UniversalSuperBox> Oh, you already have things for that?
Feb 03 17:25:53 <tgBot1> <UniversalSuperBox> Or are you saying, "It'd be really nice to use halium-boot because of the things it has"
Feb 03 17:26:28 <Tofe> I'm more saying, it'd be really nice to use halium-boot because of the things it does better than us
Feb 03 17:26:35 <tgBot1> <UniversalSuperBox> Ohhh
Feb 03 17:26:47 <tgBot1> <UniversalSuperBox> I was not connecting with you at all. :)
Feb 03 17:27:29 <Tofe> :) no problem
Feb 03 17:30:22 <Tofe> Currently our way of using Halium's rootfs is quite different: /system is already in LuneOS's rootfs, we do the initramfs extraction only when starting lxc, all the mounts (firmware, etc) is done via our fstab and systemd
Feb 03 17:31:14 <Tofe> All these things would need to be adapted before doing the switch to halium-boot
Feb 03 17:36:28 <Tofe> Some intermediate steps can be identified though: use a rootfs.img directly as halium-boot does, reuse halium-boot's script (but within our toolchain), etc
Feb 03 17:37:53 <Tofe> And when the gap will be a thiner, we'll be able to discuss on how to finally unify the bootimg
Feb 03 17:40:01 <tgBot1> <UniversalSuperBox> Cool
Feb 03 17:42:45 <tgBot1> <NSA_AMERICA> @UniversalSuperBox, Ubports boot+ hubris boot = halium boot?
Feb 03 17:43:04 <tgBot1> <UniversalSuperBox> @NSA_AMERICA, https://github.com/Halium/projectmanagement/issues/55
Feb 03 17:45:34 <tgBot1> <NSA_AMERICA> Damn.. sounds interesting..
Feb 03 17:45:53 <tgBot1> <NSA_AMERICA> Would Love to test..
Feb 03 17:46:09 <tgBot1> <UniversalSuperBox> That's a heading on that issue. :)
Feb 03 17:47:14 <tgBot1> <NSA_AMERICA> Yes.. i read the whole issues :P
Feb 03 17:54:50 <tgBot1> <UniversalSuperBox> Tofe, do you have any kernel configs that are different from Halium's? Do you use a LSM?
Feb 03 17:57:36 <tgBot1> <UniversalSuperBox> Heheh, I fixed Bullhead. Turns out enabling all the kernel options really helps. :P
Feb 03 17:57:58 <tgBot1> <UniversalSuperBox> oh this is not fixedc
Feb 03 17:57:59 <Tofe> No, we reuse the defconfig directly, so it should be the same
Feb 03 17:58:09 <Tofe> LSM ?
Feb 03 17:58:16 <tgBot1> <UniversalSuperBox> SElinux, AppArmor
Feb 03 17:58:19 <tgBot1> <UniversalSuperBox> TOMOYO
Feb 03 17:58:27 <Tofe> ah, no, we disable that, too much trouble
Feb 03 17:58:53 <tgBot1> <UniversalSuperBox> Cool. I'm trying to figure out how we can all reconcile our configs.
Feb 03 17:59:28 <Tofe> Lately we made some efforts to also unify the source code, as we had quite a few patches, mainly to support newer GCC
Feb 03 17:59:47 <tgBot1> <UniversalSuperBox> Ahh
Feb 03 17:59:56 <Tofe> But are upstreamed to you now, that's fixed
Feb 03 18:00:20 <Tofe> Maybe only mido is still on the way to be tested, but the PR is already done
Feb 03 18:00:27 <tgBot1> <UniversalSuperBox> I ask because UT uses AppArmor. Distros who don't use it can just ignore it.
Feb 03 18:01:02 <Tofe> Yes, we ignore it :)
Feb 03 18:25:04 <tgBot1> <Walid> why not change upstart by systemd on UT? is it difficult to do it ?
Feb 03 18:27:51 <tgBot1> <UniversalSuperBox> It is. The work was started but not finished by Canonical.
Feb 03 18:28:23 <tgBot1> <UniversalSuperBox> We'll have to do it for any updates after Xenial
Feb 03 19:09:06 <tgBot1> <Mattia990> Hi guys! Someone has already resolved the problem that i got now, Need i to follow this guide? https://github.com/docker/for-aws/issues/111
Feb 03 23:35:26 <tgBot1> <win8linux> Should I be concerned when `mer-kernel-check` says that almost all parameters are unset?
Feb 03 23:37:46 <tgBot1> <win8linux> Here's the output: https://paste.ubuntu.com/26515613/
**** ENDING LOGGING AT Sun Feb 04 03:00:01 2018