**** BEGIN LOGGING AT Thu Aug 13 02:59:59 2015 Aug 13 04:15:45 buffer 8 Aug 13 04:15:49 whoops. sorry Aug 13 05:28:54 how to tell a recipe to load a module after installation? Aug 13 05:42:28 see KERNEL_MODULE_AUTOLOAD and module_autoload_* Aug 13 07:19:25 hello to all. In recipe tiff_4.0.4.bb, tiff and tiff-utils are build. But only tiff (libtiff) is included in core-image and not tiff-utils. Although I can see the tiff-utils in the work directory. How can I also include tiff-utils in the image? Aug 13 07:19:55 Tamis: add tiff-utils to your IMAGE_INSTALL, probably Aug 13 07:22:08 just like any other package you want to be included. you can basically do it as a quick hack in local.conf for testing, but i'd suggest pouring it into your image recipe as soon as possible. Aug 13 07:24:10 LetoThe2nd: I read that I should use IMAGE_INSTALL_append with caution. But I am curious why although lib is included why utils are not. I will make a test production now Aug 13 07:25:39 Tamis: the _append is the part that need caution. The reason for only the lib being there is probably trivially to allow something to depend on it, or something already depends on it - but nothing needs the cli utils. Aug 13 07:28:30 LetoThe2nd: I see. yes Libtiff has many dependencies with ghostscript (gs) and others. Thanks a lot Aug 13 07:35:35 Tamis: YW Aug 13 08:16:57 morning all Aug 13 08:33:05 morning Aug 13 08:51:42 morning Aug 13 10:44:50 good morning Aug 13 10:51:04 so the latest version of a recipe will be picked up from the packagegroup by default, yeah? Aug 13 10:57:31 will specifying the preferred version in the image recipe work for a package? Aug 13 10:58:12 so that we can make different images with different image recipes for different versions of our software? Aug 13 11:00:58 lpapp: the image will use whatever version gets built; the one that gets built is determined by PREFERRED_VERSION, or if that is not present, things like layer priority, DEFAULT_PREFERENCE and latest version Aug 13 11:01:22 lpapp: based on PV alone, you cannot have two images that ship different versions of the same package Aug 13 11:01:43 you'll need to have separate recipes (i.e. with a different PN value) to accomplish that Aug 13 11:07:52 ok, so it will not work if I have foo_0.1.bb and foo_0.2.bb Aug 13 11:08:06 and I say PREFERRED_VERSION_foo = 0.1 Aug 13 11:08:11 in image-0.1 Aug 13 11:08:19 and PREFERRED_VERSION_foo = 0.2 in image-0.2? Aug 13 11:11:05 bluelightning: why would two image recipes, foo-0.1 and foo-0.2 in this case, not work if they both set the preferred versions respectively? Aug 13 11:11:30 what is the recommendation for accomplishing this? foo-ng and foo recipes? :) Aug 13 11:51:53 Hi guys, I have problem with usb eth gadget. I built poky for geode proc and trying to use my phone as usb-modem. I can see it with lsusb, but when call usbinit, it says, that there is no module g_ether, but in my machine.conf "usbgadget" presents Aug 13 11:52:08 MACHINE_FEATURES += "pcbios screen keyboard pci usbhost ext2 ext3 x86 acpi serial usbgadget alsa" Aug 13 11:58:41 are you sure that g_ether is gadget serial? I do not think so. Aug 13 11:58:44 it is more like g_serial Aug 13 11:58:53 lpapp: you can't set PREFERRED_VERSION in an image, that sort of thing must be set at the configuration level because those kinds of decisions get made before the build even starts Aug 13 11:59:08 hmm, I may be wrong, I take that back. Aug 13 11:59:38 lpapp: yes, different PN is really the only way to do it Aug 13 11:59:45 bluelightning: hmm, I see, but in my case, it is valid to build different images based on different versions. Aug 13 12:00:06 so would it go against the principles to allow this in the future? Aug 13 12:00:26 pohmelie: MACHINE_FEATURES don't influence the kernel configuration, though I can understand how you might assume that they do (and they ought to really) Aug 13 12:00:59 lpapp: architecturally it would be difficult to do that Aug 13 12:03:11 ok, I see. Perhaps different branches are the way to go? Aug 13 12:04:43 you could use separate branches with separate TMPDIR yes Aug 13 12:04:51 bluelightning: so, where can I tune kernel modules? Aug 13 12:05:30 pohmelie: the kernel recipe, or a bbappend for it - see our kernel manual: http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html Aug 13 12:06:04 bluelightning: ok, and the third option is to put the preferred version in the local.conf, yeah? Aug 13 12:06:09 bluelightning: ok, I will try it. Thanks a lot! :) Aug 13 12:06:40 hmm, we also do a fresh clean build for the release, so in that case, we can perhaps also drop the separate TMPDIR or would that still be needed? Aug 13 12:17:02 lpapp: well if you're to use separate configurations you probably can't use the same TMPDIR - building with the second version is going to remove the packages for the first Aug 13 12:27:46 ah, ok, we would not do simultaneous builds. Aug 13 13:07:47 hi.. how do i write a recipe that compiles for the host machine and brings binary into the host sysroot sdk? Aug 13 13:08:02 inherit nativesdk or something? Aug 13 13:09:14 bluelightning: thank you very much Aug 13 14:34:48 * vmeson fights with the INTC bridge yet again... the darn thing hung up on me twice no 3 times! Aug 13 14:35:45 success! Aug 13 14:53:15 ericbutters: yep, that's what nativesdk is for Aug 13 14:53:19 morning Aug 13 15:09:35 Hi, I have a question about debugging shared libraries Aug 13 15:12:39 ok Aug 13 15:14:52 I want to step through the source code of glibc. I have built with dbg-pkgs and I have added glibc-dbg to local.conf Aug 13 15:15:25 However, when I get to a libc call, it can't find the source code, even though it is there in usr/src Aug 13 15:16:56 I can get it to work with gdb commands like "dir /home/chris/MELP/rootdirs/rootfs/usr/src/debug/glibc/2.20-r0/git/sysdeps " but that seems like the wrong thing to have to do Aug 13 15:25:23 debugging glibc? Interesting :) Aug 13 15:26:50 Sometimes you just want to know what is going on :-) Aug 13 15:28:17 I think if your image is built with all the debug symbols, the issue must be on gdb's side. Aug 13 15:28:33 is it remote debugging or are you running the whole gdb on the target? Aug 13 15:29:36 Remote, using gdbserver Aug 13 15:30:16 I am writing a tutorial on library debug. With Buildroot it "just works", but with Yocto I can't get the same behaviour Aug 13 15:33:45 oh, that worked for me. Aug 13 15:33:49 let me see. Aug 13 15:34:11 the debug info (from glibc-dbg) should know how to find the sources in /usr/src/ out of the box. if not, that's a bug. Aug 13 15:37:15 hmm, for me IMAGE_FEATURES += "dbg-pkgs" works. Aug 13 15:40:02 OK, this is what happens when I try to step into printf: Aug 13 15:40:08 8 printf("Hello, world!\n"); (gdb) s _IO_puts (str=0x84dc "Hello, world!") at ioputs.c:34 34 ioputs.c: No such file or directory. Aug 13 15:40:55 [that did not appeare across multiple lines as I had intended, but you get the gist] Aug 13 15:45:09 and gdb sees the directory? Aug 13 15:46:17 Yes, (gdb) set sysroot /home/chris/MELP/rootdirs/rootfs Aug 13 15:47:03 Now, if I find out which directory ioputs.c is in and add that, it works fine: Aug 13 15:47:16 (gdb) dir /home/chris/MELP/rootdirs/rootfs/usr/src/debug/glibc/2.20-r0/git/libio Aug 13 15:48:02 ok, so it is all good :) Aug 13 15:48:11 So, I think the problem is that the compiled dir ($cdir) for glibc is wrong. It is not the full path, from the sysroot Aug 13 15:49:04 It is only good so long as I go and add all the source directories in glibc Aug 13 15:49:27 And that is way too much trouble for the average developer (me included) Aug 13 15:53:49 csim_: can you file a bug? Aug 13 15:54:43 Sure. THis is Yoco 1.7.1. I guess I should verify it with 1.8? Aug 13 15:57:06 How/where should I report this problem? Aug 13 15:57:34 https://bugzilla.yoctoproject.org/ ? Aug 13 15:57:37 yeah there Aug 13 15:57:39 (But I cannot reproduce it) Aug 13 15:57:57 Hmm Aug 13 15:58:18 which does not mean there is no bug :) Aug 13 15:58:34 So it works for you, without having to set the gdb directory then? Aug 13 19:03:33 anyone (fray?) know what encoding rpm spec files are in? Aug 13 19:06:55 answer is none.. Aug 13 19:07:27 (I assume you mean character encoding).. they're not.. they take straight characters.. occasionally you get people adding umlauts and other special characters.. but there is no defined character set.. Aug 13 19:07:44 there is a mode that you can define localizations.. but the main stuff is not.. Aug 13 19:07:54 fray: fedora imply utf8 is default, can't find a reference to what encoding type string tags are in Aug 13 19:08:03 fedora's wrong.. Aug 13 19:08:15 there is no string encoding.. they're 8-bit chars.. Aug 13 19:08:35 what you CAN do is provide a localization package that will translate for you to any specific localization Aug 13 19:09:01 so it basically says null-terminated 8 bit chars, good luck with that Aug 13 19:09:02 that's tragic Aug 13 19:09:03 it's just been a long time since I've done nay of that.. but it's the only way to get the encodings other then 'default' Aug 13 19:09:17 you have to remember RPM is circa 1996-1998 Aug 13 19:09:21 econdings were not an issue then Aug 13 19:09:29 sounds like "lets pretend the spec says utf8" is the best approach (and what fedora appear to be doing) Aug 13 19:09:50 ya.. but thats the rub, it's not actually utf8.. Aug 13 19:09:51 there's no such thing as 'no string encoding'. perhaps you meant ascii? Aug 13 19:10:04 kergoth, no as in undefined Aug 13 19:10:21 they are 8-bit characters with no defined special characters.. Aug 13 19:10:25 that doesn't make any sense. it'd be impossible to rpm to use it if it can't interpret the characters Aug 13 19:10:35 ASCII is generally what is used, but RPM doesn't interpret characters Aug 13 19:10:43 it just displays what someone else has written Aug 13 19:10:52 that doesn't make sense. it has to interpret the field names Aug 13 19:11:04 thats not the RPM, thats the spec file.. :) Aug 13 19:11:17 my context is actually the spec input Aug 13 19:11:18 [12:03:33] anyone (fray?) know what encoding rpm spec files are in? Aug 13 19:11:19 spec files are all ASCII defined characters, with undefined contents for the fields.. (generally also ASCII) Aug 13 19:11:37 i'm reading that as "utf8 is fine" :) Aug 13 19:12:00 he program simply parses the spec files for various fields.. but the contents of the fields are simply 8-bit characters.. no defined character encoding.. so ASCII is generally correct Aug 13 19:12:13 I'm being a bit pedantic here.. because it's definitely NOT utf8 Aug 13 19:12:35 and RPM doesn't do any LANG/LOCALE/etc confgiurations when it runs.. it just displays when it has when prompted.. Aug 13 19:13:18 if you actually want localized strings, you can provide RPM with a localization file.. and it will use the gettext mechanism to look up the non-language defined value and pick something that does have a defined character encoding and language Aug 13 19:13:36 (I usually do set LANG=C when I use RPM, since it's the closest to 'standard') Aug 13 19:18:04 the reason why it's not UTF-8 is that RPM doesn't do anything with the extended (2-4 byte) characters.. it's all one byte characters... Aug 13 19:18:26 each byte being 8-bits.. (not 7... so it's not strictly ASCII either.. thats part of the confusion) Aug 13 19:19:39 heh, so it's just a blob. so there's an implicit assumption that your system is close enough to the system the specs were written on Aug 13 19:19:43 interesting Aug 13 19:19:56 i.e. see comment about 1998... ;) Aug 13 19:20:01 heh :) Aug 13 19:20:13 if you want proper unicode of any kind.. then you have to use one of the mechanisms to define the localizations.. Aug 13 19:20:29 even in 1998 there were a ton of different encodings for a ton of different languages Aug 13 19:20:31 short sighted Aug 13 19:20:32 then you are free to go nuts.. but it's basically the .po type files that take the stock 'string' and covert to a localizaed version Aug 13 19:20:46 ah, makes sense Aug 13 19:21:27 but the parsing during spec generation (specifically on version/release) is 8-bit characters.. with specific character limits, such as '-' can't be in a version or release.. Aug 13 19:21:56 so in UTF-8 if you can generated a 2-4 byte character where byte 2-4 is the equivalent of a '-' or other "not permitted' character, you suddenly fail.. :) Aug 13 19:22:34 fir commits were by Erik Troan in about Nov of '95.. Aug 13 19:22:41 so most of the format was written in the '96 era Aug 13 19:23:19 (I can remember using RPM when it was "new".. [get off my lawn]) Aug 13 19:23:30 totally OT, but anyone played with git-imerge? Aug 13 19:23:48 kergoth, it's IRC... I didn't know anything was on-topic.. ;) Aug 13 19:23:53 fair point Aug 13 19:24:28 imerge is really interesting. it creates a matrix of all the commits on either side of the merge, then it merges them with one another one commit at a time, filling in the matrix Aug 13 19:24:48 sounds like of like wiggle.. Aug 13 19:24:53 basically you end up with resolving conflicts right where the specific changes that stepped on one another are, in that context, rather than the whole thing at once Aug 13 19:25:04 ya, that seems nice Aug 13 19:25:23 downside is performance, thats a lot of small merges Aug 13 19:25:24 that always seems to be my problem.. figuring out why the conflict occured.. Aug 13 19:25:59 yeah, exactly. being able to quickly look at the commit message of the two commits that really conflicted would have value Aug 13 19:26:07 yup Aug 13 19:26:18 end up digging through git log otherwise Aug 13 19:26:33 https://github.com/mhagger/git-imerge for the curious Aug 13 19:26:42 there's a talk about it Aug 13 19:26:58 * fray watches one of his dogs and one of his cats stare at each other across the room as they both decide fi they're going to go back to sleep or attack/run Aug 13 19:27:14 dog went back to sleep.. cat sat up and is just watchign the room.. ;) Aug 13 19:27:43 ...and now the dog is watching the cat watch the room... Aug 13 19:28:05 ahh.. never ends.. cats taunt the dogs.. the dogs herd the cats back into the front room.. Aug 13 19:32:14 BTW that is something we probably should consider eventually.. localization of recipe content.. something like Aug 13 19:32:17 SUMMARY = "default" Aug 13 19:32:29 SUMMARY[us.utf8] = "default US english utf-8 encoded" Aug 13 19:32:30 ... Aug 13 19:32:34 same w/ DESCRIPTION fields.. Aug 13 19:33:37 that's a good point. of course that begs the question of what exactly the default is in :) Aug 13 19:33:51 yup.. :) Aug 13 19:33:53 also what the file encoding is. we need to fix bitbake to use utf8 internally too Aug 13 19:34:01 hmm Aug 13 19:34:25 see, it's not just RPM that was short sighted.. ;) Aug 13 19:35:50 indeed. Aug 13 19:36:22 we should have known better, given how spread out around the world our devs have always been Aug 13 19:36:43 i think we had the US, england, and germany covered within the first week or two Aug 13 19:36:44 heh Aug 13 19:37:02 I think the real issue is that most hackers don't care.. "english" is 'good enough'.. and commercial folks probably aren't building devices with raw text consoles.. Aug 13 19:37:46 embedding translations inside the recipe is madness Aug 13 19:38:00 extract canonical strings from recipe, use translation framework to generate po files Aug 13 19:38:13 both have merit Aug 13 19:39:17 the po mechanism is good for many things and allows external people to maintain translations.. Aug 13 19:39:17 not filling a recipe up with 100 translations, and having frequent commits because the translators can't agree on how to write "computer" is a good bonus for separate translations Aug 13 19:39:32 interal translations have he advantage of staying with the meta-data.. Aug 13 19:40:10 also expecting translators to have knowledge of recipes, git and so on means you either set a high bar for translators, or deal with them breaking stuff now and again Aug 13 19:40:29 fray: why is that an advantage? it's not like if i change the summary of a recipe i can fix the translations Aug 13 19:40:36 its a negative - translations are bloating the recipe Aug 13 19:40:48 rburton, correct.. but how often do you change the summary/description? :) Aug 13 19:41:02 the advantage is usually felt on people who DO the translations and development as a unit.. Aug 13 19:41:11 the disadvantage is whent he translations are done by people external of the development Aug 13 19:41:13 never seen that happen :) Aug 13 19:41:18 thats why both methods are valid Aug 13 19:41:52 been in a few projects with both community and commercial translations - for both out-of-tree translations were the clearly suprior solution Aug 13 19:42:00 well, out of source Aug 13 19:42:36 eg gnome puts everything into PO files, and translators can have git push to just the po/ directories to limit any impact they can have Aug 13 19:42:46 I've seen both being useful.. I agree po files are the more used and more useful.. Aug 13 19:42:47 moblin/meego/tizen used commerical translators and transifex Aug 13 19:42:54 * rburton -> cook some tuna steak Aug 13 19:48:18 okay, need to split out a couple functions to clean up, but it's not looking too bad now: https://github.com/openembedded/bitbake/compare/openembedded:master...kergoth:shallow-git-mirror-tarballs Aug 13 19:48:25 also need to clean up the commits / rebase -i again Aug 13 19:49:01 not very useful for linux-yocto due to the commit/branch validation needing access to other branches that aren't listed in the uri, but useful otherwise Aug 13 19:49:19 should probably add back the variable as a default for the parameter, to ease usage for the common case Aug 13 19:53:33 I tried prototyping the premirror based separate fetcher approach again, *could* be doable, but would need some more invasive core changes. the symlink behavior when we don't call into the original fetcher would have to go, or be adjusted, and we'd have to be able to make the mirror method's unpack() be used instead of the main url method's unpack() Aug 13 20:34:35 crap, i just realized the shallow url parameter changes the checksums, even though the content hasn't changed. Aug 13 20:34:38 * kergoth grumbles Aug 13 20:36:07 Hello all, has anyone else been having troubles building qtwebengine from meta-qt5 using the fido branch? I keep getting link errors around icu_46::*. Aug 13 20:42:25 hello. Aug 13 21:24:16 if I created a bbappend how do i ask to be add it? Aug 13 21:24:25 in my build Aug 13 21:32:49 Is the meta-selinux email list still active ? I found references to it, but it doesn't show up on https://lists.yoctoproject.org/admin ? Aug 13 22:50:07 Okay, I think I'm finally ready to submit the git shallow clone support. Aug 13 22:50:26 https://github.com/openembedded/bitbake/compare/openembedded:master...kergoth:shallow-git-mirror-tarballs Aug 13 22:50:28 khem: ^ Aug 13 23:00:39 * kergoth 'll send out an RFC **** ENDING LOGGING AT Fri Aug 14 02:59:58 2015