**** BEGIN LOGGING AT Thu Mar 29 03:00:04 2018
Mar 29 07:21:21 <jww> Hello !
Mar 29 07:50:46 <yocti> New news from stackoverflow: Is adding a distro name similar to a machine name to distrooverrides causes bitbake fail, as they are all added to the OVERRIDES <https://stackoverflow.com/questions/49550664/is-adding-a-distro-name-similar-to-a-machine-name-to-distrooverrides-causes-bitb>
Mar 29 07:54:30 <fberg> Hello guys ! I have an issue I can't solve.. I have built a library which install mylib.a and mylib.h to ${libdir}/mylib.a and ${includedir}/mylib.h; if I "ls" the /packages-split/mylib-dev/ and /packages-split/mylib-staticdev/ I note tha in mylib-dev there is only /usr/include/mylib.h and in mylib-staticdev there is only /usr/lib/mylib.a
Mar 29 07:55:06 <fberg> I've searched online which contents are associated to any package and it seems that: FILES_${PN}-dev
Mar 29 07:55:06 <fberg>     Development related files. Any headers, libraries and support files needed for development work on the target.
Mar 29 07:55:06 <fberg>     FILES_${PN}-dev = "\
Mar 29 07:55:06 <fberg>         ${includedir} \
Mar 29 07:55:06 <fberg>         ${libdir}/lib*.so \
Mar 29 07:55:06 <fberg>         ${libdir}/*.la \
Mar 29 07:55:07 <fberg>         ${libdir}/*.a \
Mar 29 07:55:07 <fberg>         ${libdir}/*.o \
Mar 29 07:55:08 <fberg>         ${libdir}/pkgconfig \
Mar 29 07:55:09 <fberg>         ${datadir}/aclocal"
Mar 29 07:55:14 <LetoThe2nd> fberg: dude... pastebin!
Mar 29 07:56:01 <fberg> so why mylib-dev does not ship mylib.a ?
Mar 29 07:56:04 <neverpanic> fberg: what you describe sounds exactly what it should be like
Mar 29 07:56:10 <neverpanic> why would it?
Mar 29 07:56:39 <fberg> I expected that the -dev package has both the library and its header
Mar 29 07:56:55 <fberg> LetoThe2nd: ?
Mar 29 07:56:58 <neverpanic> well, then your expectation seems wrong.
Mar 29 07:57:10 <LetoThe2nd> fberg: then what you expect does not match the convention openembedded uses.
Mar 29 07:57:23 <LetoThe2nd> fberg: for sharing snippets of code, please use a pastebint!
Mar 29 07:57:27 <LetoThe2nd> *pastebin
Mar 29 07:57:59 <fberg> oh ok, I'm a rookie
Mar 29 07:58:10 <fberg> please don't give me hard time :)
Mar 29 07:58:46 <fberg> The issue is that I haveanother recipe that uses packgconfig to check for some packages
Mar 29 07:59:07 <fberg> in such a case I will have to search for two packages instead of one
Mar 29 07:59:16 <neverpanic> if you try to build that within bitbake, packaging does not matter
Mar 29 07:59:36 <neverpanic> at a recipe level, bitbake only knows DEPENDS, which contains recipe names, not package names
Mar 29 07:59:52 <LetoThe2nd> yeah, things only become complicated once you try to compile in-target
Mar 29 07:59:54 <neverpanic> so all files installed by your mylib recipe will be available if you set DEPENDS="mylib"
Mar 29 08:01:32 <fberg> I've done so. y the way since the recipe that depends on mylib has a do_configure process that searches both mylib.h and mylib.a within a package it fails everytime
Mar 29 08:02:32 <LetoThe2nd> fberg: is that searching process by any chance something standard, or some custom hackery? in the latter, you'll probably be better off patching that.
Mar 29 08:02:39 <fberg> as far as I have understood I have either remove the check process and use depends only or check for two packages isntead of one
Mar 29 08:03:34 <fberg> LetoThe2nd: https://pastebin.com/Z1kRy7rB
Mar 29 08:03:57 <fberg> something like that
Mar 29 08:04:29 <LetoThe2nd> "something like that" or "actually that"?
Mar 29 08:04:31 <fberg> I search for a package that ships both .h and .a/.so
Mar 29 08:04:42 <fberg> is that but for a different package
Mar 29 08:05:13 <LetoThe2nd> sorry, but i don't get it. if you have everything under control, why not use something generic like pkg-config?
Mar 29 08:06:35 <LetoThe2nd> by reinventing all kinds of checking and magic, you're just wasting lots of time, for already solved problems.
Mar 29 08:08:01 <fberg> I have a recipe that needs mylib.a and mylib.h so I added DEPNDS="mylib" in this recipe.
Mar 29 08:08:20 <fberg> mylib.h and mylib.a are built with mylib_1.0.0.bb and packaged as mylib-dev and mylib-staticdev.
Mar 29 08:09:00 <fberg>  Since I thought that mylib-dev would ship both .a and .h I used https://pastebin.com/Z1kRy7rB in The CMakeFileLists.txt to check for such a package
Mar 29 08:09:47 <fberg> the package is found during the do_configure process but exit with error since it does'nt ships both .h and .a
Mar 29 08:16:06 <LetoThe2nd> fberg: seriously, this sounds like you are mixing up different concepts, like source-level dependencies, packages, recipes. my opinion is that your approach of checking for that library is plain false, and referring to libxml for the sake of hiding your own hacks does not help either. i strongly suggest you read up on pkg-config, make your "mylib" (that you are hiding too!) aware of it, and then just
Mar 29 08:16:12 <LetoThe2nd> use it as is.
Mar 29 08:16:35 <fberg> yup
Mar 29 08:16:40 <fberg> I think it too
Mar 29 08:17:18 <fberg> and I am sure I am mixing up.. I'm pretty new to the world . your helo is really appreciated
Mar 29 08:17:23 <fberg> help
Mar 29 08:19:25 <fberg> I used the libxml as reference so it's the same but with libjsmn instead
Mar 29 08:20:07 <LetoThe2nd> fberg: libxml2 is a bad reference/example for about everything. do never, ever use it as a blueprint.
Mar 29 08:20:22 <fberg> ops.. guilty
Mar 29 09:14:21 <linux_gamer> hi @ all, I am trying to build an image with qemuarm and use a cortexa9hf (ARM7) but i always get a kernel panic on startup
Mar 29 09:15:03 <LetoThe2nd> linux_gamer: cortexa9hf != ARM7, certainly.
Mar 29 09:15:46 <linux_gamer> any supported board with amr7?
Mar 29 09:15:52 <linux_gamer> imx6 eg
Mar 29 09:16:22 <LetoThe2nd> i guess you are mixing up ARM7 and ARMv7-A, which are completely different things.
Mar 29 09:16:35 <LetoThe2nd> and no, as far as i know there is no qemu target for imx6
Mar 29 09:16:50 <linux_gamer> i meant ARMv7-A
Mar 29 09:17:17 <LetoThe2nd> well qemu won't run an imx6 kernel+dtb
Mar 29 09:18:45 <linux_gamer> any chance to get binary compatible?
Mar 29 09:18:49 <LetoThe2nd> no
Mar 29 09:19:14 <linux_gamer> file outputs the same but im obviosly missing neon and v7 features
Mar 29 09:19:26 <LetoThe2nd> qemu does not emulate imx6 and its peripherals, so it will not be binary compatible
Mar 29 09:20:17 <LetoThe2nd> you can try to create a ARMv7-A qemu to test binaries that are *NOT* relying on imx6 specific hardware
Mar 29 09:20:40 <linux_gamer> yes thats my point
Mar 29 09:20:50 <linux_gamer> no graphics audio eg
Mar 29 09:21:45 <LetoThe2nd> well then look at https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/conf/machine/qemuarm.conf
Mar 29 09:21:56 <linux_gamer> but best i can get running via qemu ist the standard qemuarm (v5)
Mar 29 09:22:16 <LetoThe2nd> dreive your own machine form it, maybe something vexpress-v8 orwhatsitcalled
Mar 29 09:23:16 <linux_gamer> i have the software running on imx6 already, but i would like to test the software via qemu
Mar 29 09:24:09 <linux_gamer> such that it can be done via CI
Mar 29 09:24:10 <LetoThe2nd> like i said, create your custome qemu machine that fits your needs. the hints are all there in qemuarm.conf and qemuarm64.conf
Mar 29 09:24:53 <linux_gamer> I got to the point where it was all built
Mar 29 09:26:06 <linux_gamer> starting it up is the next issue, as it uses wic vic and some other features
Mar 29 09:27:57 <linux_gamer> if it builds with the qemu.inc with no errors I will be able to get it running by qemu-start-arm with the right commands, or are there any other limitations?
Mar 29 09:28:20 <LetoThe2nd> it depends(TM)
Mar 29 09:29:10 <linux_gamer> but its worth a try?
Mar 29 09:29:35 <LetoThe2nd> it is always worth a try, even if its just for the sake of failing and learning.
Mar 29 09:29:56 <linux_gamer> your getting philosophical
Mar 29 09:30:16 <LetoThe2nd> \o/
Mar 29 09:31:09 <LetoThe2nd> well what do you expect? "i have something that runs on imx6, and not i want to ci-test it on qemu. will that work"
Mar 29 09:31:17 <LetoThe2nd> s/not/now/
Mar 29 09:31:51 <LetoThe2nd> unless you're willing to share considerably more details, the answer can only be "go ahead and try."
Mar 29 09:33:31 <linux_gamer> what type of info do you need?
Mar 29 09:34:23 <linux_gamer> I can try to strip it as far as possible but the other issue is still pending
Mar 29 09:34:45 <LetoThe2nd> well the point is if that ominous thing does rely on certain hardware or architecture features - and what you actually want to test.
Mar 29 09:35:27 <linux_gamer> i just dont get a stable qemuarm with v7-a
Mar 29 09:35:44 <LetoThe2nd> i mean, if you want to go cycle accurate for example, ARM will sell you models to emulate certain cpu cores.
Mar 29 09:35:49 <linux_gamer> thats probably my most important point
Mar 29 09:36:29 <LetoThe2nd> no, you're interpreting it backwards. you have a stable qemu, but no kernel that matches it.
Mar 29 09:37:46 <linux_gamer> no i really dont get my qemu running with cortexa9thf-neon eg
Mar 29 09:39:29 <LetoThe2nd> your qemu is most probably running fine, and the kernel that you want to boot *inside* it panics, right?
Mar 29 09:39:37 <linux_gamer> yes
Mar 29 09:39:43 <linux_gamer> its the std yocto
Mar 29 09:40:10 <LetoThe2nd> and as yocto does not provide a "standard" kernel for cortexa9....
Mar 29 09:40:17 <linux_gamer> ok
Mar 29 09:40:48 <LetoThe2nd> so again, for your testing purposes you have to create your own machine. INCLUDING a fitting kernel, and its configuration.
Mar 29 09:40:56 <linux_gamer> so there is no chance to work bottom-up via stable qemu to my dev qemu
Mar 29 09:41:21 <linux_gamer> ok i got that, but clearly its not configured for qemu in the first hand
Mar 29 09:41:28 <LetoThe2nd> *SIGH*
Mar 29 09:41:53 <LetoThe2nd> the qemuarm kernel of yocto is configured for the exacty qemu configuration of yocto. things match.
Mar 29 09:42:07 <LetoThe2nd> if you want to change one, you have to match the other too.
Mar 29 09:43:15 <LetoThe2nd> if its actually only the floating point stuff that you need, maybe just use qemuarm64?
Mar 29 09:43:44 <linux_gamer> assuming i have the stable image built by yocto i "just" have to set the right parameters when starting qemu or?
Mar 29 09:43:49 <linux_gamer> the 6
Mar 29 09:44:06 <LetoThe2nd> you're always leaving out details!
Mar 29 09:44:26 <LetoThe2nd> "i have a stable image built by yocto" built for what? which machine? which configuration?
Mar 29 09:44:30 <linux_gamer> i tried that but our devs didnt work properly to port it from m32 to 64
Mar 29 09:45:05 <linux_gamer> for a custom imx6 based prop board
Mar 29 09:46:15 <linux_gamer> all in house components would have to be reworked as the devs didnt care about int lengths
Mar 29 09:49:06 <LetoThe2nd> ok. in a nutshell. "qemu will not run the imx6 image."
Mar 29 09:49:22 <linux_gamer> yes
Mar 29 09:49:50 <LetoThe2nd> in a nutshell part 2: "qemu will run an image built for qemu"
Mar 29 09:49:58 <linux_gamer> yes
Mar 29 09:50:21 <LetoThe2nd> so conclusion: "create your own qemu and kernel configuration that fits your needs, build the image for it and run it"
Mar 29 09:50:26 <LetoThe2nd> i can't put it into other words.
Mar 29 09:50:49 <linux_gamer> y
Mar 29 09:52:01 <linux_gamer> my try was to include the qemu.inc into the custom machine conf and try to startup the system by reproducing runqemu mymachine
Mar 29 09:53:02 <LetoThe2nd> which is basically correct.
Mar 29 09:53:18 <LetoThe2nd> but you also have to provide a proper kernel configuration.
Mar 29 09:54:54 <linux_gamer> to make it more simple i should use ext4 or is configuring vic not more complicated?
Mar 29 09:55:18 <linux_gamer> as i am currently build the system to be flashable to hw
Mar 29 09:55:55 <LetoThe2nd> for running qemu, ext4 or something comparable is certainly easier
Mar 29 09:56:40 <linux_gamer> ok, i will find someone to tell me what ciomponents to remove
Mar 29 09:57:49 <linux_gamer> thanks for your help so far!
Mar 29 09:58:00 <LetoThe2nd> have fun
Mar 29 10:00:35 <linux_gamer> ty
Mar 29 10:21:21 <yocti> New news from stackoverflow: Gstreamer on Yocto <https://stackoverflow.com/questions/49553103/gstreamer-on-yocto>
Mar 29 10:51:59 <fberg> ouffffffff
Mar 29 10:52:39 <fberg> I'm full
Mar 29 10:57:12 <pk> HELP
Mar 29 11:21:32 <yocti> New news from stackoverflow: Building keras and tensor flow on yocto <https://stackoverflow.com/questions/49357422/building-keras-and-tensor-flow-on-yocto>
Mar 29 12:49:22 <peacememories> hi everyone
Mar 29 12:51:03 <peacememories> when building with the machine "genericx86_64" the final image has a grub menu with a boot and an install option. when i use the install option the installed image has a different grub image with only a boot option. i would like to modify both menus for my image. the first should automatically select "install" and the second should not appear at all^^
Mar 29 12:51:35 <peacememories> can anyone point me in the direction of some documentation on how to do that?
Mar 29 12:51:51 <yocti> New news from stackoverflow: pcie dtsi memory size <https://stackoverflow.com/questions/49556260/pcie-dtsi-memory-size>
Mar 29 12:52:27 <peacememories> generally, i have no idea how to change system configuration for an image
Mar 29 12:58:37 <RP> zeddii, zeddii_home: around?
Mar 29 12:59:03 <zeddii> yup
Mar 29 13:00:23 <RP> zeddii: Looking at this objtool error. I think its something a bit different/new :/
Mar 29 13:01:01 <RP> zeddii: I have found a way to fix it, specifically to do "make prepare" as well as "make scripts" in make-mod-scripts
Mar 29 13:01:13 <RP> and kernel-devsrc needs a tweak to fix it there too
Mar 29 13:02:30 <zeddii> aha. I've just been ignoring it so far. and I turned stack validation off :D
Mar 29 13:02:38 <zeddii> which devsrc ?  the old and crappy, or the new ?
Mar 29 13:02:48 <zeddii> I don't want to touch the old and crappy if possible :D
Mar 29 13:02:55 <RP> zeddii: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip2&id=44461e02eb578b43e2955590e8f2dbb96247d760
Mar 29 13:03:11 <RP> zeddii: ignoring it sadly isn't an option :(
Mar 29 13:04:08 <RP> zeddii: the devsrc thing is a bit of a bug as the generated binaries won't work on target :/
Mar 29 13:04:38 <RP> zeddii: in fact I just realised I'm running on qemux86_64 which won't trigger arch mismatch warnings but I bet it does on another arch
Mar 29 13:05:10 <RP> zeddii: We can hit it by deleting objtool artefacts in devsrc
Mar 29 13:05:25 <zeddii> not sure I'm following. the patch looks ok. but where are you getting binaries in your devsrc package ?
Mar 29 13:05:47 <RP> zeddii: ERROR: kernel-devsrc-1.0-r0 do_package_qa: QA Issue: non debug package contains .debug directory: kernel-devsrc path /work/qemux86_64-poky-linux/kernel-devsrc/1.0-r0/packages-split/kernel-devsrc/usr/src/kernel/tools/objtool/.debug/objtool
Mar 29 13:06:20 <RP> zeddii_home: I'd guess _mrproper_scripts now triggers it
Mar 29 13:06:41 <zeddii> again. is that with old devsrc or my re-worked one ?
Mar 29 13:06:51 <RP> zeddii: old one
Mar 29 13:07:01 <RP> zeddii: thought that was clear with the recipe
Mar 29 13:07:05 <zeddii> yah. I don't have it in my tree anymore. I have my new one.
Mar 29 13:07:06 <RP> er, patch
Mar 29 13:07:13 * zeddii isn't touching the old one anymore
Mar 29 13:07:22 <RP> zeddii: that is all well and good but I don't have that in master
Mar 29 13:07:37 <zeddii> putting more tape on it isn't the solution either.
Mar 29 13:08:01 <zeddii> there was that one multlib error, and I never did get a setup to reproduce the problem. so I can't solve that one last error on the new devsrc.
Mar 29 13:08:05 <RP> zeddii: if we got the other one in before feature freeze, fine. We didn't so it will have to do for 2.5
Mar 29 13:08:38 <RP> zeddii: I will just have to figure out a bandaid for this. I really wanted to switch :/
Mar 29 13:21:15 <RP> zeddii: when you say you didn't get a setup, you mean you need instructions to reproduce?
Mar 29 13:21:46 <peacememories> hmm... i created my own machine based on genericx86-64 but now all linux recipes are not compatible with my machine anymore :/
Mar 29 13:21:58 <peacememories> do i need to define my own kernel provider?
Mar 29 13:25:53 <zeddii> RP. yah. I tried to reverse engineer the config but when I built I didn't get a failure. and now, I can't even find the email I sent asking about the setup .. so I'm wondering if I just imagined sending it :(
Mar 29 13:26:29 <RP> zeddii: Its the kind of thing I'd have tried to provide had I seen one... :/
Mar 29 13:26:39 <RP> equally I'm drowning in mail
Mar 29 13:28:04 <RP> zeddii: better version of the fix: http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip2&id=849d9da2ae9426dbfac866304616fd074d0eb2fb
Mar 29 13:28:12 <zeddii> no doubt . and I bounce between gmail and windriver, which causes me pain as well. I'm going to keep looking
Mar 29 13:29:05 <RP> zeddii: you did ask on 15/3/18
Mar 29 13:29:07 <zeddii> RP: indeed. that one makes sense. my new devsrc has that same objtool copy, so clearly I need to fix that as well. but oddly, it did survive testing on all arches.
Mar 29 13:30:32 <zeddii> but I was making a -dbg package in the new devsrc, so I imagine that was picking up the objtool and saving me.
Mar 29 13:31:26 <RP> zeddii: right, I'm surprised the -dbg wouldn't break on != x86-64
Mar 29 13:31:33 <RP> zeddii: Just replied about the config
Mar 29 13:32:10 <RP> zeddii_home: not sure how a 32 bit machine is meant to run 64 bit binaries mind :/
Mar 29 13:32:27 <RP> zeddii_home: there is a multilib problem with devsrc though regardless
Mar 29 13:33:00 <zeddii> agreed. and I can now add that to my tests, so it won't cause us pain on the way into 2.6
Mar 29 13:33:50 <RP> zeddii: fwiw, these are all our test configs: http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder-helper/tree/config.json
Mar 29 13:34:02 <zeddii> ahaha. I'm bookmarking that.
Mar 29 13:34:22 <RP> zeddii: http://git.yoctoproject.org/cgit.cgi/yocto-autobuilder-helper/tree/config.json#n317 is the one that fails
Mar 29 13:34:37 <RP> zeddii: new AB code is much more readable
Mar 29 13:35:17 <zeddii> but painful to get into that shape I bet ;) that config.json is easy to read. very nice.
Mar 29 13:35:45 <RP> zeddii: worlds of pain to extract this but very worthwhile and has highlighted a ton of bugs in the test configs!
Mar 29 13:35:58 * RP has faithfully reproduced them with a plan to clean up in 2.6
Mar 29 13:36:40 <zeddii> I'll whip devsrc into shape using that as a guide. I have to stop copying objtool in as well
Mar 29 13:36:48 * zeddii does that now (the objtool part), or I'll forget.
Mar 29 13:39:15 <RP> zeddii: there is a script in that repo which will generate a local.conf for you too
Mar 29 13:40:39 <RP> zeddii: "./setup-config nightly-multilib 4 /tmp/foo master poky None None"
Mar 29 13:41:00 <RP> zeddii: interface is ugly right now but will improve
Mar 29 13:41:21 <zeddii> aha. now that sounds useful. I'll clone the repo onto my builder so I can give it a spin.
Mar 29 13:41:44 <zeddii> well, my 4 year old local.conf and bblayers.conf hacked all to bits with commented out sections .. aren't exactly elegant :D
Mar 29 13:41:50 <RP> zeddii_home: you'll see what I mean about some paths it adds but it also easily fixed
Mar 29 13:42:33 <RP> zeddii_home: the above just generates local.conf and sdk-extra.conf, there are other scripts which can do bblayers.conf too
Mar 29 13:43:00 <RP> zeddii: so -c testimage also fails with objtool issues, unsurprisingly :(
Mar 29 13:43:35 * RP tests a fix
Mar 29 13:43:39 <zeddii> ah. is that the on-target 'hellomod
Mar 29 13:43:49 <RP> zeddii: yes
Mar 29 13:44:34 <zeddii> on my 4.14 image I had built this morning, I did try the make ARCH=x86 scripts prepare, and was able to build the module at least.
Mar 29 13:44:52 <zeddii> but I suppose. I don't have the devsrc without it.
Mar 29 13:57:51 <RP> zeddii: Ok for me to send out http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/wip2&id=0c14d253cc3e36a9712c35ad5ef7c3a83d52cc11 ?
Mar 29 14:03:44 <zeddii> definitely. I can send an Acked-by as well, so it'll be archived forever :D
Mar 29 14:04:11 <fberg> hello guys. I'm compiling a recipe that uses aravis. I've added aravis to "DEPENDS" by the way the compilatin process exits with error since arv.h is not found
Mar 29 14:04:16 <RP> zeddii sent
Mar 29 14:04:59 <RP> fberg: perhaps that recpie isn't looking in the correct place for it? perhaps you need to pass some configure option for example?
Mar 29 14:05:40 <fberg> arv.h is shipped by aravis and I can find it in Cloud4Drones/1.0.0-r0/recipe-sysroot/usr/include/aravis-0.6/
Mar 29 14:06:41 <fberg> RP: I'm trying to figure it out
Mar 29 14:07:01 <RP> fberg: so you need to add the aravis-0.6 part to the include search paths
Mar 29 14:07:16 <fberg> if i cat Cloud4Drones/1.0.0-r0/recipe-sysroot/usr/lib/pkgconfig/aravis-0.6.pc
Mar 29 14:07:17 <RP> it won't look there by dfault
Mar 29 14:07:46 <fberg> i get this: https://pastebin.com/1gzMrfPC
Mar 29 14:08:06 <RP> TARGET_CFLAGS += "`pkg-config aravis-0.6 --cflags"  might help but usually configure takes care of things like this
Mar 29 14:08:12 <RP> something like that anyway
Mar 29 14:09:23 <fberg> The main recipe is using cmake, so I have added "inherit cmake pckgconfig"
Mar 29 14:09:34 * RP knows little about cmake
Mar 29 14:09:49 <fberg> RP:  thank you
Mar 29 14:10:21 <fberg> what do you man for:  usually configure takes care of things like this
Mar 29 14:12:32 <RP> fberg: not relevant if its cmake
Mar 29 14:16:07 <fberg> RP: oki, thanks
Mar 29 14:16:42 <otavio> Is someone capable of reproduce https://bugzilla.yoctoproject.org/show_bug.cgi?id=12631 ? It seems to happen in hardfp machines only
Mar 29 14:16:44 <yocti> Bug 12631: critical, Undecided, ---, raj.khem, NEW , Go 1.10 generates invalid code
Mar 29 14:33:24 <nayfe> Do you know any small network switch where you can remotly enable/disable POE?
Mar 29 14:34:29 <nayfe> otavio: is there any HOWTO to reproduce ?
Mar 29 14:36:05 <otavio> In the bug itself there is a recipe
Mar 29 14:36:09 <otavio> nayfe:
Mar 29 14:36:36 <nayfe> https://gist.github.com/gustavosbarreto/38216d2c50f9af589b91989dbc9916f3
Mar 29 14:37:31 <otavio> yes
Mar 29 14:39:54 <nayfe> and then, you have to launch something on target board?
Mar 29 14:41:28 <nayfe> otavio: sorry for stupid questions, GO stuff makes my brain to collapse
Mar 29 14:52:19 <yocti> New news from stackoverflow: how to solve ldflags error in yocto <https://stackoverflow.com/questions/49558653/how-to-solve-ldflags-error-in-yocto>
Mar 29 14:56:32 <RP> vmeson: https://wiki.yoctoproject.org/charts/combo.html
Mar 29 14:58:44 <aratiu> i see oe-core has a quite a number of musl specific patches in the systemd recipe which are marked as upstream pending, i fixed a segfault and have another patch which i've sent to systemd upstream but they flat out refuse to support non-glibc systems
Mar 29 14:59:01 <aratiu> so my question is: what's the plan with those patches?
Mar 29 15:00:14 <aratiu> the response to my patch in case you're curious https://lists.freedesktop.org/archives/systemd-devel/2018-March/040599.html
Mar 29 15:01:50 <Crofton|work> ah Lennart always helpful
Mar 29 15:08:52 <Crofton|work> khem, ^^^
Mar 29 15:22:15 <khem> aratiu: I think you might want to prove the case that in general the issue is present, otherwise it will be difficult to convince
Mar 29 15:22:26 <yocti> New news from stackoverflow: Yocto: how to add out-of-tree Device driver? <https://stackoverflow.com/questions/49559438/yocto-how-to-add-out-of-tree-device-driver>
Mar 29 15:24:08 <seebs> i have confirmed that my syscall wrapper appears to do what i want, yay.
Mar 29 15:26:45 <seebs> huh. is there an actual bugzilla entry for the FC27/renameat2 thing?
Mar 29 15:27:10 <seebs> Anyway, RP/rburton/whoever, I have pushed a fix to master that PROBABLY fixes that, but since I don't have an affected system, I'm not totally sure.
Mar 29 15:34:17 <JPEW> seebs: I'll give it a try
Mar 29 15:34:38 <JPEW> seebs: Have a link?
Mar 29 15:36:14 <RP> seebs: great, I will pull it in and try some tests! thanks!
Mar 29 15:40:25 <seebs> should be in the yocto project git server now. It's pretty trivial; if SYS_renameat2 is defined, fail with ENOSYS.
Mar 29 15:40:54 <seebs> Should probably make it a subport that only shows up if SYS_renameat2 is defined at all, but I first want to verify that it even works.
Mar 29 15:41:20 <seebs> And also develop some kind of setup for allowing configure to enable or disable ports, so you can override that choice later.
Mar 29 15:51:01 <RP> seebs: right, I should be able to test this out on our f27 worker
Mar 29 16:00:07 <seebs> good luck!"
Mar 29 16:37:00 <dnm> hi
Mar 29 16:37:15 <dnm> i live some problem durin bitbake build
Mar 29 16:37:30 <dnm> where can i get help
Mar 29 16:37:34 <AbleBacon> here
Mar 29 16:38:29 <dnm> how i will share my log files
Mar 29 16:38:35 <dnm> publicly
Mar 29 16:38:39 <AbleBacon> also #oe
Mar 29 16:38:43 <AbleBacon> idk. pastebin?
Mar 29 16:43:15 <RP> zeddii: now make-mod-scripts fails in the world build :/
Mar 29 16:51:22 <RP> zeddii: think I'll have to figure out how to blacklist that
Mar 29 17:05:29 <zeddii_home> well bugger.
Mar 29 17:06:36 <otavio> nayfe: you can call the go-crazy app
Mar 29 18:35:35 <khem> https://github.com/gokrazy/gokrazy
Mar 29 18:39:10 <khem> there are purists everywhere
Mar 29 19:05:08 <fischerm> hah
Mar 29 19:05:23 <tlwoerner> khem: C is doomed!!
Mar 29 19:13:14 <fischerm> khem: I know I still owe patches ...
Mar 29 19:13:16 * fischerm hides
Mar 29 19:14:45 <JPEW> seebs: I'm getting a lot of very strange errors with the renameat2 patch on FC27
Mar 29 19:22:22 <JPEW> Pretty much every do_install fails with something like: https://pastebin.com/DJzNSTW0
Mar 29 19:35:27 <majuk> I just got here, but it looks like you'
Mar 29 19:35:33 <majuk> re missing some tools. sed, xargs
Mar 29 19:38:38 <JPEW> majuk: Ya, I'm testing seebs pseudo changes for Fedora 27 :)
Mar 29 19:39:01 <majuk> Ah, ok, I figured that was too obvious to be a root problem. :D
Mar 29 19:57:07 * moto-timo prays for JPEW
Mar 29 19:57:22 <moto-timo> makes my head hurt seeing all those dang warnings
Mar 29 20:48:27 <rozachar> i am trying to unpack an .iso file , can't seem to find where the unpacking is done in bitbake is the code in the poky repo?
Mar 29 20:49:28 <neverpanic> it's in the bitbake repo
Mar 29 20:49:57 <neverpanic> http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/bitbake/lib/bb/fetch2 would be the correct place
Mar 29 20:55:19 <seebs> oooh weird
Mar 29 20:55:36 <seebs> that is a fascinatingly strange failure mode that makes no sense to me at all
Mar 29 20:55:56 <seebs> I did verify that it worked for a trivial test case of syscall(SYS_getpid), but didn't verify much past that.
Mar 29 20:56:35 <seebs> I can't immediately see how pseudo could cause sed/xargs not to be found, but it's totally possible.
Mar 29 21:03:06 <JPEW> seebs: Ya, it really surpised me too. I though I had really borked something, but as soon as I backed out the pseudo change it worked fine
Mar 29 21:06:37 <JPEW> Where do __builtin_apply and __builtin_return come from in the pseudo code?
Mar 29 21:07:20 <tlwoerner> JPEW: the gcc library?
Mar 29 21:07:50 <fray> seebs, remember early on we found a functiont hat pseudo had that sed or gawk or something also had one of the same name.. so it was calling 'the wrong one'
Mar 29 21:07:51 <JPEW> Possible? I didn't find documenation for them.... I perhaps did not look hard enough
Mar 29 21:08:45 <JPEW> Yep. I fail at google: https://gcc.gnu.org/onlinedocs/gcc/Constructing-Calls.html
Mar 29 21:10:05 <seebs> Weeeird.
Mar 29 21:10:38 <seebs> And yeah, gcc builtins. I trust them slightly more than I'd trust hand-written code, and it's much more likely to fail cleanly if someone tries an incompatible compiler, say.
Mar 29 21:11:13 <seebs> d'oh
Mar 29 21:11:34 <seebs> well, it shouldn't affect anything, but the commit was botched and still had a partial implementation of renameat2 in it, which it shouldn't have.
Mar 29 21:11:46 <seebs> not that it would *do* anything, because it's unused, but it shouldn't be there.
Mar 29 21:13:15 <RP> seebs: Juro just tried using pseudo master and found problems with one of the recent changes
Mar 29 21:13:34 <RP> seebs: he's sent mail
Mar 29 21:13:38 <seebs> 'k.
Mar 29 21:14:17 <seebs> There's definitely some stuff in there I'm not fully confident of and have not gotten to test.
Mar 29 21:17:30 <seebs> ohh, JPEW: possible science, try it without the slightly older path-handling thing, which is apparently broken also.
Mar 29 21:17:36 <seebs> If you didn't already.
Mar 29 21:17:53 <seebs> And I'll try to figure out the path handling bug.
Mar 29 21:18:40 <JPEW> K, will do
Mar 29 21:18:59 <seebs> possibly not today, though.
Mar 29 21:24:04 <JPEW> Hmm, devtool doens't like me editing pseudo-native: Task do_populate_sysroot_setscene in .../dbus_1.12.2.bb depends upon non-existent task do_populate_sysroot_setscene in virtual:native:.../pseudo_git.bb
Mar 29 21:25:17 <seebs> confirmed, the sed/xargs bug is that previous commit.
Mar 29 21:25:57 <seebs> i think you might be able to just make a local patch that's an inverse of the diff from that commit.
Mar 29 21:26:36 <JPEW> Ok, I did that. Iooks like it is working now
Mar 29 21:45:39 <yates> will morty run right in fedora 26?
Mar 29 21:45:45 <yates> i know it won't in f27
Mar 29 21:45:51 <yates> and it does in f25
Mar 29 21:47:22 <RP> zeddii_home: https://autobuilder.yocto.io/builders/nightly-world/builds/890/steps/BuildImages/logs/stdio - I think its a race :(
Mar 29 21:47:32 <JPEW> yates: I build morty in FC27. I've backported a few things....
Mar 29 21:48:04 <yates> JPEW: which things?
Mar 29 21:48:15 <yates> python?
Mar 29 21:49:19 <JPEW> yates: No system tools like that, stuff like externalsrc patches mostly.... it always seem to break on me :) I can get you a list, but I have to go home soon
Mar 29 21:52:12 <yates> JPEW: i would appreciate a list very much.
Mar 29 21:52:30 <yates> would it be too much to ask? could you email it to me at yates@ieee.org?
Mar 29 21:53:19 <JPEW> yates: Sure. Might be a few days
Mar 29 21:53:48 <yates> i can always ask for my money back... :)
Mar 29 21:56:22 <RP> zeddii_home: think I figured out a fix...
Mar 29 21:57:44 * zeddii_home looks
Mar 29 21:58:06 <zeddii_home> the bloody recipe was supposed to fix a lot of those races. grrr.
Mar 29 21:58:06 <JPEW> yates: You are in luck, git never cease to amaze me with its ability to filter things
Mar 29 22:00:57 <seebs> Okay, so, sounds like the actual problem triggering those is the path thing, which... Well, it's horrible code and I don't trust it.
Mar 29 22:01:12 <seebs> I'll see if I can track it down, probably tomorrow?
Mar 29 22:11:40 <RP> zeddii_home: I posted a patch
Mar 29 22:13:46 <zeddii_home> dear lord. I never would have figured that out.
Mar 29 22:19:25 <rozachar> does bitbake have some way of dealing with archives that have read-only directories.  I have a recipe where I am unpacking directories with read-only directorys ( it came from a cd).  but when i do cleansstate on the recipe i get errors because it is not able to delete files in ro directories
Mar 29 22:21:16 <kergoth> rozachar: bitbake doesn't, but you can easily deal with it in the recipe.
Mar 29 22:21:36 <kergoth> fixup_perms () { chmod -R u+w "${S}" }; do_unpack[postfuncs] += "fixup_perms"
Mar 29 22:21:39 <kergoth> (untested)
Mar 29 22:22:19 <rozachar> thanks
Mar 29 22:22:59 <yates> ok, time to go for me. JPEW plese email details so I can read later this weekend, please?
Mar 29 22:23:11 <kergoth> np
**** ENDING LOGGING AT Fri Mar 30 03:00:01 2018