**** BEGIN LOGGING AT Fri Jul 12 02:59:58 2013 Jul 12 06:07:04 hi, are there plans to support Yocto on Windows? Jul 12 06:13:26 probably not Jul 12 06:15:05 it would be nice to have. Jul 12 06:20:08 virtualbox? Jul 12 06:20:15 they have a build appliance Jul 12 06:44:34 msm`: vbox != native build. Jul 12 06:49:13 from the short bitbake manual: "Must support build and target operating systems (including cygwin, the BSDs, etc)." Jul 12 07:13:01 is there any plan to maintain the releases? Jul 12 07:13:18 i.e. to provide bugfix releases, like for instance, backporting build fixes to a "major" release? Jul 12 07:13:25 it is really hard now to trust any release as a company. Jul 12 07:13:45 companies cannot update Yocto all the time, and bugfix releases would solve that issue. Jul 12 07:14:33 Hi I'm having trouble generating a sdk with "-c populate_sdk" Jul 12 07:14:49 It has to do with x11-common: https://gist.github.com/fenrig/5982513 Jul 12 07:22:10 there isn't much information about it :/ Jul 12 07:22:19 so I'm pretty much stuck Jul 12 07:40:02 maybe to do with version mismatch? Jul 12 07:54:10 so I have problems building a sdk with "-c populate_sdk". It has to do with x11-common, though the error is not complete enough for me to be understandable (or even to fix it) Jul 12 07:54:29 it says it can't statisfy a dependency :/ Jul 12 08:11:43 nobody willing to help me out :/ as I'm really stuck at this last step of generating the sdk :) Jul 12 08:20:46 fenrig: maybe you missed a layer? check the build configuration header Jul 12 08:21:14 fenrig: is there a x11-common package built? try: find /tmp/deploy/ -name 'x11-common*' Jul 12 08:22:39 fenrig: if not, try "bitbake x11-common" and then try the populate_sdk again Jul 12 08:23:01 I think so /ipk/all/x11-common_0.1-r38_all.ipk Jul 12 08:23:37 fenrig: that's an older version that what it looks for Jul 12 08:23:42 erbo: x11-common is built :o Jul 12 08:23:56 erbo: yes but I tried changing version numbers, that's why the version is older Jul 12 08:24:19 erbo: I'll undo the changes, regenerate and check te version number again ;) Jul 12 08:25:06 fenrig: do that and post the build log and I'll see if I can atleast help you narrow the issue down.. Jul 12 08:25:50 erbo: the error log you mean? or ...? Jul 12 08:25:56 yes Jul 12 08:26:07 erbo: okay just a second ;) Jul 12 08:29:39 https://docs.google.com/file/d/0B5y2Yque9ykrMFBqS2h3SV93SVU/edit?usp=sharing Jul 12 08:33:09 morning all Jul 12 08:33:23 bluelightning: morning ;) Jul 12 08:33:40 morning Jul 12 08:34:22 fenrig: do you now have a /ipk/all/x11-common_0.1-r47_all.ipk ? Jul 12 08:35:04 ./ipk/all/x11-common_0.1-r47_all.ipk Jul 12 08:35:08 yes I have :) Jul 12 08:35:10 hi fenrig Jul 12 08:35:45 bluelightning: hi Jul 12 08:36:17 erbo: I think it's strange it can't statisfy the dependency :/ Jul 12 08:36:43 erbo: and it's only an issue when populating the sdk, not when generating the image :) Jul 12 08:37:12 erbo: I do however use my own image recepi in my own layer, maybe I have to extend something in it ? Jul 12 08:39:13 an hour ago I looked at belgian Linux embedded training programs, so I have a more structured approach at linux embedded. I was kind of shocked when I read that for 5 days training i had to pay 3000 euro's Jul 12 08:42:53 fenrig: training often isn't cheap. i think there'll be a yocto developer day/training thingy at ELC-E in edinburgh this october. Jul 12 08:44:56 Guest5976: going to edinburgh from belgium won't be cheap either, i'm still a (3th year) student actually, so I'm almost always low on cash -.- Jul 12 08:46:17 Guest5976: And because of social regulations here in Belgium I'm not allowed to earn more then 3000 euro as a student, for example I wanted to participate in Google summer of code, I couldn't or I'd have to pay a lot of more taxes Jul 12 08:47:03 oh, that's silly Jul 12 08:47:16 oh hang on , why am i guest! Jul 12 08:47:24 better. Jul 12 08:48:05 rburton: using the web client? Jul 12 08:48:13 (morning btw) Jul 12 08:48:31 rburton: yes it is, here in belgium payed education (that's what it is) is extra money for the goverment Jul 12 08:48:47 fenrig: well, I've been throught whole europe by jyst using "autostop" :) Jul 12 08:49:09 bluelightning: no, znc. been having small connectivity blips so it probably tried reconnecting before the server kicked the dead connection. Jul 12 08:49:48 ynezz: cool :) I can look into that Jul 12 08:50:21 fenrig: and those trainings... better buy few boards, load of books and beers for that 3000EUR Jul 12 08:50:25 erbo: did you find anything ? Jul 12 08:50:44 ynezz: got any GREAT books on the subject? Jul 12 08:50:58 fenrig: I don't really have any good ideas. From the log is seems like it install x11-common-dbg ok, but can't install x11-common.. It also looks like it uses xserver-common as a replacement for x11-common, maybe that's where something goes wrong Jul 12 08:51:34 erbo: strange :/ Jul 12 08:52:22 fenrig: http://elinux.org/Category:Books Jul 12 08:52:26 fenrig: xserver-common comes from meta-openembedded/meta-oe/recipes-graphics/xserver-common/ Jul 12 08:52:37 erbo: Multiple replacers for x11-common, using first one (xserver-common). Jul 12 08:52:45 it has conflicts and replaces for x11-common Jul 12 08:53:21 erbo: maybe something to do with using angstrom? Jul 12 08:53:27 could be Jul 12 08:54:10 can I force x11-common instead of xserver-common? Jul 12 08:57:55 fenrig: erbo: catch rburton ..he knows about that infamous X settings split Jul 12 08:58:33 rburton: Are you willing to help me out with some populate_sdk and x11-common problems? Jul 12 09:01:02 erbo: thx for helping me out ;) I appreciate it Jul 12 09:01:19 fenrig: this is maybe the last drift btw meta-oe and oe-core. Somehow impacting on -sdk Jul 12 09:02:04 ant_work: how do u mean? Jul 12 09:02:25 uhoh Jul 12 09:02:35 oh is it time for my jog? /me runs Jul 12 09:02:40 xserver-common vs. x11-common has been discussed several times on the ML Jul 12 09:02:49 fenrig: what's the problem? Jul 12 09:03:01 * rburton will go for his jog later Jul 12 09:03:08 * ant_work downloading the huge log Jul 12 09:03:37 rburton: I'm trying to generate a sdk with "-c populate_sdk" and it fails because it can't statisfy a dependency namely x11-common :o Jul 12 09:03:54 fenrig: got a build log uploaded? Jul 12 09:04:18 * satisfy_dependencies_for: Cannot satisfy the following dependencies for packagegroup-core-x11-utils-dev: Jul 12 09:04:19 * x11-common (= 0.1-r47) * Jul 12 09:04:19 * opkg_install_cmd: Cannot install package packagegroup-core-x11-utils-dev. Jul 12 09:04:21 rburton: erbo pointed out that x11-common got replaced by xserver-common, so that's probably why it fails :o Jul 12 09:04:50 rburton: yes: https://docs.google.com/file/d/0B5y2Yque9ykrMFBqS2h3SV93SVU/edit?usp=sharing Jul 12 09:05:14 I see xinput-calibrator so it's obviously from meta-oe Jul 12 09:05:14 yeah I opted to upload the file, cause when I pasted it on gist in chrome the browser tab crashed :/ Jul 12 09:05:24 heh Jul 12 09:05:44 yocto should run a pastebin, and then we can make bb upload logs to it Jul 12 09:06:08 Hi everyone, I have a question with xorg-server too ! Jul 12 09:06:16 It seems that the 'xserver-xorg-extension-dri' package isn't present in poky 9.0.0. How the libdri.so can be installed? Jul 12 09:07:25 fenrig: hm, yeah, looks like its trying to install xserver-common but x11-common-dbg, which isn't going to work. why is there a x11-common-dbg i wonder. Jul 12 09:07:43 fenrig: one option would be to blow away your deploy and mask out xserver-common Jul 12 09:08:02 (meaning, hide xserver-common from bitbake) Jul 12 09:08:05 so delete deploy and how do I mask out xserver-common ? Jul 12 09:08:18 fenrig: http://sprunge.us for pasting form console Jul 12 09:08:35 fenrig: one sec, digging a bit Jul 12 09:08:38 just rename the xserver-common.bb file to something with backup appended to it? Jul 12 09:08:46 nah there's a better way Jul 12 09:08:49 rburton: take your time ;) Jul 12 09:09:54 rburton: iirc I did delete the xserver-nodm-init of meta-oe Jul 12 09:10:14 when doing such tests Jul 12 09:10:20 i'm confused as to why there's a x11-common-dbg Jul 12 09:10:35 rburton: you need any additional files? Jul 12 09:11:09 fenrig: no Jul 12 09:11:24 oh yeah I'm using my own image recipe edna-image-minimal, and i'm building with the angstrom distro, and I'm building for the BBB Jul 12 09:13:27 the angstrom distro also is one version behind yocto, I think they still use dylan Jul 12 09:13:36 yeah, something like that Jul 12 09:13:59 really need to sort the x init stuff out Jul 12 09:15:14 supposse I upgrade to the most recent (stable?) yocto layers, would that fix the issue (if it doesn't cause other issues) Jul 12 09:16:31 fenrig: try bitbake -cclean xserver-common (that will remove it from your deploy/ too); then add BBMASK="meta-oe/recipes-graphics/xserver-common" Jul 12 09:16:40 and rebuild your image and sdk Jul 12 09:16:48 hopefully nothing explicitly depends on xserver-common Jul 12 09:17:00 the alternative is to find out why x11-common-dbg exists at all, considering its empty. Jul 12 09:17:19 as that's not getting switched to xserver-common-dbg, which is where the problem is Jul 12 09:18:55 rburton: do the xserver-common generate -dev and -dbg packages as well? If so, don't they have to be in RCONFLICTS / RREPLACES in xserver-common as well? Jul 12 09:20:25 dunno, i don't have a working meta-oe build right now Jul 12 09:20:46 rburton: okay I'll try that ;) Jul 12 09:21:45 If you guys want I can supply my build dir, but it's quite large :/ so it can take a while to upload Jul 12 09:22:07 no its fine, quite large is probably quite an understatement :) Jul 12 09:22:07 and i can see how this can happen Jul 12 09:22:32 bluelightning: under what situations will a package with no files exist, apart from using ALLOW_EMPTY? Jul 12 09:22:59 bluelightning: x11-common just puts files into $PN, but -dev and -dbg are built (but empty). are those two always built? Jul 12 09:23:01 rburton: I have built Angstrom 2012.12 overnight. Note it's still branched on danny Jul 12 09:23:10 danny? old school. Jul 12 09:23:15 rburton: those two are marked ALLOW_EMPTY I believe Jul 12 09:23:51 ah, yes Jul 12 09:23:55 in bitbake.conf Jul 12 09:24:01 gotcha. Jul 12 09:24:18 so, maybe we should set x11-common and xserver-common to have PACKAGES="$PN" Jul 12 09:24:52 we *could* add more replaces/conflicts as erbo said, but removing the problem entirely would be another solution. Jul 12 09:25:27 we have to remove one xserver-nodm-init Jul 12 09:25:41 that's the Holy Grail Jul 12 09:25:48 that too. Jul 12 09:26:40 florian: can you apply those patches to xserver-common before they remove it completely? :) Jul 12 09:26:48 pfhh Jul 12 09:27:00 never noticed xserver-common was so heavily patched Jul 12 09:27:09 rburton: ofc coordinate with JaMa ;) Jul 12 09:28:05 rburton: it's in florian's queue since 12 Apr 2012 Jul 12 09:28:38 so the Upstream-Status should be "submitted" Jul 12 09:29:01 rburton: about the bbmask, do I add this one to my image recipe or ...? Jul 12 09:30:00 fenrig: i've a better idea now. just add PACKAGES="${PN}" to both x11-common.bb and xserver-common.bb. Jul 12 09:30:19 rburton: okay, great :D7 Jul 12 09:30:22 i suspect other bits of angstrom will want xserver-common, so masking it out may break something else Jul 12 09:30:31 fenrig: that's untested but might work nicely Jul 12 09:30:35 afaik it's just xserver-nodm-init Jul 12 09:33:06 JaMa: surely all the per-machine tweaking in xserver-common should be in the BSPs Jul 12 09:33:15 yes Jul 12 09:34:15 https://github.com/beagleboard/meta-beagleboard/blob/master/common-bsp/conf/machine/beaglebone.conf Jul 12 09:34:22 this is the bsp I'm using so Jul 12 09:34:31 you could check that out ;) Jul 12 09:38:04 rburton: I just started the populate_sdk process, let's hope for success :D Jul 12 09:38:19 fenrig: thanks for testing :) Jul 12 09:39:20 rburton: with pleasure, but you don't have to thank me. I should thank you guys ;) Jul 12 09:40:02 rburton: whole point of upstream xserver-common is to support as many machines as possible Jul 12 09:42:50 but this doesn't play well with the layer arch : supposedly the BSP customizes the xorg.conf and provides formfactor Jul 12 09:46:16 BSPs can upstream their customizations too Jul 12 09:46:37 rburton: I think it fixed the problem Jul 12 09:55:12 JaMa: as it is now, there are around many (deprecated ?) variables defining the same thing. MACHINE_GUI_, MACHINE_DISPLAY_ now even GUI_MACHINE_CLASS Jul 12 09:56:16 formfactor uses the DISPLAY_ set of vars for xserver Jul 12 09:58:19 * ant_work notes this is a bit OT for #yocto, issues are mostly in meta-oe Jul 12 10:00:00 Hi JaMa, rburton, Can you please comment on Saul's reply here: http://patches.openembedded.org/patch/53489/ Jul 12 10:00:12 are you guys working on anything related to this? Or should I try to handle this? Jul 12 10:02:00 mshakeel: check this thread http://lists.openembedded.org/pipermail/openembedded-devel/2013-July/091262.html Jul 12 10:02:27 mshakeel: I agree that systemd.bbclass should be improved (like meta-systemd version was), but I'm not working on it Jul 12 10:04:53 i wasn't convinced at first, but the repetition is clearly showing it needs to happen centrally. Jul 12 10:05:30 i can't recall exactly what the meta-systemd systemd.bbclass did but its clearly a good starting point Jul 12 10:06:33 mshakeel: would be much appreciated if you could handle it. maybe just a install_append that deletes files as appropriate, so recipes install everything and the classes removes what it doesn't need. Jul 12 10:07:14 (iirc, the meta-systemd class was more complicated than that, and would auto-install service files in SRC_URI, but i'm not convinced that's a good idea) Jul 12 10:07:39 anyway after getting distracted by work for two hours, it's now time for my "pre-work" jog of doom. i may not return alive. Jul 12 10:08:00 rburton: ok, I will spend some time on it. Just wanted to make sure that you are not on it. thanks. Jul 12 10:08:25 mshakeel: rburton: unlike meta-systemd class we can add variable which says which .service files should be autoinstalled Jul 12 10:09:03 JaMa: as more upstreams integrate a service file, and they generally should be ran through sed to fix paths, i'm not sure that's worth it. Jul 12 10:09:04 that will resolve valid concerns about automagic issues we had with *-config Jul 12 10:09:08 * rburton really off now Jul 12 10:09:16 back in 30, apparently. Jul 12 10:10:33 rburton: have fun jogging, and thx for helping ;) Jul 12 11:10:53 It seems that the 'xserver-xorg-extension-dri' package isn't present in poky 9.0.0. How the libdri.so can be installed? Jul 12 11:15:09 romain_: its built into the server Jul 12 11:15:16 "noinst_LTLIBRARIES = libdri.la" Jul 12 11:15:59 also, see the log for xserver-xorg.inc Jul 12 11:16:01 " The following external modules are now built-in: Jul 12 11:16:03 * DBE Jul 12 11:16:05 * DRI2 Jul 12 11:16:07 * DRI Jul 12 11:16:09 * RECORD" Jul 12 11:24:59 rburton: all of sunray, to answer your question :) Jul 12 11:25:49 so I guess they won't be using Yocto after all :) Jul 12 11:25:54 thaytan: i suspected as much. ah well, the tech was neat. Jul 12 11:53:09 Ok thanks, it clears my doubts Jul 12 11:59:09 is there any plan for a cmake class? Jul 12 12:02:29 lpapp: there is a cmake class Jul 12 12:03:00 ok, so it is a documentation problem only. Jul 12 12:05:11 there is also a qmake class, already? Jul 12 12:06:10 lpapp: have a look in meta/classes, that's easier than asking here Jul 12 12:06:26 I do not have a clone right now. Jul 12 12:07:14 also, it is not entirely clear to me which meta-foo to check in general Jul 12 12:07:18 http://git.openembedded.org/openembedded-core/tree/meta/classes Jul 12 12:07:20 start with oe-core Jul 12 12:07:31 that's where the common ones all end up Jul 12 12:08:15 ok, there is no qbs class yet. :) Jul 12 12:10:30 is there actually anything releases that uses that yet? Jul 12 12:10:53 yes, of course. Jul 12 12:19:31 so I tried generating a sdk, with a lot of help op rburton it worked. But my SDK has to be able to compile Qt programs Jul 12 12:19:49 and I noticed I don't have a (native) qmake Jul 12 12:20:06 are there some special steps I have to follow? Jul 12 12:20:43 i thought qt-dev would recommend that, somehow Jul 12 12:21:43 rburton: what do you mean? Jul 12 12:22:21 i though it would get pulled in for you Jul 12 12:22:34 not sure how to get extra bits into a sdk to be honest. bluelightning? Jul 12 12:22:50 * rburton delegates because fenrig said "qt" Jul 12 12:23:40 I do have to point out that I used the meta-qt5 layer :) Jul 12 12:31:03 bluelightning: if you have time could you help me out with qt5 sdk generation? :) Jul 12 12:32:48 (he might be eating lunch) Jul 12 12:33:13 (he is) Jul 12 12:33:20 rburton: yes I though so because he says "goodmorning" a hour or 2 later then when I start working, but I tried asking it politely Jul 12 12:33:34 so that when he returns he'll answer me ^^ Jul 12 12:34:59 too bad there isn't much information about qt5 and yocto on the internet Jul 12 12:36:31 fenrig: for reference, me/bluelighting are in the UK, so it's lunchtime. which explains why i'm hungry. Jul 12 12:36:41 oh yeah I have a another question too, I promised myself that I would start working on an opensource project this summer, too contribute to the large ecosystem of gnu and linux that has helped me where I am now. Do you recommend the yocto project (bitbake & openembedded) Jul 12 12:36:43 belen: (is friday a themed lunch in the office?) Jul 12 12:36:59 fenrig: yes, of course we do :) Jul 12 12:37:36 and is there a way for a noob, like me, to start contributing in little stupid patches so that I could learn how the source works Jul 12 12:37:46 I have a fair bit of python experience :) Jul 12 12:38:04 there's an open bug tracker Jul 12 12:38:14 if you're brave, there's an in-progress python3 port. Jul 12 12:38:23 rburton: (no. Should it be?) Jul 12 12:38:24 and I'm the cream of the crop programmer of our school (isn't really a good reference) Jul 12 12:38:49 if you actually want to work on bitbake then i'm certainly not the person to talk to. try kergoth/bluelighting. Jul 12 12:38:50 but I'm a bit worried of the lean entry level :/ Jul 12 12:39:05 or is it steep in english? Jul 12 12:39:07 belen: well, burrito tuesday. fish and chips friday sounds like a good idea :) Jul 12 12:39:16 fenrig: steep Jul 12 12:39:51 rburton: ah, if that's what you mean, it might be Falafel Friday Jul 12 12:40:20 oh, now there's a reason to visit on a friday. Jul 12 12:41:50 rburton: you need a strong one to visit on fridays Jul 12 12:43:33 you know what I'll create a bugzilla account, and when I finish this job I'm in ;-) Jul 12 12:45:28 rburton: perhaps I can help with a qbs class file if it is not that hard to learn it... Jul 12 12:48:15 lpapp: writing a build system class is fairly simple as it's just the bits from the recipe, in a separate file Jul 12 13:04:01 rburton: [PATCH v3 0/1] xinput-calibrator: move it from meta-oe to oe-cor Jul 12 13:06:50 fenrig: I'm back, but to be honest I'm probably not the best person to ask about qt5 Jul 12 13:07:18 bluelightning: and about qt in general? Jul 12 13:07:35 fenrig: I can certainly try to help... Jul 12 13:07:43 bluelightning: that would be great :) Jul 12 13:09:04 bluelightning: so uhm I'm trying to incorperate qt5 into my sdk :) Jul 12 13:09:24 bluelightning: but as I understand I need qmake to support my version Jul 12 13:09:47 bluelightning: so this qmake needs to be able to cross compile or ...? Jul 12 13:10:35 I know qmake generates make and moc files for project, so it can support introspection :) Jul 12 13:10:53 fenrig: the qmake we use for qt4 is built separately as part of qt4-native (which is a dependency when building qt4-x11-free / qt4-embedded) Jul 12 13:11:01 I don't know what meta-qt5 does Jul 12 13:11:37 fenrig: so did you manage to produce an SDK with bitbake -c populate_sysroot imagename ? Jul 12 13:11:38 but qt4 is already an old version I presume? Jul 12 13:11:48 bluelightning: yes rburton made that possibe ;) Jul 12 13:12:01 ok, I have ax25, kiss modules present in the kernel Jul 12 13:12:04 bluelightning: in fact I already executed the installer :) Jul 12 13:12:11 fenrig: but it does not contain qmake and that's what you were asking about? Jul 12 13:12:14 the package name is 'kernel-module-{ax25,mkiss}' Jul 12 13:12:19 bluelightning: yes indeed :) Jul 12 13:12:27 should I add the package name as is, or is there another way to include a kernel module in the image? Jul 12 13:12:32 fenrig: ok, I might be able to answer that, one sec Jul 12 13:12:40 bluelightning: you mentioned something like RDEPENDS? Jul 12 13:12:51 bluelightning: take your time ;) Jul 12 13:12:53 eren: we always use RRECOMMENDS for kernel modules Jul 12 13:13:00 ah Jul 12 13:13:06 bluelightning: in which bb file? Jul 12 13:13:17 eren: in case the user wants to build them into the kernel rather than being built as modules Jul 12 13:13:17 RRECOMMENDS = 'kernel-module-ax25 kernel-module-mkiss', then? Jul 12 13:13:32 eren: RRECOMMENDS_${PN} += "..." Jul 12 13:13:57 eren: RRECOMMENDS like all runtime package variables need to be qualified with the name of the package to add the relationship to Jul 12 13:14:11 in this case the main package (${PN}) Jul 12 13:14:32 okkie Jul 12 13:14:45 then I will add it in libax25 package Jul 12 13:17:10 fenrig: so unfortunately it looks like nobody has added nativesdk support to meta-qt5 yet Jul 12 13:17:33 bluelightning: so I should revert back to qt4? Jul 12 13:17:51 bluelightning: or try to add nativesdk support? Jul 12 13:18:08 fenrig: it depends how much work you want to do :) Jul 12 13:18:29 it's possible someone else is planning on adding nativesdk to meta-qt5, I don't know what everyone's plans are Jul 12 13:18:38 JaMa: any ideas? Jul 12 13:18:39 bluelightning: Well unfornately it's not mine to decide, so I have to ask my boss Jul 12 13:19:22 bluelightning: how long do you think it could take me? Jul 12 13:19:30 bluelightning: a day? a week? Jul 12 13:19:57 couple of nights ;) Jul 12 13:20:16 fenrig: I would think at least a week to get it working fully unless you already have experience with qt / OE Jul 12 13:20:24 ant_work: okay :D thx for the help Jul 12 13:20:49 check qt3 layer and qt4 in oe-core Jul 12 13:20:58 you'll see the missing recipe Jul 12 13:21:08 bluelightning: I have experience with Qt but not as much as with cross compilation, and if I had to decide I'd probably try it, but my time here is limited so I don't get to decide :) Jul 12 13:30:47 and we've opted to go to qt4 Jul 12 13:31:27 bluelightning: thx for your help ;) Jul 12 13:31:34 fenrig: np Jul 12 13:31:48 does anybody know by chance which packages I have to provide to image_install? Jul 12 13:31:50 fenrig: few people asked about sdk support but nobody sent patches yet Jul 12 13:32:16 JaMa: I think Qt is pretty popular framework Jul 12 13:32:18 fenrig: qt5 is sometimes quite tricky, so a week for SDK is a minimum Jul 12 13:32:54 I wonder how they do it with ubuntu-touch Jul 12 13:32:58 and tizen Jul 12 13:33:01 fenrig: yes it is, that's why I maintain meta-qt5 :) Jul 12 13:33:12 they probably have their own buid system Jul 12 13:33:35 JaMa: nice commits on llvm, btw. Jul 12 13:33:43 but we're not using SDK internally so I cannot spend much time on it (and I would rather invest time in 5.1 recipes) Jul 12 13:34:08 eren: except the last one with zlib.. that sliped into master branch accidentally :/ Jul 12 13:34:26 JaMa: I learned to work with Qt a few months ago, and I immediatly felt why people loved it so :) Jul 12 13:34:36 JaMa: ah, it can happen all the time :) Jul 12 13:37:12 fenrig: the only thing you need to do I think is TOOLCHAIN_HOST_TASK_append = " nativesdk-qt4-tools" and TOOLCHAIN_TARGET_TASK_append = " qt4-mkspecs" Jul 12 13:37:27 oh yeah to uninstall the installed sdk should I just remove the dir /usr/lib/oecore-i686 Jul 12 13:37:45 fenrig: then if you do bitbake -c populate_sdk imagename for your image you'll get a complete Qt4 SDK Jul 12 13:37:55 fenrig: yep you can just delete it, no special uninstall needed Jul 12 13:38:04 bluelightning: yeah but my image does has to support Qt4 Jul 12 13:38:16 fenrig: right, for that you should just add your application to the image Jul 12 13:38:29 bluelightning: I'm so sorry for my english :o Jul 12 13:38:32 fenrig: required Qt libraries will be pulled in automatically via dependencies Jul 12 13:38:52 btw, which package puts bzImage to $DEPLOY_DIR? Jul 12 13:39:01 eren: the kernel Jul 12 13:39:10 bluelightning: ah yes, but for now I'd like to not make a recipe for it as I'm just playing with the system so to speak Jul 12 13:39:31 eren: i.e. linux-yocto in the default configuration, might be different depending on the BSP Jul 12 13:39:44 bluelightning: okkie, thanks Jul 12 13:40:04 eren: most of the magic is in kernel*.bbclass though Jul 12 13:41:21 fenrig: ok, if you just want to try you could build any image and add "qt4-pkgs" to IMAGE_FEATURES Jul 12 13:41:37 bluelightning: okay cool ;) Jul 12 13:42:00 oh yeah I don't know if I have to ask it here but, I'd like to run myt Jul 12 13:42:08 Qt application dedicated in the Xorg Jul 12 13:42:13 got any pointers on that Jul 12 13:42:32 or do you guys have no experience with that (I know I'm asking a lot) Jul 12 13:42:48 you know what, I'll try to find that out myself, sorry for asking Jul 12 13:42:57 well, if you're building qt4-x11-free (which qt4-pkgs will pull in) then that will be Qt for X11 Jul 12 13:43:22 for your application recipe just ensure you add "inherit qt4x11" and it'll get the appropriate dependencies Jul 12 13:43:44 bluelightning: yes that I already understand, but I'll have to figure out how to run that application like a DE :) Jul 12 13:43:44 fenrig: this might be useful: https://wiki.yoctoproject.org/wiki/Creating_a_recipe_for_a_Qt_application Jul 12 13:44:47 fenrig: I think if you have x11-base in IMAGE_FEATURES you'll get mini-x-session installed which should start up a very basic X11 session Jul 12 13:44:58 nothing like a full desktop environment but OK for single apps Jul 12 13:46:00 bluelightning: great :) Jul 12 14:08:34 I cannot precisely wrap my brain around the importance of gcc-*-initial. Is it there primarily to bootstrap the core libc-initial build? If so, where do we bootstrap native gcc, to ensure that the final gcc cross-compilers are built with the correct native compiler version? Jul 12 14:12:05 (i.e., to ensure that gcc-cross 4.8 is built with gcc 4.8 native, regardless of system compiler version?) Jul 12 14:15:54 (yes, it seems pretty obvious that both gcc-cross-initial and gcc-crosssdk-initial are both cross compilers, but I can't find any evidence of a gcc-native getting built as a dependency of meta-toolchain, and that seems unnecessarily stupid, so maybe I'm missing something) Jul 12 14:17:10 rtollert: there are actually three cross compilers.. "host" -> target (gcc-cross) Jul 12 14:17:20 gcc-crosssdk "host" to "nativesdk" Jul 12 14:17:30 gcc-cross-canadian "nativesdk" -> target Jul 12 14:17:41 fray: right, I got that far Jul 12 14:17:42 rtollert: there aren't gcc-native recipes, your host needs to provide sane gcc Jul 12 14:17:55 yup, thats what i was just abut to get to.. Jul 12 14:18:14 the host is expected to work "properly", well enought to be able to build functional software to run on that same host.. Jul 12 14:18:34 WIP section in the manual covering this stuff, btw: http://www.yoctoproject.org/docs/1.5/ref-manual/ref-manual.html#cross-development-toolchain-generation Jul 12 14:18:46 (feedback to Scott if there are any changes needed) Jul 12 14:19:43 fray JaMa: But that's explicitly described as a bad idea in the gcc docs. And it's broken miserably before — IIRC, gcc 4.6 added a -fbuilding-gcc option, or something like that, and it's physically impossible to build a gcc 4.6 cross from gcc 4.4 because of it Jul 12 14:20:23 ew have impericle evidence that we can correctly rebuild the cross compilers... until someone shows up bugs otherwise, we believe its working.. Jul 12 14:21:00 empirical even Jul 12 14:21:24 basically use us a combination of 'buildhistory' (built into the build system) to compare build output.. and I've personally compared the binaries being generated by the compilers from different hosts.. Jul 12 14:21:35 other then path name and some embedded timestamps, the generated objects are the same Jul 12 14:21:51 (last time I ran that test was the 4.7 toolchain BTW) 4.8 is still too new Jul 12 14:23:54 (you can do the comparison using hexdump on the text section of the ELF executables.. diff them and you'll see the differences are "reasonable") Jul 12 14:24:23 we had some pain building 4.7 with 4.8, that got fixed... but 4.8 has had quite a number of problems anyway Jul 12 14:24:47 yeah I was about to mention the 4.7/4.8 pain; I run Arch, so that bit me Jul 12 14:25:12 ... but, that would have bit me anyway if we built a gcc-native of 4.7 Jul 12 14:25:13 we're regularly building on hosts as old as CentOS/RHEL 5.9.. and as new as Fedora 19... Jul 12 14:26:39 right. and actually, I thought I saw official gcc docs to the effect of "make sure to match native and cross versions", but I can only find that on the osdev wiki right now. The official gcc docs merely say "use 2.95.3 or newer". So I might have been in error there. Jul 12 14:27:33 ya, it was a definite problem in the past, but it's gotten so much better in the last few years.. Jul 12 14:28:57 I thing there are still issues when someone with external-tc with older gcc tries to build newer gcc-runtime (or gcc) from oe-core Jul 12 14:29:08 yeah, I remember the bad old days. (occasionally I still live them.) the gcc devs are doing a bangup job Jul 12 14:30:21 JaMa: that reminds me, does anybody use external-tc for crosstool-ng sourced toolchains? Or is external-tc still mostly csl's thing? Jul 12 14:32:33 bluelightning: also do you recall the issues encountered so far with 4.8? Or can link me to the mailing lists/channels I need to follow to catch them? :) Jul 12 14:32:43 the normal mechanism is the csl stuff.. Jul 12 14:32:45 thanks for the answers so far btw Jul 12 14:32:56 but you could use it to introduce the crosstool, but it has to be modified Jul 12 14:33:08 rtollert: we're using external-tf for crosstool-ng created tc Jul 12 14:33:22 (I'm not a fan of the existing csl tool integration, but frankly their are the one ones who did it and keep it working.. so until someone does their own.. thats the way it's going to be) Jul 12 14:34:02 rtollert: you can also use external-linaro-toolchain for linaro binary toolchains which are created with ctng Jul 12 14:34:05 rtollert: we had the one I mentioned above, and we have had compile and boot-time issues on arm and ppc (the arm issue I think has required a kernel patch) Jul 12 14:34:33 ya, the arm issue was a kernel issue in the end.. Jul 12 14:34:47 I'm not familar with the PPC one.. is that the e500? or is there more then that? Jul 12 14:34:59 (older mips kernels required a patch as well to compile.. but once they do they appear to work) Jul 12 14:35:05 JaMa: s/external-tf/external-tc/? Jul 12 14:35:42 fray: I think so, I've not been closely involved with it but we had build failures with meta-fsl-ppc Jul 12 14:36:10 on the autobuilder, that is Jul 12 14:36:21 I think that's the e500... Jul 12 14:36:27 fray bluelightning: interesting. So y'all have somewhat less confidence of 4.8's stability wrt 4.7 Jul 12 14:36:57 rtollert: well, it's been a little bit rocky so far for sure... hopefully the issues have been ironed out Jul 12 14:37:00 * fray has been using 4.8 now for over a month.. and we're getting consistent results, and the number of ICE and related are dropping Jul 12 14:37:28 performance for some targets is significantly better though.. (at least in my opinion, I don't have any numbers to back that up) Jul 12 14:37:38 fray: building gcc svn? Jul 12 14:37:47 the one in oe-core master Jul 12 14:37:53 k Jul 12 14:38:13 we're just starting to use the pre-release eglibc 2.18 as well.. Jul 12 14:39:27 rtollert: y Jul 12 14:42:39 hhmm got a new problem Jul 12 14:42:54 apparently the gpu drivers of the BBB get compiled Jul 12 14:43:03 and it fails :/ due to compilation errors Jul 12 14:43:34 fenrig: pastebin the error Jul 12 14:43:36 I found some pastebins of people trying it with yocto, but no solutions as of now. Does somebody have some information about it? Jul 12 14:43:48 rburton: will do, wait a sec ;) Jul 12 14:44:34 https://gist.github.com/fenrig/5984988 Jul 12 14:45:55 fenrig: you'll be better trying #beagle or whatever the meta-ti/beagle support channel is Jul 12 14:47:29 rburton: yeah probably, but my working day is almost over so Jul 12 14:48:04 rburton: I'll probably start heading home and fix this problem another time, thx anyway. I think it has to do with the drivers itself and not yocto :) Jul 12 14:48:07 couple more (unrelated) questions. 1) poky's relationship with oe-core seems to be that of a downstream branch, so that patches get merged to/from; poky doesn't sync oe-core as a dependency. Is oe-core imported unmodified into poky? Jul 12 14:49:05 2) I wrote up some instructions on how to use debootstrap+schroot to build poky on an unsupported distribution; does that sound like something that would be useful to add to the wiki? Jul 12 14:49:05 rtollert: commits from bitbake, oe-core, meta-yocto, meta-yocto-bsp and yocto-docs are all applied to poky (with a few minor tweaks). Jul 12 14:49:29 rtollert: 2) yes. there was discussion about that sort of thing here a few days ago. Jul 12 14:49:49 rtollert: re (1), the tool used to make poky is combo-layer. in oe-core's scripts repo. Jul 12 14:49:58 rburton: 2) OK, I'll add my docs to the wiki Jul 12 14:51:17 rburton: is there any policy defined for applying tweaks to oe-core meta/ itself, as opposed to making them in meta-yocto? (and if so what?) Jul 12 14:52:05 rtollert: the tweaks to oe-core are trivial, iirc there's just one (to change the a message from saying oe-core to poky) Jul 12 14:52:45 rburton: excellent, thanks Jul 12 14:52:50 rtollert: that's why meta-yocto has some bbappends Jul 12 14:55:32 rburton: right.. when I couldn't find an obvious oe-core sync point, I started to worry that maybe the reason for that was that perhaps some changes to oe-core are more maintainable as changes made in a downstream branch, as opposed to confined to new layers. Sounds like that fear was unfounded. Jul 12 14:56:51 rtollert: yeah, poky is a merged repo from its parents, as you'll see from the log its got bitbake/oe-core/etc commits interleaved Jul 12 14:57:18 heh... I'm registering for a new acct on wiki.yoctoproject.org, and the Terms of Service link is a 404. Who ought to know about that? Jul 12 14:57:32 heh Jul 12 14:57:43 halstead i guess Jul 12 14:58:20 halstead: consider yourself knowing about that Jul 12 15:02:50 is anyone working on a similar tool as hob, but with qt/qml? Jul 12 15:03:07 lpapp: no Jul 12 15:03:17 lpapp: there is a web-based hob in active development though Jul 12 15:03:33 rburton: ok, I would prefer qt/qml. Jul 12 15:04:35 you can wait for webhob if gtk+ bothers you that much :) Jul 12 15:05:01 well, I do not like web stuff either. Jul 12 15:07:06 I guess there is nothing against someone contributing a qt frontend? :) Jul 12 15:07:24 if you feel motivated enough to write a third UI to bitbake, go for it Jul 12 15:07:42 rtollert, rburton I've added a link to our main terms of service for now. Jul 12 15:10:30 rburton: sure, I guess the problem would be to find reviewers. Jul 12 15:11:01 Heya. Does anyone here know what, __exactly__, is meant by "Installed but not shipped"? I keep seeing this 'warning' message and then my files are not included - in spite of my running install on them with (seemingly) proper arguments. This, BTW, is the recipe giving me issues: http://pastebin.com/C1fVc61R . Currently it complains that /usr/, /usr/lib/, and /usr/lib/perl/ were installed but not shipped - How do I ship them, and why aren't my ot Jul 12 15:11:01 her folders such as /etc/movis/ affected by tihs, when they are created with the same syntax? Kind regards. Jul 12 15:11:02 "smart"? Jul 12 15:11:22 wasn't that actually a hard disk related analyzing software initially? Jul 12 15:12:08 lpapp: http://labix.org/smart/ Jul 12 15:12:11 PACKAGES is a list of package names. FILES_packagename lists the files/dirs to go into that package. "installed but not shipped" means it got installed by do_install, but didn'mt end up in any binary pcakages. make sure its installing to correct paths, and the FILES_ variables match up with that Jul 12 15:12:20 lpapp: Smart vs SMART I guess Jul 12 15:12:40 wikipedia insists the disk one is S.M.A.R.T. Jul 12 15:13:03 rburton: honestly I don't think I would ever bother with the dots :) Jul 12 15:13:09 lpapp: nothing to stop it being out of tree i guess Jul 12 15:13:31 bluelightning: me neither, but someone must have insisted for the dots to be there Jul 12 15:13:40 rburton: bluelightning extra/smartmontools 6.1-3 Control and monitor S.M.A.R.T. enabled ATA and SCSI Hard Drives Jul 12 15:13:54 extra/libatasmart 0.19-2 [installed] ATA S.M.A.R.T. Reading and Parsing Library Jul 12 15:14:12 -> /usr/bin/smartd, etc Jul 12 15:14:19 it is going to be a bit confusing. :) Jul 12 15:14:21 sure Jul 12 15:14:31 -> /usr/bin/smartctl Jul 12 15:14:35 we didn't pick the name, it's an external tool we re-used... Jul 12 15:14:42 yeah, I know. Jul 12 15:14:44 kergoth, So, simply installing the files won't do, I need to explicitly add them to FILES_${PN} to ensure they got staged? This a bit confusing, as most recipes have not required me to do this. Jul 12 15:14:53 usually when I started a project back then, I looked for existing names. Jul 12 15:15:17 I do find myself having to explain what it is a lot when mentioning it since it's not well known Jul 12 15:15:37 a more unique name might have helped there I guess Jul 12 15:16:35 Stygia: yes, indeed. i send a detailed email on the list yesterday that would help you understand, i guess. Jul 12 15:16:59 ndec, Ah, unfortunately I am not subscribed to the list. Thanks anyway. Jul 12 15:17:07 ok, let me find the archive Jul 12 15:17:29 bluelightning: I still need to learn why it is better than existing package managers. Jul 12 15:17:41 I think the learning curve is pretty steep for Yocto. :) Jul 12 15:17:54 Stygia: https://lists.yoctoproject.org/pipermail/yocto/2013-July/017184.html Jul 12 15:18:40 Stygia: for correctness, use ${libdir} and ${sysconfdir} instead of /usr/lib and /etc Jul 12 15:19:02 rburton, Noted. Jul 12 15:19:29 ndec, Thanks, bookmarked. Jul 12 15:19:46 Stygia: tl;dr: $libdir/ isn't in FILES by default, so you'll need to add it Jul 12 15:20:03 rburton, Hmm, without appending ${D} in FILES, yes? Jul 12 15:20:35 Stygia: correct, files is target paths, not paths in the build system Jul 12 15:20:48 rburton, Alright, thanks. Jul 12 15:20:49 so FILES_${PN} += "${libdir}/perl" will do Jul 12 15:21:09 rburton, Hmm, no need to specify subfolders and files? Jul 12 15:21:12 rburton: can you give me an url to the thread about the gerrit discussion? Jul 12 15:21:31 lpapp: sorry, no Jul 12 15:22:00 Stygia: it will recurse down for you Jul 12 15:22:10 rburton: it exists? Jul 12 15:22:35 lpapp: no idea Jul 12 15:22:43 lpapp: may have been on irc, or in person at one of many conferences. Jul 12 15:23:04 rburton, Thanks. Jul 12 15:23:22 rburton: then it does not exist, so time to bring it up on the mailing list again. :) Jul 12 15:23:31 otherwise, no one will bother to actually document the decision, etc. Jul 12 15:23:40 lpapp: it's really not. OE/yocto is explicitly patch-review-by-mail. Jul 12 15:23:56 you might as well mail lkml and propose gerrit Jul 12 15:24:08 why? Jul 12 15:24:30 because that's the choice that's was made and re-agreed several times over many years Jul 12 15:24:36 because it might help them too. who knows? Jul 12 15:24:50 ok, so bitbake is written in python just like portage. Jul 12 15:25:06 lpapp: bitbake and portage share a common root Jul 12 15:25:08 rburton: well, new ideas are not to be rejected just by the sake of rejecting Jul 12 15:25:28 if gerrit had been rejected for valid reasons, it needs to be documented for others. Jul 12 15:25:34 lpapp: i think rburton means that it's not a new idea, as it's been evaluated already. Jul 12 15:25:40 so it can be reviewed, others can work on missing features, et cetera. Jul 12 15:26:06 ndec: all I am saying, nothing like that fundamental for the workflow should be hidden. Jul 12 15:26:09 whatever happened. Jul 12 15:26:40 decisions should happen openly, not just the source code ... ;-) Jul 12 15:26:46 lpapp: most of the rationale for using Smart is here FYI: https://lists.yoctoproject.org/pipermail/yocto/2012-October/012593.html Jul 12 15:27:15 lpapp: the biggest reason is that yocto/oe is review-by-mail, and gerrit doesn't let you do that Jul 12 15:27:45 rburton: well, it cannot be review-by-mail just for the sake of review-by-mail Jul 12 15:27:53 it is not a technical discussion. :) Jul 12 15:28:04 bluelightning: thanks. Jul 12 15:28:07 it cannot be gerrit just for the sake of gerrit. it's a choice. Jul 12 15:28:30 lpapp: it's really down to what the maintainers are comfortable with, since they have to interact with the process the most Jul 12 15:28:40 (re patch reviewing) Jul 12 15:29:50 rburton: sure, but gerrit has advantages over email. Jul 12 15:30:10 bluelightning: sure, but they probably have a /technical/ reasoning as well. Jul 12 15:30:14 not just the end result. Jul 12 15:32:20 iow, I am personally interested why they prefer email. Jul 12 15:32:54 because it's much easier for them to review and respond to using a program they use on an ongoing basis. They don't have to load a new window/program/environment to review and approve and merge patches.. Jul 12 15:33:07 lpapp: I know Richard has said he finds email works for him because he can easily work on it offline Jul 12 15:33:10 git is designed to interact directly with email lists.. (using git send-email as well as git am for applying), etc.. Jul 12 15:33:36 offline reading (and responding/processing) is yet another reason (as bluelightning indicated) Jul 12 15:34:25 fray: how do you review something without opening an email client up? Jul 12 15:34:50 rburton, kergoth, thanks to both of you, finally made this thing install properly. Jul 12 15:35:07 bluelightning, FYI, first build with all 80-ish modules where nothing segfaulted or complained about missing stuff.... Jul 12 15:35:24 Stygia: nice :) Jul 12 15:35:33 rburton, Quite. Jul 12 15:36:02 rburton, Also this week I learned a lot of CPAN modules are exactly the same - different names (although usually in the same Module::), but the actual archive you get is exactly identical. Jul 12 15:36:02 bluelightning: yeah, gerrit has not added such a feature because it is rare nowadays not be online, I guess. Jul 12 15:36:17 Stygia: ha! Jul 12 15:36:42 lpapp: unless you're the sort of person that travels to conferences and meetings frequently, and spend non-trivial time on planes and trains. Jul 12 15:36:43 bluelightning: although, it would be probably simple enough to send the diff in an email, not just the commit message. Jul 12 15:37:32 rburton: well, flights are usually 2-3 hours inside europe. Jul 12 15:37:41 if you travel between continents frequently, then ok. Jul 12 15:37:50 but even inside the country, buses and trains usually provide wifi nowadays Jul 12 15:37:54 lpapp, I assume they are like me.. I never close my email client.. it's always up and I'm always seeing and able to respond to new email Jul 12 15:37:57 and I can always use my mobile data plan. Jul 12 15:38:00 Stygia: FYI, a new layer was published yesterday contianing a few additional perl recipes for supporting other recipes - http://layers.openembedded.org/layerindex/layer/meta-security/ Jul 12 15:38:19 fray: the point is that, it is not an advantage apart from offline reading. Jul 12 15:38:29 its a workflow advantage.. Jul 12 15:38:35 fray: because it is just yet another window/tab like the web interface. Jul 12 15:38:52 I know personally I don't want "yet another tool" to do effectively what can be done in email, where everything is already automatically processed and archived.. Jul 12 15:38:53 so you do not spare window/tab in that sense if you are online. :) Jul 12 15:38:53 can we please stop discussing the personal workflow of people who are not here Jul 12 15:39:03 some people in oe use patchwork, but thats about the extent of the tooling Jul 12 15:39:06 but the email client *is* a tool. Jul 12 15:39:10 Stygia: also I just got a recipe for libio-pty-perl up-to-date based on an old recipe from OE-Classic, haven't sent it out yet Jul 12 15:39:20 Stygia: not sure if either of those overlap with the recipes you've been working on Jul 12 15:39:26 * fray yields as this is a personal preference and not something worth arguing.. Jul 12 15:39:59 fray: actually, I do not think certain feature lacks are personal preference. :) Jul 12 15:40:04 like, how you group patches? Jul 12 15:40:07 do* Jul 12 15:40:21 how can you add reviewers anyone registered easily? Jul 12 15:40:45 email threads... and reviwers are anyone who subscribes to the mailing list Jul 12 15:40:46 or you email your patch to Jul 12 15:41:00 how do you know who subscribed for? Jul 12 15:41:07 * fray goes back to work.. I'm not going to argue this Jul 12 15:41:08 on gerrit, you start typing a name and it is there. Jul 12 15:41:08 lpapp: for groups of patches we use pull requests containing a pointer to a branch, we even have a couple of scripts to create and send those easily Jul 12 15:41:15 regardless whether you interacted with that person before. Jul 12 15:41:21 also, how do you group changes with email? Jul 12 15:41:40 stable, master, next, different repositories, based on reviewers, authors, etc. Jul 12 15:41:50 it is getting tricky with a dedicated interface. Jul 12 15:41:51 without* Jul 12 15:42:03 * rburton too Jul 12 15:42:52 bluelightning: grouping, but not in that sense as you seem to have understood. Jul 12 15:43:19 how can you check only file in a diff with email? Jul 12 15:43:31 email was not meant like for such nice code review specific features. Jul 12 15:43:38 meant for*\ Jul 12 15:43:54 bluelightning, At a glance, neither do. Jul 12 15:44:18 bluelightning: email is a generic interface, and certain review specific features cannot be present that way. Jul 12 15:44:35 bluelightning, Will have a look at what you published though. Jul 12 15:45:20 bluelightning, And thanks for your help so far, you've really been invaluable. Jul 12 15:45:36 bluelightning: I think email was okay until someone put some significant effort to have a dedicated tool specialized for codereview features. Jul 12 15:46:11 bluelightning: and repeating for the record, adding a diff sending is probably an easy feature to add. Jul 12 15:46:27 because the commit header is already sent via email. Jul 12 15:46:57 I just think it was not high priority due to the available internet connection almost everywhere nowadays. Jul 12 15:47:32 * ant_work notices our similarity with http://lists.infradead.org/pipermail/linux-arm-kernel/ Jul 12 15:48:23 lpapp: email for patches is fundamental to the way our maintainers work; our process is derived from the kernel process which is pretty well established; git's email-based functionality follows on from that Jul 12 15:48:48 lpapp: if we were to use an additional tool it would have to integrate with email and not impose the use of that tool on maintainers Jul 12 15:49:27 hence, the patchwork tool is about the closest thing there is, although it needs some tweaking Jul 12 15:50:11 bluelightning: well, it would not be the first time people start using new tools. Jul 12 15:50:25 getting used to something is not equivalent automatically to the best tool available. :) Jul 12 15:50:53 if the only thing the maintainers say, they do not wanna change, that is ok, but that is not technical. Jul 12 15:51:08 technology always improves. :) Jul 12 15:51:38 no, this is mostly not a technical decision I agree, it's how maintainers have established their workflow Jul 12 15:51:43 if you try to achieve the things I mentioned above, it might be realized, those are not so handy with emails. Jul 12 15:52:12 and you have to have a pretty compelling technical solution that covers the existing use cases to address that Jul 12 15:52:44 any tool that lacks easy offline usage is not going to be workable Jul 12 15:53:13 it is, for me at least, like when people got used to svn which was not meant for merging at large. Jul 12 15:53:29 yeah, it is not a merge tool as such, but then some svn people do not change to git to solve those issues. Jul 12 15:53:55 there's also the issue that patches and discussions often overlap, if these are able to happen in the same place i.e. mailing lists then there is no danger of discussions being split Jul 12 15:53:57 bluelightning: I still think that, that is a minority of the maintainers most probably. :) Jul 12 15:54:04 but yes, that is an easy fix IMO. Jul 12 15:54:30 I will be travelling 3000 km tonight to a conference, and I will be covered by internet most of the time. Jul 12 15:55:44 bluelightning: I agree, and that is why I think a mixed solution would be worse than now. Jul 12 15:56:40 the only big issue with the current system is that it's hard to get a view on the outstanding patches Jul 12 15:56:45 having patchwork should solve that Jul 12 15:57:05 well, you would have a mixed interface Jul 12 15:57:11 instead of gerrit, where you can do everything in one place. Jul 12 15:57:24 including outstanding, but even abandoned ones. Jul 12 15:57:54 except gerrit won't be the place for non-patch discussions Jul 12 15:57:59 so, two places Jul 12 15:58:05 (that's what I meant above) Jul 12 15:59:04 bluelightning: actually it can be sometimes. Jul 12 15:59:14 but yeah, mailing list would be necessary, or irc, or something else. Jul 12 15:59:51 bluelightning: but you would probably have two places in your email client for those two as well, I gues. Jul 12 15:59:54 guess* Jul 12 16:00:00 patch and discussions folder. Jul 12 16:00:21 actually I don't... I could, but I find it easy enough to navigate with one folder for each mailing list Jul 12 16:00:29 and there are devs who do not use the mailing list, just very rarely.. they use irc for online chat, and then the review tool to review. Jul 12 16:00:51 the problem is that, you would be spammed by a lot of changes. Jul 12 16:01:59 but patchwork would not be an email solution either, anyhow? Jul 12 16:04:30 patchwork pretty much revolves around email - it picks up patches from emails and attaches threaded discussions to them Jul 12 16:04:49 http://patchwork.openembedded.org/ Jul 12 16:05:10 so, it is a web, and not email client. Jul 12 16:05:23 just like gerrit is, so you would not introduce more separated parts altogether. Jul 12 16:05:54 ok, anyway, fair enough. Jul 12 16:06:38 lpapp, we have had these conversations many times over the years Jul 12 16:06:47 and what we have know works well for the project Jul 12 16:07:57 Crofton|work: so what? I am a newcomer, and I have not been to those discussions. Jul 12 16:08:05 and I am not sure if experts had been there either. Jul 12 16:08:25 so a newcomer rightfully asks these questions IMHO. Jul 12 16:09:03 lpapp: OE is ~ten years old, so yes, this has been discussed before Jul 12 16:09:05 in fact, I suggested to document those for your future convenience, in the very first place. Jul 12 16:09:05 lpapp: I think what Crofton|work is saying is, we have genuinely looked at the process and the alternatives over the years (and fairly recently) and the decision has been that email works for us Jul 12 16:09:24 rburton: I know 20 years old projects where it has not been discussed. Jul 12 16:09:53 bluelightning: how do you know you looked at the process right, and a newcomer cannot open up new things? Jul 12 16:10:00 it is not something "done" Jul 12 16:10:10 technology is continously improving and advancing, changing, et cetera. Jul 12 16:10:50 anyway, I strongly suggest to document it... I am fairly certain I would not be the first, nor the last one asking these questions. Jul 12 16:11:53 imho, it is a rude, and potential loss to say to newcomers, "we discussed it thoroughly, and you cannot come up with anything new, so please stop it here now". Jul 12 16:11:59 it is rude* Jul 12 16:12:25 especially when the whole stuff is well hidden completely as it seems ... Jul 12 16:13:15 lpapp: I wouldn't view it like that Jul 12 16:13:27 lpapp: we're just saying it has come up Jul 12 16:13:51 bluelightning: if you read back, it has been said that "we discussed it, so let us stop it". Jul 12 16:14:33 lpapp: the trouble is the biggest impact is on the maintainers rather than other community members, and those are the people who have to be convinced Jul 12 16:15:23 bluelightning: yes, sure, but "let us stop it in the way of total hidden untrasparency" in an open project is well ... not helpful with that. :) Jul 12 16:16:40 bluelightning: believe it or not, for my contribution, it is a serious concern. Jul 12 16:16:57 so it is good to understand why I take sacrifice if I happen to do. Jul 12 16:20:17 lpapp: except we are pretty transparent, all discussions and patch review happens in the open on the mailing list Jul 12 16:22:07 bluelightning: I am referring to the "gerrit decision". Jul 12 16:22:32 lpapp: I'm not saying we shouldn't document that, we probably should Jul 12 16:25:47 it might be a little bit over the top to say we have "total hidden untransparency" just because we haven't documented that Jul 12 16:27:10 well, nothing is documented so it is fully hidden as of now. :) Jul 12 16:42:15 https://www.yoctoproject.org/documentation/build-appliance-manual -> so virtualbox is not tested? Jul 12 16:43:46 what is the difference between core-image-base and core-image-basic? The documentation does not make it that clear for me. Jul 12 16:44:54 qt4e-demo-image -> do you plan to have a qt5 variant? Jul 12 16:48:43 lpapp: there is a qt5 layer available, just not in core yet: git://github.com/meta-qt5/meta-qt5.git Jul 12 16:51:01 would it be in core for the next release? Jul 12 16:51:21 Hi all. I've got a custom layer I've written - it includes recipes for both a server daemon and a dynamically loadable module that the server uses. However when building with the module I need to modify the daemons.conf line to add support for the module... What's the correct technique to do this from the recipe? Jul 12 16:52:34 postinst script, most likely Jul 12 16:52:59 is there ubifs support in Yocto? Jul 12 16:55:48 lpapp: likely not for 1.5, which is the current planned release for Oct timeframe Jul 12 16:56:07 lpapp: ^^^ was in reference to qt5 Jul 12 16:57:15 sgw1: :( Jul 12 16:57:34 qt5 was released in december. Jul 12 16:57:43 it would be a pitty to wait more than a year for it to appear in Yocto Jul 12 16:57:52 lpapp: that's what the layers are for, its trivial to add it Jul 12 16:58:26 sgw1: yeah, but it is not nice if many people add it, instead of one centralized place... Jul 12 16:59:02 what can I do to help with getting this into the release in October? Jul 12 16:59:17 lpapp: we don't keep everything in oe-core, it will be something to look at for future releaes Jul 12 17:00:31 lpapp: BTW, ubifs is supported in yocto via the mtd-utils package and you can create a ubifs image. Jul 12 17:01:06 sgw1: we have three months until that release. Jul 12 17:01:19 and this feature cannot get in, even if it gets help from an upstream developer? Jul 12 17:03:21 lpapp: we have layers to help support upstream development when something is not yet in the core. Those layers are maintained also. Jul 12 17:04:15 sgw1: you claimed that it would not be released any soon Jul 12 17:04:25 end users need releases. Jul 12 17:10:18 lpapp: please read back more carefully, I said that qt5 would not be in the 1.5 release, it is available as a layer and that layers are supported. The layer mechanism was created for exactly this reason to allow for other projects to work with the core. Not everything will be in the oe-core and we need a plan for transitioning from qt4 to qt5 Jul 12 17:11:16 qt 5.0 has been released for more than half a year go Jul 12 17:11:22 and now we got even a new feature release, 5.1 Jul 12 17:11:45 if it is not getting released this year, Yocto will cause additional pain to qt5 developers. Jul 12 17:12:37 lpapp: we have the layer structure to allow additional items to be added easily Jul 12 17:12:56 but why would they add that "easily"? Jul 12 17:13:00 lpapp: we haven't had the resources to work on qt5, but luckily Martin and co have been able to do so in meta-qt5 Jul 12 17:13:02 when it can be solved centrally? Jul 12 17:13:51 I think if it takes 4-5 months at least + another few to get a qt5 package up... that is worrying to say the least. Jul 12 17:15:34 I am wondering why 3 months are not enough for stabilizing those packages, especially if it is now in a good shape? Jul 12 17:16:20 lpapp: some features are missing, such as SDK generation Jul 12 17:16:46 (because it hasn't been needed by the primary contributors to meta-qt5 so far) Jul 12 17:16:47 You know, I one wondered why no one had done a thing I wanted done in Yocto. Eventually I concluded that it had not yet been important enough to someone who had the time. So I did it. Jul 12 17:17:14 sure, I would be happy to help qt5 going on. Jul 12 17:18:50 feel free to distribute tasks to me. :) Jul 12 17:19:01 that is what I offered before. Jul 12 17:19:06 bluelightning: Have you ever modified conf files from a do_install() function? Jul 12 17:19:12 so I am wondering why it would not be stable enough to get in, with my help by October? Jul 12 17:21:06 lpapp: we can certainly evaluate it as time goes on, if it's ready well before october (last milestone is for stabilisation and we prefer to avoid taking new features during that time) then perhaps Jul 12 17:21:36 pev_: sure, using sed I have yes Jul 12 17:21:49 lpapp, the planning for the next release has already been done Jul 12 17:21:59 qt5 would be fairly major update Jul 12 17:22:34 and by the next cycle we should have a fairly well tested qt5 in the meat-qt5 Jul 12 17:22:40 bluelightning: Is that the best way to do things then? Just do checks to see if you've already made the change and if not use sed to mod in? Was just wondering if theres a more elegant mechanism... Jul 12 17:23:02 pev_: If your modifing another packages conf files you would need to do a postinst as kergoth suggested before Jul 12 17:23:05 Crofton: well, qt4 should not be killed. Jul 12 17:23:12 so I do not see the risk respectively. Jul 12 17:23:28 at any rate, are there tasks for that work on the issue tracker? Jul 12 17:23:47 pev_: it depends on the nature of the change really; if it's fixing an issue or adding a substantial part I'd use a patch rather than sed'ing in do_install Jul 12 17:23:51 it is vary acceptable to use layers Jul 12 17:24:12 we want to keep the core layer very focused and not start moving more and more in over time Jul 12 17:24:22 pev_: but the standard way to insert dynamic paths and values of variables is to use sed on the config file (after installing rather than before, so re-executing the task works) Jul 12 17:24:55 Crofton: as I said, qt5 was released relatively long ago Jul 12 17:25:01 and we have 5.1 as well now. Jul 12 17:25:17 it is a valid expectation not to make qt5 users' life hard. Jul 12 17:25:30 more difficult than it could be, that is. Jul 12 17:25:35 adding meta-qt5 should not make your life hard Jul 12 17:25:35 lpapp: that is correct, it's just that the majority of users we have are still working with apps that build on top of qt4 Jul 12 17:25:39 and qt5 and qt4 should exist simultaneously. Jul 12 17:25:43 for a few years. Jul 12 17:25:54 lpapp: but luckily, the community as a whole hasn't ignored qt5, we have a layer to support it already Jul 12 17:26:14 bluelightning: new developers will not pick up qt4 at all. Jul 12 17:26:28 and there are already several big projects built around qt5. Jul 12 17:26:43 sgwl: is that using "pkg_postinst_${PN} () {" - only refs I can see Jul 12 17:26:45 lpapp: I'm not in any way suggesting qt5 isn't important Jul 12 17:27:03 lpapp: with the resources we have we just have to pick the stuff we can to work on Jul 12 17:27:11 pev_: yes that would be the construct Jul 12 17:27:38 bluelightning: its just adding a line to dynamically load a module and modifying another two to change two vars. I didn't think it was sensible to use patches at that point in the build process? Jul 12 17:27:46 sgwl: Thanks will try that Jul 12 17:28:09 bluelightning: well, I would be a resource for qt5. Jul 12 17:28:25 the reasoning accordingly can be void. :) Jul 12 17:28:35 pev_: right, it depends on the nature of the changes being made Jul 12 17:28:53 lpapp: great! Jul 12 17:29:15 may I ask for concrete tasks again? Jul 12 17:30:03 lpapp: beyond adding support for building nativesdk (for SDKs) I'm not sure what needs doing Jul 12 17:30:29 sgw_: do you mean using the postinst so that it only runs on the target as I see in various examples? Is this really much different to modifying in the rootfs before packaging? Jul 12 17:30:34 lpapp: but really this is a case where someone such as yourself with Qt5 experience can help identify anything that might be missing Jul 12 17:31:28 bluelightning: "building nativesdk (for SDKs)" -> not sure that is a show stopper. Jul 12 17:31:46 I imagine Yocto would be more useful for embedded at this stage. Jul 12 17:32:18 lpapp: it is for us, people expect to have externally usable SDKs containing the tools that they can run outside of the build process Jul 12 17:33:04 lpapp: especially important for things like Qt which are used by app developers that aren't closely involved in the system development and thus won't be using the build system directly Jul 12 17:33:31 bluelightning: not sure I follow. Jul 12 17:33:51 bluelightning: wouldn't the SDK mean qtcreator, documentation, assistant, designer, and all that? Jul 12 17:34:04 bluelightning: that is not used when shipping an embedded system. Jul 12 17:34:13 they might be used on the host PC with affected distributions. Jul 12 17:34:54 lpapp: it's not for shipping, it's for when applications are being developed Jul 12 17:35:13 lpapp: I'm more thinking of qmake/moc/etc. rather than QtCreator etc. Jul 12 17:36:05 lpapp: really the most important part of the SDK is the cross-compiler, which we naturally already handle; but users expect to have the other Qt-specific build tools available as well Jul 12 17:36:18 bluelightning: those tools should come with qt5-core Jul 12 17:37:01 lpapp: yes, they do... but the recipes we have currently can only build those for native (host) and the target, not for SDKs Jul 12 17:37:02 qtchooser* Jul 12 17:37:31 bluelightning: that is enough. Jul 12 17:37:46 if you supply mkspecs files, those can cross-compile. Jul 12 17:39:04 in our system, SDKMACHINE i.e. the machine the SDK is intended to run on is not necessarily the same as the host Jul 12 17:39:22 yes, mkspecs are part of the target portion of the SDK, those aren't a problem Jul 12 17:39:23 sure, it is the matter of using the right mkspecs file. Jul 12 17:39:35 for applications Jul 12 17:39:43 for qt itself, -platform and -xplatform. Jul 12 17:39:51 OK, so if Ive added a pkg_postinst_${PN} function, when does it get run? It look like normally bit-baking the recipe doesnt execute it Jul 12 17:41:43 pev_: it will be run every time the package is installed... in practice, that will be attempted at one of three times - 1) image construction time on the host when the package is included in the image; 2) if that fails, on first boot of the image; or 3) if the package wasn't included in the image but runtime package management is enabled and the package gets installed/upgraded at a later date on the target Jul 12 17:42:38 Ok, thanks. So for convenience prototype my changes under do_install then move to postinstall once working correctly? Jul 12 17:43:10 I guess I do not yet understand what goes into bsp. Jul 12 17:43:15 pev_: I'm assuming so... I'm still not totally sure I understand what you're trying to do though Jul 12 17:43:34 lpapp: everything that's specific to the machine supported by the BSP Jul 12 17:43:40 I see regular userspace linux utils in there alongside u-boot, grub, and so forth. Jul 12 17:43:51 bluelightning: which BSP? Jul 12 17:44:11 lpapp: I'm speaking generally for any BSP Jul 12 17:44:22 lpapp: which one are you looking at? Jul 12 17:44:42 we have a custom board. Jul 12 17:44:49 bluelightning: basically I have a layer within which are two recipes. 1) a daemon with a config, 2) a dynamically loadable module for the daemon. When I build the modules recipe it needs to modify the .conf file installed by the daemon to add the line to dynamically load the module. Jul 12 17:45:06 pev_: ah right, now I get it Jul 12 17:45:21 bluelightning: Should be easy eh? :-D Jul 12 17:45:26 but how is keymaps for instance BSP related? Jul 12 17:45:37 instead of say... corE? Jul 12 17:45:39 core* Jul 12 17:45:48 pev_: yes, that is a case where a postinstall script is needed; and I don't think prototyping it in do_install will work unless you mean do_install of the daemon recipe Jul 12 17:46:11 lpapp: that's typically where there is a custom keymap for the specific machine Jul 12 17:46:31 lpapp: usually it's done as a bbappend so it's modifying the existing keymaps recipe Jul 12 17:47:04 bluelightning: Gotcha. Just an idiot question, am I right in thinking that postinstall gets executed in both the dev host AND on the target? Jul 12 17:47:15 some of the comments indicate that Jul 12 17:48:37 bluelightning: but it is more like a core package for distributions.. Jul 12 17:48:54 cannot mention any distribution without it. Jul 12 17:49:48 pev_: yes, basically as I described above Jul 12 17:49:59 lpapp: it is, and that's why the core bit is not in the BSP Jul 12 17:50:06 I'll give that a go, thanks. Jul 12 17:50:07 I gotta go, have a good weekend all Jul 12 17:50:11 but keymap is in BSP. Jul 12 17:50:13 not in core. Jul 12 17:50:16 You too. Enjoy the sun Jul 12 17:50:24 for keymaps, you have to have a board that supports 'keys'.. not all of them do Jul 12 17:50:28 lpapp: not the whole recipe, it's a bbappend as I mentioned already Jul 12 17:51:35 glib is core?! Jul 12 17:51:42 really? Jul 12 17:52:13 why is a gnome library core? Jul 12 17:54:34 Crofton|work: btw, I would probably use qt5 for a qt frontend of bitbake. Jul 12 17:54:43 lpapp, because it's really good =) Jul 12 17:54:47 look at the dependency tree.. there are a large number of basic applications these days that require glib Jul 12 17:56:31 walters: let us agree to disagree. ;) Jul 12 17:56:44 fray: same can be said about qt-core Jul 12 17:57:59 what is the recommended place for adding an updated u-boot version and ignore what is in the release? Jul 12 17:58:13 uboot versions are usually tied to the BSP.. Jul 12 17:58:15 updated u-boot version with one custom patch for our board. Jul 12 17:58:26 should I create another layer? Jul 12 17:58:35 or should I make a new recipe in meta-bsp? Jul 12 17:58:43 So placing uboot within the BSP layer (and/or patches to the base version) is the usual approach Jul 12 17:58:52 or a new one in recipes-bsp? Jul 12 17:59:10 new recipe vs extending the existing is up to the requriements of the BSP creator Jul 12 17:59:32 but you should have your own BSP layer, and within that layer place the items in similar locations to the existing system.. Jul 12 17:59:34 extending does not help as in our release, the u-boot version is pretty old. Jul 12 17:59:58 own BSP layer means? Jul 12 18:00:20 standard practice is when you add functionality to the system you do so in a layer in which you create.. Jul 12 18:00:37 you should create a BSP layer for your custom board, and place firmware and boot items within that layer so that it's all together.. Jul 12 18:00:44 it makes long-term maintenance of the BSP easier Jul 12 18:01:18 applications generally should not be in the BSP layer, unless the application is specific to functionality of that board Jul 12 18:01:20 you mean this? Jul 12 18:01:27 meta-foo/recipes-bsp? Jul 12 18:02:08 you create a new layer.. meta-foo Jul 12 18:02:22 you place the contents within meta-foo.. recipes-* replacing * with the appropriate directory Jul 12 18:02:50 why are there a few layers by default? Jul 12 18:03:26 I am especially thinking of meta-yocto? Jul 12 18:03:35 they group the software and help delinate maintenance responsibilities.. Jul 12 18:04:00 meta -- oe-core, meta-hob and meta-skeleton come from oe-core.. Jul 12 18:04:43 meta-yocto-bsp and meta-yocto come from the Yocto Project Jul 12 18:05:23 for a basic system (oe-core) you only need to use the oe-core layer.. but you get a basic distribution configuration and access to only the QEMU bsps.. Jul 12 18:05:30 so there is someone sync'ing up with oe upstream? Jul 12 18:05:35 adding in the meta-yocto and meta-yocto-bsp layers add additional functionality Jul 12 18:05:39 yes Jul 12 18:06:28 BSP-layers usually consist of the machine configuration, and patches as part of the linux recipe Jul 12 18:06:30 http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/?h=master-next -> so meta-qt5 is not planned to be an addition here for the next release so far... Jul 12 18:06:51 so by the easy way, it was meant like we can clone the meta-qt5 repository, and copy into the yocto project folder? Jul 12 18:06:57 http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/ Jul 12 18:07:03 that is the current state of Poky Jul 12 18:07:19 http://git.openembedded.org/openembedded-core/tree/ Jul 12 18:07:29 that is the current state of oe-core.. you will see they are very similar.. Jul 12 18:07:53 poky is made up of oe-core + meta-yocto Jul 12 18:07:58 (meta-yocto: http://git.yoctoproject.org/cgit/cgit.cgi/meta-yocto/tree/) Jul 12 18:08:09 git://github.com/meta-qt5/meta-qt5.git Jul 12 18:08:17 poky is provided as a unit as a convienence to developers so they don't have to assembly it themselves.. Jul 12 18:08:17 so we should clone that, and copy into the poky tree? Jul 12 18:08:21 that is what "easy" means, right? Jul 12 18:08:34 you should clone it, and add it to your projects bblayers.conf file Jul 12 18:08:51 k, ty... Jul 12 18:08:55 g2g, take care Jul 12 18:11:08 I have a problem with meta-qt5, my recipe does not set proper paths until I copy-paste OE_QMAKE_PATH_HEADERS and others from qt5.inc into my .inc. How to avoid this? Jul 12 18:20:26 is avahi a DISTRO_FEATURE? Jul 12 18:20:28 it should be Jul 12 18:24:05 trollixx: that's OK, see wiki on meta-qt5 Jul 12 18:24:14 trollixx: only QT_HEADERS should be needed Jul 12 18:27:04 who was it that was doing most of the read-only-rootfs work, again? Jul 12 18:28:12 JaMa: thanks, I missed it in wiki Jul 12 18:28:29 * kergoth just had an idea to create -volatile packages that include tmpfiles.d/volatile configurations to symlink paths the recipe needs to write to, then set up a dbg/dev-like install of complementary volatile packages in r/o rootfs constructions Jul 12 18:29:41 kergoth: that was a guy in china, Qi Chen Jul 12 18:30:17 aside: we should really have a sseparate script which creates systemd tmpfiles.d-based stuff and migrate our old volatiles to it, or something, having two implementations of this is rather ugly Jul 12 18:30:48 JaMa: Isn't it possible to put this path in mkspecs? Jul 12 18:30:53 trollixx: I know it's not elegant, but other option would be to assume that every app using qmake to build itself wants to install headers and libs in qt5 prefix and that's IMHO worse Jul 12 18:31:14 yeah Jul 12 18:31:25 trollixx: the problem is that there isn't good separation between "search" paths and "install" paths Jul 12 18:31:55 or at least I haven't found it :) Jul 12 18:32:37 Hm, ubuntu use the same separation if qt4 and qt5 headers... Jul 12 18:47:40 My image is installing avahi, but I'm not adding this dependecy no where.. when I do a bitbake -g -u depexp I see that avahi depends on libnss-mdsn which no one is depending Jul 12 18:48:02 kergoth: yes, having two solutions for /run is madness. Jul 12 18:48:41 what I see in the recipes is that libnss-mdsn depends on avahi.. and avahi has this: RRECOMMENDS_avahi-daemon_append_libc-glibc = "libnss-mdns" and RRECOMMENDS_${PN}_append_libc-glibc = "libnss-mdns" Jul 12 18:50:05 what is this _append in RRECOMMENDS ? Jul 12 18:57:34 _append is magic, it means that whatever happens to the value otherwise, after that's done the _append values will be added on to the end. Jul 12 18:59:03 not magic enough, I want bitbake to append whatever I'm thinking about to that variable before I even write it in the recipe Jul 12 19:03:34 seebs_: ok Jul 12 19:04:23 but still doesn't make sense why libnss-mdns (and then avahi) is been installed in the image Jul 12 19:05:50 Ohh. Looking more closely. _append_libc-glibc is an override-append. Meaning it's applied only if libc-glibc is in the OVERRIDES list. So presumably the intent is that if you don't have libc-glibc, that RRECOMMENDS won't get added. Not sure why. Jul 12 19:06:34 It seems sort of odd that they're both getting brought in. It seems like adding avahi is intended to recommend (but not require) libnss-mdns, and that libnss-mdns is intended to require avahi, but I am not sure how it's getting around to looking at either. Jul 12 19:27:55 seebs ftonello: fwiw, libnss-mdns can optionally query avahi for cached mdns resolution, so that's where that dep is coming from Jul 12 19:47:16 fray: wn Jul 12 19:47:19 was tnere Jul 12 19:47:26 sorry, lemme try again. :) Jul 12 19:47:36 fray: was there anything else you wanted to share with me? Jul 12 21:25:22 rtollert: i didn't get it Jul 12 21:27:49 ftonello: sorry, I meant the mdns->avahi dep. I don't know about the more important question (where either of the two are being depended on). :F Maybe run bitbake -g and look at task-depends.dot for which task is bringing in one of those two? Jul 12 21:35:50 rtollert: ok.. as I said, mdns is the one who brings avahi dependency, but no other package depends on mdns, i shows alone in the reverse dependency list (using -u depexp) **** ENDING LOGGING AT Sat Jul 13 02:59:58 2013