Thursday, 2019-01-03

*** OnkelUlla <OnkelUlla!> has quit IRC00:08
*** ejoerns <ejoerns!> has quit IRC00:09
*** dev1990 <dev1990!> has quit IRC00:10
*** dev1990 <dev1990!> has joined #yocto00:10
*** thePiGrepper <thePiGrepper!~nagato@> has joined #yocto00:17
*** dev1990 <dev1990!> has quit IRC00:19
*** ejoerns <ejoerns!> has joined #yocto00:19
*** OnkelUlla <OnkelUlla!> has joined #yocto00:21
*** dev1990 <dev1990!> has joined #yocto00:21
*** dev1990 <dev1990!> has quit IRC00:34
*** dev1990 <dev1990!> has joined #yocto00:36
*** dev1990 <dev1990!> has quit IRC00:36
*** dev1990 <dev1990!> has joined #yocto00:38
*** dev1990 <dev1990!> has quit IRC00:38
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has joined #yocto00:39
*** xperia64 <xperia64!> has quit IRC00:41
*** ravi__ <ravi__!~ravi@2a02:908:698:68a0:fd66:75f8:3696:4763> has quit IRC00:52
*** darekp_ <darekp_!> has joined #yocto00:58
*** xperia64 <xperia64!> has joined #yocto01:08
*** dev1990 <dev1990!> has joined #yocto01:10
*** dev1990 <dev1990!> has quit IRC01:22
*** dev1990 <dev1990!> has joined #yocto01:23
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC01:28
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC01:42
*** darekp <darekp!> has joined #yocto01:46
*** darekp_ <darekp_!> has quit IRC01:49
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has joined #yocto01:51
*** xperia64 <xperia64!> has quit IRC01:51
*** alicef <alicef!~none@gentoo/developer/alicef> has quit IRC01:56
*** NU-Slacker <NU-Slacker!~NU-Slacke@> has quit IRC02:00
*** xperia64 <xperia64!> has joined #yocto02:18
yoctiNew news from stackoverflow: Adding iptables to yocto causes image do_rootfs to fail due to wrong kernel version [on hold] <>03:10
*** xperia64 <xperia64!> has quit IRC03:16
*** xperia64 <xperia64!> has joined #yocto03:42
*** darekp_ <darekp_!> has joined #yocto04:27
*** darekp <darekp!> has quit IRC04:31
*** nighty- <nighty-!> has joined #yocto05:07
*** darekp <darekp!> has joined #yocto05:21
*** darekp_ <darekp_!> has quit IRC05:25
yoctiNew news from stackoverflow: modifying kernel config in Yocto <>06:11
*** jobroe <jobroe!~manjaro-u@> has joined #yocto06:15
*** darekp_ <darekp_!> has joined #yocto06:20
khemRP: I was thinking of dropping bunch of armv5 and below tunes since gcc9 wont support them anyway06:20
khemRP: this would make a few less tunes to maintain06:21
khemor should we keep them in for external toolchains06:21
khemI am not sure how much practical usecase do they have06:22
*** darekp <darekp!> has quit IRC06:24
*** hamis <hamis!~irfan@> has joined #yocto06:55
*** Carton__ <Carton__!> has joined #yocto06:59
*** JaMa <JaMa!~martin@> has joined #yocto07:06
*** thePiGrepper <thePiGrepper!~nagato@> has quit IRC07:37
*** thePiGrepper <thePiGrepper!~nagato@> has joined #yocto07:37
*** hnje <hnje!~hnje@> has joined #yocto07:46
*** tprrt <tprrt!~tprrt@> has joined #yocto07:48
hnjeMorning. 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 ?07:55
*** fl0v0 <fl0v0!> has joined #yocto07:57
*** varjag <varjag!> has joined #yocto08:18
*** Bunio_FH <Bunio_FH!> has joined #yocto08:50
*** rburton <rburton!> has joined #yocto08:51
*** muppe <muppe!> has joined #yocto09:05
*** ravi__ <ravi__!~ravi@2a02:908:698:68a0:fd66:75f8:3696:4763> has joined #yocto09:13
RPkhem: probably something to discuss on the mailing list?09:21
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto09:34
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto09:44
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC09:48
derRichardis IMAGE_FSTYPES = "iso" no longer supported?09:49
derRichardi get "No IMAGE_CMD defined for IMAGE_FSTYPES entry 'iso' - possibly invalid type name or missing support class"09:49
rburtonstill there in my checkout09:54
derRichardmy image is based on recipes-core/images/, when i add "iso" or "hddimg" to IMAGE_FSTYPES, i get the said error09:57
derRichardis this the wrong way to use it?09:57
*** lucaceresoli <lucaceresoli!> has joined #yocto10:07
*** prabhakarlad <prabhakarlad!~prabhakar@> has joined #yocto10:10
derRichardrburton: 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.10:20
derRichardso far setting IMAGE_FSTYPES in the image worked just fine for ext4, tar.xz, squashfs, etc...10:21
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto10:33
RPderRichard: 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)?10:37
derRichardRP: so, setting IMAGE_FSTYPES needs to happend before the inherit? this is the case10:38
derRichardwhy is setting IMAGE_FSTYPES in the image file not good?10:38
derRichardmy yocto project needs to create many different images, of different types.10:39
derRicharde.g. a base image, and a "installer" image which is a live disk10:39
derRichardbase image is tar.xz and squashfs, the installer picks these up and will be a live disk to install them on the target...10:40
derRichardthere is also a debug disk, etc..10:40
derRichardediting the local.conf for each image build seems hacky to me10:40
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto10:48
RPderRichard: I suspect as long as the base value has it and you remove it in the image recipe it would work10:49
RPderRichard: Its just due to the way that particular image type has been implemented :/10:50
*** alicef <alicef!> has joined #yocto10:50
RPderRichard: It is supposed to work from the image recipe...10:50
derRichardyeah, it works now. i had to put "require recipes-core/images/" in the last line of my recipe10:51
*** alicef <alicef!> has quit IRC10:52
*** alicef <alicef!~none@gentoo/developer/alicef> has joined #yocto10:52
*** PinkSnake <PinkSnake!51ff1123@gateway/web/freenode/ip.> has joined #yocto10:55
PinkSnakeHi 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 ? :)10:56
PinkSnake>derRichard, could you provide me more info about that ? I don't understand how to "bypass" crosstool-chain...11:04
derRichardPinkSnake: not sure if i fully understand your use case, but i guess you needs that way:
derRichardso, your recipe needs to be like any other tool which is needed to build the toolchain11:08
PinkSnakein 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 image11:12
yoctiNew news from stackoverflow: Cross compilling .deb package for yocto image?i.e <>11:12
PinkSnake@derRichard thank you i'm going to take a look!11:13
derRichardyou can also look how it is solved here:
derRichardthe tool depends on itself11:14
derRichard(very ugly and hacky...)11:14
derRichardbut hey...11:14
RPderRichard: standard practise for some types of problem. Where did you get a do_stage_append() from though? That should be ancient history11:21
RPoh, its oe-classic. That code is very very old at this point11:22
derRichardRP: yes, but it still works(tm). i found this gem in a customer code base :)11:23
RPderRichard: most of that recipe can probably be deleted now...11:23
kanavinRP: I fixed four or so issues with perl-sanity, we can give it another go maybe?
derRichardRP: sadly the whole regina-rexx recipe is gone in current releases11:24
derRichardi need to get up my arse and upstream my regina-rexx recipe11:24
RPderRichard: we need more people to help maintain recipes, there are only a dedicated few who do :(11:26
derRichardi know, but the list of stuff i maintain is already too long11:27
xtronhow to modify the variable value defined in *.bbclass,11:31
xtronusing some *.*append file11:31
kanavinxtron: sadly not possible really, write your own class and inherit that, or modify the existing one.11:36
*** cquast <cquast!~cquast@> has joined #yocto11:36
xtronkanavin: we can redefine that variable in local.conf so it will be applicable to all recipes?11:42
*** rburton <rburton!> has quit IRC11:43
*** rburton <rburton!> has joined #yocto11:43
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto11:44
derRichardRP: now i understand also the this hint:
derRichardit should not only talk about "live", also "hddimg" and "iso"...11:45
RPderRichard: There are others in that list so perhaps we should not list them. Care to file a bug?11:49
*** bluelightning_ is now known as bluelightning11:51
derRichardRP: done11:54
RPderRichard: thanks11:59
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto12:00
derRichardhow do you guys manage multiple yocto layers? using git submodules? google repo?12:01
derRichardi have one project using submodules, another with repo. both work, but i'm not super happy with both :D12:01
RPderRichard: 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...12:02
derRichardRP: my main use case is "fetch all needed layers, build me a bblayers.conf, a local.conf and run the build"12:03
derRichardcould be also be solved by a shell script. but....12:04
RPderRichard: the yocto autobuilder helper code actually does this...12:06
derRichardRP: well isn't this a huge buildbot thingy?12:08
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC12:10
rburtonderRichard: surely local.conf is just a metter of setting DISTRO12:11
RPderRichard: yocto-autobuilder-helper isn't12:14
* derRichard looks :)12:14
*** gaulishcoin <gaulishcoin!> has joined #yocto12:17
rburtonRP: want to pick my meson qa patches to next?12:18
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has quit IRC12:21
RPrburton: sure, they can do into the next round12:25
rburtonRP : Yocto compatible of 'meta' layer when checking with 'scripts/yocto-check-layer'12:26
rburtonRP: might need to whitelist meta :)12:26
RPrburton: 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...12:28
rburtonI'd say that meta is special here12:29
rburtonno point having meta-bsp and meta-distro just to split those out12:29
RPrburton: I ran most of the current -next on the AB yesterday. Anything in there that concerns you?12:30
RPrburton: first four still need condisderation, man-pages didn't go through the AB yet12:30
rburtonfrom a quick look, seems okay12:31
RPrburton: the eglinfo one is missing a maintainer entry12:32
*** LowLander <LowLander!> has quit IRC12:32
*** marka <marka!~masselst@> has joined #yocto12:32
*** darekp <darekp!> has joined #yocto12:32
RPah, nettle upgrade breaks signing12:33
RParmpit2: :(12:33
*** darekp_ <darekp_!> has quit IRC12:36
RPrburton: the top three patches?12:38
*** LowLander <LowLander!> has joined #yocto12:44
rburtonRP: yes12:45
RPrburton: I picked out a couple of others too12:46
RPrburton: fired another -next to check this patchset works and can merge12:48
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto12:49
*** jij <jij!jonashg@nat/axis/x-gebhtiflrklmqags> has quit IRC12:50
hnjeanyone with some knowledge about the linux-yocto scc/kmeta stuff and can explain why 'series' ends up pointing to a none-existing patch.queue?13:03
*** sveinse <sveinse!> has joined #yocto13:06
sveinseHappy new year guys!13:07
sveinseIs there a smart way of installing a set of packages on an existing running target which does not have a package system installed?13:08
sveinseI 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.13:10
sveinseI 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".13:12
sveinseIs 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?13:13
*** ravi__ <ravi__!~ravi@2a02:908:698:68a0:fd66:75f8:3696:4763> has quit IRC13:14
RPsveinse: not really. Its a package manager problem, not a bitbake one13:20
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC13:21
muppeHi. Does anyone have an idea why sed fails in "do_install_append_class-native" (krogoth)? For some reason I don't have ${D}/${libdir}/python2.7/site-package13:56
muppein place13:56
muppe(well "sed" fails because in cannot find but who should put that file there and why it is not there in my env?)13:57
RPmuppe: you've turned off python extensions in rpm? you're using a different python version?13:57
muppehmm... intentionally I haven't done that but it is quite likely that something like that has happened.13:58
muppeI am using debian package manager in my build (local.conf) but I guess it still requires some rpm thingies.13:59
RPmuppe: have a look at rpm's configure log?13:59
RPmuppe: could also be getting confused with the host python version verses the one in the build14:00
muppeI 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.14:02
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC14:03
RPmuppe: should be independent but krogoth is old and doesn't have some of the functionality we added in later releases14:04
muppeAm I shooting myself to foot if I just go ahead and comment out those "do_install_append_class" parts?14:05
*** shauno <shauno!~soneil@pdpc/supporter/professional/shauno> has quit IRC14:13
*** JaMa <JaMa!~martin@> has quit IRC14:14
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto14:22
*** shauno <shauno!~soneil@pdpc/supporter/professional/shauno> has joined #yocto14:26
sveinseRP: Yes. Which essentially implies that images without package manager are only intended for static images.14:39
* Crofton had posted that to another channel, so had it handy :)14:40
sveinseAs 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.14:41
*** gtristan <gtristan!~tristanva@> has joined #yocto14:50
*** jobroe <jobroe!~manjaro-u@> has quit IRC14:55
RPsveinse: 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 solution15:01
RPthere are some options out there, nothing has made it to be part of oe-core though15:01
*** florian_kc is now known as florian15:12
yoctiNew news from stackoverflow: Cross compilling .deb package for yocto image?i.e [on hold] <>15:13
*** hamis <hamis!~irfan@> has quit IRC15:25
kergothsveinse: there are multiple options, just as rp says none in oe-core. swupdate works well for example15:29
* armpit2 sigh... rebasing again15:31
*** armpit2 is now known as armpit15:31
*** zeddii_home <zeddii_home!> has joined #yocto15:34
*** varjag <varjag!> has quit IRC15:43
*** kaspter <kaspter!~Instantbi@> has quit IRC16:07
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC16:08
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC16:11
yoctiNew news from stackoverflow: Building Mali Driver without X11 <>16:13
*** kaspter <kaspter!~Instantbi@> has joined #yocto16:18
*** Bunio_FH <Bunio_FH!> has quit IRC16:26
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto16:29
*** rewitt <rewitt!~rewitt@> has quit IRC16:33
*** rewitt <rewitt!~rewitt@> has joined #yocto16:41
*** gtristan <gtristan!~tristanva@> has quit IRC16:54
*** gtristan <gtristan!~tristanva@> has joined #yocto16:55
*** ravi__ <ravi__!~ravi@2a02:908:698:68a0:6d70:760d:4923:5063> has joined #yocto17:03
*** fl0v0 <fl0v0!> has quit IRC17:05
*** Carton__ <Carton__!> has quit IRC17:09
*** OpenSorceress <OpenSorceress!> has joined #yocto17:11
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto17:11
yoctiNew news from stackoverflow: Yocto / Poky: install and use shared library .so on separate layers <>17:13
*** ravi__ <ravi__!~ravi@2a02:908:698:68a0:6d70:760d:4923:5063> has quit IRC17:19
*** robbawebba <robbawebba!~rob@> has quit IRC17:44
khemRP: sent a patch already to start the discussion17:48
RPkhem: Thanks! :)17:50
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC17:50
*** cquast <cquast!~cquast@> has quit IRC17:51
khemRP: I will also sent another patch to consider runit for OE-Core17:52
khemRP: systemd while good, does not fit the shoes of all embedded devices that Yocto/OE targets17:52
RPkhem: we still have problems with systemd so adding another worries me :/17:52
RPkhem: but yes, systemd isn't ideal17:53
khemI know :), I was thinking of getting it in place of sysvinit17:53
khemso it have application life cycle management on top of old script based init systems17:53
khemwhich is actually all people want in embedded world when they switch to systemd largely17:54
RPkhem: I think I need to learn more about runit17:54
khemits an old init system, major distros have it as option17:54
khemsome lesser known distros use it as default e.g. voidlinux17:55
khemits 100K in size and can be a static binary17:55
*** tprrt <tprrt!~tprrt@> has quit IRC17:55
khemand boots blazing fast17:55
khemon systems with 128M memory17:55
khemMaybe I will create a layer for it for now17:56
khemand we can consider it for core in future releases17:57
RPkhem: I like the sound of it, just need to learn more18:00
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC18:01
*** kroon <kroon!> has joined #yocto18:06
khemRP: yes, I think there is a place for a init system between sysvinit and systemd18:09
* kroon wonders why openssl.do_package_write_ipk depends on perl.do_packagedata, and where in the meta data that is described18:11
khemkroon: there must be perl scripts in there18:16
khemthere is rdeps18:16
*** kaspter <kaspter!~Instantbi@> has quit IRC18:21
*** kaspter <kaspter!~Instantbi@> has joined #yocto18:21
kroonkhem, 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 ?18:28
*** darekp_ <darekp_!> has joined #yocto18:30
*** darekp <darekp!> has quit IRC18:33
khemkroon: yes, since real rdeps would be computed during image build18:33
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto18:34
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto18:37
*** darekp <darekp!> has joined #yocto18:40
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC18:42
*** darekp_ <darekp_!> has quit IRC18:44
kroonhmm, 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 image18:46
kroonbut i'm mostly never interested in packages not installed in the image, they could be discarded early as far as im concerned..18:50
kergoththat'd be decidedly non-trivial, since you can emit packages in one bitbake command and then bake 3 different images in the next18:58
*** gtristan <gtristan!~tristanva@> has quit IRC18:59
kroonyeah ok, but perhaps not build recipes for rdeps related to packages that aren't ending up installed in the image ?19:02
kroona 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 target19:07
ds2just because your target don't need it doesn't mean you may not install it later (in general)19:09
kroonyeah in general, but having the option of avoiding it would be nice, since in my case I know i'm not gonna need it19:10
*** gtristan <gtristan!~tristanva@> has joined #yocto19:12
derRichardhmm, the documentation on wic is rather sparse19:18
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC19:25
*** OpenSorc_ <OpenSorc_!> has joined #yocto19:25
derRichardmy 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?19:26
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:27
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC19:30
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto19:31
*** OpenSorc_ <OpenSorc_!> has quit IRC19:36
rburtonkroon: if its a huge problem, make a packageconfig for the perl bits and then turn it off.19:39
rburtonor, live with building perl occasionally.  once in the sstate it will get reused anyway, right19:40
yoctiNew news from stackoverflow: Bitbake putting config files in wrong package. Ignoring FILES_ directives in my .bbappend. Next place to look/how to fix? <>19:44
kroonrburton, true19:46
*** WillMiles <WillMiles!> has joined #yocto19:51
*** demonimin <demonimin!~demonimin@unaffiliated/demonimin> has joined #yocto20:15
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has left #yocto20:26
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto20:26
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto20:43
*** sa2ajj <sa2ajj!> has joined #yocto20:48
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC20:52
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto20:52
*** tgraydon <tgraydon!textual@nat/intel/x-lcadsvkzzuyfgbor> has joined #yocto20:57
*** thePiGrepper <thePiGrepper!~nagato@> has quit IRC21:03
derRichardmeta/classes/image-live.bbclass sets LABELS_LIVE ?= "boot install"21:05
derRichardbut i see no users of LABELS_LIVE?21:05
derRichardare my git grep skills too weak or that do i miss?21:05
RPyay, eclipse fixed and a green master-next :)21:13
RPhalstead: was that you? If so thanks!21:13
halsteadRP, I made a temporary solution while waiting on a more lasting plan.21:14
rburtonderRichard: its LABELS in LIVE mode21:15
rburtonoe-core d7d1e0193c94abb1cd2daf1c298c8c1788f3616d21:15
rburton(my grep fu is stronger than yours ;)21:15
rburton(git log -G LABELS_LIVE, second commit)21:15
derRichardrburton: oh dear! once again i got fooled by the underscore magic in bitbake :-(((21:15
*** armpit <armpit!~armpit@2601:202:4180:c33:a0d1:1816:16ad:4538> has quit IRC21:16
rburtonthat's not override magic,21:16
rburtonthats literally variables get created magically21:16
rburton(see the sha)21:16
derRichardyeah, but it is still magic :P21:17
rburtonits ugly and i wish i didn't just learn about that bit21:17
derRichardi grepped in the source tree for "LABELS_LIVE"21:17
derRichardthis makes reading the source a little odd21:18
rburtonyeah, log -G searches the log for commits which introduce or remove that line, good for finding out context21:18
derRichardyeah, that's true. thanks for the hint21:18
rburtonRP: 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.21:19
RPrburton: ok, sounds good. I merged the other two pieces of it whilst we fix the test21:20
RPrburton: just merged most of -next21:20
RPhalstead: much appreciated, thanks!21:21
halsteadRP, since the solution is temporary we probably shouldn't tag any releases until the download path is updated to something more permanent though.21:21
RPhalstead: 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?21:25
*** marka <marka!~masselst@> has quit IRC21:26
rburtonRP: ok how the hell can i get a testsdk unittest to log output to the console even it passes21:26
*** armpit <armpit!~armpit@2601:202:4180:c33:7144:30fa:a7a1:7688> has joined #yocto21:27
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC21:28
RPrburton: output handling in unittest is horrible :(21:33
rburtonbb.warn works21:33
rburtonwould be nice if a logger was somehow passed in21:33
rburtonright fired21:34
RPrburton: its rat infested spools of razor wire :(21:36
halsteadRP, 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.21:37
* RP has tried to untangle it a few times21:37
*** OpenSorceress <OpenSorceress!> has joined #yocto21:38
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto21:38
RPhalstead: What is the next step to move things forward?21:43
khemRP: seems to have worked for me world build looks same as before core-image-sato-sdk-ptest passed tests21:46
RPkhem: seems ok to me in principle, Martin is the one who may have the most insight...21:47
khemhe has already looked at v1 and I addressed the feedback in this v221:47
khemthis is v1
RPkhem: I saw the discussion, looks good! :)21:48
khemI am going to send email to seek deletion of armv4 tunes21:48
khemand non thumb tunes21:49
khemfor <=v521:49
khemanother part of me says it might still be ok to keep them as some external toolchains might still be using it .. dont know21:49
halsteadRP, I have the redirect in place. Next is to build the plugin and see what happens.21:50
RPkhem: Its probably time to retire them21:51
RPkhem: armv4 predates most of us in the project21:52
*** dfaught <dfaught!~dfaught@> has joined #yocto22:04
bluelightningthe original iPAQs were armv4 IIRC22:05
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC22:05
bluelightningnot in any way a reason to keep the support around of course :D22:06
ds2long live PXA2xx!!!!22:07
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has quit IRC22:07
kroonI'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 ?22:07
derRichardhow can it happen that your commit messages reference unknown git sha1s? are you rebasing the tree? :(22:10
derRicharde.g. 53078a00ceab ("core-image-minimal-initramfs: use initramfs-framework for initialization") says:22:10
derRichardinitramfs-framework is more modular and expandable. This change was22:10
derRichard    proposed in commit 28fc6ba761ed4a47efa7c43e7f7dff5e2fe72b5e22:10
derRichardbut there is no 28fc6ba761ed4a47efa7c43e7f7dff5e2fe72b5e22:10
neverpanicderRichard: It might be openembedded-core vs. poky22:11
kroonneverpanic, is there a doc describing this ?22:11
neverpaniccheck both for the commit, the commit IDs change when stuff is merged into the poky repo22:11
derRichardneverpanic: when you merge stuff (in terms of git merge), the sha1s won't change22:12
kroonneverpanic, especially where that official yocto sstate cache mirror lives22:12
neverpanickroon: it's always a good idea to search the mega-manual, e.g.
neverpanicderRichard: the road from openembedded-core -> poky isn't a merge in the git sense22:12
derRichardneverpanic: oh :(22:12
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto22:13
neverpanicderRichard: See
kroonneverpanic, thats just the C library right, not the sstate cache ?22:18
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC22:18
neverpanicright, seems I misunderstood this, you'll still build the recipes locally, but you can share them across distros22:20
kroonneverpanic, hmm ok. I was hoping yocto would also host some sort of "official" sstate cache mirror one could use22:21
*** WillMiles <WillMiles!> has quit IRC22:22
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto22:25
*** gaulishcoin <gaulishcoin!> has quit IRC22:32
*** gaulishcoin <gaulishcoin!> has joined #yocto22:32
*** gtristan <gtristan!~tristanva@> has quit IRC22:45
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto22:50
*** kroon <kroon!> has quit IRC22:55
*** vegards <vegards!5434ebbc@gateway/web/freenode/ip.> has joined #yocto23:01
*** JaMa <JaMa!~martin@> has joined #yocto23:12
vegardsHello. 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.23:13
vegardsIn 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?23:13
derRichardvegards: well, you need to request the full sources. no binaries23:15
neverpanicYou may be able to get away with keeping the kernel and its modules (for hw support) and swap out the userland.23:17
neverpanicIn which case you might get away with an SDK and recompiling your userland from source.23:17
* derRichard wonders how vegards ever did security fixes23:18
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto23:18
neverpanicProbably paid the vendor to do them?23:18
neverpanicChances are the vendor doesn't want to provide a newer Qt version due to Qt > 5.6 being LGPL-3.023:22
*** rewitt <rewitt!~rewitt@> has quit IRC23:22
khemQT licencing is another FUD23:23
*** ds2 <ds2!> has quit IRC23:23
neverpanicembedded device vendors are generally sceptical of any *GPL-3 type licenses23:24
derRichardTBH, i'd never ever use a v3, v2 only.23:24
*** rewitt <rewitt!~rewitt@> has joined #yocto23:25
derRichardbut i guess i'm too linux'ish ;)23:25
vegardsThe vendor said they could provide Linux 4.1.15 U-Boot and Kernel BSP, is that that what I need?23:25
neverpanicderRichard: So you're using GCC 4.3?23:25
derRichardneverpanic: use in terms of using for my own code23:25
neverpanicvegards: Yes, that's a good start.23:26
derRichardi.e. products i create23:26
neverpanicIsn't using a compiler "using it for your own code"?23:26
* derRichard is not in bikeshedding mood 23:27
vegardsAlright, Thanks, I'll do a request then. The device is an industrial HMI, havent seen any security fixes for it yet...23:27
neverpanicvegards: 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.23:28
*** ds2 <ds2!> has joined #yocto23:33
khemderRichard: why wont you use v3 ?23:33
khemthen you must stick to gcc < 4.4 too23:34
derRichardkhem: IMHO v2 is good enough.23:34
derRichardkhem: using as licence for code i write. e.g. projects i create for customers23:34
khemOkay thats your choice23:35
derRichardwhat i said23:35
vegardsneverpanic will do, do you know hat I specifically have to be aware of?23:36
khemLGPL 3.0 is no different then GPL-2.023:36
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC23:36
kheminfact people confuse the versions and variants a lot I have seen23:36
*** OpenSorceress <OpenSorceress!> has joined #yocto23:37
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto23:37
derRichardkhem: true23:37
neverpanicvegards: 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.23:40
neverpanickhem: That's not entirely correct from my understanding.23:40
* derRichard had a few weeks ago a phone call with qt guys on licencing. it was "fun". ;-\23:42
khemneverpanic: yes, additionally one has to provide a way to replace LGPL-3 licenced code if you dynamically link your app to it23:47
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has quit IRC23:48
*** OpenSorceress <OpenSorceress!> has joined #yocto23:56
*** OpenSorceress <OpenSorceress!~opensorce@unaffiliated/screamingbanshee> has joined #yocto23:56
derRichardhmm, my images does "require recipes-core/images/", i have to set IMAGE_INSTALL after the require because overwrites IMAGE_INSTALL. and i have to set IMAGE_FSTYPES before be require.23:56
derRichardthat's kinda gross23:57
derRichardis there a better approach?23:57
khemjust set CORE_IMAGE_EXTRA_INSTALL in your image recipe to add packages23:58
derRichardthen require ... can be the last line in my bb file?23:59
khemIMAGE_FSTYPES could be set anywhere in config metadata23:59

Generated by 2.11.0 by Marius Gedminas - find it at!