**** BEGIN LOGGING AT Mon Aug 17 02:59:58 2015 Aug 17 05:56:18 Hi guys. I'd like to work with Kontron COMe board under Yocto. So, I'm looking for BSP meta layer (I guess). Can you please point me to the right direction? 10x. Aug 17 06:08:50 Hi guys. I'd like to work with Kontron COMe board under Yocto. So, I'm looking for BSP meta layer (I guess). Can you please point me to the right direction? 10x. Aug 17 06:41:34 KostaZ, have you looked at layers.openembedded.org Aug 17 06:41:53 Looking now... Thanks. Aug 17 06:46:41 At layers.openembedded.org I see "meta-fri2" BSP layer which is for Kontron "Fish River Island 2" BSP. Aug 17 06:47:26 Crofton, would you suggest to start with meta-fri2 BSP layer and modify it for the Kontron COMe board? Aug 17 06:48:06 KostaZ: if the boards share some significant relationship, yes. Aug 17 06:50:04 LetoThe2nd, not sure about the relationship **at all**. Can you please suggest more relevant BSP layer? Aug 17 06:50:50 KostaZ: i cannot, as i'm not familiar with neither of the boards. what i mean is, its rather pointless to base your support off some x86 target if yours is ARM, for example Aug 17 06:51:25 KostaZ: usually its a good technique to base your own bsp off the generic one for the SoC/platform in use. Aug 17 06:55:02 KostaZ: a short googling shows that the COMe stuff seems to be x86... so iron out the cpu etc. maybe the minnowboard stuff can be interesting for you. Aug 17 07:25:29 LetoThe2nd: I'm looking at minnowboard now... But do you mean that **any** x86 board will do? Aug 17 07:33:22 LetoThe2nd: Does "meta-intel" looks like a generic x86 BSP layer? Aug 17 07:35:03 KostaZ: No idea if any x86 board will do, but if you're going down to a very generic x86 setup, it will hopefully at least boot very quick. probably it will even be enough to just use the generic x86 support in poky and just tweak the tune. Aug 17 08:12:21 morning all Aug 17 08:24:31 has anyone ever included glib-2.0 python bindings in the image? Aug 17 08:24:50 apparently adding glib-2.0 only isn't sufficient Aug 17 08:42:30 Are there any discussion about some kind of long term support for a recent yocto release? Aug 17 08:42:54 I'm interested in that since we're using yocto as the base for xdg-app runtimes. Aug 17 08:43:30 topik: afaik those bindings are disabled in current glib-2.0 Aug 17 08:45:05 alexlarsson: has any yocto release seen support? afaik, no. Aug 17 08:45:15 alexlarsson: we really only support the last two major releases as stable branches Aug 17 08:45:29 mcfrisk: what's that supposed to mean? Aug 17 08:45:54 bluelightning: and there is no interest in some joint collaboration on a longer term supported base? Aug 17 08:46:22 bluelightning: are the packages in dizzy/fido maintained after release with security updates? Aug 17 08:46:35 afaik, no. Aug 17 08:47:26 mcfrisk: we've merged a number of CVE-fixing patches into those branches, so yes Aug 17 08:47:36 do we patch every single one ? no Aug 17 08:47:49 bluelightning: exactly, there are some packages supported but most not. Aug 17 08:47:49 we do the best we can with the resources we have Aug 17 08:48:00 I know. I'm just trying to be honest here. Aug 17 08:48:00 Is there some defined "core" which gets security updates? Aug 17 08:48:31 alexlarsson: I think there would be interest yes, we've always said that beyond that the community is welcome to step up and continue maintenance Aug 17 08:49:04 mcfrisk: implying that there's "no support" isn't being honest though Aug 17 08:49:17 I mean, i completely understand not wanting to support *all* the stuff in oe Aug 17 08:51:30 mcfrisk, for long term support, you either find a group of people with a common interest or talk to one off the commercial vendors Aug 17 08:51:42 pretty much everything in OE-Core *ought* to be getting security updates back to the last two stable releases, so that's what we aim for Aug 17 08:51:43 or go it alone Aug 17 08:51:55 I've talked with commercial vendors, I see what they do, and mostly don't. And we have one. Aug 17 08:52:09 * Crofton is being polite :) Aug 17 08:52:51 And I need to run, cleaning up at camp Aug 17 08:54:31 we certainly try to maintain the stable branches, fido has merged >200 patches since it was released - but it's largely a one-man spare time job Aug 17 09:06:59 topik: what do you mean by glib-2.0 python bindings? pygtk or gobject introspection ones? Aug 17 09:15:01 i think it's the pygtk Aug 17 09:15:06 import glib Aug 17 09:16:30 ah, actually it's pygobject Aug 17 09:16:53 but i'm using the misc functions from the glib module Aug 17 09:21:02 topik: you can just just python Aug 17 09:22:15 it seems like some of the misc functions are directly avaible in glib module Aug 17 09:24:20 but the module is not a python default module Aug 17 09:54:57 for the record: adding python-pygobject to the core_image_extra_install also installs the glib module Aug 17 10:51:20 hi, hmm, it seems that opkg list-installed cannot be run as non-root? Aug 17 10:51:47 opkg list-installed Aug 17 10:51:48 Collected errors: * opkg_conf_load: Could not create lock file /var/lib/opkg/lock: Permission denied. Aug 17 10:52:08 As it seems, /var/lib is not writeable by anyone else than root. Aug 17 10:52:23 is there a simple way around to this? Otherwise, I will create a setuid binary, but it would be a pity. Aug 17 10:52:33 I think getting information ought to be possible as simple users, no? Aug 17 10:57:07 on my desktop at least, I can query information from my package manager about packages. Aug 17 10:58:45 yeah that's always annoyed me Aug 17 10:58:53 should be a fairly simple patch Aug 17 10:58:59 no need to lock the database for that Aug 17 10:59:25 yeah, I was thinking about the same solution. Aug 17 11:00:25 iirc you need to be root to run the compare-version logic too Aug 17 11:00:40 which is equally stupid, but moot as the compare-version option is broken anyway Aug 17 11:05:26 :-) Aug 17 11:05:47 are you up for creating the patch then? ;-) Aug 17 11:12:03 Hello again. I have a recipe which adds a initscript via INITSCRIPT_NAME & _PARAMS. How can I bbappend this away? I tried INITSCRIPT_PARAMS = "", but this doesn't seem to work right. Aug 17 11:15:17 lpapp: i have a patch for the compare version logic but was just going to file a bug at some point for the root thing Aug 17 11:26:18 zwerch: it looks like you could set INHIBIT_UPDATERCD_BBCLASS = "1" Aug 17 11:27:50 rburton: should that be done on the yocto bugtracker? Aug 17 11:27:58 yes Aug 17 11:32:26 rburton: 8174 Aug 17 11:54:25 bluelightning: so INHIBIT_UPDATERCD_BBCLASS = "1" in the bbappend would prevent bitbake from using the update-rc.d class in the recipe? Aug 17 11:59:38 bluelightning: thanks! Aug 17 11:59:46 it worked Aug 17 12:20:01 I'm now seeing "The license listed MIT-X was not in the licenses collected for recipe xf86-input-vmmouse". What is it really trying to tell me? Reading license.bbclass isn't helping so far... Aug 17 12:22:31 I think that didn't happen when I was updating the recipe a while ago Aug 17 12:23:23 did you use wipe-sysroot? Aug 17 12:23:39 (at some point in the past) Aug 17 12:23:43 sure Aug 17 12:23:49 i think i found a bug in it :) Aug 17 12:24:29 hm actually the license thing was in wipe-deploy, which isn't in git Aug 17 12:25:16 afaik its basically saying "the deploy directory should contains MIT-X but its not there, which shouldn't happen as it that should have been copied earlier int he build" Aug 17 12:25:50 my wipe deploy was deleting the files but not the stamps, so i see this occasionally and i fixed that last week - but nobody else has this script. Aug 17 12:26:25 hmm, I usually avoid touching deploy (except for removing very old images once in a while) Aug 17 13:05:49 Hi all ! Aug 17 13:06:28 I wonder if there is a simple way to include official debian packages built from source in yocto? Aug 17 13:08:51 i mean using the debian source package to fetch source code, apply debian patches (eventually yocto patches too) and build it using yocto compiler & optimizations Aug 17 13:10:28 CromFr: there's no automated way that I could recommend, no Aug 17 13:11:03 CromFr: inside the oe buildsystem its not that easy, it basically would mean create some very clever scripting. externally for one specific package, using a poky generated SDK.... not that hard, probably. Aug 17 13:37:25 LetoThe2nd, CromFr: there's at least one recipe in oe-core that actually does that (fetches a debian diff, applies it, then applies all debian patches that just appeared in debian/patches/). Really hacky if you ask me Aug 17 13:38:23 bluelightning: your suggestion didn't work :( I don't know what I'm doing wrong. Aug 17 13:39:01 jku: after all you can override the patch task to customize it :) Aug 17 13:40:36 on my list of "software packaging methods that guarantee no-one understands what's happening" this one is moderately high Aug 17 13:40:44 jku: certainly possible, yes. but nothing that deserves the term "maintainable" at the moment. Aug 17 13:42:43 LetoThe2nd: that was aptly demonstrated last week by the discovery of several recipes that were apparently trying to do similar things but where the patches weren't actually ever applied ... Aug 17 13:43:00 * LetoThe2nd muses on pouring the generic mechanism into a bbclass... and then... (insanity starts about here.) Aug 17 14:02:20 jku: the official way to unpack and apply patches to a debian source package is "dpkg-source -x path_to_dsc", see https://www.debian.org/doc/debian-policy/ch-source.html#s-debianrules . There are a number of Debian source package formats which can handle patches to upstream sources in different ways. Aug 17 14:27:24 zwerch: oh, I thought you said it did work above ? Aug 17 14:28:00 zwerch: it won't stop your recipe actually installing the file to /etc/init.d though, that's something you need to take care of separately Aug 17 14:40:56 bluelightning: yeah I thought so, but that was something else ^^ I figured something else out I think, but thanks anyway :) Aug 17 16:06:15 hi! i got a systemd service file (located in etc/systemd/system), i pulled this out of svn.. from a supplier -- how can i tell systemd to enable this service? i hope my issue is clear to you ;) Aug 17 16:07:35 ericbutters: have a look at the systemd class Aug 17 16:22:29 ericbutters: its not clear if you are asking how to package it during build time so that its enabled by default when that image is booted ? or are you pulling it into a booted system Aug 17 17:48:10 yoohoo, otavio ... Aug 17 17:49:42 * nerdboy playing hard to get Aug 17 17:52:42 nerdboy: hi Aug 17 17:54:03 yo, how's it hangin'? Aug 17 17:54:55 someday i need to buy you a beer so i can say "here's your beer Lazlo..." Aug 17 17:58:18 hopefully remembering that correctly... Aug 17 18:01:50 +s :) Aug 17 19:02:52 otavio: how are the imx28-evk builds tested? in qemu? Aug 17 19:03:28 do they ever get booted on real hardware? as in testing the mmc pinmux thing? Aug 17 19:04:15 nerdboy: you alright? Aug 17 19:05:33 about to test my own kernel config Aug 17 19:05:46 yocto defconfig doesn't work Aug 17 19:06:01 or else it's a different problem Aug 17 19:06:44 vut i think i narrowed it down to kernel config, since the .dtb looks good afaict Aug 17 19:06:52 *but Aug 17 19:07:20 and it does boot off the right mmc slot with 2.6.35 **** ENDING LOGGING AT Tue Aug 18 02:59:58 2015