Re: The list.

It doesn't always happen every month, but I've seen it multiple times now,
as far back as January 2018, though possibly earlier.

The gzip mail archive however has all the messages that are missing from
the web archive.
https://lists.freedesktop.org/archives/mesa-dev/2018-October.txt.gz

There are patches in that series missing however, as you pointed out.

That said, looking at that file I see that the last message that didn't get
processed had the following Message ID header:

Message-ID: <20181020175547.9159-6-jason.ekstr...@intel.com>

The messages are a bit out of order there, which may or may not be related.
I can't see anything else that seems out of the ordinary.

I also get DMARC issues for certain emails (they fail DMARC, meaning that
they've not been handled properly when passing through the list). I notice
this particularly for emails from Liviu Prodea liviupro...@yahoo.com but
sometimes for other ppl too.

Perhaps a later version of Mailman (eg: 2.1.29?) might resolve some/both of
these issues?


On Mon, 22 Oct 2018 at 22:31, Samuel Iglesias Gonsálvez <
sigles...@igalia.com> wrote:

> Patch 7/9 has never arrived my inbox and checking the archives [0], looks
> like
> the archive is messed up... it has only a few emails. Does somebody know
> what
> happened with the ML archive?
>
> Sam
>
> [0] https://lists.freedesktop.org/archives/mesa-dev/2018-October/date.html
>
> On Saturday, 20 October 2018 19:55:38 (CEST) Jason Ekstrand wrote:
> > Previously, the only thing we had was nir_src_as_const_value which
> returns
> > a pointer to a nir_const_value which was NULL if the source wasn't
> actually
> > a constant.  This was great except that almost none of the users
> considered
> > anything other than 32-bit values.  With 8, 16, and 64-bit values
> floating
> > around, we really shouldn't be hand-rolling it everywhere.  Most of the
> > code is currently safe if you operate under the assumption that things
> like
> > array indices are always 32 bits.  The glaring exception was some of the
> > helpers in nir_search_helpers.h where we definitely cannot be making that
> > assumption but were anyway.
> >
> > I've converted core NIR and i965 but have not written patches for vc4,
> ir3,
> > or radeon.
> >
> > Cc: Connor Abbott <cwabbo...@gmail.com>
> > Cc: Timothy Arceri <tarc...@itsqueeze.com>
> > Cc: Eric Anholt <e...@anholt.net>
> > Cc: Rob Clark <robdcl...@gmail.com>
> > Cc: Karol Herbst <karolher...@gmail.com>
> > Cc: Bas Nieuwenhuizen <b...@basnieuwenhuizen.nl>
> >
> > Jason Ekstrand (9):
> >   nir: Add some new helpers for working with const sources
> >   nir/search: Use nir_src_is_const and friends
> >   nir/search_helpers: Use nir_src_is_const and friends
> >   nir: Use nir_src_is_const and nir_src_as_* in core code
> >   intel/fs,vec4: Clean up a repeated pattern with SSBOs
> >   intel/fs: Use the new nir_src_is_const and friends
> >   intel/vec4: Use the new nir_src_is_const and friends
> >   intel/analyze_ubo_ranges: Use nir_src_is_const and friends
> >   anv: Use nir_src_is_const and friends in lowering code
> >
> >  src/compiler/glsl/gl_nir_lower_samplers.c     |   7 +-
> >  src/compiler/nir/nir.c                        |  92 +++++
> >  src/compiler/nir/nir.h                        |  16 +
> >  src/compiler/nir/nir_deref.c                  |  14 +-
> >  src/compiler/nir/nir_gather_info.c            |   6 +-
> >  src/compiler/nir/nir_gs_count_vertices.c      |   7 +-
> >  src/compiler/nir/nir_lower_clip.c             |   2 +-
> >  src/compiler/nir/nir_lower_indirect_derefs.c  |   4 +-
> >  src/compiler/nir/nir_lower_io.c               |   6 +-
> >  .../nir/nir_lower_io_arrays_to_elements.c     |  11 +-
> >  src/compiler/nir/nir_lower_locals_to_regs.c   |   6 +-
> >  src/compiler/nir/nir_lower_two_sided_color.c  |   2 +-
> >  src/compiler/nir/nir_lower_vars_to_ssa.c      |  14 +-
> >  src/compiler/nir/nir_opt_dead_cf.c            |   7 +-
> >  src/compiler/nir/nir_opt_find_array_copies.c  |  13 +-
> >  src/compiler/nir/nir_opt_intrinsics.c         |   4 +-
> >  src/compiler/nir/nir_opt_large_constants.c    |   2 +-
> >  src/compiler/nir/nir_search.c                 |  70 +---
> >  src/compiler/nir/nir_search_helpers.h         |  49 ++-
> >  src/compiler/nir/nir_split_vars.c             |  17 +-
> >  src/compiler/nir/tests/vars_tests.cpp         |  10 +-
> >  src/intel/compiler/brw_fs.h                   |   2 +
> >  src/intel/compiler/brw_fs_nir.cpp             | 315 +++++++-----------
> >  .../compiler/brw_nir_analyze_ubo_ranges.c     |  15 +-
> >  src/intel/compiler/brw_vec4.h                 |   2 +
> >  src/intel/compiler/brw_vec4_gs_nir.cpp        |  12 +-
> >  src/intel/compiler/brw_vec4_nir.cpp           | 190 ++++-------
> >  src/intel/compiler/brw_vec4_tcs.cpp           |   6 +-
> >  .../vulkan/anv_nir_apply_pipeline_layout.c    |  15 +-
> >  .../vulkan/anv_nir_lower_ycbcr_textures.c     |   6 +-
> >  30 files changed, 423 insertions(+), 499 deletions(-)
>
> _______________________________________________
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>


-- 
Stuart Young (aka Cefiar)
_______________________________________________
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Reply via email to