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,
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
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.
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
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.
>
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.
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
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
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.
>
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
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
;
# 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
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
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
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>
> > >
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..
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
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
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
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?
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,
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
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
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
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
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
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
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
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
>
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
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.
>
>
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
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
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
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
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
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,
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
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
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
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
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:
>
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
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
>
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
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
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.
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
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
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
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
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
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
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
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
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 +++
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
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
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
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:
>
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
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
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.
> > >
> > >
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-
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
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
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
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:
> > -
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://
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.
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
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
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
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
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
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
>
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
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
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
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
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
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
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>
--
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
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
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
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
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
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
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
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)?
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
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
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...@
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
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
@@
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
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
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
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 - 100 of 3414 matches
Mail list logo