Re: [OE-core] Patchwork & patch handling improvements

2015-11-29 Thread Paul Eggleton 
Hi Armin,

On Friday 27 November 2015 09:15:39 akuster808 wrote:
> On 11/26/2015 01:00 PM, Paul Eggleton wrote:
> > Over the past several years one of the regular complaints people have made
> > about our project has been that patches sometimes take a long time to make
> > it into master, and it's not always clear what the state of a patch is
> > during that time. On the other side of things, maintainers are finding it
> > increasingly hard to keep up with testing and integrating incoming
> > patches.
> 
> This is not all the result of the patchwork. As a maintainer I rarely
> use the patchwork in work flow as I have no access to the state change
> bits. So its harder to integrate patchwork into my workflow.

So I would argue you should have access to that and we should arrange it; 
having said that though my idea is any manual status updates with Patchwork 
should be minimal - we should pick up as much as we can from other actions 
you're already carrying out e.g. pushing the patch to your staging branch, 
running that through the autobuilder, etc. About the only ones where we can't 
pick something up would be where the patch is rejected, deferred, or master 
has moved on or the patch overlaps with another person's patch such that you 
ask the submitter to rebase; in those cases someone will need to mark the 
patch in patchwork by hand. Thinking aloud though it's possible we could do 
this via email if we embedded some kind of directive to patchwork in the reply 
to the mailing list; not sure how people feel about that idea but I think it's 
at least a possibility.

> Since the rules are to wait for changes to hit Master before moving them
> down the line adds time to merging patches to the stable branches. The
> Patchwork does not have an impact on that delay.

Not directly, but my hope is that automating a lot of this is going to smooth 
the flow of patches into master so that that part of the delay is minimised.

> What adds to the challenge of integrating patches is that a layer
> maintainer may shoot a patch directly into the stable branch so if I had
> that patch queued, I now have to back it out.

I agree that would generate a bit more work, but shouldn't it be as 
straightforward as a rebase though?

> Also, I do this work all on my free time so I do my work in batches with
> leads to some delay. I could probably do a better job at communication
> where things are in the process.

As far as I've seen you've been pretty proactive as far as communicating 
things goes, and it's definitely appreciated :)

>  Additionally,
> 
> > trivial mistakes sometimes creep in that would be fairly easy to catch
> > with an automated process. We've been talking about this for a while and
> > now I'd like to propose a plan to finally address this:
> > 
> > 1) Upgrade the OE Patchwork instance [0] to a newer release; this should
> > fix some of the problems we are having [1] plus give us additional
> > features. I propose using the fork that freedesktop.org are using [2] [3]
> > which is moving a bit faster than upstream Patchwork; whilst the changes
> > there may eventually make it upstream (and work is ongoing there) we have
> > a much greater ability to influence the fork given that it's being worked
> > on by one of my colleagues who is pushing it in the direction we need it
> > to go e.g. proper support for series as opposed to treating every patch
> > individually, improved UI, etc.
>
> Yes please.
> 
> > 2) Trigger automatic testing of submitted patches from Patchwork. We'd
> > have a script look at the contents of a patch and first check that the
> > expected style has been adhered to; second it would do some quick tests
> > to verify that the patch hasn't caused any immediately obvious
> > regressions. I've filed some bugs to cover this in more detail [4].
> 
> sounds good.
> 
> > 3) Provide a means to easily schedule an overnight build on the
> > autobuilder
> > for the set of patches that have passed the initial testing, as well as
> > present the results in a form that's easier to review for maintainers. For
> > OE- Core this would be tied into the Yocto Project autobuilder, but I
> > expect the tools could be made flexible.
> > 
> > At all stages through this process the patch status in patchwork will be
> > kept up-to-date so it's clear to everyone what's happening. I'm also
> > thinking we could do email notifications to the submitter (opt-in) though
> > that would be a later add-on.
> > 
> > Whilst the initial plan covers only OE-Core, once we get them working the
> > tools and scripts used should be just as applicable to other layers. I'm
> > also trying to ensure that the patch validation is generic enough so it
> > can live in OE-Core, and thus we can easily update and refine it over
> > time in line with the code itself as well as encourage submitters to use
> > the script on their own changes before sending.
> 
> Yes, I would like to use this with meta-oe
> 
> > Please let me know your thoughts

[OE-core] [PATCH] harfbuzz: update 1.1.0 -> 1.1.2

2015-11-29 Thread Andre McCurdy 
  http://cgit.freedesktop.org/harfbuzz/tree/NEWS

Overview of changes leading to 1.1.2
Wednesday, November 26, 2015


- Fix badly-broken fallback shaper that affected terminology.
  https://github.com/behdad/harfbuzz/issues/187
- Fix y_scaling in Graphite shaper.
- API changes:
  * An unset glyph_h_origin() function in font-funcs now (sensibly)
implies horizontal origin at 0,0.  Ie, the nil callback returns
true instead of false.  As such, implementations that have a
glyph_h_origin() that simply returns true, can remove that function
with HarfBuzz >= 1.1.2.  This results in a tiny speedup.

Overview of changes leading to 1.1.1
Wednesday, November 24, 2015


- Build fixes, specially for hb-coretext.

Signed-off-by: Andre McCurdy 
---
 .../harfbuzz/{harfbuzz_1.1.0.bb => harfbuzz_1.1.2.bb} | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-graphics/harfbuzz/{harfbuzz_1.1.0.bb => harfbuzz_1.1.2.bb} 
(88%)

diff --git a/meta/recipes-graphics/harfbuzz/harfbuzz_1.1.0.bb 
b/meta/recipes-graphics/harfbuzz/harfbuzz_1.1.2.bb
similarity index 88%
rename from meta/recipes-graphics/harfbuzz/harfbuzz_1.1.0.bb
rename to meta/recipes-graphics/harfbuzz/harfbuzz_1.1.2.bb
index e12dc0d..f34a647 100644
--- a/meta/recipes-graphics/harfbuzz/harfbuzz_1.1.0.bb
+++ b/meta/recipes-graphics/harfbuzz/harfbuzz_1.1.2.bb
@@ -11,8 +11,8 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=e021dd6dda6ff1e6b1044002fc662b9b \
 SECTION = "libs"
 
 SRC_URI = "http://www.freedesktop.org/software/harfbuzz/release/${BP}.tar.bz2;
-SRC_URI[md5sum] = "1223cefac2bc77298ff5c7422bb148d5"
-SRC_URI[sha256sum] = 
"0f584a5947e60ede565e7a4e122baa5e4b17a62eab872abf5f73d8552ceb716b"
+SRC_URI[md5sum] = "e6210d3cfd4064d95621fc16913268ed"
+SRC_URI[sha256sum] = 
"4a2c5790bd3db7c3ca8c02e4858f2fd592df7932c1d2fa9f6b99acbce0f8461f"
 
 inherit autotools pkgconfig lib_package
 
-- 
1.9.1

-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] [PATCH] opkg: add cache filename length fixes

2015-11-29 Thread Robert Yang 



On 11/27/2015 05:53 AM, Nicolas Dechesne wrote:

hi,

+Robert.

On Fri, Nov 13, 2015 at 4:59 PM, Alejandro del Castillo
 wrote:

Signed-off-by: Alejandro del Castillo 
---
  ...ng_util-New-file-with-bin_to_hex-function.patch | 122 +
  .../opkg/0002-md5-Add-md5_to_string-function.patch | 110 +++
  ...0003-sha256-Add-sha256_to_string-function.patch | 110 +++
  ...4-opkg_download-Use-short-cache-file-name.patch |  85 ++
  meta/recipes-devtools/opkg/opkg_0.3.0.bb   |   4 +
  5 files changed, 431 insertions(+)
  create mode 100644 
meta/recipes-devtools/opkg/opkg/0001-string_util-New-file-with-bin_to_hex-function.patch
  create mode 100644 
meta/recipes-devtools/opkg/opkg/0002-md5-Add-md5_to_string-function.patch
  create mode 100644 
meta/recipes-devtools/opkg/opkg/0003-sha256-Add-sha256_to_string-function.patch
  create mode 100644 
meta/recipes-devtools/opkg/opkg/0004-opkg_download-Use-short-cache-file-name.patch


Can this patch be backported to jethro? My jethro builds fail without
it.. I can carry in my layer, but I believe this would be better in OE
core.

If needed, I can prepare and test the patch.


Thanks, fine to me to backport it.

// Robert



thanks


--
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: [OE-core] Should the devmem2 recipe move to oe-core?

2015-11-29 Thread Andre McCurdy 
On Sat, Nov 28, 2015 at 6:30 PM, Philip Balister  wrote:
> I was poking at the layer index and ran across this:
>
> http://layers.openembedded.org/layerindex/branch/master/recipes/?q=devmem
>
> The recipe appears in 4 layers.
>
> Should we just move it to openembedded-core?

The busybox version appears to be better maintained (it's gained
support for 64bit data types, which is still missing from the
original), so maybe better to recommend the busybox version instead.

> I wonder how easy it would
> be to have the layer index report duplicate recipes?
>
> Philip
> --
> ___
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
-- 
___
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core