**** BEGIN LOGGING AT Thu Jan 03 02:59:57 2019
Jan 03 03:10:51 <yocti> New news from stackoverflow: Adding iptables to yocto causes image do_rootfs to fail due to wrong kernel version [on hold] <https://stackoverflow.com/questions/54009728/adding-iptables-to-yocto-causes-image-do-rootfs-to-fail-due-to-wrong-kernel-vers>
Jan 03 06:11:23 <yocti> New news from stackoverflow: modifying kernel config in Yocto <https://stackoverflow.com/questions/31036303/modifying-kernel-config-in-yocto>
Jan 03 06:20:59 <khem> RP: I was thinking of dropping bunch of armv5 and below tunes since gcc9 wont support them anyway
Jan 03 06:21:19 <khem> RP: this would make a few less tunes to maintain
Jan 03 06:21:51 <khem> or should we keep them in for external toolchains
Jan 03 06:22:27 <khem> I am not sure how much practical usecase do they have
Jan 03 07:55:48 <hnje> Morning. I'm currently playing around with a linux-yocto style recipe, and I've added a patch to yocto-kernel-cache and hoped it would just apply. However, it seems like nothing gets applied and in .kernel-meta the series symlink points to a none existing patch.queue - shouldn't it point to patch.standard.queue ?
Jan 03 09:21:36 <RP> khem: probably something to discuss on the mailing list?
Jan 03 09:49:25 <derRichard> is IMAGE_FSTYPES = "iso" no longer supported?
Jan 03 09:49:30 <derRichard> i get "No IMAGE_CMD defined for IMAGE_FSTYPES entry 'iso' - possibly invalid type name or missing support class"
Jan 03 09:54:16 <rburton> still there in my checkout
Jan 03 09:57:12 <derRichard> my image is based on recipes-core/images/core-image-minimal.bb, when i add "iso" or "hddimg" to IMAGE_FSTYPES, i get the said error
Jan 03 09:57:18 <derRichard> is this the wrong way to use it?
Jan 03 10:20:41 <derRichard> rburton: found the issue, when i set IMAGE_FSTYPES in my image bb file, it does not work. it works only when i set it in my local.conf.
Jan 03 10:20:46 <derRichard> why?
Jan 03 10:21:06 <derRichard> so far setting IMAGE_FSTYPES in the image worked just fine for ext4, tar.xz, squashfs, etc...
Jan 03 10:37:15 <RP> derRichard: its not a good behaviour but I suspect its to do with the fact that requires an extra class inherit and its being set too late to manage it. Does it make a difference with the position in the image recipe (set it at the start)?
Jan 03 10:38:38 <derRichard> RP: so, setting IMAGE_FSTYPES needs to happend before the inherit? this is the case
Jan 03 10:38:52 <derRichard> why is setting IMAGE_FSTYPES in the image file not good?
Jan 03 10:39:16 <derRichard> my yocto project needs to create many different images, of different types.
Jan 03 10:39:36 <derRichard> e.g. a base image, and a "installer" image which is a live disk
Jan 03 10:40:12 <derRichard> base image is tar.xz and squashfs, the installer picks these up and will be a live disk to install them on the target...
Jan 03 10:40:21 <derRichard> there is also a debug disk, etc..
Jan 03 10:40:42 <derRichard> editing the local.conf for each image build seems hacky to me
Jan 03 10:49:48 <RP> derRichard: I suspect as long as the base value has it and you remove it in the image recipe it would work
Jan 03 10:50:11 <RP> derRichard: Its just due to the way that particular image type has been implemented :/
Jan 03 10:50:34 <derRichard> hmm
Jan 03 10:50:46 <RP> derRichard: It is supposed to work from the image recipe...
Jan 03 10:51:50 <derRichard> yeah, it works now. i had to put "require recipes-core/images/core-image-minimal.bb" in the last line of my recipe
Jan 03 10:56:13 <PinkSnake> Hi all, someone here has already to build a custom tool from source (in a recipe i mean) but not the target ARCH but for the host ? :)
Jan 03 11:00:12 <derRichard> yes
Jan 03 11:04:56 <PinkSnake> >derRichard, could you provide me more info about that ? I don't understand how to "bypass" crosstool-chain...
Jan 03 11:08:32 <derRichard> PinkSnake: not sure if i fully understand your use case, but i guess you needs that way: https://wiki.yoctoproject.org/wiki/Technical_FAQ#I_have_some_software_which_needs_to_build_a_binary_that_it_then_runs_as_part_of_its_own_build_process.2C_how_do_I_make_this_work.3F
Jan 03 11:08:54 <derRichard> so, your recipe needs to be like any other tool which is needed to build the toolchain
Jan 03 11:12:00 <PinkSnake> in fact it's a really simple tool used. I need to build it on the host because of an other recipe need this tool to build a custom image
Jan 03 11:12:23 <yocti> New news from stackoverflow: Cross compilling .deb package for yocto image?i.e remot3.it <https://stackoverflow.com/questions/54021031/cross-compilling-deb-package-for-yocto-imagei-e-remot3-it>
Jan 03 11:13:18 <PinkSnake> @derRichard thank you i'm going to take a look!
Jan 03 11:14:18 <derRichard> you can also look how it is solved here: http://cgit.openembedded.org/openembedded/tree/recipes/regina-rexx
Jan 03 11:14:26 <derRichard> the tool depends on itself
Jan 03 11:14:30 <derRichard> (very ugly and hacky...)
Jan 03 11:14:32 <derRichard> but hey...
Jan 03 11:21:48 <RP> derRichard: standard practise for some types of problem. Where did you get a do_stage_append() from though? That should be ancient history
Jan 03 11:22:48 <RP> oh, its oe-classic. That code is very very old at this point
Jan 03 11:23:11 <derRichard> RP: yes, but it still works(tm). i found this gem in a customer code base :)
Jan 03 11:23:47 <RP> derRichard: most of that recipe can probably be deleted now...
Jan 03 11:24:00 <kanavin> RP: I fixed four or so issues with perl-sanity, we can give it another go maybe? http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=akanavin/perl-sanity
Jan 03 11:24:23 <derRichard> RP: sadly the whole regina-rexx recipe is gone in current releases
Jan 03 11:24:37 <derRichard> i need to get up my arse and upstream my regina-rexx recipe
Jan 03 11:26:04 <RP> kanavin: https://autobuilder.yoctoproject.org/typhoon/#/builders/85/builds/82
Jan 03 11:26:36 <RP> derRichard: we need more people to help maintain recipes, there are only a dedicated few who do :(
Jan 03 11:27:48 <derRichard> i know, but the list of stuff i maintain is already too long
Jan 03 11:31:12 <xtron> how to modify the variable value defined in *.bbclass,
Jan 03 11:31:41 <xtron> using some *.*append file
Jan 03 11:36:01 <kanavin> xtron: sadly not possible really, write your own class and inherit that, or modify the existing one.
Jan 03 11:42:10 <xtron> kanavin: we can redefine that variable in local.conf so it will be applicable to all recipes?
Jan 03 11:44:55 <derRichard> RP: now i understand also the this hint: https://www.yoctoproject.org/docs/latest/ref-manual/ref-manual.html#var-IMAGE_FSTYPES
Jan 03 11:45:11 <derRichard> it should not only talk about "live", also "hddimg" and "iso"...
Jan 03 11:49:10 <RP> derRichard: There are others in that list so perhaps we should not list them. Care to file a bug?
Jan 03 11:54:35 <derRichard> RP: done
Jan 03 11:59:42 <RP> derRichard: thanks
Jan 03 12:01:04 <derRichard> how do you guys manage multiple yocto layers? using git submodules? google repo?
Jan 03 12:01:43 <derRichard> i have one project using submodules, another with repo. both work, but i'm not super happy with both :D
Jan 03 12:02:31 <RP> derRichard: I think there are pros and cons to the various approaches. I do want to write a standard tool but the constraints/requirements on it are tricky...
Jan 03 12:03:41 <derRichard> RP: my main use case is "fetch all needed layers, build me a bblayers.conf, a local.conf and run the build"
Jan 03 12:04:44 <derRichard> could be also be solved by a shell script. but....
Jan 03 12:06:18 <RP> derRichard: the yocto autobuilder helper code actually does this...
Jan 03 12:08:16 <derRichard> RP: well isn't this a huge buildbot thingy?
Jan 03 12:11:50 <rburton> derRichard: surely local.conf is just a metter of setting DISTRO
Jan 03 12:14:46 <RP> derRichard: yocto-autobuilder-helper isn't
Jan 03 12:14:59 * derRichard looks :)
Jan 03 12:18:47 <rburton> RP: want to pick my meson qa patches to next?
Jan 03 12:25:33 <RP> rburton: sure, they can do into the next round
Jan 03 12:26:13 <rburton> RP : Yocto compatible of 'meta' layer when checking with 'scripts/yocto-check-layer'
Jan 03 12:26:32 <rburton> RP: might need to whitelist meta :)
Jan 03 12:28:23 <RP> rburton: that is on my "to discuss" list. Can't decide if we should split qemu machines out. Doesn't seem to have much point though...
Jan 03 12:29:08 <rburton> I'd say that meta is special here
Jan 03 12:29:22 <rburton> no point having meta-bsp and meta-distro just to split those out
Jan 03 12:30:11 <RP> rburton: I ran most of the current -next on the AB yesterday. Anything in there that concerns you?
Jan 03 12:30:50 <RP> rburton: first four still need condisderation, man-pages didn't go through the AB yet
Jan 03 12:31:10 <rburton> from a quick look, seems okay
Jan 03 12:32:11 <RP> rburton: the eglinfo one is missing a maintainer entry
Jan 03 12:33:13 <RP> ah, nettle upgrade breaks signing
Jan 03 12:33:31 <RP> armpit2: https://autobuilder.yoctoproject.org/typhoon/#/builders/56/builds/86 :(
Jan 03 12:38:33 <RP> rburton: the top three patches?
Jan 03 12:45:57 <rburton> RP: yes
Jan 03 12:46:38 <RP> rburton: I picked out a couple of others too
Jan 03 12:48:29 <RP> rburton: fired another -next to check this patchset works and can merge
Jan 03 13:03:20 <hnje> anyone with some knowledge about the linux-yocto scc/kmeta stuff and can explain why 'series' ends up pointing to a none-existing patch.queue?
Jan 03 13:07:37 <sveinse> Happy new year guys!
Jan 03 13:08:31 <sveinse> Is there a smart way of installing a set of packages on an existing running target which does not have a package system installed?
Jan 03 13:10:33 <sveinse> I have a scheme where I create a new image with the addional packages, then diff this image file against the stock image and create a tarball from that. Problem is that installing an image "from scratch" like this pulls in a lot of the infrastructure packages, such as base-files and base-passwd.
Jan 03 13:12:57 <sveinse> I then tries excluding them with PACKAGE_EXCLUDE = "base-files" and that worked image-wise, but that creates other problems with other packages. E.g. bash fails with "nothing provides base-files needed by bash".
Jan 03 13:13:42 <sveinse> Is there a way to instruct bitbake to exclude packages, e.g. base-files, but claim to other packages that it is installed to avoid such errors?
Jan 03 13:20:03 <RP> sveinse: not really. Its a package manager problem, not a bitbake one
Jan 03 13:56:20 <muppe> Hi. Does anyone have an idea why sed fails in "do_install_append_class-native" rpm_5.4.16.bb (krogoth)? For some reason I don't have ${D}/${libdir}/python2.7/site-package
Jan 03 13:56:20 <muppe> s/rpm/transaction.py
Jan 03 13:56:33 <muppe> in place
Jan 03 13:57:17 <muppe> (well "sed" fails because in cannot find transaction.py but who should put that file there and why it is not there in my env?)
Jan 03 13:57:35 <RP> muppe: you've turned off python extensions in rpm? you're using a different python version?
Jan 03 13:58:50 <muppe> hmm... intentionally I haven't done that but it is quite likely that something like that has happened.
Jan 03 13:59:32 <muppe> I am using debian package manager in my build (local.conf) but I guess it still requires some rpm thingies.
Jan 03 13:59:36 <RP> muppe: have a look at rpm's configure log?
Jan 03 14:00:26 <RP> muppe: could also be getting confused with the host python version verses the one in the build
Jan 03 14:02:52 <muppe> I am using an ancient Ubuntu 12.04 (don't ask why) in this case and the host python is 2.7.3.  Shouldn't yocto/bitbake build another python version from the sources independently of what is installed on the host? Or is there a dependency.
Jan 03 14:04:19 <RP> muppe: should be independent but krogoth is old and doesn't have some of the functionality we added in later releases
Jan 03 14:05:28 <muppe> Am I shooting myself to foot if I just go ahead and comment out those "do_install_append_class" parts?
Jan 03 14:39:26 <sveinse> RP: Yes. Which essentially implies that images without package manager are only intended for static images.
Jan 03 14:40:16 <Crofton> muppe, https://pythonclock.org/
Jan 03 14:40:44 * Crofton had posted that to another channel, so had it handy :)
Jan 03 14:41:48 <sveinse> As a side comment (since this is package manager question not bitbake), is that we ditched distributing updates using packagemanagers. We used to use pkg manager, but updating the product took 40mins which was unacceptable. Updating through a field tgz-type whole-image takes only 4 mins, so we had to ditch the pkg manager update.
Jan 03 15:01:05 <RP> sveinse: the package manager piece of the system is plugable, just nobody has put the work into a good image at once off the shelf update solution
Jan 03 15:01:25 <RP> there are some options out there, nothing has made it to be part of oe-core though
Jan 03 15:13:14 <yocti> New news from stackoverflow: Cross compilling .deb package for yocto image?i.e remot3.it [on hold] <https://stackoverflow.com/questions/54021031/cross-compilling-deb-package-for-yocto-imagei-e-remot3-it>
Jan 03 15:29:34 <kergoth> sveinse: there are multiple options, just as rp says none in oe-core. swupdate works well for example
Jan 03 15:31:51 * armpit2 sigh... rebasing again
Jan 03 16:13:24 <yocti> New news from stackoverflow: Building Mali Driver without X11 <https://stackoverflow.com/questions/35990824/building-mali-driver-without-x11>
Jan 03 17:13:36 <yocti> New news from stackoverflow: Yocto / Poky: install and use shared library .so on separate layers <https://stackoverflow.com/questions/54026504/yocto-poky-install-and-use-shared-library-so-on-separate-layers>
Jan 03 17:48:04 <khem> RP: sent a patch already to start the discussion
Jan 03 17:50:09 <RP> khem: Thanks! :)
Jan 03 17:52:14 <khem> RP: I will also sent another patch to consider runit for OE-Core
Jan 03 17:52:50 <khem> RP: systemd while good, does not fit the shoes of all embedded devices that Yocto/OE targets
Jan 03 17:52:52 <RP> khem: we still have problems with systemd so adding another worries me :/
Jan 03 17:53:06 <RP> khem: but yes, systemd isn't ideal
Jan 03 17:53:17 <khem> I know :), I was thinking of getting it in place of sysvinit
Jan 03 17:53:48 <khem> so it have application life cycle management on top of old script based init systems
Jan 03 17:54:14 <khem> which is actually all people want in embedded world when they switch to systemd largely
Jan 03 17:54:20 <RP> khem: I think I need to learn more about runit
Jan 03 17:54:39 <khem> its an old init system, major distros have it as option
Jan 03 17:54:46 <khem> debian/gentoo
Jan 03 17:55:01 <khem> some lesser known distros use it as default e.g. voidlinux
Jan 03 17:55:22 <khem> its 100K in size and can be a static binary
Jan 03 17:55:34 <khem> and boots blazing fast
Jan 03 17:55:52 <khem> on systems with 128M memory
Jan 03 17:56:51 <khem> Maybe I will create a layer for it for now
Jan 03 17:57:07 <khem> and we can consider it for core in future releases
Jan 03 18:00:55 <RP> khem: I like the sound of it, just need to learn more
Jan 03 18:09:19 <khem> RP: yes, I think there is a place for a init system between sysvinit and systemd
Jan 03 18:11:12 * kroon wonders why openssl.do_package_write_ipk depends on perl.do_packagedata, and where in the meta data that is described
Jan 03 18:16:08 <khem> kroon: there must be perl scripts in there
Jan 03 18:16:41 <khem> there is rdeps
Jan 03 18:28:34 <kroon> khem, hmm so if a recipe creates target packages that contain perl scripts, Yocto will build perl for the target, even though my image will not have those target packages installed ?
Jan 03 18:33:48 <khem> kroon: yes, since real rdeps would be computed during image build
Jan 03 18:46:25 <kroon> hmm, not sure I see exactly why yocto has to build perl in this case.. other than satisfying rdeps for _all_ generated packages, even those which arent installed in the image
Jan 03 18:50:46 <kroon> but i'm mostly never interested in packages not installed in the image, they could be discarded early as far as im concerned..
Jan 03 18:58:13 <kergoth> that'd be decidedly non-trivial, since you can emit packages in one bitbake command and then bake 3 different images in the next
Jan 03 19:02:22 <kroon> yeah ok, but perhaps not build recipes for rdeps related to packages that aren't ending up installed in the image ?
Jan 03 19:07:48 <kroon> a recipe "foo" that produces a package "foo" and a package "foo-perl" that contains perl scripts; I'm not gonna install foo-perl in my image "bar", but "bitbake bar" will build perl for target
Jan 03 19:09:04 <ds2> just because your target don't need it doesn't mean you may not install it later (in general)
Jan 03 19:10:06 <kroon> yeah in general, but having the option of avoiding it would be nice, since in my case I know i'm not gonna need it
Jan 03 19:18:30 <derRichard> hmm, the documentation on wic is rather sparse
Jan 03 19:26:30 <derRichard> my plan is creating a live-system which will install my rootfs to the target later. isn't scripts/lib/wic/canned-wks/mkhybridiso.wks the way to go?
Jan 03 19:39:57 <rburton> kroon: if its a huge problem, make a packageconfig for the perl bits and then turn it off.
Jan 03 19:40:16 <rburton> or, live with building perl occasionally.  once in the sstate it will get reused anyway, right
Jan 03 19:44:06 <yocti> New news from stackoverflow: Bitbake putting config files in wrong package. Ignoring FILES_ directives in my .bbappend. Next place to look/how to fix? <https://stackoverflow.com/questions/54028501/bitbake-putting-config-files-in-wrong-package-ignoring-files-directives-in-my>
Jan 03 19:46:09 <kroon> rburton, true
Jan 03 21:05:25 <derRichard> meta/classes/image-live.bbclass sets LABELS_LIVE ?= "boot install"
Jan 03 21:05:35 <derRichard> but i see no users of LABELS_LIVE?
Jan 03 21:05:50 <derRichard> are my git grep skills too weak or that do i miss?
Jan 03 21:13:34 <RP> yay, eclipse fixed and a green master-next :)
Jan 03 21:13:42 <RP> halstead: was that you? If so thanks!
Jan 03 21:14:36 <halstead> RP, I made a temporary solution while waiting on a more lasting plan.
Jan 03 21:15:09 <rburton> derRichard: its LABELS in LIVE mode
Jan 03 21:15:25 <rburton> oe-core d7d1e0193c94abb1cd2daf1c298c8c1788f3616d
Jan 03 21:15:35 <rburton> (my grep fu is stronger than yours ;)
Jan 03 21:15:44 <rburton> (git log -G LABELS_LIVE, second commit)
Jan 03 21:15:52 <derRichard> rburton: oh dear! once again i got fooled by the underscore magic in bitbake :-(((
Jan 03 21:16:29 <rburton> that's not override magic,
Jan 03 21:16:43 <rburton> thats literally variables get created magically
Jan 03 21:16:49 <rburton> (see the sha)
Jan 03 21:17:21 <derRichard> yeah, but it is still magic :P
Jan 03 21:17:40 <rburton> its ugly and i wish i didn't just learn about that bit
Jan 03 21:17:41 <derRichard> i grepped in the source tree for "LABELS_LIVE"
Jan 03 21:18:23 <derRichard> this makes reading the source a little odd
Jan 03 21:18:33 <rburton> yeah, log -G searches the log for commits which introduce or remove that line, good for finding out context
Jan 03 21:18:56 <derRichard> yeah, that's true. thanks for the hint
Jan 03 21:19:40 <rburton> RP: can't replicate the meson epoxy failure, despite having not one but two hunches.  will throw a repeat with more debugging at the ab shortly.
Jan 03 21:20:47 <RP> rburton: ok, sounds good. I merged the other two pieces of it whilst we fix the test
Jan 03 21:20:54 <RP> rburton: just merged most of -next
Jan 03 21:21:06 <RP> halstead: much appreciated, thanks!
Jan 03 21:21:50 <halstead> RP, since the solution is temporary we probably shouldn't tag any releases until the download path is updated to something more permanent though.
Jan 03 21:25:55 <RP> halstead: I will leave that one with you/Tim/Chin Huat, I haven't followed exactly what the impact of the problem is. Does this block 2.5.2?
Jan 03 21:26:32 <rburton> RP: ok how the hell can i get a testsdk unittest to log output to the console even it passes
Jan 03 21:33:44 <RP> rburton: output handling in unittest is horrible :(
Jan 03 21:33:51 <rburton> bb.warn works
Jan 03 21:33:59 <rburton> would be nice if a logger was somehow passed in
Jan 03 21:34:16 <rburton> right fired
Jan 03 21:36:52 <RP> rburton: its rat infested spools of razor wire :(
Jan 03 21:37:11 <halstead> RP, As it is it probably should block. But if I switch the workaround to be a redirect and that is successful then we are okay.
Jan 03 21:37:13 * RP has tried to untangle it a few times
Jan 03 21:43:28 <RP> halstead: What is the next step to move things forward?
Jan 03 21:46:06 <khem> RP: https://patchwork.openembedded.org/patch/157529/ seems to have worked for me world build looks same as before core-image-sato-sdk-ptest passed tests
Jan 03 21:47:11 <RP> khem: seems ok to me in principle, Martin is the one who may have the most insight...
Jan 03 21:47:45 <khem> he has already looked at v1 and I addressed the feedback in this v2
Jan 03 21:48:03 <khem> this is v1 https://patchwork.openembedded.org/patch/157527/
Jan 03 21:48:23 <RP> khem: I saw the discussion, looks good! :)
Jan 03 21:48:52 <khem> I am going to send email to seek deletion of armv4 tunes
Jan 03 21:49:02 <khem> and non thumb tunes
Jan 03 21:49:08 <khem> for <=v5
Jan 03 21:49:38 <khem> another part of me says it might still be ok to keep them as some external toolchains might still be using it .. dont know
Jan 03 21:50:56 <halstead> RP, I have the redirect in place. Next is to build the plugin and see what happens.
Jan 03 21:51:20 <RP> khem: Its probably time to retire them
Jan 03 21:52:23 <RP> khem: armv4 predates most of us in the project
Jan 03 22:05:36 <bluelightning> the original iPAQs were armv4 IIRC
Jan 03 22:06:05 <bluelightning> not in any way a reason to keep the support around of course :D
Jan 03 22:07:03 <ds2> long live PXA2xx!!!!
Jan 03 22:07:24 <kroon> I'm not quite grasping what uninative is.. if I use it, does it mean I don't have to build most of the native/cross recipes, but can instead use an "official" yocto sstate cache mirror ?
Jan 03 22:07:59 <neverpanic> yes
Jan 03 22:10:33 <derRichard> how can it happen that your commit messages reference unknown git sha1s? are you rebasing the tree? :(
Jan 03 22:10:50 <derRichard> e.g. 53078a00ceab ("core-image-minimal-initramfs: use initramfs-framework for initialization") says:
Jan 03 22:10:53 <derRichard> initramfs-framework is more modular and expandable. This change was
Jan 03 22:10:55 <derRichard>     proposed in commit 28fc6ba761ed4a47efa7c43e7f7dff5e2fe72b5e
Jan 03 22:10:57 <derRichard> but there is no 28fc6ba761ed4a47efa7c43e7f7dff5e2fe72b5e
Jan 03 22:11:07 <neverpanic> derRichard: It might be openembedded-core vs. poky
Jan 03 22:11:14 <kroon> neverpanic, is there a doc describing this ?
Jan 03 22:11:22 <neverpanic> check both for the commit, the commit IDs change when stuff is merged into the poky repo
Jan 03 22:12:01 <derRichard> neverpanic: when you merge stuff (in terms of git merge), the sha1s won't change
Jan 03 22:12:04 <kroon> neverpanic, especially where that official yocto sstate cache mirror lives
Jan 03 22:12:20 <neverpanic> kroon: it's always a good idea to search the mega-manual, e.g. https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#ref-classes-uninative
Jan 03 22:12:48 <neverpanic> derRichard: the road from openembedded-core -> poky isn't a merge in the git sense
Jan 03 22:12:57 <derRichard> neverpanic: oh :(
Jan 03 22:14:02 <neverpanic> derRichard: See http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-poky/README.poky#n33
Jan 03 22:16:03 <neverpanic> kroon: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/distro/include/yocto-uninative.inc
Jan 03 22:18:14 <kroon> neverpanic, thats just the C library right, not the sstate cache ?
Jan 03 22:20:02 <neverpanic> right, seems I misunderstood this, you'll still build the recipes locally, but you can share them across distros
Jan 03 22:21:14 <kroon> neverpanic, hmm ok. I was hoping yocto would also host some sort of "official" sstate cache mirror one could use
Jan 03 23:13:07 <vegards> Hello. We are currently using a prebuilt device with yocto and qt5.6.2. The device is shipped to us preconfigured from the manufacturer. Now we're in need of a newer qt version and the manufacturer are not able to supply a newer image for the device. They said we have to build our own filesystem. I got the original image from the manufcaturer which is flashed via mfgtools to the eMMC.
Jan 03 23:13:13 <vegards> In the /OS Firmware/files-folder I have rootfs.tar.bz2, u-boot-imx6dlsabresd_sd.imx, zImage, zImage-imx6dl-sabresd.dtb. What I'm curious about is if i have what I need to build a functioning filesystem with working peripherals etc. or do I need to request something more? Can i use the existing u-boot-image?
Jan 03 23:15:05 <derRichard> vegards: well, you need to request the full sources. no binaries
Jan 03 23:17:34 <neverpanic> You may be able to get away with keeping the kernel and its modules (for hw support) and swap out the userland.
Jan 03 23:17:54 <neverpanic> In which case you might get away with an SDK and recompiling your userland from source.
Jan 03 23:18:15 * derRichard wonders how vegards ever did security fixes
Jan 03 23:18:28 <neverpanic> Probably paid the vendor to do them?
Jan 03 23:22:40 <neverpanic> Chances are the vendor doesn't want to provide a newer Qt version due to Qt > 5.6 being LGPL-3.0
Jan 03 23:23:39 <khem> QT licencing is another FUD
Jan 03 23:24:15 <neverpanic> embedded device vendors are generally sceptical of any *GPL-3 type licenses
Jan 03 23:24:51 <derRichard> TBH, i'd never ever use a v3, v2 only.
Jan 03 23:25:10 <derRichard> but i guess i'm too linux'ish ;)
Jan 03 23:25:15 <vegards> The vendor said they could provide Linux 4.1.15 U-Boot and Kernel BSP, is that that what I need?
Jan 03 23:25:48 <neverpanic> derRichard: So you're using GCC 4.3?
Jan 03 23:25:59 <derRichard> neverpanic: use in terms of using for my own code
Jan 03 23:26:09 <neverpanic> vegards: Yes, that's a good start.
Jan 03 23:26:21 <derRichard> i.e. products i create
Jan 03 23:26:57 <neverpanic> Isn't using a compiler "using it for your own code"?
Jan 03 23:27:27 * derRichard is not in bikeshedding mood 
Jan 03 23:27:58 <vegards> Alright, Thanks, I'll do a request then. The device is an industrial HMI, havent seen any security fixes for it yet...
Jan 03 23:28:42 <neverpanic> vegards: I'm not a lawyer, but if you're going to redistribute the device with an updated Qt, you might want to have yours look into Qt's licensing, too.
Jan 03 23:33:43 <khem> derRichard: why wont you use v3 ?
Jan 03 23:34:20 <khem> then you must stick to gcc < 4.4 too
Jan 03 23:34:24 <derRichard> khem: IMHO v2 is good enough.
Jan 03 23:34:54 <derRichard> khem: using as licence for code i write. e.g. projects i create for customers
Jan 03 23:35:41 <khem> Okay thats your choice
Jan 03 23:35:50 <derRichard> what i said
Jan 03 23:36:09 <vegards> neverpanic will do, do you know hat I specifically have to be aware of?
Jan 03 23:36:10 <khem> LGPL 3.0 is no different then GPL-2.0
Jan 03 23:36:33 <khem> infact people confuse the versions and variants a lot I have seen
Jan 03 23:37:38 <derRichard> khem: true
Jan 03 23:40:27 <neverpanic> vegards: As I said, I'm not a lawyer, so it would be unethical to attempt to give you legal advice. Take a look at section 4e, though.
Jan 03 23:40:53 <neverpanic> khem: That's not entirely correct from my understanding.
Jan 03 23:42:39 * derRichard had a few weeks ago a phone call with qt guys on licencing. it was "fun". ;-\
Jan 03 23:47:48 <khem> neverpanic: yes, additionally one has to provide a way to replace LGPL-3 licenced code if you dynamically link your app to it
Jan 03 23:56:59 <derRichard> hmm, my images does "require recipes-core/images/core-image-minimal.bb", i have to set IMAGE_INSTALL after the require because core-image-minimal.bb overwrites IMAGE_INSTALL. and i have to set IMAGE_FSTYPES before be require.
Jan 03 23:57:04 <derRichard> that's kinda gross
Jan 03 23:57:12 <derRichard> is there a better approach?
Jan 03 23:58:52 <khem> just set CORE_IMAGE_EXTRA_INSTALL in your image recipe to add packages
Jan 03 23:59:42 <derRichard> then require ... can be the last line in my bb file?
Jan 03 23:59:48 <khem> IMAGE_FSTYPES could be set anywhere in config metadata
Jan 03 23:59:57 <khem> yes
Jan 04 00:00:14 <khem> no order is then needed
Jan 04 00:00:28 <derRichard> in my setup i need (ok, i want) IMAGE_FSTYPES in the image bb file
Jan 04 00:02:47 <derRichard> khem: are you sure CORE_IMAGE_EXTRA_INSTALL is good? just checked why i'm using IMAGE_INSTALL.
Jan 04 00:02:53 <derRichard> docs say: You should only set this variable in the local.conf configuration file found in the Build Directory.
Jan 04 00:12:21 <khem> derRichard: yes it is. if you wan to keep using IMAGE_INSTALL you can just use IMAGE_INSTALL += ".." or IMAGE_INSTALL_append = " .."
Jan 04 00:13:02 <derRichard> khem: well, i do already IMAGE_INSTALL +=, but i need to do it _after_ the require line :(
**** ENDING LOGGING AT Fri Jan 04 02:59:56 2019