Friday, 2019-03-15

*** AndersD_ <AndersD_!~AndersD@> has quit IRC00:02
*** joeytheaint is now known as joeythesaint00:18
*** chandana73 <chandana73!~ckalluri@> has quit IRC00:20
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto00:30
*** fenrig <fenrig!~fenrig@> has quit IRC00:34
*** fenrig <fenrig!~fenrig@> has joined #yocto00:36
*** peacememories <peacememories!~textual@2a02:8388:8480:fd80:a5ef:5ba3:4d3:3a88> has joined #yocto01:07
*** nighty- <nighty-!> has joined #yocto01:53
*** peacememories <peacememories!~textual@2a02:8388:8480:fd80:a5ef:5ba3:4d3:3a88> has quit IRC02:25
alicefhello, i'm using devtool modify for trying to work with existing code. but it cannot find the recipe. also if is in the source code03:40
alicefthe layer have to be added with bitbake layer-add for find the recipe ?03:42
alicefI'm by the way reading the user manual but there is almost no explanation on where the recipe have to reside03:43
alicefdevtool modify $workspace/recipes/ $workspace/sources/sl/03:45
alicefbut it cannot find the recipe03:45
kergothit has to reside the same place it would for bitbake to build it.03:49
kergothadd the layer to bblayers in conf/bblayers.conf as the documentation describes for adding a layer to the build03:49
kergothdevtool extracts the source and adds a bbappend to adjust the configuration of the recipe to build from those sources. the recipe still has to be available to bitbake as a build03:50
alicefkergoth: what if i have many layers to modify? there is no why of automating it ?03:51
kergothwhat do you mean?03:51
kergothagain, devtool modifies how a recipe builds. bitbake has to be able to build the recipe for devtool to be of any use whatsoever03:51
kergothadd the layers you need to bblayers03:51
alicefkergoth: add layer management functionality03:53
yoctiBug 11677: enhancement, Medium, 2.99, paul.eggleton, NEW , eSDK: add layer management functionality03:53
alicefthis probably would be useful for my case.03:53
kergothfirst, you said nothing about the esdk03:53
alicefkergoth: sorry, i thought devtool was only for esdk03:54
kergothi use it every day and never touch esdk. it's a generally useful tool03:54
kergothbut that issue does sound up your alley, indeed03:54
alicefkergoth: thanks you03:55
alicefkergoth: using bblayers.conf is a good idea indeed. I could just use the bblayers.conf in the poky-sdk03:56
alicefand than modify it using devtool modify03:57
kergothbitbake-layers add-layer is really just a convenience around manually changing bblayers, so it should be a viable workaround for now at least03:57
alicefhow bitbake-layers choose the bblayers file ?03:57
alicefi think i have one under poky/ and one under poky-sdk/03:58
alicefprobably when i source the poky-sdk enviroment is using that03:58
alicefI will do some try with it03:58
*** fenrig <fenrig!~fenrig@> has quit IRC04:08
*** georgem_home <georgem_home!uid210681@gateway/web/> has quit IRC04:09
*** fenrig <fenrig!~fenrig@> has joined #yocto04:10
*** vmeson <vmeson!> has quit IRC04:20
*** learningc <learningc!> has joined #yocto04:22
*** vmeson <vmeson!~rmacleod@> has joined #yocto04:23
learningcIs there a way to list tasks dependencies? Like which task preceed or succeed which?04:27
*** vmeson <vmeson!~rmacleod@> has quit IRC04:28
*** learningc <learningc!> has quit IRC04:47
*** learningc <learningc!> has joined #yocto04:47
*** fenrig <fenrig!~fenrig@> has quit IRC04:48
*** fenrig <fenrig!~fenrig@> has joined #yocto04:50
*** fenrig <fenrig!~fenrig@> has quit IRC05:15
*** fenrig <fenrig!~fenrig@> has joined #yocto05:18
*** User__ <User__!> has joined #yocto05:43
*** learningc <learningc!> has quit IRC05:47
*** fenrig <fenrig!~fenrig@> has quit IRC05:57
*** fenrig <fenrig!~fenrig@> has joined #yocto06:00
*** yocti <yocti!> has joined #yocto06:30
*** kroon <kroon!~jkroon@> has joined #yocto06:35
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto06:35
*** learningc <learningc!> has joined #yocto06:44
*** agust <agust!> has joined #yocto06:45
*** User__ <User__!> has quit IRC06:47
*** fenrig <fenrig!~fenrig@> has quit IRC06:55
*** fenrig <fenrig!~fenrig@> has joined #yocto06:58
*** fenrig <fenrig!~fenrig@> has quit IRC07:04
*** fenrig <fenrig!~fenrig@> has joined #yocto07:08
*** justanotherboy <justanotherboy!~justanoth@> has quit IRC07:10
*** jeanba <jeanba!~jbl@> has joined #yocto07:15
*** jeanba <jeanba!~jbl@> has left #yocto07:15
*** fenrig <fenrig!~fenrig@> has quit IRC07:30
*** fenrig <fenrig!~fenrig@> has joined #yocto07:32
*** User__ <User__!> has joined #yocto07:43
*** learningc <learningc!> has quit IRC07:46
*** daniel__ <daniel__!~daniel-k@> has joined #yocto07:56
*** learningc <learningc!> has joined #yocto08:01
*** User__ <User__!> has quit IRC08:04
*** varjag <varjag!> has joined #yocto08:16
*** Bunio_FH <Bunio_FH!> has joined #yocto08:17
*** tprrt <tprrt!~tprrt@> has joined #yocto08:19
*** TobSnyder <TobSnyder!> has joined #yocto08:19
*** Bunio_FH <Bunio_FH!> has quit IRC08:20
*** Bunio_FH <Bunio_FH!> has joined #yocto08:20
*** prabhakarlad <prabhakarlad!~prabhakar@> has joined #yocto08:31
*** fenrig <fenrig!~fenrig@> has quit IRC08:39
yoctiNew news from stackoverflow: psplash image does not appear (yocto & qemu) <>08:40
*** sk_tandt <sk_tandt!> has joined #yocto08:40
*** fenrig <fenrig!~fenrig@> has joined #yocto08:42
*** fbre <fbre!91fdde45@gateway/web/freenode/ip.> has joined #yocto08:43
fbreHello, which recipe contains the command line tool "top"? does not give a good hint.08:44
fbreI don't want the busybox version08:44
fbrebut the full-featured version of top08:45
LetoThe2ndfbre: tip, htop is a package on its own.08:51
LetoThe2nd(and even more bang for the buck, methinks)08:51
*** sashko <sashko!~sashko@> has left #yocto08:52
*** kroon <kroon!~jkroon@> has quit IRC08:55
*** fenrig <fenrig!~fenrig@> has quit IRC08:56
*** User__ <User__!> has joined #yocto08:59
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has joined #yocto09:00
*** yacar_ <yacar_!~yacar@> has joined #yocto09:00
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has joined #yocto09:03
*** learningc <learningc!> has quit IRC09:03
*** jeanba <jeanba!~jbl@> has joined #yocto09:06
*** jeanba <jeanba!~jbl@> has left #yocto09:08
*** User__ <User__!> has quit IRC09:30
*** User__ <User__!> has joined #yocto09:30
*** yacar_ <yacar_!~yacar@> has quit IRC09:30
*** User__ <User__!> has quit IRC09:31
*** User__ <User__!> has joined #yocto09:31
*** User__ <User__!> has joined #yocto09:32
*** awe00 <awe00!~awe00@unaffiliated/awe00> has joined #yocto09:35
*** yacar_ <yacar_!~yacar@> has joined #yocto09:46
*** lfa_ <lfa_!~lfa@> has joined #yocto09:57
*** rburton <rburton!> has joined #yocto09:58
*** learningc <learningc!> has joined #yocto10:00
*** lfa <lfa!~lfa@> has quit IRC10:01
*** lexa_ <lexa_!~user@> has joined #yocto10:03
*** User__ <User__!> has quit IRC10:03
lexa_Hi, I have a question about creating mirrors in Yocto.10:07
lexa_I set BB_GENERATE_MIRROR_TARBALLS = "1" in local.conf, and git2_*.tar.gz files10:07
lexa_are created in the download directory. What bothering me is that this tarballs10:07
lexa_are not versioned. What happen if I bump a recipe version? How Bitbake would10:07
lexa_recognize that it needs to re-download the Git repository?10:07
fbreLetoThe2nd: cool, thanx! I added "procps" to my CORE_IMAGE_EXTRA_INSTALL_append variable10:08
rburtonlexa_: i believe it downloads if the sha is after isn't in the local copy10:09
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto10:11
lexa_rburton: And then it will create a new tarball?10:11
sveinseIs there anyone here who has experience compiling and running Qt apps under qemux86? Foremost to get it to compile, but I'd like to avoid having to run X.10:11
rburtonlexa_: yes10:11
*** jeanba <jeanba!~jbl@> has joined #yocto10:12
lexa_rburton: Thank you for explanation.10:13
*** jeanba <jeanba!~jbl@> has left #yocto10:15
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has quit IRC10:15
fbresveinse: if you just use qtcore, you won't need X10:16
*** TobSnyder <TobSnyder!> has quit IRC10:18
sveinsefbre: apparently I need to configure Qt to ignore opengl tests, because it failed in my build. Its not enough to remove X11 from distro features10:19
*** TobSnyder <TobSnyder!> has joined #yocto10:19
fbresveinse: there is a Qt configure option called "-opengl". Have you tried to remove that?10:21
*** jofr <jofr!~jofr@> has left #yocto10:22
*** jofr <jofr!~jofr@> has joined #yocto10:25
*** jofr <jofr!~jofr@> has quit IRC10:25
sveinsebtw, how can I remove a PACKAGECONFIG entry without having to repeat the whole default?10:25
rburtonsveinse: _remove10:38
*** yacar_ <yacar_!~yacar@> has quit IRC10:39
*** MarcWe <MarcWe!hmwmatrixo@gateway/shell/> has joined #yocto10:50
sveinseJust checked PACKAGECONFIG. it parses DISTRO_FEATUREs, and I haven't enabled x11, directfb nor gl. Verified that these PACKAGESCONFIGs are not set, yet the build fails. More digging needed apparently.10:53
rburtonthe distro feature is opengl, you checked that right10:54
*** lfa <lfa!~lfa@> has joined #yocto10:55
sveinseyeah, I did. Checked both my DISTRO_FEATURES and PACKAGECONFIG for this recipe10:55
rburtonsounds like the qt recipe is as usual a bit of a monster10:56
sveinseTo be honest, I dislike that Qt is both an application framework as well as a GUI kit. But that is ranting for another time10:57
fbreI just can speak for the qt configure stuff of a non-yocto environment. It's the -opengl option there10:57
*** lfa_ <lfa_!~lfa@> has quit IRC10:57
fbreFirst, it was a GUI kit. They separated the app framework to qtcore in qt410:58
sveinsefbre: I just checked the configure options, and there is no -opengl in it10:59
*** User__ <User__!> has joined #yocto10:59
fbresveinse: Grep for "./configure -debug-and-release -opensource -platform linux-g++ -opengl desktop" for instance on webpage
fbreI think yocto-linux route those options just trough11:03
*** learningc <learningc!> has quit IRC11:03
fbresveinse: if I remember corretly, there's always an opposite option "-no-blabla" in Qt's configure concept11:05
sveinseThe configure is quite extensive:
fbresveinse: Uhm... I cannot see a -opengl option. But maybe that is default. So try to add -no-opengl  as the generic switch-off option. But I cannot promise if that will work.11:07
sveinsefbre: yup, thanks. That took it past configure at least. Bug in the recipe.11:13
fbrecool. You're welcome :)11:14
sveinseDoes this imply that noone is really using Qt with qemu? Or is X the main way everyone is going for such a setup?11:14
fbreI suppose Qt users usually want to see some widgets. Although I especially like Qt's cool framework and also use it for programming command line tools (without GUI)11:15
rburtonsveinse: what do you *actually* want to do.11:21
rburtonsveinse: you have a graphical app using qt that you want to run in a qemu?11:21
sveinsefbre: we do the latter too, so my inital goal was to compile qt witout any GUI.11:22
sveinseHowever I do have another GUI app that would be awfully nice to be able to run within qemu. On our HW we run open gl via directfb (I think), not X. I'm uncertain what would be the simplest approach for qemu for this. I'd like to avoid having to do a major X setup just for displaying a singular fullscreen app.11:24
rburtoni doubt you run opengl via directgb11:24
rburtonyou might run EGL on framebuffer11:24
sveinsethen its eglfs11:24
*** mihai <mihai!~mihai@unaffiliated/mihai> has quit IRC11:24
sveinseI admit being a little out of my league here11:25
rburton <-- qt' eglfs in software11:25
rburtonshould work in qemu11:25
sveinserburton: cool, non accel is more than fine. I need to figure out what PACKAGE_CONFIG corresponds to that.11:27
sveinsethis is not directfb, right?11:27
rburtonno, that's directly to the framebuffer devices11:27
fbresveinse: I'm afraid I can't help with getting opengl work for your special case. I just have used it on Windows for the past years11:28
sveinsefbre: no worries. thanks for the assist!11:28
sveinseI'll attept to enable eglfs and see what happens11:30
*** berton <berton!~berton@> has joined #yocto11:35
sveinseNo, the option was -linuxfb and compilation is under way. Excited to see if this works. Thanks rburton11:42
*** justanotherboy <justanotherboy!~justanoth@> has joined #yocto11:49
*** bluelightning_ <bluelightning_!~paul@pdpc/supporter/professional/bluelightning> has quit IRC11:55
*** lfa_ <lfa_!~lfa@> has joined #yocto11:56
*** lfa <lfa!~lfa@> has quit IRC12:00
*** learningc <learningc!> has joined #yocto12:00
*** User__ <User__!> has quit IRC12:03
fbresveinse: and if one configures -opengl -linuxfb, he can have Qt rendering 3D stuff into memory buffers, if I get it right?12:10
*** justanotherboy <justanotherboy!~justanoth@> has quit IRC12:10
*** OutBackDingo <OutBackDingo!~quassel@unaffiliated/outbackdingo> has joined #yocto12:18
*** User__ <User__!> has joined #yocto12:20
*** learningc <learningc!> has quit IRC12:24
*** lfa <lfa!~lfa@> has joined #yocto12:30
*** lfa_ <lfa_!~lfa@> has quit IRC12:33
*** yacar_ <yacar_!~yacar@> has joined #yocto12:50
*** gsalazar <gsalazar!> has quit IRC12:52
*** gaulishcoin <gaulishcoin!> has joined #yocto12:55
*** willie2 <willie2!d973313a@gateway/web/freenode/ip.> has joined #yocto12:58
willie2Hi, I was here asking about sato help and got some very nice tips , however I'm having a hard time finding any documentation that describes how to do this. Are there any usefull guides i might have missed for this?13:04
*** User__ <User__!> has quit IRC13:11
sveinsefbre: not sure. I'll try. I do suspect that it needs some libs from the system, but its worth a try.13:12
*** learningc <learningc!~learningc@2001:d08:d6:3bf7:4d06:2d8c:4476:c89f> has joined #yocto13:20
jtrimbl3So I've got an image recipe "B" where I copy the output image from recipe "A" into the rootfs of image "B".  I've got the copying working, but when I make a change that causes a difference in "A", "B" does not get rebuilt.13:27
jtrimbl3I'm building "B" in a multiconfig/, and "A" in my "main config" (conf/local.conf).13:27
jtrimbl3How do I declare that do_rootfs of B depends on do_image_wic of A?13:28
fbreAnother question: By "bitbake virtual/kernel -c menuconfig", I switched off many things I think I don't need. Is there a thing like telling the kernel configuration to verify the dependencies and to switch on everything I unchecked too much?13:42
fbreCurrently, I have compile errors because I unchecked an option I rather should keep checked13:43
fbrebut I don't know which one13:43
MarcWeyou can save the config in the kernel config list13:44
fbreI still have the old .config file and can compare them side-by-side. But I cannot get the link which change is responsible for the compile error13:45
fbreSo I thought maybe there is an automatically-solve-the-dependencies thingy13:46
MarcWeand load it using13:46
MarcWeuse-kernel-config=exampl_defconfig  saved as a afile that is loaded SRC_URI =+file://defconfig13:46
fbreI don't get it what you mean, MarcWe13:48
MarcWefbre: ignore  the  last thing I described13:50
MarcWefbre: Best thing that i know is diffing the config files13:50
paulbarkerfbre: I think you're on your own with this one. There's nothing automatic to check kernel configs at that level of detail13:51
MarcWefbre: If you have 1 working and 1 not working13:51
paulbarkerThe Kconfig files in the kernel source tree do express dependencies but there's always things missing. Too many possible permutations to test everything13:51
*** jofr <jofr!~jofr@> has joined #yocto13:59
fbreWhen I look into <help> of a menuconfig item, it tells me the dependencies to other options. So I thought there is an automatic dependency resolver13:59
paulbarkerThere is, but the dependencies listed are always incomplete14:00
markapaulbarker: so netns is definitely a unicorn14:01
markaone of the rare recipes that work in a 'cross' environment but fail when the build and target arch are the same14:01
paulbarkermarka: I think some of the difficulty is caused by the use of cgo14:01
markais there a reason you were building static?14:01
markajust curious, I still want to solve this for static build as it should be possible14:02
markapaulbarker: it most certainly is the cgo aspect, along with -static14:02
markaafter sleeping on it I have a few ideas I need to poke at this morning14:03
markafirst I had to respond to some comments on my other two outstanding RRs14:04
paulbarkermarka: Just looking at the git history14:04
paulbarkerI copied do_compile from the original runc recipe which also did `oe_runmake static`14:04
markaOK, again I was just curious14:05
markaback in a bit after I try some things out14:05
Piratydoes yocto define dependencies (as mentioned in an ipk's CONTROL file) by detecting the libraries a binary is linked against + having a map which package provides it?14:06
*** feddischson <feddischson!> has joined #yocto14:07
markaPiraty: you would usually need to include these as a DEPENDS in your recipe, and if it is dynamically linked these will essentially become RDEPENDS14:08
paulbarkermarka: I have no idea is static is actually needed. Definitely something to look into!14:08
markain which case the dependency is carried into the package14:08
markaPiraty: I am not an expert on this topic, so you can most likely do a quick test to validate this14:09
markapaulbarker: I still want to get this working as it is a valid thing to do14:10
Piratymarka: i'm not using yocto yet, just elaborating options and asking things to get a better view14:10
markaPiraty: in my experience the above is correct, for libraries14:11
Piratymarka: do you  mean only packages i add manually to the recipe will end up in the packages's metadata ("depends" field in ipk's CONTROL  for example) ? what would be sad14:12
markaif for example you needed to link against libssh, you would need to include it in your recipes DEPENDS14:14
markathis would ensure libssh-dev was installed in the recipe specific sysroot to assist building14:15
markaand would ensure libssh was noted as a dependency in the final packaging14:15
markabut yes, you are required to make the addition in the recipe to DEPENDS14:15
Piratymarka should read it too ;)14:19
*** sk_tandt_ <sk_tandt_!> has joined #yocto14:19
Piratyi took RDEPENDS for revdepends somehow...14:19
Piratybut it's rundepends14:19
paulbarkerIt's rarely an issue in practice unless you use dlopen()14:20
paulbarkerIf you link directly against a library you'll need it in DEPENDS anyway so it's present at build time14:20
*** sk_tandt <sk_tandt!> has quit IRC14:21
paulbarkerRDEPENDS is usually the place for commands you run, libs you dlopen(), packages which provide configuration, etc as it's not possible to detect that stuff automatically14:21
Piratythanks paulbarker. one more thing about it: is the mapping of "shlib to package" static? as in
Piratyor is it built during compilation, depending on what i selected to be build, specifically for that buildjob?14:22
*** Crofton <Crofton!> has joined #yocto14:22
markaif your installed package includes scripts with #!/bin/something, the build system will warn you about missing 'something'14:22
*** learningc <learningc!~learningc@2001:d08:d6:3bf7:4d06:2d8c:4476:c89f> has quit IRC14:23
Piratyok. sounds sane14:23
paulbarkerPiraty: It's in the docs... "During the do_package task of each recipe, all shared libraries installed by the recipe are located. For each shared library, the package that contains the shared library is registered as providing the shared library."14:23
markaPiraty: no need to read, what I posted was essentially the distilled version14:23
markayou still need the direct dependency listed in DEPENDS, the rest is automatic as I mentioned14:24
jofr"no need to read", I don't remember having ever seen anyone discourage someone from reading documentation before...  :p14:25
markareading is overrated14:26
markaI tell my kids this all the time14:26
markajofr: thanks, I needed that14:32
*** gsalazar <gsalazar!> has joined #yocto14:41
*** Crofton <Crofton!> has quit IRC14:56
*** jwessel <jwessel!~jwessel@> has joined #yocto14:57
*** Crofton <Crofton!> has joined #yocto15:05
jtrimbl3If I want to append the do_install() of a recipe in a .bbappend file and the original do_install() is a shell function but I want my appended functionality to be written in Python, what's the best way to do that?15:12
*** chandana73 <chandana73!~ckalluri@> has joined #yocto15:14
*** fbre <fbre!91fdde45@gateway/web/freenode/ip.> has quit IRC15:19
*** Crofton <Crofton!> has quit IRC15:25
yacar_jtrimbl3: I think you that one of the case that is problematic (or at least I couldn't solve it) you probably need to patch the former one and replace the whole thing with yours15:31
yacar_or write your's in shell ahah15:32
paulbarkerjrtimbl3: You'll need to define a new task for that15:32
paulbarkerjtrimble ^^^^. I can't spell15:33
yacar_paulbarker: but how would you do that then ? You'll call the new task from the former do_install ?15:34
yacar_Ok, that makes sens :) thanks15:35
*** Tamis <Tamis!504e0570@gateway/web/freenode/ip.> has quit IRC15:35
yacar_When I did it I just patch the first one, even though I knew that it was the wrong way to do it x)15:36
*** khem <khem!~khem@unaffiliated/khem> has quit IRC15:44
*** vmeson <vmeson!> has joined #yocto15:44
markaI am pretty sure there are examples in existing recipes where there is a chain approach, have the shell function reference a python function15:45
markadon't hold me to it though, its been a while since I looked15:45
kergothjtrimbl3: use a postfunc15:46
kergotha new task works, but is overkill15:46
kergothdo_install[postfuncs] += "my_do_install"; python my_do_install () { : }15:46
*** AndersD <AndersD!~AndersD@> has joined #yocto15:49
paulbarkerI always forget that postfuncs exist15:50
*** varjag <varjag!> has quit IRC15:50
*** AndersD_ <AndersD_!~AndersD@> has joined #yocto15:54
*** Bunio_FH <Bunio_FH!> has quit IRC15:56
*** AndersD <AndersD!~AndersD@> has quit IRC15:57
*** khem <khem!~khem@unaffiliated/khem> has joined #yocto15:58
*** prabhakarlad <prabhakarlad!~prabhakar@> has left #yocto16:01
kergothI'm personally not a big fan of recipes adding new tasks, as i'd prefer if recipes were more declarative, less changing how bitbake does its job and more just filling in the metadata for existing tasks and hooks where provided16:03
markaplus you avoid having work split across scripts, logs....16:05
markaI tend to cheat while debugging a recipe's build. Edit the run.do_compile, and comment out set e, and do_compile, exit..., then source run.do_compile. Quick and easy devshell.16:07
*** yacar_ <yacar_!~yacar@> has quit IRC16:09
*** sk_tandt_ <sk_tandt_!> has quit IRC16:17
yoctiNew news from stackoverflow: Enable systemd services using yocto <>16:42
*** lucaceresoli <lucaceresoli!> has quit IRC16:44
*** chandana73 <chandana73!~ckalluri@> has quit IRC16:58
*** TobSnyder <TobSnyder!> has quit IRC17:01
*** daniel__ <daniel__!~daniel-k@> has quit IRC17:03
*** lfa <lfa!~lfa@> has quit IRC17:05
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto17:09
*** berton <berton!~berton@> has quit IRC17:12
*** nighty- <nighty-!> has quit IRC17:20
*** awe00 <awe00!~awe00@unaffiliated/awe00> has quit IRC17:35
yoctiNew news from stackoverflow: Yocto recipe problem with scons and ws281x on Raspberry Pi 3B+ <>17:42
sveinsefbre: You're probably not here any longer, but using -linuxfb and -opengl does not work. "ERROR: Feature 'opengl' was enabled, but the pre-condition 'features.opengl-desktop || features.opengl-dynamic || features.opengles2' failed." So apparently -opengl isn't intended to be used with -linuxfb17:48
sveinse^ context is configuring Qt17:49
*** tprrt <tprrt!~tprrt@> has quit IRC17:53
*** tgraydon <tgraydon!textual@nat/intel/x-lbhqlcdopusfykok> has joined #yocto17:55
khemsveinse:yes it is not, for opengl you need driver to implement some form of gl17:58
halsteadarmpit, RP, rburton AB is coming back up and is ready for new work.18:03
armpitk, thanks18:04
*** gsalazar <gsalazar!> has quit IRC18:10
sveinsekhem: yeah, apparently. We were curious if Qt implemented a opengl renderer for linuxfb, and thus -opengl -linuxfb18:11
*** florian <florian!~florian_k@Maemo/community/contributor/florian> has quit IRC18:27
*** feddischson <feddischson!> has quit IRC18:47
*** destmaster <destmaster!> has joined #yocto18:50
*** destmaster <destmaster!> has quit IRC18:52
markapaulbarker: so I believe I have solved some of the mystery with the netns GO build18:55
markadefinitely not 100% yet though18:55
markait is related to
markawhen reading these, however, this should be an issue any longer18:56
markabut obviously it is, most likely since we are also mixing in cross compiling18:57
markaat any rate I can workaround the issue by adding a -pkgdir to the go build cmd18:57
markaas described in those links it is related to the build being performed differently than when the go std pkgs were built18:57
markaand like those discussions our situation was mapping to that, as with more verbose building I could see it seeking out runtime/cgo when it should never have been18:58
*** aidanh_ <aidanh_!~aidanh@unaffiliated/aidanh> has joined #yocto19:03
*** aidanh <aidanh!~aidanh@unaffiliated/aidanh> has quit IRC19:04
*** aidanh_ is now known as aidanh19:04
*** otavio <otavio!~otavio@debian/developer/otavio> has joined #yocto19:09
*** T_UNIX <T_UNIX!uid218288@gateway/web/> has quit IRC19:13
*** lexa_ <lexa_!~user@> has quit IRC19:14
markakhem: did you want me to expand my GOARM patch to cover more of the exports? or can I go ahead and resend what I have and work on the remainder in future work?19:15
* armpit GOARM sound like a sports team chant19:23
*** bluelightning <bluelightning!~paul@pdpc/supporter/professional/bluelightning> has joined #yocto19:26
markaI have had enough long days after sorting out GO quirks that I might have dreamed about something similar at some point19:31
*** rburton <rburton!> has quit IRC20:07
LetoThe2ndarmpit: unfortunately a very un-metal chant.20:11
*** chandana73 <chandana73!~ckalluri@> has joined #yocto20:11
*** dv_ <dv_!~dv@> has quit IRC20:23
*** dv_ <dv_!~dv@> has joined #yocto20:37
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC21:25
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto21:27
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC21:27
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has joined #yocto21:30
khemmarka: yes finish it once for all21:40
khemarmpit: goarm but there might be risk ;)21:41
armpitkhem, maybe, you got intel on that situation?21:49
* armpit maybe more power?21:49
* armpit SoC puns.. I am so sad21:52
*** georgem_home <georgem_home!uid210681@gateway/web/> has joined #yocto21:52
*** gaulishcoin <gaulishcoin!> has quit IRC21:58
*** AndersD_ <AndersD_!~AndersD@> has quit IRC22:05
khemarmpit: yeah22:07
*** BCMM <BCMM!~BCMM@unaffiliated/bcmm> has quit IRC22:46
*** ant_home <ant_home!> has joined #yocto23:09
*** chandana73 <chandana73!~ckalluri@> has quit IRC23:57

Generated by 2.11.0 by Marius Gedminas - find it at!