Thursday, 2019-01-10

*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto00:16
*** gtristan <gtristan!~tristanva@> has joined #yocto00:30
*** kroon <kroon!> has quit IRC00:39
*** nighty- <nighty-!> has joined #yocto00:45
*** MiskaX <MiskaX!> has quit IRC00:46
*** MiskaX <MiskaX!i0ofgd511b@2001:2060:72::3> has joined #yocto00:47
*** khem <khem!~khem@unaffiliated/khem> has quit IRC00:52
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC00:57
*** MiskaX <MiskaX!i0ofgd511b@2001:2060:72::3> has quit IRC00:59
*** MiskaX <MiskaX!> has joined #yocto00:59
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto01:01
moto-timohalstead: can you look at my comments on YOCTO-13101 and see if it makes sense?02:32
*** onlyesterday16 <onlyesterday16!~trungdt@> has joined #yocto03:04
robbawebbaderRichard: I'm currently creating a go package recipe and I think I feel your pain now. go.bbclass is quite tough to work with outside of the most simple use case..03:12
khemrobbawebba: if you spellout the problems we might be able to improve situation03:51
*** gtristan <gtristan!~tristanva@> has quit IRC03:53
*** paulg_ <paulg_!> has quit IRC04:17
*** dv_ <dv_!~dv@> has quit IRC05:22
*** comptroller <comptroller!> has quit IRC05:23
*** dv_ <dv_!> has joined #yocto05:36
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC05:56
*** AndersD <AndersD!~AndersD@> has joined #yocto06:15
*** AndersD <AndersD!~AndersD@> has quit IRC06:21
*** jobroe <jobroe!~manjaro-u@> has joined #yocto06:21
*** AndersD <AndersD!~AndersD@> has joined #yocto06:22
*** hamis <hamis!~irfan@> has joined #yocto06:41
*** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC07:32
halsteadmoto-timo, You make sense and I agree. I'll make the changes tomorrow.07:32
*** frsc <frsc!> has joined #yocto07:36
*** cvasilak <cvasilak!> has joined #yocto07:37
*** tprrt <tprrt!~tprrt@> has joined #yocto07:38
*** rburton <rburton!> has joined #yocto07:49
*** jmiehe <jmiehe!> has joined #yocto07:49
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has quit IRC07:51
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has joined #yocto07:53
*** fl0v0 <fl0v0!> has joined #yocto08:03
*** TobSnyder <TobSnyder!> has joined #yocto08:03
*** csanchezdll <csanchezdll!> has joined #yocto08:09
*** yann <yann!> has joined #yocto08:14
*** mckoan|away is now known as mckoan08:15
*** Carton__ <Carton__!~jo@2a02:120b:7ff:51a0:494c:257f:d093:db04> has joined #yocto08:20
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto08:20
*** ant_work <ant_work!> has joined #yocto08:24
*** cvasilak <cvasilak!> has quit IRC08:25
*** cvasilak <cvasilak!> has joined #yocto08:27
derRichardkhem: first of all it _always_ does a shared link, which sounds good but is in fact broken. here in x86_64 i get runtime errors08:37
derRichardsecondly, it tries to be smart and sets GOPATH and gueses what you want to build. the GO_IMPORT and GO_INSTALL variables are anything but easy to understand08:38
derRichardthird, absolute zero documentation, except trivial examples with no dependencies08:39
derRicharddependency management is also not existent08:39
derRichardyou need to mess yourself with go get or go dep in do_compile_prepend() hooks08:39
*** piotrlewicki <piotrlewicki!c19eda3d@gateway/web/freenode/ip.> has joined #yocto08:39
derRichardoh yes, and sdk support is also odd. if you install go in your sdk it works only if you set GOROOT yourself :(08:42
derRichardgiven the complexity of go.bbcalls the amount of usefulness is low :(08:42
derRichard</rant> :-)08:42
piotrlewickihi everyone08:43
LetoThe2ndin a nutshell: don't go, just bash :)08:43
derRichardLetoThe2nd: sorry, but this is bs....08:43
LetoThe2ndderRichard: heh, the pun was intended to use bash instead of go. i'm all fine with the rant, just go ahead! (even another intended pun! yay!)08:44
derRichardLetoThe2nd: in fact, we (my company) try very hard to avoid any bash scripts in systems we design. bash just sucks for everything with more than 50 lines of code :-)08:45
derRichardbut we are getting ot :)08:46
piotrlewickicould you help me with removing the kernel image from the rootfs? I'm installing it separately and I want to make my rootfs image (ubifs) smaller. I have tried RDEPENDS_kernel-base = "" but it didn't do anything and I still have my "/boot" directory filled with uImage symlink and uImage_{version} file that is never used08:46
LetoThe2ndderRichard: ot or not, i feel that you feel a little cheered up now? so if yes, mission accomplished!08:46
piotrlewickiis there a good way of removing the whole "/boot" directory in rootfs?08:47
LetoThe2ndpiotrlewicki: thats just tinkering with the symptoms, better find out what actually causes it to be installed, because it isn't by default08:47
piotrlewickiok... that's new to me. so it gets built by default but not installed?08:48
LetoThe2ndpiotrlewicki: EEEEXACTLY :)08:48
piotrlewickiok. I'll check that.. Thanks for the tip :D08:49
LetoThe2ndpiotrlewicki: so, getting started would be to bitbake -e your image, and from there dig what actually pulls it in.08:49
LetoThe2ndpiotrlewicki: and, hint: the package that causes the kernel to be installed is surprisingly named: "kernel" :-)08:51
piotrlewickithat's a lot of lines of python codexD08:51
LetoThe2ndpiotrlewicki: happy grepping!08:51
LetoThe2ndpiotrlewicki: otherwise, (syntax might by flaky now): bitbake -g your image and then look at package-depends.dot08:52
piotrlewickihehe. thx. and for me the name of the package is "kernel-image-uimage"08:52
piotrlewickiok. That should be enough for me to get going. your help is appreciated :-)08:53
LetoThe2ndhave fun!08:53
*** cquast <cquast!~cquast@> has joined #yocto08:56
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC09:02
*** mihais <mihais!~mihaiserb@> has joined #yocto09:03
*** piotrlewicki <piotrlewicki!c19eda3d@gateway/web/freenode/ip.> has quit IRC09:04
*** prabhakarlad <prabhakarlad!~prabhakar@> has quit IRC09:18
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has joined #yocto09:21
* derRichard wonders why yocto does not enable set -fstack-clash-protection09:22
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto09:24
*** khem <khem!~khem@unaffiliated/khem> has quit IRC09:27
rburtonderRichard: patches welcome!  add it to security_flags.inc09:31
derRichardrburton: well, this is the easy part. how to you test all this?09:31
derRichardi really want avoid sending patches which break things09:32
*** JaMa <JaMa!~martin@> has joined #yocto09:34
rburtonbitbake world09:36
rburtonor send a patch that you've tested as much as possible, and ask nicely that we run it through the AB09:36
derRichardyeah, bitbake world is not an option for me :D09:37
rburtondoesn't take *that* long09:37
rburton(50% of the time in webkit)09:37
derRichardthe thing is, we're corrently working on 4 yocto migrations, our build servers are rather busy with this :D09:38
rburtontest it locally with an image, if that works post a RFC patch and ask nicely09:38
*** Bunio_FH <Bunio_FH!> has joined #yocto09:38
derRichardthis is why i run in so much odd stuff. -> moving from custom buildsystems to yocto09:38
yoctiNew news from stackoverflow: Create a mirror of all dependencies of Yocto-based project <>09:43
derRichardrburton: wait, you mean "bitbake world" on poky? no openembedded-core or meta-openembedded?09:44
derRichardthen the amount of targets is really not that much09:44
rburtonpoky is oe-core+bitbake+some qa BSPs09:45
rburtonnot meta-oe09:45
JaMawithout meta-qt5, meta-browser and meta-oe it's just 1/10 of the time of bitbake world :)09:48
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto09:48
derRichardrburton: the amount of layers and their combinations will ever confuse me ;-P09:49
rburtonpoky is just bitbake+oe-core+meta-poky, as 1) an example of creating a distro and 2) something designed for QA to test09:51
derRichardthis actually makes a lot of sense :-)09:51
JaMareally? :)09:58
LetoThe2ndsense? go away! get behind me, satan!10:00
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto10:02
*** ctlnwr <ctlnwr!~catalin@> has joined #yocto10:04
*** ctlnwr_ <ctlnwr_!~catalin@> has joined #yocto10:04
*** cquast <cquast!~cquast@> has quit IRC10:04
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto10:10
*** nighty- <nighty-!> has quit IRC10:34
*** berton <berton!~berton@> has joined #yocto10:34
*** bleu <bleu!> has quit IRC10:37
*** Guest21318 <Guest21318!> has joined #yocto10:37
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC10:57
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto10:59
*** kaspter <kaspter!~Instantbi@> has quit IRC11:02
*** kaspter <kaspter!~Instantbi@> has joined #yocto11:02
*** falk0n_ is now known as falk0n11:08
*** falk0n <falk0n!> has joined #yocto11:08
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto11:15
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC11:20
*** otavio <otavio!~otavio@> has joined #yocto11:27
*** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto11:27
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto11:30
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC11:32
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto11:33
murray_Has anyone build a Yocto build from MacOS. Getting an error relating to sed that i cant seem to resolve.11:46
murray_$ MACHINE=var-som-mx6 DISTRO=fslc-x11 . setup-environment build_x11     this command returns sed: illgal option -- r11:46
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has quit IRC11:49
jofrmurray_: That's.. not supported..  :)
murray_Ok so i will have to build it from a linux machine11:55
murray_This is a pain as it means i have to use a VM :(11:55
murray_jofr: Messages above for you :)11:56
jofrmurray_: Yes  :)11:57
murray_jofr: Thanks, I do have one building on a VM but its been over 12 hours so far... @ 82%11:58
jofrmurray_: Sounds like you need a new machine  :p  Depending on your host-specs, you could assign tons of RAM to your VM and then mount a ramdisk on your guest-system and do your builds there.12:01
murray_jofr: This is not really an option as this is just a side project to what we are using the machines to develop.12:02
murray_jofr: We have a team that are creating us a custom Yocto build but they seem to be taking ages with it. Was hoping to create a build myself with the packages that i require so i can do some initial hardware/framework testing12:02
murray_jofr: Namley, NodeJs, Webserver, FTP and Maybe a package manager12:03
jofrmurray_: I see12:04
*** onlyesterday16 <onlyesterday16!~trungdt@> has quit IRC12:07
*** comptroller <comptroller!> has joined #yocto12:46
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC12:49
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC13:03
rburtonmurray_: because yocto runs upstream configure/make scripts, and they're for linux, you need a linux-compatible userspace.  you can install the gnu tools using brew on macos to get close, then you need to patch out the linuxisms in bitbake itself (i.e. inotify use), but then you'll discover that pseudo can't work on macos as LD_PRELOAD isn't functional unless you disable all the security features.13:11
rburtonmurray_: basically, use a lean vm.  builds are mostly cpu intensive so a good container won't be much slower.13:12
rburtonfor a one off job, get an amazon cloud machine and do a build in that for a few cents13:12
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto13:20
tgoodwinIs there a way to make a recipe re-unpack if its patch task changes (e.g., a variable used in a patch postfunc or patch append changes that would need a fresh copy of source code to run correctly)?13:30
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has quit IRC13:30
RPtgoodwin: its assumed that rerunning a task is always possible. The patch tasks therefore unapply any patches and reapply allowing them to be rerun13:32
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has joined #yocto13:33
tgoodwinRP: So implicitly then, it unapplies only things that were patched, not additional tasks associated with the patch task?13:33
tgoodwin(i.e., .patch files)13:34
RPtgoodwin: correct13:34
RPtgoodwin: the patch task would rerun if the patch files change13:34
RPwell, unpack would since the files it was fetching changed13:34
tgoodwinRP: right.  What I'm dealing with are patches that are a bit more dynamic where the patch just preps the file for a generic replacement.13:35
RPtgoodwin: I think that would break our assumption that tasks can rerun13:36
tgoodwinAnd indeed it is breaking it.  I was hoping for some mechanism that if a variable in one of those patch tasks changes, then unpack must re-occur as if the patch changed.  It sounds like maybe appending the unpack is the way to go.13:37
rburtonor a new task between unpack and patch13:38
tgoodwinrburton: I think that would fail for the same reason as running these tasks as a part of patch.  The tasks themselves cannot re-run without a fresh copy of source.13:38
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has quit IRC13:42
BlauskaerMHow can I save changes that I have made with: bitbake -c menuconfig virtual/kernel ?13:42
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has joined #yocto13:42
tgoodwinRP: so if I append unpack and update a variable used in that task, would that invalidate the task so that it reoccurs?13:43
*** prabhakarlad <prabhakarlad!~prabhakar@> has joined #yocto13:43
RPtgoodwin: yes13:50
tgoodwinRP: do you happen to know if a function defined in postfuncs would trigger the same behavior (vs. actually appending the task)?13:51
rburtoniirc a postfunc that needs to be re-ran will fire the entire task13:51
tgoodwin(Thanks for the help BTW.  I think I had some failed assumptions here on using vardeps, etc.)13:51
tgoodwinBlauskaerM: I usually go into the recipe work area and pull the `.config` out as a defconfig that I add via SRC_URI.  Or if you know what flags you changed, you can append the kernel's SRC_URI to add in the `file.cfg` with those changes.13:53
tgoodwinrburton: thanks, that's what I've been assuming.  I haven't mocked up a test to prove it though.13:54
tgoodwinrburton: in a similar train of thought, I was considering adding the variables from my patch task that are "patching the patches" to the do_unpack[vardeps] in an effort to "trick" an unpack to reoccur.13:57
tgoodwinPretty hackish, but that's what I get for having to bake arch strings into sourcecode. :-/13:57
yates_homeafter "smart install kernel-dev", rpm -ql kernel-dev only shows a few files being installed in /boot, none of which are headers.13:57
yates_homeany idea on where to start looking ?13:58
yates_homehow are the kernel-dev file package files specified?13:58
yates_homecorrection: how are the kernel-dev package files specified?13:59
*** AndersD <AndersD!~AndersD@> has quit IRC14:00
tgoodwinrburton: and RP: FWIW that (probably rubbish) idea of adding the related variable to unpack's vardeps did cause it to unpack fresh source for my patch tasks.14:09
*** no_such_user <no_such_user!> has quit IRC14:17
*** paulg <paulg!> has joined #yocto14:19
yates_homeperhaps i'm not making sense. let me back up. i am trying to write a on the target LKM. the first step is to get the kernel headers installed on the target.14:19
*** paulg <paulg!> has quit IRC14:19
yates_homehowever, normally these are installed via "smart install kernel-dev" (right?)14:20
yates_homes/i am trying to write a on the target LKM/i am trying to write a LKM on the target/14:20
yates_homebut that package has no kernel include files etc.14:21
derRichardto build kernel modules you need more than header files. you need more or less the full kernel source14:23
derRichardi don't know if yocto even allows this use case. better build the module cross using yocto14:23
*** ski7777 <ski7777!~quassel@> has quit IRC14:24
*** ski7777 <ski7777!> has joined #yocto14:24
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has joined #yocto14:26
yates_homederRichard: perhaps you are right14:27
yates_homei'll do some further digging.14:27
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has quit IRC14:29
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has joined #yocto14:31
*** paulg <paulg!> has joined #yocto14:32
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC14:36
yates_homerburton: do you have any thoughts on kernel-dev? shouldn't that just work, like on a regular distro (ubuntu, etc.)?14:37
*** paulg <paulg!> has quit IRC14:37
derRichardyates_home: also on a regular distro you need more than "-dev"14:39
derRichardthe kernel is not like a library14:39
derRichardand kernel modules are not users of a lib, they are part of the kernel14:39
yates_homewhat other things would one need on a desktop distro?14:41
derRichardsuse has -syms, -macros, ...14:42
yates_homefedora's kernel-devel states it's all you need to build kernel modules: kernel-devel.x86_64 : Development package for building kernel modules to match the kernel14:46
yates_homemaybe it's different from suse?14:46
yates_homewhen do kernel modules get loaded? is it before init or after?14:48
yates_home(probably OT)14:49
yates_homeshould we go to pm, derRichard?14:49
RPyates_home: you have seen the kernel-devsrc recipe?14:50
*** paulg <paulg!> has joined #yocto14:50
yates_homeRP: no!14:50
yates_homeoh yeah baby!14:51
*** AndersD <AndersD!> has joined #yocto14:53
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has joined #yocto14:54
*** AndersD_ <AndersD_!> has joined #yocto14:55
*** AndersD <AndersD!> has quit IRC14:58
RPyates_home: there are even tests that test it works!15:01
* kergoth yawns15:08
*** TobSnyder <TobSnyder!> has quit IRC15:12
*** armpit <armpit!~armpit@2601:202:4180:c33:51e6:8d7b:36a7:8429> has quit IRC15:12
*** hamis <hamis!~irfan@> has quit IRC15:13
*** stephano <stephano!~stephano@> has joined #yocto15:15
derRichardRP: nice to see kernel-devsrc :)15:16
BlauskaerMtgoodwin: .cfg approach seems a little bit advance for me so copied /proc/config.gz and replaced my deconfig file15:17
BlauskaerMHope it works15:17
BlauskaerMThanks for your reply15:17
*** armpit <armpit!~armpit@2601:202:4180:c33:f95f:7cf9:fdd5:fd56> has joined #yocto15:24
*** gaulishcoin <gaulishcoin!> has joined #yocto15:31
*** mihai <mihai!~mihai@unaffiliated/mihai> has joined #yocto15:31
derRichardhm, having realitve paths in bblayers.conf is tricky15:35
kergothyeah, don't do it15:35
kergothdetermine the path relative to TOPDIR and use that15:35
derRichardlike here?
kergothpretty much, yes. or use custom setup scripts to add and use a variable for the yocto root, if it isn't always ${TOPDIR}/..15:37
*** murray_ <murray_!2ee2059c@gateway/web/freenode/ip.> has quit IRC15:37
kergothmentor embedded linux uses custom setup scripts that do that, to point to the mel installation directory15:37
kergoththe issue with relative paths is you never know precisely what context any given variable is evaluated and used in15:38
kergothand $PWD changes at points during the build process15:38
kergothfor the initial layer setup it may work, but in general it's not a great idea to use relative paths in variables15:38
*** Carton__ <Carton__!~jo@2a02:120b:7ff:51a0:494c:257f:d093:db04> has quit IRC15:39
derRichardkergoth: so, i can use something like ${LAYERDIR} in bblayers.conf if i set LAYERDIR in bitbake using my local.conf?15:41
kergoththat woudln't make any sense in about 4 different ways15:42
kergothlayerdir is already set by bitbake and used in layer.conf for each individual layer, for one15:42
kergothbeyond that, local.conf is parsed long, long, long after bblayers.conf is parsed15:42
kergothlocal.conf can't be parsed until we can use bblayers to find the layers to locate and parse bitbake.conf15:42
kergothokay, two different ways :)15:43
derRichardok :D15:43
kergothbbalyers.conf can only use what's defined in bblayers.conf15:44
kergothit's the first file parsed15:44
* derRichard takes a note15:45
*** otavio <otavio!~otavio@debian/developer/otavio> has quit IRC15:48
*** otavio <otavio!~otavio@> has joined #yocto15:48
*** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto15:48
*** maudat <maudat!~moda@> has joined #yocto15:49
*** martinkelly <martinkelly!> has joined #yocto15:52
*** martinkelly <martinkelly!> has quit IRC15:54
*** martinkelly <martinkelly!> has joined #yocto15:54
*** kristoiv <kristoiv!~kristoiv@> has joined #yocto15:56
*** cvasilak <cvasilak!> has quit IRC15:57
*** gtristan <gtristan!~tristanva@> has joined #yocto16:01
*** AndersD_ <AndersD_!> has quit IRC16:03
*** tprrt <tprrt!~tprrt@> has quit IRC16:10
*** rob_w <rob_w!~bob@unaffiliated/rob-w/x-1112029> has quit IRC16:18
*** aleblanc <aleblanc!~aleblanc@2607:f2c0:95d9:8500:7028:f855:17e5:678c> has joined #yocto16:25
*** cdgarren <cdgarren!~cdgarren@> has joined #yocto16:26
*** jmiehe <jmiehe!> has quit IRC16:31
jonmasonRP: I see the email now and will bottom out on if KVM is supported native and will respond before the end of the day16:37
*** paul_99 <paul_99!~paul@> has joined #yocto16:40
RPjonmason: thanks16:40
*** ant_work <ant_work!> has quit IRC16:55
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC17:05
*** jobroe <jobroe!~manjaro-u@> has quit IRC17:14
*** yann <yann!> has quit IRC17:15
*** tgraydon <tgraydon!~textual@> has joined #yocto17:17
kanavinrburton: patch is on the way :)17:17
*** WillMiles <WillMiles!> has joined #yocto17:18
rburtonkanavin: :)17:18
CroftonWe should pay attention to this:
*** mckoan is now known as mckoan|away17:24
zeddiiooo. shiny and new:17:28
zeddiiroot@qemux86-64:~# uname -a17:28
zeddiiLinux qemux86-64 5.0.0-rc1-yoctodev-standard #1 SMP PREEMPT Thu Jan 10 16:01:22 UTC 2019 x86_64 GNU/Linux17:28
zeddiiSHIP IT17:29
Croftonzeddii, ++17:29
*** frsc <frsc!> has quit IRC17:29
*** Bunio_FH <Bunio_FH!> has quit IRC17:29
* zeddii pushes it to linux-yocto-dev to see what'll explode. booted once. must be golden.17:29
*** boucman_work <boucman_work!~jrosen@wesnoth/developer/boucman> has quit IRC17:32
*** kristoiv <kristoiv!~kristoiv@> has quit IRC17:33
*** kristoiv <kristoiv!~kristoiv@> has joined #yocto17:35
*** kristoiv <kristoiv!~kristoiv@> has quit IRC17:36
*** mihais <mihais!~mihaiserb@> has quit IRC17:47
*** gtristan <gtristan!~tristanva@> has quit IRC18:05
*** gtristan <gtristan!~tristanva@> has joined #yocto18:05
*** kroon <kroon!> has joined #yocto18:08
*** Bunio_FH <Bunio_FH!> has joined #yocto18:11
*** Carton__ <Carton__!~jo@> has joined #yocto18:11
*** Carton__ <Carton__!~jo@> has left #yocto18:11
*** yann <yann!> has joined #yocto18:21
*** agust <agust!> has quit IRC18:26
*** fl0v0 <fl0v0!> has quit IRC18:28
*** mihais <mihais!~mihaiserb@> has joined #yocto18:37
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC18:40
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:01
*** JaMa <JaMa!~martin@> has quit IRC19:03
JPEWWTF! Bitbake it dying from SIGBUS???19:04
derRichardJPEW: do you have a core file or a line in dmesg?19:04
*** mihais <mihais!~mihaiserb@> has quit IRC19:06
*** rperier <rperier!~rperier@unaffiliated/bambee> has quit IRC19:06
JPEWderRichard: No... it's dying inside a docker container. I'm pretty sure it's my own fault (somewhere).... SIGBUS is just the last thing I would have expected19:09
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC19:26
derRichardJPEW: well, inside docker...19:31
derRichardmaybe a mem cgroup kicked in19:31
derRichardor you reached the max number of allowed mappings19:31
JPEWderRichard: I didn't setup any memory restrictions, so I don't think it's that.... trying with a larger vm.max_map_count19:35
*** rcw <rcw!~rcw@> has joined #yocto19:35
derRichardJPEW: did you check dmesg? no oom message?19:36
JPEWNo, OOM19:36
JPEWnothing suspicious in dmesg19:37
derRichardi still think bitbake ran into a odd restriction and had no clue how to handle it :D19:38
JPEWderRichard: That seems likely19:38
derRicharda few days ago i saw qt configure failing in odd ways because docker guys thought it is a good idea to block the rather new statx() syscall :D19:38
JPEWderRichard: Ok, it appears to be the fault of some code I wrote, not some endemic system problem. Thanks for the help!19:54
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC19:55
*** florian_kc <florian_kc!~florian_k@Maemo/community/contributor/florian> has joined #yocto19:55
derRichardJPEW: :-)19:57
rburton| x86_64-poky-linux-ld.bfd: arch/x86/kernel/head_64.o: unable to initialize decompress status for section .debug_line20:06
rburtonanyone seen that before?20:06
rburtonzeddii: ^20:07
derRichardone moment, i saw this20:08
derRichardrburton: okay, not x86_64. this was on arc20:10
*** Guest29947 <Guest29947!> has joined #yocto20:12
*** Bunio_FH <Bunio_FH!> has quit IRC20:12
*** berton <berton!~berton@> has quit IRC20:14
kroonrburton, what does "mut" (as in the git branch) stand for ?20:16
bluelightningkroon: master under test20:19
*** mihais <mihais!~mihaiserb@> has joined #yocto20:22
*** gtristan <gtristan!~tristanva@> has quit IRC20:24
kroonbluelightning, ah!20:25
*** Bunio_FH <Bunio_FH!> has joined #yocto20:26
rburtonderRichard: still might be useful. any idea how to solve?20:33
derRichardrburton: in the arc case it was a bug in their gcc port20:34
derRichardwhat kernel and gcc version are you using?20:35
rburtonand whatever gcc is in thud20:37
rburtonhm i wonder if its a elfutils bug, lets revert that20:38
derRichardyes, i was about to ask that20:38
derRichardmaybe another objtool issue ;-\20:38
rburtonkhem: hitting in thud, can we pick the fix for binutils20:38
*** Bunio_FH <Bunio_FH!> has quit IRC20:49
*** Bunio_FH <Bunio_FH!> has joined #yocto20:54
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto21:15
robbawebbais it possible to disable bitbake from building *-dev and *-staticdev packages for a specific recipe?21:30
armpitaehs29, I am trying your multiconf patches to see if they fix my problem21:43
*** gaulishcoin <gaulishcoin!> has quit IRC21:43
kroonrobbawebba, for *-staticdev, checkout *I think*21:45
kroonrobbawebba, oh, didnt read the part "for a specific recipe"21:46
kroonrobbawebba, but yeah figure out how to pass extra configure flags so that no static libs are created and append that to your build configuration21:47
bluelightningrobbawebba: are the packages empty or do they contain files?21:47
bluelightningif they contain files you'll need to delete those or otherwise prevent them from being installed at do_install time21:48
*** rcw <rcw!~rcw@> has quit IRC21:48
*** andrey_utkin <andrey_utkin!~andrey_ut@gentoo/developer/andrey-utkin> has quit IRC21:48
*** tgraydon <tgraydon!~textual@> has quit IRC21:48
bluelightningthen, you'd need to set ALLOW_EMPTY_${PN}-dev = "0"  and ALLOW_EMPTY_${PN}-staticdev = "0"21:49
bluelightning(you could exclude them from PACKAGES instead but that can be tricky depending on what else is going on)21:49
*** nate0202 <nate0202!> has quit IRC21:57
*** nate0202 <nate0202!> has joined #yocto21:57
*** nate02 <nate02!> has joined #yocto21:57
*** armpit <armpit!~armpit@2601:202:4180:c33:f95f:7cf9:fdd5:fd56> has quit IRC22:01
kergothnot sur ewhat efect removing them from pakcages would have on the depchains logic, if any22:02
*** behanw <behanw!uid110099@gateway/web/> has quit IRC22:08
*** lh <lh!sid77898@osuosl/staff/lh> has quit IRC22:08
*** lh <lh!sid77898@osuosl/staff/lh> has joined #yocto22:10
*** behanw <behanw!uid110099@gateway/web/> has joined #yocto22:10
*** armpit <armpit!~armpit@2601:202:4180:c33:d000:5af4:72a3:b2fa> has joined #yocto22:17
aehs29armpit: they probably will fix the issue in your case, but I had a talk with RP and some changes are still gonna be necessary, so I'll still send a v2 at some point22:20
*** WillMiles <WillMiles!> has quit IRC22:24
*** kaspter <kaspter!~Instantbi@> has quit IRC22:26
*** kaspter <kaspter!~Instantbi@> has joined #yocto22:27
derRichard  file /usr conflicts between attempted installs of pango-1.42.4-r0.core2_64 and libcairo2-1.14.12-r0.core2_6422:37
robbawebbabluelightning: they contain files. This is for a custom recipe that inherits from go.bbclass. The -dev and -staticdev packages contain the source code, but I would like to not create these packages if possible. This recipe fetches from a monorepo and has a ton of stuff inside it, such as static library files, documentation, makefiles, etc...22:43
robbawebbabluelightning: okay, I'll try to delete the files during do_install_append. Thanks for the tip!22:44
*** maudat <maudat!~moda@> has quit IRC22:45
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto22:49
armpitaehs29, that fixes my problem22:55
aehs29armpit: great22:55
*** tgraydon <tgraydon!~textual@> has joined #yocto23:05
*** alpha <alpha!> has joined #yocto23:08
*** alpha <alpha!> has quit IRC23:09
*** stephano <stephano!~stephano@> has quit IRC23:10
moto-timohalstead: should we point to eclipse-full for the SDK files that will be kept or should we use the partial mirror URL?23:13
halsteadmoto-timo, Use the partial mirror since it will stay around for sure. The full mirror will just be for the community.23:15
halsteadmoto-timo, Lets get those files copying automatically.23:15
moto-timohalstead: thank you, just wanted to double check. Agreed on automation.23:26
halsteadmoto-timo, Can you confirm that is all we need?23:44
halsteadmoto-timo, I can mirror the whole drop if that is better. Just mirring *linux-gtk-x86_64.tar.gz right now.23:45
*** nate0202 <nate0202!> has joined #yocto23:49
*** nate02 <nate02!> has quit IRC23:51
*** ebolton <ebolton!~ebolton@> has joined #yocto23:54
moto-timohalstead: trying to figure out their new versioning scheme (2018-09, 2018-12 and so on versions)23:54
moto-timohalstead: 4.7.3, 4.7.3.a, 4.8.* should all be backed up23:55
eboltonhey all, trying to install an ESDK generated from krogoth based env....I've tried ESDKs generated from several images (including core-image-minimal), and on the last install step I get a ton of these errors:23:57
eboltonERROR: Unexpected tasks or setscene left over to be executed:23:57
ebolton   task 1114 of 2442 (ID: 1178, /home/ebolton/poky_sdk/layers/poky/meta/recipes-extended/parted/, do_fetch)23:57
rburtonebolton: if you can, consider using normal SDKs instead23:59
rburtonthe traditional ones are more reliable, especially in an older release like krogoth23:59

Generated by 2.11.0 by Marius Gedminas - find it at!