[yocto] preserving file owners in do_package
Hi to all,
in my recipe I want to change owner and permission of a file, so I wrote:
do_install() {
ls -la ${D}/opt/user
chown -R user ${D}/opt/user
chgrp -R user ${D}/opt/user
ls -la ${D}/opt/user
chmod 754 ${D}/opt/user/user.sh
ls -la ${D}/opt/user
}
the output of ls commands is:
drwxr-xr-x 8 root root 4096 Oct 15 11:13 .
drwxr-xr-x 3 root root 4096 Oct 15 11:13 ..
-rw-r--r-- 1 *root root* 55753 Aug 2 08:48 user.sh
drwxr-xr-x 8 user user 4096 Oct 15 11:13 .
drwxr-xr-x 3 root root 4096 Oct 15 11:13 ..
-rw-r--r-- 1 *user user* 55753 Aug 2 08:48 user.sh
drwxr-xr-x 8 user user 4096 Oct 15 11:13 .
drwxr-xr-x 3 root root 4096 Oct 15 11:13 ..
*-rwxr-xr--* 1 user user 55753 Aug 2 08:48 user.sh
So the change of owner and permission works fine in do_install phase.
Opening the final rootfs tarball, however, the file user.sh has still 754
permission but root as owner...so do_package doesn't preserve owner change done
in do_install? Or maybe I'm doing something wrong in changing file owner? Any
ideas?
Thanks to all!
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] preserving file owners in do_package
Hi Davide,
On Tuesday 15 October 2013 12:02:20 Davide Soldan wrote:
in my recipe I want to change owner and permission of a file, so I wrote:
do_install() {
ls -la ${D}/opt/user
chown -R user ${D}/opt/user
chgrp -R user ${D}/opt/user
ls -la ${D}/opt/user
chmod 754 ${D}/opt/user/user.sh
ls -la ${D}/opt/user
}
the output of ls commands is:
drwxr-xr-x 8 root root 4096 Oct 15 11:13 .
drwxr-xr-x 3 root root 4096 Oct 15 11:13 ..
-rw-r--r-- 1 *root root* 55753 Aug 2 08:48 user.sh
drwxr-xr-x 8 user user 4096 Oct 15 11:13 .
drwxr-xr-x 3 root root 4096 Oct 15 11:13 ..
-rw-r--r-- 1 *user user* 55753 Aug 2 08:48 user.sh
drwxr-xr-x 8 user user 4096 Oct 15 11:13 .
drwxr-xr-x 3 root root 4096 Oct 15 11:13 ..
*-rwxr-xr--* 1 user user 55753 Aug 2 08:48 user.sh
So the change of owner and permission works fine in do_install phase.
Opening the final rootfs tarball, however, the file user.sh has still 754
permission but root as owner...so do_package doesn't preserve owner change
done in do_install? Or maybe I'm doing something wrong in changing file
owner? Any ideas? Thanks to all!
Does your recipe create the specified user via useradd.bbclass?
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] preserving file owners in do_package
In data martedì 15 ottobre 2013 11:38:21, Paul Eggleton ha scritto:
Hi Davide,
On Tuesday 15 October 2013 12:02:20 Davide Soldan wrote:
in my recipe I want to change owner and permission of a file, so I wrote:
do_install() {
ls -la ${D}/opt/user
chown -R user ${D}/opt/user
chgrp -R user ${D}/opt/user
ls -la ${D}/opt/user
chmod 754 ${D}/opt/user/user.sh
ls -la ${D}/opt/user
}
the output of ls commands is:
drwxr-xr-x 8 root root 4096 Oct 15 11:13 .
drwxr-xr-x 3 root root 4096 Oct 15 11:13 ..
-rw-r--r-- 1 *root root* 55753 Aug 2 08:48 user.sh
drwxr-xr-x 8 user user 4096 Oct 15 11:13 .
drwxr-xr-x 3 root root 4096 Oct 15 11:13 ..
-rw-r--r-- 1 *user user* 55753 Aug 2 08:48 user.sh
drwxr-xr-x 8 user user 4096 Oct 15 11:13 .
drwxr-xr-x 3 root root 4096 Oct 15 11:13 ..
*-rwxr-xr--* 1 user user 55753 Aug 2 08:48 user.sh
So the change of owner and permission works fine in do_install phase.
Opening the final rootfs tarball, however, the file user.sh has still 754
permission but root as owner...so do_package doesn't preserve owner change
done in do_install? Or maybe I'm doing something wrong in changing file
owner? Any ideas? Thanks to all!
Does your recipe create the specified user via useradd.bbclass?
Cheers,
Paul
Hi Paul,
I've got a useradd recipe (myuseradd.bbclass) that create that specific user.
Also in my recipe I've got the
DEPENDS = myuseradd
to be sure that the specific user is created before my recipe is processed.
Within myuseradd recipe I've got some chown command that works fine, but
outside that recipe I've got the problem stated in the previous mail...
Davide
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] trying a totally different way to teach OE/yocto in the classroom [LONG]
(WARNING: this post contains an unavoidable marketing component, but i'm more interested in feedback on what i want to try as a whole new way to teach OE/yoctoproject. and so, to work.) over the last while, i've taught a small number of OE/yocto courses to some commercial clients, and i've never been happy with the standard approach of writing a typical manual, having to lock it down shortly before the course to facilitate printing it, grappling with typesetting issues, worrying about how much sample code i can include without getting carried away and making a section too long, realizing partway through the course that what's in the manual is already out of date but the class is stuck with it as it's already in their manual, etc, etc, g. so i have another OE/yocto course coming up shortly and i'm going to try a totally different approach. i'm going to teach the entire course off of online wiki pages. rather than waste my time tweaking format and aesthetics for the paper manual i would normally give out, and *knowing* it will be out of date in short order, i'm going to use my existing and many additional wiki pages and build some structure around them, and spend the 4 days simply displaying wiki page after wiki page, and having students follow along with the countless code excerpts and sample commands they contain. at the risk of linking to a currently chaotic work-in-progress, here's my new top-level page: http://www.crashcourse.ca/wiki/index.php/OE which even contains an active TO DO list that is changing by the hour as i write/update existing pages, check off some items and add others. here's my take on why i'm trying this approach and its advantages in my opinion, and i'm interested in feedback. first, no messing with stupid paper manuals and worrying about fonts and spacing and aesthetics. it's a wiki page and i can immediately see what it looks like, and writing wiki pages is easy. and i've got lots to work with as a starting point. next, it's easy to update on *very* short notice. i used this approach for some sections in a different course a couple weeks back, and it worked very well for staying current. i literally, in the evenings, over lunch and even over a couple coffee breaks, snuck in updated or entirely new content when i noticed something had changed. and when i found a typo on a wiki page, i simply fixed it right in front of the class and moved on. no big deal. the biggest benefit in my opinion is that, now that i no longer have to worry about the length of the generated paper manual, i can be as verbose as i want on any wiki page, and include as much code and as many examples as i want until i feel i've made my point. i want to emphasize lots and lots and lots of code snippets from the OE/yocto source code. for example, here's a page in progress where i explain how to develop a new BSP: http://www.crashcourse.ca/wiki/index.php/OE_Developing_a_New_BSP if i was writing this for a regular paper manual, i'd be trying to skimp on the sample code i was including to not make the section too long. on the other hand, because it's a wiki page, who cares? if i want to include 500 lines of code because i think it's worth it, i'll include 500 lines of code -- i'll include as much as i need until i think i've made my point. if i want to demonstrate how intel defines the BSP for their crownbay, i will happily reproduce every single relevant file on the wiki page and walk through each one. finally, all of the pages will be totally publicly available, so not just the students but anyone is welcome to peruse them whenever they want. and students will know that if things change after they take the course, i'll do my best to update the wiki pages to keep up. no paper-based obsolescence. and the downside? well, there is one place i *would* skimp, and that's the normal, fluffy, arm-waving intro and connecting text for each topic that you normally find in a paper manual or official documentation. my plan is to be *very* terse -- i wouldn't invest a lot of time in trying to make this content readable from a standalone perspective. i would select a topic to write about, create a new page and just jump right into showing how to do it with sample commands and code excerpts. so even though all of the content would be publicly available, it wouldn't necessarily be *comprehensible* for an independent reader -- i would be writing it for the classroom. but i don't see that as a major drawback. in my experience, most techies aren't interested in filler. they just want to see the code and enough working examples to get the idea. and the plan is for the wiki pages to contain *lots* of sample commands and *lots* of source code ripped straight from the code base. anyway, i think i've rambled sufficiently so ... thoughts? comments? criticism? starting monday next week, i'm going to find out just how well this works as i do this for the first time at a client site. it should
Re: [yocto] preserving file owners in do_package
On Tuesday 15 October 2013 18:12:42 Davide Soldan wrote:
In data martedì 15 ottobre 2013 11:38:21, Paul Eggleton ha scritto:
On Tuesday 15 October 2013 12:02:20 Davide Soldan wrote:
in my recipe I want to change owner and permission of a file, so I
wrote:
do_install() {
ls -la ${D}/opt/user
chown -R user ${D}/opt/user
chgrp -R user ${D}/opt/user
ls -la ${D}/opt/user
chmod 754 ${D}/opt/user/user.sh
ls -la ${D}/opt/user
}
the output of ls commands is:
drwxr-xr-x 8 root root 4096 Oct 15 11:13 .
drwxr-xr-x 3 root root 4096 Oct 15 11:13 ..
-rw-r--r-- 1 *root root* 55753 Aug 2 08:48 user.sh
drwxr-xr-x 8 user user 4096 Oct 15 11:13 .
drwxr-xr-x 3 root root 4096 Oct 15 11:13 ..
-rw-r--r-- 1 *user user* 55753 Aug 2 08:48 user.sh
drwxr-xr-x 8 user user 4096 Oct 15 11:13 .
drwxr-xr-x 3 root root 4096 Oct 15 11:13 ..
*-rwxr-xr--* 1 user user 55753 Aug 2 08:48 user.sh
So the change of owner and permission works fine in do_install phase.
Opening the final rootfs tarball, however, the file user.sh has still
754
permission but root as owner...so do_package doesn't preserve owner
change
done in do_install? Or maybe I'm doing something wrong in changing file
owner? Any ideas? Thanks to all!
Does your recipe create the specified user via useradd.bbclass?
I solved with a postinstall script (that run at boot):
pkg_postinst_${PN}() {
#!/bin/sh -e
if [ x$D = x ]; then
chown -R user /opt/user
chgrp -R user /opt/user
else
exit 1
fi
}
This shouldn't be necessary though. I honestly can't tell you why it doesn't
work as specified. I think it might be worth filing a bug for this.
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] fetch from perforce
Hi, can someone please give me an example of fetching the code from perforce? I want to map files from perforce and put them in a different tree structure in the workspace before compiling it. I also need to set user and password. I failed to find an example online and I don't understand the perforce script enough to guess the way to call it. Thanks a lot, Katu ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] FW: Yocto Project 1.5 release readiness review
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=Liu, Song:MAILTO:song@intel.com ATTENDEE;ROLE=REQ-PARTICIPANT;PARTSTAT=NEEDS-ACTION;RSVP=TRUE;CN=yocto@yoct oproject.org:MAILTO:yocto@yoctoproject.org DESCRIPTION;LANGUAGE=en-US:\n\n-Original Appointment-\nFrom: Liu\, Song\nSent: Tuesday\, October 15\, 2013 1:38 PM\nTo: 'Anders Darander'\; B arros Pena\, Belen\; Bodke\, Kishore K\; 'Bruce Ashfield'\; 'Daniel Cauchy '\; 'deVries\, Alex'\; 'Dixon\, Brad'\; Dmytriyenko\, Denys\; Erway\, Trac ey M\; Flanagan\, Elizabeth\; Hart\, Darren\; 'Hatle\, Mark'\; 'Jeremy Puh lman'\; Kridner\, Jason\; 'lieu...@windriver.com'\; Lock\, Joshua\; Moelle r\, Thorsten\; 'Sanjay Raina'\; Osier-mixon\, Jeffrey\; 'Polk\, Jeffrey'\; Purdie\, Richard\; 'Ranslam\, Rob'\; Saxena\, Rahul\; Stewart\, David C\; Wold\, Saul\; Zanussi\, Tom\; Zhang\, Jessica\; Rifenbark\, Scott M\; 'Hu dson\, Sean'\; Serban\, Laurentiu\; Petrisor\, Ileana\; Damian\, Alexandru \; Burton\, Ross\; Mueller\, Robert\; Arce Moreno\, Abraham\; 'Ravi Vompol u'\; 'Sadiq\, Irfan'\; Santana Lopez\, Mario A\; Patel\, Keyur R\; 'achaud h...@mvista.com'\; Popa\, Valentin\; Moses\, Fred\; Iorga\, Cristian\; Palal au\, AlexandruX\; 'Butler\, Paul'\; Mirea\, Viorel\; Kamble\, Nitin A\; Sz ankin\, Maciej\; Moisan\, Radu\; Grigoropol\, IoanaX\; Olivia Salisbury\; 'Chris Kaminski'\; 'Maupin\, Chase'\; Georgescu\, Alexandru C\; Gavaz\, Io nut A\; Pruteanu\, Codrin C\; Letnes\, Thaddeus C\; Ong\, Boon Leong\; Seo w\, Chen Yong\; Haw\, Foo Chien\; steve.l...@windriver.com\; Stoicescu\, C orneliuX\; 'Chris Kaminski'\; Voicu\, Cristiana\; Chisanovici\, IonutX\nSu bject: Yocto Project 1.5 release readiness review\nWhen: Wednesday\, Octob er 16\, 2013 7:30 AM-8:00 AM (UTC-08:00) Pacific Time (US Canada).\nWher e: 916-356-2663\, 8-356-2663\, Bridge: 1\, Passcode: 1070690\n\n\nhttps:// wiki.yoctoproject.org/wiki/Yocto_Project_v1.5_Status#Milestone_5.2C_1.5_re leasehttps://wiki.yoctoproject.org/wiki/Yocto_Project_v1.5_Status\n\n\nW ednesday\, October 16\, 2013\, 07:30 AM US Pacific Time\n916-356-2663\, 8- 356-2663\, Bridge: 1\, Passcode: 1070690\nSpeed dialer: inteldialer://1\,1 070690 | Learn morehttp://it.intel.com/products/handhelds/speeddial.htm\ n\n SUMMARY;LANGUAGE=en-US:FW: Yocto Project 1.5 release readiness review DTSTART;TZID=Pacific Standard Time:20131016T073000 DTEND;TZID=Pacific Standard Time:20131016T08 UID:04008200E00074C5B7101A82E00840C6E92BA9C9CE01000 01000E8C5B41D11BBB24D94E66947B67CB42A CLASS:PUBLIC PRIORITY:5 DTSTAMP:20131015T203755Z TRANSP:OPAQUE STATUS:CONFIRMED SEQUENCE:0 LOCATION;LANGUAGE=en-US:916-356-2663\, 8-356-2663\, Bridge: 1\, Passcode: 1 070690 X-MICROSOFT-CDO-APPT-SEQUENCE:0 X-MICROSOFT-CDO-OWNERAPPTID:1915725789 X-MICROSOFT-CDO-BUSYSTATUS:TENTATIVE X-MICROSOFT-CDO-INTENDEDSTATUS:BUSY X-MICROSOFT-CDO-ALLDAYEVENT:FALSE X-MICROSOFT-CDO-IMPORTANCE:1 X-MICROSOFT-CDO-INSTTYPE:0 X-MICROSOFT-DISALLOW-COUNTER:FALSE BEGIN:VALARM ACTION:DISPLAY DESCRIPTION:REMINDER TRIGGER;RELATED=START:-PT15M END:VALARM END:VEVENT END:VCALENDAR ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] [Meta-security][PATCH V3 1/3] snort : add recipe
Hi Chunrong, [Re: [yocto] [Meta-security][PATCH V3 1/3] snort : add recipe] On 13.10.10 (Thu 08:19) Guo Chunrong-B40290 wrote: Hello, all Please give me some comments. The meta-security maintainer and I have discussed this at length and we're in agreement that for the time being it's probably appropriate to have this in meta-networking rather than meta-security. I haven't had a chance to go back over this but I think somewhere along the way a few of the earlier comments was lost (I don't see Khem's suggestion addressed in the latest meta-security, for example). Can you do another round of this, ensuring you've addressed the comments (either by incorporating the suggestions or addressing why you think they aren't appropriate here) and send this back for inclusion in meta-networking? I think you'd also had some out-of-band info from the meta-security maintainer that the PERL dependencies listed in the recipes may be over-zealous, can you take a quick pass at reducing them to a somewhat more minimal set before sending a new version? Thanks, -Joe. Thanks chunrong -Original Message- From: Guo Chunrong-B40290 Sent: Thursday, September 26, 2013 11:26 AM To: yocto@yoctoproject.org Cc: Liu Ting-B28495; Luo Zhenhua-B19537; Guo Chunrong-B40290; Guo Chunrong-B40290 Subject: [Meta-security][PATCH V3 1/3] snort : add recipe From: Chunrong Guo b40...@freescale.com *snort - a free lightweight network intrusion detection system for UNIX and Windows Signed-off-by: Chunrong Guo b40...@freescale.com --- recipes-security/snort/files/default | 42 ++ .../snort/files/disable-dap-address-space-id.patch | 52 +++ .../snort/files/disable-inaddr-none.patch | 75 recipes-security/snort/files/logrotate | 12 + recipes-security/snort/files/snort.init| 425 recipes-security/snort/files/volatiles |2 + recipes-security/snort/snort_2.9.4.6.bb| 83 7 files changed, 691 insertions(+), 0 deletions(-) create mode 100644 recipes-security/snort/files/default create mode 100644 recipes-security/snort/files/disable-dap-address-space-id.patch create mode 100644 recipes-security/snort/files/disable-inaddr-none.patch create mode 100644 recipes-security/snort/files/logrotate create mode 100755 recipes-security/snort/files/snort.init create mode 100644 recipes-security/snort/files/volatiles create mode 100644 recipes-security/snort/snort_2.9.4.6.bb diff --git a/recipes-security/snort/files/default b/recipes-security/snort/files/default new file mode 100644 index 000..afd3840 --- /dev/null +++ b/recipes-security/snort/files/default @@ -0,0 +1,42 @@ +# Parameters for the daemon +# Add any additional parameteres here. +PARAMS=-m 027 -D -d +# +# Snort user +# This user will be used to launch snort. Notice that the # preinst +script of the package might do changes to the user # (home directory, +User Name) when the package is upgraded or # reinstalled. So, do *not* +change this to 'root' or to any other user # unless you are sure there +is no problem with those changes being introduced. +# +SNORTUSER=snort +# +# Logging directory +# Snort logs will be dropped here and this will be the home # directory +for the SNORTUSER. If you change this value you should # change the +/etc/logrotate.d/snort definition too, otherwise logs # will not be +rotated properly. +# +LOGDIR=/var/log/snort +# +# Snort group +# This is the group that the snort user will be added to. +# +SNORTGROUP=snort +# +# Allow Snort's init.d script to work if the configured interfaces # +are not available. Set this to yes if you configure Snort with # +multiple interfaces but some might not be available on boot # (e.g. +wireless interfaces) # # Note: In order for this to work the 'iproute' +package needs to # be installed. +ALLOW_UNAVAILABLE=no + +# Local configs +# +LOCAL_SNORT_STARTUP=boot +LOCAL_SNORT_HOME_NET=192.168.0.0/16 +LOCAL_SNORT_INTERFACE= +LOCAL_SNORT_STATS_RCPT=root +LOCAL_SNORT_STATS_THRESHOLD=1 diff --git a/recipes-security/snort/files/disable-dap-address-space-id.patch b/recipes-security/snort/files/disable-dap-address-space-id.patch new file mode 100644 index 000..39e5c9c --- /dev/null +++ b/recipes-security/snort/files/disable-dap-address-space-id.patch @@ -0,0 +1,52 @@ +Upstream-Status:Inappropriate [embedded specific] + +fix the below error: +checking for dap address space id... configure: +configure: error: cannot run test program while cross compiling + + +Signed-off-by: Chunrong Guo b40...@freescale.com + +--- a/configure.in 2013-08-23 00:06:37.239361932 -0500 b/configure.in 2013-08-23 00:07:32.860266534 -0500 +@@ -679,23 +679,23 @@ + + AC_CHECK_FUNCS([daq_hup_apply] [daq_acquire_with_meta]) + +-AC_MSG_CHECKING([for daq address space ID]) -AC_RUN_IFELSE(
[yocto] Custom defconfig is not used
Folks,
I created the following bbapend recipe for linux-mainline_3.8.bb (from
meta-beagleboard on dylan branch) for beaglebone.
meta-mine/recipes-kernel/linux/linux-mainline_3.8.bbappend:
FILESEXTRAPATHS_prepend := ${THISDIR}/files:
SRC_URI += file://0019-mine.patch \
file://defconfig \
But the defconfig and .config files on ${S} and ${WORKDIR} used are from
meta-beagleboad, not from my bbappend.
I tried to follow the instructions to add config fragments on the page
below but it did not worked too.
http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html#changing-the-configuration
The strange thing is: My patch is applied but my defconfig, or config
fragment is not used.
I just want to add CONFIG_WATCHDOG_NOWAYOUT=y.
I already did a cleasstate but no success.
Any hints?
Regards,
--
*dS
Diego Sueiro
/*long live rock 'n roll*/
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Custom defconfig is not used
Hi Diego,
I may be wrong here, but I had a similar issue and I gave up. As I
understand from
https://www.yoctoproject.org/sites/yoctoproject.org/files/elc2013-kernel-lab.pdf
if you are not using the linux-yocto kernel you need the whole defconfig.
Anyway, reading the kernel lab is probably a good idea.
good luck,
Katu
2013/10/15 Diego Sueiro diego.sue...@gmail.com
Folks,
I created the following bbapend recipe for linux-mainline_3.8.bb (from
meta-beagleboard on dylan branch) for beaglebone.
meta-mine/recipes-kernel/linux/linux-mainline_3.8.bbappend:
FILESEXTRAPATHS_prepend := ${THISDIR}/files:
SRC_URI += file://0019-mine.patch \
file://defconfig \
But the defconfig and .config files on ${S} and ${WORKDIR} used are from
meta-beagleboad, not from my bbappend.
I tried to follow the instructions to add config fragments on the page
below but it did not worked too.
http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html#changing-the-configuration
The strange thing is: My patch is applied but my defconfig, or config
fragment is not used.
I just want to add CONFIG_WATCHDOG_NOWAYOUT=y.
I already did a cleasstate but no success.
Any hints?
Regards,
--
*dS
Diego Sueiro
/*long live rock 'n roll*/
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Custom defconfig is not used
Diego,
You are appending a kernel recipe that uses the Linux Yocto tooling. The
defconfig is essentially comprised of many different pieces from the meta
branch of the Yocto kernel repository and optional configuration fragments
that you provide. This tooling will not recognize a defconfig file you
provide but it does recognize configuration fragments to be added to
.config.
You need to put
CONFIG_WATCHDOG_NOWAYOUT=y
into a file that ends with .cfg eg. watchdog.cfg and then modify your
bbappend to
FILESEXTRAPATHS_prepend := ${THISDIR}/files:
SRC_URI += file://0019-mine.patch \
file://watchdog.cfg \
Rudi
On Tue, Oct 15, 2013 at 2:07 PM, Diego Sueiro diego.sue...@gmail.comwrote:
Folks,
I created the following bbapend recipe for linux-mainline_3.8.bb (from
meta-beagleboard on dylan branch) for beaglebone.
meta-mine/recipes-kernel/linux/linux-mainline_3.8.bbappend:
FILESEXTRAPATHS_prepend := ${THISDIR}/files:
SRC_URI += file://0019-mine.patch \
file://defconfig \
But the defconfig and .config files on ${S} and ${WORKDIR} used are from
meta-beagleboad, not from my bbappend.
I tried to follow the instructions to add config fragments on the page
below but it did not worked too.
http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html#changing-the-configuration
The strange thing is: My patch is applied but my defconfig, or config
fragment is not used.
I just want to add CONFIG_WATCHDOG_NOWAYOUT=y.
I already did a cleasstate but no success.
Any hints?
Regards,
--
*dS
Diego Sueiro
/*long live rock 'n roll*/
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] preserving file owners in do_package
On Tuesday 15 October 2013 17:18:35 Paul Eggleton wrote:
On Tuesday 15 October 2013 18:12:42 Davide Soldan wrote:
In data martedì 15 ottobre 2013 11:38:21, Paul Eggleton ha scritto:
On Tuesday 15 October 2013 12:02:20 Davide Soldan wrote:
in my recipe I want to change owner and permission of a file, so I
wrote:
do_install() {
ls -la ${D}/opt/user
chown -R user ${D}/opt/user
chgrp -R user ${D}/opt/user
ls -la ${D}/opt/user
chmod 754 ${D}/opt/user/user.sh
ls -la ${D}/opt/user
}
the output of ls commands is:
drwxr-xr-x 8 root root 4096 Oct 15 11:13 .
drwxr-xr-x 3 root root 4096 Oct 15 11:13 ..
-rw-r--r-- 1 *root root* 55753 Aug 2 08:48 user.sh
drwxr-xr-x 8 user user 4096 Oct 15 11:13 .
drwxr-xr-x 3 root root 4096 Oct 15 11:13 ..
-rw-r--r-- 1 *user user* 55753 Aug 2 08:48 user.sh
drwxr-xr-x 8 user user 4096 Oct 15 11:13 .
drwxr-xr-x 3 root root 4096 Oct 15 11:13 ..
*-rwxr-xr--* 1 user user 55753 Aug 2 08:48 user.sh
So the change of owner and permission works fine in do_install phase.
Opening the final rootfs tarball, however, the file user.sh has still
754
permission but root as owner...so do_package doesn't preserve owner
change
done in do_install? Or maybe I'm doing something wrong in changing
file
owner? Any ideas? Thanks to all!
Does your recipe create the specified user via useradd.bbclass?
I solved with a postinstall script (that run at boot):
pkg_postinst_${PN}() {
#!/bin/sh -e
if [ x$D = x ]; then
chown -R user /opt/user
chgrp -R user /opt/user
else
exit 1
fi
}
This shouldn't be necessary though. I honestly can't tell you why it doesn't
work as specified. I think it might be worth filing a bug for this.
Actually, thinking about it I don't think this is expected to work. Typically,
recipes that need a specific user to exist use useradd.bbclass themselves
rather than depending upon another recipe that does it. However, if you do
need to do it in a separate recipe (e.g. because multiple recipes use the same
user account), just adding the other recipe to DEPENDS does not guarantee that
it will be around at runtime - the actual package generated by the other
recipe (usually the same name) would need to be added to RDEPENDS_${PN}.
Additionally, if you do this, you should be able to have your postinstall
script run at all times; it should not need to be guarded to run only on the
target (although https://bugzilla.yoctoproject.org/show_bug.cgi?id=5318 may
interfere with this if you are using ipk or deb.)
Cheers,
Paul
--
Paul Eggleton
Intel Open Source Technology Centre
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Custom defconfig is not used
Hi,
I guess you're setting a wrong FILESEXTRAPATHS_prepend := ${THISDIR}/files:
See this example, using simple defconfig for some devices and an
experimental configuration (WIP ;) fo others using fragments.
http://cgit.openembedded.org/meta-handheld/tree/recipes-kernel/linux/linux-yocto_3.10.bbappend
Cheers
Andrea
On Tue, Oct 15, 2013 at 11:49 PM, Rudolf Streif
rstr...@linuxfoundation.org wrote:
Diego,
You are appending a kernel recipe that uses the Linux Yocto tooling. The
defconfig is essentially comprised of many different pieces from the meta
branch of the Yocto kernel repository and optional configuration fragments
that you provide. This tooling will not recognize a defconfig file you
provide but it does recognize configuration fragments to be added to
.config.
You need to put
CONFIG_WATCHDOG_NOWAYOUT=y
into a file that ends with .cfg eg. watchdog.cfg and then modify your
bbappend to
FILESEXTRAPATHS_prepend := ${THISDIR}/files:
SRC_URI += file://0019-mine.patch \
file://watchdog.cfg \
Rudi
On Tue, Oct 15, 2013 at 2:07 PM, Diego Sueiro diego.sue...@gmail.com
wrote:
Folks,
I created the following bbapend recipe for linux-mainline_3.8.bb (from
meta-beagleboard on dylan branch) for beaglebone.
meta-mine/recipes-kernel/linux/linux-mainline_3.8.bbappend:
FILESEXTRAPATHS_prepend := ${THISDIR}/files:
SRC_URI += file://0019-mine.patch \
file://defconfig \
But the defconfig and .config files on ${S} and ${WORKDIR} used are from
meta-beagleboad, not from my bbappend.
I tried to follow the instructions to add config fragments on the page
below but it did not worked too.
http://www.yoctoproject.org/docs/current/kernel-dev/kernel-dev.html#changing-the-configuration
The strange thing is: My patch is applied but my defconfig, or config
fragment is not used.
I just want to add CONFIG_WATCHDOG_NOWAYOUT=y.
I already did a cleasstate but no success.
Any hints?
Regards,
--
*dS
Diego Sueiro
/*long live rock 'n roll*/
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
[yocto] Minutes: Yocto Project Technical Team Meeting - Tuesday, October 15, 2013 8:00 AM-9:00 AM (UTC-08:00) Pacific Time (US Canada).
Attendees: Nitin, Cristian, AlexG, Matthew, Paul, ScottR, Saul, TomZ, JeffP, Richard, Jessica, Ross, Mark, MichaelH, Beth, Denys, Darren, Song Agenda: * Opens collection - 5 min (Song) * Yocto 1.5 status - 10 min (Song/team) https://wiki.yoctoproject.org/charts/combo.html https://wiki.yoctoproject.org/wiki/Yocto_Project_v1.5_Status . We had a 1.5 RC build last week. Likely to be our last 1.5 RC. QA is running full pass on it. Had some problems with ADT, ADT got rebuilt, issues are not release blockers. . WDD stabilized, performance seem fine so far. . Will schedule 1.5 release readiness meeting for Wednesday morning U.S. pacific time. . There are patches for the tar issue in master., * SWAT team rotation: Saul - Cristian Iorga * Opens - 10 min - Jessica: Toaster . Code name for webhob. Due to issues of webhob, it did not manage to go in for 1.5. We will release to the community to give people early access. It's a standalone release targeting first week of November. . ScottR: have a clean name change throughout the code and docs. Code, directory, wiki have been changed. Mailing list needs to be changed. (Michael will do that). Needs to announce it for others to change the filters before changing the name. A couple of days to change this. Thanks, Michael! * Team Sharing - 20 min - Mark: preparing for the ELCE, presentation is on SPDX Yocto project. U of Omaha, created a project using fossology. Doing testing for this presentation. Working well, approaching the point of being usable. Fossology server is quite slow. Progress has been made. If you are interested, please let me or Beth know. Prototype of SPDX generation is in 1.5. - RP: strange issue with for bug #5133, gcc garage collector had some issues. Got this issue nailed down. - Corneliu: There was an intern who finished his work a few months ago. A light weight web interface for HOB, he's working on his project and he likes what he is doing. New user oriented mainly. Hope we can give him some help. He's not on the mailing list. Encouraging him to get on the mailing list. - Michael: prep work on infrastructure switching is taking backseat due to dev day prep. Working on build time chart. ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] fetch from perforce
Hi Katu, On Tuesday 15 October 2013 20:52:15 Katu Txakur wrote: can someone please give me an example of fetching the code from perforce? I want to map files from perforce and put them in a different tree structure in the workspace before compiling it. I also need to set user and password. I failed to find an example online and I don't understand the perforce script enough to guess the way to call it. I have zero experience with perforce or fetching from it with a recipe, but looking at the fetcher code (bitbake/lib/bb/fetch2/perforce.py) it looks like the SRC_URI syntax is: p4://user:password:host:port@path Unfortunately it looks like you also need to set FETCHCOMMAND_p4 in your configuration as well since there is no default for this. Something like /usr/bin/env p4 might work. Cheers, Paul -- Paul Eggleton Intel Open Source Technology Centre ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
