[yocto] yocto Digest, Vol 38, Issue 92
rajan pathak
rajanpatha34 at gmail.com
Mon Nov 25 09:15:59 PST 2013
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-request at yoctoproject.org> wrote:
> Send yocto mailing list submissions to
> yocto at 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-request at yoctoproject.org
>
> You can reach the person managing the list at
> yocto-owner at 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 <bevenson at melinkcorp.com>
> To: "yocto at yoctoproject.org" <yocto at yoctoproject.org>
> Subject: [yocto] Unable to upgrade kernel; package for kernel name
> includes version
> Message-ID:
>
> <91586D499ADFD74FBCFB8425266A5DE40153C1156010 at 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.rifenbark at intel.com>
> To: "Robert P. J. Day" <rpjday at crashcourse.ca>, Yocto discussion list
> <yocto at yoctoproject.org>
> Subject: Re: [yocto] ksize.py and dirsize.py scripts not in dora
> tarball, is that deliberate?
> Message-ID:
> <
> 41DEA4B02DBDEF40A0F3B6D0DDB1237983F51186 at 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-bounces at yoctoproject.org [mailto:yocto-
> >bounces at 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 at yoctoproject.org
> >https://lists.yoctoproject.org/listinfo/yocto
>
>
> ------------------------------
>
> Message: 3
> Date: Mon, 25 Nov 2013 15:01:29 +0000
> From: Paul Eggleton <paul.eggleton at linux.intel.com>
> To: Michael Halstead <michael at yoctoproject.org>
> Cc: yocto at yoctoproject.org
> Subject: Re: [yocto] RFC Autobuilder Naming
> Message-ID: <6760837.T0hJxS54r8 at 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 <tstellanova at gmail.com>
> To: Paul Eggleton <paul.eggleton at linux.intel.com>
> Cc: "yocto at yoctoproject.org" <yocto at yoctoproject.org>
> Subject: Re: [yocto] unbootable image produced with PACKAGE_CLASSES ?=
> "package_ipk", /etc missing
> Message-ID: <FDC4F28A-69CB-406F-95EA-0A5D2AB800BC at 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.eggleton at 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
> >> <tstellanova at 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.rifenbark at intel.com>
> To: "Robert P. J. Day" <rpjday at crashcourse.ca>
> Cc: Yocto discussion list <yocto at yoctoproject.org>
> Subject: [yocto] FW: stupid question about post-installation scripts
> Message-ID:
> <
> 41DEA4B02DBDEF40A0F3B6D0DDB1237983F511F7 at 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:rpjday at 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 <bevenson at melinkcorp.com>
> To: "Rifenbark, Scott M" <scott.m.rifenbark at intel.com>, "Robert P. J.
> Day" <rpjday at crashcourse.ca>
> Cc: Yocto discussion list <yocto at yoctoproject.org>
> Subject: Re: [yocto] stupid question about post-installation scripts
> Message-ID:
>
> <91586D499ADFD74FBCFB8425266A5DE40153C1156096 at 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-bounces at yoctoproject.org [mailto:yocto-
> > bounces at 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:rpjday at 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 at yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
>
> ------------------------------
>
> Message: 7
> Date: Mon, 25 Nov 2013 11:35:47 -0500
> From: Bryan Evenson <bevenson at melinkcorp.com>
> To: Bryan Evenson <bevenson at melinkcorp.com>, "yocto at yoctoproject.org"
> <yocto at yoctoproject.org>
> Subject: Re: [yocto] Unable to upgrade kernel; package for kernel name
> includes version
> Message-ID:
>
> <91586D499ADFD74FBCFB8425266A5DE40153C11560E0 at pluto.melinkcorp.local>
> Content-Type: text/plain; charset="us-ascii"
>
> All,
>
> > -----Original Message-----
> > From: yocto-bounces at yoctoproject.org [mailto:yocto-
> > bounces at yoctoproject.org] On Behalf Of Bryan Evenson
> > Sent: Monday, November 25, 2013 9:46 AM
> > To: yocto at 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 at yoctoproject.org
> > https://lists.yoctoproject.org/listinfo/yocto
>
>
> ------------------------------
>
> Message: 8
> Date: Mon, 25 Nov 2013 17:01:10 +0000
> From: Paul Eggleton <paul.eggleton at linux.intel.com>
> To: "Rifenbark, Scott M" <scott.m.rifenbark at intel.com>, "Robert P. J.
> Day" <rpjday at crashcourse.ca>
> Cc: yocto at yoctoproject.org
> Subject: Re: [yocto] FW: stupid question about post-installation
> scripts
> Message-ID: <2877100.Goa8NZvDMD at 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:rpjday at 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.eggleton at linux.intel.com>
> To: "Rifenbark, Scott M" <scott.m.rifenbark at intel.com>, "Robert P. J.
> Day" <rpjday at crashcourse.ca>
> Cc: yocto at yoctoproject.org
> Subject: Re: [yocto] FW: stupid question about post-installation
> scripts
> Message-ID: <197917002.9dER9YZC1c at 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:rpjday at 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 at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>
>
> End of yocto Digest, Vol 38, Issue 92
> *************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20131125/d60692d8/attachment.html>
More information about the yocto
mailing list