I am not sure but any change to Linux kernel repo can be reflected by modifying the SRCREV variable in Kernel recipe file.
Thanks Rajan On Mon, Nov 25, 2013 at 10:37 PM, <yocto-requ...@yoctoproject.org> wrote: > Send yocto mailing list submissions to > yocto@yoctoproject.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.yoctoproject.org/listinfo/yocto > or, via email, send a message with subject or body 'help' to > yocto-requ...@yoctoproject.org > > You can reach the person managing the list at > yocto-ow...@yoctoproject.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of yocto digest..." > > > Today's Topics: > > 1. Unable to upgrade kernel; package for kernel name includes > version (Bryan Evenson) > 2. Re: ksize.py and dirsize.py scripts not in dora tarball, is > that deliberate? (Rifenbark, Scott M) > 3. Re: RFC Autobuilder Naming (Paul Eggleton) > 4. Re: unbootable image produced with PACKAGE_CLASSES ?= > "package_ipk", /etc missing (Todd Stellanova) > 5. FW: stupid question about post-installation scripts > (Rifenbark, Scott M) > 6. Re: stupid question about post-installation scripts > (Bryan Evenson) > 7. Re: Unable to upgrade kernel; package for kernel name > includes version (Bryan Evenson) > 8. Re: FW: stupid question about post-installation scripts > (Paul Eggleton) > 9. Re: FW: stupid question about post-installation scripts > (Paul Eggleton) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 25 Nov 2013 09:45:51 -0500 > From: Bryan Evenson <beven...@melinkcorp.com> > To: "yocto@yoctoproject.org" <yocto@yoctoproject.org> > Subject: [yocto] Unable to upgrade kernel; package for kernel name > includes version > Message-ID: > > <91586D499ADFD74FBCFB8425266A5DE40153C1156010@pluto.melinkcorp.local> > Content-Type: text/plain; charset="us-ascii" > > I'm on poky/dylan-9.0.1 I am upgrading the Linux kernel for my device's > image from a custom 3.6.9 kernel to a custom 3.10 kernel. I'm using this > layer: https://github.com/evensonbryan/meta-atmel as a basis for the > custom kernel recipe (there is a recipe for the 3.10 kernel that I haven't > yet deployed to Github in case anyone is wondering). I'm attempting to do > a firmware upgrade with my built packages (using opkg for package > management) and I've discovered an issue with the kernel naming. On my > pre-upgraded device, a list of installed packages includes: > > kernel-devicetree > kernel-image-3.6.9-yocto-standard > > So when I build my updated Linux kernel, the kernel image is now named > "kernel-image-3.10.0-yocto-standard". So when I attempt to do an upgrade, > the kernel-devicetree is upgraded just fine but the kernel image is not; > kernel-image-3.10.0-yocto-standard is not the same package as > kernel-image-3.6.9-yocto-standard, so opkg does not see this as an upgrade. > > How do I force the packaging system to recognize that the new kernel is an > upgrade of the old kernel, even though the packages have different names? > And for the future, how do I change the package name so that it doesn't > include the version? > > Thanks, > Bryan > > > > > > ------------------------------ > > Message: 2 > Date: Mon, 25 Nov 2013 14:52:00 +0000 > From: "Rifenbark, Scott M" <scott.m.rifenb...@intel.com> > To: "Robert P. J. Day" <rpj...@crashcourse.ca>, Yocto discussion list > <yocto@yoctoproject.org> > Subject: Re: [yocto] ksize.py and dirsize.py scripts not in dora > tarball, is that deliberate? > Message-ID: > < > 41dea4b02dbdef40a0f3b6d0ddb1237983f51...@orsmsx101.amr.corp.intel.com> > > Content-Type: text/plain; charset="us-ascii" > > Hmm... did these not get included in poky during the release? > > Scott > > >-----Original Message----- > >From: yocto-boun...@yoctoproject.org [mailto:yocto- > >boun...@yoctoproject.org] On Behalf Of Robert P. J. Day > >Sent: Saturday, November 23, 2013 2:59 AM > >To: Yocto discussion list > >Subject: [yocto] ksize.py and dirsize.py scripts not in dora tarball, is > that > >deliberate? > > > > > > current dev manual: > > > >http://www.yoctoproject.org/docs/latest/dev-manual/dev- > >manual.html#understand-what-gives-your-image-size > > > >claims: > > > >"To help you see where you currently are with kernel and root filesystem > >sizes, you can use two tools found in the Source Directory in the scripts > >directory: > > > >ksize.py: Reports component sizes for the kernel build objects. > > > >dirsize.py: Reports component sizes for the root filesystem." > > > > however, the current dora tarball doesn't contain these scripts, while > oe- > >core contains them more specifically under the scripts/tiny/ subdirectory. > >thoughts? > > > >rday > > > >-- > > > >=========================================================== > >============= > >Robert P. J. Day Ottawa, Ontario, CANADA > > http://crashcourse.ca > > > >Twitter: http://twitter.com/rpjday > >LinkedIn: http://ca.linkedin.com/in/rpjday > >=========================================================== > >============= > >_______________________________________________ > >yocto mailing list > >yocto@yoctoproject.org > >https://lists.yoctoproject.org/listinfo/yocto > > > ------------------------------ > > Message: 3 > Date: Mon, 25 Nov 2013 15:01:29 +0000 > From: Paul Eggleton <paul.eggle...@linux.intel.com> > To: Michael Halstead <mich...@yoctoproject.org> > Cc: yocto@yoctoproject.org > Subject: Re: [yocto] RFC Autobuilder Naming > Message-ID: <6760837.T0hJxS54r8@helios> > Content-Type: text/plain; charset="us-ascii" > > Hi Michael, > > On Friday 22 November 2013 15:43:58 Michael Halstead wrote: > > Currently all builders are simply named ab00-ab13 based on when we > > acquired them. The name doesn't change except for ab01 which has been > > reused on new hardware. As we increase the number of builders and make > > the build process more flexible this becomes inconvenient. I'd like to > > switch to embedding useful information in the name. > > > > Going forward as I refresh builders I'd like to name them with their > > distro and location. > > > > For example at OSL: > > > > fedora19.osl.yoctoproject.org > > fedora20.osl.yoctoproject.org > > opensuse131.osl.yoctoproject.org > > ubuntu1310.osl.yoctoproject.org > > etc. > > > > And if we added a build clusters in the EasyStreet datacenter in > Portland: > > > > centos64.pdx.yoctoproject.org > > debian7.pdx.yoctoproject.org > > etc. > > > > This allows for additional build clusters to be added and makes the > > distro clear to anyone viewing the logs. The current available build > > slaves can be found on the relevant cluster's buildbot interface > > (http://autobuilder.yoctoproject.org/main/buildslaves) so as names > > change there is an easy place to look them up. > > > > Comments? > > I guess this works fine until you want to have two builders with the same > distro. Maybe we plan not to do that anymore...? > > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre > > > ------------------------------ > > Message: 4 > Date: Mon, 25 Nov 2013 07:03:34 -0800 > From: Todd Stellanova <tstellan...@gmail.com> > To: Paul Eggleton <paul.eggle...@linux.intel.com> > Cc: "yocto@yoctoproject.org" <yocto@yoctoproject.org> > Subject: Re: [yocto] unbootable image produced with PACKAGE_CLASSES ?= > "package_ipk", /etc missing > Message-ID: <fdc4f28a-69cb-406f-95ea-0a5d2ab80...@gmail.com> > Content-Type: text/plain; charset=us-ascii > > Thanks for the ideas. I'll try creating a new build folder. If that still > shows the problem, I'm thinking this has something to do with the fact that > I'm running the build inside a vm (inside an Ubuntu vm running on a Mac). > It looks like the build is using debugfs...maybe it's running out of ram at > some point and not obtaining more in the vm properly? > > > On Nov 25, 2013, at 5:21 AM, Paul Eggleton < > paul.eggle...@linux.intel.com> wrote: > > > > Hi Nicolas / Todd, > > > >> On Monday 25 November 2013 11:31:42 Nicolas Dechesne wrote: > >> On Sun, Nov 24, 2013 at 3:51 AM, Todd Stellanova > >> <tstellan...@gmail.com>wrote: > >>> It appears that copying the files to the ext3 / sdcard image is > failing in > >>> *populate-extfs.sh* > >>> I see a series of these errors: > >>> > >>> *copy_file: Could not allocate block in ext2 filesystem* > >>> > >>> Any idea what might cause this? I've verified that the initial .tar > >>> archive and the bz2 contain the right files. > >> > >> can you try to create a new <build> folder (do not remove the current > one > >> for now) and reuse the downloads and sstate folder? i am wondering if > there > >> is a bug when trying to change PACKAGE_CLASSES in an existing <build> > >> folder. > > > > I do this not infrequently and never hit a problem like this, so I doubt > this > > is the case. > > > > Either there is a problem in how the filesystem is being set up (block > sizes, > > etc.) or there is some kind of corruption occurring. > > > > Cheers, > > Paul > > > > -- > > > > Paul Eggleton > > Intel Open Source Technology Centre > > > ------------------------------ > > Message: 5 > Date: Mon, 25 Nov 2013 15:21:41 +0000 > From: "Rifenbark, Scott M" <scott.m.rifenb...@intel.com> > To: "Robert P. J. Day" <rpj...@crashcourse.ca> > Cc: Yocto discussion list <yocto@yoctoproject.org> > Subject: [yocto] FW: stupid question about post-installation scripts > Message-ID: > < > 41dea4b02dbdef40a0f3b6d0ddb1237983f51...@orsmsx101.amr.corp.intel.com> > > Content-Type: text/plain; charset="us-ascii" > > Robert, > > I don't know... I am forwarding to the discussion list. > > Scott > > >-----Original Message----- > >From: Robert P. J. Day [mailto:rpj...@crashcourse.ca] > >Sent: Sunday, November 24, 2013 2:37 AM > >To: Rifenbark, Scott M > >Subject: stupid question about post-installation scripts > > > > > > when one defines pkg_postinst scripts, are those scripts invoked at > >*both* root filesystem creation time and first boot time? so that one > needs to > >manually check the value of ${D} to decide whether to run them, say, at > first > >boot time? > > > > i'm reading the section here: > > > >http://www.yoctoproject.org/docs/latest/dev-manual/dev- > >manual.html#post-installation-scripts > > > >and i know i've seen elsewhere scripts explicitly checking the value of > the ${D} > >prefix to determine when they're being invoked. it *seems* like that's > what's > >happening, but if that's the case, it can probably be said much more > clearly. > > > >rday > > > ------------------------------ > > Message: 6 > Date: Mon, 25 Nov 2013 10:56:17 -0500 > From: Bryan Evenson <beven...@melinkcorp.com> > To: "Rifenbark, Scott M" <scott.m.rifenb...@intel.com>, "Robert P. J. > Day" <rpj...@crashcourse.ca> > Cc: Yocto discussion list <yocto@yoctoproject.org> > Subject: Re: [yocto] stupid question about post-installation scripts > Message-ID: > > <91586D499ADFD74FBCFB8425266A5DE40153C1156096@pluto.melinkcorp.local> > Content-Type: text/plain; charset="us-ascii" > > Robert, > > That's how it works in my experience. I have some packages for my system > that have a postinst piece that needs to run during image creation, and > other pieces that need to run only on a package upgrade. By checking > whether "x${D}" = "${D}", I am filtering out whether the postinst script is > running during image creation or on the actual hardware. Been working > great so far. > > -Bryan > > > -----Original Message----- > > From: yocto-boun...@yoctoproject.org [mailto:yocto- > > boun...@yoctoproject.org] On Behalf Of Rifenbark, Scott M > > Sent: Monday, November 25, 2013 10:22 AM > > To: Robert P. J. Day > > Cc: Yocto discussion list > > Subject: [yocto] FW: stupid question about post-installation scripts > > > > Robert, > > > > I don't know... I am forwarding to the discussion list. > > > > Scott > > > > >-----Original Message----- > > >From: Robert P. J. Day [mailto:rpj...@crashcourse.ca] > > >Sent: Sunday, November 24, 2013 2:37 AM > > >To: Rifenbark, Scott M > > >Subject: stupid question about post-installation scripts > > > > > > > > > when one defines pkg_postinst scripts, are those scripts invoked at > > >*both* root filesystem creation time and first boot time? so that one > > >needs to manually check the value of ${D} to decide whether to run > > >them, say, at first boot time? > > > > > > i'm reading the section here: > > > > > >http://www.yoctoproject.org/docs/latest/dev-manual/dev- > > >manual.html#post-installation-scripts > > > > > >and i know i've seen elsewhere scripts explicitly checking the value > > of > > >the ${D} prefix to determine when they're being invoked. it *seems* > > >like that's what's happening, but if that's the case, it can probably > > be said much more clearly. > > > > > >rday > > _______________________________________________ > > yocto mailing list > > yocto@yoctoproject.org > > https://lists.yoctoproject.org/listinfo/yocto > > > ------------------------------ > > Message: 7 > Date: Mon, 25 Nov 2013 11:35:47 -0500 > From: Bryan Evenson <beven...@melinkcorp.com> > To: Bryan Evenson <beven...@melinkcorp.com>, "yocto@yoctoproject.org" > <yocto@yoctoproject.org> > Subject: Re: [yocto] Unable to upgrade kernel; package for kernel name > includes version > Message-ID: > > <91586D499ADFD74FBCFB8425266A5DE40153C11560E0@pluto.melinkcorp.local> > Content-Type: text/plain; charset="us-ascii" > > All, > > > -----Original Message----- > > From: yocto-boun...@yoctoproject.org [mailto:yocto- > > boun...@yoctoproject.org] On Behalf Of Bryan Evenson > > Sent: Monday, November 25, 2013 9:46 AM > > To: yocto@yoctoproject.org > > Subject: [yocto] Unable to upgrade kernel; package for kernel name > > includes version > > > > I'm on poky/dylan-9.0.1 I am upgrading the Linux kernel for my device's > > image from a custom 3.6.9 kernel to a custom 3.10 kernel. I'm using > > this layer: https://github.com/evensonbryan/meta-atmel as a basis for > > the custom kernel recipe (there is a recipe for the 3.10 kernel that I > > haven't yet deployed to Github in case anyone is wondering). I'm > > attempting to do a firmware upgrade with my built packages (using opkg > > for package management) and I've discovered an issue with the kernel > > naming. On my pre-upgraded device, a list of installed packages > > includes: > > > > kernel-devicetree > > kernel-image-3.6.9-yocto-standard > > > > So when I build my updated Linux kernel, the kernel image is now named > > "kernel-image-3.10.0-yocto-standard". So when I attempt to do an > > upgrade, the kernel-devicetree is upgraded just fine but the kernel > > image is not; kernel-image-3.10.0-yocto-standard is not the same > > package as kernel-image-3.6.9-yocto-standard, so opkg does not see this > > as an upgrade. > > > > How do I force the packaging system to recognize that the new kernel is > > an upgrade of the old kernel, even though the packages have different > > names? And for the future, how do I change the package name so that it > > doesn't include the version? > > I have a partial solution, but I'm still curious as to if there is a > cleaner method than what I've found so far. I have a package that is an > image version so that way I can easily tell the overall distribution > version. In that package, I added the line: > > RDEPENDS_${PN} = "kernel-image (>= 3.10)" > > When I did this, upgrading my image version package caused > kernel-image-3.10.0-yocto-standard to be installed. However, opkg still > claims that kernel-image-3.6.9-yocto-standard is still installed; it'd be > nice to remove this package also. Would adding: > > RCONFLICTS_${PN} = "kernel-image-3.6.9-yocto-standard" > RREPLACES_${PN} = "kernel-image-3.6.9-yocto-standard" > > to the 3.10 kernel recipe fix the issue? And if so, moving forward would > I then need to append the list with each kernel version that is created, in > case I have an old system that has never been upgraded? I think this will > work, but it seems messy. > > Thanks, > Bryan > > > > Thanks, > > Bryan > > > > > > > > _______________________________________________ > > yocto mailing list > > yocto@yoctoproject.org > > https://lists.yoctoproject.org/listinfo/yocto > > > ------------------------------ > > Message: 8 > Date: Mon, 25 Nov 2013 17:01:10 +0000 > From: Paul Eggleton <paul.eggle...@linux.intel.com> > To: "Rifenbark, Scott M" <scott.m.rifenb...@intel.com>, "Robert P. J. > Day" <rpj...@crashcourse.ca> > Cc: yocto@yoctoproject.org > Subject: Re: [yocto] FW: stupid question about post-installation > scripts > Message-ID: <2877100.Goa8NZvDMD@helios> > Content-Type: text/plain; charset="us-ascii" > > On Monday 25 November 2013 15:21:41 Rifenbark, Scott M wrote: > > >From: Robert P. J. Day [mailto:rpj...@crashcourse.ca] > > >Sent: Sunday, November 24, 2013 2:37 AM > > >To: Rifenbark, Scott M > > >Subject: stupid question about post-installation scripts > > > > > > when one defines pkg_postinst scripts, are those scripts invoked at > > > > > >*both* root filesystem creation time and first boot time? so that one > needs > > >to manually check the value of ${D} to decide whether to run them, say, > at > > >first boot time? > > Not both - it's either-or; i.e. it will be run at rootfs creation time and > if > it fails then, it will be run on first boot. Yes you can use the value of > $D > (note: *not* ${D}!) to find out where the script is being called from, if > necessary. > > > > i'm reading the section here: > > >http://www.yoctoproject.org/docs/latest/dev-manual/dev-> > >manual.html#post-installation-scripts > > > > > >and i know i've seen elsewhere scripts explicitly checking the value of > the > > >${D} prefix to determine when they're being invoked. it *seems* like > > >that's what's happening, but if that's the case, it can probably be said > > >much more clearly. > > The answer is, you can do this if you have to, but ideally you shouldn't > need > to. In the ideal situation the script should be written such that it > functions > equally well no matter where it executes; that avoids the need to run > anything > on first boot, *and* (assuming you have package management enabled for the > target) it will work if the package is installed on the target some time > afterwards. > > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre > > > ------------------------------ > > Message: 9 > Date: Mon, 25 Nov 2013 17:06:51 +0000 > From: Paul Eggleton <paul.eggle...@linux.intel.com> > To: "Rifenbark, Scott M" <scott.m.rifenb...@intel.com>, "Robert P. J. > Day" <rpj...@crashcourse.ca> > Cc: yocto@yoctoproject.org > Subject: Re: [yocto] FW: stupid question about post-installation > scripts > Message-ID: <197917002.9dER9YZC1c@helios> > Content-Type: text/plain; charset="us-ascii" > > On Monday 25 November 2013 17:01:10 Paul Eggleton wrote: > > On Monday 25 November 2013 15:21:41 Rifenbark, Scott M wrote: > > > >From: Robert P. J. Day [mailto:rpj...@crashcourse.ca] > > > >Sent: Sunday, November 24, 2013 2:37 AM > > > >To: Rifenbark, Scott M > > > >Subject: stupid question about post-installation scripts > > > > > > > > when one defines pkg_postinst scripts, are those scripts invoked at > > > > > > > >*both* root filesystem creation time and first boot time? so that one > > > >needs > > > >to manually check the value of ${D} to decide whether to run them, > say, > > > >at > > > >first boot time? > > > > Not both - it's either-or; i.e. it will be run at rootfs creation time > and > > if it fails then, it will be run on first boot. Yes you can use the value > > of $D (note: *not* ${D}!) to find out where the script is being called > > from, if necessary. > > PS, if you really do want to force the script to be postponed until first > boot, > you *must* make the postinst script fail if $D has a value - if you just > let > it pass the system will assume it doesn't need to be called again on first > boot. > > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre > > > ------------------------------ > > _______________________________________________ > yocto mailing list > yocto@yoctoproject.org > https://lists.yoctoproject.org/listinfo/yocto > > > End of yocto Digest, Vol 38, Issue 92 > ************************************* >
_______________________________________________ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto