openembedded-core.git/meta/packages/pam, branch master

packages: Separate out most of the remaining packages into recipes

2010-09-01T18:09:57Z

Signed-off-by: Richard Purdie

pam: add missing bits from previous commit

2010-08-17T21:56:12Z

Signed-off-by: Kevin Tian

pam: rename to libpam and add core config files

2010-08-13T12:36:01Z

So far pam is not really functional as there no pam config files exists, here we borrow from openembedded to setup core /etc/pam.d to make it functional: * change 'pam' to 'libpam' following Debian naming convention, and change (R)DEPENDS in other recipes * borrow openembedded libpam-base-files with changes: - rename to libpam-runtime to follow Debian naming - only keep common-* core files which can be traced back to Debian libpam-runtime-1.0.1 for license track. Other service specific files (such as atd, cron, ...) are removed because either they may contaminate the license or it's right thing to have their own packages providing them - use same libpam recipe instead of creating a new. This way other /etc/ stuff are all contained by libpam-runtime * like openembedded, we package each pam plugin into seperate package now, with some differnce though: - Some ${sbindir} binaries are bound to specific PAM plugin. So better to package them together with corresponding plugin package - populate_sysroot_prepend is invoked before actual populate_sysroot, at that time ${D} binaries haven't been tripped. So it's difficult to specify -dev for those plugin pacakges from _prepend which are simply empty. actually one -dev/-doc per recipe is one good exercise here. Signed-off-by: Kevin Tian

populate-volatile.sh: cleanup duplicated invocations and remove boot warning

2010-08-12T14:39:24Z

For one, populate-volatile.sh is itself a rcS script which is invoked earlier than package's own postinst method (last one in rcS). If package has already installed their volatile files correctly, it doesn't make sense to update volatile again in postinst since nothing is changed. On the other hand, dbus/hal are special since their user/group are only created in the target. If they pre-install volatiles like others, populate-volatile.sh will report "undefined user" since at that time their user/group haven't been created. The better way solving this is to generate their volatile in the fly after user/group are created, and then update volatiles. This fix [BUGID #121] Signed-off-by: Kevin Tian

pam: use volatile to avoid /var/run population in do_rootfs

2010-07-30T13:50:31Z

also disable doc rebuild to reuse existing man pages. Signed-off-by: Kevin Tian

pam: upgrade to 1.1.1

2010-07-09T04:05:41Z

[Patches] KEEP _disable_crossbinary.patch_ [Recipe] fix SRC_URI and EXTRA_OECONF indention Signed-off-by: Kevin Tian

pam: fix metadata

2010-06-30T22:44:21Z

Signed-off-by: Kevin Tian

pam: fix inherit, add gettext and change autotools

2010-01-06T09:17:00Z

Signed-off-by: Joshua Lock

sato: move pam from meta-moblin to meta

2009-11-20T17:47:18Z

pam recipe is required to build a sato image, and it was moved in the meta-moblin collection by mistake, and sato build was broken. pam is a dependency of policykit which is a dependency of networkmanager. Signed-off-by: Nicolas Dechesne Signed-off-by: Richard Purdie

Move pam, packagekit, monit and gnet to meta-moblin

2008-12-02T14:30:31Z