**** BEGIN LOGGING AT Thu Feb 18 02:59:57 2010 Feb 18 04:52:55 hi Feb 18 04:53:01 I am trying to do a git pull Feb 18 05:01:03 but I keep getting an error about something not being up to date Feb 18 05:09:09 git status Feb 18 05:09:12 You likely modified a file. Feb 18 06:17:11 bkero: I did modify a file Feb 18 06:17:34 is there anyway to make it ignore that file and update the rest? Feb 18 06:19:32 Move your file, git checkout file, move file back Feb 18 06:19:47 Or push your change to a git branch, checkout master again, pull Feb 18 06:22:47 hmm k Feb 18 06:27:21 thanks Feb 18 06:34:41 Aditya__1, git stash Feb 18 08:43:12 hi florian Feb 18 08:44:15 good morning Feb 18 09:00:19 good morning Feb 18 09:06:42 hi mckoan Feb 18 09:15:32 morning all Feb 18 09:17:50 hi RP Feb 18 09:19:56 hi Feb 18 09:32:14 morning Feb 18 09:34:22 hi hrw Feb 18 10:16:28 RP: hola Feb 18 10:21:51 can anyone actually like me in to out revert policy? my googlefu is failing this morning :-( Feb 18 10:25:31 XorA: come again? don't understand your msg (especially the "in to out" part, so my understanding stops at "can anyone actually like me" :-) Feb 18 10:25:54 which i guess is a rhetorical question ( big :-) ) Feb 18 10:26:29 eFfeM-work: my typing fails, link me in to Feb 18 10:27:01 * XorA keeps switching between normal and natural keyboard and the keys move Feb 18 10:28:27 ah ok, that sounds much better, well a search on revert* in wiki.openembedded.net only gives; http://wiki.openembedded.net/index.php/Commit_log_example Feb 18 10:28:51 and this: http://wiki.openembedded.net/index.php/Stable#Rejecting_changes Feb 18 10:29:01 fwiw Feb 18 10:29:02 yeah, Im sure it was codified on the mailing list, but gmane search fails me Feb 18 10:30:05 actually for things to become persistent they'd better be documented into a less volatile place, we cannot expect new devs to go over 5 years of oe ml log to find out the policies Feb 18 10:33:37 XorA: get usb natural ones and trash normal ones Feb 18 10:35:01 XorA: you needed this: http://thread.gmane.org/gmane.comp.handhelds.openembedded/19729/focus=19741 ? Feb 18 10:36:56 eFfeM-work: no actually policy there though Feb 18 10:37:24 hrw: its mostly when I work on customer site I have to use what is there Feb 18 10:38:50 I think the reversion policy used to be on the wiki, but either it's been deleted or the page is no longer linked so it is hard to find. Feb 18 10:39:02 All the old policy stuff from there seems to have been removed at some point. Feb 18 10:39:11 XorA: bring your own kbd with you (actually that the advance of laptops,btw brought my trackball with me on some occasions, first time people look strange, 2nd time they are used to it) Feb 18 10:39:47 and people wonder why I hate wikis Feb 18 10:39:47 pb_ you mean this one: http://wiki.openembedded.net/index.php/Commit_Policy Feb 18 10:40:07 eFfeM-work: no, I don't think it was that one Feb 18 10:40:55 I do remember us signing off on one that required Acks etc etc Feb 18 10:41:00 but I cant bloomin find it Feb 18 10:41:21 pre TSC era Feb 18 10:41:59 I wonder if we need a policy about pulling distro specific stuff into generic targets. Feb 18 10:42:39 XorA: if you find it, please post a link Feb 18 10:43:03 florian: well one of the issues here is console-image and x11-image and Angstrom targets Feb 18 10:43:18 florian, don't really fully understand your remark Feb 18 10:43:44 possible solution: put distro specifics in distro dir or in a separate overlay Feb 18 10:44:03 florian: they were originally named angstrom-console-image and angstrom-x11-image Feb 18 10:45:59 XorA: yes I remember... well at this time we did not think about that just renaming would not solve possible conflicts about its contents. (no idea if there was any angstrom specific stuff in there before) Feb 18 10:46:33 florian: the ANGSTROM_* variables were always there Feb 18 10:49:31 btw for x11-image there is already an angstrom specific variant (angstrom-x-image) Feb 18 10:50:25 eFfeM-work: sometimes it is really hard to decide... oe has the power to keep things in one place but sometimes (like in this case) when things are quite complex it is better to have distro specifi bits in separate files. Feb 18 10:51:17 eFfeM-work: use git log --follow Feb 18 10:53:46 * XorA thinks he should stop going out clubbing or gigs as these things only happen when he is out at these places :-) Feb 18 10:54:16 florian: actually i have no problems keeping things in one place but others seem to want specific privileges to certain files; best solution then is to make those identifiable (either by name or dir or so) so people know when they are breaking new grounds Feb 18 10:54:30 time for recipes/umbumba-images/ dir? Feb 18 10:54:51 bb in few Feb 18 10:55:29 hrw in principle there is the same problem for packages Feb 18 10:56:59 with RPs layer stuff if it goes in there is no real reason at all why core OE should have any distro specific stuff in it at all Feb 18 10:57:16 OE can become a library to be reference by distro layers Feb 18 10:57:55 XorA: agree Feb 18 10:58:42 that would make OE a build infrastructure build on top of bitbake with a set of "common" recipes. Feb 18 11:00:57 the issue that comes out of that is of course _${DISTRO} overrides Feb 18 11:02:17 XorA: from a technical point of view i agree... but on the other hand it means additional effort to propagate useful things from the distros to core Feb 18 11:03:24 eFfeM-work: Well, half the problem with *-image is that they were originally clearly Angstrom specific but were then made more generic without fully removing all the Angstrom references. Feb 18 11:03:45 Meaning that they're currently an unhappy mismatch of generic and distro specific. Feb 18 11:04:00 right Feb 18 11:04:14 this change should have been made when the image was renamed Feb 18 11:04:33 it should have been rater a split than a rename at this time Feb 18 11:06:16 koen was right though, the more sensible solution was to put IMAGE_EXTRA_INSTALL ?= "${ANGSTROM_EXTRA_INSTALL}" in the files then the users of ANGSTROM_EXTRA_INSTALL could have migrated Feb 18 11:06:55 florian i agree it makes things backporting somewhat more difficult. then again I would like to aim that people work in the common tree (and for me it is ok to have _{DISTRO} overrides there as long as they are not turning it into a distro specific recipe (or start to claim ownership) Feb 18 11:10:20 iirc these overrides are usually used for logo/splashscreens Feb 18 11:10:48 yeah (except for u-boot) Feb 18 11:11:03 like for psplash, I'd personally prefer a provider and some specific recipes Feb 18 11:11:12 and except for kernel stuff Feb 18 11:11:22 instead of hacking _distro in the recipes Feb 18 11:12:36 * RP remembers writing something about a revert policy :/ Feb 18 11:19:23 maybe in this thread: http://thread.gmane.org/gmane.comp.handhelds.openembedded/17795/focus=17811 Feb 18 11:19:29 but there is too much in it to read now Feb 18 11:22:56 btw also found this: http://wiki.openembedded.net/index.php/Category_talk:Policy Feb 18 11:23:07 not really about revert thoug Feb 18 11:25:19 How do you view deleted pages on the wiki? :/ Feb 18 11:25:42 RP this one is not deleted, it is a talk page Feb 18 11:25:59 eFfeM-work: I'm not talking about that one ;-) Feb 18 11:26:09 it depends on the wiki sw and config if people can actually delete pages Feb 18 11:26:27 and sometimes if you need a deleted one you can recreate it then view the history Feb 18 11:26:44 not sure what the #oe wiki exactly has as options and config Feb 18 11:34:12 lunch Feb 18 12:03:58 re Feb 18 12:10:00 RP: what's your opinion about having EXTRA_IMAGEDEPENDS += "xyz" in machine.conf or related includefiles? Feb 18 12:10:33 ant_work: Thats very vague and there are better fileds for things like that Feb 18 12:10:46 The specific example is Zaurus ;) Feb 18 12:11:03 we pull in (in dev) zaurus-installer Feb 18 12:11:30 so the point is: should the 'installer' be part of any image or just built alone? Feb 18 12:12:18 I actually did a patch that introduced IMAGE_EXTRA_DEPLY Feb 18 12:12:31 ant_work: there are MACHINE_ESSENTIAL_RDEPENDS and similar aren't there? Feb 18 12:12:34 to deploy stuff that is needed to install an image Feb 18 12:12:43 I end up with two images depending on linux-kexecboot :/ Feb 18 12:12:54 XorA: right, I'm sure there was already something that did this too Feb 18 12:13:02 all is built in parallel and 'just works' but seems awckward Feb 18 12:13:28 RP: people tend to use IMAGE_EXTRA_DEPENDS, but this doesnt actually make stuff deploy Feb 18 12:13:35 I might have missed the proper variable Feb 18 12:15:27 XorA: somehow we got updater.sh to deploy... Feb 18 12:15:36 * RP doesn't remember how offhand Feb 18 12:16:20 RP: I think that broke when tasks were re-ordered Feb 18 12:16:25 RP: I thought that creating a separate zaurus-installer (depending on zaurus-updater and linux-kexecboot) was the best way to pack those two together Feb 18 12:17:00 this would apply to the general flasher+image case Feb 18 12:42:55 03David-John Willis  07org.openembedded.dev * r27ae9191f5 10openembedded.git/ (3 files in 3 dirs): Feb 18 12:42:55 xfce4-power-manager: Remove broken xfce4-power-manager_4.6.1.bb and add latest 0.8.4.2 to xfce-extras. Feb 18 12:42:55 * xfce4-power-manager_4.6.1.bb was a dummy package that never worked (a left over from my Xfce 4.6.1 work). 0.8.4.2 is the correct version to use with Xfce 4.6.* >. Feb 18 12:43:05 03David-John Willis  07org.openembedded.dev * r1186314549 10openembedded.git/recipes/xfce-base/xfwm4-themes_4.6.0.bb: xfwm4-themes 4.6.0: Refactor recipe to clean up the production of the theme packages and make sure that xfwm4-themes is a valid meta package that depends on all the individual themes (over 80 of them). Feb 18 12:45:51 XorA: does it matter if such a policy exists? I have to say I wasn't aware of policy on reverts. But I double-checked with Mickey and he confirmed and I take his word for it. The point is the revert wasn't necessary and destructive. And it's the recurring pattern that's the problem. Feb 18 12:46:41 i agree with Laibsch Feb 18 12:47:27 you can't slam people on the fingers because they touch what you believe are your files, if you do not show the same respect to others Feb 18 12:48:24 btw tonight i'm going to rename mythtv_0.22.bb to mythtv_0.22+fixes.bb, which I feel is the right name Feb 18 12:49:44 hm... perhaps 0.22+0.23 would better adhere to the policies here ;) Feb 18 12:49:45 unless someone objects before ofc :-) Feb 18 12:49:50 lol Feb 18 12:50:43 ant_work: +0.23 could also be the case but the mythtv website also calls it fixes or 0.22fixes or so (and I think debian also does that) Feb 18 12:50:53 but eFfeM-home will verify Feb 18 12:51:32 well, being that vercmp seems still broken it's not soo bad :/ Feb 18 12:51:52 RP: It's a bit hidden, but generally, generated pages can be found when you click on "Special pages" in the wiki, a couple of clicks more will get you to http://wiki.openembedded.org/index.php?title=Special%3ALog&type=delete&user=&page= which has deleted pages Feb 18 12:52:46 But I don't think the doc team was ever asked to include a policy on reverting stuff Feb 18 12:53:13 I did find the references to the policy people are thinking of, it was on the oe-private list Feb 18 12:53:14 Mickey only told that Koen had previously already been sanctioned a "no revert at all" ban on him for six months Feb 18 12:53:23 that explains it ;-) Feb 18 12:53:26 It should have become a policy, I'm not sure it did officially Feb 18 12:53:28 that nobody knew about it Feb 18 12:53:41 I guess it was policy Feb 18 12:53:50 but it wasn't announced to the public Feb 18 12:53:53 Koen did know about it at least Feb 18 12:54:06 He wasn't a member of -private at the time? Feb 18 12:54:14 Laibsch: he was Feb 18 12:54:21 Then he knew about it Feb 18 12:54:32 Laibsch: I did say that Feb 18 12:54:33 Anything else would have surprised me Feb 18 12:54:42 Oh Feb 18 12:54:44 Sorry Feb 18 12:54:53 My brain added a "not" in your sentence ;-) Feb 18 12:55:37 Koen knows that reverts cause friction and has had ideas suggested to him about how to handle them better :/ Feb 18 12:56:02 but the matter is with the TSC and OE e.V. now so lets see what happens Feb 18 12:56:41 RP: obviously in an ideal world all distro would be able to build any images without special hacks Feb 18 12:57:00 atm some overhead is needed Feb 18 12:58:40 or do you have any suggestion about compatibility masks for image/distro like we have for machine? Feb 18 13:00:22 my opinion is there are perhaps too many images, some almost unmaintained Feb 18 13:02:50 ant_work: This isn't purely a technical issue but because of all the historical baggage has much wider implications and I'm glad to see RP indicate an understanding of this. Feb 18 13:03:29 right Feb 18 13:03:50 I'll try to restrain myself a bit from now to not fan the flames (although I did send a couple more juicy mails 15 odd minutes ago) Feb 18 13:04:46 Let's see if our governance processes work better this time. At least reaction time is almost instantly and proactively. I'm very happy to see that. Feb 18 13:09:06 * XorA is going to suggest that the topic becomes closed on oe-devel until TSC has a chance to meet Feb 18 13:09:26 the discussion stopped being constructive last night Feb 18 13:10:21 XorA: Are you thinking of the admin panel in a forum software? Feb 18 13:10:43 I think your suggestion makes sense, but I see no technical means to achieve them Feb 18 13:10:51 no, just a polite suggestion for people to stop mailing Feb 18 13:10:57 yes Feb 18 13:11:23 I'll try to do my part Feb 18 13:12:35 its getting pretty close to http://en.wikipedia.org/wiki/Godwin%27s_law already Feb 18 13:13:13 anyway I need to go out find lunch then go to work, back later Feb 18 13:29:25 03Koen Kooi  07org.openembedded.dev * rb377f83fde 10openembedded.git/conf/checksums.ini: checksums: fix git merge damage, sorry about that Feb 18 13:38:29 mickeyl: good afternoon Feb 18 13:38:37 hi pb_ Feb 18 13:39:26 Laibsch: about the tosa modules, perhaps our zaurus-2.6.inc is wrong Feb 18 13:39:35 or something has been renamed Feb 18 13:39:35 lrg: Can you take a look at the pulseaudio recipes? It doesn't like the latest version compiles and it seems you did not properly use the inc file when adding the latest recipe (or was it woglinde who reintroduced INC_PR incorrectly?). Feb 18 13:40:11 ant_work: I'm not really in the mood for any significant contribution to OE at the moment. Feb 18 13:40:18 pb_: where should i look to fix a driver that exposes a dev file that while reporting being ready to read blocks when you actually try to read. this way it effectively blocks my mainloop since the poll() always returns and then the read() hangs. O_NONBLOCK doesn't help, btw. Feb 18 13:40:38 Laibsch: oh, it might be me. let me have a look Feb 18 13:40:44 OE over the years has brought many frustrations but hardly ever anything that just worked[tm] for me. Feb 18 13:40:50 lrg: thanks Feb 18 13:40:50 Laibsch: I mean it's a metadata bug and not distro isse. Feb 18 13:41:03 lrg: I think it was likely woglinde's mistake Feb 18 13:41:32 lrg: http://bugs.openembedded.org/show_bug.cgi?id=5404 and http://tinderbox.openembedded.org/packages/pulseaudio/ you will immediately see the difference in PR Feb 18 13:41:57 ant_work: ultimately, everything can be fixed in OE meta data Feb 18 13:42:04 lines in OE are always blurry Feb 18 13:42:42 mickeyl: it ought to be checking for O_NONBLOCK in its read() method and acting accordingly. which driver is this? Feb 18 13:42:52 My general distinction (with exceptions) is problems on device -> NOTOURBUG. problems during compilation -> OE bug. Feb 18 13:43:07 03Thomas Zimmermann  07org.openembedded.dev * rb4c79ba094 10openembedded.git/recipes/aceofpenguins/ (aceofpenguins_1.2.bb files/fix-crosscompile.patch): Feb 18 13:43:07 aceofpenguins: fix crosscompilation Feb 18 13:43:07 * libpng and zlib from buildhost were used Feb 18 13:43:07 * now builds with libpng-native and zlib-native Feb 18 13:43:07 Signed-off-by: Martin Jansa Feb 18 13:43:10 03Martin Jansa  07org.openembedded.dev * r357e89f526 10openembedded.git/recipes/qt4/ (5 files): (log message trimmed) Feb 18 13:43:10 qt4-tools-native: set libdir and incdir in .inc file Feb 18 13:43:10 * move SRC_URI and EXTRA_OECONF for new versions to .inc and changed to Feb 18 13:43:10 old version Feb 18 13:43:10 * remove LFLAGS setting from 4.6.* versions (replaced with -L param) Feb 18 13:43:11 * Idea also Acked-by: Holger Hans Peter Freyther Feb 18 13:43:11 Signed-off-by: Martin Jansa Feb 18 13:43:12 03Martin Jansa  07org.openembedded.dev * r7f50e79364 10openembedded.git/conf/distro/include/preferred-xorg-versions-live.inc: Feb 18 13:43:12 preferred-xorg-versions-live: update dri2proto and pixman requirements Feb 18 13:43:13 Signed-off-by: Martin Jansa Feb 18 13:43:15 03Martin Jansa  07org.openembedded.dev * r7c32647443 10openembedded.git/recipes/dri/libdrm_2.4.18.bb: Feb 18 13:43:22 pb_: http://tomoyo.sourceforge.jp/cgi-bin/lxr/source/drivers/staging/dream/smd/smd_qmi.c Feb 18 13:43:25 mickeyl: but, if poll() always says it is ready even when it isn't, that sounds like a poll bug as well. Feb 18 13:43:28 staging/armv4t-oe-linux-gnueabi/usr/lib/libpangocairo-1.0.la Feb 18 13:43:28 are pulling Feb 18 13:43:30 let me take a look at that Feb 18 13:43:50 awesome, thanks. bbl, have to do PC support for a friend *sigh* Feb 18 13:43:55 ant_work: I'm afraid that currently means, there is no proper place to record and discuss on-device bugs. Feb 18 13:43:59 mickeyl: heh, enjoy Feb 18 13:44:03 *nod* Feb 18 13:44:30 Laibsch: go ahead with the axe...there is still a pile of 'invalid' bugs Feb 18 13:46:03 mickeyl: looks like it doesn't implement poll() at all, in which case you will get the default behaviour of always ready Feb 18 13:46:12 mickeyl: and, indeed, its read() method doesn't respect O_NONBLOCK Feb 18 13:47:10 ant_work: I know it's unsatisfactory, but I don't have a proper solution. I created a tracker for Sonkei on Launchpad and moved a couple of on-device bugs over there, but my enthusiasm for all of this has reached an all-time low. I'm not sure if OE will ever be able to deliver what I'm looking to get out of it. Again, I'm sorry not being able to offer any solution. Feb 18 14:16:28 (02:10:32 PM) Laibsch: I'll try to do my part Feb 18 14:16:32 I'll try too Feb 18 14:16:46 hope that'll keep the others quiet too Feb 18 14:27:04 03David-John Willis  07org.openembedded.dev * r2844d88537 10openembedded.git/recipes/gnome-mplayer/ (6 files): Feb 18 14:27:04 gnome-mplayer: Add INC_PR support to recipes, add 0.9.9 and bump svn to latest SVN not the same checkin as the 0.9.9 release. Feb 18 14:27:04 * Also mark SVN and def_pref=-1 so people default to the latest stable 0.9.9 as that is the same code as the old SVN recipe. Feb 18 14:32:18 mickeyl: you need to manage your schedule better, if I have to do PC support for a friend it is always in the evening, so I can also support him emptying a beer :-) Feb 18 15:00:43 what is our position on applying/importing patches from bitshrine.org (ltib) Feb 18 15:09:31 As far as I know there is no particular policy for that. Do you think there ought to be? Feb 18 15:10:01 If the patches have a suitable license, and they do something worthwhile, then I don't think there is any reason you shouldn't go ahead and apply or import them. Feb 18 15:11:44 eFfeM-work: ltib is GPL-2. Doesn't that prohibit inclusion in OE without being granted a relicense? Feb 18 15:12:23 If the author says, this needs to remain open-source, we can't just go ahead and say "go ahead and keep this to yourself if you want" Feb 18 15:13:00 * Laibsch wonders how many violations we already have (if the assumption is correct) Feb 18 15:17:13 LTIB is licensed under the GNU General Public License V2 or later (GPL). Feb 18 15:18:03 eFfeM-work: what do you want to import? just to focus the problem Feb 18 15:26:47 That raises an interesting question about whether we can include GPLv2 patches in OE? Feb 18 15:27:22 or whether some of the files in OE are not under the main licence at least Feb 18 15:32:06 I don't think it would necessarily be desirable to include GPLv2 patches in OE. There's no reason you couldn't refer to them (as external files) from a recipe of course, but checking them into the actual repository doesn't sound like a terribly good idea. Feb 18 15:32:30 Practically speaking, if they are patches against a source package which was itself GPLv2 then I don't think there would be any real issue, but in general it sounds like something best avoided. Feb 18 15:33:47 (Obviously there would be nothing to stop one from putting a new COPYING file at the top level and just saying "the following parts of this tree are actually licensed as GPLv2 rather than MIT...", but that sort of thing seems like it would become unpleasantly messy and complicated; you'd end up with corporate users feeling that they needed to strip out the GPL bits before importing the tree and that kind of thing.) Feb 18 15:37:22 And, applying GPLv2 patches against software that was previously under a different license might be particularly undesirable since that would cause the resulting binaries to become GPL-licensed. That might lead to nasty surprises for people who don't want to ship GPL bits in their systems. Feb 18 15:45:30 pb_: I think you miss my specific concern - if you write a patch against something which is GPL, there are bits of GPL code embedded in that patch Feb 18 15:45:48 Regardless of which licence the author then puts the patch under Feb 18 15:46:32 Its an interesting siutation but I guess you only hit it if you distribute resulting binaries so in the real world its less of a problem Feb 18 15:46:33 RP: yes, I understand. But, since that patch is (in almost all cases) only useful to apply against sources that are themselves GPL, I don't think this is much of an issue in practice. Feb 18 15:47:11 You would have a problem if you generated a patch against a GPL tree and then managed to apply that patch to a tree that was licensed in some other way, but I don't think this happens very often. Feb 18 15:47:19 pb_: it just suggests that the "licence" for OE is not a trivial question Feb 18 15:47:41 Since there are hunkslumps of code in the OE tree already that are GPL Feb 18 15:48:13 mckoan: Laibsch1 was called away. the issue is as follows. there is a u-boot version for calamari (mpc853ds) in OE, but there are some issues with it, in bitshrine there are patches, I've applied and tested these locally but was not sure whether I could check them in into oe Feb 18 15:48:18 yes, indeed. as I say, I don't think it is very desirable to have that GPL stuff in there, because it does make the licensing situation tricky, but I think it is more of a theoretical concern than a practical one. Feb 18 15:48:32 they have names like: u-boot-200910-cd77dd10-8536ds-don-t-expand-eSDHC-data-int.patch Feb 18 15:48:41 pb_: You think we can avoid patching all GPL software? Feb 18 15:48:59 RP: no, but I think we could arrange to host those patches somewhere other than in the OE tree itself. Feb 18 15:49:20 pb_: agreed, that looks desireable Feb 18 15:49:29 even if that was a parallel tree in the same git repository, at least you would then have clarity as to which bits are MIT-licensed and which are not. Feb 18 15:49:35 doesn't gpl require that we can provide the code ? Feb 18 15:49:49 pb_: right Feb 18 15:49:53 eFfeM-work: no, it requires that the person distributing the binary can provide the sources. Feb 18 15:49:59 eFfeM-work: you have to differentiate between the code and OE meta-data Feb 18 15:52:01 pb_, Laibsch1 understood Feb 18 15:52:17 should i do a http:// in the recipe ? Feb 18 15:52:32 yes, that would be fine Feb 18 15:52:41 ok Feb 18 15:53:01 there is no problem with retrieving patches from external URIs and applying them; you just need to make sure that the resulting LICENSE field in the recipe is consistent with the license of the patch. Feb 18 15:53:40 it is only when you check the patch itself into the oe tree (in order to refer to it as file://) that the licensing issue becomes sticky. Feb 18 15:55:22 the patches themself do not mention a license Feb 18 15:55:50 assume GPL-2, then Feb 18 15:55:57 here is one: http://www.bitshrine.org/gpp/0034-PowerPC-85xx-Add-localbus-node-in-MPC8536ds-dts-fil.patch Feb 18 15:56:25 i'll use http, will test then check in, need to go now, will connect later from home Feb 18 16:01:37 eFfeM-work: doh, too legal for me, but IMHO if you are patching a GPL licensed package (u-boot) I don't see any issue with OE Feb 18 16:02:17 eFfeM-work: the risk wold be to remove every GPL package from OE Feb 18 16:02:54 eFfeM-work: I prefer to consider OE ad an 'user' of each package rather than 'the package' itself Feb 18 16:03:04 s/ad/as Feb 18 16:26:08 morning kergoth Feb 18 16:26:15 hey Feb 18 16:56:49 has anyone else been seeing issues on a clean build with gtk+-native failing requiring you to bitbake jpeg-native, libxext-native, and libxrender-native prior? I wonder if its DEPENDS should include those instead of or in addition to jpeg libxext libxrender Feb 18 17:02:03 home :-) Feb 18 17:12:53 tharvey native recipes have to depend on native recipes Feb 18 17:13:33 BBCLASSEXTEND will make it harder in the future to make such errors Feb 18 17:14:58 woglinde, so your saying the gtk+ recipe should be patched? I'm not clear what all the -native stuff is - its new to me but its been a while since I sync'd up with OE. I assume all -native are things needed on host? Feb 18 17:15:07 not clear why gtk+ would be needed on host though Feb 18 17:30:08 tharvey huh? Feb 18 17:30:22 tharvey native stuff is for running on the host Feb 18 17:30:42 you need this sometimes to generate stuff like pictures or so Feb 18 17:33:38 it does seem a bit decadent to build gtk+ and all its dependencies for the native system. do you know what actually depends on gtk+-native? Feb 18 17:34:48 i suspect this is the bad guy: glib-2.0/glib-2.0-native_2.16.1.bb:DEPENDS = "gtk-doc-native" Feb 18 17:36:08 oops that is gtk not gtk+ Feb 18 17:39:27 grepped again, it is uim-native and gdk-pixbuf-csource-native Feb 18 17:39:49 but i noticed before that sometimes there is some odd and unexpected stuff being build Feb 18 17:43:20 03Tom Rini  07org.openembedded.dev * r14bb71705b 10openembedded.git/recipes/initscripts/ (initscripts-1.0/sysfs.sh initscripts_1.0.bb): Feb 18 17:43:20 initscripts: Have sysfs.sh do similar checks to rcS and bump PR. Feb 18 17:43:20 rcS checks for [ -e /sys/kernel ], sysfs.sh, for proc will check Feb 18 17:43:20 -e /proc && ! -e /proc/mounts, so for sysfs check for Feb 18 17:43:20 -e /sys && ! -e /sys/kernel && sysfs in /proc/filesystems Feb 18 17:43:57 the issue I'm running into is explained by someone else here: http://old.nabble.com/Re:-Desktop-Image-Build-Failure-(gtk%2B-2.18.6)-p27566033.html Feb 18 17:44:24 I ran into this on one build system, but not another (same source/configuration) so I would guess its a timing issue (I'm not using parallel or threads) Feb 18 17:45:26 odd Feb 18 17:45:48 my issue was slightly different and I no longer have the logs Feb 18 17:46:11 eFfeM: gdk-pixbuf-csource-native does have a lot of native dependencies Feb 18 17:46:12 my issue specifically complained about missing jpeg Feb 18 17:46:43 the missing jpeg is probably a missing dependency somewhere (as might the other two files be) Feb 18 17:46:55 but can't really build gtk+ now Feb 18 17:47:23 looks like it was gnome-keyring that required gtk+-native - not clear yet why my custom image even needs that Feb 18 17:47:47 ah... gst-plugins-good->libsoup->gnome-keyring Feb 18 17:48:50 df Feb 18 17:49:00 seems like org.openembedded.dev/recipes/gtk+/gtk+-native_2.12.11.bb should also depend on jpeg-native etc - not clear why it works sometimes and not others Feb 18 17:50:08 someone else might have dragged it in Feb 18 17:50:45 I mean same source/conf worked on one build machine but not another - which would indicate some timing related thing Feb 18 17:51:49 do environment vars override local.conf ? Feb 18 17:52:11 effeM: no, vice versa Feb 18 17:52:16 env never overrides config Feb 18 17:52:25 ok, thanks Feb 18 17:53:02 kergoth: unless its weakly assigned :) Feb 18 17:53:09 kergoth: checked again, Feb 18 17:53:16 actually that is just what i wanted to say :-) Feb 18 17:53:59 well, even then its not overriding the config, the config is deciding voluntarily to not set it :) Feb 18 17:54:21 eFfeM, env shouldn't override in my case, I'm using whitelist Feb 18 17:55:20 tharvey: this was not related to your problem, but a problem which i was having. all my machines except one use glibc, but one uses eglibc and also uses TARGET_OS = "linux-gnuspe" Feb 18 17:55:51 eFfeM, your talking about your build hosts? Feb 18 17:56:00 targets Feb 18 17:57:15 i build for 7 different machines, 4 different architectures (i686, armv5, armv7, ppc) fortunately only one endianness Feb 18 17:57:16 I'll have to kick off a fresh build and recreate my issue then I can work through it and/or explain it in more detail - I asked first because I thought it was a common thing or something perhaps recently fixed that I missed a patch for Feb 18 17:57:37 ok, np Feb 18 17:57:45 thx for help Feb 18 18:05:43 pb_: ok, thanks, so that basically means the driver sucks a bit and would need fixing Feb 18 18:52:06 mickeyl: yeah, it seems Feb 18 18:52:36 I don't think it would be terribly hard to fix on either score, but it would need a bit of work. Feb 18 19:06:26 have a nice rest of day Feb 18 19:12:24 I'm trying to create a recipe for graphviz (need it for some webadmin image generation of dot formats) - having trouble with autotools/libtool resulting in '/bin/sh: ./mkdefs: cannot execute binary file' in do_compile - is this a common thing? Feb 18 19:13:04 the mkdefs is coming from arm-angstrom-linux-gnueabi-libtool - perhaps I need to run libtoolize or something to reconfigure libtool? Feb 18 19:47:39 tharvey: this looks like the build process builds a binary tool that gets executed later. Feb 18 19:48:10 tharvey: this of course is a bad idea if you are crosscompiling Feb 18 19:49:09 yup... just trying to figure out why - graphviz uses autotools so I'm not sure why it would be doing this (poor use of autotools perhaps) Feb 18 19:51:00 was actually surprised that nobody has found the need for a graphviz recipe yet - perhaps there is something else in OE that generates images from dot graphs? Feb 18 19:52:32 not that i'm aware of Feb 18 19:53:08 if you can't get around this with autotools you can make a native recipe and run the tool from staging Feb 18 19:53:32 libtool is being used - log.do_compile shows: /bin/sh ../../arm-angstrom-linux-gnueabi-libtool --tag=CC --mode=link ccache arm-angstrom-linux-gnueabi-gcc -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -isystem/home/tharvey/oe/landroids2/tmp/staging/armv7a-angstrom-linux-gnueabi/usr/include -fexpensive-optimizations -frename-registers -fomit-frame-pointer -O2 -ggdb3 -Wno-unknown-pragmas -Wstrict-prototypes -Wpo Feb 18 19:53:32 inter-arith -Wall -ffast-math -L/home/tharvey/oe/landroids2/tmp/staging/armv7a-angstrom-linux-gnueabi/usr/lib -Wl,-rpath-link,/home/tharvey/oe/landroids2/tmp/staging/armv7a-angstrom-linux-gnueabi/usr/lib -Wl,-O1 -Wl,--hash-style=gnu -o mkdefs mkdefs.o -ldl Feb 18 19:54:15 looks like that should be the host libtool vs the target libtool as thats to generate a util thats run on host Feb 18 20:05:03 florian: good evening Feb 18 20:06:10 tharvey: yes.. in fact it is more. for the native tool it needs to use the whole native stack Feb 18 20:07:07 well, if it's only linking against -ldl then there is not much of a stack involved :-) Feb 18 20:07:12 but you're right, in general it ought to Feb 18 20:09:29 sadly I think automake is (still) lacking proper support for build-time helper programs. you can do it in plain autoconf, by using something like $(BUILD_CC) as your compiler, but I don't think there is any way to persuade automake to output the right bits without splitting the helper programs into a whole separate package. Feb 18 20:09:41 or, at least, a subdir with its own configury Feb 18 20:10:00 florian, so your saying I should perhaps make graphviz dep on a graphviz-native and then tweak its build to call the auto-built tools from the native staging area? Feb 18 20:10:21 pb___: heh true Feb 18 20:11:08 tharvey: yes right this would be a possible solution. Feb 18 20:11:33 not really nice but there are some other bits that need the same Feb 18 20:25:40 automake support for build time bits would be lovely. i wonder how much work that would be.. Feb 18 20:32:41 mm, dunno. I suspect it would be as much of a political as technical problem. Feb 18 20:33:01 heh Feb 18 20:33:01 if you look at the archives of the automake list, people have been talking about this for the best part of a decade and it never really seems to go anywhere Feb 18 20:33:07 ah Feb 18 20:33:10 that's unfortunate Feb 18 20:35:12 http://sources.redhat.com/ml/automake/2004-01/msg00152.html is a fairly representative example of that kind of thread Feb 18 20:36:12 the general consensus there seems to be that the "right way" is to put the build-side bits in their own directory and configure them separately. Feb 18 20:36:30 approximately like gcc does for its runtime libraries, though of course in that case it's for the host vs target distinction rather than host vs build. Feb 18 20:37:18 (gcc itself still does have a hand-written Makefile.in for the main compiler, and they handle the build-time utilities specially in there.) Feb 18 21:27:16 Hi all. I was wondering if OpenEmbedded supports any machine architectures that don't have an MMU? Feb 18 21:28:52 I do see some machine confs that mention software FPU emulation Feb 18 21:44:47 zenlinuxPDX, if mmu-less machine runs standard linux kenrel or uclinux,and uses standard userland...you could try and see Feb 18 21:44:55 s/if/if your Feb 18 21:45:47 zenlinuxPDX, btw what's the link between fpu-less and mmu-less? Feb 18 21:48:37 GNUtoo, not trying to suggest a link, just that FPU-less architectures tend to be less sophisticated systems Feb 18 21:48:50 ok Feb 18 21:49:03 I gave a presentation on OE the other night in Portland, OR, and someone asked me about support for MMU-less systems. I didn't have an immediate answer. Feb 18 21:49:16 but fpu is emulated in fpu-less systems so not a big issue apart speed Feb 18 21:49:21 right Feb 18 21:49:23 ok Feb 18 21:49:32 maybe look for arch without an mmu Feb 18 21:50:02 look also in kernel for uclinux Feb 18 21:50:23 like for instance linux for portable games consoles like nitendo ds or psp Feb 18 21:50:38 ok Feb 18 21:53:35 there is a recipe for blackfin Feb 18 21:53:42 and maybe that's mmu-less Feb 18 21:54:17 there is also a recipe for old ipods Feb 18 21:54:20 which uses uclinux Feb 18 21:54:38 sorry it was not handhelds gaming console but ipod...bad memory Feb 18 22:22:52 cbrake, who has the necessary access to add a public key to the git server, again? Feb 18 22:34:45 kergoth: I can do that Feb 18 22:34:49 kergoth: checking list Feb 18 22:35:11 my macbook is down until i get a new magsafe adapter in the mail, and it had my key :) Feb 18 22:35:30 so figured adding another and removing it after that, if you wouldn't mind that Feb 18 22:36:12 kergoth: sure, send it over -- cbrake@bec-systems.com Feb 18 22:37:26 cbrake, sent, thanks. Feb 18 22:42:07 kergoth: ok, give it a try Feb 18 22:43:51 cbrake, works, thanks :) Feb 18 22:44:02 kergoth: sue Feb 18 22:44:04 *sure Feb 18 23:04:45 is there a generic image/task thats designed to install dev tools on target? Feb 18 23:19:12 03Andrea Adami  07org.openembedded.dev * r162fb1acf2 10openembedded.git/recipes/kexecboot/kexecboot-cfg_0.1.bb: kexecboot-cfg_0.1: minor edits (one echo is enough). No runtime changes. Feb 18 23:46:44 yes Feb 18 23:46:48 task-sdk-native Feb 18 23:47:02 Some of the naming stuff drives me crazy, but i suck at names :) Feb 18 23:50:42 Tartarus, thx - I'll give that a shot Feb 19 00:01:20 03Martin Jansa  07org.openembedded.dev * r67d82332de 10openembedded.git/conf/distro/include/sane-srcrevs.inc: Feb 19 00:01:21 EFL: bump SRCREV a bit, big python-EFL cleanup Feb 19 00:01:21 Signed-off-by: Martin Jansa Feb 19 00:01:22 03Martin Jansa  07org.openembedded.dev * r9ba3f175d5 10openembedded.git/conf/distro/include/preferred-shr-versions.inc: Feb 19 00:01:22 preferred-shr-versions: use udev 151 and usbutils 0.86 Feb 19 00:01:22 Signed-off-by: Martin Jansa Feb 19 00:01:24 03Martin Jansa  07org.openembedded.dev * r5b50d796a9 10openembedded.git/ (2 files in 2 dirs): Feb 19 00:01:24 xf86-video-glamo: bump SRCREV for xserver 1.8 compatibility and move SRCREV from srcrevs.inc Feb 19 00:01:24 Signed-off-by: Martin Jansa Feb 19 00:01:29 03Martin Jansa  07org.openembedded.dev * re447274278 10openembedded.git/ (2 files in 2 dirs): Feb 19 00:01:29 mesa-dri: update PV, SRCREV for 7.8, needed for xserver 1.8 Feb 19 00:01:30 * disable gallium for om-gta02 Feb 19 00:01:30 Signed-off-by: Martin Jansa Feb 19 00:01:31 03Thomas Zimmermann  07org.openembedded.dev * r6b41c59b6a 10openembedded.git/recipes/shr/phoneui-shr-theme-neo_git.bb: Feb 19 00:01:31 phoneui-shr-theme-neo: add new recipe Feb 19 00:01:32 Signed-off-by: Martin Jansa Feb 19 00:01:32 03Martin Jansa  07org.openembedded.dev * r051ef10289 10openembedded.git/ (2 files in 2 dirs): Feb 19 00:01:33 libdrm: update PV, SRCREV after 2.4.18 release, needed for newer mesa-dri Feb 19 00:01:33 * disable radeon and enable libkms for om-gta02 Feb 19 00:01:34 Signed-off-by: Martin Jansa Feb 19 00:01:34 03Martin Jansa  07org.openembedded.dev * r2613ee5ac5 10openembedded.git/recipes/xorg-xserver/ (2 files in 2 dirs): Feb 19 00:01:35 xserver-xorg_git: fix build after mesa 61d26bc82e7c4100acfb551cbb0ba9d84bbc4ba5 Feb 19 00:01:36 Signed-off-by: Martin Jansa Feb 19 00:01:36 03Martin Jansa  07org.openembedded.dev * r38f8179119 10openembedded.git/ (9 files in 3 dirs): Feb 19 00:01:37 shr-neo-theme: lower dependencies from RRECOMMENDS to RSUGGESTS, update SRCREVs Feb 19 00:01:37 * SRCREVs moved from sane-srcrevs.inc Feb 19 00:01:38 Signed-off-by: Martin Jansa Feb 19 00:01:54 Signed-off-by: Martin Jansa Feb 19 00:23:52 03Martin Jansa  07org.openembedded.dev * reebdc1719a 10openembedded.git/conf/distro/include/sane-srcrevs.inc: Feb 19 00:23:52 Revert "EFL: bump SRCREV a bit, big python-EFL cleanup" Feb 19 00:23:52 * Too soon for that, works ok with ~/.e created before and fails Feb 19 00:23:52 without one (in one intro wizard step or another) Feb 19 00:23:52 This reverts commit 67d82332de85bec36b389e956edaa37ff4a1d664. Feb 19 02:02:41 still trying to understand, what's the differencde between PV and PKGV... Feb 19 02:05:00 anyone knows? **** ENDING LOGGING AT Fri Feb 19 02:59:57 2010