**** BEGIN LOGGING AT Tue Dec 01 03:00:47 2015
Dec 01 03:04:58 <jynik> deviosity: Not sure which image type, but I know meta-fsl-arm contains an SD card image type: https://github.com/Freescale/meta-fsl-arm/blob/master/classes/image_types_fsl.bbclass#L169
Dec 01 03:22:30 <deviosity> jynik: Thank you very much.
Dec 01 04:15:32 <pevster> Hey all... It seems that one of the things that slows down my build massively is building perl. This seems to be a dependency of udev - before I dig around to work it out, does anyone know if it's definitely critical?
Dec 01 04:16:32 <pevster> Likewise, glib seems like an unexpected thing to drag in
Dec 01 04:19:05 <pevster> (also wondering why we need udev at all for embedded systems with a static set of devices...!)
Dec 01 04:26:08 <kergoth> not all embedded systems have a static set of devices, but certainly you can switch to a different device manager for your builds. there's a VIRTUAL-RUNTIME variable for it, see the yocto reference manual
Dec 01 04:27:07 <bluelightning> if only it were in the reference manual, unfortunately it isn't
Dec 01 04:27:16 <kergoth> huh, that's surprising, i thought most of those were covered
Dec 01 04:27:42 <bluelightning> basically though, set VIRTUAL-RUNTIME_dev_manager = "", ensure /dev is populated with static device nodes, and you're done
Dec 01 04:27:49 * kergoth nods
Dec 01 04:28:01 <bluelightning> some people use busybox's mdev as an alternative as well
Dec 01 04:29:26 <pevster> Well, my device is simple so dumping altogether would be great - I hadn't realised how much crap udev brings in! What's the best way to populate the devnodes?
Dec 01 04:29:36 <pevster> is there an example somewhere?
Dec 01 04:30:41 <pevster> Also - am I being blind or is there not a simple way to list all packages included in your build? I was trying to see how many drop off when I dump udev...
Dec 01 04:31:58 <pevster> And I'm guessing I can probably duplicate what udev has set up currently now somehow as a lazy shortcut?
Dec 01 04:32:16 <bluelightning> I don't know that there is an example anywhere I'm afraid
Dec 01 04:32:52 <bluelightning> also, since we ultimately leave construction of the image to the package manager, we don't know exactly what will be in it until it's actually constructed
Dec 01 04:34:15 <bluelightning> you could use pn-buildlist produced by bitbake -g your-image to see what the difference would be in terms of things that will be *built* though
Dec 01 04:34:28 <bluelightning> (which is not the same set of things that will be in the image)
Dec 01 04:39:09 <pevster> bluelightning: Thanks - will have a play with that
Dec 01 04:58:53 <pevster> I never could work out what's going on in my builds when in certain stages theres not much cpu load and not much IO but it stalls for ages e.g. perl's write_ipk
Dec 01 05:01:19 <pevster> and why do I have rpm-native forced on me?
Dec 01 08:13:45 <mckoan> good morning
Dec 01 09:02:36 <Taurenking> morning
Dec 01 09:03:12 <Taurenking> i have a question regarding uboot and bootcmd in particular
Dec 01 09:03:48 <Taurenking> is it possible to patch uboot to have a custom bootcmd or should i just build the image and then override the command with uEnv.txt?
Dec 01 09:09:04 <LetoThe2nd> Taurenking: in patching, anything is possible
Dec 01 09:09:40 <Taurenking> really? cause I had some problems with patching uboot
Dec 01 09:09:51 <Taurenking> in that the patch didn't seem to get appliend into the image
Dec 01 09:37:14 <LetoThe2nd> Taurenking: i can't tell if your patch in itself is fine, and if it gets properly applied. but changing the default env is certainly possible, we're doing it all the time.
Dec 01 09:37:49 <LetoThe2nd> Taurenking: as usual, check the patch function without an automated build process first, then when it's done, automate.
Dec 01 09:39:50 <Taurenking> "check the patch function without an automated build process first"
Dec 01 09:39:56 <Taurenking> what does that mean?
Dec 01 09:40:05 <Taurenking> sorry I just started 1w ago
Dec 01 09:40:26 <LetoThe2nd> you take u-boot source, apply your patch, build it manually, then check if your patch has the desired effect.
Dec 01 09:41:00 <LetoThe2nd> or, you take uboot source, tinker with it, build it, test it.
Dec 01 09:41:16 <LetoThe2nd> oncwe you're satiesfied with the result, pour the changes into a patch set.
Dec 01 09:43:04 <LetoThe2nd> i mean, where does that patch that you say you have problems with come from?
Dec 01 09:43:05 <Taurenking> ok
Dec 01 09:43:15 <LetoThe2nd> how did you generate it?
Dec 01 09:43:25 <Taurenking> bitbake u-boot
Dec 01 09:43:29 <Taurenking> modify some files
Dec 01 09:43:32 <Taurenking> create bbappend
Dec 01 09:43:43 <Taurenking> add patch
Dec 01 09:43:51 <Taurenking> bitbake -c patch u-boot
Dec 01 09:43:58 <Taurenking> go to work dir
Dec 01 09:44:01 <Taurenking> see changes
Dec 01 09:44:05 <Taurenking> go to root
Dec 01 09:44:15 <LetoThe2nd> thats really not how you created the *PATCH* itself
Dec 01 09:44:20 <Taurenking> build image for sd card for embedded device
Dec 01 09:44:23 <Taurenking> ?
Dec 01 09:44:34 <Taurenking> git format-patch?
Dec 01 09:44:38 <Taurenking> done
Dec 01 09:45:06 <LetoThe2nd> well then, i'll stick with my "build and test manually" advice.
Dec 01 09:45:12 <Taurenking> aahah
Dec 01 09:45:26 <Taurenking> anyway
Dec 01 09:45:30 <Taurenking> after building the image
Dec 01 09:45:34 <Taurenking> flash sd card
Dec 01 09:45:45 <Taurenking> put sd card into embedded device
Dec 01 09:45:49 <Taurenking> flash device
Dec 01 09:45:52 <Taurenking> reboot device
Dec 01 09:45:57 <Taurenking> go into uboot
Dec 01 09:46:04 <Taurenking> print env variables
Dec 01 09:46:14 <Taurenking> still old bootcmd, old bootdelay etc..
Dec 01 09:46:18 <LetoThe2nd> Taurenking: hint: pressing the "ENTER" key after every second word makes it really a bit tiring to read
Dec 01 09:46:41 <Taurenking> sorry
Dec 01 09:47:05 <LetoThe2nd> and all that really doesn't test the u-boot patch itself, as it includes a lot of build and flash magic.
Dec 01 09:47:24 <LetoThe2nd> build and deploy uboot manually, check that the patch does what you want. automate later.
Dec 01 09:51:20 <Taurenking> but into the uboot directory theres a folder called patches applied and my patch is there
Dec 01 09:51:30 <LetoThe2nd> *sigh*
Dec 01 09:51:54 <LetoThe2nd> have you ever verified that the patch *REALLY* does what you think it does? e.g., is it tested?
Dec 01 09:55:49 <Taurenking> ok, what about taking on another road to accomplish what i want? (eg.: modifiy bootcmd trough uEnv.txt)
Dec 01 09:56:32 <LetoThe2nd> maybe that is exactly what is happening and messing with what you try to do?
Dec 01 09:57:06 <LetoThe2nd> sorry, but it seems a bit pointless to me to continue as long as you just do random shots into the dark instead of trying to isolate the source of your problems.
Dec 01 10:00:47 <Taurenking> ok. how do i build uboot manually and test that it actually applies the patch
Dec 01 10:02:03 <LetoThe2nd> if you have created you patch through git format-patch, you should have a u-boot tree anyways. so make $THECONFIGYOUWANT, make, then try on your target.
Dec 01 11:57:02 <rob_w> hi, i am using repo to sync down poky + some meta layers from a certain branch (fido atm) .. is there a way beside "PREFERRED_VERSION" to lock all recipes and their SRC to a certain version ?
Dec 01 13:48:59 <ed_bart> sujith_h: hi
Dec 01 13:49:14 <sujith_h> ed_bart: Hi
Dec 01 13:49:46 <ed_bart> sujith_h: did you have questions about toaster?
Dec 01 13:50:02 <sujith_h> ed_bart: Yah, I was trying to source toaster script from branch ed/toaster/8279-v6
Dec 01 13:50:49 <ed_bart> sujith_h: and?
Dec 01 13:50:58 <sujith_h> and it was leading to error: http://pastebin.ubuntu.com/13599367/
Dec 01 13:52:13 <ed_bart> sujith_h: looks like you don't have that directory. let me look at the sources.
Dec 01 13:53:54 <sujith_h> ed_bart: I cross verified for toasterconf.json file and http://pastebin.ubuntu.com/13599405/
Dec 01 13:53:55 <sujith_h> its there
Dec 01 13:55:43 <ed_bart> sujith_h: brian's commit c68c75e9 brought this functionality to the codebase.
Dec 01 13:56:12 <sujith_h> ed_bart: ok
Dec 01 13:57:34 <sujith_h> ed_bart: so do I need to set TEMPLATECONF variable to point to toasterconf.json file?
Dec 01 13:57:43 <ed_bart> sujith_h: this one: https://git.yoctoproject.org/cgit/cgit.cgi/poky-contrib/commit/?h=toaster-next&id=879517fdaa2f9e128a45d838e57595afe01a35a0
Dec 01 13:58:25 <ed_bart> sujith_h: looks like it should be set in . $OEROOT/.templateconf
Dec 01 14:06:28 <sujith_h> ed_bart: ok
Dec 01 14:06:34 <ed_bart> sujith_h: I can see it in my git clone:
Dec 01 14:06:42 <ed_bart> [ed@vmed yocto]$ pwd
Dec 01 14:06:44 <ed_bart> /home/ed/git/yocto
Dec 01 14:06:46 <ed_bart> [ed@vmed yocto]$ cat .templateconf
Dec 01 14:06:48 <ed_bart> # Template settings
Dec 01 14:06:50 <ed_bart> TEMPLATECONF=${TEMPLATECONF:-meta-yocto/conf}
Dec 01 14:08:17 <sujith_h> ed_bart: I do have the same file
Dec 01 14:08:19 <sujith_h> [sujith@sujith poky-updates]$ cat .templateconf
Dec 01 14:08:21 <sujith_h> # Template settings
Dec 01 14:08:22 <sujith_h> TEMPLATECONF=${TEMPLATECONF:-meta-yocto/conf}
Dec 01 14:08:24 <sujith_h> [sujith@sujith poky-updates]$
Dec 01 14:09:17 <sujith_h> ed_bart: so, are you able to source ../bitbake/bin/toaster successfully?
Dec 01 14:11:02 <ed_bart> sujith_h: yes, I am
Dec 01 14:11:02 <sujith_h> ed_bart: and the sourcing of toaster script should be done inside build folder, right?
Dec 01 14:11:12 <ed_bart> yes
Dec 01 14:14:00 <ed_bart> sujith_h: do you have meta-yocto/conf/toasterconf.json in your clone?
Dec 01 14:14:34 <sujith_h> yes
Dec 01 14:17:03 <sujith_h> Error: './poky-contrib/bitbake/bin/../../meta-yocto/conf' must be a directory containing toasterconf.json line seems to be wrong
Dec 01 14:17:20 <sujith_h> because I am inside directory poky-updates and not inside poky-contrib
Dec 01 14:18:17 <ed_bart> sujith_h: what's poky-updates?
Dec 01 14:18:48 <sujith_h> ed_bart: its the directory where I cloned poky
Dec 01 14:19:36 <ed_bart> sujith_h: this doesn't matter. you most probably have some env variables set.
Dec 01 14:20:07 <ed_bart> sujith_h: can you open new terminal window, go to your clone and start from there?
Dec 01 14:20:30 <sujith_h> ed_bart: that's exactly now i am trying to do :)
Dec 01 14:23:00 <ed_bart> sujith_h: can you also look at the output of set | grep -i toaster in your old terminal window?
Dec 01 14:23:16 <sujith_h> ed_bart: sure
Dec 01 14:23:37 <ed_bart> sujith_h: theoretically you shouldn't have anything toaster-related set
Dec 01 14:23:54 <sujith_h> ed_bart: nothing is there
Dec 01 14:23:56 <ed_bart> sujith_h: however, if you run code from master you can :)
Dec 01 14:25:24 <ed_bart> sujith_h: so, do you have the same issue in new terminal window?
Dec 01 14:26:42 <sujith_h> ed_bart: Now it works in the new terminal window :)
Dec 01 14:27:29 <sujith_h> ed_bart: Now my next query is with respect to cancellation of build.
Dec 01 14:28:47 <ed_bart> sujith_h: go ahead
Dec 01 14:28:48 <sujith_h> ed_bart: I am working on that part. And I was wondering, do we have any new mechanism incorporated recently to kill bitbake process?
Dec 01 14:29:26 <ed_bart> sujith_h: why do you want to kill it?
Dec 01 14:30:28 <sujith_h> ed_bart: that's one of the way came to my mind :(
Dec 01 14:32:23 <ed_bart> sujith_h: you can look at bitbake/lib/toaster/bldcontrol/localhostbecontroller.py code.
Dec 01 14:32:38 <sujith_h> ed_bart: sure
Dec 01 14:32:42 <ed_bart> sujith_h: killing it would be the last resort.
Dec 01 14:33:10 <sujith_h> ed_bart: sure. I will have a look at it. Thanks for the helping hand :)
Dec 01 14:33:14 <ed_bart> sujith_h: I'd suggest to investigate if we can tell bitbake server to stop the build.
Dec 01 14:33:32 <sujith_h> ed_bart: sure I will do that.
Dec 01 14:34:27 <ed_bart> sujith_h: toaster has a connection to bitbake server. It uses it to set variables and start the build.
Dec 01 14:34:52 <ed_bart> sujith_h: here are couple of examples:
Dec 01 14:34:55 <ed_bart> sujith_h: bbctrl.setVariable('INHERIT', ' '.join(inherit))
Dec 01 14:35:04 <ed_bart> bbctrl.build(list(map(lambda x:x.target, targets)), task)
Dec 01 14:35:33 <ed_bart> sujith_h: it would be good to have bbctrl.cancel or bbctlr.stopbuild there.
Dec 01 14:36:16 <ed_bart> sujith_h: however, it depends on bitbake. if might not have this functionality.
Dec 01 14:38:01 <sujith_h> ed_bart: sure will have a look at that part
Dec 01 14:40:15 <ed_bart> sujith_h: look at processing of KeyboardInterrupt exceptions under bitbake/lib. you may find something useful there.
Dec 01 14:41:05 <sujith_h> ed_bart: Yah something like ctrl+c
Dec 01 14:41:28 <ed_bart> sujith_h: as this exception is generated when user press ^C. and bitbake cancels current build when it happens.
Dec 01 14:41:41 <sujith_h> ed_bart: yes
Dec 01 14:42:14 <ed_bart> sujith_h: if this functionality is not present in bitbake server you can try to add it there.
Dec 01 14:42:39 <sujith_h> ed_bart: ok
Dec 01 14:42:45 <ed_bart> sujith_h: anything else I can help with?
Dec 01 14:43:55 <sujith_h> ed_bart: You have shared a lot :) I will go through them and will try to proceed further :)
Dec 01 14:44:05 <sujith_h> ed_bart: thanks a bunch :)
Dec 01 14:44:24 <ed_bart> sujith_h: no prob.
Dec 01 15:18:10 <mtownsend1973_> Valgrind isn't reporting any errors for me on my Arm cortex A9 board.  The code is example code that should trigger a whole bunch. I can run on my PC and it reports all the errors.  Does anyone else use Valgrind on ARM?
Dec 01 15:18:38 <mtownsend1973_> I'm using fido branch.
Dec 01 15:39:35 <t0mmy_> mtownsend1973_: Valgrind working fine on imx6q, bbb and rpi on Fido branch, we use it.
Dec 01 15:43:51 <Marex> rburton1: Hi, how do you do that sort of testing which found the libbsd openssl breakage ?
Dec 01 15:44:05 <Marex> rburton1: is that something I can do on my machine or is that an infrastructure thing ?
Dec 01 15:44:58 <rburton1> Marex: "bitbake libbsd"
Dec 01 15:45:07 <rburton1> Marex: it was trying to use openssl, which wasn't in my sysroot
Dec 01 15:45:18 <rburton1> Marex: so delete your tmp, or use the wipe-sysroot script.
Dec 01 15:45:23 <Marex> rburton1: so I need to wipe my sysroot and do bitbake libbsd, that's the right way to do it ?
Dec 01 15:45:28 <Marex> oki
Dec 01 15:45:40 <Marex> I was wondering if there's something less destructure
Dec 01 15:45:54 <rburton1> wipe-sysroot is the middle ground - deletes the sysroots and all relevant stamps
Dec 01 15:46:03 <Marex> rburton1: I'll check that, thanks!
Dec 01 15:46:08 <rburton1> so a lot quicker than wiping tmp, but doesn't save as much space :)
Dec 01 15:46:49 <Marex> rburton1: I just want to know how to improve my submissions, I'm not concerned about the space that much
Dec 01 15:47:19 <rburton1> Marex: doing a test from a clean sysroot before submitting is always sensible
Dec 01 15:47:31 <Marex> rburton1: sorry about that
Dec 01 15:48:01 <mtownsend1973_> t0mmy: Thanks for replying. I'll dig a bit deeper to see whats going on.
Dec 01 15:52:30 <rburton1> Marex: no problem, its a good practise but many people - including myself - forget
Dec 01 15:53:18 <Marex> rburton1: well, I uninstalled libssl-dev from my host system (to make sure), I also did wipe-sysroot and rebuilt the libbsd, but it doesn't seem to complain about missing openssl headers
Dec 01 15:53:25 <Marex> I should probably wipe the whole tmp then
Dec 01 15:54:38 <rburton1> weird
Dec 01 15:54:46 <rburton1> wiping sysroot should be sufficient
Dec 01 15:54:57 <rburton1> *unless*
Dec 01 15:55:03 * Marex is petrified
Dec 01 15:55:23 <rburton1> it found openssl at configure time but as it didn't list it as a dependency, bitbake was happily going off and deleting it from the sysroot, so it had disappeared by the time compile ran :)
Dec 01 15:56:38 <Marex> bitbake can do that now ?
Dec 01 15:57:02 <sjolley1> YPTM:   Ready-Access Number: 8007302996/9139049836  Access Code:     2705751
Dec 01 15:57:09 <sjolley1> YPTM: Stephen Joined
Dec 01 15:59:26 <jku> YPTM: Jussi is on the call
Dec 01 16:00:08 <Marex> rburton1: search no more, look at http://cgit.freedesktop.org/libbsd/commit/?id=8493c7f27da2dcd2de71e9c7782c3d020d89c2a2
Dec 01 16:00:23 <zeddii> YPTM: bruce on the call
Dec 01 16:00:45 <vmeson> YPTM: Randy MacLeod joined.
Dec 01 16:01:19 <sgw_> YPTM: saul is here
Dec 01 16:02:00 <fray> YPTM: fray is here
Dec 01 16:02:23 <jku> is the call working for others? I'm just getting loud static for last 30secs
Dec 01 16:02:34 <sgw_> static
Dec 01 16:02:40 <sjolley1> I am getting static too.
Dec 01 16:02:42 <fray> ya, that is what I just got
Dec 01 16:02:46 * zeddii is getting nothing at all.
Dec 01 16:02:48 <zeddii> just beeping.
Dec 01 16:02:50 <fray> WOW
Dec 01 16:02:53 <fray> it's aweful
Dec 01 16:03:03 <fray> zeddii you might need to put all or something
Dec 01 16:03:20 <fray> put -> MUTE
Dec 01 16:03:26 <zeddii> yah. I wonder if it is a caller, or the conference provider.
Dec 01 16:03:36 <fray> likely both.. one feeding back to the other
Dec 01 16:03:42 <zeddii> I am muted, on my headset. what's the * code for irt ?
Dec 01 16:03:54 <sjolley1> I am talking to an operator
Dec 01 16:03:58 <fray> hey there we go
Dec 01 16:04:00 <belen1> YPTM: belen joined the call
Dec 01 16:04:32 <fray> lol.. it's only need about what 2 years?  ;)
Dec 01 16:07:24 * zeddii smells a short call.
Dec 01 16:16:31 <sjolley> YPTM is over.
Dec 01 16:20:05 <kratsg> Is there a guide on how to build u-boot for a custom board using yocto?
Dec 01 16:24:21 <CTtpollard> kratsg: do you have a bsp layer for the board?
Dec 01 16:25:27 <kratsg> Sort of. It closely matches Xilinx ZC706, but custom. So I imagine I need to remake the entire chain.
Dec 01 16:27:04 <kratsg> I'm guessing I need to copy over a conf/machine into my custom layer to build out the BSP (and define the device tree)
Dec 01 16:28:11 <fl0v0> Hi, in which variable contains the path to the sysroot?
Dec 01 16:30:09 <fl0v0> i want to compile an autotools project which is linked against a static library. But it always wants to use the library from the HOST system
Dec 01 16:40:01 <kratsg> is there a guide somewhere? I can't seem to find any information. I need to adapt this; https://github.com/Xilinx/meta-xilinx/ for sure.
Dec 01 16:44:11 <CTtpollard> kratsg: if you need to make a lot of changes you could use that layer as a base for your own, or you could use bbappends to make the required changes
Dec 01 16:44:34 <CTtpollard> or local conf overrides etc
Dec 01 16:45:34 <kratsg> well, I use a ZC706 on a custom board.
Dec 01 16:45:54 <kratsg> So I should be able to use the same recipes, but I need to... modify the device tree at a minimum, I think. Not sure how to make it point correctly.
Dec 01 16:46:22 <kratsg> For some reason, u-boot refuses to boot the kernel image out of the box, and so I'm guessing it's because of the devicetree being wrong.
Dec 01 16:46:35 <kratsg> but it doesn't give me any error messages.
Dec 01 16:47:50 <kratsg> I think I have to start with copying this file: https://github.com/Xilinx/meta-xilinx/blob/master/conf/machine/zc706-zynq7.conf
Dec 01 16:47:58 <kratsg> and creating my own custom machine with that.
Dec 01 16:48:30 <kratsg> by making the new device tree.
Dec 01 16:49:15 <rburton1> Marex: ah, awesome, just apply that fix then
Dec 01 16:49:57 <rburton1> Marex: the patch needs a signed-off-by alongside your Upstream-Status, sorry!
Dec 01 16:54:07 <kratsg> So, no idea though. I'm guessing that might be all I need to do.
Dec 01 16:54:14 <kratsg> and u-boot is built from that same devicetree which is helpful?
Dec 01 16:54:23 <Marex> rburton1: so V3 ? :-)
Dec 01 16:54:30 <rburton1> Marex: please :)
Dec 01 16:54:50 <rburton1> i'm liking this quick turnaround though :)
Dec 01 16:56:27 <Marex> rburton1: there, done
Dec 01 16:56:43 <Marex> rburton1: it's sometimes frowned upon to keep posting a new version of the patch each hour :)
Dec 01 16:58:31 <rburton1> Marex: if its based on feedback its fine by me!
Dec 01 17:00:14 <Marex> rburton1: thanks :-)
Dec 01 17:02:37 <rburton1> Marex: looks good ;)
Dec 01 17:05:13 <Marex> rburton1: thanks :-)
Dec 01 17:36:03 <moto-timo> rburton1: working on xbmc 16.0; libsdl is not always required depends on input
Dec 01 17:36:53 <moto-timo> rburton1: also it drops the pesky rsxs screensaver, so we can finally get rid of the blacklist
Dec 01 17:37:05 <rburton1> ah, interesting
Dec 01 17:37:18 <moto-timo> much better structure to 15.0 and 16.0
Dec 01 17:37:19 <rburton1> well hopefully the libsdl-native i sent is good
Dec 01 17:37:28 <moto-timo> we'll find out :)
Dec 01 17:37:58 <moto-timo> right now I'm stuck on building the packaged dependency tools
Dec 01 17:38:00 <moto-timo> sigh
Dec 01 17:38:16 <moto-timo> JsonSchemaBuilder to be specific
Dec 01 17:38:34 <moto-timo> (I should say bundled, not packaged)
Dec 01 17:39:18 <rburton1> yay bundled
Dec 01 17:39:25 <moto-timo> facepalm
Dec 01 18:05:37 <abelloni> Is there still any support for the fri2 ?
Dec 01 18:19:03 <Marex> abelloni: is that the thing they were handing out in barcelona ?
Dec 01 18:21:05 <bluelightning> sgw_: ^
Dec 01 18:22:14 <abelloni> yeah
Dec 01 18:22:29 <abelloni> I'm actually using mine
Dec 01 18:22:36 <abelloni> but it still has a 3.8 kernel
Dec 01 18:25:48 <sgw_> abelloni: which version of OE-Core, for YP 2.0 we will be releasing the meta-intel 4.0 release in the next week or and the fri2 should still be supported by the intel-core2-32
Dec 01 18:29:49 <abelloni> oh great, any preview available ? :)
Dec 01 18:38:27 <sgw_> abelloni: it's currently jethro branch of meta-intel if you are building from source
Dec 01 18:45:54 <abelloni> ok, I'll try intel-core2-32
Dec 01 19:22:59 <blilly5567> can anyone point me toward documentation regarding setting up a package manager inside the distribution? I've added "rpm", but (to no surprise) the base installation is not done through that mechanism.
Dec 01 19:24:25 <bluelightning> blilly5567: this may be of interest: http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#using-runtime-package-management
Dec 01 19:25:20 <blilly5567> thats exactly what I was looking for. thank you.
Dec 01 19:25:32 <blilly5567> I have that document open - I guess I just hadn't found that section yet
Dec 01 20:08:43 <raykinsella78> Can I not add a .ko to a reciepes FILES and presume that the default install script will put it in the right place?
Dec 01 20:10:57 <bluelightning> raykinsella78: well there isn't really a default do_install - unless a class you're inheriting defines one (which a lot do) - what kind of recipe is this in?
Dec 01 20:12:17 <raykinsella78> bluelightning: hey blue!
Dec 01 20:12:27 <bluelightning> hey :)
Dec 01 20:12:41 <raykinsella78> bluelightning: its building a kernel module ... its from android world, so kinda crap.
Dec 01 20:13:22 <raykinsella78> bluelightning: its full of 'install -D something.ko /lib/module/${KERNVER}/this/that'
Dec 01 20:13:24 <pevster> Hm... I think I've asked this before and failed... I've got a slightly clever set of image recipes that do some custom compound image creation. However when I remove the build directory to do a full clean re-build it pulls stuff from sstate-cache and doesn't quite populate everything back into the deploy dir...
Dec 01 20:21:25 <raykinsella781> Great system crash - love linux at times.
Dec 01 20:21:35 <raykinsella781> bluelightning: missed any response
Dec 01 20:25:55 <bluelightning> pevster: you're not doing anything you shouldn't be like poking files directly into the sysroot, are you?
Dec 01 22:43:10 <deviosity> is there a proper way to ensure a conflicted recipe doesn't get built or installed?
Dec 01 22:45:14 <bluelightning> deviosity: conflicted how specifically?
Dec 01 22:45:21 <deviosity> currently I have tried listing the conflicting recipe in PROVIDES, RPROVIDES, RREPLACES, RCONFLICTS, and have tried with PNBLACKLIST as well as EXCLUDE
Dec 01 22:45:49 <deviosity> basically dealing with linux-firmware, which is installed via other images and distort features
Dec 01 22:46:20 <deviosity> when it uses some conflicting firmware files that are already created by a custom recipe.
Dec 01 22:47:10 <bluelightning> RCONFLICTS would be the correct way to specify that; but if something else explicitly calls for linux-firmware, you're going to get an error
Dec 01 22:47:49 <deviosity> yeah I think I may be dealing with the latter case
Dec 01 22:48:39 <bluelightning> so what you do now is going to depend on whether you really need anything in linux-firmware or not
Dec 01 22:52:56 <deviosity> I definitely do not need linux-firmware
Dec 01 22:53:18 <deviosity> since all of my hardware is custom
Dec 01 22:54:21 <rburton1> deviosity: have your recipe (my-firmware.bb) PROVIDE linux-firmware and then set PREFERRED_PROVIDER?
Dec 01 22:54:46 <deviosity> I currently have that set
Dec 01 22:55:04 <deviosity> Looks like it is defined from an inherited packagegroup
Dec 01 22:56:11 <deviosity> what PACKAGECONFIG_remove = "linux-firmware"
Dec 01 23:02:02 <bluelightning> deviosity: I doubt you mean PACKAGECONFIG
Dec 01 23:02:22 <deviosity> it didn't work anyway :(
Dec 01 23:02:33 <bluelightning> no, it's unrelated to this, so I'm not surprised
Dec 01 23:03:30 <bluelightning> really what you'll need to is adjust the offending packagegroup, possibly through a bbappend file
Dec 01 23:03:51 <bluelightning> the other alternative of course is to simply bbappend linux-firmware and remove the conflicting files
Dec 01 23:06:05 <deviosity> I thought bbappend was only additive.
Dec 01 23:12:09 <bluelightning> it is, but that doesn't mean it can't clear variables, set them to different values or remove items from their values
Dec 01 23:12:49 <bluelightning> just think of it as the contents of the bbappend(s) being cut-and-pasted on the end of the recipe
Dec 01 23:15:05 <deviosity> Well that was actually too easy. It works great.
Dec 02 02:56:32 <pevster> Question: If adding coreutils, do I need to manually modify the busybox config in a bbappend to remove overlap or is that handle automagically?
Dec 02 02:57:28 <pevster> (I really just want to include a proper dd...)(
**** ENDING LOGGING AT Wed Dec 02 03:00:57 2015