**** BEGIN LOGGING AT Fri Jul 26 02:59:57 2013 Jul 26 06:13:05 morning all Jul 26 06:13:33 basic question, does anyone know the name of the package that provides xvfb in yocto? Jul 26 06:23:40 melonipoika: which version? Jul 26 06:24:24 melonipoika: have you checked the graphics recipes? Jul 26 06:24:45 melonipoika: check xserver-xorg.inc Jul 26 06:25:12 i am using ti mcsdk, let me check what version of yocto it is absed Jul 26 06:25:51 ${PN}-xvfb Jul 26 06:26:01 so it is xserver-xorg-xvfb Jul 26 06:26:07 at leat with oe-core Jul 26 06:26:11 least* Jul 26 06:26:31 yeah, i tried adding xserver-xorg-xvfb to my local.conf Jul 26 06:26:57 adding in what sense? Jul 26 06:27:02 it should build by default, no? Jul 26 06:27:11 | * opkg_install_cmd: Cannot install package xserver-xorg-xvfb. Jul 26 06:27:36 that is the error i got Jul 26 06:28:22 i don't think so, the original image didn't ahve any x related stuff... Jul 26 06:28:34 what image are you building? Jul 26 06:28:50 is it custom or some-premade? Jul 26 06:29:13 the image is tidsk-server-rootfs-image.bb Jul 26 06:29:17 sorry, I am afk for 20 minutes Jul 26 06:29:21 should i paste here the content? (17 lines) Jul 26 06:29:23 ok, that I do not know Jul 26 06:29:28 but if I use the default images Jul 26 06:29:30 they work ok. Jul 26 06:29:40 compare with the default ones Jul 26 06:29:55 ifik this is the only image that is supported in keystone II hw... Jul 26 06:30:26 ok, thanks Jul 26 07:26:50 rburton: the cache stuff is calling for troubles Jul 26 07:26:58 I was just debugging an issue because of that for hours. Jul 26 07:27:05 once cache removed, it works. Jul 26 07:27:44 rburton: was getting this continuously: http://paste.kde.org/~lpapp/p0bec71e5/ Jul 26 07:28:03 by cache, I mean everything except the conf folder. Jul 26 07:36:15 kergoth: hey? Jul 26 07:39:19 http://paste.kde.org/~lpapp/p67427bfb/ Jul 26 07:39:19 another libexec arch bug? Jul 26 07:40:03 find /usr/local/arm-2009q1/ -name libexec Jul 26 07:40:04 /usr/local/arm-2009q1/libexec Jul 26 07:40:12 it is looking into the wrong directory again. Jul 26 07:50:46 rburton: oh, and we debugged that python stuff last time as well with -e for hours Jul 26 07:50:54 that is exactly the reason why I prefer to clean cache. Jul 26 07:50:57 there are no such issues then. Jul 26 07:54:21 rburton: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4922 Jul 26 07:54:22 Bug 4922: normal, Undecided, ---, richard.purdie, NEW , There is no clean option for bitbake or a separate util Jul 26 07:59:09 kergoth: sgw_:https://bugzilla.yoctoproject.org/show_bug.cgi?id=4922 Jul 26 07:59:10 Bug 4922: normal, Undecided, ---, richard.purdie, NEW , There is no clean option for bitbake or a separate util Jul 26 07:59:12 kergoth: sgw_:https://bugzilla.yoctoproject.org/show_bug.cgi?id=4923 * Jul 26 07:59:13 Bug 4923: normal, Undecided, ---, bogdan.a.marinescu, NEW , Cross-compilation issue with libexec when building for 32 bit host on arch 64. Jul 26 08:00:42 morning all Jul 26 08:01:42 hi Jul 26 08:08:55 what is prefix usually in a bb recipe? Jul 26 08:08:57 I mean where is it set? Jul 26 08:09:08 I see it used in a meta-sourcery bb file, but it is not set right in there. Jul 26 08:09:37 and I do not find it set anywhere inside meta-sourcery. Jul 26 08:12:05 good morning Jul 26 08:18:27 lpapp: default prefix is set in bitbake.conf, or your distro can override that Jul 26 08:18:50 it is set to /usr Jul 26 08:18:52 not sure that is correct for the cross-toolchain, really. Jul 26 08:18:56 perhaps I am missing the sysroot Jul 26 08:20:15 distro = layer, I believe Jul 26 08:20:25 as it is probably not specific to a distro Jul 26 08:20:31 as layers are not specific to distros Jul 26 08:26:26 rburton: shouldn't the meta-sourcery layer set the prefix to the cross-toolchain? Jul 26 08:26:37 rburton: or is that the prefix for the installation? Jul 26 08:26:40 I am slightly confused now. Jul 26 08:46:07 * lpapp is considering to open a bugreport about making shm optional Jul 26 08:46:14 it has been causing so much issues for several hours now. Jul 26 08:46:19 and it is very hard to get it right. Jul 26 08:46:29 er, we can't do that Jul 26 08:46:35 python multiprocessing requires it Jul 26 08:46:50 bluelightning: then you should not use such python instructions. Jul 26 08:46:57 if any instruction needs that, that sucks huge balls. Jul 26 08:47:03 that means, the language is fundamentally broken. Jul 26 08:47:08 because it gives no choice for IPC to you. Jul 26 08:47:25 but I am fairly certain it is not the case. Jul 26 08:47:42 python multiprocessing is a well-accepted and widely used concurrency tool Jul 26 08:48:05 which does not work apparently right ... Jul 26 08:48:15 and got no help for several hours on #archlinux, #debian, #yocto Jul 26 08:48:19 how to get it fed properly. Jul 26 08:48:23 I tried everything now I had ideas. Jul 26 08:48:40 so if it is this hassle, and so hard to get help, I would not consider it acceptable for everyone. Jul 26 08:48:47 which brings back to optional. Jul 26 08:49:08 pretty much no programs need that in my debian wheezy. Jul 26 08:49:12 otherwise they would be broken. Jul 26 08:49:16 bitbake is the first one. Jul 26 08:49:25 so life can work without it. Jul 26 08:49:34 well, we cannot, sorry Jul 26 08:49:46 yes, you can. Jul 26 08:49:49 I don't see why it should be so hard to ensure /dev/shm exists and has the correct permissions Jul 26 08:49:55 it only means a different backend. Jul 26 08:50:08 bluelightning: then why have you not spoken up for about a day? Jul 26 08:50:13 the issue has been discussed here several times. Jul 26 08:50:17 anyway, I am filing a bugreport. Jul 26 08:50:29 we have had several different concurrency mechanisms in bitbake over the years, and this one is the one that functions most efficiently and effectively Jul 26 08:50:38 for _you_ Jul 26 08:50:42 but not for many others users Jul 26 08:50:49 for the majority of users Jul 26 08:50:53 so please do not demand non-functional stuff for users. Jul 26 08:51:05 yeah, whatever. Jul 26 08:51:22 bugtracker does not only exist for your top priority bugs Jul 26 08:51:37 you assume that your experience is mirrored by a large number of others; I can assure you that in my experience helping users it is not Jul 26 08:51:53 oh, so your perception is right? Jul 26 08:51:57 but others' are not Jul 26 08:52:00 nice joke. Jul 26 08:52:10 many users who tried to help me (pro users, that is), could not help. Jul 26 08:52:11 lpapp: all you need is a tmpfs in the right place. Jul 26 08:52:15 my perception is based upon years of experience helping users to use the system Jul 26 08:52:46 yeah, so let us get the next users with the very same issues who are forced for silly debian chroot to suck. Jul 26 08:52:56 and go away from the project because it is not working. Jul 26 08:53:03 that will be so beneficial for Yocto Jul 26 08:54:00 lpapp: You are the first person who has ever complained that bitbake should not be using shm (and as a bitbake maintainer, I'd likely have seen such complaints) Jul 26 08:54:14 lpapp: if SHM is broken in your chroot, you'll have great trouble running a lot of software. fix your chroot and bitbake will work. Jul 26 08:56:09 RP: you are free to help me to fix it. Jul 26 08:56:17 I just do not have yet another day trying to fix it, honestly. Jul 26 08:56:31 and I am very close to stepping away because pretty much there is no existing Yocto setup which actually works Jul 26 08:56:40 I have been trying to make it work for a week in full time. Jul 26 08:56:52 lpapp: you've tried 1) an unsupported distro and 2) a broken chroot Jul 26 08:57:02 lpapp: *everyone else* in here is clearly using it fine Jul 26 08:57:15 RP: and what you have seen does not mean there are no more. Jul 26 08:57:21 https://bugzilla.yoctoproject.org/show_bug.cgi?id=4925 Jul 26 08:57:22 Bug 4925: normal, Undecided, ---, richard.purdie, NEW , Add an alternative backend for IPC communication Jul 26 08:57:22 lpapp: as you're running arch, try systemd-nspawn Jul 26 08:57:40 it is totally irrelevant to systemd-nspawan Jul 26 08:57:45 nspawn* Jul 26 08:58:05 rburton: no software is broken in my chroot just as I wrote. Jul 26 08:58:15 lpapp: anything that uses SHM will be broken Jul 26 08:58:17 the ones I actually use Jul 26 08:58:28 rburton: please do not come with theoretical issues Jul 26 08:58:32 we live in a practical world. Jul 26 08:58:37 where we need to solve problems. Jul 26 08:58:41 lpapp: listen for a minute. your problem is that the chroot isn't correctly configured - specifically your /dev/shm is broken. systemd-nspawn will effectivly boot the guest and in that process, init /dev/shm Jul 26 08:59:20 that's the point, the joy, and reason for systemd-nspawn to live Jul 26 08:59:35 chroots are *known* to have all sorts of fun problems as they don't actually boot Jul 26 08:59:54 I am not sure how to put it clearly, Jul 26 09:00:18 chroot *should* just work with proper bind mounts which I think I kinda have. Jul 26 09:00:33 nspawn *would* probably have another issues on its own Jul 26 09:00:41 you clearly don't have the right mounts if the permissions are wrong Jul 26 09:00:52 not to mention, I have a *lot* more experience with chroot. Jul 26 09:01:36 it is "fun" to see how people argue against solution proposals, but they do not provide anything better. Jul 26 09:02:22 lpapp: you asked for help, we're giving you advice, if you ignore it then you're on your own Jul 26 09:02:34 i've proposed 1) let us help you fix your mounts or 2) try systemd-nspawn Jul 26 09:02:41 but now i'm going to have a run Jul 26 09:02:44 rburton: 1) sorry, where? Jul 26 09:03:02 2) Dropping what you have instead of fixing it is *not* a proposal. Jul 26 09:03:08 it is a totally valid use case to use chroot for such things. Jul 26 09:04:02 so, if you cannot help fixing the chroot stuff, please just implement an alternative backend when you get there. Jul 26 09:18:32 bluelightning: what advice have you provided for fixing the shm mount? Jul 26 09:18:39 and its writability. Jul 26 09:18:50 I just went through the log, but I have not found anything. Jul 26 09:20:01 lpapp: make sure it's mounted and you have write permissions there? Jul 26 09:23:00 bluelightning: oh, really? Jul 26 09:23:03 lpapp: how did you mount it? Jul 26 09:23:05 I would not have thought that. Jul 26 09:23:11 bluelightning: the question is _how_. Jul 26 09:23:17 we all know what the end result should be. Jul 26 09:23:25 ndec: check the bugreport. Jul 26 09:25:37 lpapp: it's not really up to us how you set up your chroot environment Jul 26 09:25:50 lpapp: ok... can you tell me again which #BUG it is? Jul 26 09:25:59 it's lost in the huge irc backlog ;-) Jul 26 09:26:21 ndec: 09:55 < yocti> Bug 4925: normal, Undecided, ---, richard.purdie, NEW , Add an alternative backend for IPC communication Jul 26 09:26:22 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=4925 normal, Undecided, ---, richard.purdie, NEW , Add an alternative backend for IPC communication Jul 26 09:26:42 bluelightning: oh, it is not really up to make users' life easier? Jul 26 09:26:46 to you* Jul 26 09:26:54 that is a very disappointing mission statement. Jul 26 09:27:33 lpapp: you don't seem to mount /run/shm... Jul 26 09:27:38 or the bug report is wrong. Jul 26 09:27:52 ndec: /run is mounted. Jul 26 09:28:04 lpapp: /run is not /run/shm Jul 26 09:28:05 what's not what i said . Jul 26 09:28:06 it is Jul 26 09:28:13 but even then, I tried this: mount --bind /dev/shm /media/wheezy/run/shm Jul 26 09:28:23 there is no point in mounting recursively, really. Jul 26 09:28:29 none on /run/shm type tmpfs (rw,nosuid,nodev) Jul 26 09:28:31 lpapp: I'm afraid there is Jul 26 09:28:48 and to be monone on /run type tmpfs (rw,noexec,nosuid,size=10%,mode=0755) Jul 26 09:28:48 none on /run/lock type tmpfs (rw,noexec,nosuid,nodev,size=5242880) Jul 26 09:28:48 none on /run/shm type tmpfs (rw,nosuid,nodev) Jul 26 09:28:48 re complete Jul 26 09:28:58 oops.. to be more 'complete' that was. Jul 26 09:29:01 why that will not work is simply because it is not bind mount. Jul 26 09:29:10 see my command above please. Jul 26 09:29:21 that's from a working LXC container, where I can build OE. Jul 26 09:29:50 the bugreport is not meant to be a chroot manual though Jul 26 09:30:02 it is meant to be a feature extension for a better future for people having such issues Jul 26 09:30:17 so I would not like to hijack it into chroot bugfixing. Jul 26 09:30:29 that is why I did not provide all the details in there, just one of those. Jul 26 09:31:49 added this information though Jul 26 09:32:21 ndec: and it is 755 after that bind mount Jul 26 09:32:23 even if someone one day will accept to implement a new IPC .. which i doubt, that won't happen today. so you need to fix your chroot issue, should you want to make a build at some point. Jul 26 09:32:25 and I cannot change that Jul 26 09:32:56 I would not be so sure about that. Jul 26 09:33:01 so, i would agree 'more' on asking yocto to provide a 'manual' to setup a chroot. that seems more reasonnable to me. Jul 26 09:33:04 but yes, obviously, it is a long term plan. Jul 26 09:33:43 you cannot provide manual for each chroot/spawn host / guest combination ... Jul 26 09:33:47 you would go haywire ... Jul 26 09:34:20 so to me, that seems less reasonable. :) Jul 26 09:35:36 bbiab Jul 26 09:43:04 not even Ubuntu 12.10 is supported. :( Jul 26 09:43:05 WARNING: Host distribution "Ubuntu 12.10" has not been validated with this version of the build system; you may possibly experience unexpected failures. It is recommended that you use a tested distribution. Jul 26 09:43:54 lpapp: with which version now? Jul 26 09:45:26 Request account Jul 26 09:45:27 Your account request has successfully been sent and is now pending review. A confirmation email has been sent to your e-mail address. Jul 26 09:45:32 I thought I could help with the wiki Jul 26 09:48:00 even danny seems to have 12.10 support, at least from git. Jul 26 09:59:17 apparently, it is not simply a fire and help us Jul 26 09:59:35 ndec: as dany a Jul 26 09:59:43 as danny and dylan are fully broken for cross compilation Jul 26 09:59:48 our best bet is denzil Jul 26 09:59:56 which was not fully broken Jul 26 10:00:01 the regression was not yet introduced in there. Jul 26 10:00:09 and since we do not have shm alternative Jul 26 10:00:13 and since I do not know how to make chroot work Jul 26 10:00:25 I got an access to an ubuntu machine over ssh. Jul 26 10:00:49 lpapp: sorry but it's completely incorrect to say "danny and dylan are fully broken for cross compilation" Jul 26 10:01:08 oh, really, so I am not having any issues with it then? Jul 26 10:01:22 I just imagine them? Jul 26 10:01:32 no, you imply that it is not capable of cross-compilation; the fact of the matter is many, people use those versions daily to cross-compile Jul 26 10:01:32 alongsidfe other people who can reproduce those issues? Jul 26 10:01:58 I am not referring to the "many people doing cross-compilation" Jul 26 10:02:00 you've had problems specifically with external toolchains, that doesn't mean you can't cross-compile Jul 26 10:02:02 let us not play word games. Jul 26 10:02:07 I am clearly referring for my scenario. Jul 26 10:02:11 to* Jul 26 10:02:18 yes, it means Jul 26 10:02:23 I also had problems with internal toolchains Jul 26 10:02:27 I even wrote them here. Jul 26 10:02:35 for me, there is no any setup where Yocto would work so far. Jul 26 10:02:38 with cross-compilation. Jul 26 10:04:29 sorry for putting it this way, but Yocto is immature for me at this point. Jul 26 10:04:34 and for those who can reproduce the issues. Jul 26 10:04:41 hopefully, this will improve over time. Jul 26 10:05:37 I'll make it clear as I have done so before, you make things harder for yourself by using host setups that aren't well-tested Jul 26 10:05:55 before you say anything I know you have had other problems Jul 26 10:06:15 but at least half of the major problems you have had have been due to the host environment you have chosen Jul 26 10:06:23 huh, not? Jul 26 10:06:36 actually, there has not been any arch specific issue so far that I can recall. Jul 26 10:06:55 not in master HEAD that is. Jul 26 10:07:34 but feel free to back your statement about this as it is unclear for me, the arch user.s Jul 26 10:07:37 user.* Jul 26 10:08:23 could you please show me _any_ issue that was arch specific? Jul 26 10:08:54 how about the issue you had with host gcc 4.8? I'm still unclear on how you got that given that the patch is already in dylan for that one Jul 26 10:09:12 I did not have any of that? Jul 26 10:09:17 since I am not using 4.8? Jul 26 10:09:20 we are using gcc 4.3.3 ? Jul 26 10:09:26 what CS ships ? Jul 26 10:10:00 you are confused between host and target gcc Jul 26 10:10:02 perhaps you are confusing me with net147? Jul 26 10:10:10 ndec: no, not at all Jul 26 10:10:15 yes. you are. Jul 26 10:10:22 ndec: host toolchain for building for the target *is* from code sourcery Jul 26 10:10:36 it would work even if there was no any toolchain installed on my arch for native x86 builds. Jul 26 10:10:36 bluelightning told you about host gcc 4.8, and you answer you use gcc 4.3.3, which is the target gcc. Jul 26 10:10:41 no Jul 26 10:10:42 lpapp: I'm referring to when you switched to the internal toolchain Jul 26 10:10:45 that is where you are wrong. Jul 26 10:10:59 4.3.3 is *explicitly* not the target gcc Jul 26 10:11:08 it is the x86 ELF 32 binary for the *host*. Jul 26 10:11:12 lpapp: and no matter what, for building native tools you *are* using your native gcc 4.8 Jul 26 10:11:16 you seem to not understand how this works. Jul 26 10:11:17 yes, it is... Jul 26 10:11:28 well, let me have some doubts about that... Jul 26 10:11:47 bluelightning: internal toolchain has never been a plan to be used. Jul 26 10:11:55 bluelightning: as I stated clearly, it is a complete no go Jul 26 10:11:59 sigh Jul 26 10:12:04 according to everyone here. Jul 26 10:12:21 I made a test for out of the curiosity, but I could not care less about it. Jul 26 10:13:11 so again, what issue can present for arch for the intended goal? Jul 26 10:13:17 (to get back on track) Jul 26 10:13:29 mind pasting a bugreport or irc note? Jul 26 10:13:33 or even email thread. Jul 26 10:13:40 * ndec lunch... Jul 26 10:14:12 lpapp: I was including your recent attempts to use a debian chroot without completely setting it up Jul 26 10:14:57 bluelightning: that is also not an intentional final goal. Jul 26 10:15:07 the final goal is to get 4.3.3 from CS and Arch 64 bit host working. Jul 26 10:15:14 I do not see any arch specific issue for that. Jul 26 10:15:28 and I do not think the chroot is arch specific issue either Jul 26 10:15:36 I would have the same trouble on other "supported" hosts, as well. Jul 26 10:15:55 I just do not see what arch specific issue happened in here for arm2009q1 Jul 26 10:16:00 perhaps, you are right, I just need to understand. Jul 26 10:16:15 to me, all the issues look generic. Jul 26 10:18:18 my original point was, cross-compilation *does* work Jul 26 10:18:24 if it did not nobody would use our system Jul 26 10:18:32 and many successfully do Jul 26 10:19:00 we know there is a problem with external toolchain support out of the box with recent versions Jul 26 10:19:11 and there are folks working on that problem Jul 26 10:20:01 in the mean time, while I'm in here arguing with you I'm not getting any actual work done Jul 26 10:21:27 actually CS cross-compilation does not work Jul 26 10:21:33 and everyone could reproduce the issue. Jul 26 10:21:45 not with oe-core which belongs to Yocto. Jul 26 10:22:11 but I had more problems than that, correct. Jul 26 10:22:16 none of it is Arch specific though. Jul 26 10:22:19 those are general issues. Jul 26 10:22:48 bluelightning: the problem is that you should not argue. Jul 26 10:23:18 you claim me being wrong, even though the bugreports are accepted by the decision makers, so probably not, and then you wonder if I try to clarify my statement in more details. Jul 26 10:23:52 when someone is potentially misleading other people about the state of our project, sure I'll argue Jul 26 10:24:09 facts are speaking for themselves. Jul 26 10:24:12 no need to "mislead". Jul 26 10:24:51 and that is the impression from the comments on my blog post as well. Jul 26 10:25:01 it is not just me thinking that Yocto is not yet mature as it is. Jul 26 10:25:07 for embeddded cross-compilation. Jul 26 10:25:21 it is not just my opinion Jul 26 10:25:39 and it is possibly not just me filing the bugreports, and spending a lot of time with improving things. Jul 26 10:29:55 amen Jul 26 10:30:37 just in case: https://bugzilla.yoctoproject.org/show_bug.cgi?id=4927 Jul 26 10:30:38 Bug 4927: normal, Undecided, ---, saul.wold, NEW , Make Archlinux a supported host distribution Jul 26 10:31:06 lpapp: Remember that the people trying to help you *are* some of the decision makers on this project. Filing bug reports is good, I totally encourage that however it doesn't mean that they are verified as an issue or that people can find the time/resources to work on fixing them. I agree in an ideal world we should however the world is imperfect Jul 26 10:31:37 RP: they were verified as issues yesterday. Jul 26 10:32:27 RP: people were spending a day with one of them to be fixed. Jul 26 10:32:37 it is just that critical... Jul 26 10:34:04 currently 4923 is sitting on my as a blocker for arch Jul 26 10:34:12 otherwise I would not need to use Ubuntu, or even Debian. Jul 26 10:40:48 Welcome to the Yocto Project | Learn more: http://www.yoctoproject.org | Join the community: http://www.yoctoproject.org/community | Yocto 1.4 (dylan) Released! http://www.yoctoproject.org/download | Channel logs available at https://www.yoctoproject.org/irc/ Jul 26 10:43:34 RP: thanks Jul 26 10:43:43 I requested this a few days ago to be compliant with the freenode rules. Jul 26 10:43:52 nice to see it happening. Jul 26 10:44:24 lpapp: the delay was because he's on holiday and he's the only one with the ability to change it Jul 26 10:44:49 bluelightning: the log could have been blocked in the meantime. Jul 26 10:44:55 bluelightning: but it is solved now anyway Jul 26 10:46:10 lpapp: I'll point you to the freenode connect message which clearly states "you may wish to keep a notice in the topic" not "you must" Jul 26 10:46:22 lpapp: not that it's not a good idea, but let's be clear about what's stated Jul 26 10:49:53 bluelightning: you might wanna contact #freenode then. Jul 26 10:50:29 I have not seen a channel yet the last 10+ years who have not followed this btw. Jul 26 10:51:05 it is not even ethical to publish private information about people without their agreement. Jul 26 10:51:24 this is not private information Jul 26 10:52:26 regardless, the link is in the topic now Jul 26 10:52:37 right, and we have a pointer on our IRC page on the website Jul 26 10:52:40 If you're publishing logs on an ongoing basis, your channel topic should reflect that fact. Be sure to provide a way for users to make comments without logging, Jul 26 10:52:46 http://freenode.net/channel_guidelines.shtml Jul 26 10:52:48 "should" Jul 26 10:52:56 "Be sure" Jul 26 10:52:59 etc Jul 26 10:53:34 RP: yes, thanks. Jul 26 11:10:25 just FYI there is another log service at http://logs.nslu2-linux.org/livelogs/yocto/ Jul 26 11:10:42 this covers #oe as well Jul 26 11:11:30 ant_work: good catch Jul 26 11:11:34 let me raise the issue there. Jul 26 11:17:43 * Topic for #mtd is: fish Jul 26 11:17:43 * Topic for #mtd set by ChanServ!services@services.oftc.net at Thu Mar 21 19:21:28 2013 Jul 26 11:18:01 I don't dare bother them ;) Jul 26 11:18:55 heh Jul 26 11:18:57 (is not on freenode) Jul 26 11:31:15 right, so tmp does not contain the packagers per layer... Jul 26 11:31:42 that makes it very hard to verify the build results. Jul 26 11:34:08 lpapp: long long ago there was a wiki page like that Jul 26 11:34:11 http://www.openembedded.org/wiki/OEandYourDistro Jul 26 11:34:39 but it has happened that most tools are now built as -native packages Jul 26 11:35:57 not sure how that is related to my comment, Jul 26 11:36:06 I would like to verify the layers one by one. Jul 26 11:36:10 is about your generic Arch stuff Jul 26 11:36:23 ? Jul 26 11:36:27 I am more confused now. :) Jul 26 11:36:41 take the time to open the link I posted ;) Jul 26 11:37:06 I did, but it is actually fully outdated. Jul 26 11:37:11 so did not bother to spend my time with it. Jul 26 11:37:25 sure, any similar page would be inesorably out of date Jul 26 11:38:47 or is Yocto only supposed to build a distro image? Jul 26 11:38:54 where can I find it? Jul 26 11:39:22 the packages are split per ARCH Jul 26 11:39:34 not per layer Jul 26 11:39:47 those are not exclusive ... Jul 26 11:40:28 -> /tmp/deploy seems to be the right stuff. Jul 26 11:40:38 that's only for images/bootloaders Jul 26 11:40:53 the packages are i.e. under /ipk Jul 26 12:32:27 * wmat gets more coffee :/ Jul 26 13:11:47 Hi, I'm having trouble with imx53 (freescale) and having a /dev/fb0 Jul 26 13:19:25 witch recipe contains python libxml2 module? "python-lxml" don't work for me. I can't cross compile mesa because it requires it. Jul 26 13:22:36 mike23434: hmm, our mesa recipes in OE-Core don't need python-lxml to build AFAIK Jul 26 13:24:33 I'm not using OE-Core mesa recipes, I want to cross compile upstream mesa+etnaviv driver (vivante graphics in imx6) Jul 26 13:25:37 mike23434: ah ok, so it is extra functionality you're enabling that needs python libxml2 bindings? Jul 26 13:28:13 glapi/gen regires libxml2, libxml2-python is mesa depency from january 2013 Jul 26 13:32:20 mike23434: hmm, looks like libxml2-python and lxml are two different things, I guess that explains why python-lxml doesn't work Jul 26 13:32:55 mike23434: I think you may have to write a new recipe for that, but presumably you could use the python-lxml recipe as a starting point Jul 26 13:36:09 great :) how do you build mesa witchout it? Jul 26 13:38:07 is it possible to get an image generated rather many small stuff? Jul 26 13:38:36 lpapp: what is a 'small stuff'? Jul 26 13:38:52 package Jul 26 13:39:09 sorry, I got off for two hours Jul 26 13:39:14 we had a barbacue party. :-P Jul 26 13:39:17 the image is generated at the end of the build, when all packages are built. Jul 26 13:39:48 ok, so there are many small packages _and_ also the image? Jul 26 13:39:52 yep. Jul 26 13:39:59 fair enough Jul 26 13:40:04 in tmp/deploy/images Jul 26 13:40:31 you have to 'bitbake' an image, of course. Jul 26 13:40:58 image are .bb files too, which has a different 'task set', and include a do_rootfs() task. Jul 26 13:41:16 core-image-minimal Jul 26 13:41:34 that's one of them. yes. Jul 26 13:42:16 bluelightning: can i put it to some common place that nobody has to do it again after i create new recipe? Jul 26 13:45:27 is the "tmp" layout documented somewhere? Jul 26 13:46:40 mike23434: certainly, it would be great if you could add it into the meta-oe layer and send a patch to openembedded-devel@openembedded.org that does that Jul 26 13:46:50 lpapp: http://www.yoctoproject.org/docs/current/poky-ref-manual/poky-ref-manual.html#structure-build Jul 26 14:17:28 ndec: I do not find u-boot.bin inside the /tmp folder. How can I debug it why not? Jul 26 14:17:33 run bitbake on that particular package only? Jul 26 14:17:53 lpapp: does your machine specify that it needs uboot? Jul 26 14:18:31 ndec: ? Jul 26 14:18:48 shouldn't all the recipes be built by default? Jul 26 14:18:50 bitbake only builds what it is asked to build. Jul 26 14:19:00 define 'all'? Jul 26 14:19:47 all means all Jul 26 14:19:50 cannot explain more Jul 26 14:19:57 all the .bb stuff in every layer Jul 26 14:20:03 that belongs to a particular image. Jul 26 14:20:11 I thought u-boot would be included in core-image-minimal? Jul 26 14:26:11 lpapp: u-boot is a machine specific param. some machine don't need it. Jul 26 14:26:33 lpapp: your machine config should do EXTRA_IMAGEDEPENDS += "u-boot" Jul 26 14:27:07 lpapp: this is what meta-yocto/conf/machine/* do Jul 26 14:27:43 bluelightning: also x-load, I believe. Jul 26 14:28:08 lpapp: in the case of beagleboard, yes; and if that's valid for your board, that too Jul 26 14:28:13 probably MACHINE_ESSENTIAL_EXTRA_RDEPENDS Jul 26 14:28:36 ant_work: no, EXTRA_IMAGEDEPENDS because it's not to be installed in the image, just built alongside it Jul 26 14:28:39 the policies are in the manual Jul 26 14:29:13 sorry, I ssaw uEnv.txt is installed like this Jul 26 14:29:24 I meant target part Jul 26 14:29:48 anyway it's all in the FM Jul 26 14:52:49 is it enough to just rebuild? Jul 26 14:52:57 after uncommenting the EXTRA_IMAGEDEPENDS line? Jul 26 14:53:01 I mean without deleting anything. Jul 26 14:53:06 will I get the u-boot.bin stuff? Jul 26 15:03:42 bluelightning: ndec ^ Jul 26 15:04:17 i never delete everything Jul 26 15:06:25 ERROR: Nothing PROVIDES 'u-boot' Jul 26 15:06:25 ERROR: u-boot was skipped: because UBOOT_MACHINE is not set Jul 26 15:06:26 ERROR: u-boot was skipped: because UBOOT_MACHINE is not set Jul 26 15:06:26 ERROR: u-boot was skipped: because UBOOT_MACHINE is not set Jul 26 15:06:26 ERROR: u-boot was skipped: because UBOOT_MACHINE is not set Jul 26 15:06:33 hmm, apparently, I would need to set that, too. Jul 26 15:07:30 yep Jul 26 15:07:34 ERROR: Required build target 'core-image-minimal' has no buildable providers. Jul 26 15:07:34 Missing or unbuildable dependency chain was: ['core-image-minimal', 'u-boot'] Jul 26 15:08:42 bluelightning: http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta-yocto/conf has no machine ... Jul 26 15:09:39 I figured out the meta-sourcery issue Jul 26 15:09:42 it's a DISTRO layer. Jul 26 15:09:49 silly meta-sourcery is demanding an empty folder Jul 26 15:09:50 meta-yocto. Jul 26 15:09:53 which is not present for me as we use git Jul 26 15:09:58 and git does not track empty folders Jul 26 15:10:02 lpapp: my mistake, meta-yocto-bsp/conf/machine/* Jul 26 15:10:06 why on earth does CS ship an empty folder :D :D Jul 26 15:10:32 bluelightning: yeah, I just grepped in the root, and that helped to figure out meta-yocto-bsp Jul 26 15:10:56 lpapp: re your earlier question, no need to delete anything, no Jul 26 15:11:13 https://www.yoctoproject.org/docs/current/bsp-guide/bsp-guide.html Jul 26 15:11:22 it does not document UBOOT_MACHINE ... Jul 26 15:11:28 nor does the reference guide. Jul 26 15:12:39 lpapp: we can't really be expected to document every possible bootloader in the BSP guide Jul 26 15:12:47 looks like a bugreport Jul 26 15:12:53 bluelightning: the variable could be defined! Jul 26 15:14:52 https://bugzilla.yoctoproject.org/show_bug.cgi?id=4928 Jul 26 15:14:53 Bug 4928: normal, Undecided, ---, saul.wold, NEW , No documentation for UBOOT_MACHINE Jul 26 15:17:55 lpapp: btw, several developers here use Yocto on Archlinux just fine. and on Gentoo, Debian, SuSE and kubuntu... Jul 26 15:18:31 Sput: me and a few others are not those developers though. Jul 26 15:18:40 bluelightning: what should I put into UBOOT_MACHINE? Jul 26 15:20:30 lpapp: well, just mentioning it because in your blog you mentioned it doesn't work and resort to a chroot instead. but it's definitely possible... Jul 26 15:21:57 Sput: if it is definitely possible, let me know how. Jul 26 15:21:58 lpapp: looking at the recipe, it's whatever you would specify as the machine config on the u-boot make command line Jul 26 15:22:00 it just does not work for us. Jul 26 15:22:10 Sput: and people could reproduce issues following my instructions. Jul 26 15:22:56 weird. only issue I am aware of that happened here was that gcc 4.8 on the Arch host couldn't build gcc 4.7 on target, but that was fixed afaik Jul 26 15:23:11 and sometimes you need to install some -native packages because the host tools are too new (bibtex-native comes to mind) Jul 26 15:23:33 not bibtex, what was it called? Jul 26 15:24:05 Sput: lpapp initially was using denzil (or danny). which might not have the most recent fixes from master. Jul 26 15:24:07 docbook-native? Jul 26 15:24:44 it probably gets harder and harder to use Arch for stable OE releases, as time pass. Jul 26 15:24:50 Sput: as I wrote in my posts implicitly, we do not use 4.8 Jul 26 15:24:53 and we do not do native builds. Jul 26 15:25:00 that is kinda the crucial part of the post, really. :) Jul 26 15:25:02 well, that might be true (but that's probably also true for other distros) Jul 26 15:25:12 lpapp: install native packages so Yocto has proper versions Jul 26 15:25:13 lpapp: i am sorry.. but you are still confused by native vs host vs target... Jul 26 15:25:19 no reason not to do it to make things work :) Jul 26 15:25:39 Sput: what do you mean? Jul 26 15:25:42 Sput: sure... but it depends if you want to use OE, or fix it ;-) Jul 26 15:25:50 ndec: dude, I have been developing for embedded for years Jul 26 15:26:05 you presented yesterday the confusion about native vs. internal. Jul 26 15:26:17 -native packages go into the native sysroot. so if your host docbook or whatever it was is too new, you can still install the older version into the native sysroot, so Yocto can useit. Jul 26 15:26:20 i have no doubt. but you are confused about these terms in OE. Jul 26 15:26:25 nope Jul 26 15:26:33 usually people do native builds on arch Jul 26 15:26:38 i.e. for x86 or x86_64 Jul 26 15:26:41 not arm, whatsoever. Jul 26 15:26:49 and that is exactly what I meant. Jul 26 15:27:00 so for a very simple scenario it may work. Jul 26 15:27:13 but we are kinda ... building a next generation stuff with bleeding edge technology. Jul 26 15:27:49 so are we. which is why we use the newest poky, actually Jul 26 15:27:59 and have contemporary distros and not some LTS stuff :) Jul 26 15:28:26 Sput: that is the other thing, we do not use the newest poky. Jul 26 15:28:30 we already have a technology in place. Jul 26 15:28:40 as you may know, switching core components of the stack is not 2 pounds. Jul 26 15:29:08 it's not so much next generation bleeding edge then :) Jul 26 15:29:08 bluelightning: right, thanks. Jul 26 15:29:17 bluelightning: make foo -> foo goes to UBOOT_MACHINE Jul 26 15:29:28 bluelightning: so it is probably doing MAKE $UBOOT_MACHINE in the background then. Jul 26 15:29:32 make* Jul 26 15:29:41 Sput: it is. Jul 26 15:29:47 no one has done anything yet as such. Jul 26 15:29:55 and we are the number one in this industry as far as I can tell. Jul 26 15:29:58 lpapp: that's effectively what it does yes Jul 26 15:30:00 hope we can keep that position. :-) Jul 26 15:30:23 all my energy goes into that. Jul 26 15:31:35 well, dylan fixed lots of issues for us, so you might want to consider an upgrade nonetheless Jul 26 15:32:04 not for now, no. Jul 26 15:32:09 meta-sourcery is currently broken. Jul 26 15:32:14 and it has been blocking me. Jul 26 15:32:21 it requires empty folders for reading, etc. :) Jul 26 15:32:23 funny, really. Jul 26 15:32:32 it has to become mature before we will switch to it. Jul 26 15:32:56 what would be more worthy is the toolchain upgrade. Jul 26 15:33:00 to get C++11/C++14 features Jul 26 15:33:14 we also appreciated more or less proper systemd support Jul 26 15:33:37 bluelightning: do we need to specify the enty point and load address, too? Jul 26 15:33:51 entry* Jul 26 15:34:52 bluelightning: ah, you meant this, ../meta/recipes-bsp/u-boot/u-boot.inc:43: oe_runmake ${UBOOT_MACHINE} Jul 26 15:35:16 lpapp: I have limited experience with u-boot, but based on other machine configs, probably yes Jul 26 15:36:46 bluelightning: really strange. Jul 26 15:36:54 because it is not necessary for building u-boot separately. Jul 26 15:37:00 it is only necessary for things like openocd. Jul 26 15:37:05 or when you update it over tftp. Jul 26 15:37:20 perhaps it is possible to hard code the address into u-boot Jul 26 15:37:24 which then cannot be changed later. Jul 26 15:37:38 which might be just an optional feature if you otherwise plan to specify that separelty at flashing/updating time. Jul 26 15:37:57 not sure I'm afraid Jul 26 15:41:02 bluelightning: it is ok Jul 26 15:42:03 Sput: btw, the issues are not arch related. Jul 26 15:42:11 there are general immatureness. Jul 26 15:42:14 they* Jul 26 15:42:30 but since I am now involved in full-time with fixing it for myself. Jul 26 15:42:35 I think you go too far with accusations of immaturity Jul 26 15:42:38 It might be easier to move forward on this front. Jul 26 15:42:38 oh, yes, there are many issues (but many have been fixed in the past two poky releases, too), not disputing that Jul 26 15:42:53 I was just referring to your claim that Archlinux is the problem, which it isn't. Jul 26 15:42:59 they are the issues with poky master HEAD fwiw Jul 26 15:43:06 and meta-sourcery master Jul 26 15:43:38 Sput: the problem is that with archlinux, they do not support it. Jul 26 15:43:39 One thing I like to do when I need help from people who are familiar with a given project is use terms with strong negative connotations a lot, because people who feel insulted are much more likely to be cooperative and helpful. Jul 26 15:43:41 not even a single configuration. Jul 26 15:44:14 who cares about official support for any given distro? we're engineers, we can solve that Jul 26 15:44:22 Sput: it is all voluntary work if there are issues which is not a reliable solution for a company. Jul 26 15:44:28 for real Yocto issues, I've found the people in this channel always very helpful Jul 26 15:44:30 Sput: many companies including us, of course. Jul 26 15:44:39 it is not about engineers Jul 26 15:44:48 you think a lower layer than the business happens. Jul 26 15:44:50 lpapp: tbh, Archlinux is not a reliable solution for a company Jul 26 15:44:56 "fixing" yourself is a lot of cost. Jul 26 15:44:57 RHEL would be Jul 26 15:45:01 which a manager will not take. Jul 26 15:45:10 a manager will say (rightfully) to use a supported distribution. Jul 26 15:45:17 but that goes against the engineers' own wish. Jul 26 15:45:18 when I chose to use Gentoo at work, I did that knowing that I could not go to our IT and demand support Jul 26 15:45:33 archlinux is a reliable solution Jul 26 15:45:40 have done business for 6-7 years with it. Jul 26 15:45:41 but then I'm also not complaining if the tools we use require tinkering on my end Jul 26 15:46:16 again, it is not about your money Jul 26 15:46:18 you do not decide. Jul 26 15:46:24 the stakeholders decide. Jul 26 15:47:00 engineers wish. Jul 26 15:47:11 well, you use a rolling release distro with no enterprise support for professional purposes, and then go complaining that this distro isn't supported by a project like Yocto... doesn't sound too sane to me :) Jul 26 15:47:26 yet you can make it work, if you invest the time to make it work Jul 26 15:47:31 no no, that is untrue Jul 26 15:47:39 I am *definitely* not using Arch for enterprise. Jul 26 15:47:58 as discussed here the whole day, I was using debian, and since that did not work, I use Ubuntu 12.10 Jul 26 15:48:04 you are way beyond the facts. :) Jul 26 15:48:17 I would love to use Archlinux, but I cannot. Jul 26 15:48:44 because no one sells the argument the engineer like it, but upstream has no any support for it. Jul 26 15:48:50 buys* Jul 26 15:48:54 likes* Jul 26 15:48:59 ah well, I'm happily using Gentoo and Yocto does what it's supposed to do if you fix the occasional quirk, so I'm rather happy with it Jul 26 15:49:01 I would not buy it either. Jul 26 15:49:20 I worked with MeeGo before, I'm rather glad I can use Yocto now :) Jul 26 15:49:29 bluelightning: http://paste.kde.org/~lpapp/pab8e62ea/ Jul 26 15:49:32 some issue with my machine. Jul 26 15:50:17 MeeGo and Yocto ... Jul 26 15:50:20 apple and orange ... Jul 26 15:50:34 thankfully. Jul 26 15:50:38 I like oranges more. Jul 26 15:50:49 lpapp: the x-load recipe declares that it's only compatible with a set list of machines using COMPATIBLE_MACHINE Jul 26 15:50:54 Arlo N' Janis did that one something like 20+ year ago. Jul 26 15:51:17 Arlo: One is hard, smooth, and red. The other is softer, with a dimpled skin, and orange. Janis: What are you doing? Arlo: Comparing apples and oranges. Jul 26 15:52:55 16:45 < Sput> yet you can make it work, if you invest the time to make it work -> I do not live 100 hours a day Jul 26 15:53:08 Oh, there's your problem. Jul 26 15:53:10 if I am not allowed to work with unsupported stuff which is a reasonable decision to be fair, I cannot put anything more into it. Jul 26 15:53:23 I am already involved with tons of other FOSS stuff, and I have real life, too ... ;-) Jul 26 15:54:30 lpapp: don't we all Jul 26 15:54:31 and frankly, the lack of proper Qt5 bugs me a lot more than switching to ubuntu for now. Jul 26 15:54:51 bluelightning: yes Jul 26 15:55:18 I wonder if we really need x-load. Jul 26 15:55:21 I am afraid, we do. Jul 26 15:55:57 I might be wrong actually. Jul 26 15:56:22 if it is this stuff, we probably do not, http://en.wikipedia.org/wiki/Xload Jul 26 15:56:31 but I bet it is different. Jul 26 15:56:34 entirely dependent on how your machine boots Jul 26 15:57:28 eagle.s3.amazonaws.com/esc/Uboot-esc-chicago-2010.pdf Jul 26 15:57:35 based on this, u-boot requires x-load. Jul 26 15:57:46 page 2 -> boot up process. Jul 26 15:58:05 but it is using ROM Jul 26 16:00:36 if I understand correctly, x-load is usually used with nand flashes. Jul 26 16:00:38 written into that. Jul 26 16:00:43 but we use nor flash. Jul 26 16:01:22 x-load is completely deprecated. Jul 26 16:03:00 ndec: well, beagleboard seems to use it though. Jul 26 16:03:25 hmm. that's weird.. Jul 26 16:03:55 ../meta-yocto-bsp/conf/machine/mpc8315e-rdb.conf does not though. Jul 26 16:05:03 I personally just flashed the u-boot with openocd, so I did not need x-load Jul 26 16:05:16 and it worked, so I will drop that for now. Jul 26 16:05:24 but I would need to get a more thorough picture on the topic later. Jul 26 16:06:06 you don't need it, because it was probably already 'there' on the board. you can't boot with just uboot. Jul 26 16:06:54 you can. Jul 26 16:06:58 it was not on the board. Jul 26 16:10:10 ndec: spl is in the u-boot tree. Jul 26 16:10:18 yes. Jul 26 16:10:24 SPL is the replacement for x-load Jul 26 16:10:55 yes, it is coming with u-boot. Jul 26 16:13:12 who is the u-boot maintainer for oe-core? Jul 26 16:13:23 is s/he lurking around in here? Jul 26 16:28:41 bluelightning: ndec ^ Jul 26 16:28:52 don't know Jul 26 16:42:13 moin Jul 26 16:42:20 yo Jul 26 16:49:29 * mr_science smells a high-speed timing test on the horizon Jul 26 16:49:55 having sata link issues with ~10% of the motherboards... Jul 26 17:12:20 the sucky part is the lack of response from TI on the plethora of SATA problems posted by customers... Jul 26 17:13:19 kinda makes me never want to buy another TI part ever again... Jul 26 17:13:52 mr_science: have you tried e2e? Jul 26 17:13:58 usually, they are very helpful in there. Jul 26 17:14:05 mr_science: also, #linux-omap? Jul 26 17:14:28 been all over the TI e2e forums Jul 26 17:14:41 they tend to leave them unanswered Jul 26 17:15:03 mr_science: which board? Jul 26 17:15:31 816x/am389 family Jul 26 17:15:56 our board is based largely on the dm8168evm Jul 26 17:16:25 overal i am definitely *not* impressed with their support Jul 26 17:16:34 oh. i didn't know there was sata there Jul 26 17:18:31 everything seems to point to noise and/or timing issues Jul 26 17:19:08 like i said, it's about a 10% failure rate on boards coming from the manufacturer Jul 26 17:19:39 mr_science: can you show the forum url? Jul 26 17:20:14 and our little hardware test suite only tests that the RTC can save/increment the clock Jul 26 17:20:38 sata test uses the ddt filiesystem test Jul 26 17:21:03 perhaps I have been lucky with TI, but I had excellent customer support. Jul 26 17:21:17 except the fact they do not wanna support C++11 for the TI toolchain, but that is hardly support issue. Jul 26 17:21:28 lpapp: http://e2e.ti.com/support/dsp/davinci_digital_media_processors/f/717/t/178108.aspx Jul 26 17:21:45 that's the one i posted on, but there are tons of others... Jul 26 17:22:10 put "sata link" in the search box... Jul 26 17:23:04 haven't asked in #linux-omap yet, so i'll try that... Jul 26 17:24:53 mr_science: do not forget that it is holiday season btw. Jul 26 17:33:53 outside th US you mean? Jul 26 17:34:39 mr_science: yes Jul 26 17:34:45 there are many support guys in France for instance. Jul 26 17:37:06 Morning everybody! including x11 in DISTRO_FEATURES is giving me a grief. GTK+ is refusing to build. I'm on Dylan. What can I do? Jul 26 17:37:21 b1gtuna: what is the build error? Jul 26 17:38:05 lpapp: one sec i was just about to pastebinit Jul 26 17:38:08 lpapp: thanks Jul 26 17:39:44 lpapp: http://paste.ubuntu.com/5915599/ it's quite large Jul 26 17:40:17 lpapp: i tried cleanall on gtk+, still occuring as long as I have x11 in DISTRO_FEATURES Jul 26 17:40:38 b1gtuna: and can you confirm you do not have this, /home/ubuntu/build/tmp/sysroots/overo/usr/lib/libXinerama.la Jul 26 17:40:52 could be a missing dependency on xinerama Jul 26 17:41:30 lpapp: I have a debootstrap running to test the /usr configuration on ubuntu to see if it works there. Don't have an arch chroot handy, but i expect it's the path that's the issue, rather than the host distro. we shall see Jul 26 17:42:11 lpapp: ls: cannot access /home/ubuntu/build/tmp/sysroots/overo/usr/lib/libXinerama.la: No such file or directory Jul 26 17:42:18 lpapp: so nope it's not there.. =( Jul 26 17:42:58 b1gtuna: do you have /home/ubuntu/build/tmp/sysroots/overo/usr/lib/ ? Jul 26 17:44:10 lpapp: yes it contains a lot of .la, .so files Jul 26 17:44:39 b1gtuna: check the gtk recipe for a dependency on xinerama Jul 26 17:44:41 b1gtuna: ok, so it is probably a missing dependency Jul 26 17:44:56 is there a proper bitbake manual somewhere? Jul 26 17:45:06 kergoth lpapp - i see doing it now thx Jul 26 17:45:12 this comes up all the time when I look for one, but it is very short, and does not cover a lot of stuff: https://pixhawk.ethz.ch/_media/dev/oebb/bb_manual.pdf‎ Jul 26 17:46:17 RP: ^ Jul 26 17:46:55 openembedded.googlecode.com/files/usermanual.pdf -> perhaps this one? Jul 26 17:47:46 kergoth: right, I am trying to write a patch for the other issue now ... Jul 26 17:47:54 I just need a helpful bitbake manual. Jul 26 17:48:36 lpapp kergoth - no dependency on xinerama, will add it and try again Jul 26 17:49:44 the bitbake manual is in the middle of being rewritten Jul 26 17:50:02 http://docs.openembedded.org/bitbake/html/ is the old one Jul 26 17:50:23 but it mostly covers recipe syntax and bitbake command syntax, most everything else is oe/yocto, not bitbake Jul 26 17:51:17 see my last comment on 4923 Jul 26 17:51:23 we cannot do much on our side for now. Jul 26 17:51:40 we could switch away from git to some internal mirror, but meh. Jul 26 17:52:00 I think distributing an empty folder is wrong from CS. Jul 26 17:52:17 but since it cannot be fixed for 2013.05, it has to be solved somewhere. Jul 26 17:52:26 and the logical workaround place looks meta-sourcery to me. Jul 26 17:52:37 because that is the central place what everyone would probably use. Jul 26 17:52:49 I already said in comment #4 that i'd add a check for it Jul 26 17:52:52 and i will Jul 26 17:52:58 well, I can help with that. Jul 26 17:53:03 once I understand the bitbake stuff. Jul 26 17:53:06 I do have a day job, you realize. supporting people on irc is only part of it Jul 26 17:53:12 only so many hours in teh day Jul 26 17:53:19 fair enough Jul 26 17:53:36 to be honest, 4923 is higher priority for me. Jul 26 17:53:38 than 4921 Jul 26 17:53:45 2013.05 is just a toy project at home. Jul 26 17:53:53 the real issue is 2009q1 what we use at the company. Jul 26 17:54:24 * lpapp g2g Jul 26 17:55:33 lpapp can you please attach the run.do_install.8130 from your temp directory to 4923, I want to check some Jul 26 17:55:43 already left Jul 26 17:55:44 just missed him Jul 26 17:57:16 he's had a couple valid points, but in other cases his expectations are pretty out there Jul 26 17:57:19 * kergoth rolls eyes Jul 26 17:57:21 lol Jul 26 18:12:41 kergoth: adding xinerama to gtk+'s DEPENDS seems to have fixed. Is this a bug? Jul 26 18:13:12 sounds like it, do mention w hich releas eyou're using if you open an issue Jul 26 18:13:55 kergoth: i will, great thanks Jul 26 18:17:13 Have anyone seen do_populate_lic_setscene task failing in sstate_install with cp: will not create hard link `/OE/deploy/licenses/recipe' to directory `/OE/deploy/licenses/recipe' (same path) Jul 26 18:22:22 sgw_: 4923 already got a change which I can test next week. Jul 26 18:22:35 lpapp: Ok, I saw that. Jul 26 18:29:29 kergoth: should i post a patch or should i simply file through bugzilla? Jul 26 18:29:53 up to you Jul 26 18:31:59 kergoth: sweet ty Jul 26 18:35:19 kergoth: if you have some time, can you look over Qi.Chen's RO ROOTFS changes, I know they would be of interest to you. Jul 26 18:36:18 I haven't had time to read his reply on my thread even, neck deep in madness :) Jul 26 18:36:21 will do when i find a moment Jul 26 18:36:32 kergoth: thanks Jul 26 18:52:24 kergoth: have you seen my comment on 4921 Jul 26 19:02:40 b1gtuna: did building xinerama first fix it? Jul 26 19:03:00 * mr_science scrolling... Jul 26 19:03:09 mr_science: yes Jul 26 19:04:03 yup, just found it... Jul 26 19:04:51 kergoth: those are the patches i mentioned before Jul 26 19:05:21 couldn't remember his name, but Qi.Chen is correct Jul 26 20:13:18 Hey all, as you know the default Yocto root password is empty. I want to change this so that one exists, but I'm having some trouble tracking down how to do this. My image has shadow, but I haven't seen anything obvious looking at recipes-extended/shadow Jul 26 20:20:56 posborne: what rev are you using? Jul 26 20:22:29 I'm on Dylan Jul 26 20:25:15 I have a tentative patch (still testing it a bit) to improve the consistency of how NO32LIBS is handled in pseudo.inc. Jul 26 20:25:56 Basically, the proposed behavior is: If NO32LIBS is 1, we just don't try to do a 32-bit build, and we say so. If NO32LIBS is unset, we try to build 32-bit if and only if stubs-32.h exists. If NO32LIBS is 0, we check for stubs-32.h, and emit a warning if we don't find it. Jul 26 20:26:00 there should be no NO32LIBS Jul 26 20:26:10 it should just work automatically IMHO. Jul 26 20:26:34 And then the actual compilation is contingent on whether we think we want to try for it, and if it fails, we have a better diagnostic in view. Jul 26 20:28:32 The background here is that for the vast majority of 64-bit systems, there's no reason at all to build a 32-bit libpseudo, and requiring everyone to have a working multilib toolchain is ridiculous. Jul 26 20:29:07 The one case where 32-bit libpseudo is needed on 64-bit hosts is when there's a compelling need to run 32-bit binaries, and the one case where that tends to come up is prebuilt toolchains (like the Code Sourcery/Mentor Graphics ones). Jul 26 20:29:41 The original behavior was to try to build 32-bit if stubs-32.h existed, but this was a source of build failures and various problems in cases where there really wasn't any need to do this anyway. Jul 26 20:30:30 Problem is, when we adopted the NO32LIBS configuration thing, we never removed the check for stubs-32.h, so you could have a configuration which thought it needed 32-bit libpseudo, but silently failed to actually build one and didn't mention that it was missing something it thought it needed. Jul 26 20:32:06 Since a couple of echoes in the pseudo-native/pseudo-nativesdk output are cheap, and the confusions caused by problems with this have been expensive, I'm adding a little extra output, including a message warning the reader (if they happen to go looking, anyway) that only a 64-bit libpseudo is being built in the common case. Jul 26 20:32:17 Will send out a draft patch for review soonish. Jul 26 20:32:32 the toolchain option specifies what to build already, especially it is 32 bit, there is any doubt what it is. Jul 26 20:32:47 uname -m returns the host architecture Jul 26 20:33:10 it should be pretty clear that it is trying to build 32 bit on a 64 bit host if "uname -m" return x86_64, and the toolchain binary is 32 bit ELF. Jul 26 20:33:17 posborne: There was a patch for master recently to allow that, and it was discussed on the oe-core ML Jul 26 20:33:23 I do not see any reason why interaction would be necessary for it to work. Jul 26 20:33:41 this NO32LIBS feels like a hackaround, but not a real solution. Jul 26 20:34:17 posborne: for dylan I have no easy answer other than add some ROOTFS_POSTPROCESS_COMMAND to your image maybe that patches the passwd file Jul 26 20:34:27 The pool of programs which you *might* need to run, which could be 32-bit binaries, is extremely large. It's not restricted to the toolchain. Jul 26 20:34:39 Heck, nothing prevents a user from having a 64-bit gcc executable which calls a 32-bit cc1. Jul 26 20:35:02 yada-yada Jul 26 20:35:17 posborne: that's exactly what i so in the older bitbake world too Jul 26 20:35:23 file works for any important executables, which is in my case gcc only, that would need to be checked. Jul 26 20:35:32 s/so/do/ Jul 26 20:36:04 I vote for removing NO32LIBS altogether for my use case, at least, but I feel the potential for removal in certain other scenarios, too. Jul 26 20:36:15 i also made a pwgen native recipe and use it in my custom image function to generate the root password Jul 26 20:36:45 since it goes along with adding a normal user with a known password... Jul 26 20:40:16 posborne: let me know if you'd like to know any details (it's pretty straightforward) Jul 26 20:52:24 mr_science sgw_ Thanks, I'll look at the latest stuff. Before I got pulled away from my desk I was starting to look into ROOTFS_POSTPROCESS_COMMAND Jul 26 20:52:39 Has anyone done gdm + xfce integration? Can't shutdown as a user. Kicks me back into the login screen instead. Jul 26 20:52:52 Related, is there a good way to trace backward from a file in the sysroot to see which recipe(s) touch it? Jul 26 21:00:33 kergoth: have you made any progress on the arch chroot Jul 26 21:00:40 or were you able to reproduce that on ubuntu Jul 26 21:00:46 I need to leave soon. Jul 26 21:01:13 You mean 4919? Jul 26 21:02:13 I went and looked more closely at that because I'd been looking at the command line options. The huge pile of incompatible library directories isn't even remotely related to anything Yocto's doing except specifying "-m32" to a compiler that's not configured to know to look elsewhere for 32-bit libraries. Jul 26 21:02:19 posborne: much easier to link the file to a package in the runtime Jul 26 21:02:30 The only -L in there is into a bitbake library directory which is in fact the correct directory for it to specify. Jul 26 21:02:34 using opkg on the running system Jul 26 21:03:06 posborne: let me pastebin something... Jul 26 21:03:52 no, not 4919. Jul 26 21:07:40 mr_science: sure, whatever works Jul 26 21:08:23 this relates root password thing as opposed to tracing a file... Jul 26 21:08:43 mr_science: ah, gotcha Jul 26 21:08:59 http://paste2.org/pZp792G7 <= this is at the bottom of my image recipe, with some other custom stuff Jul 26 21:09:22 lemme thing about the other one for a sec... Jul 26 21:10:25 as i said, easy to go from "opkg search /usr/bin/foo" to a recipe that builds the package Jul 26 21:11:17 traceability from the sysroot is a bit different... Jul 26 21:12:24 posborne: if you tell me what the file is i might be able to answer, but i don't have a "query sysroot" answer to the bigger question atm Jul 26 21:14:31 unless it's a file from one your own in-house packages Jul 26 21:14:32 Sure, that is fair. In this case, I was wondering about /etc/shadow Jul 26 21:17:24 the recipe is also "shadow" Jul 26 21:17:34 in oe-core Jul 26 21:17:48 oe-core/meta/recipes-extended/shadow Jul 26 21:18:06 Right, initially looking at the recipe, it was hard to see that it actually generated the file. Jul 26 21:18:47 mr_science: thanks for the pastebin. building an image now to test Jul 26 21:22:08 posborne: recipes typically don't even have a function for compile or install unless they need to do something special or apply a workaround Jul 26 21:22:45 so looking there is a little "iffy" Jul 26 21:23:19 OTOH, sometimes you'll find a whole bunch of manual install stuff and file/path jiggering Jul 26 21:23:42 it all depends on the condition of upstream Jul 26 21:24:09 which is probably pretty obvious so i'll shutup now Jul 26 21:27:40 mr_science: haha, no problem. the help has been appreciated Jul 26 21:28:40 maybe i'm stilla little numb from my lovely meeting where i was the only linux guy... Jul 26 21:30:24 don't think they learned a thing, so i can't call it successful, at least from my perspective Jul 26 21:30:46 mr_science: I'm on a couple projects like that right now; nothing more fun telling people what to type in the terminal over the phone Jul 26 21:40:02 if that's all it was i'd never have mentioned it... Jul 26 21:40:14 well, maybe... Jul 26 21:45:25 posborne: feel free to yell at me after hours (ping nerdboy) if you have more questions Jul 26 21:45:53 since i have a pretty extensive set of custom_post_process stuff Jul 26 21:47:01 * mr_science goes bowling... **** ENDING LOGGING AT Sat Jul 27 02:59:58 2013