| Submitter | Khem Raj |
|---|---|
| Date | July 31, 2012, 6:56 p.m. |
| Message ID | <1343760977-3290-1-git-send-email-raj.khem@gmail.com> |
| Download | mbox | patch |
| Permalink | /patch/33457/ |
| State | Superseded |
| Headers | show |
Comments
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Op 31-07-12 20:56, Khem Raj schreef: > Dont inherit vala and gitpkgv not needed anymore > > Along with upgrade use the release tarballs instead of git For an update we need to pull in some patches from master, so a git recipe is still the preferred way. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: GPGTools - http://gpgtools.org iD8DBQFQGUc1MkyGM64RGpERArReAJ93fwNc/vyBp0l0r3BUegfsZ7f9cgCeIL5F 5n7y+QcXp8vO9Mj8n/5idgM= =4sUO -----END PGP SIGNATURE-----
On Aug 1, 2012, at 8:11 AM, Koen Kooi <koen@dominion.thruhere.net> wrote: >> >> Along with upgrade use the release tarballs instead of git > > For an update we need to pull in some patches from master, so a git recipe > is still the preferred way. OK, you know more about it then me but do you know how many those will be ? in other words does systemd releases mean much for stability yet or still its a project moving at so fast pace ? I see that releases are rolled out almost every month, that sort of could mean either way, we wait until the next release or just take from a commit upstream I feel like staying with a release+patches could be one way if we are not importing pathes too often. but I don't know how often that would be. For the testing I did release worked well for those platforms x86, ppc and arm
On Wednesday 01 August 2012 15:56:34 Khem Raj wrote: > On Aug 1, 2012, at 8:11 AM, Koen Kooi <koen@dominion.thruhere.net> wrote: > >> Along with upgrade use the release tarballs instead of git > > > > For an update we need to pull in some patches from master, so a git recipe > > is still the preferred way. > > OK, you know more about it then me but do you know how many those will be ? > in other words does systemd releases mean much for stability yet or still > its a project moving at so fast pace ? > > I see that releases are rolled out almost every month, that sort of could > mean either way, we wait until the next release or just take from a commit > upstream > > I feel like staying with a release+patches could be one way if we are not > importing pathes too often. but I don't know how often that would be. For > the testing I did release worked well for those platforms x86, ppc and arm One might suggest, if stable releases are working and you want to live on the bleeding edge in your distro, you can easily do so there... Cheers, Paul
On Aug 2, 2012, at 1:11 AM, Paul Eggleton <paul.eggleton@linux.intel.com> wrote: > On Wednesday 01 August 2012 15:56:34 Khem Raj wrote: >> On Aug 1, 2012, at 8:11 AM, Koen Kooi <koen@dominion.thruhere.net> wrote: >>>> Along with upgrade use the release tarballs instead of git >>> >>> For an update we need to pull in some patches from master, so a git recipe >>> is still the preferred way. >> >> OK, you know more about it then me but do you know how many those will be ? >> in other words does systemd releases mean much for stability yet or still >> its a project moving at so fast pace ? >> >> I see that releases are rolled out almost every month, that sort of could >> mean either way, we wait until the next release or just take from a commit >> upstream >> >> I feel like staying with a release+patches could be one way if we are not >> importing pathes too often. but I don't know how often that would be. For >> the testing I did release worked well for those platforms x86, ppc and arm > > One might suggest, if stable releases are working and you want to live on the > bleeding edge in your distro, you can easily do so there… This is moving forward from where we were so it includes all the git commits that were there until cd96b3b86abb4a88cac2722bdfb6e5d4413f6831 commit so this update is inclusive. we can also think of having a stable recipe and a git recipe but systemd releases are almost a month apart it would be more or less covered if we moved from release to release with some patches if needed. thirdly we can have two recipes as Paul suggested. > > Cheers, > Paul > > -- > > Paul Eggleton > Intel Open Source Technology Centre
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Op 03-08-12 12:32, Khem Raj schreef: > > On Aug 2, 2012, at 1:11 AM, Paul Eggleton <paul.eggleton@linux.intel.com> > wrote: > >> On Wednesday 01 August 2012 15:56:34 Khem Raj wrote: >>> On Aug 1, 2012, at 8:11 AM, Koen Kooi <koen@dominion.thruhere.net> >>> wrote: >>>>> Along with upgrade use the release tarballs instead of git >>>> >>>> For an update we need to pull in some patches from master, so a git >>>> recipe is still the preferred way. >>> >>> OK, you know more about it then me but do you know how many those >>> will be ? in other words does systemd releases mean much for >>> stability yet or still its a project moving at so fast pace ? >>> >>> I see that releases are rolled out almost every month, that sort of >>> could mean either way, we wait until the next release or just take >>> from a commit upstream >>> >>> I feel like staying with a release+patches could be one way if we are >>> not importing pathes too often. but I don't know how often that would >>> be. For the testing I did release worked well for those platforms >>> x86, ppc and arm >> >> One might suggest, if stable releases are working and you want to live >> on the bleeding edge in your distro, you can easily do so there… > > This is moving forward from where we were so it includes all the git > commits that were there until cd96b3b86abb4a88cac2722bdfb6e5d4413f6831 > commit so this update is inclusive. > > we can also think of having a stable recipe and a git recipe but systemd > releases are almost a month apart it would be more or less covered if we > moved from release to release with some patches if needed. If you look at the fedora and debian packages you'll see that they also pull in a fair number of patches, so it's not uncommon to do what we're doing. regards, Koen -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: GPGTools - http://gpgtools.org iD8DBQFQG8Y6MkyGM64RGpERAjOXAJ4mDqgr4BngOrGZk9drnilAvprDygCcCnW7 yiaKvRITgm6shVyoul4z3a0= =bngc -----END PGP SIGNATURE-----
On Fri, Aug 3, 2012 at 5:38 AM, Koen Kooi <koen@dominion.thruhere.net> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Op 03-08-12 12:32, Khem Raj schreef: >> >> On Aug 2, 2012, at 1:11 AM, Paul Eggleton <paul.eggleton@linux.intel.com> >> wrote: >> >>> On Wednesday 01 August 2012 15:56:34 Khem Raj wrote: >>>> On Aug 1, 2012, at 8:11 AM, Koen Kooi <koen@dominion.thruhere.net> >>>> wrote: >>>>>> Along with upgrade use the release tarballs instead of git >>>>> >>>>> For an update we need to pull in some patches from master, so a git >>>>> recipe is still the preferred way. >>>> >>>> OK, you know more about it then me but do you know how many those >>>> will be ? in other words does systemd releases mean much for >>>> stability yet or still its a project moving at so fast pace ? >>>> >>>> I see that releases are rolled out almost every month, that sort of >>>> could mean either way, we wait until the next release or just take >>>> from a commit upstream >>>> >>>> I feel like staying with a release+patches could be one way if we are >>>> not importing pathes too often. but I don't know how often that would >>>> be. For the testing I did release worked well for those platforms >>>> x86, ppc and arm >>> >>> One might suggest, if stable releases are working and you want to live >>> on the bleeding edge in your distro, you can easily do so there… >> >> This is moving forward from where we were so it includes all the git >> commits that were there until cd96b3b86abb4a88cac2722bdfb6e5d4413f6831 >> commit so this update is inclusive. >> >> we can also think of having a stable recipe and a git recipe but systemd >> releases are almost a month apart it would be more or less covered if we >> moved from release to release with some patches if needed. > > If you look at the fedora and debian packages you'll see that they also pull > in a fair number of patches, so it's not uncommon to do what we're doing. ok. However, my original motivation is to make this layer independent enough and remove the layer dependencies it has It will make both layers thrive IMO. I proposed removal of using gitpkgv you did not like that, then I proposed this to remove use of SRCREV completely this also is objected on. may I ask what other option do you have ? I am willing to make a solution. Ultimately this will make systemd integration into OE-Core as reference init system easier.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Op 03-08-12 16:41, Khem Raj schreef: > On Fri, Aug 3, 2012 at 5:38 AM, Koen Kooi <koen@dominion.thruhere.net> > wrote: >> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 >> >> Op 03-08-12 12:32, Khem Raj schreef: >>> >>> On Aug 2, 2012, at 1:11 AM, Paul Eggleton >>> <paul.eggleton@linux.intel.com> wrote: >>> >>>> On Wednesday 01 August 2012 15:56:34 Khem Raj wrote: >>>>> On Aug 1, 2012, at 8:11 AM, Koen Kooi >>>>> <koen@dominion.thruhere.net> wrote: >>>>>>> Along with upgrade use the release tarballs instead of git >>>>>> >>>>>> For an update we need to pull in some patches from master, so a >>>>>> git recipe is still the preferred way. >>>>> >>>>> OK, you know more about it then me but do you know how many >>>>> those will be ? in other words does systemd releases mean much >>>>> for stability yet or still its a project moving at so fast pace >>>>> ? >>>>> >>>>> I see that releases are rolled out almost every month, that sort >>>>> of could mean either way, we wait until the next release or just >>>>> take from a commit upstream >>>>> >>>>> I feel like staying with a release+patches could be one way if we >>>>> are not importing pathes too often. but I don't know how often >>>>> that would be. For the testing I did release worked well for >>>>> those platforms x86, ppc and arm >>>> >>>> One might suggest, if stable releases are working and you want to >>>> live on the bleeding edge in your distro, you can easily do so >>>> there… >>> >>> This is moving forward from where we were so it includes all the git >>> commits that were there until >>> cd96b3b86abb4a88cac2722bdfb6e5d4413f6831 commit so this update is >>> inclusive. >>> >>> we can also think of having a stable recipe and a git recipe but >>> systemd releases are almost a month apart it would be more or less >>> covered if we moved from release to release with some patches if >>> needed. >> >> If you look at the fedora and debian packages you'll see that they also >> pull in a fair number of patches, so it's not uncommon to do what we're >> doing. > > ok. However, my original motivation is to make this layer independent > enough and remove the layer dependencies it has It will make both layers > thrive IMO. I proposed removal of using gitpkgv you did not like that, > then I proposed this to remove use of SRCREV completely this also is > objected on. may I ask what other option do you have ? I am willing to > make a solution. Ultimately this will make systemd integration into > OE-Core as reference init system easier. Move gitpkgv into oe-core -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: GPGTools - http://gpgtools.org iD8DBQFQG/ATMkyGM64RGpERAnAsAKCcUD6itYfYsd2xJLDYXLRoQHJL0ACcCaaH rguf6ChRPi9AZxlufQ3+lsw= =ASlA -----END PGP SIGNATURE-----
On Aug 3, 2012, at 8:36 AM, Koen Kooi <koen@dominion.thruhere.net> wrote: >> . However, my original motivation is to make this layer independent >> enough and remove the layer dependencies it has It will make both layers >> thrive IMO. I proposed removal of using gitpkgv you did not like that, >> then I proposed this to remove use of SRCREV completely this also is >> objected on. may I ask what other option do you have ? I am willing to >> make a solution. Ultimately this will make systemd integration into >> OE-Core as reference init system easier. > > Move gitpkgv into oe-core will it even be necessary with autopr ?
On Fri, Aug 03, 2012 at 11:39:43AM -0700, Khem Raj wrote: > > On Aug 3, 2012, at 8:36 AM, Koen Kooi <koen@dominion.thruhere.net> wrote: > >> . However, my original motivation is to make this layer independent > >> enough and remove the layer dependencies it has It will make both layers > >> thrive IMO. I proposed removal of using gitpkgv you did not like that, > >> then I proposed this to remove use of SRCREV completely this also is > >> objected on. may I ask what other option do you have ? I am willing to > >> make a solution. Ultimately this will make systemd integration into > >> OE-Core as reference init system easier. > > > > Move gitpkgv into oe-core > > > will it even be necessary with autopr ? Yes as PR is applied after SRCPV Cheers,
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Op 03-08-12 20:39, Khem Raj schreef: > > On Aug 3, 2012, at 8:36 AM, Koen Kooi <koen@dominion.thruhere.net> > wrote: >>> . However, my original motivation is to make this layer independent >>> enough and remove the layer dependencies it has It will make both >>> layers thrive IMO. I proposed removal of using gitpkgv you did not >>> like that, then I proposed this to remove use of SRCREV completely >>> this also is objected on. may I ask what other option do you have ? I >>> am willing to make a solution. Ultimately this will make systemd >>> integration into OE-Core as reference init system easier. >> >> Move gitpkgv into oe-core > > > will it even be necessary with autopr ? PV != PR!!!!One!!!!eleven!!!! -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: GPGTools - http://gpgtools.org iD8DBQFQHCGhMkyGM64RGpERAuUrAKCcsXZzLSoVOK6qVS+dHz3ohp5EsgCgs0XS ssK5c/quhHOFaekH02udVn4= =tQVt -----END PGP SIGNATURE-----
On Fri, Aug 3, 2012 at 8:36 AM, Koen Kooi <koen@dominion.thruhere.net> wrote:
> Move gitpkgv into oe-core
OK until I fight moving it into OE-Core :) , I have sent a V4 of
patchset which creates a copy of gitpkgv.bbclass
in meta-systemd. I believe it will be short lived. Please take a look
at them and install if ok
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Op 04-08-12 22:10, Khem Raj schreef: > On Fri, Aug 3, 2012 at 8:36 AM, Koen Kooi <koen@dominion.thruhere.net> > wrote: >> Move gitpkgv into oe-core > > OK until I fight moving it into OE-Core :) , I have sent a V4 of patchset > which creates a copy of gitpkgv.bbclass in meta-systemd. I believe it > will be short lived. Please take a look at them and install if ok Can't you just symlink it from meta-oe? It will be in the same git repo anyway. That would avoid having 2 copies. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: GPGTools - http://gpgtools.org iD8DBQFQHYeGMkyGM64RGpERAgWIAJ9xNd5O/3TMfJCzt4yjP0/Er5JrfwCgg5pp jDXWDi0yfnZ9IjX0uF5x0Z4= =LkJ4 -----END PGP SIGNATURE-----
On Sat, Aug 4, 2012 at 1:35 PM, Koen Kooi <koen@dominion.thruhere.net> wrote: >> On Fri, Aug 3, 2012 at 8:36 AM, Koen Kooi <koen@dominion.thruhere.net> >> wrote: >>> Move gitpkgv into oe-core >> >> OK until I fight moving it into OE-Core :) , I have sent a V4 of patchset >> which creates a copy of gitpkgv.bbclass in meta-systemd. I believe it >> will be short lived. Please take a look at them and install if ok > > Can't you just symlink it from meta-oe? It will be in the same git repo > anyway. That would avoid having 2 copies we dont have synlinks in repo I didnt want to create first one and its reaching across layers moreover this calss seldom changes. If you prefer symlink I can redo that bit
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Op 04-08-12 22:50, Khem Raj schreef: > On Sat, Aug 4, 2012 at 1:35 PM, Koen Kooi <koen@dominion.thruhere.net> > wrote: >>> On Fri, Aug 3, 2012 at 8:36 AM, Koen Kooi >>> <koen@dominion.thruhere.net> wrote: >>>> Move gitpkgv into oe-core >>> >>> OK until I fight moving it into OE-Core :) , I have sent a V4 of >>> patchset which creates a copy of gitpkgv.bbclass in meta-systemd. I >>> believe it will be short lived. Please take a look at them and >>> install if ok >> >> Can't you just symlink it from meta-oe? It will be in the same git >> repo anyway. That would avoid having 2 copies > > we dont have synlinks in repo I didnt want to create first one and its > reaching across layers moreover this calss seldom changes. If you prefer > symlink I can redo that bit Please use a symlink. Whenever there is manual synchronization needed people *will* screw up, just look at kernel.bbclass in meta-oe :) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (Darwin) Comment: GPGTools - http://gpgtools.org iD8DBQFQHlw/MkyGM64RGpERAsFEAJ9GGd0Q8NjGqRGUxLxBTMe/modZ0ACbB2we FCmtXTuVV0fgxg8lUi+Zpbw= =WDO3 -----END PGP SIGNATURE-----
On 08/05/2012 07:42 AM, Koen Kooi wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Op 04-08-12 22:50, Khem Raj schreef: >> On Sat, Aug 4, 2012 at 1:35 PM, Koen Kooi <koen@dominion.thruhere.net> >> wrote: >>>> On Fri, Aug 3, 2012 at 8:36 AM, Koen Kooi >>>> <koen@dominion.thruhere.net> wrote: >>>>> Move gitpkgv into oe-core >>>> >>>> OK until I fight moving it into OE-Core :) , I have sent a V4 of >>>> patchset which creates a copy of gitpkgv.bbclass in meta-systemd. I >>>> believe it will be short lived. Please take a look at them and >>>> install if ok >>> >>> Can't you just symlink it from meta-oe? It will be in the same git >>> repo anyway. That would avoid having 2 copies >> >> we dont have synlinks in repo I didnt want to create first one and its >> reaching across layers moreover this calss seldom changes. If you prefer >> symlink I can redo that bit > > Please use a symlink. Whenever there is manual synchronization needed people > *will* screw up, just look at kernel.bbclass in meta-oe :) Can someone provide a clear explanation of exactly what the gitpkgv class does and why it is needed? Furthermore, does oe-core provide something that could be used? It is clear that ther eis a desire for something like this in two layers, and that makes it a candidate for oe-core. Symlinking stuff across layers is just wrong. The underlying issue has to be resolved. Philip > > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.5 (Darwin) > Comment: GPGTools - http://gpgtools.org > > iD8DBQFQHlw/MkyGM64RGpERAsFEAJ9GGd0Q8NjGqRGUxLxBTMe/modZ0ACbB2we > FCmtXTuVV0fgxg8lUi+Zpbw= > =WDO3 > -----END PGP SIGNATURE----- > > > _______________________________________________ > Openembedded-devel mailing list > Openembedded-devel@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel > >
On Sun, Aug 5, 2012 at 4:53 AM, Philip Balister <philip@balister.org> wrote: > Can someone provide a clear explanation of exactly what the gitpkgv class > does and why it is needed? Furthermore, does oe-core provide something that > could be used? It is clear that ther eis a desire for something like this in > two layers, and that makes it a candidate for oe-core. well oe-core does not have this functionality and it works in most cases and 'most cases' is a problem to get it accepted in oe-core. Its a good feature where it provides a good incremental version from the maze of git SHA ids. That part is good however there is another variable it provides which is GITPKGVTAG that relies on the tags to be incrementally sortable which is broken since tags are arbitrary and systemd uses GITPKGVTAG I think I can defend GITPKGV but GITPKGVTAG will have unanswered questions. ideally bitbake fetcher should provide this functionality > > Symlinking stuff across layers is just wrong. The underlying issue has to be > resolved. I am in agreement. here its deemed to be a short term solution so lets live with it
Patch
diff --git a/meta-systemd/classes/systemd.bbclass b/meta-systemd/classes/systemd.bbclass index dd9f326..4036f91 100644 --- a/meta-systemd/classes/systemd.bbclass +++ b/meta-systemd/classes/systemd.bbclass @@ -154,7 +154,10 @@ python populate_packages_prepend () { # check service-files and call systemd_add_files_and_parse for each entry def systemd_check_services(): - searchpaths = '/etc/systemd/system/ /lib/systemd/system/ /usr/lib/systemd/system/' + base_libdir = d.getVar('base_libdir', 1) + searchpaths = '/etc/systemd/system/' + ' ' + searchpaths += d.getVar('base_libdir', 1) + '/systemd/system/' + ' ' + searchpaths += d.getVar('libdir', 1) + '/systemd/system/' + ' ' systemd_packages = d.getVar('SYSTEMD_PACKAGES', 1) has_exactly_one_service = len(systemd_packages.split()) == 1 if has_exactly_one_service: diff --git a/meta-systemd/recipes-core/systemd/systemd/use-rootlibdir.patch b/meta-systemd/recipes-core/systemd/systemd/use-rootlibdir.patch new file mode 100644 index 0000000..2167216 --- /dev/null +++ b/meta-systemd/recipes-core/systemd/systemd/use-rootlibdir.patch @@ -0,0 +1,94 @@ +Upstream-Status: Undecided + +This patch removes some of hardcoded references to /lib +and /usr/lib since on some architectures it should be +/lib64 and /usr/lib64 atleast in OE + +I am not sure about the intention of hardcoded values +thats why status is undecided + +Signed-off-by: Khem Raj <raj.khem@gmail.com> + +Index: git/Makefile.am +=================================================================== +--- git.orig/Makefile.am 2012-07-22 16:20:38.424405916 -0700 ++++ git/Makefile.am 2012-07-22 16:23:21.232406621 -0700 +@@ -61,23 +61,23 @@ + + # Our own, non-special dirs + pkgsysconfdir=$(sysconfdir)/systemd +-userunitdir=$(prefix)/lib/systemd/user +-tmpfilesdir=$(prefix)/lib/tmpfiles.d +-sysctldir=$(prefix)/lib/sysctl.d +-usergeneratordir=$(prefix)/lib/systemd/user-generators ++userunitdir=$(prefix)/$(rootlibdir)/systemd/user ++tmpfilesdir=$(prefix)/$(rootlibdir)/tmpfiles.d ++sysctldir=$(prefix)/$(rootlibdir)/sysctl.d ++usergeneratordir=$(prefix)/$(rootlibdir)/systemd/user-generators + pkgincludedir=$(includedir)/systemd + systemgeneratordir=$(rootlibexecdir)/system-generators + systemshutdowndir=$(rootlibexecdir)/system-shutdown + systemsleepdir=$(rootlibexecdir)/system-sleep +-systemunitdir=$(rootprefix)/lib/systemd/system +-udevlibexecdir=$(rootprefix)/lib/udev ++systemunitdir=$(rootprefix)/$(rootlibdir)/systemd/system ++udevlibexecdir=$(rootprefix)/$(rootlibdir)/udev + udevhomedir = $(udevlibexecdir) + udevrulesdir = $(udevlibexecdir)/rules.d + + # And these are the special ones for / + rootprefix=@rootprefix@ + rootbindir=$(rootprefix)/bin +-rootlibexecdir=$(rootprefix)/lib/systemd ++rootlibexecdir=$(rootprefix)/$(rootlibdir)/systemd + + CLEANFILES = + EXTRA_DIST = +@@ -126,7 +126,7 @@ + -DSYSTEMD_STDIO_BRIDGE_BINARY_PATH=\"$(bindir)/systemd-stdio-bridge\" \ + -DROOTPREFIX=\"$(rootprefix)\" \ + -DRUNTIME_DIR=\"/run\" \ +- -DRANDOM_SEED=\"$(localstatedir)/lib/random-seed\" \ ++ -DRANDOM_SEED=\"$(localstatedir)/$(rootlibdir)/random-seed\" \ + -DSYSTEMD_CRYPTSETUP_PATH=\"$(rootlibexecdir)/systemd-cryptsetup\" \ + -DSYSTEM_GENERATOR_PATH=\"$(systemgeneratordir)\" \ + -DUSER_GENERATOR_PATH=\"$(usergeneratordir)\" \ +@@ -2535,7 +2535,7 @@ + + binfmt-install-data-hook: + $(MKDIR_P) -m 0755 \ +- $(DESTDIR)$(prefix)/lib/binfmt.d \ ++ $(DESTDIR)$(prefix)/$(rootlibdir)/binfmt.d \ + $(DESTDIR)$(sysconfdir)/binfmt.d \ + $(DESTDIR)$(systemunitdir)/sysinit.target.wants + ( cd $(DESTDIR)$(systemunitdir)/sysinit.target.wants && \ +@@ -3165,7 +3165,7 @@ + logind-install-data-hook: + $(MKDIR_P) -m 0755 \ + $(DESTDIR)$(systemunitdir)/multi-user.target.wants \ +- $(DESTDIR)$(localstatedir)/lib/systemd ++ $(DESTDIR)$(localstatedir)/$(rootlibdir)/systemd + ( cd $(DESTDIR)$(systemunitdir) && \ + rm -f dbus-org.freedesktop.login1.service && \ + $(LN_S) systemd-logind.service dbus-org.freedesktop.login1.service) +@@ -3284,7 +3284,7 @@ + -e 's,@PACKAGE_VERSION\@,$(PACKAGE_VERSION),g' \ + -e 's,@PACKAGE_NAME\@,$(PACKAGE_NAME),g' \ + -e 's,@PACKAGE_URL\@,$(PACKAGE_URL),g' \ +- -e 's,@RANDOM_SEED\@,$(localstatedir)/lib/random-seed,g' \ ++ -e 's,@RANDOM_SEED\@,$(localstatedir)/$(rootlibdir)/random-seed,g' \ + -e 's,@prefix\@,$(prefix),g' \ + -e 's,@exec_prefix\@,$(exec_prefix),g' \ + -e 's,@libdir\@,$(libdir),g' \ +@@ -3407,9 +3407,9 @@ + $(MKDIR_P) -m 0755 \ + $(DESTDIR)$(tmpfilesdir) \ + $(DESTDIR)$(sysconfdir)/tmpfiles.d \ +- $(DESTDIR)$(prefix)/lib/modules-load.d \ ++ $(DESTDIR)$(prefix)/$(rootlibdir)/modules-load.d \ + $(DESTDIR)$(sysconfdir)/modules-load.d \ +- $(DESTDIR)$(prefix)/lib/sysctl.d \ ++ $(DESTDIR)$(prefix)/$(rootlibdir)/sysctl.d \ + $(DESTDIR)$(sysconfdir)/sysctl.d \ + $(DESTDIR)$(systemshutdowndir) \ + $(DESTDIR)$(systemsleepdir) \ diff --git a/meta-systemd/recipes-core/systemd/systemd_187.bb b/meta-systemd/recipes-core/systemd/systemd_187.bb new file mode 100644 index 0000000..a6f6281 --- /dev/null +++ b/meta-systemd/recipes-core/systemd/systemd_187.bb @@ -0,0 +1,220 @@ +DESCRIPTION = "Systemd a init replacement" +HOMEPAGE = "http://www.freedesktop.org/wiki/Software/systemd" + +LICENSE = "GPLv2 & LGPLv2.1 & MIT" +LIC_FILES_CHKSUM = "file://LICENSE.GPL2;md5=751419260aa954499f7abaabaa882bbe \ + file://LICENSE.LGPL2.1;md5=fb919cc88dbe06ec0b0bd50e001ccf1f \ + file://LICENSE.MIT;md5=544799d0b492f119fa04641d1b8868ed" + +PROVIDES = "udev" + +DEPENDS = "xz kmod docbook-sgml-dtd-4.1-native intltool-native gperf-native acl readline dbus libcap libcgroup tcp-wrappers usbutils glib-2.0" +DEPENDS += "${@base_contains('DISTRO_FEATURES', 'pam', 'libpam', '', d)}" + +SERIAL_CONSOLE ?= "115200 /dev/ttyS0" + +SECTION = "base/shell" + +inherit useradd pkgconfig autotools perlnative + +SRC_URI = "http://www.freedesktop.org/software/systemd/${P}.tar.xz \ + file://use-rootlibdir.patch \ + file://gtk-doc.make \ + file://touchscreen.rules \ + file://modprobe.rules \ + file://var-run.conf \ + " + +SRC_URI[md5sum] = "26606e3c84448800ef0b3ffd57e6e8b6" +SRC_URI[sha256sum] = "1a3b338f00cc1ec8b1dcdafe6ce7928f016f70403190db72960df38731fbeed4" + +LDFLAGS_libc-uclibc_append = " -lrt" + +SYSTEMDDISTRO ?= "debian" +SYSTEMDDISTRO_angstrom = "angstrom" + +CACHED_CONFIGUREVARS = "ac_cv_file__usr_share_pci_ids=no \ + ac_cv_file__usr_share_hwdata_pci_ids=no \ + ac_cv_file__usr_share_misc_pci_ids=yes" +# The gtk+ tools should get built as a separate recipe e.g. systemd-tools +EXTRA_OECONF = " --with-distro=${SYSTEMDDISTRO} \ + --with-rootprefix=${base_prefix} \ + --with-rootlibdir=${base_libdir} \ + --sbindir=${base_sbindir} \ + --libexecdir=${base_libdir} \ + ${@base_contains('DISTRO_FEATURES', 'pam', '--enable-pam', '--disable-pam', d)} \ + --enable-xz \ + --disable-manpages \ + --disable-coredump \ + --disable-introspection \ + --with-pci-ids-path=/usr/share/misc \ + --disable-gtk-doc-html \ + --disable-tcpwrap \ + --enable-split-usr \ + " + +# There's no docbook-xsl-native, so for the xsltproc check to false +do_configure_prepend() { + sed -i /xsltproc/d configure.ac + + cp ${WORKDIR}/gtk-doc.make ${S}/docs/ + + # we only have /home/root, not /root + sed -i -e 's:=/root:=/home/root:g' units/*.service* +} + +do_install() { + autotools_do_install + # provided by a seperate recipe + rm ${D}${systemd_unitdir}/system/serial-getty* -f + + # provide support for initramfs + ln -s ${systemd_unitdir}/systemd ${D}/init + + # create dir for journal + install -d ${D}${localstatedir}/log/journal + + # create machine-id + # 20:12 < mezcalero> koen: you have three options: a) run systemd-machine-id-setup at install time, b) have / read-only and an empty file there (for stateless) and c) boot with / writable + touch ${D}${sysconfdir}/machine-id + + install -m 0644 ${WORKDIR}/*.rules ${D}${sysconfdir}/udev/rules.d/ + + install -m 0644 ${WORKDIR}/var-run.conf ${D}${sysconfdir}/tmpfiles.d/ +} + +python populate_packages_prepend (){ + systemdlibdir = d.getVar("base_libdir", True) + do_split_packages(d, systemdlibdir, '^lib(.*)\.so\.*', 'lib%s', 'Systemd %s library', extra_depends='', allow_links=True) +} + +PACKAGES =+ "${PN}-gui ${PN}-vconsole-setup ${PN}-initramfs ${PN}-analyze" + +USERADD_PACKAGES = "${PN}" +GROUPADD_PARAM_${PN} = "-r lock" + +FILES_${PN}-analyze = "${bindir}/systemd-analyze" +RDEPENDS_${PN}-analyze = "python-dbus" +RRECOMMENDS_${PN}-analyze = "python-pycairo" + +FILES_${PN}-initramfs = "/init" +RDEPENDS_${PN}-initramfs = "${PN}" + +FILES_${PN}-gui = "${bindir}/systemadm" + +FILES_${PN}-vconsole-setup = "${systemd_unitdir}/systemd-vconsole-setup \ + ${systemd_unitdir}/system/systemd-vconsole-setup.service \ + ${systemd_unitdir}/system/sysinit.target.wants/systemd-vconsole-setup.service" + +RRECOMMENDS_${PN}-vconsole-setup = "kbd kbd-consolefonts" + +FILES_${PN} = " ${base_bindir}/* \ + ${datadir}/dbus-1/services \ + ${datadir}/dbus-1/system-services \ + ${datadir}/polkit-1 \ + ${datadir}/${PN} \ + ${sysconfdir}/bash_completion.d/ \ + ${sysconfdir}/binfmt.d/ \ + ${sysconfdir}/dbus-1/ \ + ${sysconfdir}/machine-id \ + ${sysconfdir}/modules-load.d/ \ + ${sysconfdir}/sysctl.d/ \ + ${sysconfdir}/systemd/ \ + ${sysconfdir}/tmpfiles.d/ \ + ${sysconfdir}/xdg/ \ + ${systemd_unitdir}/* \ + ${systemd_unitdir}/system/* \ + ${base_libdir}/udev/rules.d/99-systemd.rules \ + ${base_libdir}/security/*.so \ + /cgroup \ + ${bindir}/systemd* \ + ${libdir}/tmpfiles.d/*.conf \ + ${libdir}/systemd \ + ${libdir}/binfmt.d \ + ${libdir}/modules-load.d \ + ${libdir}/sysctl.d \ + ${localstatedir} \ + ${libexecdir} \ + ${base_libdir}/udev/rules.d/70-uaccess.rules \ + ${base_libdir}/udev/rules.d/71-seat.rules \ + ${base_libdir}/udev/rules.d/73-seat-late.rules \ + ${base_libdir}/udev/rules.d/99-systemd.rules \ + " + +FILES_${PN}-dbg += "${systemd_unitdir}/.debug ${systemd_unitdir}/*/.debug ${base_libdir}/security/.debug/" +FILES_${PN}-dev += "${base_libdir}/security/*.la ${datadir}/dbus-1/interfaces/ ${sysconfdir}/rpm/macros.systemd" + +RDEPENDS_${PN} += "dbus-systemd udev-systemd" + +# kbd -> loadkeys,setfont +# systemd calls 'modprobe -sab --', which busybox doesn't support due to lack +# of blacklist support, so use proper modprobe from module-init-tools +# And pull in the kernel modules mentioned in INSTALL +# swapon -p is also not supported by busybox +# busybox mount is broken +RRECOMMENDS_${PN} += "systemd-serialgetty \ + util-linux-agetty \ + util-linux-swaponoff \ + util-linux-fsck e2fsprogs-e2fsck \ + module-init-tools \ + util-linux-mount util-linux-umount \ + kernel-module-autofs4 kernel-module-unix kernel-module-ipv6 \ +" + +PACKAGES =+ "udev-dbg udev udev-consolekit udev-utils udev-systemd" + +FILES_udev-dbg += "${base_libdir}/udev/.debug" + +RDEPENDS_udev += "udev-utils" +RPROVIDES_udev = "hotplug" + +FILES_udev += "${base_libdir}/udev/udevd \ + ${base_libdir}/systemd/systemd-udevd \ + ${base_libdir}/udev/accelerometer \ + ${base_libdir}/udev/ata_id \ + ${base_libdir}/udev/cdrom_id \ + ${base_libdir}/udev/collect \ + ${base_libdir}/udev/findkeyboards \ + ${base_libdir}/udev/keyboard-force-release.sh \ + ${base_libdir}/udev/keymap \ + ${base_libdir}/udev/mtd_probe \ + ${base_libdir}/udev/scsi_id \ + ${base_libdir}/udev/v4l_id \ + ${base_libdir}/udev/keymaps \ + ${base_libdir}/udev/rules.d/4*.rules \ + ${base_libdir}/udev/rules.d/5*.rules \ + ${base_libdir}/udev/rules.d/6*.rules \ + ${base_libdir}/udev/rules.d/70-power-switch.rules \ + ${base_libdir}/udev/rules.d/75*.rules \ + ${base_libdir}/udev/rules.d/78*.rules \ + ${base_libdir}/udev/rules.d/8*.rules \ + ${base_libdir}/udev/rules.d/95*.rules \ + ${sysconfdir}/udev \ + " + +FILES_udev-consolekit += "${libdir}/ConsoleKit" +RDEPENDS_udev-consolekit += "${@base_contains('DISTRO_FEATURES', 'x11', 'consolekit', '', d)}" + +FILES_udev-utils = "${bindir}/udevadm" + +FILES_udev-systemd = "${base_libdir}/systemd/system/*udev* ${base_libdir}/systemd/system/*.wants/*udev*" +RDEPENDS_udev-systemd = "udev" + +# TODO: +# u-a for runlevel and telinit + +pkg_postinst_systemd () { +update-alternatives --install ${base_sbindir}/init init ${systemd_unitdir}/systemd 300 +update-alternatives --install ${base_sbindir}/halt halt ${base_bindir}/systemctl 300 +update-alternatives --install ${base_sbindir}/reboot reboot ${base_bindir}/systemctl 300 +update-alternatives --install ${base_sbindir}/shutdown shutdown ${base_bindir}/systemctl 300 +update-alternatives --install ${base_sbindir}/poweroff poweroff ${base_bindir}/systemctl 300 +} + +pkg_prerm_systemd () { +update-alternatives --remove init ${systemd_unitdir}/systemd +update-alternatives --remove halt ${base_bindir}/systemctl +update-alternatives --remove reboot ${base_bindir}/systemctl +update-alternatives --remove shutdown ${base_bindir}/systemctl +update-alternatives --remove poweroff ${base_bindir}/systemctl +} diff --git a/meta-systemd/recipes-core/systemd/systemd_git.bb b/meta-systemd/recipes-core/systemd/systemd_git.bb deleted file mode 100644 index 39b883a..0000000 --- a/meta-systemd/recipes-core/systemd/systemd_git.bb +++ /dev/null @@ -1,224 +0,0 @@ -DESCRIPTION = "Systemd a init replacement" -HOMEPAGE = "http://www.freedesktop.org/wiki/Software/systemd" - -LICENSE = "GPLv2 & LGPLv2.1 & MIT" -LIC_FILES_CHKSUM = "file://LICENSE.GPL2;md5=751419260aa954499f7abaabaa882bbe \ - file://LICENSE.LGPL2.1;md5=fb919cc88dbe06ec0b0bd50e001ccf1f \ - file://LICENSE.MIT;md5=544799d0b492f119fa04641d1b8868ed" - -PROVIDES = "udev" - -DEPENDS = "xz kmod docbook-sgml-dtd-4.1-native intltool-native gperf-native acl readline dbus libcap libcgroup tcp-wrappers usbutils glib-2.0" -DEPENDS += "${@base_contains('DISTRO_FEATURES', 'pam', 'libpam', '', d)}" - -SERIAL_CONSOLE ?= "115200 /dev/ttyS0" - -SECTION = "base/shell" - -inherit gitpkgv -PKGV = "v${GITPKGVTAG}" - -PV = "git" -PR = "r4" - -inherit useradd pkgconfig autotools vala perlnative - -SRCREV = "cd96b3b86abb4a88cac2722bdfb6e5d4413f6831" - -SRC_URI = "git://anongit.freedesktop.org/systemd/systemd;protocol=git \ - file://gtk-doc.make \ - file://touchscreen.rules \ - file://modprobe.rules \ - file://var-run.conf \ - " -LDFLAGS_libc-uclibc_append = " -lrt" - -S = "${WORKDIR}/git" - -SYSTEMDDISTRO ?= "debian" -SYSTEMDDISTRO_angstrom = "angstrom" - -# The gtk+ tools should get built as a separate recipe e.g. systemd-tools -EXTRA_OECONF = " --with-distro=${SYSTEMDDISTRO} \ - --with-rootprefix=${base_prefix} \ - --with-rootlibdir=${base_libdir} \ - --sbindir=${base_sbindir} \ - --libexecdir=${base_libdir} \ - ${@base_contains('DISTRO_FEATURES', 'pam', '--enable-pam', '--disable-pam', d)} \ - --enable-xz \ - --disable-manpages \ - --disable-coredump \ - --disable-introspection \ - --with-pci-ids-path=/usr/share/misc \ - ac_cv_file__usr_share_pci_ids=no \ - ac_cv_file__usr_share_hwdata_pci_ids=no \ - ac_cv_file__usr_share_misc_pci_ids=yes \ - --disable-gtk-doc-html \ - --disable-tcpwrap \ - " - -# There's no docbook-xsl-native, so for the xsltproc check to false -do_configure_prepend() { - sed -i /xsltproc/d configure.ac - - cp ${WORKDIR}/gtk-doc.make ${S}/docs/ - - # we only have /home/root, not /root - sed -i -e 's:=/root:=/home/root:g' units/*.service* -} - -do_install() { - autotools_do_install - # provided by a seperate recipe - rm ${D}${systemd_unitdir}/system/serial-getty* -f - - # provide support for initramfs - ln -s ${systemd_unitdir}/systemd ${D}/init - - # create dir for journal - install -d ${D}${localstatedir}/log/journal - - # create machine-id - # 20:12 < mezcalero> koen: you have three options: a) run systemd-machine-id-setup at install time, b) have / read-only and an empty file there (for stateless) and c) boot with / writable - touch ${D}${sysconfdir}/machine-id - - install -m 0644 ${WORKDIR}/*.rules ${D}${sysconfdir}/udev/rules.d/ - - install -m 0644 ${WORKDIR}/var-run.conf ${D}${sysconfdir}/tmpfiles.d/ -} - -python populate_packages_prepend (){ - systemdlibdir = d.getVar("base_libdir", True) - do_split_packages(d, systemdlibdir, '^lib(.*)\.so\.*', 'lib%s', 'Systemd %s library', extra_depends='', allow_links=True) -} - -PACKAGES =+ "${PN}-gui ${PN}-vconsole-setup ${PN}-initramfs ${PN}-analyze" - -USERADD_PACKAGES = "${PN}" -GROUPADD_PARAM_${PN} = "-r lock" - -FILES_${PN}-analyze = "${bindir}/systemd-analyze" -RDEPENDS_${PN}-analyze = "python-dbus" -RRECOMMENDS_${PN}-analyze = "python-pycairo" - -FILES_${PN}-initramfs = "/init" -RDEPENDS_${PN}-initramfs = "${PN}" - -FILES_${PN}-gui = "${bindir}/systemadm" - -FILES_${PN}-vconsole-setup = "${systemd_unitdir}/systemd-vconsole-setup \ - ${systemd_unitdir}/system/systemd-vconsole-setup.service \ - ${systemd_unitdir}/system/sysinit.target.wants/systemd-vconsole-setup.service" - -RRECOMMENDS_${PN}-vconsole-setup = "kbd kbd-consolefonts" - -FILES_${PN} = " ${base_bindir}/* \ - ${datadir}/dbus-1/services \ - ${datadir}/dbus-1/system-services \ - ${datadir}/polkit-1 \ - ${datadir}/${PN} \ - ${sysconfdir}/bash_completion.d/ \ - ${sysconfdir}/binfmt.d/ \ - ${sysconfdir}/dbus-1/ \ - ${sysconfdir}/machine-id \ - ${sysconfdir}/modules-load.d/ \ - ${sysconfdir}/sysctl.d/ \ - ${sysconfdir}/systemd/ \ - ${sysconfdir}/tmpfiles.d/ \ - ${sysconfdir}/xdg/ \ - ${systemd_unitdir}/* \ - ${systemd_unitdir}/system/* \ - ${base_libdir}/udev/rules.d/99-systemd.rules \ - ${base_libdir}/security/*.so \ - /cgroup \ - ${bindir}/systemd* \ - ${libdir}/tmpfiles.d/*.conf \ - ${libdir}/systemd \ - ${libdir}/binfmt.d \ - ${libdir}/modules-load.d \ - ${libdir}/sysctl.d \ - ${localstatedir} \ - ${libexecdir} \ - ${base_libdir}/udev/rules.d/70-uaccess.rules \ - ${base_libdir}/udev/rules.d/71-seat.rules \ - ${base_libdir}/udev/rules.d/73-seat-late.rules \ - ${base_libdir}/udev/rules.d/99-systemd.rules \ - " - -FILES_${PN}-dbg += "${systemd_unitdir}/.debug ${systemd_unitdir}/*/.debug ${base_libdir}/security/.debug/" -FILES_${PN}-dev += "${base_libdir}/security/*.la ${datadir}/dbus-1/interfaces/ ${sysconfdir}/rpm/macros.systemd" - -RDEPENDS_${PN} += "dbus-systemd udev-systemd" - -# kbd -> loadkeys,setfont -# systemd calls 'modprobe -sab --', which busybox doesn't support due to lack -# of blacklist support, so use proper modprobe from module-init-tools -# And pull in the kernel modules mentioned in INSTALL -# swapon -p is also not supported by busybox -# busybox mount is broken -RRECOMMENDS_${PN} += "systemd-serialgetty \ - util-linux-agetty \ - util-linux-swaponoff \ - util-linux-fsck e2fsprogs-e2fsck \ - module-init-tools \ - util-linux-mount util-linux-umount \ - kernel-module-autofs4 kernel-module-unix kernel-module-ipv6 \ -" - -PACKAGES =+ "udev-dbg udev udev-consolekit udev-utils udev-systemd" - -FILES_udev-dbg += "${base_libdir}/udev/.debug" - -RDEPENDS_udev += "udev-utils" -RPROVIDES_udev = "hotplug" - -FILES_udev += "${base_libdir}/udev/udevd \ - ${base_libdir}/systemd/systemd-udevd \ - ${base_libdir}/udev/accelerometer \ - ${base_libdir}/udev/ata_id \ - ${base_libdir}/udev/cdrom_id \ - ${base_libdir}/udev/collect \ - ${base_libdir}/udev/findkeyboards \ - ${base_libdir}/udev/keyboard-force-release.sh \ - ${base_libdir}/udev/keymap \ - ${base_libdir}/udev/mtd_probe \ - ${base_libdir}/udev/scsi_id \ - ${base_libdir}/udev/v4l_id \ - ${base_libdir}/udev/keymaps \ - ${base_libdir}/udev/rules.d/4*.rules \ - ${base_libdir}/udev/rules.d/5*.rules \ - ${base_libdir}/udev/rules.d/6*.rules \ - ${base_libdir}/udev/rules.d/70-power-switch.rules \ - ${base_libdir}/udev/rules.d/75*.rules \ - ${base_libdir}/udev/rules.d/78*.rules \ - ${base_libdir}/udev/rules.d/8*.rules \ - ${base_libdir}/udev/rules.d/95*.rules \ - ${sysconfdir}/udev \ - " - -FILES_udev-consolekit += "${libdir}/ConsoleKit" -RDEPENDS_udev-consolekit += "${@base_contains('DISTRO_FEATURES', 'x11', 'consolekit', '', d)}" - -FILES_udev-utils = "${bindir}/udevadm" - -FILES_udev-systemd = "${base_libdir}/systemd/system/*udev* ${base_libdir}/systemd/system/*.wants/*udev*" -RDEPENDS_udev-systemd = "udev" - -# TODO: -# u-a for runlevel and telinit - -pkg_postinst_systemd () { -update-alternatives --install ${base_sbindir}/init init ${systemd_unitdir}/systemd 300 -update-alternatives --install ${base_sbindir}/halt halt ${base_bindir}/systemctl 300 -update-alternatives --install ${base_sbindir}/reboot reboot ${base_bindir}/systemctl 300 -update-alternatives --install ${base_sbindir}/shutdown shutdown ${base_bindir}/systemctl 300 -update-alternatives --install ${base_sbindir}/poweroff poweroff ${base_bindir}/systemctl 300 -} - -pkg_prerm_systemd () { -update-alternatives --remove init ${systemd_unitdir}/systemd -update-alternatives --remove halt ${base_bindir}/systemctl -update-alternatives --remove reboot ${base_bindir}/systemctl -update-alternatives --remove shutdown ${base_bindir}/systemctl -update-alternatives --remove poweroff ${base_bindir}/systemctl -}
Dont inherit vala and gitpkgv not needed anymore Along with upgrade use the release tarballs instead of git Fix build for ppc64 Consider /lib64 and /usr/lib64 Some 64bit architectures chose lib64 instead of lib for default library dirnames. So we dig this from metadata vars base_libdir and libdir instead of hardcoding 'lib' ppc64 in OE uses lib64 for default libdir and this leaves lot of udev/systemd files unpackaged since 'lib' was hardcoded Additionally use --split-usr option since in OE-Core now we want to treat /usr mounted sepatately. Signed-off-by: Khem Raj <raj.khem@gmail.com> --- meta-systemd/classes/systemd.bbclass | 5 +- .../systemd/systemd/use-rootlibdir.patch | 94 ++++++++ meta-systemd/recipes-core/systemd/systemd_187.bb | 220 +++++++++++++++++++ meta-systemd/recipes-core/systemd/systemd_git.bb | 224 -------------------- 4 files changed, 318 insertions(+), 225 deletions(-) create mode 100644 meta-systemd/recipes-core/systemd/systemd/use-rootlibdir.patch create mode 100644 meta-systemd/recipes-core/systemd/systemd_187.bb delete mode 100644 meta-systemd/recipes-core/systemd/systemd_git.bb