Re: [go-nuts] Re: Test, test coverage & httptest.Server

You should be able to do that with: http://damien.lespiau.name/2017/05/building-and-using-coverage.html HTH, -- Damien On 18 June 2017 at 17:49, Jérôme LAFORGE wrote: > Hello, > Can I consider that no workaround? > Thx > > Le dimanche 21 mai 2017 09:48:01 UTC+2,

Re: [Nouveau] [PATCH 5/6] drm: Delete "mandatory" stereographic modes

On Wed, Jan 18, 2017 at 11:27:16AM -0500, Ilia Mirkin wrote: > Damien - did you ever test these mandatory modes on an actual > commercial 3D TV or similar device? My main testing device was a Samsung TV with this 3D_present bit set and all the advertised modes were working. Can't quite remember

Re: [Nouveau] [PATCH 5/6] drm: Delete "mandatory" stereographic modes

On Wed, Jan 18, 2017 at 01:48:04PM -0500, Ilia Mirkin wrote: > After some more conversations with Alastair, it sounds like what's > actually going on is that it's just the frame-packing modes that > aren't working, but all the side-by-side and top-and-bottom modes from > the "mandatory" list work.

Re: [Nouveau] [PATCH 5/6] drm: Delete "mandatory" stereographic modes

On Wed, Jan 18, 2017 at 04:33:43PM +, Damien Lespiau wrote: > On Wed, Jan 18, 2017 at 11:27:16AM -0500, Ilia Mirkin wrote: > > Damien - did you ever test these mandatory modes on an actual > > commercial 3D TV or similar device? > > My main testing device was a Samsung TV

Re: [Nouveau] [PATCH 5/6] drm: Delete "mandatory" stereographic modes

On Wed, Jan 18, 2017 at 12:10:56AM -0500, Ilia Mirkin wrote: > On Tue, Jan 17, 2017 at 5:42 PM, Alastair Bridgewater > wrote: > > HDMI specification 1.4a, table 8-15 is very explicitly a "must > > support at least one of" table, not a "must support all of" table. >

Re: [Nouveau] [PATCH 5/6] drm: Delete "mandatory" stereographic modes

On Wed, Jan 18, 2017 at 01:48:04PM -0500, Ilia Mirkin wrote: > After some more conversations with Alastair, it sounds like what's > actually going on is that it's just the frame-packing modes that > aren't working, but all the side-by-side and top-and-bottom modes from > the "mandatory" list work.

Re: [Nouveau] [PATCH 5/6] drm: Delete "mandatory" stereographic modes

On Wed, Jan 18, 2017 at 04:33:43PM +, Damien Lespiau wrote: > On Wed, Jan 18, 2017 at 11:27:16AM -0500, Ilia Mirkin wrote: > > Damien - did you ever test these mandatory modes on an actual > > commercial 3D TV or similar device? > > My main testing device was a Samsung TV

Re: [Nouveau] [PATCH 5/6] drm: Delete "mandatory" stereographic modes

On Wed, Jan 18, 2017 at 11:27:16AM -0500, Ilia Mirkin wrote: > Damien - did you ever test these mandatory modes on an actual > commercial 3D TV or similar device? My main testing device was a Samsung TV with this 3D_present bit set and all the advertised modes were working. Can't quite remember

Re: [Nouveau] [PATCH 5/6] drm: Delete "mandatory" stereographic modes

On Wed, Jan 18, 2017 at 12:10:56AM -0500, Ilia Mirkin wrote: > On Tue, Jan 17, 2017 at 5:42 PM, Alastair Bridgewater > wrote: > > HDMI specification 1.4a, table 8-15 is very explicitly a "must > > support at least one of" table, not a "must support all of" table. >

Re: [Mesa-dev] [PATCH] egl/x11: avoid using freed memory if dri2 init fails

On Mon, Aug 15, 2016 at 11:46:40AM -0700, Kristian Høgsberg wrote: > On Mon, Aug 15, 2016 at 11:33 AM, ⚛ <0xe2.0x9a.0...@gmail.com> wrote: > > On Mon, Aug 15, 2016 at 8:08 PM, Emil Velikov > > wrote: > >> > >> On 4 August 2016 at 03:13, Nicolas Boichat

Re: [Intel-gfx] [PATCH i-g-t] tests: Fix compilation when some gcc configurations

On Thu, Jul 14, 2016 at 06:48:26PM +0100, Chris Wilson wrote: > On Thu, Jul 14, 2016 at 06:44:59PM +0100, Chris Wilson wrote: > > On Thu, Jul 14, 2016 at 06:31:37PM +0100, Damien Lespiau wrote: > > > Depending how the gcc was compiled it may be necessary to enable SSE4

[Intel-gfx] [PATCH i-g-t] tests: Fix compilation when some gcc configurations

; # error "SSE4.1 instruction set not enabled" ^ v2: Use a pragma directive (Chris) Cc: Chris Wilson <ch...@chris-wilson.co.uk> Signed-off-by: Damien Lespiau <damien.lesp...@intel.com> --- tests/gem_exec_flush.c | 1 + tests/gem_gtt_speed.c | 1 + 2 files changed, 2 i

[Intel-gfx] [PATCH i-g-t] tests: Fix compilation when some gcc configurations

ilson.co.uk> Signed-off-by: Damien Lespiau <damien.lesp...@intel.com> --- tests/Makefile.am | 2 ++ 1 file changed, 2 insertions(+) diff --git a/tests/Makefile.am b/tests/Makefile.am index 102b8a6..8c6b0a3 100644 --- a/tests/Makefile.am +++ b/tests/Makefile.am @@ -76,6 +76,7 @@ ge

[Intel-gfx] [PATCH] drm/i915: Eliminate dead code in intel_sanitize_enable_ppgtt()

We exit early if has_aliasing_ppgtt is 0, so towards the end of the function has_aliasing_ppgtt can only be 1. Also: if (foo) return 1; else return 0; when foo is already a bool is really just: return foo; Signed-off-by: Damien Lespiau

Re: [Intel-gfx] [PATCH i-g-t] assembler/: Fix lex warnings for %empty and %nonassoc.

On Thu, May 19, 2016 at 07:02:40AM -0700, Ben Widawsky wrote: > On Thu, May 19, 2016 at 12:28:10PM +0100, Damien Lespiau wrote: > > On Mon, May 16, 2016 at 01:39:10PM +0300, Marius Vlad wrote: > > > Signed-off-by: Marius Vlad <marius.c.v...@intel.com> > > >

Re: [Intel-gfx] [PATCH i-g-t] assembler/: Fix lex warnings for %empty and %nonassoc.

ay to test the change is to regenerate the vaapi shaders from source and check for differences in the generated opcodes. https://cgit.freedesktop.org/vaapi/intel-driver/ If all the shaders do compile and there's no difference in the generated code, this is: Acked-by: Damien Lespiau <damien.lesp..

Re: [Intel-gfx] [PATCH i-g-t] benchmarks/, overlay/, demos/, tools/, tests/: Add optional Werror.

On Tue, May 10, 2016 at 05:32:15PM +0300, Marius Vlad wrote: > v2: Initially added Werror by default. Make it optional so it doesn't > break android build and (potential) distros maintaing the package > (Hinted by Damien Lespiau). > > --enable-werror will enable -Werror compiler fl

Re: [Intel-gfx] [PATCH i-g-t] benchmarks/, overlay/, demos/, tools/, tests/: Add Werror by default.

On Mon, May 09, 2016 at 06:55:12PM +0300, Marius Vlad wrote: > > Adding a test (with patchwork integration!) that ensures each commit > > posted on this mailing-list compiles without new warning with a chosen > > toolchain (and even passes distcheck!) would be nice. > We have this for check and

Re: [Intel-gfx] [PATCH i-g-t] benchmarks/, overlay/, demos/, tools/, tests/: Add Werror by default.

On Mon, May 09, 2016 at 04:23:44PM +0300, Marius Vlad wrote: > Easier to catch compilation errors. Having -Werror by default is a no go as you cannot control/predict the set of warnings (and the quality of those) of all previous and future gcc/clang versions. Always using this flag will cause

Re: [PATCH 1/2] wsgi: Move wsgi file to expected location

On Fri, Feb 05, 2016 at 05:35:37PM +, Stephen Finucane wrote: > Django places a wsgi.py file in the root of each application's > directory. Do this, adding a symlink to preserve existing > operation for users. Even if the commit message mentions a symlink, there isn't one in the commit?

Re: [PATCH 2/2] xmlrpc: Treat negative max_count as meaning "return last N results"

On Fri, Feb 05, 2016 at 05:21:20PM +, Stephen Finucane wrote: > @@ -602,6 +607,8 @@ def patch_list(filt=None): > > if max_count > 0: > return list(map(patch_to_dict, patches[:max_count])) > +elif max_count < 0: > +return list(map(patch_to_dict,

Re: getting meta-data out of patchwork

On Wed, Mar 23, 2016 at 09:01:43AM -0500, Andy Doan wrote: > On 03/22/2016 10:41 PM, Jeremy Kerr wrote: > >Hi Stephen, > > > >>Is there anyway to get statistics out of patchwork about how long > >>patches sit around, reject/accept rates, and patch sizes? > > > >There's no exposed interface for

Re: [Intel-gfx] [PATCH RESEND FOR CI] drm/i915: Fix races on fbdev

Hi Lukas, I'm sorry I haven't reacted sooner. I've enabled the option to only consider git send-email patches on intel-gfx as we were having a lot of false positives (ie patchwork considering emails were people were making suggestions with diffs as patches to test). I'm not sure how you send

News from the freedesktop.org patchwork I

Hi all, I've written about the current state of the patchwork deployed on freedesktop.org. This might be of some interest to some of you to understand where that branch is going: http://damien.lespiau.name/2016/02/augmenting-mailing-lists-with-patchwork.html In particular, the testing part

Re: [Mesa-dev] [PATCH v2 i-g-t] igt/list-workarounds: Extend the script to Mesa

On Fri, Feb 05, 2016 at 04:12:08PM -0800, Dylan Baker wrote: > > > parse(work_arounds) > > > + print "\nList of workarounds found in %s:" % project > > Hey Damien, the script says it's python 3, and this ^^^ is broken syntax > in python 3 (but not in 2). :( I did notice the python2

Re: [Intel-gfx] [Mesa-dev] [PATCH v2 i-g-t] igt/list-workarounds: Extend the script to Mesa

On Fri, Feb 05, 2016 at 04:12:08PM -0800, Dylan Baker wrote: > > > parse(work_arounds) > > > + print "\nList of workarounds found in %s:" % project > > Hey Damien, the script says it's python 3, and this ^^^ is broken syntax > in python 3 (but not in 2). :( I did notice the python2

[Intel-gfx] [PATCH i-g-t] list-workarounds: Fix python 2 print statement

m> Signed-off-by: Damien Lespiau <damien.lesp...@intel.com> --- scripts/list-workarounds | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/list-workarounds b/scripts/list-workarounds index 8b41ae5..70c026d 100755 --- a/scripts/list-workarounds +++ b/script

Re: Patch tagging/classification

On Mon, Feb 08, 2016 at 04:39:15PM +0200, Ruslan Kuprieiev wrote: > Hi Damien, > > That looks great! > Is it a pure pwclient you are using? This is a different version of patchwork that I maintain for our own use (I'm part of the i915 kernel team at Intel). That version is deployed on

Re: Patch tagging/classification

On Mon, Feb 08, 2016 at 03:28:26PM +0200, Ruslan Kuprieiev wrote: > Hi All, > > Btw, is patchwork able to group several patches from one patchset? > I.e. typical git-send-email structure: > [PATCH 00/03] intro > |-[PATCH 01/03] first > |-[PATCH 02/03] second > |-[PATCH 03/03] third >

Re: Patch tagging/classification

On Mon, Feb 08, 2016 at 08:08:58PM +0200, Ruslan Kuprieiev wrote: > >As mentioned before, Freedesktop's patchwork has a somewhat strong > >opinion on distribution dependencies. It favours deploying patchwork in > >an isolated, sateless, WM/container (or at least in a virtualenv) with a > >tight

Re: Patch tagging/classification

On Mon, Feb 08, 2016 at 04:18:53PM +0100, Thomas Petazzoni wrote: > I think it's not a big deal if patchwork sometimes doesn't recognize a > new version of a series as being a new version, and leaves it to the > project admins to mark the old version of the series as superseded > manually. > >

Re: Patch tagging/classification

On Mon, Feb 08, 2016 at 05:19:37PM +0200, Ruslan Kuprieiev wrote: > It looks fantastic, and it is exactly what I've been looking for for a long > time now. > Why aren't these features merged into base patchwork yet? I wanted to make some fairly big design decisions that didn't resonate well with

Re: [Mesa-dev] [PATCH] list-workarounds: Extend the script to Mesa

On Thu, Feb 04, 2016 at 06:14:02PM +, Kibey, Sameer wrote: > Updated the list-workarounds script so that it > can parse Mesa directory if provided. Moved the > common code to a separate function to allow > reuse for both kernel and mesa. > > The new command line is: > Usage: list-workarounds

Re: [Intel-gfx] [PATCH] list-workarounds: Extend the script to Mesa

On Thu, Feb 04, 2016 at 06:14:02PM +, Kibey, Sameer wrote: > Updated the list-workarounds script so that it > can parse Mesa directory if provided. Moved the > common code to a separate function to allow > reuse for both kernel and mesa. > > The new command line is: > Usage: list-workarounds

Re: [Mesa-dev] [PATCH v2 i-g-t] igt/list-workarounds: Extend the script to Mesa

On Fri, Feb 05, 2016 at 01:55:19PM -0800, Sameer Kibey wrote: > Updated the list-workarounds script so that it > can parse Mesa directory if provided. Moved the > common code to a separate function to allow > reuse for both kernel and mesa. > > The new command line is: > Usage: list-workarounds

Re: [Intel-gfx] [PATCH v2 i-g-t] igt/list-workarounds: Extend the script to Mesa

On Fri, Feb 05, 2016 at 01:55:19PM -0800, Sameer Kibey wrote: > Updated the list-workarounds script so that it > can parse Mesa directory if provided. Moved the > common code to a separate function to allow > reuse for both kernel and mesa. > > The new command line is: > Usage: list-workarounds

[Intel-gfx] [PATCH xf86-video-intel] Sync PCI ids with latest kernel, adding more BXT devices

commit 985dd4360fdf2533fe48a33a4a2094f2e4718dc0 Author: Imre Deak <imre.d...@intel.com> Date: Thu Jan 28 16:04:12 2016 +0200 drm/i915/bxt: update list of PCIIDs Signed-off-by: Damien Lespiau <damien.lesp...@intel.com> --- src/i915_pciids.h | 4 +++- 1 file changed,

Re: [Intel-gfx] [PATCH v3] drm/i915/skl/kbl: Add support for pipe fusing

t; v2: Don't store the pipe disabled mask in device info (Damien) > > v3: Don't check FUSE_STRAP register for pipe c disabled > > Cc: Damien Lespiau <damien.lesp...@intel.com> > Signed-off-by: Patrik Jakobsson <patrik.jakobs...@linux.intel.com> Reviewed-by: Damien

Re: [Intel-gfx] ✗ Fi.CI.BAT: failure for MAINTAINERS: Add "B:" preferred bug reporting method (rev3)

On Wed, Jan 27, 2016 at 09:16:24AM -0800, Joe Perches wrote: > On Wed, 2016-01-27 at 16:47 +, Patchwork wrote: > > == Summary == > > > > Built on 5ae916607e3e12ba18c848dff42baaad5b118c4b drm-intel-nightly: > > 2016y-01m-27d-12h-48m-36s UTC integration manifest > > I've no idea what this

[Intel-gfx] [PATCH libdrm] xf86drm: Bound strstr() to the allocated data

On Fri, Jan 22, 2016 at 04:48:05PM +0200, Ville Syrjälä wrote: > On Fri, Jan 22, 2016 at 12:51:23PM +0000, Damien Lespiau wrote: > > We are reading at most sizeof(data) bytes, but then data may not contain > > a terminating '\0', at least in theory, so strstr() may overflo

[PATCH libdrm] xf86drm: Bound strstr() to the allocated data

We are reading at most sizeof(data) bytes, but then data may not contain a terminating '\0', at least in theory, so strstr() may overflow the stack allocated array. Make sure that data always contains at least one '\0'. Signed-off-by: Damien Lespiau --- xf86drm.c | 3 ++- 1 file changed, 2

Re: [Intel-gfx] ✗ Fi.CI.BAT: warning for FBC crtc/fb locking + smaller fixes

On Thu, Jan 21, 2016 at 08:14:34PM +, Zanoni, Paulo R wrote: > Em Ter, 2016-01-19 às 14:50 +, Patchwork escreveu: > > == Summary == > > > > Built on 20c388faff9d8c41ab27e825c685526561b892a2 drm-intel-nightly: > > 2016y-01m-19d-13h-31m-46s UTC integration manifest > > > > Test kms_flip: >

[Intel-gfx] [PATCH libdrm] xf86drm: Bound strstr() to the allocated data

We are reading at most sizeof(data) bytes, but then data may not contain a terminating '\0', at least in theory, so strstr() may overflow the stack allocated array. Make sure that data always contains at least one '\0'. Signed-off-by: Damien Lespiau <damien.lesp...@intel.com> --- xf86drm

Re: [Intel-gfx] [PATCH libdrm] xf86drm: Bound strstr() to the allocated data

On Fri, Jan 22, 2016 at 04:48:05PM +0200, Ville Syrjälä wrote: > On Fri, Jan 22, 2016 at 12:51:23PM +0000, Damien Lespiau wrote: > > We are reading at most sizeof(data) bytes, but then data may not contain > > a terminating '\0', at least in theory, so strstr() may overflow the >

Re: [Intel-gfx] [PATCH i-g-t] tools/Android.mk: Add zlib support

On Fri, Jan 15, 2016 at 03:49:00PM +, Morton, Derek J wrote: > Can this be merged so IGT on Android builds? No one has raise any > objections since Monday about this patch. Merged, thanks for the patch. -- Damien ___ Intel-gfx mailing list

Re: [Intel-gfx] [PATCH 7/7] drm/i915/skl: WA for watermark calculation based on Arbitrated Display BW

On Thu, Jan 14, 2016 at 11:30:31PM +0800, kbuild test robot wrote: > Hi Mahesh, > > [auto build test ERROR on drm-intel/for-linux-next] > [also build test ERROR on next-20160114] > [cannot apply to v4.4] > [if your patch is applied to the wrong git tree, please drop us a note to > help improving

Re: [Intel-gfx] [PATCH v2] drm/i915: Handle PipeC fused off on GEN7+

On Wed, Jan 13, 2016 at 04:46:43PM +0200, Gabriel Feceoru wrote: > Starting with Gen7 (IVB) Display PipeC can be fused off on some production > parts. When disabled, display hardware will prevent the pipe C register bit > from being set to 1. > > Fixed by adjusting pipe_count to reflect this.

Re: [Intel-gfx] [PATCH] drm/i915: Demote user facing DMC firmware load failure message

ed to load DMC firmware > [https://01.org/linuxgraphics/intel-linux-graphics-firmwares], disabling > runtime power management. > > Signed-off-by: Chris Wilson <ch...@chris-wilson.co.uk> > Cc: Damien Lespiau <damien.lesp...@intel.com> > Cc: Imre Deak <imre.d...@i

[Intel-gfx] [PATCH xf86-video-intel] Sync PCI ids with latest kernel, adding SKL GT4

Syncs with: commit 15620206ae87ba9643ffa6f5ddb5471be7192006 Author: Mika Kuoppala <mika.kuopp...@linux.intel.com> Date: Fri Nov 6 14:11:16 2015 +0200 drm/i915/skl: Add SKL GT4 PCI IDs Signed-off-by: Damien Lespiau <damien.lesp...@intel.com> --- src/i915_p

Re: [Intel-gfx] [PATCH] drm/i915/kbl: Enable PW1 and Misc I/O power wells

On Wed, Jan 06, 2016 at 12:08:36PM +, Michel Thierry wrote: > My kbl stopped working because of this. > > Fixes regression from > commit 2f693e28b8df69f67beced5e18bb2b91c2bfcec2 > Author: Damien Lespiau <damien.lesp...@intel.com> > Date: Wed Nov 4 19:24:12 2015 +0

Re: [Intel-gfx] [PATCH] drm/i915: Restore skl_gt3 device info

On Fri, Dec 04, 2015 at 04:19:49PM +0100, Daniel Vetter wrote: > This was broken in > > commit 6a8beeffed3b2d33151150e3a03696e697f16d46 > Author: Wayne Boyer > Date: Wed Dec 2 13:28:14 2015 -0800 > > drm/i915: Clean up device info structure definitions > > and I

Re: [Intel-gfx] [PATCH] drm/i915/skl: Add SKL GT4 PCI IDs

On Fri, Dec 04, 2015 at 07:00:36PM +, Damien Lespiau wrote: > On Fri, Nov 06, 2015 at 02:11:16PM +0200, Mika Kuoppala wrote: > > From: Mika Kuoppala <mika.kuopp...@linux.intel.com> > > > > Add Skylake Intel Graphics GT4 PCI IDs > > > > v2: Rebas

Re: [Intel-gfx] [PATCH] drm/i915/skl: Add SKL GT4 PCI IDs

On Fri, Nov 06, 2015 at 02:11:16PM +0200, Mika Kuoppala wrote: > From: Mika Kuoppala <mika.kuopp...@linux.intel.com> > > Add Skylake Intel Graphics GT4 PCI IDs > > v2: Rebase > > Signed-off-by: Mika Kuoppala <mika.kuopp...@intel.com> > --- Reviewed-by: Dami

Re: [Intel-gfx] [PATCH 1/2] drm/i915: PSR: Let's rely more on frontbuffer tracking.

ting. That said, I think we need to extend the language we use for review and make patchwork understand it. For instance, being able to review several patches in one go could be done with: Patches 1-3,6: Reviewed-by: Damien Lespiau damien.lesp...@intel.com (See: https://github.com/dl

Re: [Intel-gfx] i-g-t/libdrm email tagging & patchwork

On Thu, Nov 19, 2015 at 12:44:07PM +0200, Jani Nikula wrote: > On Wed, 18 Nov 2015, Daniel Vetter <dan...@ffwll.ch> wrote: > > On Sun, Nov 08, 2015 at 12:31:36AM +, Damien Lespiau wrote: > >> Hi all, > >> > >> I've added a feature to sort the pat

Re: [Intel-gfx] [PATCH] lib: Add Skylake Intel Graphics GT4 PCI IDs

On Fri, Nov 06, 2015 at 04:42:10PM +0200, Mika Kuoppala wrote: > Add Skylake Intel Graphics GT4 PCI IDs. > > Signed-off-by: Mika Kuoppala <mika.kuopp...@intel.com> Reviewed-by: Damien Lespiau <damien.lesp...@intel.com> -- Damien > --- > lib/intel_chipset.h | 12 +++

Re: Patchwork to require git-send-email formatted patches?

On Thu, Nov 12, 2015 at 06:40:48PM -0800, Bryce Harrington wrote: > On Thu, Nov 12, 2015 at 09:38:48AM +, Ucan, Emre (ADITG/SW1) wrote: > > Hi, > > > > I personally create the patches with git format-patch and then copy to the > > email. > > Because I have to use windows and outlook for my

Re: Patchwork to require git-send-email formatted patches?

On Wed, Nov 11, 2015 at 02:01:38PM +0200, Pekka Paalanen wrote: > On Tue, 10 Nov 2015 11:35:35 + > Damien Lespiau <damien.lesp...@intel.com> wrote: > > > Something else I noticed on this thead: > > > > In the reply 20151019013047.GA8175@jelly.local f

Re: Patchwork to require git-send-email formatted patches?

On Thu, Nov 12, 2015 at 02:20:01PM +0200, Pekka Paalanen wrote: > IMHO, it is less of a burden to prune accidental patches from Patchwork > than cause people grief by rejecting legitimate patches. Or does that > screw up the patch revision or series tracking? That should work, if not, it's

Re: Patchwork missing the rest of the series (Re: [PATCH wayland 0/3] Restore DTD and use wayland-scanner to validate)

On Mon, Nov 09, 2015 at 11:25:17AM +0200, Pekka Paalanen wrote: > Hi Damien, Hi Pekka, > I just noticed that from this patch series of three, only 1/3 shows up > in Patchwork as http://patchwork.freedesktop.org/patch/64191/ . > The rest are: >

Re: [PATCH 1/2] retag: Don't use BaseCommand's stdin/stdout wrappers

On Mon, Nov 09, 2015 at 03:39:09PM +, Finucane, Stephen wrote: > > On Mon, Nov 09, 2015 at 03:33:18PM +, Finucane, Stephen wrote: > > > PS: Since we're talking, if you have time to address the remaining > > comments > > > on the 'series' series it would be appreciated. I don't want to just

Re: [PATCH 1/2] retag: Don't use BaseCommand's stdin/stdout wrappers

On Mon, Nov 09, 2015 at 03:33:18PM +, Finucane, Stephen wrote: > PS: Since we're talking, if you have time to address the remaining comments > on the 'series' series it would be appreciated. I don't want to just do the > rework without you input in case I miss something. It's one of three

Re: [PATCH 2/2] retag: Properly display the final count

On Mon, Nov 09, 2015 at 03:30:22PM +, Finucane, Stephen wrote: > > On Mon, Nov 09, 2015 at 03:20:39PM +, Finucane, Stephen wrote: > > > > That wouldn't work either. On the last iteration (count - 1)/count > > would > > > > be printed and count/count would never be printed. > > > > > >

Re: [PATCH 2/2] retag: Properly display the final count

On Mon, Nov 09, 2015 at 02:59:49PM +, Finucane, Stephen wrote: > > On Mon, Nov 09, 2015 at 02:37:54AM +, Finucane, Stephen wrote: > > > > i == count cannot happen in the loop as i will vary from 0 to count - > > 1. > > > > > > > > Signed-

Re: [PATCH 2/2] retag: Properly display the final count

On Mon, Nov 09, 2015 at 03:20:39PM +, Finucane, Stephen wrote: > > That wouldn't work either. On the last iteration (count - 1)/count would > > be printed and count/count would never be printed. > > Right you are. What on earth was that code doing there at all? :) Actually, because i goes

Re: [PATCH 1/2] retag: Don't use BaseCommand's stdin/stdout wrappers

On Mon, Nov 09, 2015 at 03:39:09PM +, Finucane, Stephen wrote: > > On Mon, Nov 09, 2015 at 03:33:18PM +, Finucane, Stephen wrote: > > > PS: Since we're talking, if you have time to address the remaining > > comments > > > on the 'series' series it would be appreciated. I don't want to just

Re: [PATCH 2/2] retag: Properly display the final count

On Mon, Nov 09, 2015 at 02:37:54AM +, Finucane, Stephen wrote: > > i == count cannot happen in the loop as i will vary from 0 to count - 1. > > > > Signed-off-by: Damien Lespiau <damien.lesp...@intel.com> > > --- > > patchwork/management/commands/ret

Re: [PATCH 1/2] retag: Don't use BaseCommand's stdin/stdout wrappers

On Mon, Nov 09, 2015 at 02:29:57AM +, Finucane, Stephen wrote: > > @@ -38,6 +39,6 @@ class Command(BaseCommand): > > for i, patch in enumerate(query.iterator()): > > patch.refresh_tag_counts() > > if (i % 10) == 0 or i == count: > > -

Re: [Intel-gfx] i-g-t/libdrm email tagging & patchwork

On Mon, Nov 09, 2015 at 10:45:14AM +0200, Jani Nikula wrote: > On Sun, 08 Nov 2015, Damien Lespiau <damien.lesp...@intel.com> wrote: > > There are two new patchwork projects then: > > > > http://patchwork.freedesktop.org/project/intel-gpu-tools/ > > http://

Re: [Intel-gfx] i-g-t/libdrm email tagging & patchwork

On Mon, Nov 09, 2015 at 01:21:33PM +0200, Jani Nikula wrote: > On Mon, 09 Nov 2015, Damien Lespiau <damien.lesp...@intel.com> wrote: > > That would work for us, but not in the general case (for other > > projects). I was thinking of using some kind of other heuristic, eg.

[PATCH 2/2] retag: Properly display the final count

i == count cannot happen in the loop as i will vary from 0 to count - 1. Signed-off-by: Damien Lespiau <damien.lesp...@intel.com> --- patchwork/management/commands/retag.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/patchwork/management/commands/retag.py b/pat

[Intel-gfx] i-g-t/libdrm email tagging & patchwork

Hi all, I've added a feature to sort the patches sent to intel-gfx into 3 buckets: i915, intel-gpu-tools and libdrm. This sorting relies on tagging patches, using the subject prefixes (which is what most people do already anyway). - i915 (intel-gfx): catchall project, all mails not matching

Re: [PATCH v2 0/4] Remove support for Django 1.6

On Fri, Nov 06, 2015 at 01:04:10PM +0100, Johannes Berg wrote: > Hi, > > > A possible solution: [...] > > I'm not involved in the maintenance of kernel.org, so I can't really > say. However, in the past we've been told that they can only upgrade > patchwork if the django requirement can be

Re: Patchwork instance for SNPS ARC Linux

On Mon, Nov 02, 2015 at 10:05:47AM +, Alexey Brodkin wrote: > Hello, Hi, > I'm wondering if there's a chance to get a patchwork project instance > for SNPS ARC Linux mailing list > (http://lists.infradead.org/pipermail/linux-snps-arc/) > on http://patchwork.ozlabs.org/? I can't help you

Re: [Intel-gfx] HDMI 4k modes VIC

On Wed, Oct 28, 2015 at 01:58:55PM +, Sharma, Shashank wrote: >Hi Damien > >This is regarding one of the patches: >drm: Add support for alternate clocks of 4k modes >(3f2f653378112c1453c0d83c81746a9225e4bc75) > >I am seeing that from function drm_match_hdmi_mode we are

Re: [Intel-gfx] HDMI 4k modes VIC

On Wed, Oct 28, 2015 at 06:38:21PM +0200, Jani Nikula wrote: > > Are you seeing a bug? it's totally possible, I've never used an actual > > conformance tool when I wrote that code, so it's likely buggy and the > > VIC in the AVI infoframe may well be wrong. > > Possibly relevant >

Re: [Intel-gfx] [PATCH] drm/i915: Use dpcd read wake for sink crc calls.

On Thu, Oct 22, 2015 at 12:01:21AM +0530, Thulasimani, Sivakumar wrote: > > > On 8/25/2015 2:50 AM, Vivi, Rodrigo wrote: > >On Mon, 2015-08-24 at 19:54 +, Zanoni, Paulo R wrote: > >>Em Qui, 2015-08-20 às 16:23 -0700, Rodrigo Vivi escreveu: > >>>Let's use a native read with retry as suggested

[PATCH 0/2] Atomicity & parsemail.sh

Damien Lespiau (2): lock: Import file lock class from mercurial parsemail: Make parsing an email atomic operation patchwork/bin/parsemail.py | 20 +++ patchwork/lock.py| 301 +++ patchwork/tests/test_lock.py | 290

[PATCH 1/2] lock: Import file lock class from mercurial

With series now in production, I realized I needed the mail parsing to be atomic. Because of the race can happen between mutiple process a file lock seems like it could work. Signed-off-by: Damien Lespiau <damien.lesp...@intel.com> --- patchwork/lock.py

[PATCH 13/14] series: New series with similar titles as previous ones are new revisions

v3: Rebase on top of the SERIES_DEFAULT_NAME change Signed-off-by: Damien Lespiau <damien.lesp...@intel.com> --- patchwork/bin/parsemail.py | 46 +- patchwork/tests/test_series.py | 73 +- 2 files changed, 117 insertions

[PATCH 12/14] series: Add a signal to notify when a revision is complete

To decouple some high level and rather complex parsing code from the models, let's add a signal when a SeriesRevision is complete. One can use that signal to hook some logic there, for instance from the mail parsing code. Signed-off-by: Damien Lespiau <damien.lesp...@intel.com> Acked-by: S

[PATCH 02/14] parsemail: Make find_content() return a MailContent object

Returning tuples is not super scalable. I now want to return a Series object along with a patch or a comment. So let's put the return values into a class, used as a typed dictionary really. Signed-off-by: Damien Lespiau <damien.lesp...@intel.com> Acked-by: Stephen Finucane <step

[PATCH 01/14] parsemail: Return the list of prefixes when cleaning up the subject

The patch is a preparation step towards understanding series. It will be handy to parse those prefixes, looking for 'x/n' to retrieve the order of a patch in a series. Signed-off-by: Damien Lespiau <damien.lesp...@intel.com> Acked-by: Stephen Finucane <stephen.finuc...@intel.com> --

[PATCH 03/14] parsemail: Add a function to parse series markers eg. "1/12"

This can be used to identify cover letters, patches part of series, length of series, ... Signed-off-by: Damien Lespiau <damien.lesp...@intel.com> Acked-by: Stephen Finucane <stephen.finuc...@intel.com> --- patchwork/bin/parsemail.py | 12 pat

[PATCH 04/14] parsemail: Extract building the list of mail references

We'll need to figure out whether the mail we are parsing is the root of the thread to automatically build series, and we'll need the list of references for that. Signed-off-by: Damien Lespiau <damien.lesp...@intel.com> Acked-by: Stephen Finucane <stephen.finuc...@intel.com> --- p

[PATCH 4/7] api: Add a basic REST API to access Series/Revisions and Patches

v2: Merge commits introducing basic objects v3: Introduce the SeriesListMixin class v4: Add the expand get parameter v5: Introduce /api/1.0/ metadata entry point Signed-off-by: Damien Lespiau <damien.lesp...@intel.com> --- docs/api.rst

[PATCH 5/7] models: Add Event and EventLog models

overkill. I have to mind to attach more properties to events. For instance link a state to an event so we can generically set the state of a series/patch when a certain event is created. Signed-off-by: Damien Lespiau <damien.lesp...@intel.com> --- patchwork/migrations/0005_event_eventlog.p

[PATCH 2/7] models: Monkey patch User to have a name() method

The name is really a poperty of the User. Not always having to retrieve the profile for that makes things simpler. Signed-off-by: Damien Lespiau <damien.lesp...@intel.com> --- patchwork/models.py | 3 +++ 1 file changed, 3 insertions(+) diff --git a/patchwork/models.py b/patchwork/mod

[PATCH 7/7] api: Expose events

so a bot can retrieve its patches and test them. Signed-off-by: Damien Lespiau <damien.lesp...@intel.com> --- docs/api.rst | 51 patchwork/serializers.py | 8 +++- patchwork/urls.py| 5 + patchwork/views/api.py

[PATCH 6/7] series: Add a 'new-series-revision' event

in the SeriesLog table. v2: Rebase on top of SERIES_DEFAULT_NAME changes Signed-off-by: Damien Lespiau <damien.lesp...@intel.com> --- patchwork/fixtures/default_events.xml | 6 + patchwork/models.py | 8 ++ patchwork/tests/test_bundles.py | 2 +- patchwork

Re: [PATCH 00/15] Series models & parsing (v2)

On Sat, Oct 10, 2015 at 12:21:28AM +0100, Finucane, Stephen wrote: > I've replied to all the patches available bar one (which I want to > investigate a little further). However, I'm missing two patches. Can > you submit these separately or resend the series (ideally after > addressing comments)?

[PATCH 10/14] tests: Add a utility class to create Series

a TestSeries classes that can create a series with n patches with or without a cover letter. Signed-off-by: Damien Lespiau <damien.lesp...@intel.com> Acked-by: Stephen Finucane <stephen.finuc...@intel.com> --- patchwork/tests/test_series.py | 51 - patchwork/te

[PATCH 07/14] series: Create Series objects when parsing mails

at a later point. Single patches are treated as a Series of 1 patch, named with the subject of that patch. v2: SERIES_DEFAULT_NAME change Signed-off-by: Damien Lespiau <damien.lesp...@intel.com> Acked-by: Stephen Finucane <stephen.finuc...@intel.com> --- patchwork

[PATCH 09/14] tests: Save the test project if we're going to use it

create_email() can use the default project for its mail. If that is the case, chances are we are going to use that email later in a test where we'll want that project to exist. Signed-off-by: Damien Lespiau <damien.lesp...@intel.com> Acked-by: Stephen Finucane <stephen.finuc...@

[PATCH 3/7] models: Don't return the email along with the name in Person's __unicode__

If we have a person name, that's enough to identify her/him. We don't need to add ones email address there. Signed-off-by: Damien Lespiau <damien.lesp...@intel.com> --- patchwork/models.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/patchwork/models.py b/pat

[PATCH 1/7] models: Split a user_name() helper out of UserProfile

Signed-off-by: Damien Lespiau <damien.lesp...@intel.com> --- patchwork/models.py | 10 ++ 1 file changed, 6 insertions(+), 4 deletions(-) diff --git a/patchwork/models.py b/patchwork/models.py index 6660cad..a1d6840 100644 --- a/patchwork/models.py +++ b/patchwork/models.py @@

Re: [PULL] github.com/stephenfin/development

On Fri, Oct 16, 2015 at 07:08:45PM +0100, Finucane, Stephen wrote: > # 1) Add additional project configuration options: > > We should add the following options to the 'Project' model > > * Add an optional list property to specify the tests contexts that > have to run in order for a patch to be

Re: [PULL] github.com/stephenfin/development

On Thu, Oct 15, 2015 at 11:46:30PM +, Finucane, Stephen wrote: > Hey, > > First pull request (request-pull style, that is). Hope I've done > everything correctly :S This PR includes two fixes and the code enable > the check API. It's got positive reviews first time round and I > haven't heard

Re: missing patches

Hi, On Mon, Oct 12, 2015 at 01:54:24PM -0700, Brian Norris wrote: > Occasionally, I'll run across patches from the linux-mtd mailing list > that never show up on the ozlabs.org Patchwork instance. I don't > really have much visibility into this problem, so I wanted to reach > out here. > > For

Re: [PULL] github.com/stephenfin/development

On Fri, Oct 16, 2015 at 04:11:50PM +0100, Finucane, Stephen wrote: > You appear to be insisting there should be a more static configuration > of "runnable tests". However, I don't think this would scale or allow > the fluidity of Thomas' proposal. I'm insisting it's *possible* to have a list of

  1   2   3   4   5   6   7   8   9   10   >