**** BEGIN LOGGING AT Wed Jan 29 02:59:58 2014 Jan 29 03:16:55 Hi Jan 29 03:16:57 have one doubt Jan 29 03:17:15 want to build a module for two hardware(two machine variable), will _.bb work? Jan 29 07:17:59 morning, europeans :) Jan 29 07:18:43 i sent two emails (description+patch) to poky@yoctoproject.org yesterday, but I cannot see it at https://lists.yoctoproject.org/pipermail/poky/2014-January/date.html . anyone with an idea why? Jan 29 07:18:50 i'm not subscribed to the list, btw Jan 29 07:27:59 ..and the mail was sent from jonas.eriksson@enea.com. i did a trial send first to an external address, so the mail configuration on my side seems alright :) Jan 29 07:52:06 hello, for my question, anyone? Jan 29 07:52:14 oopsie, wrong channel, sorry. Jan 29 07:59:05 good morning Jan 29 08:28:54 Hello, how can I fixe this Jan 29 08:28:56 gst-ffmpeg was skipped: because it has a restricted license not whitelisted in LICENSE_FLAGS_WHITELIST Jan 29 08:30:25 from poky-dylan/meta/recipes-multimedia/gst-ffmpeg-0.10.13 Jan 29 08:30:32 LICENSE = "GPLv2+ & LGPLv2+ & ( (GPLv2+ & LGPLv2.1+) | (GPLv3+ & LGPLv3+) )" Jan 29 08:33:15 does anyone used gst-ffmpeg ? Jan 29 08:42:05 /etc/init.d/rc: /etc/rcS.d/S37populate-volatile.sh: line 1: can't create /etc/volatile.cache.build: No space left on device Jan 29 08:42:13 has anyone got a clue for this? Jan 29 08:46:45 lpapp: maybe your HD is full? try df -h Jan 29 08:46:56 mks: which machine? Jan 29 08:49:45 mckoan : fsl imx6q Jan 29 08:49:56 mks: as I supposed Jan 29 08:51:07 mckoan: do I need to append a COMPATIBLE_MACHINE ? Jan 29 08:51:23 use meta-fsl-demos and take a look at fsl-image-test.bb Jan 29 08:52:42 ok thanks a lot Jan 29 09:09:42 mckoan: it obviously is full, but I am wonder how it can be fixed, and what is causing it. Jan 29 09:17:45 lpapp: you can delete something or use a larger HD Jan 29 09:18:43 lpapp: or maybe I'm misunderstanding what you are doing, please pastebin your log Jan 29 09:26:59 mckoan: delete something? Jan 29 09:27:07 it is already like that by the initscripts. :) Jan 29 09:27:14 partition is as big as before. Jan 29 09:35:44 so I guess I am interested in what that initscript is doing Jan 29 09:49:06 morning all Jan 29 09:51:04 bluelightning: good morning Jan 29 11:05:47 so does anyone know how this script is supposed to work? meta/recipes-core/initscripts/initscripts-1.0/populate-volatile.sh Jan 29 11:05:54 how much rootfs space would it require? Jan 29 11:06:11 why does it populate the whole disc on the first boot up? Jan 29 11:09:48 every boot, because it puts directories into locations that are tmpfs, so empty on every boot Jan 29 11:10:39 I am not sure I follow... Jan 29 11:10:58 it populates the root (/) to full. Jan 29 11:11:02 that is of course unacceptable. Jan 29 11:11:24 http://pastebin.kde.org/phevoeeoz Jan 29 11:11:30 I do not of course want that. :-) Jan 29 11:11:34 so how to fix the issue? Jan 29 11:11:54 can't create /etc/volatile.cache.build: No space left on device Jan 29 11:12:09 -> /etc is not tmpfs AFAICT Jan 29 11:13:14 test "$VOLATILE_ENABLE_CACHE" = yes && echo "$EXEC" >> /etc/volatile.cache.build Jan 29 11:14:20 we switched from RO to RW, so that may be the reason why it appears all of a sudden, but still, it should not behave like this IMHO. :-) Jan 29 11:15:13 or is it because we already have a full / before this script is trying to write? Jan 29 11:25:40 hmm, the core kernel is 1.9 MB on our side with some custom stuff? That does not look alright, does it? Jan 29 11:26:01 That seems very big for a limited embedded platform. I would have imagined it around 1-1.2 MB. Jan 29 11:28:20 my desktop kernel is 3.8 MB with the initramfs. Jan 29 11:31:10 very hard for people who don't know your use case or kernel config to comment on size Jan 29 11:31:51 well, it is poky. Jan 29 11:32:15 core-image-minimal Jan 29 11:32:43 but your kernel, right? Jan 29 11:33:15 well, 10K+ LOC maybe. Jan 29 11:33:19 that is negligible to the kernel size. Jan 29 11:33:21 and kernel tuning is obviously something you want to do if you care about the size, there's bound to be bits you can turn off. Jan 29 11:33:54 well, yes, but really, 1.9 MB sounds huge either way. Jan 29 11:34:39 so review your kernel config Jan 29 11:34:42 huh? the kernel size could vary drastically depending on feature set Jan 29 11:34:48 yeah Jan 29 11:35:00 there is no any "huh". Jan 29 11:35:04 1.9 MB is big, period. :) Jan 29 11:35:07 rburton: when could we expect ASSUME_PROVIDED = "pkgconfig" to be pushed? Jan 29 11:35:25 lpapp: its half the size of your desktop kernel, so it's not that big Jan 29 11:35:26 I would imagine /much/ less for a core-image-minimal. Jan 29 11:35:35 rburton: that is very big IMHO. Jan 29 11:35:37 lpapp: core-image-minimal shares the kernel with core-image-sato Jan 29 11:35:47 rburton: I used to have 1-1.2 MB or even less. Jan 29 11:35:52 so tune it then Jan 29 11:36:28 I imagine even core-image-minimal includes a lot of needless stuff. Jan 29 11:36:39 (for just booting a system up) Jan 29 11:36:39 its an example, so by definition yes Jan 29 11:37:50 so, what is the reason for /home/root? I still did not get it. Jan 29 11:37:52 Xz: you'll have to ask RP about that. he might be waiting on darren to review it Jan 29 11:37:54 I have not seen that anywhere. Jan 29 11:38:11 lpapp: so that all homes are in the same mount, i suspect. Jan 29 11:38:14 move it if it bothers you Jan 29 11:38:30 rburton: what is the point of that? Root has always been a super user. Jan 29 11:38:42 so it has not been available as such among the regular users for that reason. Jan 29 11:39:01 * danielki found is strange as well, and it clashes with having a separate partition for /home Jan 29 11:39:10 but you can set ROOT_HOME to move it Jan 29 11:39:16 I know. Jan 29 11:39:27 but what I do not know is the point of /home/root, hence asking. :-) Jan 29 11:39:55 IMHO, currently, most of the people will override that to /root, so why not have that as a default? Jan 29 11:41:10 btw, when I made that ROOT_HOME change, I had to manually delete the sstate for the recipes involved or it would continue to put the old stuff into generated RPMs -- took me a while to figure that one out Jan 29 11:42:00 "that ROOT_HOME change" means? Jan 29 11:42:13 Xz: I was hoping Darren would comment... Jan 29 11:44:20 lpapp: I changed it to /root for my images, but I had already done a build with the original setting -- normally Yocto is quite good at recognizing changes, and I even bumped PR, and ran bitbake -f -c clean on base-files and base-passwd, but nothing helped until I deleted the sstate directories Jan 29 11:45:20 danielki: yes, but what I meant is, how you changed it... through local conf or layer? Jan 29 11:45:35 bbappend in custom layer Jan 29 11:45:57 really? Jan 29 11:46:05 why not the image config or local? Jan 29 11:46:37 danielki: oh can you file a bug about that, something isn't noticing the variable change. -cclean will only remove the local workdir so as it didn't notice the variable change, the sstate was used. Jan 29 11:46:45 (-ccleansstate is what you want for that) Jan 29 11:46:46 hmm, my lib is 6.8 MB... I wonder if the stuff is stripped, really... Jan 29 11:46:52 image conf would not apply if you run bitbake on single recipes -- not a good idea. And local conf is not in any git repo -- not an option Jan 29 11:46:58 what is this "firmware" file in /lib (2 MB!) ? Jan 29 11:47:15 rburton: where do I file it? Jan 29 11:47:39 !bug Jan 29 11:47:42 danielki: bugzilla.yoctoproject.org, build system -> oe-core Jan 29 11:47:45 !bug 1111 Jan 29 11:47:45 k Jan 29 11:47:46 Bug https://bugzilla.yoctoproject.org/show_bug.cgi?id=1111 enhancement, Low, 1.1 M2, bruce.ashfield, VERIFIED FIXED, [routerstationpro] Add watchdog support in default kernel configure Jan 29 11:47:49 byo Jan 29 11:48:38 apparently, yocti does not recognize !bug Jan 29 11:48:54 (IMHO, it should :) ) Jan 29 11:49:29 danielki: well, custom recipes will not apply to other recipes.... Jan 29 11:49:48 though we check the local config in since it does not feel so local... Jan 29 11:50:02 lpapp: hm? it is a bbappend to an existing recipe Jan 29 11:50:06 and it works Jan 29 11:50:12 it just has a caching problem Jan 29 11:50:18 yes, so if you need it for many recipes, you will do it many times .... :-/ Jan 29 11:50:46 maybe I could put it into my distro conf Jan 29 11:50:46 in fact, I would require that it works for images just fine, anytime wherever it is used the building of that image. Jan 29 11:51:10 I certainly want to have several bbappends around. Jan 29 11:51:13 do not* Jan 29 11:51:25 used for the* Jan 29 11:51:35 ah wait, I was talking shite Jan 29 11:51:45 I actually have it in my distro conf already :) Jan 29 11:52:06 * danielki got confused between the various changes he made Jan 29 11:52:51 yes, that makes more sense. Jan 29 11:53:00 so: 11:41 < lpapp> what is this "firmware" file in /lib (2 MB!) ? Jan 29 11:53:52 I do not find an option for opkg which package owns it Jan 29 11:54:47 ah, it might be our custom stuff. Jan 29 11:57:48 yes, nvm about that one. Jan 29 11:58:56 danielki: so if you modify it in the distro conf, the meta initscripts will respect it, too? Jan 29 11:59:12 yes, I think so Jan 29 11:59:22 ROOT_HOME is used in several places Jan 29 11:59:34 in some cases installed files are modified Jan 29 12:00:19 distro config is global unless specific recipes change it Jan 29 12:00:31 in any case, it works for us and I can place /home on a separate ubi volume and it still log in as root if /home is not mounted Jan 29 12:00:52 yes, exactly. Jan 29 12:01:04 I do not see the point of /home/root. :-) Jan 29 12:01:13 yes, and it causes problems, too Jan 29 12:01:19 IMHO, it is going against the Unix philosophy. Jan 29 12:01:22 otherwise I would not have minded Jan 29 12:01:34 lpapp: mail the list, there may be valid reasons, or now-obsolete reasons that don't apply anymore Jan 29 12:04:42 rburton: http://comments.gmane.org/gmane.comp.handhelds.openembedded.core/32719 Jan 29 12:04:44 When I build ucblic - it should build ldd (as for uclibc-packages.inc). However ldd does not get built. Inspecting tmp/work/i586-uclibc/uclibc//packages-split shows that ldd/ is empty Jan 29 12:04:46 you sined it... Jan 29 12:04:48 signed* Jan 29 12:04:52 any ideas? Jan 29 12:05:02 oh, sorry, that is systemd Jan 29 12:05:27 commit de5b44a74018c49b6f3079c4c5085b4146b422c4 Jan 29 12:05:38 Kang introduced it in this commit, but without any explanation why it is /home/root Jan 29 12:05:53 it may be that some software had this nasty assumption, or recipe. Jan 29 12:06:35 http://lists.openembedded.org/pipermail/openembedded-commits/2012-December/144631.html Jan 29 12:06:43 yes, so the thing is, the systemd recipe used /home/root Jan 29 12:06:47 the question is why.... Jan 29 12:08:10 git show b8744d5376a9df4ec30120fdc8f39579d34d0545 | grep home/root Jan 29 12:08:10 + # we only have /home/root, not /root Jan 29 12:08:10 + sed -i -e 's:=/root:=/home/root:g' units/*.service* Jan 29 12:10:21 danielki: are you also on the list? I could CC you, too. Jan 29 12:10:36 (if not) Jan 29 12:10:51 lpapp: no, I'm not yet on the list. mail is daniel.elstner@kdab.com Jan 29 12:11:18 thanks Jan 29 12:13:21 danielki: heh, you work for KDAB? Jan 29 12:13:22 :-) Jan 29 12:13:28 yep Jan 29 12:13:31 nice. Jan 29 12:13:39 lpapp: FHS 2.3 still says /root : Home directory for the root user (optional) Jan 29 12:13:54 yes Jan 29 12:13:59 hence writing the email. :-) Jan 29 12:14:00 lpapp: ah, I see you're a KDE guy :) Jan 29 12:14:13 not much these days. :) Jan 29 12:14:14 so iirc first embedded debian had /home/root Jan 29 12:14:27 ant_work: the question is _why_ ? Jan 29 12:15:17 lpapp: well, I'm originally a GNOME guy who managed to end up at KDAB anyway -- didn't know about the company until shortly before I joined it :) Jan 29 12:15:30 guess: to have / RO, but /home RW Jan 29 12:15:47 well, KDAB is more into Qt these days than KDE, no? Jan 29 12:16:07 zqad: I do not see the point for RO / Jan 29 12:16:12 zqad: you can remount stuff r/w. Jan 29 12:16:15 yeah, but we have quite a few KDE guys as employees Jan 29 12:16:16 So what is the point? :-) Jan 29 12:16:20 lots of embedded folks do :-) Jan 29 12:16:28 yes, we used to do that, too. Jan 29 12:16:36 but IMHO, the predecessors made a mistake. :) Jan 29 12:16:50 since you can remount it r/w anytime, what is the additional gain of RO? Jan 29 12:16:59 oh, kdab still exists :) Jan 29 12:17:07 well, squashfs is one thing. and dm-verity is another. Jan 29 12:17:48 zqad: I do not know these, so I will assume they are valid use cases. Still, I do not see them the majority to lead the value of the default path. Jan 29 12:18:10 av500: it's well and very much alive indeed Jan 29 12:18:22 booting from a cpio and having a persistent /home is a third.. :) Jan 29 12:18:26 years ago we had a visit from Kalle here :) Jan 29 12:18:32 heh Jan 29 12:18:50 but I guess that someone sometime thought that it's for the best Jan 29 12:18:59 danielki: yes, dfaure, volker, etc. Jan 29 12:19:17 * av500 wonders how to remount a cramfs root to RO Jan 29 12:19:21 to RW* Jan 29 12:19:35 or squashfs Jan 29 12:20:19 zqad: right, I will assume these are valid use cases, cannot judge currently, but considering that how infrequent these are on embedded, I would say go ahead and purge /home/root Jan 29 12:20:27 and these users can modify the default. Jan 29 12:20:36 lpapp: indeed, volker sits just a few doors away from me :) Jan 29 12:20:38 ubifs, jffs2, etc are way more common. Jan 29 12:21:03 in all the systems you sampled maybe Jan 29 12:21:40 exactly. in my experience, "real" flash file systems are not that common. Jan 29 12:21:49 zqad: and pratically speaking, even in those cases, you could have a root partition. Jan 29 12:21:58 keeping /root as is. Jan 29 12:22:15 so I really do not see any problem. :) Jan 29 12:22:26 but I see a lot more trouble from /home/root. Jan 29 12:22:30 but what if you upgrade? you probable erase your root partition. and thus want to keep your persistent data in one place, e.g. /home/root Jan 29 12:22:36 I see no problems :-) Jan 29 12:22:53 btw I've noticed we get per default "UBIFS: reserved for root: 0 bytes (0 KiB" Jan 29 12:24:59 zqad: upgrade, erase your root partition? Jan 29 12:25:08 Surely, I do not know what you are referring to? Jan 29 12:25:24 It is just a generic config/upgrade issue... It has not much to do with the ROOT_HOME. Jan 29 12:25:43 practically speaking, upgrade happens with packages these days than reflashes IMHO. Jan 29 12:25:46 (mostly) Jan 29 12:26:31 also, /home/root is not any better than a /root/ partition, just worse due to the no proper super/normal user separation, IMHO. :) Jan 29 12:26:32 hm Jan 29 12:26:59 i don't think anyone of us can win this argument :-) Jan 29 12:27:13 well, the mailing list will decide. Jan 29 12:27:16 but we can prolong it indefinitley Jan 29 12:27:20 like the debian vote Jan 29 12:27:28 I agree, having the choice is fine, but the default may still be questionable Jan 29 12:27:38 av500 :-) Jan 29 12:27:59 if your only worry is persistent data, /root parition will do it as fine as /home/root. Jan 29 12:28:04 IMHO, /home/root is a silly idea. Jan 29 12:28:13 greetings earthlings, i come in piece Jan 29 12:28:20 (I do not know how the debian guys came up with it at all...) Jan 29 12:31:32 the big disadvantage of such a change is incompatibility IMHO. Jan 29 12:32:29 danielki: ok, sent. Jan 29 12:32:40 cool Jan 29 12:34:10 danielki: so are you also a Qt Expert ? Jan 29 12:34:52 Nah, not really, I work more on the embedded side of things. You could say I'm a C++ expert though, which might explain why they hired me :) Jan 29 12:35:41 wow, C++ in embedded, good to know there are such people.... Unfortunately, so many people (old) people think C is the only true way. :-/ Jan 29 12:36:59 lpapp: whereas on the commercial side of things, no-one is using C Jan 29 12:37:24 well, we do. :-/ Jan 29 12:37:55 oh, I haven't seen that in a while :) Jan 29 12:42:30 ok, so it seems Yocto does not strip libraries by default. Jan 29 12:43:25 * av500 sees a lof of java in embedded.... Jan 29 12:43:47 av500: you have a different definition of embedded, I think... Jan 29 12:44:33 * KotH sees a lot of forth in embedded Jan 29 12:45:05 so the default value for INHIBIT_PACKAGE_STRIP is 1 set by some class ? Jan 29 12:48:37 for instance: file ./tmp/sysroots/foo/lib/libc-2.17.so Jan 29 12:48:38 ./tmp/sysroots/foo/lib/libc-2.17.so: ELF 32-bit LSB shared object, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.16, not stripped Jan 29 12:50:03 oh, possibly I am wrong, these are actually stripped for the image, but the non-stripped interim version is kept around, too. Jan 29 12:55:49 lpapp: well, android certainly counts as embedded, so java is indeed used a lot. thankfully, I have nothing to do with that Jan 29 12:59:33 you would be surprised what some of our customers are trying to put on an embedded device :) (HTML5 for instance) Jan 29 13:00:43 omg Jan 29 13:00:53 some people even put that on phones Jan 29 13:00:58 yep Jan 29 13:01:14 what has become of the world.. Jan 29 13:02:26 danielki: not for me. Jan 29 13:02:37 android is a generic computing platform... you have millions of apps. Jan 29 13:02:54 lpapp: well a bit like yocto :) Jan 29 13:02:56 * danielki hides Jan 29 13:03:00 for me, embedded means a dedicated system for 1-2 or a couple of tasks at maximum with very limited resources accodingly. Jan 29 13:03:02 ah, so embedded == no apps for it Jan 29 13:03:23 danielki: and on such platorms, java is a clear no starter. Jan 29 13:03:23 lpapp: but android is being used for specialized systems Jan 29 13:03:45 danielki: on such systems, too. Jan 29 13:03:55 I don't like it either, but as I said... you would be surprised what some people are attempting to do Jan 29 13:04:11 danielki: that does not make it more dedicated that a particularly designed system for that task to put harmony between the use and the platform. Jan 29 13:04:25 s/that/than/ Jan 29 13:05:03 well, the embedded work I am involved with is very UI heavy Jan 29 13:05:08 s/use/use case/ Jan 29 13:05:26 av500: but the c64 that runs the big train display in zh mainstation is embedded ;) Jan 29 13:06:31 danielki: to be complete, even Qt is a no starter for us with small flash. :) Jan 29 13:07:06 Qt embedded means powerful "embedded" systems that are much more powerful than my few years old PCs. Jan 29 13:07:11 yes Jan 29 13:07:23 * av500 did QT embedded on 150mhz arm9 Jan 29 13:07:39 many of the systems we work on have a UI that requires OpenGL acceleration Jan 29 13:08:08 iMX and OMAP based, mostly Jan 29 13:09:09 av500: we are talking about Q toolkit, not Quick time. Jan 29 13:09:13 Quick Time* Jan 29 13:09:17 different project... ;-) Jan 29 13:09:31 lpapp: I am well aware of that Jan 29 13:10:13 video or did not happen. :) Jan 29 13:10:54 http://www.youtube.com/watch?v=juSloegmnsk Jan 29 13:10:56 because you can use QString on embedded, and it may even run... but running a full UI stack on a real embedded, that is a challange, especially with Qt 4, or it will be almost unusable. Jan 29 13:11:03 there, even done by Churby himself Jan 29 13:11:13 and with Qt 5 it is even more impossible. Jan 29 13:13:09 av500: right, so basically that looks like a desktop UI Jan 29 13:13:11 well, depends on what you mean by "real embedded" :) Jan 29 13:13:15 forced onto an embedded hardware. :-/ Jan 29 13:13:30 that's just bad UI design Jan 29 13:13:37 danielki: nah, it is more. Jan 29 13:13:39 it is QT embedded on an arm9, 150mhz Jan 29 13:13:43 Qt did not really have nice UI back then for embedded. Jan 29 13:13:54 (themes, tools for rapit prototyping, etc) Jan 29 13:14:00 (still does not have it for real embedded) Jan 29 13:14:09 our customers mostly use custom UIs implemented in QML Jan 29 13:14:25 QML is a toy IMHO. :-) Jan 29 13:14:29 a huuuge one. Jan 29 13:14:44 to get qml without any frameworks, just to build up the UI, you are getting close to 10 MB Jan 29 13:14:47 (if not more) Jan 29 13:15:06 and the language is almost 5 years old, but still has no any ISO spec. Jan 29 13:15:12 well, that's nothing given the platforms we normally work on :) Jan 29 13:15:20 it is changing randomly as the time goes ahead. :) Jan 29 13:15:40 well, people use 8-32 MB flashes out there for embedded, as well. Jan 29 13:15:41 tell the Qt guys, not me Jan 29 13:16:11 I'm currently working on a system with 1GiB flash, and that's even the usual size for us :) Jan 29 13:16:14 64-512 MB RAM, etc. Jan 29 13:16:40 on such systems, QML is just a big no-go inherently. :-/ Jan 29 13:17:01 well it needs hardware acceleration Jan 29 13:17:12 so it plays in the beefy league by definition Jan 29 13:17:14 no, it does not. Jan 29 13:17:22 for real use it does Jan 29 13:17:34 at least with Qt5 Jan 29 13:17:35 it has both types of backend AFAIK. Jan 29 13:17:42 raster and gpu as well. Jan 29 13:17:42 not anymore Jan 29 13:17:51 surely, it does. :) Jan 29 13:17:57 OpenGL is a hard dependency of Qt 5 Jan 29 13:17:58 software adn gpu* Jan 29 13:18:04 opengl != hardware acceleration Jan 29 13:18:08 it is just a graphics API. Jan 29 13:18:09 sure Jan 29 13:18:13 but it is slow without Jan 29 13:18:37 well, good that we have better alternatives for embedded than Qt, e.g. fltk. Jan 29 13:19:00 trust me, our customers who use QML all have hardware acceleration, and they need it too :) Jan 29 13:19:14 RP: ok, let's wait for Darren Jan 29 13:19:23 yes, I trust... I am referring to my minimal use case though. :) Jan 29 13:19:40 yes -- different things, different domains :) Jan 29 13:33:29 hi, how can I be sure my overlay recipe (.bbappend) is used when baking it ? Jan 29 13:34:13 FILESEXTRAPATHS_prepend := "${THISDIR}/${PN}-${PV}:" Jan 29 13:34:59 is this the only variable need to set ? Jan 29 13:38:47 anybody has any idea what is wrong with ldd & ucblic? After compiling ucblic in packages-split ldd/ dir is empty and basically ldd does not get installed on image Jan 29 13:38:53 no problem with eglibc however Jan 29 14:22:29 du -sh /var/lib/opkg/ Jan 29 14:22:29 2.2M /var/lib/opkg/ Jan 29 14:22:41 is it normal size, or I can shrink it much more down? Jan 29 14:41:07 hi every one, Jan 29 14:41:34 lpapp: if you don't want opkg on the target, remove the package-management image feature. if you do, you need that. Jan 29 14:42:16 RP: I had no idea what that file was for. I am looking as to how it can be validated building the source separate from the objects. Jan 29 14:42:35 rburton: OK Jan 29 14:42:42 I had assumed we had some kind of opt out list and not an opt in list for the separate build dir. Jan 29 14:44:10 jwessel: ideally, I want to get to an opt-out model but opt-in was at least progress in that direction Jan 29 14:44:29 jwessel: usually, set those variables, try a build and see if you get what you expect is a good enough test Jan 29 14:44:54 I am looking for doc as to how to change it. I am assuming you just add the vars to local.conf to test locally for a single package. Jan 29 14:45:19 I couldn't find a reference in the documentation as to how to use it :-) Jan 29 14:50:41 I'll send a new patch. I just tested it with the vars in my local.conf and it builds fine. Jan 29 14:54:04 I want to create the following custom filesystem /boot (ext3 unmount) / (squashfs ro) /home (ext3 + ecryptfs) /update (ext3 unmount) /update-1 (ext3 unmount), can someone help me please? Jan 29 14:54:04 I found IMAGE_TYPES = "squashfs" but that create the entire image, what should I do? Jan 29 14:54:49 Where should I specify this options? Jan 29 14:55:00 jwessel: the documentation hasn't caught up with SEPB, B is documented though and the rest is standard overrides. Yes, enabling from local.conf should be fine Jan 29 14:59:54 danielki: still there? Jan 29 15:00:00 yep Jan 29 15:00:21 http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/base-passwd/base-passwd/nobash.patch#n6 Jan 29 15:00:30 I asked about this yesterday, but got no replies ... :-/ Jan 29 15:00:43 so why is that needed? It breaks for anyone like us where /etc/shadow is there. Jan 29 15:01:22 also, why is this patch not separated into two as it has two logically different custom mods? Jan 29 15:01:36 it would be easier to disable the "*" (/etc/shadow) part... Jan 29 15:01:58 btw, is there a nice way of disabling a patch meta tries to apply on top of something? Jan 29 15:02:02 lpapp: I think you're talking to the wrong guy :) Jan 29 15:02:17 I am talking to everyone. :D Jan 29 15:02:24 ah ok :) Jan 29 15:38:48 does anyone know when the linux-fslc kernel will include pcie support for imx6 ? Jan 29 15:48:41 is there some global config? Jan 29 15:48:58 similarly to local.conf, but actually committing global stuff that should be the same by our developers, like the distro, etc? Jan 29 15:49:09 or it is just fine to commit the local.conf for such stuff? Jan 29 15:49:52 lpapp: that would be the distro config, or if its actually a "site" configuration then site.conf (distribute that however you wish) Jan 29 15:49:56 lpapp: one thing you could do is to add it default-content to setup-environment, which is in a repo Jan 29 15:50:03 or site.conf Jan 29 15:50:09 :) Jan 29 15:50:22 i have site.conf in a personal layer that i add to all new build directories Jan 29 15:51:05 is there a better place than local.conf for setting this? IMAGE_FEATURES += "package-management" Jan 29 15:51:10 Couldn't I just put it into the image file? Jan 29 15:51:34 yes Jan 29 15:51:43 if its an image-specific thing Jan 29 15:51:43 lpapp: the standard setup-environment script has a variable for DISTRO btw, the default of which you could change Jan 29 15:51:46 I really do not know why I put it into the local.conf.... Jan 29 15:51:54 you'll note that plenty of images set specific image features Jan 29 15:52:00 ah, because we have different images, possibly. Jan 29 15:52:12 right, so anyway... the main question is local.conf is not really local. Jan 29 15:52:16 is there a global config file? Jan 29 15:52:22 and then a developer may chose to override that and add it to their local.conf to eg get packages or ssh on an otherwise minimal image Jan 29 15:52:28 I know I argued for one long time ago, but perhaps stuff changed. :-) Jan 29 15:52:32 no Jan 29 15:52:51 no, it is not a random environment Jan 29 15:52:59 we work on the same stuff with the same goal. Jan 29 15:53:10 hence, most of the setup (if not all) should be the same. Jan 29 15:53:19 -> distro configuration Jan 29 15:53:21 and should be coming from the repository for convenience. Jan 29 15:53:22 no Jan 29 15:53:32 there are settings over settings that are the same, e.g. package management. Jan 29 15:53:38 or, a site.conf in your layer Jan 29 15:54:00 over distros* Jan 29 15:54:16 or EXTERNAL_TOOLCHAIN, NO32LIBS, etc. Jan 29 15:54:23 pretty much my whole local.conf should be global. Jan 29 15:54:31 rburton: is site.conf updated by setup-environment if it exists already? IIRC it was not, but I might misremember Jan 29 15:54:40 we even have similar machines, so even BB_NUMBER_THREADS and PARALLEL_MAKE. :-) Jan 29 15:55:15 yes, really, my local.conf should be global Jan 29 15:55:17 applied to all developers. Jan 29 15:55:33 which we currently do through local.conf, but AFAIK it was not meant for such stuff. Jan 29 15:55:36 danielki: not iirc Jan 29 15:55:47 lpapp: those are auto-detected in master now :) Jan 29 15:55:59 lpapp: hm, the setup-environment script I have figures out the parallel settings automatically Jan 29 15:56:17 rburton: that is nice, but that was just one of those. Jan 29 15:56:26 danielki: setup-environment is a angstrom thing (iirc). it's not oe-core. Jan 29 15:56:29 (not that we will switch to master in 2014) Jan 29 15:57:37 for instance, the tedious ROOT_HOME would also better fit in a global conf for us. Jan 29 15:57:47 in our "PDK", that is. Jan 29 15:58:02 changing ROOT_HOME is 100% a distro configuration change Jan 29 15:58:35 no no Jan 29 15:58:39 it is a global change at us. Jan 29 15:58:50 we will never use insane home root path. :-) Jan 29 15:59:07 no matter what distro, etc, well unless someone else takes over the maintainership here. :) Jan 29 15:59:12 (with a vastly different mindset) Jan 29 15:59:45 btw, this sentence is obsolete then in the current documentation ... A good example is perhaps the level of parallelism you want to use through the BB_NUMBER_THREADS and PARALLEL_MAKE variables. Jan 29 15:59:52 or at least, there could be a more useful example... Jan 29 16:00:10