Tuesday, 2018-03-20

*** Jefro <Jefro!josiermi@nat/intel/x-pqmiyjctcrpamies> has quit IRC00:01
*** kpo__ <kpo__!~bob@user-94-254-242-24.play-internet.pl> has joined #yocto00:01
*** Jefro <Jefro!~josiermi@> has joined #yocto00:01
*** scottrif <scottrif!~scottrif@> has quit IRC00:02
*** Willy-- <Willy--!~william@> has joined #yocto00:04
*** Jefro <Jefro!~josiermi@> has quit IRC00:05
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto00:07
*** seebs <seebs!~seebs@> has quit IRC00:09
*** seebs <seebs!~seebs@> has joined #yocto00:16
*** kmorrow <kmorrow!81c4e2e3@gateway/web/freenode/ip.> has quit IRC00:19
*** kpo__ <kpo__!~bob@user-94-254-242-24.play-internet.pl> has quit IRC00:27
*** yann <yann!~yann@LFbn-1-527-224.w86-245.abo.wanadoo.fr> has quit IRC00:28
*** majuk <majuk!~majuk@75-163-148-173.clsp.qwest.net> has quit IRC00:28
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-hfqwhhfqavxzjjzo> has joined #yocto00:35
*** nighty- <nighty-!~nighty@kyotolabs.asahinet.com> has joined #yocto00:43
*** martinkelly <martinkelly!~martin@71-212-16-149.tukw.qwest.net> has quit IRC00:50
*** majuk <majuk!~majuk@75-163-148-173.clsp.qwest.net> has joined #yocto00:56
*** batman_ <batman_!95c73efe@gateway/web/freenode/ip.> has quit IRC01:02
*** slips <slips!~slips@138.51-174-203.customer.lyse.net> has quit IRC01:03
*** Jefro <Jefro!~josiermi@> has joined #yocto01:05
*** Guest14668 <Guest14668!95c73efe@gateway/web/freenode/ip.> has quit IRC01:06
*** kpo__ <kpo__!~bob@user-94-254-242-24.play-internet.pl> has joined #yocto01:12
*** bluelightning_ <bluelightning_!~paul@> has joined #yocto01:15
*** bluelightning_ <bluelightning_!~paul@> has quit IRC01:15
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto01:15
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto01:16
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC01:18
khemwhat warning do you see01:19
*** Crofton <Crofton!~Crofton@2601:284:8200:f356::c8ca> has joined #yocto01:22
*** Willy-- <Willy--!~william@> has quit IRC01:36
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has quit IRC01:36
*** kpo__ <kpo__!~bob@user-94-254-242-24.play-internet.pl> has quit IRC01:41
*** DarkKnight <DarkKnight!~quassel@HSI-KBW-046-005-002-217.hsi8.kabel-badenwuerttemberg.de> has quit IRC01:46
*** Jefro <Jefro!~josiermi@> has quit IRC01:49
*** marka <marka!~masselst@> has quit IRC01:53
*** sgw2 <sgw2!~swold@> has quit IRC01:55
*** morphis__ <morphis__!~morphis@pD9ED670D.dip0.t-ipconnect.de> has quit IRC02:05
*** sgw <sgw!~swold@c-71-238-116-168.hsd1.or.comcast.net> has joined #yocto02:12
*** cratliff <cratliff!~cratliff@> has joined #yocto02:23
*** majuk <majuk!~majuk@75-163-148-173.clsp.qwest.net> has quit IRC02:33
*** kpo__ <kpo__!~bob@user-94-254-242-24.play-internet.pl> has joined #yocto02:40
*** slips <slips!~slips@138.51-174-203.customer.lyse.net> has joined #yocto02:52
*** learningc <learningc!~User@mti-37-145.tm.net.my> has joined #yocto02:53
*** sgw <sgw!~swold@c-71-238-116-168.hsd1.or.comcast.net> has quit IRC02:57
*** sgw <sgw!~swold@> has joined #yocto02:58
*** kpo__ <kpo__!~bob@user-94-254-242-24.play-internet.pl> has quit IRC03:06
*** fl0v0 <fl0v0!~fvo@mue-88-130-99-095.dsl.tropolys.de> has quit IRC03:20
*** fl0v01 <fl0v01!~fvo@i3ED6F34A.versanet.de> has joined #yocto03:20
*** Crofton <Crofton!~Crofton@2601:284:8200:f356::c8ca> has quit IRC03:39
*** learningc <learningc!~User@mti-37-145.tm.net.my> has quit IRC03:46
*** morphis <morphis!~morphis@pD9ED7F7C.dip0.t-ipconnect.de> has joined #yocto03:55
*** cratliff <cratliff!~cratliff@> has quit IRC04:00
*** gtristan <gtristan!~tristanva@> has joined #yocto04:16
-YoctoAutoBuilder- build #928 of nightly-oe-selftest is complete: Failure [failed Running oe-selftest] Build details are at https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/92804:17
*** thaytan <thaytan!~thaytan@180-150-118-156.NBN.mel.aussiebb.net> has quit IRC04:18
*** thaytan <thaytan!~thaytan@180-150-118-156.NBN.mel.aussiebb.net> has joined #yocto04:21
*** Marex <Marex!~Marex@> has quit IRC04:25
*** Marex <Marex!~Marex@> has joined #yocto04:26
*** majuk <majuk!~majuk@75-163-148-173.clsp.qwest.net> has joined #yocto04:34
*** majuk <majuk!~majuk@75-163-148-173.clsp.qwest.net> has quit IRC04:39
*** sgw <sgw!~swold@> has quit IRC04:42
*** stephano <stephano!~stephano@> has joined #yocto04:50
*** stephano <stephano!~stephano@> has quit IRC04:50
*** dreyna <dreyna!~dreyna@2601:646:4201:b1a0:9506:235c:380:51fd> has quit IRC05:02
*** ntl <ntl!~nathanl@65-36-80-8.dyn.grandenetworks.net> has quit IRC05:11
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-hfqwhhfqavxzjjzo> has quit IRC05:24
*** sgw <sgw!~swold@c-71-238-116-168.hsd1.or.comcast.net> has joined #yocto05:25
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has joined #yocto05:29
*** sgw <sgw!~swold@c-71-238-116-168.hsd1.or.comcast.net> has quit IRC05:31
*** sgw <sgw!swold@nat/intel/x-ggjowetuckdkyjdj> has joined #yocto05:32
*** robert_yang <robert_yang!~robert@> has quit IRC05:52
*** hanthings <hanthings!~nandor@> has joined #yocto06:12
hanthingsHi. I have some issue with devtool and I would need some advice.06:15
khemhanthings: ask away06:17
hanthingswhen using devtool it seems that the local files are moved to oe-local-files dir, and if the recipe tries to install these files from workdir there are not found anymore. Why devtool is moving these files away compared with bitbake which keeps these files in workdir. is there any workaround to this?06:18
hanthingsseems that the files are moved after unpack task and before patch task (devtool:_extract_sources)06:19
*** agust <agust!~agust@> has joined #yocto06:21
*** hamis <hamis!~irfan@host-58-net-96-160-119.mobilinkinfinity.net.pk> has joined #yocto06:23
*** tasslehoff <tasslehoff!~Tasslehof@> has joined #yocto06:27
khemhow are you installing them in recipe ?06:33
khemthere should be symlinks in top of srctree pointing back into oe-local-files06:37
khemdo you see them06:38
*** Jefro <Jefro!josiermi@nat/intel/x-piyhrwgjpozuwroi> has joined #yocto06:43
*** t0mmy <t0mmy!~tprrt@> has joined #yocto06:45
*** sysdef <sysdef!~sysdef@debiancenter/founder.developer/pdpc.professional.sysdef> has joined #yocto06:50
sysdefhello, yesterday i tried for hours to get core-image-minimal-initramfs to boot (qemu/i586) but had no luck. cannot mount rootfs. someone has a useful hint for me?06:53
hanthingskhem, in the recipe I do install them by `install ... ${workdir}/file ${D}path/file07:05
hanthingskhem, in the recipe I do install them by `install ... ${workdir}/file ${D}path/file`07:05
hanthingskhem, I don't see any symlinks07:05
hanthingskhem, there are not part of srctree07:05
hanthingskhem, there are just local files07:06
*** ggtk <ggtk!c1e7a222@gateway/web/freenode/ip.> has quit IRC07:10
*** dengke_1990 <dengke_1990!~dengke@> has quit IRC07:11
*** frieder <frieder!~frieder@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has joined #yocto07:17
*** Jefro <Jefro!josiermi@nat/intel/x-piyhrwgjpozuwroi> has quit IRC07:19
khemit should be ${WORKDIR} and are you on master?07:20
*** sjolley <sjolley!~sjolley@> has joined #yocto07:22
hanthingskhem, I'm on rocko07:27
*** hanthings <hanthings!~nandor@> has left #yocto07:27
*** varjag <varjag!~user@122.62-97-226.bkkb.no> has joined #yocto07:28
*** hanthings <hanthings!~nandor@> has joined #yocto07:29
*** pohly <pohly!~pohly@p548497B7.dip0.t-ipconnect.de> has joined #yocto07:31
hanthingskhem, ?07:37
LetoThe2ndsysdef: standard core-image-minimal-initramfs on qemux86? just on poky head?07:39
khemhanthings: I would suggest to try it on master and see if it behaves differently07:41
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has joined #yocto07:41
hanthingskhem, it's not feasible for me to try on master :). in order to try it I probably need to fix/adapt other stuff as well07:43
sysdefLetoThe2nd: yes. tried "root=/dev/ram0" and "root=" but no luck. i can boot tinycorelinux rootfs (cpio and cpio.gz) with the kernel so i guess it's not a kernel option07:43
LetoThe2ndsysdef: no, i don't think so too. anything additional i need to know so i can try an reproduce it? addional layers in use or such?07:47
LetoThe2ndsysdef: and, i guess core-image-minimal work fine?07:48
sysdefcore-image-minimal boots up fine, yes.i think i'll reset all my changes from yesterday to have a clean setup again07:49
LetoThe2ndok, i yank out a build too. lets see.07:49
sysdefLetoThe2nd: https://pastebin.com/raw/fQxKjatW07:53
LetoThe2ndsysdef: you're mixing IMAGE_INSTALL and CORE_IMAGE_EXTRA_INSTALL, as well as cramming everything into local.conf is not a good idea too.. but yet thats not the source of your issue, me thinks.07:56
*** sjolley <sjolley!~sjolley@> has quit IRC07:59
*** fl0v01 <fl0v01!~fvo@i3ED6F34A.versanet.de> has quit IRC08:00
*** fl0v0 <fl0v0!~fvo@i3ED6F34A.versanet.de> has joined #yocto08:00
*** rdanter <rdanter!~rad@cpc76236-cosh15-2-0-cust704.6-1.cable.virginm.net> has joined #yocto08:14
*** T_UNIX <T_UNIX!uid218288@gateway/web/irccloud.com/x-cluhilcbbmsgifdz> has joined #yocto08:25
*** TobSnyder <TobSnyder!~schneider@ipb2180325.dynamic.kabel-deutschland.de> has joined #yocto08:31
*** morphis <morphis!~morphis@pD9ED7F7C.dip0.t-ipconnect.de> has quit IRC08:36
*** morphis <morphis!~morphis@pD9ED7F7C.dip0.t-ipconnect.de> has joined #yocto08:36
yoctiNew news from stackoverflow: How to know install in build image package in yocto? <https://stackoverflow.com/questions/49379524/how-to-know-install-in-build-image-package-in-yocto>08:39
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto09:07
*** vdehors <vdehors!~vdehors@91-162-62-2.subs.proxad.net> has joined #yocto09:07
*** yann <yann!~yann@> has joined #yocto09:23
*** xtron <xtron!~xtron@> has joined #yocto09:27
sysdefLetoThe2nd: the result from a fresh install: http://sysdef.de/gallery/photos/yocto/2018-03-20_10-28-38.png09:35
LetoThe2ndsysdef: i'm seeing the exact same. yet, after the "waiting for removable media" it counts down 30 seconds, and the drops into busybox. so my understanding is that the initramfs is preconfigured to skip to some other root later, which it doesn't find. but the shell it drops to comes from the initramfs and seems to be functional.09:44
sysdefso i just have to find the timeout counter and set it to 3 sec? ^^09:45
LetoThe2ndor not use it at all if you want to stay in the initramfs.09:46
sysdefto use what at all?09:46
sysdefi mean: what is "it" and how can i avoid using "it"09:47
LetoThe2ndwell, i don't know what you want. why did you even choose an initramfs in the first place?09:47
LetoThe2ndand there, /init is the setup script, pretty verbose about what the initramfs is meant to do. disabling the timeout should be easy.09:48
sysdefi wanna use initramfs to have a clean systam at any boot. no need for persistent data so initramfs or even .iso would be perfect09:49
LetoThe2ndsound like this is what you actually want09:50
LetoThe2ndinitramfs is kinda special in some ways, and given the usual embedded/container usecase not needed very often. hence, its working, but not very polished.09:50
LetoThe2ndusually we go for kernel+initrd, which behaves way more similar to a classic system.09:51
LetoThe2ndplus, you might want IMAGE_FEATURE rootfs-read-only09:51
sysdefmy use case is a qemu image that runs an openvpn client on windows09:52
fancerkergoth: cool. Thanks, man! Funny to see, I did half of the things u did in the cross-canadians support. I'll merge it with my changes and try it out.09:52
sysdefLetoThe2nd: i have no idea what to do with that script. i heard "yocto" the first time, yesterday09:54
LetoThe2ndsysdef: i'd augment core-image-minimal with waht you need, have it create a readonly rootfs in ext* or something, and then use that as initrd. this is basically even the rumqemu hello world case.09:54
LetoThe2ndsysdef: just don't use initramfs here. it will give you headaches but no gain.09:55
sysdefk, i'll give it a try ...09:56
LetoThe2ndsysdef: plus, try to keep tinkering in local.conf at a total minimum. pour stuff into an own image, that makes stuff way more reproductible. a simple example is the recipe for core-image-minimal-dev: it just adds something to core-image-minimal. copy it and beat it into shape for your needs :)10:04
T_UNIXI was wondering: How do I extend  a recipe `MY_IMAGE.bb` as a new recipe `MY_EXTENDED_IMAGE.bb`, so that any `MY_IMAGE.bbappend` are applied?10:06
sveinseOn builds extensible SDKs with  bitbake -c populate_sdk_ext imagename .  What happens if I build multiple images? And can I have multiple machines in the same SDK? Apparently populate_sdk_ext cannot be a target of its own10:06
LetoThe2ndT_UNIX: thats not how appends work.10:06
T_UNIXafaii `inherit` is supposed to be used w/ `.bbclass` only10:06
*** vladzouth <vladzouth!500c5411@gateway/web/freenode/ip.> has joined #yocto10:07
LetoThe2ndT_UNIX: exactly. inherit is for classes, bbappends are name-matching the recipe file name.10:07
LetoThe2ndT_UNIX: if you want recipes to share stuff, pull it out into an .inc file that all users pull it.10:07
LetoThe2nd*in, even.10:08
sveinseHow do I control which packages gets included in extensible SDKs?10:10
sveinseI'm getting failure on do_sdk_depends as brcm-firmware and linux-firmware provide the same file10:11
sveinsenayfe: Where do you define that?10:12
sveinseBecause in the old SDK scheme, I had a meta-toolchain-sp.bb which inherit populate_sdk and then sets TOOLCHAIN_TARGET_TASK, but this is apparently not working for sdk_ext10:13
sveinseI.e. on SDKs I used to run bitbake meta-toolchain-sp to generate the SDK, with with the extensible scheme one does bitbake -c populate_sdk_ext image, and this is where I fall off10:14
vladzouthHi, i use fsl yocto project given by KARO(https://www.karo-electronics.com/1646.html?&L=1) to build an embedded linux system for the KARO TX6S-8035 target. The build work fine. I use the freescale mfgtool to download images into the board. when the kernel start, i have the following error message: "Kernel panic - not syncing: Requested init /linuxrc failed (error -2)" . How can i fix this?10:17
*** AndersD <AndersD!~anders@2a02:aa1:160d:867f:ea2a:eaff:fe2e:dcef> has joined #yocto10:21
*** xtron <xtron!~xtron@> has quit IRC10:26
*** Anticom <Anticom!~anticom@> has joined #yocto10:28
sysdefLetoThe2nd: skipped: 'rootfs-read-only' in IMAGE_FEATURES is not a valid image feature. Valid features: allow-empty-password dbg-pkgs... the same with read-only-rootfs. not in that list10:29
sysdefoh, wait, it's working...10:30
sysdefread-only-rootfs instead of rootfs-read-only. my file save to the server just crashed :s10:31
*** AndersD <AndersD!~anders@2a02:aa1:160d:867f:ea2a:eaff:fe2e:dcef> has quit IRC10:32
*** AndersD <AndersD!~anders@2a02:aa1:160d:867f:ea2a:eaff:fe2e:dcef> has joined #yocto10:32
*** AndersD <AndersD!~anders@2a02:aa1:160d:867f:ea2a:eaff:fe2e:dcef> has joined #yocto10:33
nayfesveinse: did you look at https://www.yoctoproject.org/docs/2.5/sdk-manual/sdk-manual.html#sdk-installing-additional-items-into-the-extensible-sdk ?10:36
*** AndersD <AndersD!~anders@2a02:aa1:160d:867f:ea2a:eaff:fe2e:dcef> has quit IRC10:39
*** AndersD <AndersD!~anders@2a02:aa1:160d:867f:ea2a:eaff:fe2e:dcef> has joined #yocto10:39
*** AndersD <AndersD!~anders@2a02:aa1:160d:867f:ea2a:eaff:fe2e:dcef> has quit IRC10:41
sveinsenayfe: yes, but I don't have any ext SDK to begin with, so I don't have devtool to play with yet10:42
sysdefLetoThe2nd: i can boot, rootfs is read-only but the size "exploded" from ~10MB to 143MB10:44
sveinseThere's probably something fundamental I'm not getting hold of here10:45
*** AndersD <AndersD!~anders@2a02:aa1:160d:867f:ea2a:eaff:fe2e:dcef> has joined #yocto10:46
*** AndersD <AndersD!~anders@2a02:aa1:160d:867f:ea2a:eaff:fe2e:dcef> has quit IRC10:46
nayfeDevtool I'd not dependant to eSDK10:47
*** rburton <rburton!~textual@> has joined #yocto10:52
*** phako[m] <phako[m]!phakomatri@gateway/shell/matrix.org/x-hzoljmpbcahjaqnj> has left #yocto10:53
*** hastake <hastake!~ack@cable-> has quit IRC11:00
*** hastake <hastake!~ack@cable-> has joined #yocto11:04
LetoThe2ndsysdef: have a look into the tmp/deploy/$YOURPACKAGEMANAGER/qemux86 directory and check what is eating the space.11:12
LetoThe2ndbbl, lünch!11:12
*** luneff <luneff!~yury@> has joined #yocto11:26
sysdefLetoThe2nd: änjoi jur fuddah.11:34
sveinseAny reasons why glibc-locale should fail building (installed-vs-shipped) on vanilly poky, rocko and qmeu86-64?11:39
*** AndersD <AndersD!~anders@2a02:aa1:160d:867f:ea2a:eaff:fe2e:dcef> has joined #yocto11:58
*** nighty- <nighty-!~nighty@kyotolabs.asahinet.com> has quit IRC11:58
*** JaMa <JaMa!~martin@> has joined #yocto12:04
*** wooosaiiii <wooosaiiii!~woo@cpe-90-157-180-95.static.amis.net> has quit IRC12:05
LetoThe2ndsysdef: did so. found enlightenment already?12:08
*** AndersD <AndersD!~anders@2a02:aa1:160d:867f:ea2a:eaff:fe2e:dcef> has quit IRC12:10
*** wooosaiiii <wooosaiiii!~woo@cpe-90-157-180-95.static.amis.net> has joined #yocto12:12
sveinseI had DISTRO_FEATURES += " pam x11 opengl" in my local.conf. When I removed this, everything built fine12:15
T_UNIXLetoThe2nd: the problem is that I have a common base image, which is extended for various products via `.bbappend`. Then there shall be a `-dev` distribution that simply extends that base image w/ some packages and settings.12:19
T_UNIXcurrently I use `require`, but by doing so the `.bbappend` are - obviously - irgnored12:19
LetoThe2ndT_UNIX: well, maybe you need to rethink that structure then?12:19
*** marka <marka!~masselst@> has joined #yocto12:21
T_UNIXI guess I'll have to. It would have been the way with the smallest replication of code and truely layer-style :-/12:21
LetoThe2ndin our experience, the common-base-image thing just doesnt work.12:22
T_UNIXafair poky uses the same style `include core-image` for the derivative images, doesn't it?12:22
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC12:23
LetoThe2ndits a class, not a base image. totally different concept.12:23
LetoThe2ndbecause if you look at it, it doesn't define a set that makes up the base image, as you call it. it just offers the infrastructure.12:24
T_UNIXline 7012:26
LetoThe2ndi know what you mean, but thats just the stuff needed to actually being able to boot. its a subtle line to hit, we have been exactly there too.12:27
LetoThe2ndwhat totally did backfire is the attempt to define a "base image that we can extend in all of our products.". it worked for exactly the first product.12:28
sysdefLetoThe2nd: the initramfs thing is using busybox (ash) instead of the full gnutools (core-utils, bash)12:28
LetoThe2ndsysdef: then find out what pulls that in. i did a build of core-image-minimal over lunch, and it is 10M12:28
LetoThe2ndsysdef: so something in the stuff you added in the paste you showed me probably pulls in a lot of dependencies.12:29
T_UNIXhm... currently we use different MACHINEs and conditional `.bbappend` (that are included, depending on `MACHINE`), which significantly reduces the maintenance and copy/pasta.12:31
T_UNIXLetoThe2nd: but thanks for the insight. I'll rethink the current structure :)12:32
LetoThe2ndsysdef: and for the reason what that did not bite you in the initramfs version: it cleans out IMAGE_INSTALL and probably did actually not include some stuff you thought it has.12:32
LetoThe2ndT_UNIX: i'm not saying that our findings apply everywhere, just sharing what we ran into. good luck.12:32
sysdefLetoThe2nd: i disabled everything and it's 11MB now. how do i install packages? that runs in an error: PACKAGE_INSTALL += " ntp"12:37
LetoThe2ndsysdef: for tinkering, do CORE_IMAGE_EXTRA_INSTALL += " ... " in local.conf12:38
LetoThe2ndsysdef: and as fast as possible, pour that into your own image.12:38
sysdefi do my config in ~/poky/meta/recipes-core/images/mb-v2-qemu.bb now. maybe i should search for a setup-howto ...12:40
yoctiNew news from stackoverflow: External xilinx PCie driver with Yocto <https://stackoverflow.com/questions/49384433/external-xilinx-pcie-driver-with-yocto>12:40
LetoThe2ndsysdef: ok, thats not too bad already. move it into your own layer and you're all set. :)12:40
T_UNIXLetoThe2nd: well, since there's apparently no way to inherit (including `.bbappend`) the direction would be a dead end anyway.12:41
LetoThe2ndi think the yocto-layer script is still included, if not, then look at devtool. we've had some churn there.12:41
sysdefi have no idea what a layer is ... *shrug*12:41
LetoThe2ndsysdef: and in your image, it is IMAGE_INSTALL += " ... "12:41
LetoThe2ndsysdef: in short: RTFM :-P in long: a layer is a collection of recipes, that can be mixed-and-matched. you usually create a layer of your own that holds all your recipes, so you do not have to pollute the poky tree you cloned, and therefore can move back and forth.12:43
LetoThe2ndplay around with http://layers.openembedded.org/layerindex/branch/master/layers/ a bit to get the feeling.12:43
LetoThe2ndalso see https://wiki.yoctoproject.org/wiki/images/1/1d/Ypdd-2017.02-ELC-Portland.pdf12:45
LetoThe2ndand if all else fails: https://www.buildingiot.de/veranstaltung-6616-erste-schritte-mit-dem-yocto-project.html?id=661612:46
LetoThe2ndoh, and a new one: https://www.yoctoproject.org/docs/what-i-wish-id-known/12:46
sysdefERROR: Nothing RPROVIDES 'ntp' (but /home/admin/poky/meta/recipes-core/images/mb-v2-qemu.bb RDEPENDS on or otherwise requires it)12:49
sysdefthat's what i get when i use IMAGE_INSTALL += " ... "12:50
LetoThe2ndsysdef: http://layers.openembedded.org/layerindex/recipe/2299/12:51
LetoThe2ndsysdef: so, clone http://git.openembedded.org/meta-openembedded next to poky, and add meta-openembedded/meta-networking to your conf/bblayers.conf12:52
sveinseI tried using devtool modify core-image-minimal to get my own working copy of it, but unfortunately that doesn't work. "The core-image-minimal recipe is an image, and therefore is not supported by this tool." :(12:52
*** kaspter <kaspter!~Instantbi@> has quit IRC12:52
*** kaspter <kaspter!~Instantbi@> has joined #yocto12:52
LetoThe2ndsysdef: and make sure the branches of poky and meta-openembedded match :)12:54
sysdefyocto is something like a framework for openembedded?12:57
LetoThe2ndsysdef: btw: you get that when using IMAGE_INSTALL, because IMAGE_INSTALL has a meaning. PACKAGE_INSTALL just has no meaning, hence it has no effect (and no errors)12:57
LetoThe2ndsysdef: the yocto project is actually just an umbrella term for a couple of things. many people use it synonymously for "that openembedded thing"12:58
LetoThe2ndsysdef: technically, poky is a "reference distribution" built on openembedded technology.12:58
sysdefwhat i was searching for was something like an easy 'qemu_build_image -arch i386 -packages "openvpn,openssl,module-tun"'12:59
LetoThe2ndsysdef: openembedded is a lot of things, but most people do not associate "easy" with it. for a reason, actually. it brings both power and complexity.13:00
sysdefnow it's getting more and more complex and i'm not an embedded developer at all. i can try to get my software to run on that 3y/o tinycorelinux image but that doesn't fit any security claim13:04
*** cratliff <cratliff!~cratliff@23-31-250-83-static.hfc.comcastbusiness.net> has joined #yocto13:06
sveinseYeah, I can support that. We have a arm-based product and migrated from Ubuntu to yocto 3 years ago. Now, yocto is excellent at making an image which fits the needs exactly, so it's as lean as you want it. But is /is/ complex to maintain.13:07
*** guenni_90 <guenni_90!d95b4710@gateway/web/freenode/ip.> has joined #yocto13:08
sveinseLike now, I'm trying to embed a npm-based app of our own, and I expect to use the rest of the week to get it in. Yocto and npm are very different beasts and their ways of handling SW control is very different, so progress is slow13:08
sveinseThat said, for embedded use, I'm not sure there is anything better. It gives you tremendous control, but with control comes complexity13:09
*** tasslehoff <tasslehoff!~Tasslehof@> has quit IRC13:14
*** eduardas_m <eduardas_m!~eduardas@> has joined #yocto13:32
*** wooosaiiii <wooosaiiii!~woo@cpe-90-157-180-95.static.amis.net> has quit IRC13:35
*** nighty- <nighty-!~nighty@s229123.ppp.asahi-net.or.jp> has joined #yocto13:36
*** wooosaiiii <wooosaiiii!~woo@cpe-90-157-180-95.static.amis.net> has joined #yocto13:39
*** neverpanic <neverpanic!~clemens@towel.neverpanic.de> has quit IRC13:45
*** neverpanic <neverpanic!~clemens@towel.neverpanic.de> has joined #yocto13:53
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC13:54
*** rcw <rcw!~rwoolley@> has joined #yocto13:55
*** gtristan <gtristan!~tristanva@> has quit IRC14:00
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC14:00
*** justanotherboy <justanotherboy!040f0002@gateway/web/freenode/ip.> has joined #yocto14:01
*** alinucs <alinucs!~abo@bgn92-6-88-179-202-174.fbx.proxad.net> has quit IRC14:01
*** gtristan <gtristan!~tristanva@> has joined #yocto14:04
*** vdehors <vdehors!~vdehors@91-162-62-2.subs.proxad.net> has quit IRC14:05
*** vdehors <vdehors!~vdehors@91-162-62-2.subs.proxad.net> has joined #yocto14:06
*** tlwoerner <tlwoerner!~Trevor@unaffiliated/tlwoerner> has joined #yocto14:07
*** ntl <ntl!~nathanl@65-36-80-8.dyn.grandenetworks.net> has joined #yocto14:07
*** vdehors <vdehors!~vdehors@91-162-62-2.subs.proxad.net> has quit IRC14:08
*** paulg <paulg!~paulg@198-84-204-211.cpe.teksavvy.com> has quit IRC14:11
seppe_Hey, does anyone have a good method for calculating the minimal size for a block device partition so it can fit the kernel + rootfs generated by Yocto?14:11
rburtonadd the sizes together?14:12
*** seppe_ <seppe_!~seppe@sep.pe> has quit IRC14:13
sveinseI'm trying to build npm-based package, and using the description in https://wiki.yoctoproject.org/wiki/TipsAndTricks/NPM, I run devtool add "npm://registry.npmjs.org;name=cute-files;version=1.0.2". When I try to build the recipe, it fails with https://bpaste.net/show/18abd8b08c79 . This is with vanilla rocko poky, qemu86-6414:18
sveinseWhat can I do?14:20
*** seppe <seppe!~seppe@sep.pe> has joined #yocto14:21
*** Crofton <Crofton!~Crofton@2601:284:8200:f356::c8ca> has joined #yocto14:21
sepperburton: adding what sizes together? To give a bit more context: I'm basing my work on the vendor provided yocto set-up (variscite-fslc) to generate a double rootfs+kernel layout.14:24
seppeSadly the vendor requires me to provide the wanted space for my data partition iof making the rootfs partition as small as possible and the data partition as big as possible...14:25
sveinseIs npm.bbclass maintained?14:28
T_UNIXhow do i select one of the possbily multiple DTBs provided for an image?14:29
*** vdehors <vdehors!~vdehors@91-162-62-2.subs.proxad.net> has joined #yocto14:31
sveinseI'm wondering if the devtool and npm isn't properly synced. Fixing the above manually in npm.bbclass, it fails once more as the package build output contains a symlink to workspace/sources/cute-files which makes bitbake stop on symlink error14:34
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto14:42
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC14:43
LetoThe2ndsysdef: well, the point is that you are actually creating a whole distribution14:46
*** luneff <luneff!~yury@> has quit IRC14:46
LetoThe2ndsysdef: for a "i just want to"-usecase, it might be better to base off an existing distribution14:48
*** pinkSnake <pinkSnake!51ff1123@gateway/web/freenode/ip.> has joined #yocto14:49
*** cratliff <cratliff!~cratliff@23-31-250-83-static.hfc.comcastbusiness.net> has quit IRC14:53
*** dreyna <dreyna!~dreyna@unknown-6-30.windriver.com> has joined #yocto15:04
sveinseHow does the mechanism for externalsrc with devtool work? The appends/<recipe>.bbappend, because I suspect this is what's causing the packaging to fail15:09
rburtonseppe: image construction is typically based on making image big enough to hold what you want not the other way around, so this is some vendor crazy you need to work out yourself15:10
*** falk0n <falk0n!~falk0n@a109-51-188-2.cpe.netcabo.pt> has joined #yocto15:10
*** falk0n <falk0n!~falk0n@a109-49-51-30.cpe.netcabo.pt> has joined #yocto15:11
*** falk0n <falk0n!~falk0n@a109-49-51-30.cpe.netcabo.pt> has joined #yocto15:13
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto15:13
*** cratliff <cratliff!~cratliff@23-31-250-83-static.hfc.comcastbusiness.net> has joined #yocto15:14
sveinseWell, he's not alone with this thinking. It's a pretty ordinary setup for embedded. Say you want to create a system with a dual redundant rootfs, one for the main function and one for recovery. You then need to determine the fraction between the partitions at build-time, since these things normally can't or won't be repartioned in the field later.15:15
LetoThe2nds/build time/design time/15:17
*** open-nandra_ <open-nandra_!~marek@> has quit IRC15:20
kergothsveinse: externalsrc works with or without devtool, devtool just leverages it to point at an external source tree rather than the usual download/unpack/patch paradigm15:22
eduardas_mhello, I have trouble compiling the cpupower recipe for an i.MX6 SoM with Rocko for some reason: https://pastebin.com/jmARhWCj15:22
eduardas_mcan it be that this tool is not even appropriate for my platform?15:22
sveinsekergoth: yeah, but for some reason npm recipes are playing havok with me in devtools. I used devtool to create the recipe, and it builds (after modding npm.bbclass), but fails to install due to a symlink into workspace/sources/15:23
*** scottrif <scottrif!~scottrif@47-40-108-60.dhcp.knwc.wa.charter.com> has joined #yocto15:24
*** vmeson <vmeson!~rmacleod@192-0-133-4.cpe.teksavvy.com> has quit IRC15:24
sveinseremoving the devtools added .bbappend file which sets the external source, then my recipe wont fetch15:24
sveinseSo I'm preplexed how the npm system is intended to work15:25
*** Crofton <Crofton!~Crofton@2601:284:8200:f356::c8ca> has quit IRC15:26
sveinseAnd for the record, I'm following the https://wiki.yoctoproject.org/wiki/TipsAndTricks/NPM and is using vanilla Rocko + meta-openembbeded (for nodejs) against qemux86-6415:26
pinkSnake@eduardas_m msgfmt can be installed by running ./configure && make && make install in the gettext-tools directory under the gettext source root.15:28
*** dreyna_ <dreyna_!~dreyna@unknown-157-208.windriver.com> has joined #yocto15:30
kergothsveinse: have you checked the git history on the class and contacted the folks that created it? worst case that'd be a viable option, presumably they'd have the answers15:30
*** dreyna <dreyna!~dreyna@unknown-6-30.windriver.com> has quit IRC15:33
sveinsekergoth: yeah, I probably need to take it on the mailing lists. My main problem is that I don't know if it is true bugs in poky or if it is my usage...15:35
kergothyeah.. still worth asking about, though. it sounds like there may well be a bug relating to externalsrc+npm regardless, though, and even if it is in your usage, there's a good chance someone else has run into it too, so still worth discussing15:35
* kergoth shrugs15:36
sveinsein the devtool / workspace scheme of things, how is recipies moved into the main layers?15:37
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has joined #yocto15:37
sveinsebecause from what I understand, the recipes/ contains "normal" recipe code which can be copied anywhere, while the special workspace/externalsrc adoptions are made in appends/15:37
kergothdevtool has a finish command to push the changes to the layer the recipe lives in, but iirc it doesn't move a newly created recipe made with 'create' into its location in the layer for you15:38
sveinseSo in principle, removing the bbappends file in appends/ would make this recipe like any other recipe, right?15:38
kergothyep. devtool has a reset command to do that for you as well15:39
sveinsegood, thanks. Then I know that its the npm tools that is misbehaving and not my layer/recipe-handling15:39
sveinseoh, devtool reset removed the files :P15:41
sveinseCan I run devtool add and have it not setup externalsrc?15:44
kergothi'm not sure. i don't see that devtool would add any real value without externalsrc, other than create, which is mostly independent of the other functions15:46
sveinseThen I can make my own foobar meta-layer to have it edited there as one would in a production setup15:47
sveinseI just need somewhere "normal" to build the recipe, since devtool does magic things with externalsrc15:47
kergoththat's what i'd do, bitbake-layers to create a layer for it, devtool create to get the recipe, put it in the layer, and build as usual, and only devtool modify & the rest if you need to muck with the sources, generate patches, etc, or if you want to avoid the fetch/unpack/patch process15:48
* kergoth shrugs15:48
kergothadmittedly not a devtool expert, and don't know much about external sdk or the like15:48
T_UNIXdoes the order within `OVERRIDES` imply priorities? Is it also applied to `FILESPATH`?15:49
*** Crofton <Crofton!~Crofton@2601:284:8200:f356::c8ca> has joined #yocto15:49
kergothT_UNIX: yes, and yes (though technicalli t's FILESOVERRIDES that's used for the latter)15:50
kergothT_UNIX: the order is lowest priority to highest, later override former15:50
kergoththe intention is that more specific information always wins over less specific. machine beats arch, which beats no override, etc15:50
eduardas_mpinkSnake: I am using Ubuntu 16.04 and already have gettext installed... msgfmt is present on my development host15:51
T_UNIXkergoth: thanks :)15:51
T_UNIXdo I need to specifically alter `FILESOVERRIDES` or are changes to`OVERRIDES` sufficient?15:52
kergothi don't recall, check bitbake.conf, it's what defines them15:52
kergothbitbake.conf is also what includes machine .conf, distro .conf, local.conf, etc, and the order of those inclusions also mirrors the aforementioned priority, loosely.. unfortunately we have to parse local.conf before distro/machine since it's usually what defines them15:53
T_UNIXthanks for the insight :)15:54
T_UNIXfyi: it is not sufficient. one might use `DISTROOVERRIDES` to alter both though.15:57
sveinsekergoth: I was able to fetch and build the recipe outside devtool/workspace, and here I was able to build it proper. So this is truly a bug in npm.bbclass and not so much with externalsrc. npm is installing with symlinks which bitbake doesn't like of course. Thank you, this certainly got me longer along the path.15:59
*** varjag <varjag!~user@122.62-97-226.bkkb.no> has quit IRC15:59
*** zeddii <zeddii!~bruce@unknown-6-81.windriver.com> has joined #yocto16:00
*** kaspter <kaspter!~Instantbi@> has quit IRC16:02
*** kaspter <kaspter!~Instantbi@> has joined #yocto16:02
kergothah, that's very good information. no problem16:02
*** Jefro <Jefro!~josiermi@> has joined #yocto16:03
*** frieder <frieder!~frieder@2003:a:e7a:6200:246c:2a8b:f45a:a33d> has quit IRC16:03
T_UNIXkergoth: so if I somehow modify `FILESOVERRIDES` will it affect the `FILESPATH`s searched or just allow for `FILES_myfoo = ...` wihtin recipes?16:03
*** Son_Goku <Son_Goku!~King_InuY@fedora/ngompa> has quit IRC16:05
kergothyes, FILESPATH is constructed based on an explicit base list of paths + filesextrapaths, then we check each path with the filesoverride appended, obeying priorities as you'd expect for an OVERRIDES variable16:05
kergothsee base.bbclass (FILESPATH =) and utils.bbclass (base_set_filespath function)16:05
tlwoernersveinse: i just tried 'devtool add "npm://registry.npmjs.org;name=cute-files;version=1.0.2"' with qemux86-64 on master and it seems to complete successfully https://bpaste.net/show/33199e6d937916:10
sveinsetlwoerner: can you try it on rocko?16:10
*** stephano <stephano!stephano@nat/intel/x-sssrwrfonrsaexus> has joined #yocto16:11
tlwoernersveinse: ok16:11
sveinsewhat version of node and npm do you have?16:11
sveinseand can you try to build the recipe?16:11
*** armpit <armpit!~armpit@2601:202:4000:1184:4088:e426:a566:fc98> has quit IRC16:11
*** martinkelly <martinkelly!~martin@71-212-16-149.tukw.qwest.net> has joined #yocto16:12
sveinseYeah, I have 8.4.0-r016:14
*** Jefro <Jefro!~josiermi@> has quit IRC16:15
*** cratliff <cratliff!~cratliff@23-31-250-83-static.hfc.comcastbusiness.net> has quit IRC16:16
sveinseI have to run rocko, and 8.4.0 is the version which is bundled (and tested?) with rocko16:17
*** hanthings <hanthings!~nandor@> has quit IRC16:17
T_UNIXkergoth: I donot quite get the variable expansion here (http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/classes/utils.bbclass#n303). Does `getVar` return the values as provided by a overriden variable or just what's defined e.g. by `bitbake.conf`?16:22
kergothgetVar returns variables in expanded form, which includes resolving variable references (${}), running inline python (${@}), applying OVERRIDES, and applying _append/_remove operations16:23
kergothunless you pass False or expand=False as the second argument16:23
kergothin older releases, the default was unexpanded unless you passed True, though16:24
T_UNIXI.e. if I have `FILES_myoverride = 'foo'` and `FILESOVERRIDE = 'os:machine:myoverride'` does the `getVar` stmt return `foo` or `os...`?16:24
kergothFILESOVERRIDES is only used to check paths on *disk*16:25
kergothi.e. /path/to/the/recipe/recipename/arm instead of /path/to/the/recipe/recipename16:25
kergothwhich is what FILESPATH is for16:25
kergothonly OVERRIDES apply to getVar16:25
T_UNIXin my example it would check `recipename/myoverride/` instead of `recipename/foo/`, right?16:27
kergothyes. that FILES_myoverride doesn't make any sense, though, since FILESOVERRIDES doesn't apply to variable expansion, and FILES variables are per-package16:28
*** pinkSnake <pinkSnake!51ff1123@gateway/web/freenode/ip.> has quit IRC16:28
*** Crofton <Crofton!~Crofton@2601:284:8200:f356::c8ca> has quit IRC16:30
*** zeddii <zeddii!~bruce@unknown-6-81.windriver.com> has quit IRC16:31
T_UNIXkergoth: right. I need some of that 'Feierabend' ;-P16:34
vladzouthHi, i use fsl yocto project given by KARO(https://www.karo-electronics.com/1646.html?&L=1) to build an embedded linux system for the KARO TX6S-8035 target. The build work fine. I use the freescale mfgtool to download images into the board. when the kernel start, i have the following error message: "Kernel panic - not syncing: Requested init /linuxrc failed (error -2)" . I use the default init system of yocto "systemVinit.16:37
vladzouthIs there something in yocto to add in order to have "linuxrc" in the rootfs?16:38
*** hamis <hamis!~irfan@host-58-net-96-160-119.mobilinkinfinity.net.pk> has quit IRC16:47
-YoctoAutoBuilder- build #963 of nightly is complete: Failure [failed] Build details are at https://autobuilder.yocto.io/builders/nightly/builds/96316:48
*** Anticom <Anticom!~anticom@> has quit IRC16:50
*** Bunio_FH <Bunio_FH!~bunio@81-18-201-214.static.chello.pl> has quit IRC16:50
fancerkergoth: just tried your changes. For some reason my system can't find cross-sdk strip binutil when installing binutils-cross-canadian.16:52
fancerI get error like: No such file or directory: 'x86_64-tpsdk-linux-strip'16:52
fancer* my target - mipsel, host - x86_64, sdk-host - x86_6416:53
fancerHow come you were able to build it successfully?16:53
fancerIf I inhibt strip process, of course binutils-cross-canadian-mipsel gets installed. I try to create the package directly by bitbake binutils-cross-canadian-mipsel.16:57
fancerDo you do the same?16:57
fancerEither the package must depend on the nativesdk versions of binutils, or it must get installed by default somehow...16:59
sveinseHow do I proceed to request backporting a patch from master to the rocko branch? Because rocko is being fix and updated on, right?17:00
sveinseI found the master branch alreay contains a fix for the issues I'm having. This is why it is working for you tlwoerner. When I applied the patch to rocko, then everything resolves correctly.17:01
tlwoernersveinse: okay, i was just getting around to the actual test17:02
tlwoernerwhich patch?17:02
sveinsetlwoerner: https://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/meta/classes/npm.bbclass?id=d38e1e2c2ea4646b34ea6282d3d7620df5b0374b17:03
*** stephano <stephano!stephano@nat/intel/x-sssrwrfonrsaexus> has quit IRC17:03
sveinseI noticed something else: If I run -c cleanall on a npm recipe, it fails with checksum error on the npm sub modules. I have to use "devtool add npm://" to update the download cache. Then I can delete it with devtool reset and use it as a normal recipe17:06
*** stephano <stephano!stephano@nat/intel/x-wtoegbngciararza> has joined #yocto17:06
fancerkergoth: yeah, I guess I need to build nativesdk-packagegroup-sdk-host first, then try to build the cross-canadian packages. Although I am still surprised it doesn't determine the crosssdk tools dependency by default.(17:07
sveinse...if I run -c cleanall on a npm recipe, it fails the next time I try to built it with checksum error...17:07
kergothfancer: I'm working on a fix for that now17:07
fancerEmm, you think it's our bug?17:08
sveinsethis is the failure: https://bpaste.net/show/2c467044c98b17:08
*** dreyna <dreyna!~dreyna@unknown-6-30.windriver.com> has joined #yocto17:08
*** zeddii <zeddii!~bruce@unknown-6-81.windriver.com> has joined #yocto17:08
*** dreyna_ <dreyna_!~dreyna@unknown-157-208.windriver.com> has quit IRC17:09
*** fl0v0 <fl0v0!~fvo@i3ED6F34A.versanet.de> has quit IRC17:11
kergothfancer: just need to have binutils-external-cross in DEPENDS for everything, so strip is available in the recipe specific sysroot to be run by do_package. just have to make sure that dep isn't added for binutils-external-cross itself, to avoid recursion. i'll push a couple commits in a few17:11
kergothiirc i was hitting an unrelated failure after fixing that, though, i need to check the status17:11
tlwoernersveinse: hmm... i just tried with rocko and don't see an error https://bpaste.net/show/236a3f737fe917:11
kergoththe intent is this support should be functional and stable in meta-external-toolchain master for anyone to use regardless of toolchain17:11
fancerEmm, I think we are talking about different things.17:12
sveinsetlwoerner: how can that be?17:12
tlwoerneri don't know :-S maybe check the git commits?17:13
*** eduardas_m <eduardas_m!~eduardas@> has quit IRC17:13
kergothcertainly possible, yes. in exactly what context are you seeing the strip error?17:13
sveinsetlwoerner: with node 8.4.0-r0?17:13
kergothi was seeing it in do_package for libgcc-external, as strip is required to be able to package17:13
fancerkergoth: I see the strip error, when I try to do: bitbake binutils-cross-canadian-mipsel.17:14
kergothbut what task errored out?17:14
tlwoerneryes: tmp-glibc/work/x86_64-linux/nodejs-native/8.4.0-r017:14
fancerERROR: binutils-external-cross-canadian-mipsel-2.25.1-r0 do_package: Error executing a python function in exec_python_func() autogenerated:17:14
sveinsetlwoerner: what is the git hash for the poky repo?17:14
tlwoernersveinse: oh... i'm not using poky, i use openembedded-core, bitbake, and meta-openembedded directly17:14
tlwoernersveinse: check the build configuration in the paste17:15
fancerkergoth: I suppose, it just can't find find the crosssdk version of binutils for stripping.17:15
kergothyeah, exactly. we didn't build a crosssdk toolchain, we run the external tools, so instead we should be able to depend on the cross version17:16
kergothaka binutils-external-cross, which is what i was just referring to17:16
sveinsetlwoerner: what is the url to the git repo I need to check out to get your "meta" repo?17:16
fancerEmm, binutils-external-cross isn't crosssdk toolchain.17:17
kergothdoesn't need to be, it can still run it17:17
kergothwe're not building cross-canadian from source, so we don't need a crosssdk toolchain17:17
kergothand cross recipes are installed in the native sysroot, which is in the PATH for every recipe17:17
*** ladidadida <ladidadida!~ladidadid@ipbcc2211a.dynamic.kabel-deutschland.de> has joined #yocto17:17
tlwoernersveinse: that is openembedded-core: git://git.openembedded.org/openembedded-core17:17
fancerkergoth: No-no, we can't even use the binutils-cross to strip binutils itself. We need to use crosssdk toolchain for it, that's why bitbake failed to find x86_64-tpsdk-linux-strip.17:18
kergothit runs it fine, i already fixed it locally17:19
kergothas i said already17:19
kergoththe issue is external-toolchain.bbclass depends on it using do_package[depends], which doesn't add it to the recipe-specific-sysroot. adding it to DEPENDS instead fixes it17:19
sveinsetlwoerner: this is weird... npm.bbclass is identical. To the one in rocko which clearly does not work for me. And the patch in master could suggest that I'm not the only one17:21
*** kmorrow <kmorrow!81c4e2aa@gateway/web/freenode/ip.> has joined #yocto17:22
tlwoernersveinse: when our node person updates the app, i use a special "devel" image, scp the code to the running target platform, then run "npm install" there. i then collect up the stuff in ~/.npm and ~/ourapp and package it as a binary17:23
tlwoernersveinse: iow, i haven't had much luck getting node stuff to work fully from the development host, only on the target17:23
sveinsetlwoerner: yeah, we have discussed the same. I'm not free to spend many days getting npm up and running17:24
sveinsePity tough, because it won't take yocto any further in fixing the support for it17:25
*** stephano <stephano!stephano@nat/intel/x-wtoegbngciararza> has quit IRC17:26
fancerkergoth: Did you fix the error I stated? do_package tries to package our cross-tools, which are going to run on SDK machine to produce binaries for target. It means do_package either need the crosssdk tool to strip our packaging binaries or we need to prevent it from stripping, right?17:27
fancerDid you prevent it from stripping in your local tree?17:27
*** yann <yann!~yann@> has quit IRC17:28
*** vdehors <vdehors!~vdehors@91-162-62-2.subs.proxad.net> has quit IRC17:28
sveinseIt also seems npm is dependent on devtool to download the modules to the download cache. If I wipe it with -c cleanall, then bitbake seems to be unable to fetch the modules without failing17:28
sveinseok, I need to drop the yocto mailinglist a email about this17:29
*** stephano <stephano!stephano@nat/intel/x-xaylxpehccmufdcd> has joined #yocto17:29
fancerkergoth: My thought was, that even though we don't really need the stripping, how come the bitbake system didn't determine, that our package is cross-canadian and it needs binutils-crosssdk for it. We inherited cross-canadian class, it should have declare such dependencies.17:30
tlwoernersveinse: ok, hopefully someone has made more progress on it. there used to be meta-nodejs, but it appears to have been abandoned17:30
sveinsetlwoerner: I was told meta-nodejs was obsolete now that it has been included into the official repos17:34
sveinsehere yesterday17:34
tlwoernersveinse: ah, thanks for the info17:34
sveinsetlwoerner: But I don't know, I'm just the messenger17:34
sveinsetlwoerner: How has npm not been working for your project? I mean, since builds seems to be fine in your end17:38
*** rdanter <rdanter!~rad@cpc76236-cosh15-2-0-cust704.6-1.cable.virginm.net> has quit IRC17:40
tlwoernersveinse: it's been about a month since i last tried it on the development host machine, our app has dozens (hundreds?) of node packages, some work, some fail. overall it's just easier to do it on the target17:40
tlwoernerin this case we're just doing one package, and this one happens to work17:40
sveinsetlwoerner: one package with dependencies, right? So the difference would only be which packages or the sheer number of them perhaps?17:41
tlwoernerlots of packages, with lots of dependencies... it's turtles all the way down!17:42
sveinsetlwoerner: yeah, my js guy has already frowned upon the lockdown and npm-shrinkwrap thing. He thinks this is far too detailed and specific, borderline paranoid. So the difference in thinking between npm and oe is apparent :D17:44
rburtonsveinse: because nothing ever went wrong with npm randomly installing versions from the internet17:46
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has joined #yocto17:47
sveinserburton: no, never! But getting those devs to be aware of that is harder than I expected...17:47
sveinseThe approach outlined above is very common thou: Run npm install on a (dev) system and snapshot the whole thing. Run tests and QA on that and binary distribute the whole thing. If internet breaks a package, then it's a dev problem, not a build problem.17:52
*** cratliff <cratliff!~cratliff@> has joined #yocto17:53
*** dreyna_ <dreyna_!~dreyna@unknown-6-30.windriver.com> has joined #yocto17:56
*** vmeson <vmeson!~rmacleod@> has joined #yocto18:02
JPEWI think I'm misunderstanding how bitbake --runall works: I would have thought 'bitbake --runall package_qa core-image-minimal' would run do_package_qa on all recipes that are part of the image, but it doesn't18:02
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC18:07
kergothfancer: it's a good question, it seems currently every cross-canadian recipe explicitly sets those DEPENDS itself, and cross-canadian does an INHIBIT_DEFAULT_DEPS18:10
kergothfancer: potential area for improvement of the class18:10
kergothfancer: if you're using my meta-external-toolchain branch, go ahead and update it. it builds now. i built an sdk for core-image-minimal, installed it, sourced environment-setup, ran eval $CC $CFLAGS $LDFLAGS hello.c -o hello and ran hello18:10
fancerkergoth: Thanks man. I'll merge it with my changes right now. What type of SDK did you try?18:13
*** JPEW is now known as JPEWhacker18:13
kergothbitbake -c populate_sdk core-image-minimal, using the default TOOLCHAIN_HOST_TASK/TOOLCHAIN_TARGET_TASK for populate_sdk18:13
*** JPEWhacker is now known as JPEW18:16
kergothended up creating symlinks to align EXTERNAL_TARGET_SYS- with TARGET_PREFIX, since the binary names metaa-environment expects differ from what's in the external toolchain. easier to do that than muck with adjusting environment-setup only for the binaries which come from external18:17
*** paulg <paulg!~paulg@198-84-204-211.cpe.teksavvy.com> has joined #yocto18:23
kergothfancer: did find an unrelated bug, nativesdk-qemu was failing to build for me, something about python2. could be related to my host, though. if you hit it, i have a workaround handy18:27
kergothjust as an fyi18:27
fancerkergoth: thanks. I haven't for now.18:27
fancerThis weird:18:31
fancerERROR: Error for /media/windows/WORKSPACE/IT/T-platforms/SDK/src/yocto/meta-external-toolchain/recipes-external/binutils/binutils-external-cross-canadian.bb:do_package[depends], dependency virtual/mipsel-baikal-linux-binutils:do_populate_sysroot:do_populate_sysroot in ' virtual/fakeroot-native:do_populate_sysroot rpm-native:do_populate_sysroot file-native:do_populate_sysroot18:31
fancervirtual/mipsel-baikal-linux-binutils:do_populate_sysroot:do_populate_sysroot' does not contain exactly one ':' character.18:31
kergothfancer: my mistake, hold18:31
kergothweird that it didn't fail here18:32
fancerI could find where we got the second do_populate_sysroot...=)18:32
kergothfixed, go ahead and update18:32
kergothPACKAGE_DEPENDS is a list of recipes, but i left the :do_populate_sysroot there from when i was using do_package[depends]18:32
fancerAhh, It does so automatically18:32
* kergoth wipes his build and rebuilds from scratch without sstate, to make sure nothing is cached18:33
*** armpit <armpit!~armpit@50-233-148-156-static.hfc.comcastbusiness.net> has joined #yocto18:38
yoctiNew news from stackoverflow: Could not inherit file classes/pypi.bbclass with meta-raspberrypi Yocto Bitbake <https://stackoverflow.com/questions/49391785/could-not-inherit-file-classes-pypi-bbclass-with-meta-raspberrypi-yocto-bitbake>18:41
fancerkergoth: ln: failed to create symbolic link ‘<nip>/mipsel-baikal-linux-ld.bfd’: File exists18:48
fancerYou shouldn't have discarded that check.)18:48
*** yann <yann!~yann@LFbn-1-527-224.w86-245.abo.wanadoo.fr> has joined #yocto18:48
fancerSince we  got ld.bfd listed in binutils_binaries18:50
kergothah, that was unintentional18:50
kergothnot my day today18:50
fancerno worries.18:50
lukmaIs there any problem with devtool add + ssh with some keys ?18:51
*** kpo_ <kpo_!~bob@user-94-254-250-40.play-internet.pl> has joined #yocto18:51
lukmaThe simple ssh clone is working, but when I try to fetch the repo with devtool add it breaks18:51
lukma(I mean ssh: connect to host  port 22: Connection timed out)18:51
kergothpushed the fix. i'll rebase and clean up the branch after we're done mucking with it and know it works, getting a bit cluttered18:52
fancerYep, if everything works for me, I'll push mu changes to public repo, so you could fetch them from there.18:52
fancerkergoth: If you discard this line "INHIBIT_PACKAGE_STRIP = "1"" from mets-external-toolchain/classes/external-toolchain.bbclass, you'll end up with error I was talking about.) I suppose the cross-canadian tools should also have have the direct dependency from "virtual/${SDK_PREFIX}binutils-crosssdk", like you did for  all external toolchains and "virtual/${SDK_PREFIX}binutils".18:53
lukmaexport SSH_AGENT_PID= seems to be correct18:53
fancerThing is, I need the standard libraries being stripped, since my sysroot should be as small as possible. My target for just 16MB for U-boot, Kernel, rootfs compressed images.18:55
*** rob_w <rob_w!~rob@unaffiliated/rob-w/x-1112029> has quit IRC18:55
kergothyeah, iirc it's assuming that it's already stripped and/or has debug files split out already, but that's not necessarily the case for all toolchains18:58
kergothtesting now18:58
fancerDumn it binutils-crosssdk-* is so heavy...19:04
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:04
kergothas we're packaging binaries we already know run on both this host and the host we're installing the sdk on, we should actually be able to use host tools rather than crosssdk tools19:07
lukmaAny hints on how to debug devtool ssh connections ?19:07
kergothwhich means we can just run 'strip' and 'objcopy' from the build machine19:07
kergothtesting it now19:07
*** AndersD <AndersD!~anders@h83-209-191-235.cust.se.alltele.net> has joined #yocto19:08
kergothfancer: pushed that change, if you want to test it19:08
kergothi have a new populate_sdk going, but it'll take a while19:08
*** t0mmy <t0mmy!~tprrt@> has quit IRC19:08
yoctiNew news from stackoverflow: Install SciPy issue under Yocto <https://stackoverflow.com/questions/49392254/install-scipy-issue-under-yocto>19:11
fancerkergoth: Ok, just merged and started my build19:11
*** JaMa <JaMa!~martin@> has quit IRC19:12
*** stephano <stephano!stephano@nat/intel/x-xaylxpehccmufdcd> has quit IRC19:13
*** stephano <stephano!stephano@nat/intel/x-jgisjhzgvgkvjrfp> has joined #yocto19:14
fanceryep, it worked.) Although it started fetching binutils-crosssdk-* anyway when I had ran the populate_sdk task.)19:19
kergothyeah.. depends on what you're including in the sdk. crosssdk still needs buliding to build the nativesdk stuff being included in the sdk. we could dep on it, but it's a bit unnecessary in this case, no point pulling in deps we don't need19:20
* kergoth shrugs19:20
*** AndersD <AndersD!~anders@h83-209-191-235.cust.se.alltele.net> has quit IRC19:21
kergothPresumably since we know the build machine and sdk install machine are one and the same, we could hack nativesdk to use host tools as well and just exclude crosssdk entirely19:22
kergothwould have to be an opt-in behavior, of course, due to that assumption19:22
kergothwill give that some thought19:22
*** AndersD <AndersD!~anders@h83-209-191-235.cust.se.alltele.net> has joined #yocto19:22
kergoths/one and the same/compatible/19:23
kergoththat said, the toolchain was probably built in such a way that its more binary compatible across linux hosts than anything oe builds itself19:23
kergothso maybe best to keep the current behavior and only bypass it for external bits19:23
kergothiirc sourcery toolchains are built on ancient linux hosts to avoid glibc versioning issues re: binary portability19:24
*** AndersD <AndersD!~anders@h83-209-191-235.cust.se.alltele.net> has quit IRC19:25
*** AndersD <AndersD!~anders@h83-209-191-235.cust.se.alltele.net> has joined #yocto19:25
fanceryeah, right. It must be optional somewhere. I would think fo to have something like meta/conf/sdk.conf and put there all the SDK-related variable default together with one you said, which prevents nativesdk being built.19:25
*** maw <maw!~martinaw@pdpc/supporter/student/maw> has joined #yocto19:26
*** AndersD <AndersD!~anders@h83-209-191-235.cust.se.alltele.net> has quit IRC19:27
kergothwould basically need to 1) remove the deps on the crosssdk bits, and 2) ensure that it runs the binaries with the correct prefixes, i.e. compare native vs nativesdk so the latter runs the same tools as the former19:27
kergothso it runs 'gcc', not x86_64-oesdk-linux-gcc or whatever19:28
kergothnot a priority in my mind at hte moment, more an optimization to reduce build time19:28
kergothi won't be able to put too much more time into this, mentor doesn't really need this feature much, but i think it's a good one to have in the layer to support the community, this isn't the first time someone has mentioned it. still, have to switch back to my other priority tasks soon. let me know how your builds go19:29
fancerI see. I won't have time for this either.  Need to get back to kernel/u-boot dev.19:32
fancerOk, I will19:32
*** jcreekmo_ <jcreekmo_!~jcreekmor@c-68-42-37-11.hsd1.al.comcast.net> has joined #yocto19:32
fancerIt will take some time. I am doing the build on my laptop, which is old 'a bit'.)19:35
*** kmorrow <kmorrow!81c4e2aa@gateway/web/freenode/ip.> has quit IRC19:42
*** marka <marka!~masselst@> has quit IRC19:47
*** falk0n <falk0n!~falk0n@a109-49-51-30.cpe.netcabo.pt> has quit IRC19:50
*** kpo_ <kpo_!~bob@user-94-254-250-40.play-internet.pl> has quit IRC19:54
*** kpo_ <kpo_!~bob@user-94-254-250-40.play-internet.pl> has joined #yocto19:57
*** zeddii <zeddii!~bruce@unknown-6-81.windriver.com> has quit IRC19:58
*** zeddii <zeddii!~bruce@unknown-6-81.windriver.com> has joined #yocto19:59
*** dreyna__ <dreyna__!~dreyna@unknown-157-208.windriver.com> has joined #yocto19:59
*** dreyna <dreyna!~dreyna@unknown-6-30.windriver.com> has quit IRC20:03
*** dreyna_ <dreyna_!~dreyna@unknown-6-30.windriver.com> has quit IRC20:03
*** dreyna <dreyna!~dreyna@unknown-157-208.windriver.com> has joined #yocto20:03
armpitdoes anyone recall if there is a fix for qemu image in for "INIT: Id "hvc0" respawning too fast: disabled for 5 minutes" ?20:04
*** Jefro <Jefro!josiermi@nat/intel/x-dpiquvmkrpxnbxbv> has joined #yocto20:05
*** martinkelly <martinkelly!~martin@71-212-16-149.tukw.qwest.net> has quit IRC20:07
*** vmeson <vmeson!~rmacleod@> has quit IRC20:19
*** sgw <sgw!swold@nat/intel/x-ggjowetuckdkyjdj> has quit IRC20:27
aehs29Does anyone knows jussi's handle here?20:29
*** Jefro1 <Jefro1!josiermi@nat/intel/x-kbzwtsiiuglptaij> has joined #yocto20:30
*** Jefro1 <Jefro1!josiermi@nat/intel/x-kbzwtsiiuglptaij> has quit IRC20:32
*** Jefro <Jefro!josiermi@nat/intel/x-dpiquvmkrpxnbxbv> has quit IRC20:33
*** Jefro <Jefro!josiermi@nat/intel/x-opuoiiiplnlapgbu> has joined #yocto20:33
*** dev1990 <dev1990!~dev@> has quit IRC20:41
*** dev1990 <dev1990!~dev@> has joined #yocto20:41
*** kmorrow <kmorrow!81c4e2e3@gateway/web/freenode/ip.> has joined #yocto20:45
*** armpit <armpit!~armpit@50-233-148-156-static.hfc.comcastbusiness.net> has quit IRC20:47
-YoctoAutoBuilder- build #929 of nightly-oe-selftest is complete: Success [build successful] Build details are at https://autobuilder.yocto.io/builders/nightly-oe-selftest/builds/92920:48
*** jcreekmo_ <jcreekmo_!~jcreekmor@c-68-42-37-11.hsd1.al.comcast.net> has quit IRC20:50
*** sgw <sgw!~swold@c-71-238-116-168.hsd1.or.comcast.net> has joined #yocto20:50
*** sgw <sgw!~swold@c-71-238-116-168.hsd1.or.comcast.net> has quit IRC20:56
*** sgw <sgw!~swold@> has joined #yocto20:56
*** Jefro <Jefro!josiermi@nat/intel/x-opuoiiiplnlapgbu> has quit IRC20:59
*** stephano <stephano!stephano@nat/intel/x-jgisjhzgvgkvjrfp> has quit IRC20:59
*** stephano <stephano!~stephano@> has joined #yocto21:00
*** Crofton <Crofton!~Crofton@2601:284:8200:f356::c8ca> has joined #yocto21:03
*** SuicidalLabRat <SuicidalLabRat!d826965a@gateway/web/freenode/ip.> has joined #yocto21:05
*** Jefro <Jefro!~josiermi@> has joined #yocto21:05
SuicidalLabRatWhere is the most appropriate place to disable creation of the /etc/hostname file?21:07
*** kmorrow <kmorrow!81c4e2e3@gateway/web/freenode/ip.> has quit IRC21:08
*** rburton <rburton!~textual@> has quit IRC21:10
*** rcw <rcw!~rwoolley@> has quit IRC21:16
*** georgem_home <georgem_home!uid210681@gateway/web/irccloud.com/x-newhbyosddihjpsy> has joined #yocto21:19
*** bluelightning_ <bluelightning_!~paul@> has joined #yocto21:23
*** bluelightning_ <bluelightning_!~paul@> has quit IRC21:23
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto21:23
*** rburton <rburton!~textual@> has joined #yocto21:23
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC21:23
*** WillMiles <WillMiles!~Will@static-209-87-231-80.storm.ca> has quit IRC21:31
*** Jefro <Jefro!~josiermi@> has quit IRC21:32
*** King_InuYasha <King_InuYasha!~kvirc@fedora/ngompa> has quit IRC21:33
*** pohly <pohly!~pohly@p548497B7.dip0.t-ipconnect.de> has quit IRC21:35
*** morphis <morphis!~morphis@pD9ED7F7C.dip0.t-ipconnect.de> has quit IRC21:37
*** dreyna <dreyna!~dreyna@unknown-157-208.windriver.com> has quit IRC21:43
*** sgw <sgw!~swold@> has quit IRC21:50
*** Crofton <Crofton!~Crofton@2601:284:8200:f356::c8ca> has quit IRC21:57
*** gtristan <gtristan!~tristanva@> has quit IRC22:02
*** justanotherboy <justanotherboy!040f0002@gateway/web/freenode/ip.> has quit IRC22:05
*** cratliff <cratliff!~cratliff@> has quit IRC22:05
*** Jefro <Jefro!~josiermi@> has joined #yocto22:08
*** sgw <sgw!~swold@c-71-238-116-168.hsd1.or.comcast.net> has joined #yocto22:11
*** sgw1 <sgw1!~swold@> has joined #yocto22:15
*** sgw <sgw!~swold@c-71-238-116-168.hsd1.or.comcast.net> has quit IRC22:18
*** Jefro <Jefro!~josiermi@> has quit IRC22:30
*** SuicidalLabRat <SuicidalLabRat!d826965a@gateway/web/freenode/ip.> has quit IRC22:38
*** armpit <armpit!~armpit@2601:202:4000:1184:a1c1:eb3f:f249:aed1> has joined #yocto22:45
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has joined #yocto22:58
*** agust <agust!~agust@> has quit IRC23:00
*** Jefro <Jefro!~josiermi@> has joined #yocto23:00
*** stephano <stephano!~stephano@> has quit IRC23:05
*** nathani__ <nathani__!~nathani@mail.validmanufacturing.com> has quit IRC23:09
*** martinkelly <martinkelly!~martin@> has joined #yocto23:12
*** Bunio_FH <Bunio_FH!~bunio@clj-165.netdrive.pl> has quit IRC23:16
RPaehs29: would be jku23:24
* armpit tests oe world builds with YP sstate mirror23:29
*** dv_ <dv_!~dv@> has quit IRC23:32
*** nathani__ <nathani__!~nathani@mail.validmanufacturing.com> has joined #yocto23:37
*** dv_ <dv_!~dv@62-178-50-190.cable.dynamic.surfer.at> has joined #yocto23:46
*** zeddii <zeddii!~bruce@unknown-6-81.windriver.com> has quit IRC23:55
*** Jefro <Jefro!~josiermi@> has quit IRC23:55
*** Jefro <Jefro!~josiermi@> has joined #yocto23:55
*** sjolley <sjolley!sjolley@nat/intel/x-bxxmapqatxixxyog> has joined #yocto23:56

Generated by irclog2html.py 2.11.0 by Marius Gedminas - find it at mg.pov.lt!