Patchwork [meta-webserver,0/6] Add meta-webserver

login
register
mail settings
Submitter Paul Eggleton
Date Oct. 1, 2012, 4:14 p.m.
Message ID <cover.1349107616.git.paul.eggleton@linux.intel.com>
Download mbox
Permalink /patch/37559/
State Superseded
Headers show

Pull-request

git://git.openembedded.org/meta-openembedded-contrib paule/meta-webserver-add

Comments

Paul Eggleton - Oct. 1, 2012, 4:14 p.m.
So finally I have got this into a working state; apologies for the
delay. There were a number of issues affecting cross-compilation as well
as some problems with the initial configuration; these should now be
addressed. We may wish to look at a more standard directory layout for
Apache as the default one doesn't seem to be used by most distributions;
we can look at this later - for now let's get the recipes out there so
people can try them out.

I know there are a few people waiting to submit additional recipes for
this layer and I expect we will also want to look at moving some
web-server related recipes from meta-oe into here at some point in the
near future.


The following changes since commit 7bfff4b1d6b0067ddabf2474320e3e78795b2b4f:

  uhd,fuse: Fix misplaced quotations (2012-09-28 22:50:42 +0200)

are available in the git repository at:

  git://git.openembedded.org/meta-openembedded-contrib paule/meta-webserver-add
  http://cgit.openembedded.org/cgit.cgi/meta-openembedded-contrib/log/?h=paule/meta-webserver-add

Paul Eggleton (6):
  Add meta-webserver layer
  apache2: add from OE-Classic
  modphp: add from OE-Classic
  apache2: update to version 2.4.2 and fix
  modphp: update to 5.3.14 and fix
  xdebug: add new recipe

 meta-webserver/COPYING.MIT                         |   17 +
 meta-webserver/README                              |   37 +++
 meta-webserver/conf/layer.conf                     |   13 +
 .../apache2-2.4.2/apache-configure_perlbin.patch   |   37 +++
 .../apache2-2.4.2/apache-ssl-ltmain-rpath.patch    |   76 +++++
 .../apache2/apache2-2.4.2/fix-libtool-name.patch   |   55 +++
 .../apache2-2.4.2/httpd-2.4.1-corelimit.patch      |   37 +++
 .../apache2/apache2-2.4.2/httpd-2.4.1-export.patch |   22 ++
 .../apache2-2.4.2/httpd-2.4.1-selinux.patch        |   63 ++++
 .../apache2-2.4.2/httpd-2.4.2-r1326980+.patch      |   74 +++++
 .../apache2-2.4.2/httpd-2.4.2-r1327036+.patch      |   87 +++++
 .../apache2-2.4.2/httpd-2.4.2-r1332643.patch       |  260 +++++++++++++++
 .../apache2-2.4.2/httpd-2.4.2-r1337344+.patch      |  350 ++++++++++++++++++++
 .../apache2-2.4.2/httpd-2.4.2-restart.patch        |   35 ++
 .../replace-lynx-to-curl-in-apachectl-script.patch |   52 +++
 .../apache2/apache2-2.4.2/server-makefile.patch    |   11 +
 .../recipes-httpd/apache2/apache2-native_2.4.2.bb  |   43 +++
 .../recipes-httpd/apache2/apache2_2.4.2.bb         |  130 ++++++++
 meta-webserver/recipes-httpd/apache2/files/init    |   63 ++++
 .../recipes-php/modphp/files/70_mod_php5.conf      |   12 +
 .../recipes-php/modphp/files/configure.patch       |   11 +
 .../recipes-php/modphp/files/pthread-check.patch   |   64 ++++
 meta-webserver/recipes-php/modphp/modphp5.inc      |   91 +++++
 meta-webserver/recipes-php/modphp/modphp_5.3.14.bb |    5 +
 meta-webserver/recipes-php/xdebug/xdebug_2.2.1.bb  |   29 ++
 25 files changed, 1674 insertions(+)
 create mode 100644 meta-webserver/COPYING.MIT
 create mode 100644 meta-webserver/README
 create mode 100644 meta-webserver/conf/layer.conf
 create mode 100644 meta-webserver/recipes-httpd/apache2/apache2-2.4.2/apache-configure_perlbin.patch
 create mode 100644 meta-webserver/recipes-httpd/apache2/apache2-2.4.2/apache-ssl-ltmain-rpath.patch
 create mode 100644 meta-webserver/recipes-httpd/apache2/apache2-2.4.2/fix-libtool-name.patch
 create mode 100644 meta-webserver/recipes-httpd/apache2/apache2-2.4.2/httpd-2.4.1-corelimit.patch
 create mode 100644 meta-webserver/recipes-httpd/apache2/apache2-2.4.2/httpd-2.4.1-export.patch
 create mode 100644 meta-webserver/recipes-httpd/apache2/apache2-2.4.2/httpd-2.4.1-selinux.patch
 create mode 100644 meta-webserver/recipes-httpd/apache2/apache2-2.4.2/httpd-2.4.2-r1326980+.patch
 create mode 100644 meta-webserver/recipes-httpd/apache2/apache2-2.4.2/httpd-2.4.2-r1327036+.patch
 create mode 100644 meta-webserver/recipes-httpd/apache2/apache2-2.4.2/httpd-2.4.2-r1332643.patch
 create mode 100644 meta-webserver/recipes-httpd/apache2/apache2-2.4.2/httpd-2.4.2-r1337344+.patch
 create mode 100644 meta-webserver/recipes-httpd/apache2/apache2-2.4.2/httpd-2.4.2-restart.patch
 create mode 100644 meta-webserver/recipes-httpd/apache2/apache2-2.4.2/replace-lynx-to-curl-in-apachectl-script.patch
 create mode 100644 meta-webserver/recipes-httpd/apache2/apache2-2.4.2/server-makefile.patch
 create mode 100644 meta-webserver/recipes-httpd/apache2/apache2-native_2.4.2.bb
 create mode 100644 meta-webserver/recipes-httpd/apache2/apache2_2.4.2.bb
 create mode 100755 meta-webserver/recipes-httpd/apache2/files/init
 create mode 100644 meta-webserver/recipes-php/modphp/files/70_mod_php5.conf
 create mode 100644 meta-webserver/recipes-php/modphp/files/configure.patch
 create mode 100644 meta-webserver/recipes-php/modphp/files/pthread-check.patch
 create mode 100644 meta-webserver/recipes-php/modphp/modphp5.inc
 create mode 100644 meta-webserver/recipes-php/modphp/modphp_5.3.14.bb
 create mode 100644 meta-webserver/recipes-php/xdebug/xdebug_2.2.1.bb
Koen Kooi - Oct. 2, 2012, 2:40 p.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Op 01-10-12 18:14, Paul Eggleton schreef:
> So finally I have got this into a working state; apologies for the delay.
> There were a number of issues affecting cross-compilation as well as some
> problems with the initial configuration; these should now be addressed.
> We may wish to look at a more standard directory layout for Apache as the
> default one doesn't seem to be used by most distributions; we can look at
> this later - for now let's get the recipes out there so people can try
> them out.
> 
> I know there are a few people waiting to submit additional recipes for 
> this layer and I expect we will also want to look at moving some 
> web-server related recipes from meta-oe into here at some point in the 
> near future.

How does this compare to meta-networking?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: GPGTools - http://gpgtools.org

iD8DBQFQavz3MkyGM64RGpERAnFmAJwJBHthgpRyWHCa3ECpmk6OUuMs5gCeOtDa
9BWYkISAbsBLbxmhcf89yGU=
=shQt
-----END PGP SIGNATURE-----
Paul Eggleton - Oct. 2, 2012, 2:53 p.m.
On Tuesday 02 October 2012 16:40:55 Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Op 01-10-12 18:14, Paul Eggleton schreef:
> > So finally I have got this into a working state; apologies for the delay.
> > There were a number of issues affecting cross-compilation as well as some
> > problems with the initial configuration; these should now be addressed.
> > We may wish to look at a more standard directory layout for Apache as the
> > default one doesn't seem to be used by most distributions; we can look at
> > this later - for now let's get the recipes out there so people can try
> > them out.
> > 
> > I know there are a few people waiting to submit additional recipes for
> > this layer and I expect we will also want to look at moving some
> > web-server related recipes from meta-oe into here at some point in the
> > near future.
> 
> How does this compare to meta-networking?

It's separate; this focuses just on web-based items (on the server side). I'm
not sure how much it will actually grow but you can imagine in the extreme
case we could end up with a number of web servers, several standalone web
admin interfaces, a bunch of web frameworks and related recipes for each of
the latter. All of that would bloat out meta-networking a bit too much,
hence this separate layer.

I did send an RFC for this a couple of months ago, although the scope has
been refined a little since then:

http://www.mail-archive.com/openembedded-devel@lists.openembedded.org/msg26071.html

Cheers,
Paul
Koen Kooi - Oct. 3, 2012, 10:24 a.m.
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Op 01-10-12 18:14, Paul Eggleton schreef:
> So finally I have got this into a working state; apologies for the delay.
> There were a number of issues affecting cross-compilation as well as some
> problems with the initial configuration; these should now be addressed.
> We may wish to look at a more standard directory layout for Apache as the
> default one doesn't seem to be used by most distributions; we can look at
> this later - for now let's get the recipes out there so people can try
> them out.
> 
> I know there are a few people waiting to submit additional recipes for 
> this layer and I expect we will also want to look at moving some 
> web-server related recipes from meta-oe into here at some point in the 
> near future.
> 
> 
> The following changes since commit
> 7bfff4b1d6b0067ddabf2474320e3e78795b2b4f:
> 
> uhd,fuse: Fix misplaced quotations (2012-09-28 22:50:42 +0200)
> 
> are available in the git repository at:
> 
> git://git.openembedded.org/meta-openembedded-contrib
> paule/meta-webserver-add 
> http://cgit.openembedded.org/cgit.cgi/meta-openembedded-contrib/log/?h=paule/meta-webserver-add
>
>  Paul Eggleton (6): Add meta-webserver layer apache2: add from
> OE-Classic modphp: add from OE-Classic apache2: update to version 2.4.2
> and fix modphp: update to 5.3.14 and fix xdebug: add new recipe

Squash those "import" with the "fix" commits, no sense in having a broken
recipe in there.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: GPGTools - http://gpgtools.org

iD8DBQFQbBJTMkyGM64RGpERAnW0AKCEqJZSIe3A+BJ7h8VchN/jKfV0BgCeOcM8
sKPvfhNA7x2tyEhwEj6dw/M=
=5Lcn
-----END PGP SIGNATURE-----
Paul Eggleton - Oct. 3, 2012, 10:43 a.m.
On Wednesday 03 October 2012 12:24:19 Koen Kooi wrote:
> Squash those "import" with the "fix" commits, no sense in having a broken
> recipe in there.

I'd rather not - there is sense in being clear about the changes, because 
there are a large number of them in this case.

Cheers,
Paul
Koen Kooi - Oct. 3, 2012, 11:27 a.m.
Op 3 okt. 2012 om 12:43 heeft Paul Eggleton <paul.eggleton@linux.intel.com> het volgende geschreven:

> On Wednesday 03 October 2012 12:24:19 Koen Kooi wrote:
>> Squash those "import" with the "fix" commits, no sense in having a broken
>> recipe in there.
> 
> I'd rather not - there is sense in being clear about the changes, because 
> there are a large number of them in this case.

The broken recipes are still available in OE classic if people want to compare them. I still don't get why you want to have broken recipes in the tree at multiple points in your series.


> 
> Cheers,
> Paul
> 
> -- 
> 
> Paul Eggleton
> Intel Open Source Technology Centre
Paul Eggleton - Oct. 3, 2012, 11:29 a.m.
On Wednesday 03 October 2012 13:27:41 Koen Kooi wrote:
> Op 3 okt. 2012 om 12:43 heeft Paul Eggleton <paul.eggleton@linux.intel.com> 
het volgende geschreven:
> > On Wednesday 03 October 2012 12:24:19 Koen Kooi wrote:
> >> Squash those "import" with the "fix" commits, no sense in having a broken
> >> recipe in there.
> > 
> > I'd rather not - there is sense in being clear about the changes, because
> > there are a large number of them in this case.
> 
> The broken recipes are still available in OE classic if people want to
> compare them. I still don't get why you want to have broken recipes in the
> tree at multiple points in your series.

Because I want to easily see in "git blame" where particular lines came from - 
did I add them, or have they been around for ages?

Cheers,
Paul
Koen Kooi - Oct. 3, 2012, 11:43 a.m.
Op 3 okt. 2012, om 13:29 heeft Paul Eggleton <paul.eggleton@linux.intel.com> het volgende geschreven:

> On Wednesday 03 October 2012 13:27:41 Koen Kooi wrote:
>> Op 3 okt. 2012 om 12:43 heeft Paul Eggleton <paul.eggleton@linux.intel.com> 
> het volgende geschreven:
>>> On Wednesday 03 October 2012 12:24:19 Koen Kooi wrote:
>>>> Squash those "import" with the "fix" commits, no sense in having a broken
>>>> recipe in there.
>>> 
>>> I'd rather not - there is sense in being clear about the changes, because
>>> there are a large number of them in this case.
>> 
>> The broken recipes are still available in OE classic if people want to
>> compare them. I still don't get why you want to have broken recipes in the
>> tree at multiple points in your series.
> 
> Because I want to easily see in "git blame" where particular lines came from - 
> did I add them, or have they been around for ages?

Does oe-core have the same flow for new recipes?
Paul Eggleton - Oct. 3, 2012, 12:23 p.m.
On Wednesday 03 October 2012 13:43:30 Koen Kooi wrote:
> Op 3 okt. 2012, om 13:29 heeft Paul Eggleton <paul.eggleton@linux.intel.com> 
het volgende geschreven:
> > On Wednesday 03 October 2012 13:27:41 Koen Kooi wrote:
> >> Op 3 okt. 2012 om 12:43 heeft Paul Eggleton
> >> <paul.eggleton@linux.intel.com>
> > 
> > het volgende geschreven:
> >>> On Wednesday 03 October 2012 12:24:19 Koen Kooi wrote:
> >>>> Squash those "import" with the "fix" commits, no sense in having a
> >>>> broken
> >>>> recipe in there.
> >>> 
> >>> I'd rather not - there is sense in being clear about the changes,
> >>> because
> >>> there are a large number of them in this case.
> >> 
> >> The broken recipes are still available in OE classic if people want to
> >> compare them. I still don't get why you want to have broken recipes in
> >> the
> >> tree at multiple points in your series.
> > 
> > Because I want to easily see in "git blame" where particular lines came
> > from - did I add them, or have they been around for ages?
> 
> Does oe-core have the same flow for new recipes?

You already know the answer to this.

Cheers,
Paul
Koen Kooi - Oct. 3, 2012, 1:12 p.m.
Op 3 okt. 2012, om 14:23 heeft Paul Eggleton <paul.eggleton@linux.intel.com> het volgende geschreven:

> On Wednesday 03 October 2012 13:43:30 Koen Kooi wrote:
>> Op 3 okt. 2012, om 13:29 heeft Paul Eggleton <paul.eggleton@linux.intel.com> 
> het volgende geschreven:
>>> On Wednesday 03 October 2012 13:27:41 Koen Kooi wrote:
>>>> Op 3 okt. 2012 om 12:43 heeft Paul Eggleton
>>>> <paul.eggleton@linux.intel.com>
>>> 
>>> het volgende geschreven:
>>>>> On Wednesday 03 October 2012 12:24:19 Koen Kooi wrote:
>>>>>> Squash those "import" with the "fix" commits, no sense in having a
>>>>>> broken
>>>>>> recipe in there.
>>>>> 
>>>>> I'd rather not - there is sense in being clear about the changes,
>>>>> because
>>>>> there are a large number of them in this case.
>>>> 
>>>> The broken recipes are still available in OE classic if people want to
>>>> compare them. I still don't get why you want to have broken recipes in
>>>> the
>>>> tree at multiple points in your series.
>>> 
>>> Because I want to easily see in "git blame" where particular lines came
>>> from - did I add them, or have they been around for ages?
>> 
>> Does oe-core have the same flow for new recipes?
> 
> You already know the answer to this.

No I don't, actually.
Paul Eggleton - Oct. 3, 2012, 1:43 p.m.
On Wednesday 03 October 2012 15:12:55 Koen Kooi wrote:
> Op 3 okt. 2012, om 14:23 heeft Paul Eggleton <paul.eggleton@linux.intel.com> 
het volgende geschreven:
> > On Wednesday 03 October 2012 13:43:30 Koen Kooi wrote:
> >> Op 3 okt. 2012, om 13:29 heeft Paul Eggleton
> >> <paul.eggleton@linux.intel.com>> 
> > het volgende geschreven:
> >>> On Wednesday 03 October 2012 13:27:41 Koen Kooi wrote:
> >>>> Op 3 okt. 2012 om 12:43 heeft Paul Eggleton
> >>>> <paul.eggleton@linux.intel.com>
> >>> 
> >>> het volgende geschreven:
> >>>>> On Wednesday 03 October 2012 12:24:19 Koen Kooi wrote:
> >>>>>> Squash those "import" with the "fix" commits, no sense in having a
> >>>>>> broken
> >>>>>> recipe in there.
> >>>>> 
> >>>>> I'd rather not - there is sense in being clear about the changes,
> >>>>> because
> >>>>> there are a large number of them in this case.
> >>>> 
> >>>> The broken recipes are still available in OE classic if people want to
> >>>> compare them. I still don't get why you want to have broken recipes in
> >>>> the
> >>>> tree at multiple points in your series.
> >>> 
> >>> Because I want to easily see in "git blame" where particular lines came
> >>> from - did I add them, or have they been around for ages?
> >> 
> >> Does oe-core have the same flow for new recipes?
> > 
> > You already know the answer to this.
> 
> No I don't, actually.

The answer is no, it doesn't.

I guess on reflection we probably ought to be consistent here though - for 
better or worse, this is not what has been done when pulling in recipes from 
OE-Classic for the rest of meta-openembedded. The commit message does already 
list the changes from the original, and I'll concede that having just one 
revision doesn't give a huge amount in the way of insight on previous origin; 
ultimately as you say, OE-Classic is still there as a reference for that.

OK, I've squashed those commits out on the branch. Would it be worth me 
posting a v2 after all these changes?

Cheers,
Paul
McClintock Matthew-B29882 - Oct. 3, 2012, 2:08 p.m.
On Wed, Oct 3, 2012 at 8:43 AM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> The answer is no, it doesn't.
>
> I guess on reflection we probably ought to be consistent here though - for
> better or worse, this is not what has been done when pulling in recipes from
> OE-Classic for the rest of meta-openembedded. The commit message does already
> list the changes from the original, and I'll concede that having just one
> revision doesn't give a huge amount in the way of insight on previous origin;
> ultimately as you say, OE-Classic is still there as a reference for that.
>
> OK, I've squashed those commits out on the branch. Would it be worth me
> posting a v2 after all these changes?

Actually, this is one really annoying thing about OE. When people
rename the file 'git blame' comes worthless. Is there a way around
this?

-M
Paul Eggleton - Oct. 3, 2012, 2:18 p.m.
On Wednesday 03 October 2012 14:08:16 McClintock Matthew-B29882 wrote:
> On Wed, Oct 3, 2012 at 8:43 AM, Paul Eggleton
> 
> <paul.eggleton@linux.intel.com> wrote:
> > The answer is no, it doesn't.
> > 
> > I guess on reflection we probably ought to be consistent here though - for
> > better or worse, this is not what has been done when pulling in recipes
> > from OE-Classic for the rest of meta-openembedded. The commit message
> > does already list the changes from the original, and I'll concede that
> > having just one revision doesn't give a huge amount in the way of insight
> > on previous origin; ultimately as you say, OE-Classic is still there as a
> > reference for that.
> > 
> > OK, I've squashed those commits out on the branch. Would it be worth me
> > posting a v2 after all these changes?
> 
> Actually, this is one really annoying thing about OE. When people
> rename the file 'git blame' comes worthless. Is there a way around
> this?

Usually it picks up on renames just fine, but as with git diff -M there is some 
fuzziness in how it determines the difference between a file rename and an 
unrelated delete followed by an add; sometimes the difference is too great for 
git to consider as a rename with its default settings. I just tested, you can 
improve rename detection with git blame by using the -C option though; 
adjusting the -M value might also help.

Cheers,
Paul
Khem Raj - Oct. 3, 2012, 2:19 p.m.
On Wed, Oct 3, 2012 at 7:08 AM, McClintock Matthew-B29882
<B29882@freescale.com> wrote:
> On Wed, Oct 3, 2012 at 8:43 AM, Paul Eggleton
> <paul.eggleton@linux.intel.com> wrote:
>> The answer is no, it doesn't.
>>
>> I guess on reflection we probably ought to be consistent here though - for
>> better or worse, this is not what has been done when pulling in recipes from
>> OE-Classic for the rest of meta-openembedded. The commit message does already
>> list the changes from the original, and I'll concede that having just one
>> revision doesn't give a huge amount in the way of insight on previous origin;
>> ultimately as you say, OE-Classic is still there as a reference for that.
>>
>> OK, I've squashed those commits out on the branch. Would it be worth me
>> posting a v2 after all these changes?
>
> Actually, this is one really annoying thing about OE. When people
> rename the file 'git blame' comes worthless. Is there a way around
> this?
>

does git blame -M -C help ?

> -M
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel