Re: [yocto] enable netbase network interfaces?
On Fri, 28 Dec 2012, Gary Thomas wrote:
On 2012-12-27 23:40, Lai Eddy wrote:
Thanks Gary,
after download and extract the ti cortex A8 BSP . there's only binary image
inside, what MACHINE to use to build a beagleboard yocto image?
MACHINE=beagleboard
Why does this matter? You asked about how to set up *your* BSP to have
a tailored network interface file. All you need to do is pattern your
setup after the beagleboard one, as quoted.
n.b. please don't top-post :-(
On 2012-12-25 16:31, Lai Eddy wrote:
in the Reference Manual How do I make sure connected network
interfaces are brought up by default? said 2 files need to be added to
enable network interfaces, where can I find
template files?
--__--__--__-
The default interfaces file provided by the netbase recipe does not
automatically bring up network interfaces. Therefore, you will need to add a
BSP-specific netbase that includes
an interfaces file.
For example, add the following files to your layer:
meta-MACHINE/recipes-bsp/__netbase/netbase/MACHINE/__interfaces
meta-MACHINE/recipes-bsp/__netbase/netbase_5.0.bbappend
--__--__--__--
Look in meta-ti (git://git.yoctoproject.org/__meta-ti
http://git.yoctoproject.org/meta-ti):
$ find meta-ti/recipes-core/netbase/
meta-ti/recipes-core/netbase/
meta-ti/recipes-core/netbase/__netbase-5.0
meta-ti/recipes-core/netbase/__netbase-5.0/beagleboard
meta-ti/recipes-core/netbase/__netbase-5.0/beagleboard/__interfaces
meta-ti/recipes-core/netbase/__netbase_5.0.bbappend
i'm not sure where your __ prefixes are coming from, but i know
i've pointed out before that meta-ti's netbase_5.0.bbappend file seems
to be broken. currently, on dev branch, it contains:
THISDIR := ${@os.path.dirname(bb.data.getVar('FILE', d, True))}
FILESPATH =. ${@base_set_filespath([${THISDIR}/${PN}], d)}:
that value for FILESPATH is incorrect -- because the directory name
for the interfaces file in meta-ti is netbase-5.0 (not simply
netbase), it will *not* be picked up; rather, the default interfaces
file from oe-core will be pulled in.
using bitbake-env, you can *see* the FILESPATH value that's used
when building for beagle using meta-ti:
$ bitbake-env -r netbase FILESPATH | tr : '\n'
Parsing recipes..WARNING: No recipes available for:
/home/rpjday/oe/dist/layers/meta-ti/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend
done.
# FILESPATH=${@base_set_filespath([${THISDIR}/${PN}], d)}
${@base_set_filespath([${FILE_DIRNAME}/${BP},
${FILE_DIRNAME}/${BPN}, ${FILE_DIRNAME}/files], d)}
FILESPATH=/home/rpjday/oe/dist/layers/meta-ti/recipes-core/netbase/netbase/arm
/home/rpjday/oe/dist/layers/meta-ti/recipes-core/netbase/netbase/beagleboard
/home/rpjday/oe/dist/layers/meta-ti/recipes-core/netbase/netbase/omap3
/home/rpjday/oe/dist/layers/meta-ti/recipes-core/netbase/netbase/armv7a
/home/rpjday/oe/dist/layers/meta-ti/recipes-core/netbase/netbase/
/home/rpjday/oe/dist/layers/meta-ti/recipes-core/netbase/netbase/
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/arm
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/beagleboard
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/omap3
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/armv7a
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase/arm
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase/beagleboard
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase/omap3
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase/armv7a
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase/
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase/
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/files/arm
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/files/beagleboard
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/files/omap3
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/files/armv7a
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/files/
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/files/
$
you can see that FILESPATH doesn't include the very directory in
meta-ti that contains the overriding beagleboard interfaces file.
or am i horribly misunderstanding something here?
rday
--
Robert P. J. Day Ottawa, Ontario, CANADA
[yocto] IMHO, the meta-yocto layer is not adequately explained
during travels thru the docs, ran across a layer graphic (dang, can't remember where) whose bottom layers were: ... snip ... BSPs Yocto OE Core clearly showing the yocto layer sitting above OE core and directly below BSPs. but that picture is somewhat misleading since it's perfectly reasonable to build BSPs with no inclusion of the meta-yocto layer. i think there's a danger that new readers will get the impression that they *must* include the meta-yocto layer to do any serious work, when that's just not true. i think it would be worth briefly explaining what the meta-yocto (and, consequently, meta-yocto-bsp) layers bring to the table, and under what circumstances one can leave that out. i realize this sounds contradictory since this *is* the yocto project, but a simple list of what constitutes meta-yocto would be handy so developers realize what they're pulling in, and even if they need it. 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
Re: [yocto] enable netbase network interfaces?
On 2012-12-29 02:58, Robert P. J. Day wrote:
On Fri, 28 Dec 2012, Gary Thomas wrote:
On 2012-12-27 23:40, Lai Eddy wrote:
Thanks Gary,
after download and extract the ti cortex A8 BSP . there's only binary image
inside, what MACHINE to use to build a beagleboard yocto image?
MACHINE=beagleboard
Why does this matter? You asked about how to set up *your* BSP to have
a tailored network interface file. All you need to do is pattern your
setup after the beagleboard one, as quoted.
n.b. please don't top-post :-(
On 2012-12-25 16:31, Lai Eddy wrote:
in the Reference Manual How do I make sure connected network
interfaces are brought up by default? said 2 files need to be added to
enable network interfaces, where can I find
template files?
--__--__--__-
The default interfaces file provided by the netbase recipe does not
automatically bring up network interfaces. Therefore, you will need to add a
BSP-specific netbase that includes
an interfaces file.
For example, add the following files to your layer:
meta-MACHINE/recipes-bsp/__netbase/netbase/MACHINE/__interfaces
meta-MACHINE/recipes-bsp/__netbase/netbase_5.0.bbappend
--__--__--__--
Look in meta-ti (git://git.yoctoproject.org/__meta-ti
http://git.yoctoproject.org/meta-ti):
$ find meta-ti/recipes-core/netbase/
meta-ti/recipes-core/netbase/
meta-ti/recipes-core/netbase/__netbase-5.0
meta-ti/recipes-core/netbase/__netbase-5.0/beagleboard
meta-ti/recipes-core/netbase/__netbase-5.0/beagleboard/__interfaces
meta-ti/recipes-core/netbase/__netbase_5.0.bbappend
i'm not sure where your __ prefixes are coming from, but i know
i've pointed out before that meta-ti's netbase_5.0.bbappend file seems
to be broken. currently, on dev branch, it contains:
THISDIR := ${@os.path.dirname(bb.data.getVar('FILE', d, True))}
FILESPATH =. ${@base_set_filespath([${THISDIR}/${PN}], d)}:
that value for FILESPATH is incorrect -- because the directory name
for the interfaces file in meta-ti is netbase-5.0 (not simply
netbase), it will *not* be picked up; rather, the default interfaces
file from oe-core will be pulled in.
using bitbake-env, you can *see* the FILESPATH value that's used
when building for beagle using meta-ti:
$ bitbake-env -r netbase FILESPATH | tr : '\n'
Parsing recipes..WARNING: No recipes available for:
/home/rpjday/oe/dist/layers/meta-ti/recipes-graphics/mesa/mesa-dri_8.0.4.bbappend
done.
# FILESPATH=${@base_set_filespath([${THISDIR}/${PN}], d)}
${@base_set_filespath([${FILE_DIRNAME}/${BP},
${FILE_DIRNAME}/${BPN}, ${FILE_DIRNAME}/files], d)}
FILESPATH=/home/rpjday/oe/dist/layers/meta-ti/recipes-core/netbase/netbase/arm
/home/rpjday/oe/dist/layers/meta-ti/recipes-core/netbase/netbase/beagleboard
/home/rpjday/oe/dist/layers/meta-ti/recipes-core/netbase/netbase/omap3
/home/rpjday/oe/dist/layers/meta-ti/recipes-core/netbase/netbase/armv7a
/home/rpjday/oe/dist/layers/meta-ti/recipes-core/netbase/netbase/
/home/rpjday/oe/dist/layers/meta-ti/recipes-core/netbase/netbase/
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/arm
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/beagleboard
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/omap3
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/armv7a
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase-5.0/
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase/arm
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase/beagleboard
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase/omap3
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase/armv7a
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase/
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/netbase/
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/files/arm
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/files/beagleboard
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/files/omap3
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/files/armv7a
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/files/
/home/rpjday/oe/dist/layers/oe-core/meta/recipes-core/netbase/files/
$
you can see that FILESPATH doesn't include the very directory in
meta-ti that contains the overriding beagleboard interfaces file.
or am i horribly misunderstanding something here?
I agree that file is incorrect. I simply quoted its use as it is the only
example in a commonly available layer. I'll send a patch for the meta-ti
file and hopefully they'll fix it.
Here's what I
Re: [yocto] IMHO, the meta-yocto layer is not adequately explained
-Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto- boun...@yoctoproject.org] On Behalf Of Robert P. J. Day Sent: Saturday, December 29, 2012 2:23 AM To: Yocto discussion list Subject: [yocto] IMHO, the meta-yocto layer is not adequately explained during travels thru the docs, ran across a layer graphic (dang, can't remember where) whose bottom layers were: ... snip ... BSPs Yocto OE Core clearly showing the yocto layer sitting above OE core and directly below BSPs. but that picture is somewhat misleading since it's perfectly reasonable to build BSPs with no inclusion of the meta-yocto layer. i think there's a danger that new readers will get the impression that they *must* include the meta-yocto layer to do any serious work, when that's just not true. i think it would be worth briefly explaining what the meta- yocto (and, consequently, meta-yocto-bsp) layers bring to the table, and under what circumstances one can leave that out. i realize this sounds contradictory since this *is* the yocto project, but a simple list of what constitutes meta-yocto would be handy so developers realize what they're pulling in, and even if they need it. 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 That is a great idea. It would be very helpful. Regards, Sean Liming Owner Annabooks Tel: 714-970-7523 / Cell: 858-774-3176 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] odd(?) behaviour with qemu arm image and runqemu-extract-sdk
first time perusing these sections in the yocto docs, kind of puzzling result so i'm prepared to believe i did something silly. reading: http://www.yoctoproject.org/docs/latest/dev-manual/dev-manual.html#workflow-using-stand-alone-cross-development-toolchains Workflow Using Stand-alone Cross-development Toolchains, and i already had an OE qemuarm core-image-minimal built that i can run just fine with: $ runqemu qemuarm so i was reading that section and followed the link over to the ADT manual: http://www.yoctoproject.org/docs/1.4/adt-manual/adt-manual.html#extracting-the-root-filesystem where it talked about Extracting the Root Filesystem, so i figured, what the heck, i'll give that a shot, so i ran runqemu-extract-sdk on the very rootfs tarball that had been created by my build and extracted it under ~/rootfs, then without reading any further, tried this variation of runqemu for the first time: $ runqemu qemuarm ~/rootfs Assuming /home/rpjday/rootfs is an nfs rootfs Continuing with the following parameters: KERNEL: [/home/rpjday/oe/builds/oe/qemuarm/tmp-eglibc/deploy/images/zImage-qemuarm.bin] ROOTFS: [/home/rpjday/rootfs] FSTYPE: [nfs] Setting up tap interface under sudo [sudo] password for rpjday: Acquiring lockfile for tap0... runqemu-export-rootfs restart /home/rpjday/rootfs Error: Unable to find rpc.mountd binary in /home/rpjday/oe/builds/oe/qemuarm/tmp-eglibc/sysroots/x86_64-linux/usr/sbin/ Have you run 'bitbake meta-ide-support'? Set 'tap0' nonpersistent Releasing lockfile of preconfigured tap device 'tap0' $ so ... how many things did i do wrong? some random thoughts on this before i dig back into the docs and code: 1) why the name runqemu-extract-sdk? it seems that the point of that script is to just untar a root filesystem. i don't see anything being extracted per se. 2) i notice that the dev directory created by that script contains only regular files instead of actual special device files. but if i use sudo to just untar exactly the same tarball, i get real device files. is that the expected behaviour of that script? 3) what should i have done earlier to have the apparently necessary usr/sbin/rpc.mountd in my sysroot? it seems odd that i can run my built qemu image just fine if i run it normally, but if i runqemu-extract-sdk to unload a rootfs, suddenly my sysroot is missing that utility. is the documentation simply missing some simple but critical details about what types of images are required for this? and one more thing. from that first link in the dev manual, there's that note that takes you over to the ADT manual. and it's entirely possible that there some critical info *before* the section Extracting the Root Filesystem but given how one got there (by following the link), the reader might miss it. anyway, 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
[yocto] How to include RPM database into target image?
Presumably this is very obvious, apologies, but I can't track down the answer. I'm building a distro based on Yocto for a Raspberry Pi but I don't seem to have the RPM database / sample feeds installed on the target image. Having hunted around and googled I can't spot the environment variable or recipe I presumably need to set/include. Can anybody advise? Many Thanks, Alex ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
[yocto] [PATCH] Documentation: Small number of typoes/grammos in Ch 4, Dev Manual.
Signed-off-by: Robert P. J. Day rpj...@crashcourse.ca --- diff --git a/documentation/dev-manual/dev-manual-model.xml b/documentation/dev-manual/dev-manual-model.xml index 442cab3..1c27828 100644 --- a/documentation/dev-manual/dev-manual-model.xml +++ b/documentation/dev-manual/dev-manual-model.xml @@ -33,7 +33,7 @@ Direct modification of temporary source code is a convenient development model to quickly iterate and develop towards a solution. Once the solution has been implemented, you should of course take steps to - get the changes upstream and applied in the affected recipes./para/listitem + get the changes upstream and applied to the affected recipes./para/listitem listitemparaemphasisImage Development using Hob:/emphasis You can use the ulink url='YOCTO_HOME_URL;/projects/hob'Hob/ulink to build custom operating system images within the build environment. @@ -55,7 +55,7 @@ Usually, when you want to create an image that runs on embedded hardware, the image does not require the same number of features that a full-fledged Linux distribution provides. Thus, you can create a much smaller image that is designed to use only the -features for your particular hardware. +features of your particular hardware. /para para @@ -99,7 +99,7 @@ orderedlist listitemparaemphasisSet up your host development system to support development using the Yocto Project/emphasis: See the -ulink url='YOCTO_DOCS_QS_URL;#the-linux-distro'The Linux Distributions/ulink +ulink url='YOCTO_DOCS_QS_URL;#the-linux-distro'The Linux Distribution/ulink and the ulink url='YOCTO_DOCS_QS_URL;#packages'The Packages/ulink sections both in the Yocto Project Quick Start for requirements./para/listitem @@ -110,7 +110,7 @@ process and to the tools you need. For information on how to set up the link linkend='source-directory'Source Directory/link, see the -link linkend='getting-setup'Getting Setup/link section./para/listitem +link linkend='getting-setup'Getting Set Up/link section./para/listitem listitemparaemphasisEstablish the filenamemeta-intel/filename repository on your system/emphasis: Having local copies of the supported BSP layers on your system gives you access to the build @@ -245,7 +245,7 @@ para Traditionally, when one thinks of a patched kernel, they think of a base kernel source tree and a fixed structure that contains kernel patches. -The Yocto Project, however, employs mechanisms, that in a sense, result in a kernel source +The Yocto Project, however, employs mechanisms that, in a sense, result in a kernel source generator. By the end of this section, this analogy will become clearer. /para @@ -327,7 +327,7 @@ representing and using the code on your host development system is another. Conceptually, you can think of the kernel source repositories as all the source files necessary for all the supported kernels. -As a developer, you are just interested in the source files for the kernel on +As a developer, you are just interested in the source files for the kernel on which you are working. And, furthermore, you need them available on your host system. /para @@ -391,7 +391,7 @@ orderedlist listitemparaemphasisSet up your host development system to support development using the Yocto Project/emphasis: See -ulink url='YOCTO_DOCS_QS_URL;#the-linux-distro'The Linux Distributions/ulink and +ulink url='YOCTO_DOCS_QS_URL;#the-linux-distro'The Linux Distribution/ulink and ulink url='YOCTO_DOCS_QS_URL;#packages'The Packages/ulink sections both in the Yocto Project Quick Start for requirements./para/listitem listitemparaemphasisEstablish a local copy of project files on your @@ -445,7 +445,7 @@ Doing so, can produce unexpected results when the OpenEmbedded build system regenerates the configuration file./para paraOnce you are satisfied with the configuration changes made using -filenamemenuconfig/filename, you can directly examine the +filenamemenuconfig/filename, you can directly compare the
[yocto] [Package Report System]Upgrade recipes name list
This mail was sent out by Package Report System. This message list those recipes which need to be upgraded. If maintainers believe some of them needn't to upgrade this time, they can fill in RECIPE_NO_UPDATE_REASON_pn-xxx in upstream_tracking files to ignore this recipe remainder until newer upstream version was detected. Example: RECIPE_NO_UPDATE_REASON_pn-xxx = Not upgrade to 2.0 because the new version is unstable You can check the detail information at http://packages.yoctoproject.org/upgradepkgname PackageName Version UpVersion MaintainerNoUpgradeReason sysprof 1.1.8+gitAUTOINC+4692f85 1.2.0 Tom Zanussi tom.zanu...@intel.com systemtap-uprobes 1.8+gitAUTOINC+48fa6b5e1 2.0 Tom Zanussi tom.zanu...@intel.com shadow4.1.4.3 4.1.5.1 Scott Garman scott.a.gar...@intel.com sudo 1.8.5p2 1.8.6 Scott Garman scott.a.gar...@intel.com blktool 4-6 4 Scott Garman scott.a.gar...@intel.com icu 50.1 50.1.1 Scott Garman scott.a.gar...@intel.com apmd 3.2.2-14 3.2.2 Scott Garman scott.a.gar...@intel.com openssh 6.0p1 6.1p1 Scott Garman scott.a.gar...@intel.com man-pages 3.44 3.45 Saul Wold s...@linux.intel.com augeas0.10.01.0.0 Saul Wold s...@linux.intel.com libidn1.25 1.26 Saul Wold s...@linux.intel.com mc4.8.6 4.8.7 Saul Wold s...@linux.intel.com libtasn1 2.14 3.2 Saul Wold s...@linux.intel.com libnl 3.2.143.2.16 Saul Wold s...@linux.intel.com libnl-3.2.2 is incompatible w... createrepo0.4.110.9.9 Saul Wold s...@linux.intel.com Versions after 0.9.* use YUM,... apt 0.7.140.9.7.7 Saul Wold s...@linux.intel.com pkgconfig 0.25 0.27.1 Saul Wold s...@linux.intel.com removes glib-conf, adds circu... build-appliance-image 1.0 3.2.1 Saul Wold s...@linux.intel.com util-linux2.22.12.22.2 Saul Wold s...@linux.intel.com resolvconf1.68 1.69 Saul Wold s...@linux.intel.com dhcp 4.2.4-P2 4.2.4 Saul Wold s...@linux.intel.com mtdev 1.1.2 1.1.3 Ross Burton ross.bur...@intel.com logrotate 3.8.1 3.8.3 Robert Yang liezhi.y...@windriver.com gawk 4.0.1 4.0.2 Radu Moisan radu.moi...@intel.com iputils s20101006 20121221 Radu Moisan radu.moi...@intel.com ed1.6 1.7 Radu Moisan radu.moi...@intel.com cronie1.4.8 1.4.9 Radu Moisan radu.moi...@intel.com apr-util 1.4.1 1.5.1 Radu Moisan radu.moi...@intel.com liburcu 0.7.4 0.7.5 Radu Moisan radu.moi...@intel.com js1.7.0+1.8.0rc11.60 Radu Moisan radu.moi...@intel.com
[yocto] [Package Report System]Manual check recipes name list
This mail was sent out by Package Report System. It will list all the recipes which can't check upstream version by script, and will show how long it is since their last mannual version check. You can check the detail information at http://packages.yoctoproject.org/manuallychkinfo PackageName Version LastChkVersion LastChkTime Maintainer NoUpgradeReason lsb 4.1 4.1 116 day Yi Zhao yi.z...@windriver.co...No data e2fsprogs1.42.1 1.42.5 124 day Scott Garman scott.a.garman@...No data chrpath 0.140.14125 day Scott Garman scott.a.garman@...No data opensp 1.5.2 1.5.2 121 day Scott Garman scott.a.garman@...No data expat2.1.0 2.0.1 124 day Scott Garman scott.a.garman@...No data nfs-utils1.2.3 1.2.6 121 day Scott Garman scott.a.garman@...No data libpng 1.5.13 1.5.11 178 day Scott Garman scott.a.garman@...1.4.3 and later changes the AP... cracklib 2.8.19 2.8.19 58 days Saul Wold s...@linux.intel.co...No data psmisc 22.20 22.20 58 days Saul Wold s...@linux.intel.co...No data sysstat 10.1.2 10.1.2 58 days Saul Wold s...@linux.intel.co...No data less 457 451 58 days Saul Wold s...@linux.intel.co...No data glew 1.9.0 1.9.0 58 days Saul Wold s...@linux.intel.co...No data libexif 0.6.21 0.6.21 58 days Saul Wold s...@linux.intel.co...No data sqlite3 3.7.15.13.7.14.158 days Saul Wold s...@linux.intel.co...No data boost1.51.0 1.51.0 58 days Saul Wold s...@linux.intel.co...No data libcheck 0.9.9 0.9.9 58 days Saul Wold s...@linux.intel.co...No data kconfig-frontends3.6.0 3.6.0 58 days Saul Wold s...@linux.intel.co...No data sysfsutils 2.1.0 2.1.0 58 days Saul Wold s...@linux.intel.co...No data libcgroup0.37.1 0.38-1 58 days Saul Wold s...@linux.intel.co...No data console-tools0.3.2 0.3.2 58 days Saul Wold s...@linux.intel.co...No data libmad 0.15.1b 0.15.1b 58 days Saul Wold s...@linux.intel.co...No data tzdata 2012d 2012c 115 day Radu Moisan radu.moisan@inte...No data watchdog 5.125.1251 days Radu Moisan radu.moisan@inte...No data tslib1.0 1.0 118 day Radu Moisan radu.moisan@inte...No data hdparm 9.399.3951 days Radu Moisan radu.moisan@inte...No data zip 3.0 3.0 117 day Radu Moisan radu.moisan@inte...No data unzip6.0 6.0 118 day Radu Moisan radu.moisan@inte...No data beecrypt 4.2.1 4.2.1 51 days Radu Moisan radu.moisan@inte...No data acpid
