**** BEGIN LOGGING AT Thu Apr 30 02:59:58 2015
Apr 30 04:58:11 <nilesh_> Hi, I'm getting error like this http://pastebin.com/yDFmp7dR whin i run gstremer on yocto generated image .. can anyone help on this?
Apr 30 07:46:29 <mckoan> good morning
Apr 30 07:49:27 <cristianiorga> any brave souls out there that know what is happening to MPD (Music Player Daemon)? No commit for more than 1 month...
Apr 30 08:27:10 <bluelightning> morning all
Apr 30 08:46:52 <AlexVaduva> morning Paul
Apr 30 09:54:30 <francis_tttech> hello, I would need to create a recipe which packs (in a tar.gz or other any file) the compilation results ot some libraries (e.g. clutter, mx...). I have tried to create an image, but the image is also trying to compile the kernel, etc; I do not need/want that, only a few libraries. Is it possible to do that?
Apr 30 09:59:33 <francis_tttech> hello, anybody to help with my previous question? thanks.
Apr 30 09:59:45 <bluelightning> francis_tttech: hi
Apr 30 09:59:57 <francis_tttech> hello bluelightning
Apr 30 10:00:12 <francis_tttech> any advice on how to do that?
Apr 30 10:00:54 <bluelightning> francis_tttech: hmm, so that ought to be possible with an image recipe
Apr 30 10:00:58 <bluelightning> one sec
Apr 30 10:01:30 <bluelightning> francis_tttech: which version of the build system are you using?
Apr 30 10:01:31 <francis_tttech> ok, thanks
Apr 30 10:06:59 <bluelightning> francis_tttech: removing the kernel dependency will depend on which version you're using ...
Apr 30 10:09:40 <francis_tttech> eldk553
Apr 30 10:09:59 <bluelightning> do you know what Yocto Project version that is based on?
Apr 30 10:10:24 <francis_tttech> well, it is not that I would like to remove the kernel dependency. I want to pack only some libraries, i.e. clutter and mx. nothing else
Apr 30 10:10:47 <francis_tttech> I believe it is 1.5
Apr 30 10:10:49 <francis_tttech> dora
Apr 30 10:13:16 <bluelightning> ok, so in general I would say set PACKAGE_INSTALL instead of IMAGE_INSTALL, and set IMAGE_LINGUAS = ""
Apr 30 10:13:29 <bluelightning> with dora that may be enough
Apr 30 10:14:46 <francis_tttech> where should I set that?
Apr 30 10:15:01 <francis_tttech> in a recipe? in an image? packagegroup?
Apr 30 10:15:04 <bluelightning> you'd need to create a custom image recipe if you haven't already
Apr 30 10:15:18 <bluelightning> i.e. you'd set it in that custom image recipe
Apr 30 10:16:05 <francis_tttech> and the custom image has to inherit from core-image?
Apr 30 10:18:21 <bluelightning> inherit image
Apr 30 10:18:29 <bluelightning> you don't need anything from core-image in this case
Apr 30 10:22:34 <francis_tttech> ok thanks a lot. I will try that way and let you know how it goes.
Apr 30 10:23:04 <bluelightning> ok, no worries
Apr 30 10:56:22 <francis_tttech> hello bluelightning. I have created the image using PACKAGE_INSTALL = "glib-2.0" (just as example) and IMAGE_LINGUAS = "", but it is still trying to locate a provider for kernel-dev, binutils-cross-canadian-i586, gdb-cross-canadian-i586 and gcc-cross-canadian-i586. and also it is trying to compile opkg, which I do not need/want
Apr 30 11:03:45 <bluelightning> francis_tttech: I'm afraid our image construction makes use of a package manager, so you don't have a choice about that - it will not appear in the final image though
Apr 30 11:04:40 <bluelightning> francis_tttech: the others really are required, otherwise how would it be able to build glib-2.0 ?
Apr 30 11:07:29 <francis_tttech> well, I am using an external toolchain, which is able to build glib-2.0, so it should not need any other cross canadian tool
Apr 30 11:07:41 <francis_tttech> I will try to remove opkg compilation somehow, thanks!
Apr 30 11:09:04 <bluelightning> francis_tttech: the external toolchain ought to be providing those things such that they are not built; if they are still being built, your external toolchain is probably not set up correctly
Apr 30 11:09:43 <bluelightning> francis_tttech: for opkg, if you use an image at least opkg-native has to be built, there is no way around that
Apr 30 11:13:06 <francis_tttech> ok, thanks
Apr 30 12:39:04 <condo43> Hello, I wrote a bug (7680) about python3 with fido branch, I fact, python3-fcntl and python3-elementtree are empty (and packages are not generated) since patch b2f8367dff8a2db49b9296bd27a2e94a3619884d
Apr 30 12:47:42 <bluelightning> condo43: I've assigned the bug to Robert whose patch that was
Apr 30 12:47:51 <condo43> Ok thanks
Apr 30 12:47:57 <bluelightning> thanks for the report, hopefully we can get it sorted out soon
Apr 30 12:49:25 <condo43> as workarround, I just revert this patch and all works fine for me...
Apr 30 12:50:49 <ramose> Can any one please point me out, how could I compile new snmp mib moudle through yocto ?
Apr 30 12:56:10 <condo43> I have a general question, I don't use systemd for my distrib, but for many package, standard init scripts are missing... (like bluez5, obex, x11vnc,  upower...) I wrote all this scripts and add it to the recipe with bbappend, My question is, why all this init scripts are missing ?? nobody use this package without systemd ?
Apr 30 13:00:52 <bluelightning> condo43: that is interesting, I didn't realise we were missing initscripts for bluez5
Apr 30 13:01:29 <bluelightning> on the face of it that would be a bug
Apr 30 13:05:16 <bluelightning> condo43: I think we'd take patches if you have done the changes already
Apr 30 13:07:05 <condo43> Yes, I can send it, the best way is to attached init script to bugzilla or to send a git patch to mail list ?
Apr 30 13:12:23 <challinan> nick challinan
Apr 30 13:25:15 <bluelightning> condo43: the mailing list - FYI there's a quick pointer in the README as to which part goes where, as well as http://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded
Apr 30 13:25:45 <condo43> Ok, I will do that this today or next week
Apr 30 13:50:13 <LocutusOfBorg1> hi folks, can anybody please explain why with systemd+fido builds my board gets a different ip address (dhcp) each time I flash it? I suppose it is something related to a changed mac address...
Apr 30 13:50:54 * mckoan is doing scary tests "Host distribution "Ubuntu-15.04" has not been validated" :-D
Apr 30 13:52:14 <abelloni> mckoan: wasn't it already the case for 14.10 ? :)
Apr 30 13:52:21 <mckoan> challinan: I've just realized I've got your book in my shelf :-D
Apr 30 13:52:39 <mckoan> abelloni: possible
Apr 30 13:53:33 <LetoThe2nd> abelloni: it was, but i think it was gone with dizzy then.
Apr 30 13:53:58 <abelloni> I don't think so, I still had it with dizzy before upgrading
Apr 30 13:54:16 <LetoThe2nd> abelloni: ok, i'm really not sure
Apr 30 13:55:21 <abelloni> it doesn't really matter
Apr 30 13:55:55 <LetoThe2nd> yeah
Apr 30 13:59:13 <LetoThe2nd> mckoan: concerning books, i managed to set a preorder on ldd4 on amazon, so they feel like telling every couple of weeks that unfortunately its still not available ;)
Apr 30 14:03:27 <mckoan> LetoThe2nd: "book covers significant changes to Version 3.2 of the Linux kernel" gosh!
Apr 30 14:04:20 <LetoThe2nd> mckoan: i keep the order open mainly to find out how many reminder emails i can collect before they cancel it themselves
Apr 30 14:04:36 <challinan> mckoan: cool, thanks!  They are asking me to do the third edition <ouch>. it's pretty outdated now
Apr 30 14:05:28 <LetoThe2nd> challinan: heh, you're naming the reason why its not on my shelf so far ;)
Apr 30 14:05:52 <challinan> heh yeah, it's time to update it ;)
Apr 30 14:06:23 * LetoThe2nd did the early budget thing today and reserved company money to get on all of your nerves in dublin. *STRIKE*
Apr 30 14:09:05 <mckoan> I've just bought the YP book from Alex Gonzalez
Apr 30 14:09:30 <mckoan> too expensive for its content
Apr 30 14:09:35 <LetoThe2nd> mckoan: ah, once you get it tell me if its worth getting it
Apr 30 14:09:47 <mckoan> LetoThe2nd: probably not
Apr 30 14:09:53 <LetoThe2nd> mckoan: okay
Apr 30 14:09:54 <mckoan> still reading
Apr 30 14:10:32 <LetoThe2nd> mckoan: thats about what i feared.
Apr 30 14:16:33 <mckoan> I've just discovered a weird file in YP scripts : {{ if xserver == "y": }} xserver-xf86-config_0.1.bbappend
Apr 30 14:16:47 <mckoan> the file name is "{{ if xserver == "y": }} xserver-xf86-config_0.1.bbappend"
Apr 30 14:17:07 <mckoan> is it a typo?
Apr 30 14:17:10 <kergoth> that's used by the yocto- scripts for templating
Apr 30 14:17:11 <kergoth> no
Apr 30 14:17:16 <kergoth> the file is named conditionally
Apr 30 14:17:27 <kergoth> or created conditionally, in this case
Apr 30 14:18:17 <mckoan> it can't be stored in a Windows based version control system
Apr 30 14:21:15 <LetoThe2nd> mckoan: is it bad that i count that as a feature? ;)
Apr 30 14:24:30 <mckoan> LetoThe2nd: me too, but not my customer
Apr 30 14:27:02 <kergoth> good god, they use a windows based vcs? please tell me it's not visual sourcesafe at least
Apr 30 14:27:17 <LetoThe2nd> kergoth: im super sure it must be excel
Apr 30 14:27:21 <kergoth> haha
Apr 30 14:27:49 <bluelightning> surely VSS is dead by now, wasn't TSVC the successor to that ?
Apr 30 14:28:09 <LetoThe2nd> kergoth: i actually have a customer that sends in his specs as visio screen shots embedded into excel sheets.
Apr 30 14:28:27 * bluelightning shudders at memories of being forced to use VSS...
Apr 30 14:28:36 <LetoThe2nd> kergoth: and his "patches" as screenshots of eclipses diff view
Apr 30 14:34:17 * kergoth twitches
Apr 30 15:32:55 <pumpernickel> If I'm trying to work on a body of code, potentially many "projects".
Apr 30 15:33:03 <pumpernickel> What is the recommended way to do this, externalsrc?
Apr 30 15:33:16 <pumpernickel> Or to just make the SRC_URI point to a directory on the file-system.
Apr 30 15:33:17 <pumpernickel> ?
Apr 30 15:38:50 <kergoth> externalsrc is probably best. devtool might also be of interest, bluelightning would know more about that
Apr 30 15:42:15 <bluelightning> devtool is basically a way you manage use of externalsrc easily
Apr 30 15:42:27 <bluelightning> available in 1.8 (fido) and beyond
Apr 30 15:50:34 <pumpernickel> I tried devtool briefly.
Apr 30 15:50:39 <pumpernickel> It seems like it creates a layer and more.
Apr 30 15:50:45 <pumpernickel> Perhaps I should revisit it.
Apr 30 16:02:07 <mckoan> have a nice rest of the day and Labor day
Apr 30 19:41:52 <DS_> I'd like to write an append to a recipe. That recipe requires a .inc that defines a function, and I'd like to call that function from the append file. Just calling the function isn't working (I get parse errors). How can I do that without requiring the .inc again? The way I see it is that if I require the .inc again, I'll just override what the recipe changed from the .inc with the default values again
Apr 30 19:46:07 <kergoth> you can use that function just fine from an append
Apr 30 19:46:16 <kergoth> how exactly are you trying to "call" it?
Apr 30 19:47:22 <DS_> kergoth the .inc defines it just as a shell function. Name is "kernel_configure_variable". I'm calling it this way: kernel_configure_variable "RD_GZIP" "y"
Apr 30 19:47:39 <kergoth> insufficient information
Apr 30 19:47:54 <kergoth> you haven't sai danythingabout th eparse error, nor the context wher eyou're trying to use it
Apr 30 19:48:03 <kergoth> where exactly is that line?
Apr 30 19:49:48 <DS_> kergoth http://pastebin.com/rhZLv2N5
Apr 30 19:50:09 <DS_> kergoth that makes things easier I guess
Apr 30 19:50:23 <kergoth> you can't call a shell function from nowhere.
Apr 30 19:50:30 <kergoth> shell functions are called in tasks
Apr 30 19:50:56 <kergoth> e.g. you could use do_configure_append() to add something to the end of the do_configure shell task
Apr 30 19:51:05 <kergoth> see the many, many example bbappends out there
Apr 30 19:51:19 <kergoth> see also the bitbake and yocto manuals for info on the file format
Apr 30 19:51:36 <DS_> kergoth I'm following the "guide" from the meta-raspberrypi layer (see section 2.J): http://git.yoctoproject.org/cgit/cgit.cgi/meta-raspberrypi/about/
Apr 30 19:52:10 <kergoth> read hte recipe or .inc to see where that function is called.
Apr 30 19:52:31 <DS_> I'm not familiar with all tasks of a recipe. Where is the best way to include those lines? In the configure task?
Apr 30 19:52:41 <kergoth> again, read the .inc and see what the recipe is doing
Apr 30 19:53:18 <DS_> Gotcha. Haven't read your previous line
Apr 30 19:53:52 <DS_> Yup, it does stuff in the configure_prepend task. I only saw the definition of the function and tried to use it
Apr 30 19:54:23 <DS_> If I also declare a do_configure_prepend in the bbappend file, does it override the task from the .inc, or does it just get appended as well?
Apr 30 19:54:38 <DS_> prepended*
Apr 30 19:54:48 <kergoth> from examining linux.inc, you see that function is called in do_configure_prepend
Apr 30 19:55:23 <kergoth> the problem is, the beginning of that prepend erases .config, and the end of it runs make oldconfig and the sed. they don't provide a way to run additional calls of kernel_configure_variable between those two
Apr 30 19:56:05 <DS_> If I declare a do_configure_prepend in the .bbappend file, will it override that task?
Apr 30 19:56:09 <kergoth> no
Apr 30 19:56:13 <kergoth> append/prepend are cumulative operations
Apr 30 19:56:13 <DS_> That's bad
Apr 30 19:56:31 <DS_> I'm trying my best not to change the .inc in that layer
Apr 30 19:56:34 <kergoth> indeed, they don't provide a way to use kernel_configure_variable at all from an append
Apr 30 19:56:46 <kergoth> your better bet would be to make use of linux-yocto's support for config fragments, IMO
Apr 30 19:57:12 <DS_> You mean creating a .cfg file with those parameters already set?
Apr 30 19:57:20 <kergoth> yeah. and add it to SRC_URI and whatnot
Apr 30 19:57:58 <kergoth> i'm *assuming* those still work with the raspberry pi kernel recipe, but i haven't read all of it, and i'm also not an expert with linux-yocto, but it's an existing mechanism to inject additional settings, which sounds ideal for this case if it works
Apr 30 19:58:02 <khem`> hmmm we have bashism in logging.bbclass
Apr 30 19:58:18 <khem`>         if ! [[ "$DBGLVL" =~ ^[0-9]+ ]]; then
Apr 30 19:58:24 <kergoth> heh, indeed
Apr 30 19:58:26 <kergoth> that's no good
Apr 30 19:58:33 <kergoth> somebody needs to learn about grep :)
Apr 30 19:58:55 <DS_> kergoth that seems to be a good try. Thank you for your help
Apr 30 19:58:56 <kergoth> hmm
Apr 30 19:59:25 <DS_> I'll let you know if it solves
Apr 30 19:59:28 <kergoth> DS_: np, good luck with it. worst case, contact the layer maintainers. might want to do that anyway, to mention that their readme gives commands that aren't of use without modifying the layer directly
Apr 30 19:59:32 <DS_> if it solves my problem*
Apr 30 20:00:14 <DS_> In their readme they say to change directly in the .inc, but I'll contact them asking if it's possible to allow for interaction outside their layer as well
Apr 30 20:00:16 <paulg_> DS_, http://www.yoctoproject.org/docs/1.6.1/kernel-dev/kernel-dev.html#changing-the-configuration
Apr 30 20:00:54 <DS_> paulg_ thanks! I've done this task in the past, was looking for the link to do it again :)
Apr 30 20:01:02 <kergoth> modifying an upstream layer directly is bad form.. they should really provide a better mechanism, or document using fragments to do it instead
Apr 30 20:05:17 <DS_> kergoth paulg_ thank you for the help! At least the append recipe was parsed now :) I'll contact the maintainers of the layer and ask for a better mechanism
Apr 30 20:05:25 <kergoth> good start. np
Apr 30 20:05:47 <paulg_> good luck.
Apr 30 21:02:05 <Marex> zeddii: hey!
Apr 30 21:02:30 <Marex> zeddii: so uh, shall I prod the ML about my issue again or shall I wait a few more days please ?
May 01 01:02:44 * kergoth thinks about creating a crosstool-ng toolchain recipe which installs into an internal sysroot path, then having the meta-sourcery recipes extract from that sysroot, shifting more to build time and away from parse time, and then the actual meta-sourcery could use those recipes but replace the toolchain recipe with one that grabs the external sysroot
**** ENDING LOGGING AT Fri May 01 02:59:59 2015