[PATCH 0/1] mtools: add glibc-gconv-* to RDEPENDS/RRECOMMENDS

[PATCH 0/1] mtools: add glibc-gconv-* to RDEPENDS/RRECOMMENDS

[xin.ouyang]

From: Xin Ouyang <Xin.Ouyang@windriver.com>

[YOCTO #2829] 

mtools commands use cp850 as the "mtools_default_codepage", they would
use this to do some coverting tasks. 

So, add glibc-gconv-ibm850 to RDEPENDS for mtools commands to run 
correctly.




The following changes since commit 0ffb02eec2beaea27ff0ec9d3d31b0a09e675a4c:

  documentation: Updated the h6 style to use a larger font (2012-07-24 10:35:34 +0100)

are available in the git repository at:

  git://git.pokylinux.org/poky-contrib xouyang/master
  http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=xouyang/master

Xin Ouyang (1):
  mtools: add glibc-gconv-* to RDEPENDS/RRECOMMENDS

 meta/recipes-devtools/mtools/mtools_3.9.9.bb  |   20 +++++++++++++++++++-
 meta/recipes-devtools/mtools/mtools_4.0.17.bb |   20 +++++++++++++++++++-
 2 files changed, 38 insertions(+), 2 deletions(-)

-- 
1.7.9.5

[PATCH 1/1] mtools: add glibc-gconv-* to RDEPENDS/RRECOMMENDS

[xin.ouyang]

From: Xin Ouyang <Xin.Ouyang@windriver.com>

[YOCTO #2829]

mtools commands use cp850 as the "mtools_default_codepage", they would
use this to do some coverting tasks.

So, add glibc-gconv-ibm850 to RDEPENDS for mtools commands to run
correctly.

Also add other MSDOS/FAT codepages related packages to RRECOMMENDS.

Code Pages for MSDOS/FAT:
 *http://msdn.microsoft.com/en-us/library/cc195051.aspx

Signed-off-by: Xin Ouyang <Xin.Ouyang@windriver.com>
---
 meta/recipes-devtools/mtools/mtools_3.9.9.bb  |   20 +++++++++++++++++++-
 meta/recipes-devtools/mtools/mtools_4.0.17.bb |   20 +++++++++++++++++++-
 2 files changed, 38 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/mtools/mtools_3.9.9.bb b/meta/recipes-devtools/mtools/mtools_3.9.9.bb
index cced7da..5f5403a 100644
--- a/meta/recipes-devtools/mtools/mtools_3.9.9.bb
+++ b/meta/recipes-devtools/mtools/mtools_3.9.9.bb
@@ -6,7 +6,25 @@ DESCRIPTION = "Mtools is a collection of utilities for accessing MS-DOS disks fr
 HOMEPAGE = "http://www.gnu.org/software/mtools/"
 LICENSE = "GPLv2+"
 LIC_FILES_CHKSUM = "file://COPYING;md5=92b58ec77696788ce278b044d2a8e9d3"
-PR = "r5"
+PR = "r6"
+
+RDEPENDS_${PN} = "glibc-gconv-ibm850"
+RRECOMMENDS_${PN} = "\
+	glibc-gconv-ibm437 \
+	glibc-gconv-ibm737 \
+	glibc-gconv-ibm775 \
+	glibc-gconv-ibm851 \
+	glibc-gconv-ibm852 \
+	glibc-gconv-ibm855 \
+	glibc-gconv-ibm857 \
+	glibc-gconv-ibm860 \
+	glibc-gconv-ibm861 \
+	glibc-gconv-ibm862 \
+	glibc-gconv-ibm863 \
+	glibc-gconv-ibm865 \
+	glibc-gconv-ibm866 \
+	glibc-gconv-ibm869 \
+	"
 
 #http://mtools.linux.lu/mtools-${PV}.tar.gz 
 SRC_URI = "http://downloads.yoctoproject.org/mirror/sources/mtools-${PV}.tar.gz \
diff --git a/meta/recipes-devtools/mtools/mtools_4.0.17.bb b/meta/recipes-devtools/mtools/mtools_4.0.17.bb
index e4666ff..5ce6c09 100644
--- a/meta/recipes-devtools/mtools/mtools_4.0.17.bb
+++ b/meta/recipes-devtools/mtools/mtools_4.0.17.bb
@@ -5,7 +5,25 @@ SECTION = "optional"
 LICENSE = "GPLv3"
 LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
 
-PR = "r0"
+PR = "r1"
+
+RDEPENDS_${PN} = "glibc-gconv-ibm850"
+RRECOMMENDS_${PN} = "\
+	glibc-gconv-ibm437 \
+	glibc-gconv-ibm737 \
+	glibc-gconv-ibm775 \
+	glibc-gconv-ibm851 \
+	glibc-gconv-ibm852 \
+	glibc-gconv-ibm855 \
+	glibc-gconv-ibm857 \
+	glibc-gconv-ibm860 \
+	glibc-gconv-ibm861 \
+	glibc-gconv-ibm862 \
+	glibc-gconv-ibm863 \
+	glibc-gconv-ibm865 \
+	glibc-gconv-ibm866 \
+	glibc-gconv-ibm869 \
+	"
 
 SRC_URI = "${GNU_MIRROR}/mtools/mtools-${PV}.tar.bz2 \
            file://mtools-makeinfo.patch \
-- 
1.7.9.5

Re: [PATCH 1/1] mtools: add glibc-gconv-* to RDEPENDS/RRECOMMENDS

[Phil Blundell]

On Wed, 2012-07-25 at 15:02 +0800, xin.ouyang@windriver.com wrote:
> +RDEPENDS_${PN} = "glibc-gconv-ibm850"

That will make mtools unbuildable for non-glibc configurations.  Is this
intended?

p.

Package recipes change proposal (system-wide) - name wise

[Iorga, Cristian]

Hello all,

For me, having the version number contained in the name of package recipe is a little bit puzzling.
For example: libpcre/libpcre_8.31.bb

Is there a solid technical reason to not have it like this?

libpcre/libpcre.bb
and inside the recipe to have a PV variable defined:
PV="8.31"

In that case, the upgrade/update process would not involve performing a "git move" operation.
In my opinion, this "git move" operation is something to be avoided, as it puzzles a little bit the versioning system and complicates the review process.

Of course, some changes in the bitbake system would be involved, but I guess would not be too complicated.
Also, there will be a volume of work to be performed for changing the name of recipes and adding the PV variable inside the recipe.
But I guess that a script could solve that, followed by some manual review.

Waiting for some feedback.

Thanks,
Cristian

Cristian Iorga
Linux Software Engineer
Open Source Technology Center
System Software Division Romania
iNET: 88451023

Re: Package recipes change proposal (system-wide) - name wise

[Koen Kooi]

Op 25 jul. 2012, om 09:23 heeft Iorga, Cristian het volgende geschreven:

> 
> Hello all,
> 
> For me, having the version number contained in the name of package recipe is a little bit puzzling.
> For example: libpcre/libpcre_8.31.bb
> 
> Is there a solid technical reason to not have it like this?
> 
> libpcre/libpcre.bb
> and inside the recipe to have a PV variable defined:
> PV="8.31"
> 
> In that case, the upgrade/update process would not involve performing a "git move" operation.
> In my opinion, this "git move" operation is something to be avoided, as it puzzles a little bit the versioning system and complicates the review process.

git format-patch -M

Re: Package recipes change proposal (system-wide) - name wise

[Paul Eggleton]

On Wednesday 25 July 2012 07:23:31 Iorga, Cristian wrote:
> For me, having the version number contained in the name of package recipe is
> a little bit puzzling. For example: libpcre/libpcre_8.31.bb
> 
> Is there a solid technical reason to not have it like this?
> 
> libpcre/libpcre.bb
> and inside the recipe to have a PV variable defined:
> PV="8.31"

The benefit of having PV in the recipe file name is that you can then easily 
have different recipes for different versions of the same piece of software, 
which is particularly useful when those different versions may need to be built 
slightly differently.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: Package recipes change proposal (system-wide) - name wise

[Chris Larson]

On Wed, Jul 25, 2012 at 3:09 AM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> On Wednesday 25 July 2012 07:23:31 Iorga, Cristian wrote:
>> For me, having the version number contained in the name of package recipe is
>> a little bit puzzling. For example: libpcre/libpcre_8.31.bb
>>
>> Is there a solid technical reason to not have it like this?
>>
>> libpcre/libpcre.bb
>> and inside the recipe to have a PV variable defined:
>> PV="8.31"
>
> The benefit of having PV in the recipe file name is that you can then easily
> have different recipes for different versions of the same piece of software,
> which is particularly useful when those different versions may need to be built
> slightly differently.

It's worth noting that that can still be done by leveraging
BBVERSIONS. Not that I'm advocating that approach necessarily, but
noting that it can still be done without using multiple recipes with
version in the filename.
-- 
Christopher Larson

Re: Package recipes change proposal (system-wide) - name wise

[Bruce Ashfield]

On Wed, Jul 25, 2012 at 6:09 AM, Paul Eggleton
<paul.eggleton@linux.intel.com> wrote:
> On Wednesday 25 July 2012 07:23:31 Iorga, Cristian wrote:
>> For me, having the version number contained in the name of package recipe is
>> a little bit puzzling. For example: libpcre/libpcre_8.31.bb
>>
>> Is there a solid technical reason to not have it like this?
>>
>> libpcre/libpcre.bb
>> and inside the recipe to have a PV variable defined:
>> PV="8.31"
>
> The benefit of having PV in the recipe file name is that you can then easily
> have different recipes for different versions of the same piece of software,
> which is particularly useful when those different versions may need to be built
> slightly differently.

And an example would be the three linux-yocto kernel versions. We'd have
to break them out into separate layers if the version wasn't in the filename.

That being said, the linux-yocto-dev recipe doesn't have a version in it's name
for the same reason, it's simpler to keep it moving forward constantly without
the version in the name.

.. just chiming in from the kernel point of view :)

Cheers,

Bruce

>
> Cheers,
> Paul
>
> --
>
> Paul Eggleton
> Intel Open Source Technology Centre
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: Package recipes change proposal (system-wide) - name wise

[Richard Purdie]

On Wed, 2012-07-25 at 07:23 +0000, Iorga, Cristian wrote:
> For me, having the version number contained in the name of package recipe is a little bit puzzling.
> For example: libpcre/libpcre_8.31.bb
> 
> Is there a solid technical reason to not have it like this?
> 
> libpcre/libpcre.bb
> and inside the recipe to have a PV variable defined:
> PV="8.31"

FWIW, you can do that and it will just work, even today. Its just not
the convention we've "grown up" with.

> In that case, the upgrade/update process would not involve performing a "git move" operation.
> In my opinion, this "git move" operation is something to be avoided, as it puzzles a little bit the versioning system and complicates the review process.
> 
> Of course, some changes in the bitbake system would be involved, but I guess would not be too complicated.
> Also, there will be a volume of work to be performed for changing the name of recipes and adding the PV variable inside the recipe.
> But I guess that a script could solve that, followed by some manual review.

The original idea was that updating to new versions was easy, it was a
mv operation. The checksums have of course complicated this idea but the
principle still applies. It also lets you see versions without having to
view the files themselves which I know I personally find very useful.

Also, as others have mentioned, git can detect move operations if you
tell it to.

Cheers,

Richard

Re: Package recipes change proposal (system-wide) - name wise

[Joshua Lock]

On Thu, 2012-07-26 at 20:40 +0100, Richard Purdie wrote:
> On Wed, 2012-07-25 at 07:23 +0000, Iorga, Cristian wrote:
> > For me, having the version number contained in the name of package recipe is a little bit puzzling.
> > For example: libpcre/libpcre_8.31.bb
> > 
> > Is there a solid technical reason to not have it like this?
> > 
> > libpcre/libpcre.bb
> > and inside the recipe to have a PV variable defined:
> > PV="8.31"
> 
> FWIW, you can do that and it will just work, even today. Its just not
> the convention we've "grown up" with.
> 
> > In that case, the upgrade/update process would not involve performing a "git move" operation.
> > In my opinion, this "git move" operation is something to be avoided, as it puzzles a little bit the versioning system and complicates the review process.
> > 
> > Of course, some changes in the bitbake system would be involved, but I guess would not be too complicated.
> > Also, there will be a volume of work to be performed for changing the name of recipes and adding the PV variable inside the recipe.
> > But I guess that a script could solve that, followed by some manual review.
> 
> The original idea was that updating to new versions was easy, it was a
> mv operation. The checksums have of course complicated this idea but the
> principle still applies. It also lets you see versions without having to
> view the files themselves which I know I personally find very useful.
> 
> Also, as others have mentioned, git can detect move operations if you
> tell it to.

FYI the create-pull-request script passes -M40 to git format-patch,
which tells git to:

"should consider a delete/add pair to be a rename if more than 40% of
the file hasn’t changed."

Though with the size of some recipes perhaps the -M value should be
increased, or not passed at all?

Joshua

Re: Package recipes change proposal (system-wide) - name wise

[Anders Darander]

On 26 jul 2012, at 22:43, "Joshua Lock" <josh@linux.intel.com> wrote:
> On Thu, 2012-07-26 at 20:40 +0100, Richard Purdie wrote:
>> 
>> Also, as others have mentioned, git can detect move operations if you
>> tell it to.
> 
> FYI the create-pull-request script passes -M40 to git format-patch,
> which tells git to:
> 
> "should consider a delete/add pair to be a rename if more than 40% of
> the file hasn’t changed."
> 
> Though with the size of some recipes perhaps the -M value should be
> increased, or not passed at all?

No, the -M option shouldn't be removed. Why would you like to increase the percentage needed to handle a delete/add pair as a rename? Rather, it could very well be lowered even more, though the current 40% might be a good compromise.

Detecting a delete/add pair as a rename operation with some further modifications of the recipe does make reviewing the upgrade patches a lot easier...

Cheers,
Anders

Re: Package recipes change proposal (system-wide) - name wise

[Darren Hart]

On 07/28/2012 02:22 AM, Anders Darander wrote:
> 
> On 26 jul 2012, at 22:43, "Joshua Lock" <josh@linux.intel.com>
> wrote:
>> On Thu, 2012-07-26 at 20:40 +0100, Richard Purdie wrote:
>>> 
>>> Also, as others have mentioned, git can detect move operations if
>>> you tell it to.
>> 
>> FYI the create-pull-request script passes -M40 to git
>> format-patch, which tells git to:
>> 
>> "should consider a delete/add pair to be a rename if more than 40%
>> of the file hasn’t changed."
>> 
>> Though with the size of some recipes perhaps the -M value should
>> be increased, or not passed at all?
> 
> No, the -M option shouldn't be removed. Why would you like to
> increase the percentage needed to handle a delete/add pair as a
> rename? Rather, it could very well be lowered even more, though the
> current 40% might be a good compromise.
> 
> Detecting a delete/add pair as a rename operation with some further
> modifications of the recipe does make reviewing the upgrade patches a
> lot easier...

Right, Anders submitted the -M40 change deliberately:

This was introduced as:

commit c8294d1e6da20f82d444a9d866bf5444a002dc5c
Author: Anders Darander <anders@chargestorm.se>
Date:   Tue Aug 16 15:41:34 2011 +0200

    create-pull-request: increase likelihood of detecting a rename

    Decrease the similarity percentage needed to recognize a
delete/add-pair follow
    as a rename.
    This make reviewing patches easier.

    (From OE-Core rev: 3944f5e02d22b70b3bcd733a80f005dbd8e248a2)

    Signed-off-by: Anders Darander <anders@chargestorm.se>
    Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

This hasn't been an issue for me, but I could see that with some of the
minimal recipes that this could trigger some false renames. Still, I
don't see it as a problem.

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Technical Lead - Linux Kernel

Re: [PATCH 0/1] mtools: add glibc-gconv-* to RDEPENDS/RRECOMMENDS

[Saul Wold]

On 07/25/2012 12:02 AM, xin.ouyang@windriver.com wrote:
> From: Xin Ouyang <Xin.Ouyang@windriver.com>
>
> [YOCTO #2829]
>
> mtools commands use cp850 as the "mtools_default_codepage", they would
> use this to do some coverting tasks.
>
> So, add glibc-gconv-ibm850 to RDEPENDS for mtools commands to run
> correctly.
>
>
>
>
> The following changes since commit 0ffb02eec2beaea27ff0ec9d3d31b0a09e675a4c:
>
>    documentation: Updated the h6 style to use a larger font (2012-07-24 10:35:34 +0100)
>
> are available in the git repository at:
>
>    git://git.pokylinux.org/poky-contrib xouyang/master
>    http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=xouyang/master
>
> Xin Ouyang (1):
>    mtools: add glibc-gconv-* to RDEPENDS/RRECOMMENDS
>
>   meta/recipes-devtools/mtools/mtools_3.9.9.bb  |   20 +++++++++++++++++++-
>   meta/recipes-devtools/mtools/mtools_4.0.17.bb |   20 +++++++++++++++++++-
>   2 files changed, 38 insertions(+), 2 deletions(-)
>
Merged into OE-Core

Thanks
	Sau!