**** BEGIN LOGGING AT Tue Oct 01 02:59:57 2019
Oct 01 03:23:57 <yocti> New news from stackoverflow: Understand how to rebuild recipe with Yocto <https://stackoverflow.com/questions/58177617/understand-how-to-rebuild-recipe-with-yocto>
Oct 01 03:39:13 <mischief> hm.. for some reason my kernel ends up inside the initramfs o.O
Oct 01 03:41:02 <bluelightning> mischief: possibly this: https://wiki.yoctoproject.org/wiki/Technical_FAQ#How_do_I_avoid_the_kernel_itself_being_pulled_into_my_image_when_installing_kernel_modules.3F
Oct 01 03:45:14 <mischief> hm, seems plausible but adding that didn't change anything.
Oct 01 03:47:58 <mischief> aaah, RDEPENDS_${KERNEL_PACKAGE_NAME}-base = "" did it
Oct 01 03:48:05 <mischief> thanks bluelightning :-)
Oct 01 03:50:06 <bluelightning> no probs
Oct 01 03:50:20 <bluelightning> hmm, I should update for KERNEL_PACKAGE_NAME, I'll do that now
Oct 01 07:21:16 <__angelo> is there a better/elegant way to create 2 similar image targets, one for prod (with something diabled) and one for devel ?
Oct 01 07:23:56 <kroon> __angelo, an .inc and two .bb maybe ?
Oct 01 07:30:29 <Chaser> or a .bbappend for the prod target
Oct 01 07:35:18 <__angelo> oh thanks, do you have in mind an example bsp i can check ?
Oct 01 07:39:13 <iceaway2_> kroon: thanks for the advice on adding FILESEXTRAPATH_prepend in my .bbappend recipe yesterday, that did the trick!
Oct 01 07:41:35 <kroon> iceaway2_, cool, glad it helped
Oct 01 07:54:11 <alessioigor> Good morning!
Oct 01 07:54:17 <alessioigor> Few problems with current master branch:
Oct 01 07:54:21 <alessioigor> *) With latest patches applied (9973f89daf systemd: fix NFS regression) on systemd my Yocto system stops to boot over network (Yeah it is NFS!)
Oct 01 07:54:25 <alessioigor> *) The SDK installation stuck at Setting it up...ls: cannot access '[...]/environment-setup-*': No such file or directory
Oct 01 07:54:35 <alessioigor> *) Using meta-intel on master branch: Exception: FileExistsError: [Errno 17] File exists: '[...]/sysroots-components/corei7-64/zlib-intel/usr/include/zlib.h' -> '[...]/work/corei7-64-voltumna-linux/alsa-utils/1.1.9-r0/recipe-sysroot/usr/include/zlib.h'
Oct 01 07:59:11 <iceaway2_> Is it possible to supply a username and password to the https-fetcher in bitbake? I am looking at the manual right now but it's not really obvious if/how it can be done.
Oct 01 08:06:04 <erbo> iceaway2_: I believe the https://<username>:<password>@<the url> should work
Oct 01 08:10:54 <Domin1k> Hi everybody.
Oct 01 08:17:34 <Domin1k> I have a recipe which installs a pre-compiled shared object which has dependencies that i have set within "DEPENDS" do i also have to set them in RDEPENDS_${PN} ? The mega-manual says: "DEPENDS alone is sufficient for most recipes" What does "most" mean here? Is it guaranteed that shared objects that come with packages that were marked as DEPENDS
Oct 01 08:17:35 <Domin1k> get installed in the final image?
Oct 01 08:29:23 <kroon> Domin1k, DEPENDS are for build-time dependencies
Oct 01 08:30:17 <amine> hi all
Oct 01 08:30:48 <amine> is there any recipe for ntpsec ?
Oct 01 08:30:57 <amine> https://github.com/ntpsec/ntpsec
Oct 01 08:31:09 <LetoThe2nd> amine: http://layers.openembedded.org/layerindex/branch/master/recipes/?q=ntpsec
Oct 01 08:31:19 <LetoThe2nd> amine: so, probably no
Oct 01 08:32:29 <amine> okay thanks i ll try to do somthing myself
Oct 01 08:37:46 <Domin1k> So in the case where my DEPENDS are just a bunch on shared objects that depend on the binary i install. I also have make sure these are set in RDEPENDS_${PN} so that i won't get undefined references at runtime?
Oct 01 08:41:18 <kroon> Domin1k, first I would just try not listing any RDEPENDS(or DEPENDS) at all, since oe-core is pretty good at automatically finding ELF runtime deps
Oct 01 08:41:19 <iceaway2_> erbo: Cannot really get it to work, I'm getting a bad request from the server. It works via curl from the command line though, with -O -L --user <name>:<pass> as arguments.
Oct 01 08:42:28 <iceaway2_> is it possible to supply additional arguments to curl? In case it's the -L that does it (I do not see that argument in the do_fetch logs).
Oct 01 08:43:13 <iceaway2_> It't not even using curl though, but wget, I just noticed.
Oct 01 08:45:01 <LetoThe2nd> iceaway2_: the core problem with the user/pass approach is that those would end up in the metadata
Oct 01 08:48:00 <LetoThe2nd> iceaway2_: the alternative is some function that dynamically creates the SRC_URI including credentials, and is passed those through local.conf or the environment
Oct 01 08:48:09 <LetoThe2nd> it can be done, but its not exactly pretty.
Oct 01 08:49:02 <Domin1k> i've already tried not using DEPENDS within my recipe of a precompiled shared object (libcef.so). This recipe just fetches this shared object and installs it to "/usr/lib". In the next step i wrote a recipe for an application that links against libcef.so. Now do_compile fails because of undefined references that are caused because of libcef.so
Oct 01 08:49:03 <Domin1k> dependencies that are missing e.g. libgtk+ etc. if i now at all dependencies of libcef.so to DEPENDS of the libcef.so-recipe my application build will succeed. I'm now wondering if it's guaranteed that the DEPENDS will land in the final Image or if i also have to add them as RDEPENDS_${PN} because otherwise i will get undefined references at
Oct 01 08:49:03 <Domin1k> startup.
Oct 01 08:53:20 <iceaway2_> LetoThe2nd: Will let the brain work a bit on how to solve this :)
Oct 01 08:53:54 <crawler> Hi guys, anyone have any idea what i do wrong here, why this test does not pass https://paste.ofcode.org/37XrnMc2DkSM9bBJmUU22BF
Oct 01 08:54:51 <yocti> New news from stackoverflow: Kernel 5.3 failes to compile: No rules to make target zImage <https://stackoverflow.com/questions/58181207/kernel-5-3-failes-to-compile-no-rules-to-make-target-zimage>
Oct 01 08:55:12 <erbo> iceaway2_: I did a quick test here, and I can specify username and password that way. I'm using http and not https though, but I doubt that matters.
Oct 01 08:58:25 <kroon> Domin1k, I would try adding gtk+ deps etc to the application recipe DEPENDS, not the lib recipe since it doesn't need them to build itself, and add nothing explicitly to the application RDEPENDS, but trust that oe-core shlibs code fill find them
Oct 01 09:03:48 <kroon> Domin1k, or like you did, which I think is what the manual states..
Oct 01 09:05:34 <Domin1k> Why specify it as a dependencie of the application instead of the shared lib? in case it would not be precompiled i had to set it directly in the recipe of the shared lib because it actually is a dependencie of the shared lib but not a build-time dependency because there is nothing to build here.
Oct 01 09:07:44 <Domin1k> OK to be sure that everything gets intalled i will set all dependencies inside the recipe of the shared library as DEPENDS and RDEPENDS.
Oct 01 09:11:58 <crawler> SDKIMAGE_FEATURES_append = " staticdev-pkgs" is this necessary to have libstc++ available in sdk?
Oct 01 09:42:16 <yacar_> Hi guys, I'd like to contribute more to yocto, I'm beginning to be experienced as a user with Yocto, however I I feel like the bug are not descriptive enough to be cleared. For instance if I take : https://bugzilla.yoctoproject.org/show_bug.cgi?id=13333 , I feel like to solve all those bug it's only required to add some "headers", what are the said SPDX header?
Oct 01 09:42:17 <yocti> Bug 13333: normal, Medium+, 3.1, newcomer, NEW , Add SPDX license headers to all source files for yocto-kernel-cache
Oct 01 09:42:48 <yacar_> probably only a matter of copy pasting them.
Oct 01 10:22:20 <crawler> anyone got few spare minutes :)
Oct 01 10:22:33 <crawler> for the issue above
Oct 01 10:26:31 <mckoan> crawler: TOOLCHAIN_TARGET_TASK_append = " libc-staticdev"
Oct 01 10:26:35 <mckoan> https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html
Oct 01 10:27:19 <crawler> oh goodness i appended libstdc++-staticdev
Oct 01 10:27:47 <mckoan> TOOLCHAIN_TARGET_TASK_append = " libstdc++-staticdev"
Oct 01 10:28:05 <crawler> yes
Oct 01 10:32:03 <crawler> this is my TARGET_TASK now
Oct 01 10:32:06 <crawler> TOOLCHAIN_TARGET_TASK_append = " protobuf protobuf-dev boost boost-dev lua lua-dev lua-staticdev asciidoc asciidoc-dev sqlite libbsd libbsd-dev tpm2-tss libtss2-mu libtss2-mu-dev libtss2-tcti-device libtss2-tcti-device-dev libtss2-tcti-mssim libtss2-tcti-mssim-dev libtss2 libtss2-dev ibmswtpm2 ibmswtpm2-dev nlohmann-json-dbg nlohmann-json-dev gcc-sanitizers gcc-sanitizers-dbg libasan libasan-dev libc-static-dev listdc++-staticdev"
Oct 01 10:32:25 <crawler> meh, mistake, its libc-statidev
Oct 01 10:34:03 <crawler> let me recompile everything and check
Oct 01 10:34:20 <crawler> thanks for the help mckoan
Oct 01 10:37:11 <mckoan> crawler: YW, let us know it it works
Oct 01 10:55:10 <yocti> New news from stackoverflow: u-boot script to allow choosing between which rootfs part to boot (RAUC) <https://stackoverflow.com/questions/58183097/u-boot-script-to-allow-choosing-between-which-rootfs-part-to-boot-rauc> || "git binary diffs are not supported" error using yocto <https://stackoverflow.com/questions/50677861/git-binary-diffs-are-not-supported-error-using-yocto>
Oct 01 11:13:36 <coretec> Hi, it seems there is a problem in meta-mingw32/thud, all qemu binaries arebroken for SDKMACHINE=x86_64-mingw32, but working fine for i686-mingw32.
Oct 01 11:14:06 <coretec> Could anyone advise on how to find the root cause for this?
Oct 01 11:15:44 <coretec> It seems there are other people with this particular problem, https://www.mail-archive.com/yocto@yoctoproject.org/msg45487.html
Oct 01 11:16:28 <coretec> and https://www.mail-archive.com/yocto@yoctoproject.org/msg45481.html
Oct 01 11:25:14 <yocti> New news from stackoverflow: How to use OpenCV with camera on Jetson Nano with Yocto/poky <https://stackoverflow.com/questions/57989992/how-to-use-opencv-with-camera-on-jetson-nano-with-yocto-poky>
Oct 01 11:26:07 <iceaway2_> erbo: strange, I will look into it again.
Oct 01 11:27:38 <yacar_> Sorry I had to switch off my computer, I couldn't see your replies about "(11:42:16) yacar_: Hi guys, I'd like to contribute more to yocto, I'm beginning to be experienced as a user with Yocto, however I I feel like the bug are not descriptive enough to be cleared. For instance if I take : https://bugzilla.yoctoproject.org/show_bug.cgi?id=13333 , I feel like to solve all those bug it's only required to add some "headers", what are the said SPDX header?"
Oct 01 11:27:39 <yocti> Bug 13333: normal, Medium+, 3.1, newcomer, NEW , Add SPDX license headers to all source files for yocto-kernel-cache
Oct 01 11:28:33 <milloni> something that i never understood but i feel like i should: what's the difference between += and _append?
Oct 01 11:30:54 <LetoThe2nd> milloni: the fomer adds a space in front automatically :)
Oct 01 11:31:09 <milloni> is that the only difference?
Oct 01 11:31:18 <milloni> i've seen people use `_append +=`
Oct 01 11:31:57 <milloni> (to be honest, i've used `_append +=` "just for good measure")
Oct 01 11:33:26 <rburton> milloni: don't do _append += because that just confuses things
Oct 01 11:33:36 <rburton> += is "add this to the variable now"
Oct 01 11:33:40 <LetoThe2nd> '_append += sounds strange'
Oct 01 11:33:45 <rburton> _append is 'after parse, extend with this value'
Oct 01 11:33:54 <mihai> milloni, it depends on the context you want to append, += is immediate, _append is processed after all the parsing is done
Oct 01 11:34:06 <milloni> hmm
Oct 01 11:34:37 <mihai> sometimes people use _append += to avoid the extra space in: _append = " value"
Oct 01 11:34:44 <milloni> yes that ^
Oct 01 11:35:00 <milloni> can you give me an example where those two different forms would be useful?
Oct 01 11:35:35 <rburton> eg a class that recipes can inherit might use DEPENDS_append = ' foo' so that DEPENDS *always* has foo in
Oct 01 11:35:42 <rburton> even if the recipe does DEPEDNS=bar
Oct 01 11:35:52 <rburton> where += would fail depending on the line order
Oct 01 11:36:12 <rburton> use += normally, append if you can't
Oct 01 11:36:49 <milloni> ah, okay, thanks
Oct 01 11:48:07 <mihai> yacar_, spdx refers to a shorter, one liner, identifier for the standard licenses headers in source code files
Oct 01 11:48:45 <yacar_> mihai; indeed, but how one should determine what the line to put?
Oct 01 11:48:46 <mihai> yacar_, https://spdx.org/ids for hint
Oct 01 11:49:15 <mihai> there's also a list of licenses and their spdx identifier there
Oct 01 11:49:46 <yacar_> Let's say I'm going to work on this bug I just unilaterally choose what license I want?
Oct 01 11:49:54 <yacar_> It doesn't make sens x)
Oct 01 11:49:58 <yacar_> *sense
Oct 01 11:55:39 <mihai> yacar_, the files should have existing license headers, the bug is to replace them with their equivalent spdx identifier
Oct 01 12:01:46 <yacar_> mihai : Ok cool I see I'll be looking into that then.
Oct 01 12:03:47 <rburton> if the source doesn't have explicit license then the intended license should be fairly obvious anyway
Oct 01 12:04:53 <ThomasD13> Hi, hen I use KERNEL_FEATURES_append, will this feature be built into the kernel, or just be as kernel module available?
Oct 01 12:11:18 <yacar_> rburton: mihai : I might sound stupid, however I can't find anywhere to replace that in the said directory.
Oct 01 12:11:57 <yacar_> If I'm looking for GPL, BSD, GPL on the directory I can't find anything relevant except in some patches.
Oct 01 12:12:41 <rburton> yacar_: i'm guessing from the license files at the top of the repo, the metadata is MIT but the scripts are GPL
Oct 01 12:13:05 <rburton> yacar_: safest to just mail bruce ashfield and ask as its his repo (paging zeddii to irc)
Oct 01 12:13:45 <rburton> (this is why we want spdx headers everywhere, as the license isn't always obvious)
Oct 01 12:15:45 <coretec> It seems there is a problem in meta-mingw32 in thud. All qemu binaries are broken for SDKMACHINE=x86_64-mingw32, but working fine for i686-mingw32. Does anybody know how to tackle this issue?
Oct 01 12:16:24 <yacar_> Yep, my point here is not only about this matter, I am (and I think some other are too) looking for bug to solve on the bugzilla but most of them are not exactly self explanatory which is the purpose of the bug description. I'd like to make the project go further, but the bugs need to filled precisely so that it's not problematic to get started.
Oct 01 12:16:50 <yacar_> Even for some simple licensing bug.
Oct 01 12:18:20 <rburton> "simple" and "licensing" don't go hand in hand
Oct 01 12:18:28 <rburton> the bug is that the licensing isn't clear
Oct 01 12:19:05 <rburton> if you want a simple yocto bug, there's a 'newcomer' tag
Oct 01 12:19:59 <yacar_> rburton: yes it is in newcomer tag ^
Oct 01 12:21:00 <rburton> engaging here or in the bug is part of the process. feel free to add a comment listing the scripts and saying that the license isnt obvious, and bruce can reply with his definite answer.
Oct 01 12:21:17 <yacar_> rburton : that's why I was assuming it was mostly a matter of finding and replacing licences
Oct 01 12:23:00 <rburton> newcomer means you don't need huge amounts of detailed knowledge.  the license bugs are just chase down the right license info, and add the headers
Oct 01 12:23:05 <zeddii> that bug is already done.
Oct 01 12:23:11 <zeddii> apparently someone didn’t update it.
Oct 01 12:23:16 <zeddii> probably me
Oct 01 12:23:19 <zeddii> commit 7604d2d1a49d88e38d5b5854209dc1435b790893
Oct 01 12:23:20 <zeddii> Author: William Bourque <wbourque@gmail.com>
Oct 01 12:23:21 <zeddii> Date:   Tue Aug 6 14:05:38 2019 -0400
Oct 01 12:23:22 <zeddii>     Add SPDX license headers to source files
Oct 01 12:23:44 <rburton> http://git.yoctoproject.org/cgit/cgit.cgi/yocto-kernel-cache/tree/scripts/rr-fix <-- no header
Oct 01 12:25:37 <rburton> zeddii: kernel-cache not kernel-tools
Oct 01 12:25:56 <rburton> (morning)
Oct 01 12:26:05 <zeddii> ah. kernel-cache!
Oct 01 12:27:40 <zeddii> and yes, rburton’s comment is correct. there’s no SPDX headers, but all the .scc and .cfg files are MIT and the scripts themselves are GPLv2 (as indicated by the copying files)
Oct 01 12:27:52 * zeddii drinks his coffee to engage his brain
Oct 01 12:27:56 <zeddii> more strace debugging today
Oct 01 12:29:13 <__angelo> seems i have an issue with loadable modules, getting :  modprobe: FATAL: Module tea.ko not found in directory /lib/modules/4.19.50-test-001+
Oct 01 12:29:54 <rburton> yacar_: there we go. if you can add the spdx headers to the scripts and a section to the readme describing the license policy as stated by zeddii then that would be ideal
Oct 01 12:30:39 <__angelo> .ko is there. Even if i see a strange path, like /lib/modules/kernel/kernel ... what could be the issue ?
Oct 01 12:31:14 <__angelo> *  /lib/modules/4.19.50-test-001+/kernel/kernel
Oct 01 12:32:44 <yacar_> zeddii : ok so it's required to also add SPDX-License-Identifier: MIT to scc and cfg files?
Oct 01 12:33:27 <zeddii> that’s what the SPDX folks tell me. So yes!
Oct 01 12:37:28 <yacar_> Ok I'll be looking into that then ! I didn't want to sound patronizing earlier, i just was a bit frustrated about the bugs descriptions that are not enough to get started.
Oct 01 13:30:37 <crawler_> hey guys, regarding problem i described here, https://paste.ofcode.org/37XrnMc2DkSM9bBJmUU22BF issue was solved by adding libc-staticdev and libstdc++-staticdev to the TOOLCHAIN_TARGET_TASK_append ---- kudos to the mckoan for helping out on this
Oct 01 13:33:01 <mckoan> crawler_: thank to letting me know. I updated my wiki with that
Oct 01 13:33:05 <mckoan> https://wiki.koansoftware.com/index.php/How_to_add_libstdc%2B%2B_to_a_Yocto_(Poky)_image
Oct 01 13:33:57 <crawler_> cheers, bookmarked ;)
Oct 01 13:34:03 <mckoan> https://wiki.koansoftware.com/index.php/How_to_add_libstdc++_to_a_Yocto_(Poky)_image
Oct 01 13:37:02 <__angelo> about my question above, just seet that insmod works, it's like /sbin/modprobe is not able to load modules
Oct 01 13:37:26 <__angelo> depmod -a has no effect
Oct 01 13:42:42 <kroon> __angelo, you have a modules.dep.bin ?
Oct 01 13:43:08 <__angelo> kroon, yes
Oct 01 13:47:52 <opennandra> hello, I'm trying to use u-boot-fw-utils fro later yocto version on building fw_printenv tools from 2010.06 u-boot and it fails with issue to cannot find stdio.h and other includes
Oct 01 13:47:55 <opennandra> any ideas?
Oct 01 13:51:15 <qschulz> opennandra: is there a reason for not using latest u-boot-fw-utils?
Oct 01 13:52:03 <qschulz> we use it for our boards even though we have older U-Boot versions for the bootloader part
Oct 01 13:52:41 <kroon> __angelo, and your modules.dep looks correct ?
Oct 01 13:55:41 <__angelo> :) i omitted the way i use modprobe, error was there   modprobe virtio_crypto.ko  doesn't work of course, .ko is not welcome
Oct 01 13:55:59 <kroon> aha
Oct 01 13:55:59 <__angelo> kroon, thanks for the help
Oct 01 13:56:24 <__angelo> i thought it could be some yocto mistery, while it's not :)
Oct 01 13:57:25 <kroon> __angelo, you helped yourself methinks :D
Oct 01 14:20:18 <opennandra> qschulz: ok thanks I'll try
Oct 01 15:07:25 <mcfrisk> what will be the codename for yocto 2.8/3.0? I need a branch already :)
Oct 01 15:07:30 <rburton> zeus
Oct 01 15:07:38 <mcfrisk> rburton: thanks!
Oct 01 15:07:45 <rburton> https://wiki.yoctoproject.org/wiki/Releases
Oct 01 15:35:06 <armpit> we should emoji's for 3.1
Oct 01 15:36:50 <LetoThe2nd> armpit: we need the poop emoji.
Oct 01 15:53:16 <RP> armpit: that would mess with people! :)
Oct 01 15:53:59 <armpit> hehe
Oct 01 15:54:33 <RP> I was using 🦒where it worked fine but 🦁 arrived and it stopped working
Oct 01 16:00:52 <milloni> if there's more than one recipe for a package, how does bitbake choose which one to install?
Oct 01 16:01:02 <milloni> for instance lets say i have openssh in my IMAGE_INSTALL
Oct 01 16:01:54 <milloni> and i've got a recipe openssh_7.8p1+git.bb  in my layer
Oct 01 16:02:33 <milloni> and another openssh_7.1p2.bb from meta
Oct 01 16:03:23 <rburton> it uses the one that bitbake picked.  layer priority then recipe version, unless overridden with PREFERRED_VERSION etc
Oct 01 16:04:38 <milloni> so the priority is 1) PREFERRED_VERSION 2) layer priority 3) recipe version ?
Oct 01 16:04:49 <rburton> pretty much
Oct 01 16:04:51 <milloni> thanks
Oct 01 16:05:04 <rburton> bitbake-layers can show what versions it knows about and what is picked
Oct 01 16:07:57 <qschulz> milloni: (and you have preferred_provider in the story :) )
Oct 01 16:14:35 <zeddii> RP: I've thrown in the towel. and have just emailed lkml for some pointers on the strace issue.
Oct 01 16:14:48 <zeddii> I cc'd you on the email .. in case they ask for details I don't hae.
Oct 01 16:14:55 <zeddii> s/hae/have/
Oct 01 16:17:21 <milloni> how come poky keeps this patch? https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-devtools/python/python-native/debug.patch
Oct 01 16:21:47 <rburton> milloni: good question, feel free to send a patch to delete it
Oct 01 16:56:13 <yocti> New news from stackoverflow: How to build Yocto hddimg on i.MX7 to boot from usb stick <https://stackoverflow.com/questions/58189022/how-to-build-yocto-hddimg-on-i-mx7-to-boot-from-usb-stick>
Oct 01 16:58:11 <RP> zeddii: I was going to ask how that was going, thanks for the update
Oct 01 19:15:59 <opennandra> qschulz: it's not working
Oct 01 19:16:20 <opennandra> it tried for minline u-boot build my machine and it fails as in mainline I don't have changes ;
Oct 01 19:36:03 <RP> zeddii: dilemma is do we block release on this?>
Oct 01 20:11:10 <qschulz> opennandra: damn it. Didn;t forsee why it would need the machine for scripts. But playing with an almost 10yo U-Boot is... asking for trouble. I had a couple of boards a few years back that were not properly tested or support was dropped and could stay only with old U-Boot. Is there really no way around upgrading U-Boot reasonably?
Oct 01 20:11:59 <opennandra> qschulz: it's from vendor SDK and updating u-boot will be long process :)
Oct 01 20:12:07 <opennandra> which I don't have time for
Oct 01 20:12:24 <opennandra> so maybe I'll do it brute force -> compile manually and install only or so
Oct 01 20:12:28 <opennandra> :)
Oct 01 20:15:32 <qschulz> opennandra: depends... NXP for example is not that bad of a BSP. On the other hand, Allwinner is pretty crappy BSP but there is usually a very good upstream support.
Oct 01 20:15:41 <qschulz> May I ask which vendor/board?
Oct 01 20:16:00 <opennandra> qschulz: hisilicon
Oct 01 20:16:23 <opennandra> they provide SDK with obsolete Makefile base stuff
Oct 01 20:16:28 <opennandra> and I'm porting it to yocto
Oct 01 20:16:36 <opennandra> to be able to develop something easily on it
Oct 01 20:16:41 <opennandra> u-boot builds fine
Oct 01 20:16:47 <opennandra> I just need fw-utils
Oct 01 20:16:53 <opennandra> but then hit issue
Oct 01 20:17:11 <qschulz> opennandra: are you able to compile fw-tools manually?
Oct 01 20:17:42 <opennandra> qschulz: yes
Oct 01 20:18:39 <qschulz> opennandra: ok, good start :)
Oct 01 20:18:57 <opennandra> qschulz: :)
Oct 01 20:19:14 <qschulz> opennandra: (but honestly.... u-boot 2010.06.... way to treat your customers)
Oct 01 20:19:43 <opennandra> qschulz: well if you don't have any support you have to live with what you get from vendor
Oct 01 20:20:15 <qschulz> opennandra: I meant, coming from Hisilicon, not you :)
Oct 01 20:20:29 <opennandra> qschulz: I see
Oct 01 20:22:46 <qschulz> opennandra: I *think* they fixed an issue recently (~1-2 years ago?) wrt Makefiles and tools/scripts. SO it might be worth checking newer commits in those areas
Oct 01 20:23:23 <opennandra> qschulz: ok I'll look around and check
Oct 01 20:23:30 <qschulz> but if it cannot find includes (as basic as stdio and such) check that the sysroot is passed to the Makefile and correctly taken into account by the Makefile
Oct 01 20:24:02 <qschulz> (e.g. explore WORKDIR/temp/[run|log].do_compile
Oct 01 20:24:23 <qschulz> (well, in correct syntax, {run,log} :)
Oct 01 20:25:43 <qschulz> good luck with that, I hate vendor BSP and especially those that are outdated and/or far from mainline. Praying for you :D
Oct 01 20:26:46 <yocti> New news from stackoverflow: Unable to start bitbake server <https://stackoverflow.com/questions/48132054/unable-to-start-bitbake-server>
Oct 01 20:27:05 <opennandra> qschulz: thanks
Oct 01 20:31:32 <qschulz> opennandra: and I actually mixed u-boot-fw-utils and u-boot-tools. We use u-boot-tools from upstream but not u-boot-fw-utils AFAIR (due to the same limitation as yours :) )
Oct 01 20:31:53 <palate> hello :)
Oct 01 20:32:01 <palate> Curious: does somebody here know fastboot?
Oct 01 20:32:04 <opennandra> qschulz: +1
Oct 01 20:32:36 <qschulz> opennandra: BTW, it mght actually be a better idea (if not already done) to use the same recipe for u-boot and u-boot-fw-tools
Oct 01 20:32:53 <qschulz> palate: ask your question, then people will see if they can answer :)
Oct 01 20:33:12 <opennandra> qschulz: I tried and got same issue like with separate recipe
Oct 01 20:35:17 <qschulz> opennandra: gl, I'm afk now, maybe others will help but bed is singing lullabies to me right now
Oct 01 20:36:21 <palate> I have this device on which I can flash an image with fastboot. I do it in 3 commands: one for "system", a *.ubi, one for "boot", a *.img, and one for "recovery", another *.img. I could access the kernel config in /proc/config.gz on the device, and I'm hoping I can make my own image for it. But I don't know what an *.ubi image is, and I wonder how risky it is with fastboot (i.e.: can I brick my
Oct 01 20:36:23 <palate> device if I don't do it correctly?)
Oct 01 20:36:56 <palate> So I'm effectively trying to reverse engineer a linux image to replace it with my own yocto :)
Oct 01 20:47:03 <qschulz> palate: https://en.wikipedia.org/wiki/UBIFS#UBI it's basically a type of "container" for raw data or UBIFS on NAND devices
Oct 01 20:47:58 <qschulz> palate: if your device is locked (secure boot and all), then most likely anything that isn't coming from the vendor will brick your device
Oct 01 20:49:13 <palate> qschulz: I don't think that it is locked. They already gave me this "minimal linux" image to play around, it doesn't seem like it is secured (but that's a guess)
Oct 01 20:49:40 <palate> qschulz: but with fastboot, you think that if I "brick" it, I won't be able to reflash the older image?
Oct 01 20:49:40 <qschulz> palate: now if it is not so far from the Android boot process (boot, recovery and system sounds like it?), I think you're fine messing with the system partition
Oct 01 20:50:03 <palate> qschulz: oh, I would only replace the system one then? Good to know
Oct 01 20:50:12 <qschulz> palate: well, which partition contains the code starting fastboot?
Oct 01 20:51:02 <qschulz> if you mess this one and there is no other mechanism available..
Oct 01 20:51:10 <palate> qschulz: I don't know... I know that if I press the "home" button many times, it goes in fastboot mode. But I guess that's not helping :D
Oct 01 20:51:24 <qschulz> palate: U-Boot I guess?
Oct 01 20:51:30 <qschulz> for the bootloader?
Oct 01 20:52:18 <palate> qschulz: no clue. Can I see that when I'm in the device? I can connect with `adb shell`
Oct 01 20:53:19 <qschulz> I would strongly encourage you to find the serial port on the device before trying to tinker with it
Oct 01 20:53:49 <qschulz> hopefully there is one :)
Oct 01 20:54:16 <palate> qschulz: What I see is that the system "linux.ubi" image is 22M, the recovery "recovery.img" is 9.3M, and the boot "linux-boot.img" is 5.5M
Oct 01 20:54:42 <palate> qschulz: so it would sound like playing with the system "linux.ubi" image should not be too bad...
Oct 01 20:55:05 <qschulz> that should be alright, looks like the rootfs
Oct 01 20:55:26 <qschulz> considering the size of linux-boot.img, I guess that might well be the kernel
Oct 01 20:55:44 <palate> qschulz: ok! Because I don't think I have a serial access (I could try to open it, but still I probably wouldn't know what to look for)
Oct 01 20:56:32 <qschulz> I might be wrong but I think you should try to find out which kernel is running to get the kernel headers for this version and compile yocto with this version of the headers to be sure evrything will go smoothly
Oct 01 20:56:56 <palate> qschulz: wait, then "boot" is the kernel, "system" is the rootfs, and "recovery" is... well I don't know what, maybe the fastboot image, then?
Oct 01 20:57:10 <palate> qschulz: I want to recompile the kernel to add new modules
Oct 01 20:57:23 <palate> haha maybe I should try to contact the guys doing this device and get some help
Oct 01 20:57:34 <qschulz> palate: depending on the board there might already be some tutorials for this
Oct 01 20:57:39 <qschulz> palate: what's the board?
Oct 01 20:58:04 <palate> qschulz: it's an armv7, I think "apq8009", if that's a thing
Oct 01 20:58:15 <palate> I think it's a qualcomm thingy
Oct 01 20:58:32 <qschulz> yup
Oct 01 20:58:41 <qschulz> (well at least GOogle told me :) )
Oct 01 20:59:12 <palate> (yes, but I did not find a yocto BSP for that)
Oct 01 21:00:17 <qschulz> try to get from them a tutorial on how to compile the things (and especially how to get the *.ubi, since you need many info for mkfs.ubifs for example)
Oct 01 21:00:23 <qschulz> ideally where the serial is
Oct 01 21:00:34 <qschulz> and what's the content of which partition
Oct 01 21:00:40 <palate> ok!
Oct 01 21:01:50 <palate> Thanks a lot qschulz :). Sorry for the stupid questions xD
Oct 01 21:01:57 <palate> But I'm learning a lot!
Oct 01 21:03:31 <qschulz> palate: no stupid questions really, everybody has to start from somwhere :)
Oct 01 21:04:27 <qschulz> palate: remember to shoot the question directly with the origin of your issue and if people know the answer, they'll most likely give you an answer or tip where to look at
Oct 01 21:05:00 <palate> got it. Thanks a lot :)
Oct 01 21:05:09 <qschulz> palate: might be of interest for later use: http://layers.openembedded.org/layerindex/branch/master/layer/meta-qcom/
Oct 01 21:05:39 <qschulz> alright, I really should rest during my holidays, back to bed!
Oct 01 21:05:44 * qschulz zzz
Oct 01 21:07:52 <palate> qschulz: good night!
Oct 01 21:20:00 <mischief> why does this trigger on my git repos with submodules? does this imply the submodule URIs are malformed somehow? http://git.yoctoproject.org/cgit.cgi/poky/tree/bitbake/lib/bb/fetch2/gitsm.py#n111
Oct 01 21:42:49 <Crofton> lolz, yocto build pulled out of someones ass
Oct 01 21:43:05 <Crofton> quote from speaker, I need to get to the bottom of this comment
**** ENDING LOGGING AT Wed Oct 02 02:59:57 2019