**** BEGIN LOGGING AT Tue Feb 03 02:59:58 2015 Feb 03 05:15:27 * khem sees the little button for light theme on git.yp.org what a relief, thanks halstead Feb 03 05:15:47 Glad you like it khem. Feb 03 05:16:05 this was one thing I always asked for. Feb 03 05:16:22 the dark color combo just didnt fit my eyes Feb 03 05:17:24 :) Feb 03 09:35:37 morning all Feb 03 09:36:43 morning~ Feb 03 09:36:54 bluelightning: did you get to try the intel edison meta-data package? Feb 03 10:04:24 opengl class Feb 03 10:04:26 http://38.media.tumblr.com/3d0a87092555a46c56a81dc04ffdd566/tumblr_nj6fk0KY7A1tlb56zo1_400.gif Feb 03 10:12:59 miandonmenmian_: I did try building the kernel, and it succeeded; but I wasn't building on debian though Feb 03 10:13:27 miandonmenmian_: did you see the workaround in this post? https://communities.intel.com/message/264124 Feb 03 10:14:09 obviously there is a proper fix for this and we should figure out what that is, but that looks to be a workaround Feb 03 10:18:10 bluelightning: took note of that, that probably helps quite a bit with the proxy issue, however i dont understand that patch Feb 03 10:19:10 should i just copy the entire text and issue something like patch -p2 < fromforumpatch.patch ? Feb 03 10:19:15 it was rejected Feb 03 10:19:43 current sources, or at least the sources that i have, do not have that many lines with git apply Feb 03 10:19:49 has 2 or 3 Feb 03 10:20:05 my guess is that it fails because there are not that many lines to delete Feb 03 10:21:56 bluelightning: on a side note, if I change something on a recipe. do i need to manually clean the whole /tmp/ folder? or just running bitbake will notice? Feb 03 10:22:18 you may need to apply the changes manually if the patch does not apply, I didn't try it myself Feb 03 10:22:33 no, it should pick up the change automatically Feb 03 10:23:43 i see, i managed to get my previous working environment. i would still like to figure out a way how to fix the issue with my newer broken environment.. Feb 03 10:23:59 but i cant wait to play a bit with it :P Feb 03 10:25:23 i liked the way you could add files in openwrt to the new image. adding a new recipe+layer seems complicated Feb 03 10:27:26 bluelightning: perhaps for my change to be picked up, i need to call the source again before running bitbake? Feb 03 10:30:57 I'm not sure I understand the question... you should be able to run the same command to continue the build that you did earlier when it failed Feb 03 10:33:21 sorry, mixed up things. What i mean is that i have done a successful build. Then changed the size of the rootfs and run bitbake again. but no change is done or picked up Feb 03 10:33:57 what do you mean by "changed the size of the rootfs"? how did you do that exactly? Feb 03 10:35:22 edison.env "partitions" variable and edison-image.bb Feb 03 10:35:51 meta-edison-distro/recipes-bsp/u-boot/files/edison.env Feb 03 10:36:05 i'm wondering if the uboot is actually done Feb 03 10:39:45 changing it on the .bb is picked up as you said Feb 03 10:39:57 not on the .env Feb 03 10:41:22 I'll have to look to see where that .env file is actually used Feb 03 10:48:20 miandonmenmian_: hmm, near as I can tell it ought to pick up changes to that file, just testing now Feb 03 10:50:13 bluelightning: found my mistake, you are totally right Feb 03 10:50:44 seems like the step 'postBuild.sh' is now required Feb 03 10:51:02 i recall trying this last year, and was not needed :S Feb 03 10:51:42 its quite confusing, not sure what is yocto standard way to do it. I should probably start it from a plain yocto source Feb 03 10:52:31 yes, there are extra scripts the BSP authors have added Feb 03 10:53:56 add layers and recipes should be quite the same, right? Feb 03 10:54:44 yes Feb 03 11:21:17 bluelightning: edison.env is making any sense to you ? Feb 03 11:21:34 usually this is just changed on the .bb? Feb 03 11:25:46 miandonmenmian: I haven't looked at the standard u-boot recipe to see if it's something custom there or not Feb 03 11:28:17 Hi everyone Feb 03 11:29:17 Hi Aurele Feb 03 11:30:00 I would like to split my rootfs into different parts (the main goal is to have one read only with basic fs, and a second one with graphics libraries) Feb 03 11:30:14 does anyone has a starting point ? Feb 03 11:30:57 I would like to know how to say to bitbake that for example /opt is a different filesystem Feb 03 11:31:59 so I could have 2 fs generated (chose wich library goes in which fs is a different story ;) ) Feb 03 11:37:55 we don't have built-in support for that kind of thing, but wic can be used to produce a multi-partition image from one or more images that the build system produces Feb 03 11:38:16 so it would be a general matter of setting up to mount the other partition(s) from /etc/fstab Feb 03 11:41:01 hi bluelightning, thx for your fast answer, what do you mean by "wic can be used to produce a multi-partition"? Feb 03 11:41:27 there is a tool called wic supplied with the build system that can compose a partition layout for you Feb 03 11:42:11 http://www.yoctoproject.org/docs/current/dev-manual/dev-manual.html#creating-partitioned-images Feb 03 12:26:48 I really feel like wic is far from complete right now Feb 03 12:45:30 hi, psplash + systemd - should it work "out of the box" or are these patches still needed https://lists.yoctoproject.org/pipermail/yocto/2014-August/021142.html ? Feb 03 12:49:29 there's no sign of upstream patches in psplash repo, so i figure this is still required. Feb 03 13:06:20 bluelightning, abelloni, thanks for the hints Feb 03 13:08:17 abelloni: patches welcome... ;) Feb 03 13:52:17 bluelightning: yeah, I'm actually working on that right now Feb 03 13:52:42 abelloni: excellent :) Feb 03 13:52:42 but I'm not used to python Feb 03 13:52:54 progress is a bit slow :) Feb 03 14:23:09 abelloni: wic is wip :) Feb 03 14:23:31 abelloni: what you are working on it right now? Feb 03 14:26:14 I find wic good for making basic sd cards for zynq based hardware Feb 03 14:27:43 in fact, "wic" doesn't really fit my needs... I would like to have each partition standalone... or at most multiple devices, if we have a big sdcard and a little flash it is interesting for us to split the filesystem Feb 03 14:28:19 but anyhow it was a good advice Feb 03 14:28:33 Aurele: wic should be capable of that though... what exactly is missing? Feb 03 14:29:00 bluelightning, maybe I didn't understood everything :) Feb 03 14:29:49 bluelightning, if you say so I will go further on this Feb 03 14:30:24 AFAIK with wic you should be able to specify pretty much any partition layout using a kickstart file Feb 03 14:41:02 otavio: did you look at the uboot multiple-compile patches? Feb 03 14:54:29 rburton: on the pipeline for today Feb 03 14:54:37 great, thanks Feb 03 14:55:16 rburton: i were working on the 3.10.53 GA release from Freescale and this used most of my free time Feb 03 14:55:39 otavio: like we discussed, i.mx6 image support for wic Feb 03 14:55:57 abelloni: how is this going? Feb 03 14:56:02 and also omap support without a fat partition Feb 03 14:56:11 otavio: i.mx6 is easy ;) Feb 03 14:56:18 mxs is not the same Feb 03 14:56:19 abelloni: ohhhh yes Feb 03 14:56:29 abelloni: did you handled SPL as well? Feb 03 14:56:52 abelloni: mxs has the specific 'S' labelled partition Feb 03 14:57:09 yeah but I'm not happy yet with my solution Feb 03 14:57:25 otavio: I know... Feb 03 14:57:58 abelloni: :-) Feb 03 15:01:37 tomz: I'm actually wondering whether we should actually use sectors for the partition size in wic Feb 03 15:16:11 abelloni: I don't think so Feb 03 15:16:24 abelloni: nothing forbits the wic to work with bigger sectors Feb 03 15:16:37 abelloni: so I think we ought to use offsets Feb 03 15:17:20 abelloni: 512B can be usable for now but if we can get most of code sector size independant, it'd be better Feb 03 15:18:00 abelloni: except the SoC related stuff. For those, I am afraid we have fixed offsets (at least for i.MX) Feb 03 15:26:38 otavio: yeah, my issue is SoC related Feb 03 15:26:59 I want to put u-boot at 1k for i.mx Feb 03 15:27:11 or the SPL at 128k for am335x for example Feb 03 15:27:36 so I'm wondering whether we should make that configurable with a 1k granularity Feb 03 15:27:45 or 512B granularity Feb 03 15:28:39 There may be some architecture out there wanting the SPL to be on the second sectore of the sdcard :) Feb 03 15:40:42 abelloni: have you considered putting all of that as a separate source plugin? Feb 03 15:43:57 bboozzoo: that's not quite possible Feb 03 15:44:04 part of it yes Feb 03 15:48:14 it is definitely possible with uboot, I got a kind of proof of concept working on a mx66q before the boards were taken to another project Feb 03 15:48:31 that's why I moved to BBB later on :) Feb 03 15:49:37 yeah but we have a choice Feb 03 15:49:59 either say: it is already possible to create a bootable sdcard image for bbb, use it Feb 03 15:50:28 or be flexible and provide a way to create an sdcard image with two spl for example Feb 03 15:50:40 and that one is not yet possible Feb 03 16:02:00 abelloni: yeah, it's a bit inflexible now, the source plugins should produce partition image but in reality they tend to do a bit more, take a look at bootimg-pcbios for instance Feb 03 16:04:25 it'd be nice to have something that would process the disk image after partition assembly Feb 03 16:39:43 I have 2 recipes with same name. However the second recipe has a higher version. Does anyone know if which one would be included ? The older one or the newer one ? Feb 03 16:40:30 the newer, by default Feb 03 16:40:31 the newer one unles you use preferred version Feb 03 16:40:37 bottazzini: newer, in the absence of DEFAULT_PREFERENCE or PREFERRED_VERSION Feb 03 16:41:03 got it :) thanks Feb 03 16:41:53 unless the two recipes are in different layers, in which case the lower version would be preferred if it's in the higher priority of the two layers Feb 03 16:57:55 Hmm, should really add uclibc and musl support to meta-sourcery at some point here Feb 03 17:00:03 might be worth just enhancing and renaming the existing libc recipe to greedily grab the bits for all of them, rather than adding separate recipes Feb 03 17:20:11 it's really a pain debugging a problem with inline python which results in a shell syntax error due to the shell parsing error message, which sucks Feb 03 17:22:00 bluelightning: hi, poky 1.7 (dizzy) has a dependency on python 2.7.x which i didn't have installed on my build machines. so I am using buildtools as described here: http://downloads.yoctoproject.org/releases/yocto/yocto-1.7/buildtools/ Feb 03 17:22:52 bluelightning: the trouble is that the build tools don't have pexpect python module needed for image testing. How can I get that added to my buildtools? Feb 03 17:27:33 darkhorse: there is a python-pexpect recipe in meta-oe, that would be a starting point - it doesn't have BBCLASSEXTEND = "nativesdk" so that would need to be added Feb 03 17:28:16 darkhorse: then you would need to add nativesdk-python-pexpect to the TOOLCHAIN_HOST_TASK value in buildtools-tarball recipe Feb 03 17:28:32 darkhorse: then rebuild buildtools-tarball and install it Feb 03 17:28:51 I think I had better open a bug for that because we should have it Feb 03 17:31:45 bluelightning, https://bugzilla.yoctoproject.org/show_bug.cgi?id=7278 Feb 03 17:31:47 Bug 7278: normal, Undecided, ---, ross.burton, NEW , Default core-image-x11 has X server with screen blanking active Feb 03 17:31:52 bluelightning: thanks. yeah i think it should be in the prebuilt tarball Feb 03 17:32:01 I'll look at it when I get a chance, just wnated a record of it :) Feb 03 17:33:11 Crofton|work: thanks Feb 03 17:33:51 also, I figure some other opinons would be good and if anyone can tell me what to change, even better Feb 03 17:34:22 I need to go find a laptop power supply, I forgot mine in the devroom :( Feb 03 17:35:11 darkhorse: https://bugzilla.yoctoproject.org/show_bug.cgi?id=7279 Feb 03 17:35:12 Bug 7279: normal, Undecided, ---, saul.wold, NEW , buildtools needs python-pexpect Feb 03 17:58:54 so far i've seen 3 different crashes with traceback from toaster in a single attempt to test it Feb 03 17:58:57 this doesn't bode well Feb 03 17:59:49 some *obvious* typos here Feb 03 17:59:57 os.environment? i think you mean os.environ Feb 03 18:01:13 i suggest the folks doing toaster development make use of flake8 Feb 03 18:04:04 kergoth: gah, sorry about that. A lot of new functionality has gone in in a very short period of time, so things are bound to be a bit shaky at the moment Feb 03 18:05:00 fair enough, but afaict it can't even be run from a fresh environment at all right now. some level of basic sanity testing would be useful, i think Feb 03 18:05:22 * kergoth fixes and continue Feb 03 18:07:15 kergoth: that doesn't sound good. Any details you can send our way about the issues will help (I've seen you've opened one in Bugzilla, thanks for that). Feb 03 18:11:02 hmm, looks like the example hosted toasterconf.json in the wiki isn't valid according to toaster Feb 03 18:13:16 belen: is there a functioning example toasterconf.json for hosted mode available? Feb 03 18:13:44 * kergoth switches to local for now Feb 03 18:14:32 kergoth: let me see what's the file in the wiki. I must confess that the wiki is not very up to date right now either :/ Feb 03 18:15:10 looks like toaster fails to be sourced by zsh, fyi, as it uses non-portable shell constructs. looks like bash only at the moment? Feb 03 18:18:30 kergoth: I believe so. We have an issue open for that https://bugzilla.yoctoproject.org/show_bug.cgi?id=6964 Feb 03 18:18:32 Bug 6964: normal, Low, 1.8, fabrice.coulon, NEW , command "source toaster start" does not work with zsh Feb 03 18:18:37 ah, thanks Feb 03 18:20:11 belen: question, is there a toaster roadmap, or just the bugs in the yocto 1.8 schedule? also, is the intent for toaster managed mode to replace hob at some point, or is hob continuing to be developed? Might be a stupid question, but I can see it being asked, I know someone asked me that already Feb 03 18:20:34 or will local mode gain the ability to launch builds or do configuration of the current build dir? Feb 03 18:21:18 * kergoth wonders if there'd be interest in exposing recipe configuration with PACKAGECONFIG to the user in hob or toaster Feb 03 18:23:25 right, I'll try to answer one by one. Is there a Toaster roadmap? Well, yes, a fluid one that changes with input from you all, and it is not really documented anywhere. Medium term, it involves providing the same functionality as Hob Feb 03 18:23:55 is the intent for toaster managed mode to replace hob at some point, or is hob continuing to be developed? Yes. Hob is very much in life support already, and will be deprecated once Toaster does what Hob does Feb 03 18:27:25 belen: okay, thanks, that's helpful Feb 03 18:28:30 will local mode gain the ability to launch builds or do configuration of the current build dir? > It can right now (work in progress, though) but you have to configure and start your builds from Toaster itself Feb 03 18:29:13 kergoth: I have a question for you now ;) Is this the toasterconf.json from the wiki that didn't work for you https://wiki.yoctoproject.org/wiki/File:Toasterconf.json.txt.patch Feb 03 18:29:33 yeah, i think so. it complained about the '1' source type and lacking source priority info Feb 03 18:29:55 kergoth: that sounds about right. It needs to be updated. Thanks! Feb 03 18:33:07 belen: i realize i could probably determine it by examining hte schedlue, but tehre are a ton of bugs to sort thorugh, so i'll ask you real quick if you don't mind.. is it expected to reach feature parity in the 1.8 timeframe, or post-1.8? Feb 03 18:34:12 kergoth: post 1.8. In 1.8 we'll bring in the ability to add layers, set variables and start builds Feb 03 18:34:23 recipe and image customisation will come later Feb 03 18:34:24 cool, thanks Feb 03 19:35:38 Any docs on changing arm flavor? I have an arm7 and the defaults are arm5? Feb 03 20:42:56 linux-yocto builds an initial ramdisk, right? I see "rootfs" mounted on / in addition to my real root partition. Feb 03 20:43:04 Where do I find the content of that ramdisk? Feb 03 20:43:40 I'm using EFI boot with just a vmlinuz kernel file, so it must be something that was linked into that. Feb 03 20:47:59 Does systemd always manage cgroups? Feb 03 20:48:42 I see early in the bootlog that it starts doing something with cgroups: "Using cgroup controller name=systemd. File system hierarchy is at /sys/fs/cgroup/systemd." Feb 03 20:48:58 And then later ps shows that already pid 1 has cgroups. Feb 03 20:49:09 But I am not seeing that on another system also using systemd. Feb 03 20:51:10 For example, on Debian pid 1 = /sbin/init has no cgroups. Feb 03 20:51:51 Sorry for the dumb questions. I'm also my googling in parallel, I just don't know what I am looking for :-/ Feb 03 20:52:38 "As a nice default, if the cpu controller is enabled in the kernel, systemd will create a cgroup for each service when starting it." says the systemd admin guide Feb 03 20:52:55 so maybe that? Feb 03 20:55:58 rburton: is there a way to check whether it's enabled on a running system without the kernel's defconfig? Feb 03 20:56:28 systemd should create cgroups, it's one of the ways it makes sure that daemons don't end up with processes that don't get killed when a service stops. However, anything can create a cgroup as long as it follows some rules to not stomp on the other cgroups. More recently it was decided that if using systemd, that anything that wanted to manipulate cgroups should go through the systemd cgroup api to make sure that one cgroup doesn't break another. Feb 03 20:57:54 rewitt: I remember reading about that, but did not pay attention to the details at the time. Either way, should pid 1, systemd itself, already have a cgroup? Feb 03 21:01:25 pohly: On my Fedora workstation and it the yocto image I'm looking at, pid 1 is in the systemd cgroup Feb 03 21:02:41 pohly: perhaps on debian they are explicitly removing pid 1 from the systemd cgroup for some reason? I'm not familiar enough with the distro to know. Feb 03 21:03:02 rewitt: thanks for the confirmation. Feb 03 21:04:32 rewitt: It's not just pid 1, all kernel threads also show up with no cgroup on Debian and with cgroup on this other machine. Feb 03 21:07:18 pohly: so "cat /proc/1/cgroup" is empty? Feb 03 21:07:51 pohly: Are you sure your Debian is using systemd? Feb 03 21:08:23 tastycactus: Good question! :-D Feb 03 21:08:38 rewitt: on Debian, cat /proc/1/cgroup is not empty. For example, it includes "1:name=systemd:/" Feb 03 21:08:59 tastycactus: yes, I just checked again, just to be sure ;-} Feb 03 21:09:11 pohly: then it's in the systemd cgroup Feb 03 21:09:26 tastycactus: /sbin/init -> /lib/systemd/systemd Feb 03 21:10:30 rewitt: so what you are saying is that pid 1 is in the cgroup and it's just "ps" which (for whatever reason) does not show it? Feb 03 21:13:40 pohly: Yeah. If I do "ps -eo pid,cgroup" I see the same results, it doesn't show a cgroup for pid 1. Feb 03 21:14:09 That would be the second time that ps from procps-3.2.8. fools me. It also silently fell back to printing the 114 uid for messagebus, because "messagebus" is too long. Feb 03 21:14:36 That left me scratching my head too for quite a while because I simply assumed that there must be a hard-coded uid not listed in /etc/passwd. Feb 03 21:15:09 pohly: Try systemd-cgls Feb 03 21:16:34 rewitt: I will, once the system is back up. Feb 03 21:16:46 On Debian, it does show /sbin/init under 1. Feb 03 21:17:13 pohly: Note that the systemd "cgroup" that is always created is only for process management not for delegation of resources. systemd can also do that and does by default for cpu, but even that is tunable. see DefaultControllers in http://0pointer.de/public/systemd-man/systemd.conf.html if you're curious. Feb 03 21:24:22 Is there a recipe for reference for creating a /boot ubifs image continaing kernel and device tree? Feb 03 21:47:19 rewitt: as you seem to be familiar with cgroups and systemd, I hope you don't mind me asking further questions. "user@5000.service" fails to start, because of: "systemd[729]: Failed to create root cgroup hierarchy: Permission denied". Feb 03 21:47:49 I have no idea who is denying permission here on what. Feb 03 21:47:58 Any hints? Feb 03 21:57:34 pohly: I'm not that familiar with the systemd-user aspect. But something is mucked up there. Whenever a user logs in systemd can be configured to run "systemd --user" for that user so the user can have service files in his home account that systemd starts. Feb 03 21:57:58 I don't think I am getting that far. Feb 03 21:58:39 I'm currently looking at /usr/lib/systemd/system/user@.service, which is what starts "systemd --user". Feb 03 21:59:16 pohly: Right, so my guess is that particular instance of systemd is what is getting the permission failure" Feb 03 21:59:41 I tried adding strace, but systemd is unhappy: Feb 03 21:59:41 ExecStart=-strace -o/tmp/systemd-user.log /usr/lib/systemd/systemd --user Feb 03 21:59:50 Ah. path must be absolute. Feb 03 22:00:10 pohly: It may be a problem with pam Feb 03 22:01:32 No, cgroups again: Feb 03 22:01:32 open("/sys/fs/cgroup/systemd/user.slice/user-5000.slice/user@5000.service/cgroup Feb 03 22:01:32 .procs", O_WRONLY|O_NOCTTY|O_CLOEXEC) = -1 EACCES (Permission denied) Feb 03 22:01:32 sendmsg(3, {msg_name(0)=NULL, msg_iov(4)=[{"PRIORITY=3\nSYSLOG_FACILITY=3\nCOD". Feb 03 22:01:32 .., 132}, {"MESSAGE=", 8}, {"Failed to create root cgroup hie"..., 57}, {"\n", 1 Feb 03 22:01:33 }], msg_controllen=0, msg_flags=0}, MSG_NOSIGNAL) = 198 Feb 03 22:04:08 That user-5000.slice is still there after the failure, but user@5000.service is not. Feb 03 22:04:27 pohly: My guess is that it isn't getting a pam session and thus the process doesn't have credentials Feb 03 22:04:45 pohly: Is this on yocto? Feb 03 22:05:21 rewitt: some perverted version of it. And no, it wasn't me who modified it. I'm just the unlucky sod who needs to clean up. Feb 03 22:05:52 And of course the people who came before me left no comments whatsoever for the changes they were making. Feb 03 22:07:36 pohly: what files are in /etc/pam.d? Feb 03 22:10:35 The pam.d file responsible for creating the PAM session is tlm-default-login, from the Tizen login manager (TLM). I asked the developers of that how systemd --user gets triggered and they told me that they just ask for a pam session. So it should be around. Feb 03 22:11:06 I also compared /etc/pam.d against a working system. There's no difference. No, the problem must be elsewhere. Feb 03 22:11:16 I'm now adding more debug commands to the user unit. Feb 03 22:21:09 My debug output shows that /sys/fs/cgroup/systemd/user.slice/user-5000.slice/user@5000.service/cgroup.procs exists and is read-only. "systemd --user" tries to write it, which of course fails. Feb 03 22:21:44 It also did a mkdir("/sys/fs/cgroup/systemd/user.slice/user-5000.slice/user@5000.service") earlier, which also failed. Feb 03 22:22:19 So the question is: does systemd --user perhaps incorrectly attempt to modify the cgroup hierarchy instead of using what's already there? Feb 03 22:22:27 And why? Feb 03 22:22:40 rewitt: ^^^ still around? Feb 03 22:23:06 pohly: why do you think it's trying to modify it? I thought I only saw an "open" Feb 03 22:23:26 open( O_WRONLY|O_NOCTTY|O_CLOEXEC) Feb 03 22:23:35 Opening for writing. Feb 03 22:24:21 who is the owner of the slice? Feb 03 22:24:23 Argh, it's really to late for me here. Feb 03 22:24:31 i was about to say that pohly Feb 03 22:24:38 It is rw, and the user is also matching. Feb 03 22:25:05 But smack label is wrong. That is a Tizen specific thing. Feb 03 22:25:21 rburton: so whay are you still up? ;-} Feb 03 22:25:21 pohly: fwiw tizen is the only place that i've heard of systemd —user actually working :/ Feb 03 22:25:50 pohly: its an hour earlier here :) and i just came back to my laptop to kick the overnight jobs and sleep it Feb 03 22:26:01 rburton: it is running here on Debian Testing. Feb 03 22:26:05 oh yay Feb 03 22:26:15 I don't know what it does, but it runs. Feb 03 22:26:22 \o/ Feb 03 22:26:43 pohly: If the file permissions are correct then it would have to be an acl issue Feb 03 22:26:46 crumpets popped, time to go. stop working, pohly! Feb 03 22:27:13 pohly: considering it's just an open call Feb 03 22:28:19 rewitt: yes, that's what this smack thingie is. No, it's not something that you smack (although people tend to get into that mood), it is a kernel security module which adds its own checks to open(). Feb 03 22:28:44 pohly: That, I can't help you with. :-D Feb 03 22:29:13 rewitt: you have helped already, so thanks! Feb 03 22:29:27 pohly: Well I tried at least :) Feb 04 00:27:08 adtrepo.yoctoproject.org　does not work? **** ENDING LOGGING AT Wed Feb 04 02:59:58 2015