Patchwork [oe,meta-oe,2/4] xterm: add latest version of xterm

login
register
mail settings
Submitter Marco Cavallini
Date April 9, 2013, 2:21 p.m.
Message ID <1365517275-30955-1-git-send-email-m.cavallini@koansoftware.com>
Download mbox | patch
Permalink /patch/47707/
State New
Headers show

Comments

Marco Cavallini - April 9, 2013, 2:21 p.m.
* Recipe taken from oe-classic
 * Required by xinput-calibrator

Signed-off-by: Marco Cavallini <m.cavallini@koansoftware.com>
---
 meta/recipes-graphics/xorg-app/xterm_277.bb | 23 +++++++++++++++++++++++
 1 file changed, 23 insertions(+)
 create mode 100644 meta/recipes-graphics/xorg-app/xterm_277.bb
Ross Burton - April 9, 2013, 2:26 p.m.
On 9 April 2013 15:21, Marco Cavallini <koansoftware@gmail.com> wrote:
>  * Recipe taken from oe-classic
>  * Required by xinput-calibrator

oe-core already ships not one but two terminal emulators, let's not
add another one.  Can we make this configurable in the recipe somehow
and default to use matchbox-terminal (which is in the Sato images)?

Long-term, alternatives along the lines of Debian's
x-terminal-emulator is probably something we want.  Then again I'm
still not entirely sure why this is even spawning a terminal in the
first place.

Ross
Martin Jansa - April 9, 2013, 5:46 p.m.
On Tue, Apr 09, 2013 at 03:26:58PM +0100, Burton, Ross wrote:
> On 9 April 2013 15:21, Marco Cavallini <koansoftware@gmail.com> wrote:
> >  * Recipe taken from oe-classic
> >  * Required by xinput-calibrator
> 
> oe-core already ships not one but two terminal emulators, let's not
> add another one.  Can we make this configurable in the recipe somehow
> and default to use matchbox-terminal (which is in the Sato images)?
> 
> Long-term, alternatives along the lines of Debian's
> x-terminal-emulator is probably something we want.  Then again I'm
> still not entirely sure why this is even spawning a terminal in the
> first place.

u-a is not enough, we also need VIRTUAL-RUNTIME-x-terminal-emulator for
other recipes to RDEPENDS/RSUGGESTS/RRECOMMENDS on if they need some
terminal (and don't care which one will be used).
Koen Kooi - April 9, 2013, 6:01 p.m.
Op 9 apr. 2013, om 19:46 heeft Martin Jansa <martin.jansa@gmail.com> het volgende geschreven:

> On Tue, Apr 09, 2013 at 03:26:58PM +0100, Burton, Ross wrote:
>> On 9 April 2013 15:21, Marco Cavallini <koansoftware@gmail.com> wrote:
>>> * Recipe taken from oe-classic
>>> * Required by xinput-calibrator
>> 
>> oe-core already ships not one but two terminal emulators, let's not
>> add another one.  Can we make this configurable in the recipe somehow
>> and default to use matchbox-terminal (which is in the Sato images)?
>> 
>> Long-term, alternatives along the lines of Debian's
>> x-terminal-emulator is probably something we want.  Then again I'm
>> still not entirely sure why this is even spawning a terminal in the
>> first place.
> 
> u-a is not enough, we also need VIRTUAL-RUNTIME-x-terminal-emulator for
> other recipes to RDEPENDS/RSUGGESTS/RRECOMMENDS on if they need some
> terminal (and don't care which one will be used).

Isn't this what xdg-utils are for?
Martin Jansa - April 9, 2013, 7:06 p.m.
On Tue, Apr 09, 2013 at 08:01:21PM +0200, Koen Kooi wrote:
> 
> Op 9 apr. 2013, om 19:46 heeft Martin Jansa <martin.jansa@gmail.com> het volgende geschreven:
> 
> > On Tue, Apr 09, 2013 at 03:26:58PM +0100, Burton, Ross wrote:
> >> On 9 April 2013 15:21, Marco Cavallini <koansoftware@gmail.com> wrote:
> >>> * Recipe taken from oe-classic
> >>> * Required by xinput-calibrator
> >> 
> >> oe-core already ships not one but two terminal emulators, let's not
> >> add another one.  Can we make this configurable in the recipe somehow
> >> and default to use matchbox-terminal (which is in the Sato images)?
> >> 
> >> Long-term, alternatives along the lines of Debian's
> >> x-terminal-emulator is probably something we want.  Then again I'm
> >> still not entirely sure why this is even spawning a terminal in the
> >> first place.
> > 
> > u-a is not enough, we also need VIRTUAL-RUNTIME-x-terminal-emulator for
> > other recipes to RDEPENDS/RSUGGESTS/RRECOMMENDS on if they need some
> > terminal (and don't care which one will be used).
> 
> Isn't this what xdg-utils are for?

Maybe I'm missing something, but I don't see how xdg-utils will help
bitbake to find suitable runtime provider for "any-x-terminal-emulator".
Koen Kooi - April 10, 2013, 5:44 a.m.
Op 9 apr. 2013, om 21:06 heeft Martin Jansa <martin.jansa@gmail.com> het volgende geschreven:

> On Tue, Apr 09, 2013 at 08:01:21PM +0200, Koen Kooi wrote:
>> 
>> Op 9 apr. 2013, om 19:46 heeft Martin Jansa <martin.jansa@gmail.com> het volgende geschreven:
>> 
>>> On Tue, Apr 09, 2013 at 03:26:58PM +0100, Burton, Ross wrote:
>>>> On 9 April 2013 15:21, Marco Cavallini <koansoftware@gmail.com> wrote:
>>>>> * Recipe taken from oe-classic
>>>>> * Required by xinput-calibrator
>>>> 
>>>> oe-core already ships not one but two terminal emulators, let's not
>>>> add another one.  Can we make this configurable in the recipe somehow
>>>> and default to use matchbox-terminal (which is in the Sato images)?
>>>> 
>>>> Long-term, alternatives along the lines of Debian's
>>>> x-terminal-emulator is probably something we want.  Then again I'm
>>>> still not entirely sure why this is even spawning a terminal in the
>>>> first place.
>>> 
>>> u-a is not enough, we also need VIRTUAL-RUNTIME-x-terminal-emulator for
>>> other recipes to RDEPENDS/RSUGGESTS/RRECOMMENDS on if they need some
>>> terminal (and don't care which one will be used).
>> 
>> Isn't this what xdg-utils are for?
> 
> Maybe I'm missing something, but I don't see how xdg-utils will help
> bitbake to find suitable runtime provider for "any-x-terminal-emulator".

Ah, I thought you were after runtime resolving of that, sorry.
Trevor Woerner - April 10, 2013, 4:56 p.m.
This whole thread has me thoroughly confused. Isn't xterm_277.bb already
part of meta-openembedded?

$ find . -name "*xterm*" -print
./meta-openembedded/meta-oe/recipes-graphics/xorg-app/xterm_277.bb

And from what I can tell, it was added over a year ago by Koen:

$ git log meta-oe/recipes-graphics/xorg-app/xterm_277.bb
commit a38efd953c0bfef80fd6819c8339c1d1e79364b3
Author: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
Date:   Thu Dec 13 10:35:26 2012 +0000

    xterm: added gnu-configize for AArch64 support

    Signed-off-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org>
    Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com>

commit 253b1d7bc35c5a2a12dd6a7f2f0c034a34bfae18
Author: Koen Kooi <koen@dominion.thruhere.net>
Date:   Fri Jan 13 09:41:51 2012 +0100

    xterm: update to 277

    License checksum changed due to date changes

    Signed-off-by: Koen Kooi <koen@dominion.thruhere.net>
Marco Cavallini - April 10, 2013, 6:10 p.m.
Il 10/04/2013 18:56, Trevor Woerner ha scritto:
> This whole thread has me thoroughly confused. Isn't xterm_277.bb
> <http://xterm_277.bb> already part of meta-openembedded?
>
> $ find . -name "*xterm*" -print
> ./meta-openembedded/meta-oe/recipes-graphics/xorg-app/xterm_277.bb
> <http://xterm_277.bb>
>
> And from what I can tell, it was added over a year ago by Koen:
>
> $ git log meta-oe/recipes-graphics/xorg-app/xterm_277.bb
> <http://xterm_277.bb>
> commit a38efd953c0bfef80fd6819c8339c1d1e79364b3
> Author: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org
> <mailto:marcin.juszkiewicz@linaro.org>>
> Date:   Thu Dec 13 10:35:26 2012 +0000
>
>      xterm: added gnu-configize for AArch64 support
>      Signed-off-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org
> <mailto:marcin.juszkiewicz@linaro.org>>
>      Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com
> <mailto:Martin.Jansa@gmail.com>>
>
> commit 253b1d7bc35c5a2a12dd6a7f2f0c034a34bfae18
> Author: Koen Kooi <koen@dominion.thruhere.net
> <mailto:koen@dominion.thruhere.net>>
> Date:   Fri Jan 13 09:41:51 2012 +0100
>
>      xterm: update to 277
>      License checksum changed due to date changes
>      Signed-off-by: Koen Kooi <koen@dominion.thruhere.net
> <mailto:koen@dominion.thruhere.net>>
>
>

Yes, it is copied from meta-openembedded into oe-core
Martin Jansa - April 10, 2013, 7:36 p.m.
On Wed, Apr 10, 2013 at 08:10:11PM +0200, Marco wrote:
> Il 10/04/2013 18:56, Trevor Woerner ha scritto:
> > This whole thread has me thoroughly confused. Isn't xterm_277.bb
> > <http://xterm_277.bb> already part of meta-openembedded?
> >
> > $ find . -name "*xterm*" -print
> > ./meta-openembedded/meta-oe/recipes-graphics/xorg-app/xterm_277.bb
> > <http://xterm_277.bb>
> >
> > And from what I can tell, it was added over a year ago by Koen:
> >
> > $ git log meta-oe/recipes-graphics/xorg-app/xterm_277.bb
> > <http://xterm_277.bb>
> > commit a38efd953c0bfef80fd6819c8339c1d1e79364b3
> > Author: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org
> > <mailto:marcin.juszkiewicz@linaro.org>>
> > Date:   Thu Dec 13 10:35:26 2012 +0000
> >
> >      xterm: added gnu-configize for AArch64 support
> >      Signed-off-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org
> > <mailto:marcin.juszkiewicz@linaro.org>>
> >      Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com
> > <mailto:Martin.Jansa@gmail.com>>
> >
> > commit 253b1d7bc35c5a2a12dd6a7f2f0c034a34bfae18
> > Author: Koen Kooi <koen@dominion.thruhere.net
> > <mailto:koen@dominion.thruhere.net>>
> > Date:   Fri Jan 13 09:41:51 2012 +0100
> >
> >      xterm: update to 277
> >      License checksum changed due to date changes
> >      Signed-off-by: Koen Kooi <koen@dominion.thruhere.net
> > <mailto:koen@dominion.thruhere.net>>
> >
> >
> 
> Yes, it is copied from meta-openembedded into oe-core

Then you should fix commit message too

 * Recipe taken from oe-classic                                                                                                                               

In all recipes you sent to oe-core.
Mark Hatle - April 10, 2013, 7:43 p.m.
On 4/10/13 2:36 PM, Martin Jansa wrote:
> On Wed, Apr 10, 2013 at 08:10:11PM +0200, Marco wrote:
>> Il 10/04/2013 18:56, Trevor Woerner ha scritto:
>>> This whole thread has me thoroughly confused. Isn't xterm_277.bb
>>> <http://xterm_277.bb> already part of meta-openembedded?
>>>
>>> $ find . -name "*xterm*" -print
>>> ./meta-openembedded/meta-oe/recipes-graphics/xorg-app/xterm_277.bb
>>> <http://xterm_277.bb>
>>>
>>> And from what I can tell, it was added over a year ago by Koen:
>>>
>>> $ git log meta-oe/recipes-graphics/xorg-app/xterm_277.bb
>>> <http://xterm_277.bb>
>>> commit a38efd953c0bfef80fd6819c8339c1d1e79364b3
>>> Author: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org
>>> <mailto:marcin.juszkiewicz@linaro.org>>
>>> Date:   Thu Dec 13 10:35:26 2012 +0000
>>>
>>>       xterm: added gnu-configize for AArch64 support
>>>       Signed-off-by: Marcin Juszkiewicz <marcin.juszkiewicz@linaro.org
>>> <mailto:marcin.juszkiewicz@linaro.org>>
>>>       Signed-off-by: Martin Jansa <Martin.Jansa@gmail.com
>>> <mailto:Martin.Jansa@gmail.com>>
>>>
>>> commit 253b1d7bc35c5a2a12dd6a7f2f0c034a34bfae18
>>> Author: Koen Kooi <koen@dominion.thruhere.net
>>> <mailto:koen@dominion.thruhere.net>>
>>> Date:   Fri Jan 13 09:41:51 2012 +0100
>>>
>>>       xterm: update to 277
>>>       License checksum changed due to date changes
>>>       Signed-off-by: Koen Kooi <koen@dominion.thruhere.net
>>> <mailto:koen@dominion.thruhere.net>>
>>>
>>>
>>
>> Yes, it is copied from meta-openembedded into oe-core
>
> Then you should fix commit message too
>
>   * Recipe taken from oe-classic
>
> In all recipes you sent to oe-core.

See: http://openembedded.org/wiki/Commit_Patch_Message_Guidelines

Specifically the Example: Importing fro Elsewhere Unmodified (and modified)

It's a good idea to list where it came from the commit.. that way if the 
original location is ever changed, people can track what changes may need to be 
merged in.

--Mark

>
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>
Trevor Woerner - April 10, 2013, 10:44 p.m.
On Wed, Apr 10, 2013 at 2:10 PM, Marco <koansoftware@gmail.com> wrote:
> Yes, it is copied from meta-openembedded into oe-core

I'm sorry, I thought the [meta-oe] in the subject line implied this
patch was destined for meta-openembedded, not coming from
meta-openembedded.

It seems rather confusing that both openembedded-core and
meta-openembedded use the same mailing list :-)

Is openembedded-core sometimes referred to as oe-classic? Or is that
something else?

Do poky and openembedded-core maintain their own meta-hob and
meta-skeleton components?
Denys Dmytriyenko - April 10, 2013, 10:53 p.m.
On Wed, Apr 10, 2013 at 06:44:21PM -0400, Trevor Woerner wrote:
> On Wed, Apr 10, 2013 at 2:10 PM, Marco <koansoftware@gmail.com> wrote:
> > Yes, it is copied from meta-openembedded into oe-core
> 
> I'm sorry, I thought the [meta-oe] in the subject line implied this
> patch was destined for meta-openembedded, not coming from
> meta-openembedded.

Agree.


> It seems rather confusing that both openembedded-core and
> meta-openembedded use the same mailing list :-)

They are not - meta-openembedded uses the old 
openembedded-devel@lists.openembedded.org list from Classic OE days:
http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/README


> Is openembedded-core sometimes referred to as oe-classic? Or is that
> something else?

That's something else:
http://openembedded.org/wiki/OpenEmbedded-Core


> Do poky and openembedded-core maintain their own meta-hob and
> meta-skeleton components?

http://cgit.openembedded.org/openembedded-core/tree/
http://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/
Marco Cavallini - April 11, 2013, 9:02 a.m.
Il 10/04/2013 21:43, Mark Hatle ha scritto:

>>> Yes, it is copied from meta-openembedded into oe-core
>>
>> Then you should fix commit message too
>>
>>   * Recipe taken from oe-classic
>>
>> In all recipes you sent to oe-core.
>
> See: http://openembedded.org/wiki/Commit_Patch_Message_Guidelines
>
> Specifically the Example: Importing fro Elsewhere Unmodified (and modified)
>
> It's a good idea to list where it came from the commit.. that way if the
> original location is ever changed, people can track what changes may
> need to be merged in.
>

OK
thank you Mark
Marco Cavallini - April 11, 2013, 9:04 a.m.
Il 11/04/2013 00:53, Denys Dmytriyenko ha scritto:
> On Wed, Apr 10, 2013 at 06:44:21PM -0400, Trevor Woerner wrote:
>> On Wed, Apr 10, 2013 at 2:10 PM, Marco <koansoftware@gmail.com> wrote:
>>> Yes, it is copied from meta-openembedded into oe-core
>>
>> I'm sorry, I thought the [meta-oe] in the subject line implied this
>> patch was destined for meta-openembedded, not coming from
>> meta-openembedded.
>
> Agree.
>


[meta-oe] was my fauly, I already sent my apologies in IRC yesterday :-(
Sorry

Patch

diff --git a/meta/recipes-graphics/xorg-app/xterm_277.bb b/meta/recipes-graphics/xorg-app/xterm_277.bb
new file mode 100644
index 0000000..18abe35
--- /dev/null
+++ b/meta/recipes-graphics/xorg-app/xterm_277.bb
@@ -0,0 +1,23 @@ 
+require recipes-graphics/xorg-app/xorg-app-common.inc
+DESCRIPTION = "xterm is the standard terminal emulator for the X Window System."
+DEPENDS = "libxaw xproto xextproto libxext libxau libxpm ncurses"
+
+LIC_FILES_CHKSUM = "file://xterm.h;beginline=3;endline=33;md5=71d7532e485b8d325906bd751617e2a4"
+
+SRC_URI = "ftp://invisible-island.net/xterm/${PN}-${PV}.tgz"
+SRC_URI[md5sum] = "c0de5c2f7b3a50244c5cdd53dcab1de5"
+SRC_URI[sha256sum] = "6cd38606e4179a874220f33dfd41063f93cd1c717aa26c742beb7adea3c1471e"
+
+EXTRA_OECONF = " --x-includes=${STAGING_INCDIR} \
+                 --x-libraries=${STAGING_LIBDIR} \
+                 FREETYPE_CONFIG=${STAGING_BINDIR_CROSS}/freetype-config \
+                 --disable-imake \
+                 --disable-setuid"
+
+do_configure() {
+        gnu-configize --force
+        sed -e "s%/usr/contrib/X11R6%${STAGING_LIBDIR}%g" -i configure
+        oe_runconf
+}
+
+FILES_${PN} += " /usr/lib/X11"