**** BEGIN LOGGING AT Mon Jun 10 02:59:58 2013
Jun 10 07:35:34 <panda84kde> Morning everybody. Suppose I have a license which is not in this list https://wiki.yoctoproject.org/wiki/License_Infrastructure_Interest_Group#Licenses , in my case this one: https://github.com/rafalmiel/glmark2-wl/blob/master/COPYING.SGI
Jun 10 07:35:47 <panda84kde> what should I put in the LICENSE field in my recipe?
Jun 10 08:31:47 <bluelightning> morning all
Jun 10 08:35:45 <mckoan> good morning
Jun 10 08:54:08 <agherzan> EsbenH_:
Jun 10 08:54:14 <agherzan> EsbenH_: sorry
Jun 10 08:54:20 <agherzan> Hello all.
Jun 10 08:54:56 <bluelightning> hi agherzan
Jun 10 08:55:07 <agherzan> I spotted a bashism (or something that behaves wrongly in dash). Is there anybody willing to test and give me a hint fix?
Jun 10 08:55:19 <bluelightning> agherzan: if I can, sure
Jun 10 08:55:25 <agherzan> bluelightning: great
Jun 10 08:56:02 <agherzan> just bake an image where you include the systemd package udev-hwdb having dash as sh.
Jun 10 08:56:10 <agherzan> Tell me if it fails.
Jun 10 09:10:07 <agherzan> bluelightning: that was the build? #162?
Jun 10 09:10:58 <agherzan> bluelightning: (realized the answer: no - checked timing)
Jun 10 10:50:46 <ChristianBS> Hi. Anyone here working on qmx6 ?
Jun 10 11:16:04 <agherzan> ChristianBS: imx6q?
Jun 10 12:46:17 <otavio> ChristianBS: Hello
Jun 10 12:46:28 <otavio> ChristianBS: from Congatec?
Jun 10 12:53:03 <ChristianBS> Nope
Jun 10 12:53:26 <ChristianBS> otavio:
Jun 10 12:57:52 <otavio> ChristianBS: so which som is it?
Jun 10 12:57:54 <rao_> hihi
Jun 10 12:58:11 <otavio> ChristianBS: The only qmx6 SOM I know is from Congatec IIRC
Jun 10 12:58:28 <otavio> ChristianBS: and it is supported by meta-fsl-arm-extra
Jun 10 13:00:22 <rao_> can anyone tel me basics of creating an SDK for some project in yocto?
Jun 10 13:03:11 <bluelightning> rao_: easiest method is: bitbake -c populate_sdk imagename
Jun 10 13:05:16 <rao_> thank you  . i tried the same command and installed the sdk in some target directory. it contains one sysroot and some script files. Now i am totally confused what to do with those files and how i can basically use it? pls help me
Jun 10 13:05:53 <rao_> is there any possible way that i can emulate it Using QEMU?
Jun 10 13:14:25 <ChristianBS> otavio: yup its indeed the conga som. Have you tried using the *-x11 libs from the vivante blob and gotten them working on x11?
Jun 10 13:15:06 <otavio> ChristianBS: I don't have the Congatec SOM here; they never sent it to me so I cannot help on it
Jun 10 13:15:23 <ChristianBS> got another board that you used the vivante libs on?
Jun 10 13:15:29 <otavio> ChristianBS: it works in other i.MX6 boards (with known issues)
Jun 10 13:15:56 <ChristianBS> otavia: known issues = undefined symbols in the vivante_dri causing it fallback to mesa?
Jun 10 13:16:12 <otavio> ChristianBS: yes; for windowed mode, yes
Jun 10 13:16:22 <otavio> ChristianBS: but fullscreen mode works
Jun 10 13:17:08 <otavio> ChristianBS: It'd be great if you could e-mail the mailing list so others can help.
Jun 10 13:17:52 <otavio> ChristianBS: and I also would like to backport the U-Boot support for it, so it'd be great if you could test it as well.
Jun 10 13:18:32 <ChristianBS> otavio: i'll try to post it on the mailing list aswell
Jun 10 13:19:32 <ChristianBS> otavio: how to ensure I run it in fullscreen?
Jun 10 13:22:53 <otavio> ChristianBS: I am not a GPU guy; panda84kde is a better guy to help here.
Jun 10 14:06:27 <panda84kde> ChristianBS: hi
Jun 10 14:07:19 <ChristianBS> panda84kde: hi
Jun 10 14:09:37 <panda84kde> I don't have problems with software fallback; I have problems with wrong 3D rendering
Jun 10 14:10:25 <ChristianBS> okay. Are you able to display e.g. the vivante demos using the -x11 libs?
Jun 10 14:11:21 <panda84kde> they start and run without errors on the command line, but they display only white windows
Jun 10 14:11:45 <ChristianBS> and you absolutely certain thats it not mesa your using?
Jun 10 14:14:25 <ChristianBS> when X starts, it attempts to start the vivante x11 driver, but (atleast for me) fails. If mesa is present, it fallbacks to using software rendering.
Jun 10 14:16:02 <panda84kde> es2info reports Vivante Driver is being used
Jun 10 14:17:01 <panda84kde> yes, I'm sure. Freescale's Ubuntu has the same problem as Yocto
Jun 10 14:17:07 <ChristianBS> Could I ask you to post a dump of the /var/log/Xorg.log ?
Jun 10 14:18:37 <panda84kde> ChristianBS: ok, just a minute
Jun 10 15:01:37 <davest> Good morning, #yocto!
Jun 10 15:03:26 <bluelightning> davest: good morning!
Jun 10 15:08:21 <sgw_> anyone else getting mail bounces: 5.1.2 - Bad destination host "DNS Hard Error looking up yoctoproject.org' (MX):  NXDomain"
Jun 10 15:11:45 <Crofton|work> dig works for me
Jun 10 15:12:09 <Crofton|work> davest, we gave up and all started using buildroot while you were gone!
Jun 10 15:13:28 <Crofton|work> and RP took up professional motorcycle racing
Jun 10 15:41:31 <RP> Crofton|work: :)
Jun 10 15:59:54 <Saur> I'm experiencing something odd with building an image. I have added systemd to DISTRO_FEATURES, but have not added it to IMAGE_INSTALL. Now if I build my image it includes udev 182 (i.e., the non-systemd version). However, if I explicitly add udev to IMAGE_INSTALL it installs udev 199 (i.e., the systemd version). Any explanation?
Jun 10 16:03:33 <bluelightning> Saur: have you set VIRTUAL-RUNTIME_init_manager ?
Jun 10 16:05:38 <Saur> bluelightning: Nope (as I said systemd is not yet installed, still working on that). I was just confused why explicitly adding udev to IMAGE_INSTALL would make a difference as a udev package is installed in both cases.
Jun 10 16:06:37 <bluelightning> Saur: I'm not entirely sure how that would come about either; it may have to do with udev being brought in through some other dependency
Jun 10 16:07:45 <Saur> bluelightning: Yeah, but PREFERRED_PROVIDER_udev == "systemd" (duse to systemd being in DISTRO_FEATURES), which is why I don't get what's happening...
Jun 10 16:07:58 <Saur> due to*
Jun 10 16:09:37 <bluelightning> Saur: what package management backend are you using? (ipk/rpm/deb)
Jun 10 16:09:48 <Saur> bluelightning: rpm
Jun 10 16:11:09 <bluelightning> Saur: was it a clean build from scratch after changing DISTRO_FEATURES or an existing TMPDIR?
Jun 10 16:12:30 <Saur> bluelightning: An existing...
Jun 10 16:16:05 <bluelightning> Saur: typically we recommend clearing out your TMPDIR after changing DISTRO_FEATURES
Jun 10 16:16:16 <Saur> Now you tell me ;)
Jun 10 16:16:53 <Saur> bluelightning: Wouldn't it just recreate from the sstate cache though?
Jun 10 16:20:52 <bluelightning> Saur: the parts that don't include DISTRO_FEATURES in their signature, yes
Jun 10 16:23:18 <bluelightning> Saur: the safest option is not to keep that either I suspect
Jun 10 16:25:39 <mranostay> morning...
Jun 10 16:25:54 <Saur> bluelightning: Guess it's finally time to create a distro configuration and stop relying on poky.conf...
Jun 10 16:26:30 <bluelightning> Saur: if you're wanting to do customisation at that level I would recommend that yes
**** BEGIN LOGGING AT Mon Jun 10 16:51:49 2013
Jun 10 18:43:26 <kergoth> RP: could use your thoughts on https://bugzilla.yoctoproject.org/show_bug.cgi?id=4634 whenever you have a chance.
Jun 10 18:43:27 <yocti> Bug 4634: normal, Undecided, ---, richard.purdie, NEW , BitBake default 'dirs' in exec_func (${B}) causes build failures
Jun 10 19:27:12 <ftonello> what do I have to do to update the rpm metadata in tmp/deploy/rpm?
Jun 10 19:27:52 <ftonello> because I'm building a recipe, it installs packages into tmp/deploy/rpm but when I do smart update, I don't get any new packages, which means the metadata inside the repodata/ is not been updated
Jun 10 20:15:29 <Ryan777> Hi Everyone.  Definitely a new guy with yocto, and have everything running, but now trying to install chromium.  Having some issues, here's what I get:
Jun 10 20:15:34 <Ryan777> ryan@Ryan:~/fsl-community-bsp/build$ bitbake chromium
Jun 10 20:15:34 <Ryan777> Loading cache: 100% |###############################################################################################################################################################################| ETA:  00:00:00
Jun 10 20:15:34 <Ryan777> Loaded 1711 entries from dependency cache.
Jun 10 20:15:34 <Ryan777> ERROR: No recipes available for:
Jun 10 20:15:34 <Ryan777>   /home/ryan/fsl-community-bsp/sources/meta-browser/recipes-gnome/gnome-settings-daemon/gnome-settings-daemon_2.32.1.bbappend
Jun 10 20:15:37 <Ryan777>   /home/ryan/fsl-community-bsp/sources/meta-browser/recipes-support/nspr/nspr_4.9.6.bbappend
Jun 10 20:15:39 <Ryan777>   /home/ryan/fsl-community-bsp/sources/meta-browser/recipes-graphics/libxi/libxi_1.7.1.bbappend
Jun 10 20:15:41 <Ryan777> ERROR: Command execution failed: Exited with 1
Jun 10 20:15:43 <Ryan777> Summary: There were 2 ERROR messages shown, returning a non-zero exit code.
Jun 10 20:25:47 <kergoth> Ryan777: sounds like a branch mismatch (e.g. using master meta-browser with dylan oe-core/poky) or meta-browser is just out of date wrt upstream.
Jun 10 20:36:37 <mranostay> pastebin!
Jun 10 20:41:03 <bluelightning> meta-browser should stop bbappending things...
Jun 10 20:43:52 <kergoth> that does seem odd, indeed
Jun 10 20:56:20 <Garibaldi|work> hi folks.  I'm trying to use the 'archive-patched-source' class to get an srpm of the sources for all my packages (including the patches).  However, when I build my target, I don't get srpms, I get only xxx.diff.gz and xxx.showdata.dump.  Is there some knob that I should be adjusting and am not?
Jun 10 20:57:07 <Garibaldi|work> I've set ARCHIVER_MODE = "patched", ARCHIVER_MODE[type] = "srpm"
Jun 10 20:57:10 <Garibaldi|work> in local.conf
Jun 10 20:57:28 <Garibaldi|work> Also SOURCE_ARCHIVE_PACKAGE_TYPE = "srpm"
Jun 10 20:58:05 <kergoth> SOURCE_ARCHIVE_PACKAGE_TYPE is set basd on ARCHIVER_MODE[type] by default, both should be redundant, but not harmful
Jun 10 20:58:34 <kergoth> hmm
Jun 10 20:58:43 * kergoth shrugs, never tried to use the srpm stuff personally, hopefully someone else has
Jun 10 20:59:39 <Garibaldi|work> maybe I'll give the tar variety a go, but the srpm would be nice —we have some automated tool that accepts srpms
Jun 10 21:09:31 <bluelightning> Garibaldi|work: I think you should be setting ARCHIVE_TYPE and not ARCHIVER_MODE[type]
Jun 10 21:10:32 * kergoth still rather dislikes the archiver.bbclass use semantics, confusing
Jun 10 21:10:38 <bluelightning> yes :/
Jun 10 21:10:47 <bluelightning> actually it's not ARCHIVE_TYPE
Jun 10 21:11:22 <bluelightning> SOURCE_ARCHIVE_PACKAGE_TYPE, as you said
Jun 10 21:11:27 <bluelightning> *grumble*
Jun 10 21:12:10 <kergoth> it's a weird hodgepodge of INHERIT-based choices, flags, and actual variables
Jun 10 21:12:12 <kergoth> heh
Jun 10 21:12:40 <bluelightning> honestly I think we need to clean it up, this is too complicated
Jun 10 21:13:53 <kergoth> there's a fair bit of non-idiomatic python in the implementation that makes it harder to read/grasp than necessary, too
Jun 10 21:13:56 <kergoth> heh
Jun 10 21:14:00 <kergoth> </complaining>
Jun 10 21:20:34 <Garibaldi|work> so the 'tar' type worked where the 'srpm' didn't
Jun 10 21:21:00 <Garibaldi|work> I'm now getting xxx-patched.tar.gz
Jun 10 21:22:49 <Garibaldi|work> but then, I removed SOURCE_ARCHIVE_PACKAGE_TYPE; maybe me having had set it caused some problems for srpm
Jun 10 21:37:11 <Garibaldi|work1> yeah, ARCHIVER_MODE[type] = "tar" works, = "srpm" doesn't :-(
Jun 10 21:38:53 <Garibaldi|work> with srpm, I get only xxx.showdata.dump and xxx.diff.gz
Jun 10 21:39:37 <Garibaldi|work> and some -script-logs.tar.gz
Jun 10 21:43:49 <bluelightning> Garibaldi|work: looking at the implementation to be honest I can't see how it could create srpms despite claiming to do so...
Jun 10 21:44:31 <Garibaldi|work> bluelightning: yeah, I'm looking at the same
Jun 10 21:46:02 <Garibaldi|work> tar it is then :-)
**** ENDING LOGGING AT Tue Jun 11 02:59:58 2013