Re: [yocto] Issue in combining configure options in different tunes
Hi,
Actually I am able to build both elf(for xloader uboot) and linux
toolchain(linux and userspace components) using tune mips32 and tune mips64-n32
with the required libgcc libraries and other required headers.
Glibc libraries were also build using tune-mips64-n32 with different
combinations of abi arch and endianness.
Now my issue is to combine both the toolchain in single meta-xtoolchain layer
so that both can be build in one yocto workspace using single meta-xtoolchain
layer by just changing a variable in local.conf and all is done.
Example say Toolchain_var =elf
DEFAULTTUNE=mips32
Build using the same gcc recipes the elf toolchain
Toolchain_var=linux
DEFAULTTUNE=mips64-n32
Build using the same gcc recipes the linux toolchain
EXTRA_OECONF_append_mips32=
${@bb.utils.contains(mailto:$%7b@bb.utils.contains(Toolchain_var , elf,
put elf related extra_oeconf, put linux related extra_oeconf, d)}
Is this type of thing possible to put EXTRA_OECONF configure options on the
basis of toolchian variable ?? and this EXTRA_OECONF_append_mips32 or
EXTRA_OECONF_append_mips64-n32 works???
Or tell me the way that I can add specific Configure options for gcc on the
basis of tune passed?
Please help me out on the issue.
Thanks in advance
Regards,
Rohit Jindal
===
Please refer to http://www.aricent.com/legal/email_disclaimer.html
for important disclosures regarding this electronic communication.
===
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] busybox and mdev, how does it really work?
Hi. We have a system based on the poky-tiny distro and we use mdev as our device manager, or at least we do not set it to something at all in the distro .conf: # Use tmpdevfs and the busybox runtime services VIRTUAL-RUNTIME_dev_manager = #VIRTUAL-RUNTIME_login_manager = tinylogin #VIRTUAL-RUNTIME_init_manager = VIRTUAL-RUNTIME_keymaps = and busybox is configured for have CONFIG_MDEV support. Other from this we have not added or installed any specific mdev packages. Things looked ok for a while, /dev was populated properly after boot and all necessary file systems / mount points were created. We were using an ext2 fs in RAM for mounting /. Now, we made a change to instead use a CPIO image compressed using xz and enabled the support in kernel to handle this. This is when our problems started :( Suddenly our system booted with just a very minimalistic /dev folder, containing basically only a few of the devices probed at boot time. When checking /etc/init.d we discovered that the mdev script actually is not part of our image at all? In fact, it never was, even when we used the ext2 boot! The only way I could see how this script may be added to the image was to install busybox-mdev, but that resulted in even more problems. Now our mtd partitions could no longer be accessed!? They were visible in /dev but not found by tools like flashcp. If I reduced the mdev script to only do 'mdev -s' it all seems to work, and /dev looks like it did before the change of ram boot mode. My guess here is that the re-mounting of /dev that is performed as part of the mdev init script destroys something? Also, there seems to be a mess among the scripts executed at boot time with respect to what is mounted and not. We have the mountall.sh script, devpts.sh, mdev and a few others that all seems to think they need to mount core file systems, but nothing besides mdev seems to mount /dev? How was this done before adding mdev? Obviously it worked well without it, but when moving to CPIO.xz it seems to be mandatory, but requires changes to work as expected? So, the questions now are: - how was /dev populated before when there was no /etc/init.d/mdev? - why does adding /etc/init.d/mdev corrupt our /dev filesystem and render some of our devices unusable? - should you really need to explicitly add busybox-mdev? And if so, is it expected that we need to change the init script? Anyone that could describe how this is supposed to work, and what we probably did wrong? Seems a little bit too magical right now, and it would really feel a lot better if this could be explained. Thanks. Hans Build Configuration: BB_VERSION= 1.20.0 BUILD_SYS = x86_64-linux NATIVELSBSTRING = SUSE-LINUX-11 TARGET_SYS= arm-poky-linux-gnueabi DISTRO_VERSION= 1.5 TUNE_FEATURES = armv7a vfp cortexa9 TARGET_FPU= vfp meta meta-yocto meta-yocto-bsp= dora:75bed4086eb83f1d24c31392f3dd54aa5c3679b1 meta-oe = dora:513e7ca20ddd0a5c3b649bf292a67c3e0473d3a8 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] busybox and mdev, how does it really work?
* Hans Beckérus hans.becke...@gmail.com [140121 11:05]: Things looked ok for a while, /dev was populated properly after boot and all necessary file systems / mount points were created. We were using an ext2 fs in RAM for mounting /. Now, we made a change to instead use a CPIO image compressed using xz and enabled the support in kernel to handle this. This is when our problems started :( Suddenly our system booted with just a very minimalistic /dev folder, containing basically only a few of the devices probed at boot time. So, the questions now are: - how was /dev populated before when there was no /etc/init.d/mdev? I haven't checked poky-tiny, or more specifically the kernel configurations for it. But based on the description that I cited above, I'd guess that poky-tiny has CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y enabled. That would mean the the kernel itself were managing /dev for you when you were using ext2. Unfortunately, CONFIG_DEVTMPFS_MOUNT do only automount devmptfs on /dev if you're not in an initramfs (or initrd). Thus, you should add a simple initscript which mounts devtmpfs on /dev. Thereafter, you should be fine. Regarding your other questions on mdev, it's been a little while since I used mdev. Let us know if the ideas above is enough, or if you want to dig more into mdev. Cheers, Anders -- Anders Darander ChargeStorm AB / eStorm AB ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] busybox and mdev, how does it really work?
On Tue, Jan 21, 2014 at 11:23 AM, Anders Darander and...@chargestorm.se wrote: * Hans Beckérus hans.becke...@gmail.com [140121 11:05]: Things looked ok for a while, /dev was populated properly after boot and all necessary file systems / mount points were created. We were using an ext2 fs in RAM for mounting /. Now, we made a change to instead use a CPIO image compressed using xz and enabled the support in kernel to handle this. This is when our problems started :( Suddenly our system booted with just a very minimalistic /dev folder, containing basically only a few of the devices probed at boot time. So, the questions now are: - how was /dev populated before when there was no /etc/init.d/mdev? I haven't checked poky-tiny, or more specifically the kernel configurations for it. But based on the description that I cited above, I'd guess that poky-tiny has CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y enabled. Indeed (from our .config): CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y That would mean the the kernel itself were managing /dev for you when you were using ext2. Unfortunately, CONFIG_DEVTMPFS_MOUNT do only automount devmptfs on /dev if you're not in an initramfs (or initrd). Sounds reasonable. But, when moving from ext2.gz to cpio.xz, we still did not add any init script for mounting /dev, yet it is still created and populated? But only with a very limited set of devices. I guess there is a difference when the kernel mounts the cpio.xz image compared to expanding the ext2.gz in RAM with respect to how /dev is handled. But I am only guessing here. Thus, you should add a simple initscript which mounts devtmpfs on /dev. Thereafter, you should be fine. Well, using the one that came from busybox-mdev rendered our /dev completely useless :( As I said, if I reduce the script to perform only 'mdev -s', then it works a lot better. So mounting /dev again seems like a bad idea. Regarding your other questions on mdev, it's been a little while since I used mdev. Let us know if the ideas above is enough, or if you want to dig more into mdev. mdev as a device manager I think we have under control, the confusion is more in our current system behavior at boot. Cheers, Anders -- Anders Darander ChargeStorm AB / eStorm AB ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] busybox and mdev, how does it really work?
On Tue, Jan 21, 2014 at 12:10 PM, Hans Beckérus hans.becke...@gmail.com wrote: On Tue, Jan 21, 2014 at 11:23 AM, Anders Darander and...@chargestorm.se wrote: * Hans Beckérus hans.becke...@gmail.com [140121 11:05]: Things looked ok for a while, /dev was populated properly after boot and all necessary file systems / mount points were created. We were using an ext2 fs in RAM for mounting /. Now, we made a change to instead use a CPIO image compressed using xz and enabled the support in kernel to handle this. This is when our problems started :( Suddenly our system booted with just a very minimalistic /dev folder, containing basically only a few of the devices probed at boot time. So, the questions now are: - how was /dev populated before when there was no /etc/init.d/mdev? I haven't checked poky-tiny, or more specifically the kernel configurations for it. But based on the description that I cited above, I'd guess that poky-tiny has CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y enabled. Indeed (from our .config): CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y That would mean the the kernel itself were managing /dev for you when you were using ext2. Unfortunately, CONFIG_DEVTMPFS_MOUNT do only automount devmptfs on /dev if you're not in an initramfs (or initrd). Sounds reasonable. But, when moving from ext2.gz to cpio.xz, we still did not add any init script for mounting /dev, yet it is still created and populated? But only with a very limited set of devices. I guess there is a difference when the kernel mounts the cpio.xz image compared to expanding the ext2.gz in RAM with respect to how /dev is handled. But I am only guessing here. Another thing, You say CONFIG_DEVTMPFS_MOUNT does *not* automount /dev if using the initrd scheme? But I think it did when using the compressed ext2 file system? How come /dev was mounted and populated automatically in the ext2 case but when we changed to cpio.xz things seem to break? Thus, you should add a simple initscript which mounts devtmpfs on /dev. Thereafter, you should be fine. Well, using the one that came from busybox-mdev rendered our /dev completely useless :( As I said, if I reduce the script to perform only 'mdev -s', then it works a lot better. So mounting /dev again seems like a bad idea. Regarding your other questions on mdev, it's been a little while since I used mdev. Let us know if the ideas above is enough, or if you want to dig more into mdev. mdev as a device manager I think we have under control, the confusion is more in our current system behavior at boot. Cheers, Anders -- Anders Darander ChargeStorm AB / eStorm AB ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] busybox and mdev, how does it really work?
* Hans Beckérus hans.becke...@gmail.com [140121 13:12]: On Tue, Jan 21, 2014 at 12:10 PM, Hans Beckérus hans.becke...@gmail.com wrote: On Tue, Jan 21, 2014 at 11:23 AM, Anders Darander and...@chargestorm.se wrote: * Hans Beckérus hans.becke...@gmail.com [140121 11:05]: Things looked ok for a while, /dev was populated properly after boot and all necessary file systems / mount points were created. We were using an ext2 fs in RAM for mounting /. Now, we made a change to instead use a CPIO image compressed using xz and enabled the support in kernel to handle this. This is when our problems started :( Suddenly our system booted with just a very minimalistic /dev folder, containing basically only a few of the devices probed at boot time. So, the questions now are: - how was /dev populated before when there was no /etc/init.d/mdev? I haven't checked poky-tiny, or more specifically the kernel configurations for it. But based on the description that I cited above, I'd guess that poky-tiny has CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y enabled. Indeed (from our .config): CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y That would mean the the kernel itself were managing /dev for you when you were using ext2. Unfortunately, CONFIG_DEVTMPFS_MOUNT do only automount devmptfs on /dev if you're not in an initramfs (or initrd). Sounds reasonable. But, when moving from ext2.gz to cpio.xz, we still did not add any init script for mounting /dev, yet it is still created and populated? But only with a very limited set of devices. I guess there is a difference when the kernel mounts the cpio.xz image compared to expanding the ext2.gz in RAM with respect to how /dev is handled. But I am only guessing here. I'm running a slow build of poky-tiny on an overloaded machine... Maybe I can get back to those question in a while. Another thing, You say CONFIG_DEVTMPFS_MOUNT does *not* automount /dev if using the initrd scheme? But I think it did when using the compressed ext2 file system? How come /dev was mounted and populated automatically in the ext2 case but when we changed to cpio.xz things seem to break? This one can I at least answer. It's because that's how devmtpfs is implemented in the kernel. This option does not affect initramfs based booting, here the devtmpfs filesystem always needs to be mounted manually after the roots is mounted. quote taken from the help text of CONFIG_DEVMTPFS_MOUNT, see your kernel tree or e.g. http://cateee.net/lkddb/web-lkddb/DEVTMPFS_MOUNT.html Cheers, Anders -- Anders Darander ChargeStorm AB / eStorm AB ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] busybox and mdev, how does it really work?
On Tue, Jan 21, 2014 at 1:41 PM, Anders Darander and...@chargestorm.se wrote: * Hans Beckérus hans.becke...@gmail.com [140121 13:12]: On Tue, Jan 21, 2014 at 12:10 PM, Hans Beckérus hans.becke...@gmail.com wrote: On Tue, Jan 21, 2014 at 11:23 AM, Anders Darander and...@chargestorm.se wrote: * Hans Beckérus hans.becke...@gmail.com [140121 11:05]: Things looked ok for a while, /dev was populated properly after boot and all necessary file systems / mount points were created. We were using an ext2 fs in RAM for mounting /. Now, we made a change to instead use a CPIO image compressed using xz and enabled the support in kernel to handle this. This is when our problems started :( Suddenly our system booted with just a very minimalistic /dev folder, containing basically only a few of the devices probed at boot time. So, the questions now are: - how was /dev populated before when there was no /etc/init.d/mdev? I haven't checked poky-tiny, or more specifically the kernel configurations for it. But based on the description that I cited above, I'd guess that poky-tiny has CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y enabled. Indeed (from our .config): CONFIG_DEVTMPFS=y CONFIG_DEVTMPFS_MOUNT=y That would mean the the kernel itself were managing /dev for you when you were using ext2. Unfortunately, CONFIG_DEVTMPFS_MOUNT do only automount devmptfs on /dev if you're not in an initramfs (or initrd). Sounds reasonable. But, when moving from ext2.gz to cpio.xz, we still did not add any init script for mounting /dev, yet it is still created and populated? But only with a very limited set of devices. I guess there is a difference when the kernel mounts the cpio.xz image compared to expanding the ext2.gz in RAM with respect to how /dev is handled. But I am only guessing here. I'm running a slow build of poky-tiny on an overloaded machine... Maybe I can get back to those question in a while. No problem. Take your time ;) Another thing, You say CONFIG_DEVTMPFS_MOUNT does *not* automount /dev if using the initrd scheme? But I think it did when using the compressed ext2 file system? How come /dev was mounted and populated automatically in the ext2 case but when we changed to cpio.xz things seem to break? This one can I at least answer. It's because that's how devmtpfs is implemented in the kernel. This option does not affect initramfs based booting, here the devtmpfs filesystem always needs to be mounted manually after the roots is mounted. quote taken from the help text of CONFIG_DEVMTPFS_MOUNT, see your kernel tree or e.g. http://cateee.net/lkddb/web-lkddb/DEVTMPFS_MOUNT.html Well, I do not think this is absolutely true, or I have misunderstood something. But we do not *use* the initramfs scheme, we use initrd in both ext2 and cpio case. So, what from what I can tell we use the initrd scheme and /sbin/init. And if CONFIG_DEVMTPFS_MOUNT is only affected the initramfs scheme then it should work similar for initrd for both the ext2 and the cpio case, which obviously is not the case. Cheers, Anders -- Anders Darander ChargeStorm AB / eStorm AB ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Where's my 'thermal_zone'?
Hi Chris, On Thursday 16 January 2014 23:15:13 Chris Tapp wrote: I'm trying to find the cpu temperatures on a system running a cedartrail image built under Danny. /sys/thermal has thermal_cooling entries (four of which are CPU related), but not the thermal_zone entries I need to read the CPU temperatures. What do I need to do / add to get these in? This is probably more of a question for the meta-intel list since it's about a specific meta-intel BSP. I don't have an answer for your question but maybe someone on that list will. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Minutes: Yocto Project Technical Team Meeting - Tuesday, January 21, 2014 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US Canada).
Attendees: Vali, Stephen, Matthew, Paul, Jessica, ScottR, Cristian, Richard, Tom, MarkH, Saul, Ross, Beth, MichaelH, Nitin, AlexG, AlexD, Belen, Song Agenda: * Opens collection - 5 min (Song) * Yocto 1.6 status - 10 min (Song/team) https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.6_Status https://wiki.yoctoproject.org/wiki/Yocto_1.6_Features - Had a bug sprint week last week, resolved 26 bugs, better than we normally do. The WDD number is coming down a little. We stopped the trend, but did not make a huge dent on the bug numbers. - Planning a RC2 for M2, compared with RC1, it has a lot more changes, probably 80 or so. It's certainly not a small incremental changes. But no big features. Will have RC2 once we have the full pass report and the build appliance issue is fixed. - There was a small performance issue. We got a patch in for it, overall build time has been improved by 2 minutes. The patch queue is moving, looking good. - QA run full pass on RC1, report will be out soon. So far no major issues. - Saul: 1.4.3 Paul is looking in some issues, once resolved, will generate a build for QA. Looking at mid Feb release. * SWAT team rotation: Ross - Cristian * Opens - 10 min * Team Sharing - 20 min - Cristian: package upgrade and bug fix. Next step will work on feature related to HW testing. There are lots of change in communication and media stack. Vali would like to talk with Cristian. Paul: there are some talk regarding future direction. There is a mailing list for this, feel free to join.(https://lists.yoctoproject.org/listinfo/automated-testing) - Beth: switched over to new AB software. 3 and half hour rebuild/rootfs now, reduced by one hour. Need more run for an average. Removed YP blocker. Changed git. RP: package part won't start until non-package part completes. Still some improvement there. Beth is aware of that. - Michael: Replacing drives, continuing to refresh builders, Google compute engine available, looking into how that will work. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] Yocto Project Technical Team Meeting
BEGIN:VCALENDAR METHOD:REQUEST PRODID:Microsoft Exchange Server 2010 VERSION:2.0 BEGIN:VTIMEZONE TZID:Pacific Standard Time BEGIN:STANDARD DTSTART:16010101T02 TZOFFSETFROM:-0700 TZOFFSETTO:-0800 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11 END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T02 TZOFFSETFROM:-0800 TZOFFSETTO:-0700 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3 END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT ORGANIZER;CN=Jolley, Stephen K:MAILTO:stephen.k.jol...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Liu, Song: MAILTO:song@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Anders Da rander':MAILTO:and...@chargestorm.se ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Barros Pen a, Belen:MAILTO:belen.barros.p...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Ashfield, Bruce (Wind River):MAILTO:bruce.ashfi...@windriver.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Daniel Ca uchy':MAILTO:dcau...@mvista.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=DeVries, A lex (Wind River):MAILTO:alex.devr...@windriver.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Dixon, Br ad':MAILTO:brad_di...@mentor.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Dmytriyenk o, Denys:MAILTO:de...@ti.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Erway, Tra cey M:MAILTO:tracey.m.er...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Flanagan, Elizabeth:MAILTO:elizabeth.flana...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Hart, Darr en:MAILTO:darren.h...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Hatle, Mar k G (Wind River):MAILTO:mark.ha...@windriver.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Jeremy Pu hlman':MAILTO:jpuhl...@gmail.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Kridner, J ason:MAILTO:j...@ti.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Lieu.Ta@w indriver.com':MAILTO:'lieu...@windriver.com' ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Moeller, T horsten:MAILTO:thorsten.moel...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Sanjay Ra ina':MAILTO:sra...@mvista.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Osier-mixo n, Jeffrey:MAILTO:jeffrey.osier-mi...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Polk, Jeff rey (Wind River):MAILTO:jeff.p...@windriver.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Purdie, Ri chard:MAILTO:richard.pur...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Ranslam, R obert E (Wind River):MAILTO:rob.rans...@windriver.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Stewart, D avid C:MAILTO:david.c.stew...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Wold, Saul :MAILTO:saul.w...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Zanussi, T om:MAILTO:tom.zanu...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Zhang, Jes sica:MAILTO:jessica.zh...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Rifenbark, Scott M:MAILTO:scott.m.rifenb...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Hudson, S ean':MAILTO:sean_hud...@mentor.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Serban, La urentiu:MAILTO:laurentiu.ser...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Petrisor, Ileana:MAILTO:ileana.petri...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Damian, Al exandru:MAILTO:alexandru.dam...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Burton, Ro ss:MAILTO:ross.bur...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Mueller, R obert:MAILTO:robert.muel...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Arce Moren o, Abraham:MAILTO:abraham.arce.mor...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Ravi Vomp olu':MAILTO:ravi.vomp...@mathworks.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Sadiq, Ir fan':MAILTO:irfan_sa...@mentor.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Santana Lo pez, Mario A:MAILTO:mario.a.santana.lo...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Patel, Key ur R:MAILTO:keyur.r.pa...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='achaudha@ mvista.com':MAILTO:achau...@mvista.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Popa, Vale
[yocto] Canceled: Yocto Project Technical Team Meeting - cancelled, Stephen setup new ones
BEGIN:VCALENDAR METHOD:CANCEL PRODID:Microsoft Exchange Server 2010 VERSION:2.0 BEGIN:VTIMEZONE TZID:Pacific Standard Time BEGIN:STANDARD DTSTART:16010101T02 TZOFFSETFROM:-0700 TZOFFSETTO:-0800 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=1SU;BYMONTH=11 END:STANDARD BEGIN:DAYLIGHT DTSTART:16010101T02 TZOFFSETFROM:-0800 TZOFFSETTO:-0700 RRULE:FREQ=YEARLY;INTERVAL=1;BYDAY=2SU;BYMONTH=3 END:DAYLIGHT END:VTIMEZONE BEGIN:VEVENT ORGANIZER;CN=Liu, Song:MAILTO:song@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Anders Da rander':MAILTO:and...@chargestorm.se ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Barros Pen a, Belen:MAILTO:belen.barros.p...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Ashfield, Bruce (Wind River):MAILTO:bruce.ashfi...@windriver.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Daniel Ca uchy':MAILTO:dcau...@mvista.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=DeVries, A lex (Wind River):MAILTO:alex.devr...@windriver.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Dixon, Br ad':MAILTO:brad_di...@mentor.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Dmytriyenk o, Denys:MAILTO:de...@ti.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Erway, Tra cey M:MAILTO:tracey.m.er...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Flanagan, Elizabeth:MAILTO:elizabeth.flana...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Hart, Darr en:MAILTO:darren.h...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Hatle, Mar k G (Wind River):MAILTO:mark.ha...@windriver.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Jeremy Pu hlman':MAILTO:jpuhl...@gmail.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Kridner, J ason:MAILTO:j...@ti.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Lieu.Ta@w indriver.com':MAILTO:'lieu...@windriver.com' ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Moeller, T horsten:MAILTO:thorsten.moel...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Sanjay Ra ina':MAILTO:sra...@mvista.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Osier-mixo n, Jeffrey:MAILTO:jeffrey.osier-mi...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Polk, Jeff rey (Wind River):MAILTO:jeff.p...@windriver.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Purdie, Ri chard:MAILTO:richard.pur...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Ranslam, R obert E (Wind River):MAILTO:rob.rans...@windriver.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Stewart, D avid C:MAILTO:david.c.stew...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Wold, Saul :MAILTO:saul.w...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Zanussi, T om:MAILTO:tom.zanu...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Zhang, Jes sica:MAILTO:jessica.zh...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Rifenbark, Scott M:MAILTO:scott.m.rifenb...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Hudson, S ean':MAILTO:sean_hud...@mentor.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Serban, La urentiu:MAILTO:laurentiu.ser...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Petrisor, Ileana:MAILTO:ileana.petri...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Damian, Al exandru:MAILTO:alexandru.dam...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Burton, Ro ss:MAILTO:ross.bur...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Mueller, R obert:MAILTO:robert.muel...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Arce Moren o, Abraham:MAILTO:abraham.arce.mor...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Ravi Vomp olu':MAILTO:ravi.vomp...@mathworks.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='Sadiq, Ir fan':MAILTO:irfan_sa...@mentor.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Santana Lo pez, Mario A:MAILTO:mario.a.santana.lo...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Patel, Key ur R:MAILTO:keyur.r.pa...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN='achaudha@ mvista.com':MAILTO:achau...@mvista.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Popa, Vale ntin:MAILTO:valentin.p...@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=Moses, Fre
[yocto] [meta-selinux][PATCH] udev/init: fix the invalid binary path
From: Jackie Huang jackie.hu...@windriver.com The invalid binary path causes failure: udevd[102]: starting version 182 /etc/rcS.d/S04udev: line 106: /usr/bin/udevadm: No such file or directory use the command 'udevadm' directly in the init just as the oe-core one does. Signed-off-by: Jackie Huang jackie.hu...@windriver.com --- recipes-core/udev/udev/init | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/recipes-core/udev/udev/init b/recipes-core/udev/udev/init index a96638f..29146ec 100644 --- a/recipes-core/udev/udev/init +++ b/recipes-core/udev/udev/init @@ -103,13 +103,13 @@ case $1 in echo -e '\000\000\000\000' /proc/sys/kernel/hotplug @UDEVD@ -d -/usr/bin/udevadm control --env=STARTUP=1 +udevadm control --env=STARTUP=1 if [ $not_first_boot != ];then -/usr/bin/udevadm trigger --action=add --subsystem-nomatch=tty --subsystem-nomatch=mem --subsystem-nomatch=vc --subsystem-nomatch=vtconsole --subsystem-nomatch=misc --subsystem-nomatch=dcon --subsystem-nomatch=pci_bus --subsystem-nomatch=graphics --subsystem-nomatch=backlight --subsystem-nomatch=video4linux --subsystem-nomatch=platform -(/usr/bin/udevadm settle --timeout=10; /usr/bin/udevadm control --env=STARTUP=) +udevadm trigger --action=add --subsystem-nomatch=tty --subsystem-nomatch=mem --subsystem-nomatch=vc --subsystem-nomatch=vtconsole --subsystem-nomatch=misc --subsystem-nomatch=dcon --subsystem-nomatch=pci_bus --subsystem-nomatch=graphics --subsystem-nomatch=backlight --subsystem-nomatch=video4linux --subsystem-nomatch=platform +(udevadm settle --timeout=10; udevadm control --env=STARTUP=) else -/usr/bin/udevadm trigger --action=add -/usr/bin/udevadm settle +udevadm trigger --action=add +udevadm settle fi test ! -x /sbin/restorecon || /sbin/restorecon -F /dev -- 1.7.9.5 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
