**** BEGIN LOGGING AT Mon Jul 06 02:59:59 2015
Jul 06 07:34:01 <mckoan> good morning
Jul 06 08:26:01 <bluelightning> morning all
Jul 06 08:58:50 <AlexVaduva> morning
Jul 06 09:15:59 <milan> bluelightning: Is there any option called IMAGE_INSTALL_remove (like IMAGE_INSTALL_append) ? I want to prevent a package from installing into the rootfs temporarily via local.conf .
Jul 06 09:17:00 <bluelightning> milan: there's PACKAGE_EXCLUDE
Jul 06 09:17:29 <bluelightning> milan: but the important thing to note about that is that it will not remove dependency chains for you, so if something else depends on the thing you are trying to remove you will get an error straight away
Jul 06 09:17:57 <bluelightning> which may be useful as it will at least tell you what that dependency is
Jul 06 09:18:22 <milan> That's fine I think for current scenario though.
Jul 06 09:18:55 <milan> But how can I dump in advance the list of packages to be included in final rootfs
Jul 06 09:19:33 <milan> Have been using this .. "bitbake -g default-image && cat pn-depends.dot | grep -v -e '-native' | grep -v digraph | grep -v -e '-image' | awk '{print $1}' | sort | uniq"
Jul 06 09:19:38 <bluelightning> completely in advance, you can't - the contents of the image is up to the package manager and that operation happens as part of building the image
Jul 06 09:19:52 <bluelightning> you can however look at how the image got constructed *after* it has been done
Jul 06 09:20:03 <milan> ok
Jul 06 09:20:40 <bluelightning> the dependency graphs produced by buildhistory provide one way to track down how a package got into the image
Jul 06 09:20:57 <bluelightning> this manual section gives some details on how to set up buildhistory: http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#maintaining-build-output-quality
Jul 06 09:21:26 <milan> ok
Jul 06 09:53:20 <LocutusOfBorg1> Hi folks, my customer asked me to give him a list of packages and respective licenses in the target image
Jul 06 09:53:30 <LocutusOfBorg1> do you have any bitbake command to extract them?
Jul 06 09:53:41 * LocutusOfBorg1 wonders if playing with bash is the right way to do it
Jul 06 09:54:29 <LetoThe2nd> LocutusOfBorg1: like, tmp/deploy/licenses?
Jul 06 09:54:43 <bluelightning> right, was just about to suggest that :)
Jul 06 09:55:13 <bluelightning> specifically, tmp/deploy/licenses/<imagename>-<machine>-<datetime>
Jul 06 09:55:16 <LetoThe2nd> bluelightning: hand me a red sharpie, please! first time i answered faster than you and it was even correct :)
Jul 06 09:55:23 <bluelightning> heh
Jul 06 09:55:27 * LetoThe2nd needs to make a mark in his caldendar
Jul 06 09:56:55 <LocutusOfBorg1> bluelightning, yes, but the problem is: how I convert that "tree" directory list in a table with "package --> license"
Jul 06 09:57:04 <LocutusOfBorg1> excluding sh tools
Jul 06 09:57:28 <LetoThe2nd> huh?
Jul 06 09:57:36 <LetoThe2nd> its a plain text file that fits the image you crated
Jul 06 09:57:36 <bluelightning> LocutusOfBorg1: it's not a tree structure, under the directory for the image there are two files - one, the license manifest (a list of package + license) and two a plain list of packages
Jul 06 09:58:01 <LocutusOfBorg1> damn
Jul 06 09:58:03 <LetoThe2nd> for tabelizing, awk/sed :)
Jul 06 09:58:12 <bluelightning> $ ls tmp/deploy/licenses/core-image-minimal-qemux86-64-20150618123313
Jul 06 09:58:13 <bluelightning> license.manifest  package.manifest
Jul 06 09:58:16 <LocutusOfBorg1> I was looking at "licenses", not licenses/imagename-and so on
Jul 06 09:58:18 <LocutusOfBorg1> ajajajaj
Jul 06 09:58:23 <LocutusOfBorg1> that's true
Jul 06 09:58:29 <LocutusOfBorg1> and it's monday :) sorry!
Jul 06 09:58:34 <bluelightning> np :)
Jul 06 09:59:30 <LocutusOfBorg1> damn, I was aware of the deploy/licenses, but not of the subdirectory with everything inside :D
Jul 06 10:00:05 <bluelightning> I'll have to check how well we document that, maybe we can make it clearer
Jul 06 10:00:08 <LocutusOfBorg1> that is *exactly* what I was needing for
Jul 06 10:00:24 <LocutusOfBorg1> I also need coffee, but this is a little bit OT there :p
Jul 06 10:00:54 <LocutusOfBorg1> I searched here
Jul 06 10:00:55 <LocutusOfBorg1> http://www.yoctoproject.org/docs/1.6.1/dev-manual/dev-manual.html#new-recipe-licensing
Jul 06 10:01:05 <LocutusOfBorg1> but I didn't find anything useful, at least I thinkk
Jul 06 10:01:44 <LocutusOfBorg1> I also have the yocto book, but I do not remember it was listed
Jul 06 10:11:49 <ftonello> does oe has any support for git submodules out of the box?
Jul 06 10:25:49 <rburton> ftonello: do you mean does the bitbake fetcher support submodules?
Jul 06 10:26:17 <joshuagl> rburton: RP: autobuilder is idle, may I?
Jul 06 10:26:57 <rburton> joshuagl: yes
Jul 06 10:27:19 <joshuagl> thanks
Jul 06 10:28:00 <ftonello> rburton: well, yes. I would think that submodules would be something optional.
Jul 06 10:28:44 <rburton> yes
Jul 06 10:28:48 <rburton> there's a gitsm fetcher
Jul 06 10:29:42 <ftonello> ok, let me check
Jul 06 10:31:21 <ftonello> rburton: where should I look for?
Jul 06 10:32:08 <rburton> http://www.yoctoproject.org/docs/1.6.1/bitbake-user-manual/bitbake-user-manual.html#gitsm-fetcher
Jul 06 10:32:31 <rburton> the source is in bitbake's fetch directory
Jul 06 10:32:48 <rburton> but its basically just a git fetcher that does a submodule update for you
Jul 06 10:33:09 <rburton> pay attention to the warning in the docs though
Jul 06 10:43:26 <ftonello> rburton: Thanks!
Jul 06 10:46:02 <ftonello> I am having trouble fetching a repository from github.
Jul 06 10:46:28 <ftonello> The fetcher always adds a ssh:// when the protocol is ssh, but for some reason that won't close the repository.
Jul 06 10:46:45 <rburton> what URI are you using?
Jul 06 10:47:16 <ftonello> git@github.com:private/repo.git
Jul 06 10:47:36 <ftonello> this url works, but bitbake does ssh://git@github.com:private/repo.git which doesn't work.
Jul 06 10:47:51 <ftonello> github denies access when using ssh://
Jul 06 10:49:01 <rburton> the default protocol for git fetches is git
Jul 06 10:49:02 <rburton> not ssh
Jul 06 10:49:30 <ftonello> I am using protocol=ssh, because the git:// doesn't support the colon (:) which thinks is a port.
Jul 06 10:50:22 <ftonello> I remembered I solved this problems a long time ago, but I forgot, TBH.
Jul 06 10:50:54 <rburton> git: doesn't support authentication
Jul 06 10:50:57 <rburton> which is why that doesn't work
Jul 06 10:50:58 <rburton> use http?
Jul 06 10:51:20 <ftonello> yes. http requires http user and pass, which sucks.
Jul 06 10:51:28 <ftonello> Ok.
Jul 06 10:51:30 <rburton> ssh should work if you have keys that work
Jul 06 10:52:19 <ftonello> I do have, is just wrong path.
Jul 06 10:52:30 <ftonello> I have to use / instead of : for ssh://.
Jul 06 10:52:48 <ftonello> What happens is that when not specifying what protocol, git does it under the hood.
Jul 06 10:53:13 <rburton> remember the URI in a SRC_URI isn't exactly what git is given
Jul 06 10:54:11 <ftonello> Yes, I was checking.
Jul 06 10:54:29 <ftonello> To use github ssh URI on bitbake one needs to replace : with /
Jul 06 10:54:47 <ftonello> for example
Jul 06 10:55:03 <ftonello> github.com/private/repo.git;protocol=ssh;user=git
Jul 06 13:31:18 <realBigfoot> Does anyone know what would cause my rootfs to boot in Read Only?
Jul 06 13:43:55 <Minipada> Does someone know if there's a way to disable build flags for some packages ?
Jul 06 13:49:08 <bluelightning> realBigfoot: 'read-only-rootfs' in IMAGE_FEATURES ?
Jul 06 13:49:34 <bluelightning> realBigfoot: other than that, you'd have to look at your fstab and the boot log
Jul 06 13:49:47 <bluelightning> Minipada: which build flags do you mean?
Jul 06 13:51:00 <Minipada> For example O3 or ffast-math
Jul 06 13:53:25 <bluelightning> it depends on where those flags have actually come from
Jul 06 13:54:28 <bluelightning> i.e. it's trivial to override CFLAGS or CXXFLAGS or whatever per-recipe, but if those flags are being passed within the makefile for the particular piece of software for example, then that's more difficult to override
Jul 06 13:57:02 <Minipada> I don't know I'm doing the right thing, but these are not here by default, but I would like to apply it to the maximum packages possible, thus editing BUILD_OPTIMIZATION parameter and "disabling" it for packages who can't work with it
Jul 06 14:06:29 <int> hey guys
Jul 06 14:06:49 <int> is there a way to use absolete path in bbappend.conf file?
Jul 06 14:07:00 <int> I mean through the variable?
Jul 06 14:09:00 <bluelightning> int: absolute path in which variable ?
Jul 06 14:10:00 <int> bluelightning: can I user ${TOPDIR}/yocto instead of /home/user/yocto/poky/yocto in bbappend.conf file?
Jul 06 14:10:17 <bluelightning> int: certainly you can yes
Jul 06 14:10:46 <bluelightning> do you mean bblayers.conf ?
Jul 06 14:11:20 <int> bblayers yes
Jul 06 14:11:24 <int> sorry
Jul 06 14:12:10 <int> bluelightning: which variable can I user instead?
Jul 06 14:13:12 <bluelightning> int: I'm not sure I understand the question... ${TOPDIR} should work
Jul 06 14:14:22 <bluelightning> Minipada: perhaps you could do something similar to what meta/conf/distro/include/security_flags.inc does
Jul 06 14:14:40 <bluelightning> Minipada: i.e. has a default set of flags and then clears them for select recipes where they don't work
Jul 06 14:18:28 <btooth> some meta-mono guys here?
Jul 06 14:22:21 <int> bluelightning: thank you
Jul 06 14:23:32 <Minipada> Ok, I may do something like that. Thanks bluelightning
Jul 06 14:25:03 <btooth> i get: aclocal: error: 'configure.ac' is required -- seems to be related to: https://lists.yoctoproject.org/pipermail/yocto/2014-May/019818.html (Specifically master enables separate build dir by default in)
Jul 06 14:25:07 <btooth> autotools.bbclass whereas daisy doesn't
Jul 06 14:26:38 <bluelightning> btooth: see the migration section of the manual, specifically http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#moving-to-the-yocto-project-1.6-release
Jul 06 14:26:50 <bluelightning> er, actually http://www.yoctoproject.org/docs/current/ref-manual/ref-manual.html#migration-1.6-build-changes
Jul 06 14:27:20 <bluelightning> btooth: well, actually I guess that isn't so helpful
Jul 06 14:28:00 <btooth> bluelighning: back in the mailinglist thread they wrote: The simple way to fix this is to change
Jul 06 14:28:03 <btooth> 'inherit autotools' to 'inherit autotools-brokensep'
Jul 06 14:28:14 <btooth> i am going to try this
Jul 06 14:29:26 <bluelightning> right yes, that's what it mentions in the second link I posted above
Jul 06 14:31:09 <btooth> bluelightning: that solved it
Jul 06 14:32:15 <int> bluelightning: http://paste.pound-python.org/show/khOwUBgi4qXiORXXHjiw/
Jul 06 14:32:21 <int> it is not correct, right?
Jul 06 14:36:55 <bluelightning> int: maybe you're not aware, but TOPDIR effectively points to your build directory, that probably isn't what you're expecting I guess
Jul 06 14:41:29 <kergoth> morning
Jul 06 14:42:18 <bluelightning> morning kergoth
Jul 06 14:42:21 <kergoth> bluelightning: hey, congrats
Jul 06 14:42:28 <bluelightning> kergoth: thanks!
Jul 06 14:42:40 <kergoth> still a zombie?
Jul 06 14:43:21 <bluelightning> kergoth: actually she's sleeping reasonably well at the moment, thankfully
Jul 06 14:43:31 <kergoth> ah, nice :)
Jul 06 14:44:29 <bluelightning> luckily we've had parents around to help us over the last few weeks, otherwise it would have been much more painful
Jul 06 14:45:41 <rink_> oh, gratz bluelightning
Jul 06 14:45:47 <bluelightning> thanks
Jul 06 14:52:08 <int> bluelightning: ok, which variable can I use instead?
Jul 06 14:52:30 <bluelightning> int: which directory is it that you actually want?
Jul 06 14:53:07 <int> bluelightning: /home/user/yocto/poky
Jul 06 14:53:30 <int> in poky there are meta, meta-yocto, meta-yocto-bsp, etc
Jul 06 14:53:58 <bluelightning> ok... so ${COREBASE} might give you that
Jul 06 14:55:31 <int> bluelightning: ERROR: Unable to parse ${COREBASE}/meta/conf/layer.conf: file ${COREBASE}/meta/conf/layer.conf not found in /home/vadimi/yocto_jenkins/poky/build
Jul 06 14:56:01 <bluelightning> oh right... that's set in layer.conf, so that's not going to work
Jul 06 14:56:45 <bluelightning> layer.conf in meta/conf/ that is
Jul 06 14:57:11 <bluelightning> if you really absolutely must have this done through a variable, I would suggest you set one yourself - if you want you can set one externally and add it to BB_ENV_EXTRAWHITE (again externally) and it'll come through into bitbake's environment
Jul 06 15:04:06 <kergoth> you can use a template with TEMPLATECONF, then ##OEROOT## will be substituted as th epath to corebase
Jul 06 15:18:36 <ftonello> I just sent a patch to bitbake regarding gitsm, if anyone can have a look if it makes sense.
Jul 06 15:18:43 <ftonello> I appreciate.
Jul 06 15:35:40 <kergoth> ftonello: that patch will result in git mirror tarballs not including the submodules, so it'll be impossible to build with BB_NO_NETWORK=1
Jul 06 15:35:47 <kergoth> since fetch won't fetch them
Jul 06 15:36:00 <kergoth> afaict anyway
Jul 06 15:36:32 <kergoth> and fetching something from a remote in unpack is not kosher, thhat's what fetch is for
Jul 06 15:36:52 <rburton> kergoth: reply to the list too please :)
Jul 06 15:37:00 <kergoth> yeah, iw as just thinking that :)
Jul 06 15:37:13 <joshuagl> halstead: rburton: RP: I just had a builder fail on disk space
Jul 06 15:37:14 <joshuagl> https://autobuilder.yoctoproject.org/main/builders/nightly-mips/builds/383/steps/Building%20Toolchain%20Images_1/logs/stdio
Jul 06 15:37:32 <rburton> yeah, its getting space back again now
Jul 06 15:37:41 <joshuagl> ah, OK
Jul 06 15:37:51 * joshuagl may never see a succesful build run on the ab :-(
Jul 06 15:38:59 <halstead> joshuagl, Plenty now. I'm going to start clearing based on space/number of builds instead of time.
Jul 06 15:39:16 <halstead> joshuagl, Which will work much better.
Jul 06 15:39:41 <joshuagl> halstead: indeed, that does sound like it'll work better
Jul 06 15:40:18 <joshuagl> looks like I need to find a fix for oe-selftest before I trigger another fido-next build anyway
Jul 06 15:42:35 <rburton> joshuagl: check master, theres lots of fixes there :)
Jul 06 15:44:43 <joshuagl> rburton: aye, I plan to
Jul 06 15:46:07 <kergoth> bluelightning: I'm sure you have a fair bit of stuff to catch up on, but just so it's on your radar, if you could look at the merged recipetool appendsrc patches and the not-yet-merged recipetool patches which let it pull plugins from BBPATH, would appreciate it. still need to write tests for appendsrcfile{,s} for oe-selftest though, forgot about that :)
Jul 06 15:46:34 <bluelightning> kergoth: ah yes that is definitely on my todo list, should be able to get to it soon
Jul 06 15:46:35 <rburton> kergoth: i think the unmerged bits are in mut, but the ab has been a bit funky recently
Jul 06 15:46:44 <kergoth> rburton: ah, np
Jul 06 15:46:55 <kergoth> hmm, need to play with devtool's update-recipe —append, haven't tried that, but remember wanting it when i was playing with it last :)
Jul 06 15:46:58 <kergoth> bluelightning: cool, thanks
Jul 06 15:47:23 <bluelightning> I believe there's a bug open for the plugins in multiple layers thing, so we should probably add that to the commit message
Jul 06 15:47:32 <kergoth> ah, didn't realize
Jul 06 15:47:53 <bluelightning> https://bugzilla.yoctoproject.org/show_bug.cgi?id=7625
Jul 06 15:47:54 <yocti> Bug 7625: enhancement, Medium, 1.9, paul.eggleton, NEW , Add support for devtool/recipetool plugins in additional layers
Jul 06 15:48:04 <bluelightning> it covers devtool as well though so I guess it's half of that ;)
Jul 06 15:48:25 <kergoth> cool. it was pretty straightforward, other than the argument parsing thing — had to split that up in order to get the —debug arg before the plugins were available
Jul 06 15:48:27 <ftonello> kergoth: Yes, I see. I just replied there..
Jul 06 15:50:52 * kergoth ponders
Jul 06 15:51:29 <bluelightning> I just learnt that you can refer to bitbake vars as python vars in in-line python
Jul 06 15:51:58 <bluelightning> kergoth: apparently you implemented that :)
Jul 06 15:52:43 <kergoth> Indeed :) Hmm, I'm not actually sure if the checksumming code properly captures those as variable dependencies, though, better check that before using it too much :)
Jul 06 15:53:05 <rburton> bluelightning: as in literal ${FOO} gets expanded at parse?
Jul 06 15:53:15 <bluelightning> rburton: ${@FOO} yes
Jul 06 15:53:34 <bluelightning> I stumbled across it in os-release.bb and thought "how can that possibly work?"
Jul 06 15:53:56 <rburton> bitbake needs a way to escape the $, very annoying when you're trying to write files containing ${FOO} statements :)
Jul 06 15:54:15 <bluelightning> it's not the only thing we cannot escape... , in PACKAGECONFIG springs to mind
Jul 06 15:54:41 <rburton> bluelightning: that VERSION assignment is just line noise
Jul 06 15:55:10 <rburton> if i read it a third time, maybe it will make sense
Jul 06 15:56:37 <kergoth> DISTRO_CODENAME is placed in parens after the version if the variable exists in the metadata, since DataSmart supports __contains__, but it should probably have been based on its value, otherwise you can't use the empty string to undo its set, you'd have to use delVar
Jul 06 15:56:47 * kergoth yawns
Jul 06 15:57:18 <bluelightning> right, that's just what I mentioned in my reply to someone on the yocto list
Jul 06 15:57:19 <kergoth> ah, that's what the email was about :)
Jul 06 15:57:23 <bluelightning> :)
Jul 06 15:57:42 <rburton> yeah on the third read i realised that the ${@ is a python trinary test
Jul 06 15:58:19 <kergoth> heh, i much prefer the inline if statements to how we used to do it.. remember indexing an inline array based on a boolean state?
Jul 06 15:58:21 * kergoth shudders
Jul 06 15:58:44 <bluelightning> those variable names are a little... poorly name-scoped as well, perhaps should have picked that up on review
Jul 06 15:58:58 <rburton> kergoth: indexing an inline array was… disgusting
Jul 06 15:59:14 <bluelightning> kergoth: yeah those definitely took multiple reads to figure out what was going on
Jul 06 15:59:26 <bluelightning> we may even still have those in the metadata in places
Jul 06 15:59:37 <bluelightning> brb
Jul 06 15:59:43 <kergoth> most of those variables are un-prefixed since they're not ?=, intended to be isolated to the recipe / set via bbappend. but its a fair point, i don't think many folks cared about os-release at the time i submitted it
Jul 06 16:01:11 <kergoth> that's odd, it looks like a patch to os-release was applied twice, or something. i'm seeing two of the comments about the valid fields, and two of the noexecs on patch/configure
Jul 06 16:02:18 <bluelightning> kergoth: hmm, I can't see that in either poky or OE-Core... ?
Jul 06 16:02:34 <rburton> me neither
Jul 06 16:03:13 <kergoth> huh, weird, terminal refresh artifact. nevermind :)
Jul 06 16:06:13 <ftonello> kergoth, rburton: Sent another patch, which works with previous implementation.
Jul 06 16:25:58 <ryansturmer> Hi everyone, I'm getting started building an image for the Intel Edison
Jul 06 16:27:35 <ryansturmer> I'm not a stranger to LFS or to Embedded Linux, but I am new to Yocto - is there a preferred starting point for working with the Edison?  I see that intel provides a source build that - includes yocto somehow - is that the preferred place to start?
Jul 06 16:28:34 <david1> I started with their work, and their makefiles just to understand how it worked and I then switched to a normal yocto architecture
Jul 06 16:28:50 <ryansturmer> I have cloned poky and done a test build without changing any of the default settings, and am having some difficulty figuring out where to go next to configure things.
Jul 06 16:29:19 <Crofton|work> what are you trying to change?
Jul 06 16:30:32 <ryansturmer> Well, I'd like to do some customization to the file systems that are used and the packages that are installed
Jul 06 16:30:45 <ryansturmer> For instance, booting with a read-only root FS
Jul 06 16:31:40 <ryansturmer> So compiling the image from scratch with my preferred packages and filesystem configuration is attractive
Jul 06 16:32:29 <kergoth> that's documented. usually done from <build dir>/conf/local.conf. EXTRA_IMAGE_FEATURES += "read-only-rootfs". I'm actually surprised the existing section about image features in the local.conf doesnt' mention that feature
Jul 06 16:32:39 <kergoth> still, read local.conf, which has many examples of cnfiguration, and the yocto project documentation
Jul 06 16:32:47 <ryansturmer> oh that's nice!
Jul 06 16:33:29 <ryansturmer> So, the best thing to do would be to start with intel's package, rather than cloning yocto and working my way into it from there?
Jul 06 16:33:46 <kergoth> https://www.yoctoproject.org/docs/1.8/mega-manual/mega-manual.html#usingpoky-extend-customimage-imagefeatures
Jul 06 16:34:02 <kergoth> not sure on that one, guessing the intel folks would know the answer to that better than i
Jul 06 16:34:15 <rburton> intel's bsp is yocto based, and you;ll need the right BSP if you actually want to run anything on the edison...
Jul 06 16:34:26 <rburton> (for the kernel, drivers, etc)
Jul 06 16:41:27 <ryansturmer> I'm running their makefile now, it looks like their thing is just a recipe, and a script that goes and clones poky, puts it in the right place, and runs the build
Jul 06 16:42:41 <david1> yep exactly ryansturmer. It also set some variables in the local.conf
Jul 06 16:42:57 <ryansturmer> Ah gotcha
Jul 06 16:43:15 <ryansturmer> What is the difference between a BSP and a recipe?
Jul 06 16:44:00 <ryansturmer> The terms BSP, recipe, layer all run togehter for me - a recipe is instructions for making a single package, and a layer is a bunch of recipes?
Jul 06 16:44:09 <ryansturmer> and a bsp is a collection of layers and other stuff?
Jul 06 16:44:35 <david1> The BSP layer contains hardware specific configuration and recipes
Jul 06 16:45:20 <david1> A layer is just ... a layer, it can be hardware, software, for a middleware etc.
Jul 06 16:45:49 <david1> It's a group of packages you get from recipes (someone stops me if I'm wrong)
Jul 06 16:46:07 <ryansturmer> So a layer is a bunch of recipes, and a BSP is really just a layer that contains the recipes for a specific hardware implementation
Jul 06 16:46:50 <david1> Yes
Jul 06 16:50:10 <ryansturmer> Ok - complete tangent - anyone used toaster?  I got it setup and played with it some, it seems neat
Jul 06 16:51:41 <rburton> toaster is awesome!!!!
Jul 06 16:51:52 <rburton> <disclaimer: i work with the people who wrote it>
Jul 06 16:52:14 <Crofton|work> rburton, do you use it?
Jul 06 16:52:43 <ulf`> I like my toaster
Jul 06 16:52:46 <Crofton|work> (serious question)
Jul 06 16:53:05 <belen1> yes, rburton: serious question ;)
Jul 06 16:53:42 * Crofton|work does need to remember how to run it
Jul 06 16:54:18 * Crofton|work needs to find out what he did with all his disk space first
Jul 06 16:55:20 <ryansturmer> My toaster installation keeps prompting me to configure a layer source
Jul 06 16:55:27 <rburton> Crofton|work: terminal from cold dead hands etc
Jul 06 16:55:35 <Crofton|work> yeah
Jul 06 16:55:39 <Crofton|work> I understand
Jul 06 16:55:52 <rburton> now if only it had awesome analytics
Jul 06 16:55:56 <belen1> ryansturmer: are you using master or fido?
Jul 06 16:55:58 <ryansturmer> which I believe I did, and I'm not sure I fully understand the whole layer source thing
Jul 06 16:56:00 <ryansturmer> fido
Jul 06 16:56:58 <belen1> ryansturmer: a layer source is just a collection of layers. Toaster comes with a configuration file that sets up the layer source at layers.openembedded.org
Jul 06 16:57:25 <belen1> ryansturmer: but you need to make you to import that configuration file when setting up Toaster
Jul 06 16:57:34 <ryansturmer> When I go to "view compatible machines" it says "configure a layer source" which I have done, using toasterconf.json during the install process
Jul 06 16:58:22 <ryansturmer> I did tell it to use that file, and if I go to the django admin, it has a few layer sources listed, including the openembedded one
Jul 06 16:58:43 <ryansturmer> the openembedded one looks like the only "remote" source, and the other two just point to directories on disk
Jul 06 16:59:18 <belen1> ryansturmer: mmm, something has gone wrong. Maybe it failed to import the information from the layer source. If you click to view compatible layers, do you have any?
Jul 06 17:03:32 <ryansturmer> if I choose "view all compatible layers" from the project configuration area on a fresh project
Jul 06 17:03:42 <ryansturmer> I get a list of 70 layers
Jul 06 17:03:57 <ryansturmer> release is set to 1.8 fido
Jul 06 17:04:12 <belen1> ryansturmer: that sounds about right. What if you click on 'view compatible recipes'?
Jul 06 17:06:39 <ryansturmer> toaster has no recipe information
Jul 06 17:07:01 <ryansturmer> to get recipes, configure a layer source, or import a thing and do a stuff
Jul 06 17:07:09 <belen1> ryansturmer: are you sure you haven't cloned the yocto project master branch?
Jul 06 17:07:21 <ryansturmer> hell no I'm not sure of that :)
Jul 06 17:07:23 <ryansturmer> lemme check
Jul 06 17:07:32 <belen1> ryansturmer: we have a bug in master that causes that problem, but it should work if you use the fido release instead
Jul 06 17:07:47 <ryansturmer> i should be on the fido branch, right?
Jul 06 17:08:02 <ryansturmer> or is there a release branch other than the one just called "fido"
Jul 06 17:08:58 <belen1> ryansturmer: it's a bit confusing. Toaster supports building with several releases through the project release selection trick, but you need to run Toaster itself using a certain release
Jul 06 17:09:33 <ryansturmer> so I need to pass something to toaster when I invoke it, or edit a config file?
Jul 06 17:09:45 <ryansturmer> just being on the fido branch isn't enough?
Jul 06 17:10:10 <belen1> ryansturmer: no. You need to clone the fido branch of the yocto project and set up Toaster with that.
Jul 06 17:10:34 <belen1> ryansturmer: purely because Toaster is broken in master right now. We broke it last week and we are still trying to fix it :)
Jul 06 17:12:07 <belen1> ryansturmer: but if you cloned the fido branch of the yocto project and set up Toaster with that, and you are still seeing this problem, then we have an issue we didn't know about, and we should look into
Jul 06 17:15:10 <realBigfoot> We got some yocto recpies repository. Does it make sense to have a license file on the recipes ?
Jul 06 17:16:11 <ryansturmer> so, I have never been on the master, so far as I know. I cloned fido, and configured with fido
Jul 06 17:16:22 <ryansturmer> I will try again from scratch to reproduce my issue for you, if that is helpful.
Jul 06 17:18:37 <belen1> ryansturmer: Yes please. That would be really helpful
Jul 06 17:21:51 <ryansturmer> good time to mention im not on a "supported" linux distro
Jul 06 17:30:56 <ryansturmer> ah
Jul 06 17:31:04 <ryansturmer> I did not notice this error message on toaster first run last time
Jul 06 17:31:06 <ryansturmer> Cannot find layer version  OpenEmbedded (1) 65 fido
Jul 06 17:31:07 <ryansturmer> Failure while trying to import the toaster config file: Layer_Version matching query does not exist.
Jul 06 17:37:26 <kergoth> realBigfoot: yes. do you mean the license of the recipes themselves rather than the projects the recipes refer to?
Jul 06 17:37:35 <kergoth> usually that's MIT
Jul 06 17:37:52 <kergoth> (doesn't have to be, though, just easy since they're usually trivial)
Jul 06 17:37:57 <realBigfoot> kergoth, yes.. Nice! This is the license we were planing to put it
Jul 06 17:44:13 <ryansturmer> If there is any further toaster error information I can provide, let me know.
Jul 06 17:44:30 <ryansturmer> I am diverting temporarily to go build with the intel makefile
Jul 06 17:44:40 <ryansturmer> but I can pick it back up again
Jul 06 17:47:03 <Crofton|work> hmm, opening page of toaster still refers to hob
Jul 06 17:47:32 <kergoth> heh
Jul 06 17:48:03 <Crofton|work> hmm
Jul 06 17:48:12 <Crofton|work> I run toaster, not I can't tun bitbake
Jul 06 17:48:37 <Crofton|work> wtf?
Jul 06 17:50:18 <Crofton|work> toaster started bibtake server
Jul 06 18:46:35 <belen1> ryansturmer: Thanks! That means the problem might be on the OE layer source.
Jul 06 18:49:13 <belen1> Crofton|work: well, if you are running Toaster in 'analysis' mode, yes it does.
Jul 06 18:49:13 <belen1> http://www.yoctoproject.org/docs/1.8/toaster-manual/toaster-manual.html#intro-modes
Jul 06 18:49:52 <belen1> Crofton|work: because you cannot build with Toaster if you are running it that way
Jul 06 18:59:14 <kergoth> Hmm, I wonder if oe selftest unit tests can be loaded from external / layer locations, so i could write unit tests for the MEL layer-local kernel recipetool subcommands
Jul 06 19:00:54 <Crofton|work> belen1, I was following instructinos :)
Jul 06 19:05:27 <belen1> Crofton|work: I was just talking about the Hob thing :)
Jul 06 19:07:02 <Crofton|work> belen1, I started toaster, but it wouldn't let me run bitbake, claimed bitbake was already running
Jul 06 19:08:13 <kergoth> Crofton|work: are you running in the context where toaster was started? iirc it sets env vars so bitbake acts as a client with the bitbake server it starts rather than starting a server itself. course thats speaking as someone who knows jack about toaster, so i might be completely wrong :)
Jul 06 19:08:15 <kergoth> hmmm
Jul 06 19:08:40 <Crofton|work> yeah, I jsut did what it said on the wiki and it started the bitbaek server
Jul 06 19:09:11 <Crofton|work> I'll poke more later, jsut wanted to see how it had changed since I last ran it
Jul 06 19:09:19 <kergoth> iirc the wiki has you source the thing, if you changed terminals....
Jul 06 19:09:29 * kergoth shrugs, admittedly speaking from ignorance, should know better than to do that :)
Jul 06 19:10:00 <belen1> Crofton|work: I wouldn't follow the wiki. We have a manual now! :)
Jul 06 19:10:01 <belen1> http://www.yoctoproject.org/docs/1.8/toaster-manual/toaster-manual.html
Jul 06 19:10:05 <Crofton|work> ah, I changed terminals :)
Jul 06 19:11:05 <belen1> kergoth: I wouldn't be too worried. I know nothing myself ;)
Jul 06 19:11:08 <kergoth> so its trying to start a second server against the same build dir, probably
Jul 06 19:11:10 <kergoth> hah :)
Jul 06 19:12:30 <belen1> Crofton|work: we should really get rid of those instructions in the wiki. I might get to that tomorrow
Jul 06 21:08:51 <kergoth> Hmmm, should add a recipetool sub-command which simply creates a bbappend in the specified layer for the specified recipe/provide, and prints the path to it, as a convenience when making changes other than those recipetool does for you
Jul 06 21:11:46 <rburton> yes
Jul 06 21:39:58 <ryansturmer> so I've run into a build issue with yocto and I'm struggling with what to do next.  My build for the intel edison passed, save for ncurses and pseudo
Jul 06 21:40:30 <ryansturmer> What's the procedure for sorting this out - do I find a patch and add it to the recipe in the yocto tree?
Jul 06 21:42:23 <rburton> first step is usually to say what the problem is and see if its something we can help with
Jul 06 21:42:36 <rburton> pseudo not working is fairly fundamental to packages being built at all though
Jul 06 21:42:43 * rburton has to go now though
Jul 06 21:52:45 <ryansturmer> Alrighty
Jul 06 21:52:50 <ryansturmer> well, here's the paste of my output:
Jul 06 21:52:52 <ryansturmer> http://pastebin.com/T7iRX2HB
Jul 06 21:53:43 <ryansturmer> This was a subsequent build - the first build took a long time, and it looks like many tasks completed
Jul 06 21:54:21 <ryansturmer> This one was quick, but reported failures in the same two recipes
Jul 06 21:56:16 <ryansturmer> I was not familiar with pseudo, but yeah, it looks essential, not sure why so much seemed successful without it?
Jul 06 22:05:51 <ryansturmer> It looks like with ncurses, that this is perhaps a known issue with the newest version
Jul 06 22:06:12 <ryansturmer> I wonder if there's a way to convince it to use an older one
Jul 06 22:25:37 <vmrod25> question .. does any one have being able to make a webcam works on Yocto ?
Jul 06 22:32:31 <nerdboy> do you have the right module(s) enabled?
Jul 06 22:33:15 <nerdboy> depending on camera driver you might need vendor fork/patch for all i know...
Jul 06 22:33:38 <nerdboy> *if you're talking yocto kernel
Jul 07 01:02:01 <tanamo> Hello guys, I have a problem with psplash, well it wont work during boot because /dev/fb0 is missing, because the order of scripts is start psplash first then run udev,
Jul 07 01:02:15 <tanamo> obviously psplash works during shutdown,
Jul 07 01:02:49 <tanamo> now my question is how to make it work during boot?
Jul 07 01:50:29 <ryansturmer> tanamo: what platform are you running
Jul 07 02:05:26 <tanamo> ryansturmer: do you mean hardware? an intel-based mini pc
Jul 07 02:06:13 <ryansturmer> yeah
Jul 07 02:06:51 <ryansturmer> I am new to yocto, so I may be of limited use
Jul 07 02:07:05 <ryansturmer> are you using uboot?
Jul 07 02:07:51 <tanamo> i dont use uboot as far as I know
Jul 07 02:08:34 <tanamo> uboot is similar to grub right?
Jul 07 02:08:47 <tanamo> my boot loader is extlinux/syslinux
Jul 07 02:12:11 <tanamo> when you boot your yocto, is there a boot splash image? or just text scrolling?
Jul 07 02:20:39 <ryansturmer> My system is headless
Jul 07 02:21:03 <ryansturmer> does your system use an initramfs?
Jul 07 02:22:14 <ryansturmer> (sorry, again, I'm new - but I do a fair bit of embedded stuff, so I might be able to help anyone - and I'm here :)
Jul 07 02:22:31 <ryansturmer> **anyway
Jul 07 02:30:47 <tanamo> i tried using initramfs but it wont boot, maybe im using initramfs wrong,
Jul 07 02:31:07 <tanamo> but i use ramdisk
Jul 07 02:32:24 <tanamo> i tried to use core-image-minimal-initramfs as my initramfs
Jul 07 02:32:45 <tanamo> but it didnt work, i dont know what i was doing actually haha
Jul 07 02:33:52 <tanamo> im not sure if i can use initramfs because I also use ramdisk (i dont install yocto on the hd)
Jul 07 02:37:05 <ryansturmer> is it possible for you to paste the console output at boot?
Jul 07 02:46:19 <tanamo> is tmpfs the initramfs?
Jul 07 02:47:05 <tanamo> bec the psplash script is mounting it,  ( mount tmpfs -t tmpfs TMPDIR -o,size=40k )
**** ENDING LOGGING AT Tue Jul 07 02:59:58 2015