**** BEGIN LOGGING AT Wed Jul 20 02:59:58 2016
Jul 20 06:20:47 <akoc> Hi all, When building for yocto. I get This error. How the I solved this problem  https://anotepad.com/notes/arjixe
Jul 20 06:57:33 <boucman_work1> morning
Jul 20 07:16:06 <boucman_work1> akoc: yocto is trying to apply a patch to something and it's failing... probably because the patch process is not run in the proper directory
Jul 20 07:16:35 <boucman_work1> when compiling libpng in native format
Jul 20 07:17:05 <boucman_work1> it's hard to tell more from that single error... did you add that patch yourself ?
Jul 20 07:31:09 <akoc_> boucman_work1:  How can I do this operation ? I have no idea in this life
Jul 20 07:40:52 <boucman_work1> hmm, ok, let's start at the beggining.. what version of yocto are you using, what architecture ?
Jul 20 07:43:13 <akoc_> boucman_work1: I have a freesclae sabre automotive i.mx6q architecture.
Jul 20 07:47:31 <boucman_work1> I don't have that patch on master, do you know what version of poky the fsl bsp is based on ?
Jul 20 07:53:43 <akoc_> boucman_work: I used the fsl-image-gui. I used the command 'bitbake fsl-image-gui' for build,
Jul 20 07:55:56 <boucman_work> akoc_: if you go in /home/beagle/fsl-release-bsp/sources/ and run "git status" it should give you a clue on what branch it's based on
Jul 20 07:56:16 <boucman_work> but bsp tend to be old, so that bug might have been corrected ages ago...
Jul 20 07:59:59 <akoc_> I understand. I will try. Have you had a version of your advice
Jul 20 08:35:17 <boucman_work> rburton: around ?
Jul 20 08:57:15 <akoc> boucman_work: I sory boucman. restoring of summer are gone you send back page
Jul 20 08:58:01 <boucman_work> I don't understand what you say
Jul 20 08:59:07 <akoc> I accidently reload the page can you resend what you wrote
Jul 20 09:00:49 <boucman_work> akoc_: if you go in /home/beagle/fsl-release-bsp/sources/ and run "git status" it should give you a clue on what branch it's based on
Jul 20 09:00:57 <boucman_work> but bsp tend to be old, so that bug might have been corrected ages ago...
Jul 20 10:08:31 <sveinse> Is the sh construct "for f in dir;  echo ${f}" safe in recipes, or will bb take over ${f} ?
Jul 20 10:20:26 <berlin> while probing my touch screen i am getting dmesg as "Unable to request touchscreen IRQ" and "edt_ft5x06: probe of 2-0039 failed with error -22".what this mean!
Jul 20 10:57:25 <sveinse> My Qt application fails, because it requests libfoo.so. And due to Qt policy, this is now moved into the -dev package. My Qt devs say, but the .so file is the one Qt needs. So how can I remedy this? Install -dev on the target image?
Jul 20 10:57:39 <sveinse> *due to Yocto policy
Jul 20 10:58:00 <sveinse> It feels like something is off here
Jul 20 11:10:05 <rburton> is libfoo.so a real library that is unversioned, or a symlink to a versioned library
Jul 20 11:10:20 <sveinse> rburton: symlink to a versioned lib
Jul 20 11:11:09 <rburton> so is the application opening a .so directly because its stupid, or because it shouldn't be versioned and someone is too lazy to unversion it
Jul 20 11:11:20 <rburton> either way, if its meant to be in PN and not PN-dev, fix FILES to do that
Jul 20 11:11:31 <sveinse> I'm being told that Qt can't control getting a versioned lib. It looks for the .so, and this is not Qt's fault, its linux
Jul 20 11:11:51 <sveinse> rburton: Yeah, I used to have it in FILES, but QA complains a lot.
Jul 20 11:11:56 <rburton> yeah its not linux's fault
Jul 20 11:12:25 <sveinse> I'm just the messenger (stuck between a rock and a hard place) :P
Jul 20 11:12:28 <rburton> yeah you'll get warnings for putting what looks like a development .so symlink in PN, so use INSANE_SKIP
Jul 20 11:12:46 <rburton> if its a loadable module and should be installed as a .so file, then turning off versioning is trivial
Jul 20 11:13:08 <rburton> (and stops all the warnings from our build system telling you that you're doing something that is unusual)
Jul 20 11:13:17 <sveinse> its Qt we're talking about :P
Jul 20 11:14:28 <sveinse> I know they do things differently than what Yocto expects/wants, ref the previous discussions about Qt and crossbuilding
Jul 20 11:14:37 <rburton> s/yocto/linux/ :)
Jul 20 11:15:18 <sveinse> yeah, still, it's out of my reach to evangelize to the Qt community
Jul 20 12:02:23 <sveinse> Our app requires java to compile. How do I specify that in DEPENDS?
Jul 20 12:02:49 <sveinse> (and it works without specifying anything, so I suppose the host tools are leaking into the build here)
Jul 20 12:03:23 <rburton> yes, the host paths are available in the builds, as otherwise you'd have the bootstrap problem of "how to build make without make" :)
Jul 20 12:03:39 <sveinse> yes
Jul 20 12:03:54 <rburton> the best solution is to use meta-java and depends on a native jdk there, so you control the jdk you build with and run with on target
Jul 20 12:03:57 <sveinse> so, is it ok to depend on host java like this then?
Jul 20 12:04:24 <rburton> you can depend on host java if you want, but you can't express that as a dependency and what java are you using on the target?
Jul 20 12:04:50 <sveinse> No java on target, its for code generation only
Jul 20 12:07:42 <rburton> sveinse: then your choice - depending on host java works if you document it
Jul 20 12:07:56 <sveinse> rburton: ok. thanks
Jul 20 12:09:04 <boucman_work> rburton: http://pastebin.com/byX8NaMT <= my attempt at allowing override of noexec
Jul 20 12:09:30 <boucman_work> but i'm not a python programmer so i'd be happy to hear about a better way to test for truth in python than comparing to "0"
Jul 20 12:10:04 <boucman_work> (and are bitbake patches welcomed on the oe-core or does bitbake have its own mailing list ?)
Jul 20 12:10:15 <rburton> bitbake has its own list
Jul 20 12:10:25 <rburton> i'd post it with a nice commit message and see what rp/kergoth say
Jul 20 12:10:29 <boucman_work> ok, i'll have to subscribe then...
Jul 20 12:11:24 <sveinse> boucman_work: (I am a py programmer): I think you could have "if not isFlag or deptask" in line 16. It depends if deptask is literally a string with "0" or int(0)
Jul 20 12:11:31 <boucman_work> i'll wait to see if I can get some feedback here when they are around...
Jul 20 12:11:33 <rburton> its a string
Jul 20 12:11:42 <boucman_work> it's a string
Jul 20 12:11:54 <rburton> there is a function to handle various strings that are bool-like but that might be overkill considering this is always 0/1
Jul 20 12:11:59 <boucman_work> but i'd gladly have a function that check for "true" "True" "1" etc...
Jul 20 12:12:00 <RP> boucman_work: you know you can do d.delVarFlag(XXX, 'noexec') right?
Jul 20 12:12:25 <boucman_work> RP: yes, but that can't be done in a config file without using python {}
Jul 20 12:12:35 <boucman_work> that's how I do it locally right now.
Jul 20 12:12:46 <RP> boucman_work: fair enough
Jul 20 12:13:18 <RP> boucman_work: you could do XXX := "${@d.delVarFlag(XXX, 'noexec')}" but that is evil
Jul 20 12:13:34 <boucman_work> the problem is bitbake checks if the flag is set, not if the flag is "1" (the doc seems to say that you must set it to "1" but it doesn't clearly state anything about setting it to "0")
Jul 20 12:13:56 <RP> boucman_work: right, the code just checks if its set at all
Jul 20 12:14:12 <RP> boucman_work: the other approach would be to allow some kind of unset syntax
Jul 20 12:14:34 <RP> unset XXX['noexec']
Jul 20 12:14:44 <boucman_work> RP: that's beyond my current mastery of bitbake. I have no idea where the bitbake syntax is coded
Jul 20 12:14:53 <boucman_work> (i'd gladly take some pointers, though :) )
Jul 20 12:14:58 <sveinse> I read in the manuals, that quite a few variables now needs to be literal "1" to be set. Perhaps its related to this truth testing?
Jul 20 12:15:22 <sveinse> (but ignore me if I'm babbling)
Jul 20 12:15:43 <boucman_work> sveinse: as I said, the manual does say that, but the code only checks for existance afaict
Jul 20 12:15:53 <sveinse> right
Jul 20 12:16:11 <RP> boucman_work: bitbake/lib/bb/parse/parse_py/ConfHandler.py, the __export_regexp__ = re.compile( r"export\s+([a-zA-Z0-9\-_+.${}/]+)$" ) is a good line to start with
Jul 20 12:16:29 <boucman_work> RP: need to go AFK for 1h, i'll check that and come back to discuss that later, thx for the pointer
Jul 20 12:17:01 * RP gives the autobuilder a stern look
Jul 20 12:17:55 <RP> rburton: I'd bet this is the rpm performance optimisation - no package indexes
Jul 20 12:18:13 <RP> rburton: its all going to fail horribly
Jul 20 12:18:36 <bcan> hi
Jul 20 12:18:49 <bcan> how can i use tftp command on yocto?
Jul 20 12:18:56 <rburton> RP: i'll admit this is the first time it hit the AB.
Jul 20 12:19:01 <rburton> abort abort abort
Jul 20 12:20:11 <rburton> bcan: looks like busybox has tftp enabled
Jul 20 12:20:50 <bcan> how can i sue it from busybox?
Jul 20 12:20:52 <bcan> *use
Jul 20 12:21:22 <rburton> bcan: its /usr/bin/tftp
Jul 20 12:21:34 <RP> rburton: attempt to fix it or abort it, given its a high M2 :/
Jul 20 12:21:47 <rburton> abort
Jul 20 12:22:13 <RP> rburton: release criteria then won't be met :(
Jul 20 12:23:13 <bcan> rburton: i want to send file to yocto from my pc
Jul 20 12:23:13 <rburton> i never entirely understood why rpm can't handle multiple users on the same feed
Jul 20 12:23:20 <bcan> is that tftp will work
Jul 20 12:23:22 <rburton> bcan: i prefer scp for that
Jul 20 12:23:42 <RP> rburton: multiple reading users is fine, multiple writers however...
Jul 20 12:24:13 <rburton> RP: so why can't the feeds be generated once, and then rootfs happen
Jul 20 12:24:17 <bcan> i didn't understand its usage can you write and example code of it
Jul 20 12:24:25 <bcan> i mean scp usage
Jul 20 12:24:52 <rburton> bcan: scp [filename] [hostname], assuming you're running ssh on the target and have shared keys etc etc.  or, read the busybox manual on tftp.
Jul 20 12:25:11 <RP> rburton: core-image-minimal < core-image-sato < core-image-sato-sdk. Whilst the minimal image is building, packages are still being written which means updating the index
Jul 20 12:25:17 <rburton> never used tftp, but when you say "i want to copy a file" the default answer is "scp"
Jul 20 12:26:01 <rburton> RP: we need granular locking on the rpm deploy dir, so rootfs grabs a read lock and package deploy grabs a write lock.
Jul 20 12:26:24 <RP> rburton: other way around but that is what the code does today
Jul 20 12:26:43 <RP> rburton: this patch makes it have indexes per rootfs and removes the lock
Jul 20 12:27:52 <rburton> well if the generate a package index bit is the only part that grabs a write lock then they can parallellise
Jul 20 12:28:14 <RP> rburton: the index cannot be rewritten whilst the rootfs is being built
Jul 20 12:28:33 <rburton> sure, a write lock will wait for there to be no readers
Jul 20 12:29:06 <RP> rburton: reality is that the rootfs construction was sequential since only one rootfs could hold the lock at any time
Jul 20 12:29:20 <RP> and breaking that would be "very nice"
Jul 20 12:30:27 <RP> it probably does open a hole where something could get removed for a rebuild whilst a rootfs was running :/
Jul 20 12:31:10 <RP> so the index would list something that doesn't exist. In theory that shouldn't be a problem since the rootfs would never want to use it
Jul 20 12:31:18 <RP> but package globbing
Jul 20 13:54:37 <simonl> So I have a weird issue. I basically run bitbake image1 image2, generating ubi/ubifs images. image2 is corrupt. Basically the ubi headers look fine but the LEB data is a little trashed... Basically I think I should ask in #mtd about that, but I wonder if there's something about generating two images at once that might be weird?
Jul 20 13:55:09 <simonl> like I said, one image works, the other doesn't. What's more, it used to work for both images.
Jul 20 13:56:51 <simonl> I've tried running the image generation commands outside of the build environment (copied the exports and the commands from the ubi creation script) and then the image is generated correctly (well it looks that way to me anyway)
Jul 20 15:58:10 <sveinse> What machine can I use to build an image for PC which I can install on a USB device?
Jul 20 15:58:59 <boucman_work> generic-x86 (it's part of meta-intel iirc)
Jul 20 15:59:10 <boucman_work> or maybe generix-86_64 i'm not sure of the exact name
Jul 20 15:59:34 <rburton> genericx86 is part of meta-yocto-bsp
Jul 20 15:59:44 <rburton> preferred option is the BSPs in meta-intel
Jul 20 15:59:45 <boucman_work> RP: http://pastebin.com/9a9geVtt
Jul 20 15:59:54 <sveinse> And it'll install grub and the works?
Jul 20 15:59:56 <rburton> such as intel-corei7-64
Jul 20 16:00:10 <rburton> yeah build the hddimg, grub asks do you want to live boot or install
Jul 20 16:00:12 <boucman_work> sveinse: yes
Jul 20 16:00:21 <boucman_work> I think it even handle EFI, though I never tested that
Jul 20 16:00:26 <rburton> (i have a 32gb usb3 stick so just live boot)
Jul 20 16:00:42 <rburton> pretty sure it can do efi
Jul 20 16:01:01 <boucman_work> RP: oh wait... the first chunk is some cruft I didn't remove
Jul 20 16:02:27 <boucman_work> http://pastebin.com/jvCRkj3f <= better
Jul 20 16:04:20 <boucman_work> and.... I need to leave :( i'll try to catch someone tomorow on that subject
Jul 20 16:04:25 <boucman_work> see you all later
Jul 20 16:04:31 <rburton> oh nice
Jul 20 16:04:45 <rburton> +1!
Jul 20 16:05:41 <sveinse> All I really need to do is to get qtbase going for either native or qemu, but I just can't get past this step: http://paste.ubuntu.com/20192243/
Jul 20 16:06:04 <sveinse> I have no clue how I can provide lGl for intel platforms...
Jul 20 16:06:35 <sveinse> (and find it slightly strange that qtbase doesn't depend on it, since it croaks in configure)
Jul 20 16:52:15 <Xz> hi guys, I need to build couple of recipes and grab cross-compiled binaries. Is there a way to force Yocto to compile them with -static?
Jul 20 16:58:31 <RP> Xz: Adding it to the TARGET_CFLAGS of the recipe in question or maybe TARGET_LDFLAGS might work, depends on the Makefile of the software in question
Jul 20 17:09:34 <Xz> RP: can I do it globally e.g. in local.conf?
Jul 20 17:10:07 <Xz> RP: it's around 12 utilities, would be handy not to have to modify every single recipe
Jul 20 18:18:54 <sveinse> Anyone here with experience with libsdl-native on ubuntu system? I have it (libsdl1.2-dev) installed, yet compilation fails as it complains about configure not able to find it. Install SDL devel
Jul 20 18:32:08 <rburton> sveinse: old release?
Jul 20 18:32:12 <rburton> (of oe)
Jul 20 18:32:45 <rburton> modern ubuntu + old OE results in libsdl being unable to link, which is why configure can't find it
Jul 20 18:32:50 <rburton> so what release of oe are you using
Jul 20 18:35:25 <ulf`> rburton: halp
Jul 20 18:35:36 <ulf`> rburton: bbnote "nothing to compile"
Jul 20 18:35:44 <rburton> no makefile in ${B}
Jul 20 18:36:24 <rburton> prediction says you're inherit autotools but configure failed but exited with success so there's no makefile written into ${B}
Jul 20 18:36:33 <ulf`> rburton: do_compile() {
Jul 20 18:36:33 <ulf`>     cp -pP /home/ostro/ostro-gt/build/tmp-glibc/work/corei7-64-ostro-linux/or-caffedev/git-r0/git/Makefile.config.ostro /home/ostro/ostro-gt/build/tmp-glibc/work/corei7-64-ostro-linux/or-caffedev/git-r0/git/Make
Jul 20 18:36:37 <ulf`> file.config
Jul 20 18:36:39 <ulf`>     base_do_compile
Jul 20 18:36:42 <ulf`> }
Jul 20 18:37:10 <rburton> do the cp as a do_compile_prepend() instead, and don't manually chain up to base_do_compile
Jul 20 18:37:49 * ulf` looks at that
Jul 20 18:54:15 <sveinse> rburton: yes, ok. I was planning on using the one our BSP is using, which is poky 2.0 + a bunch of local patches. But if that isn't possible, I'll update poky.
Jul 20 19:12:11 <rburton> sveinse: 2.0 is fine, but you need 2.0.2
Jul 20 19:13:12 <rburton> if your vendor hasn't updated to 2.0.2 then moan at them: not only does it fix the modern ubuntu (and fedora) problem, but theres a slew of CVEs
Jul 20 19:42:08 <sveinse> whew, you have a nick for names I'd have to look up. Note to self: krogoth
Jul 20 19:55:37 <rburton> https://wiki.yoctoproject.org/wiki/Releases
Jul 20 19:55:44 <rburton> amuse yourself and play spot the theme
Jul 20 19:56:06 <rburton> the release activity goes back to the first names, 15 releases ago
Jul 20 19:56:27 <rburton> three themes so far iirc
Jul 20 20:30:22 <RP> Xz: TARGET_LDFLAGS_append_pn-<recipename> = " XXX"
Jul 20 20:38:48 <khem> so today world builds for musl are successful on master for all qemus
Jul 20 20:57:06 <istarilucky> hi there, is possible generate a live image with a rootfs.img greater than 4gb? What is the correct approach in this case?
Jul 20 22:01:45 <rburton> istarilucky: maybe if you change how its constructed, currently it goes into a old-school fat system so theres a 4gb file size limit. you could just not use a live image?  or look at changing the filesystem.
Jul 20 22:27:46 <khem> istarilucky: you can define IMAGE_ROOTFS_EXTRA_SPACE = "5000000" e.g. to add 5G of empty space to rootfs
Jul 20 22:28:07 <khem> you can have vmdk imgs
Jul 20 22:51:20 <khem> RP: should http://git.openembedded.org/openembedded-core/log/?h=master-next-1.9 be deleted ?
Jul 20 23:42:46 <paulg> RP, a heads up,  3e0137113e894eb8 / 5c21fd5eb8b689 is a total fail regression here  ("linux-yocto-dev: Handle performance regression")
Jul 20 23:43:13 <paulg> the autorev fails to do anything and I get the default ancient 3.7 commit ID and it goes boom.
Jul 20 23:43:54 <paulg> like so...
Jul 20 23:43:57 <paulg>     ERROR: linux-yocto-dev-4.6-rc++gitAUTOINC+29594404d7_29594404d7-r0 do_fetch: Fetcher failure: Unable to find revision 29594404d7fe73cd80eaa4ee8c43dcc53970c60e in branch master even from upstream
Jul 20 23:44:31 <paulg> I've just reverted the above locally for now ; too tired and bitbake stupid to see what is wrong with it ATM.
Jul 21 02:31:40 <khem> paulg_: dev branches are rebased IIRC, so all one should use for them is AUTOREV
**** ENDING LOGGING AT Thu Jul 21 02:59:58 2016