mesa3d-dev

Re: [Mesa3d-dev] Current tinderbox regression (dri: fix dri_test.c)

[Chris B. <cj...@la...>]

Hi Sedat,

   > While striving the log of libGL [1], I noticed that
   > configure-option --enable-radeon-experimental-api is set, this is
   > obsolete and build by default, now. Please change.

Thanks, I've removed it now.

- Chris.
-- 
Chris Ball   <cj...@la...>
One Laptop Per Child

Re: [Mesa3d-dev] Current tinderbox regression (dri: fix dri_test.c)

[Sedat D. <sed...@go...>]

While striving the log of libGL [1], I noticed that configure-option
--enable-radeon-experimental-api is set, this is obsolete and build by
default, now. Please change.
For more Details see Radeon Build-HowTo [2].

[configure - 2010-03-23 22:28:49]

./autogen.sh --prefix /home/cjb/xorg-build   --disable-static
--cache-file=/home/cjb/xorg-git/autoconf-cache --with-log-dir=/var/log
--with-mesa-source=/home/cjb/xorg-git/mesa
--enable-radeon-experimental-api --enable-nouveau-experimental-api

--
Sedat

[1] http://tinderbox.x.org/builds/2010-03-23-0040/logs/libGL/
[2] http://wiki.x.org/wiki/radeonBuildHowTo#Bleedingedgecodefromdevelopmentbranch

Re: [Mesa3d-dev] Current tinderbox regression (dri: fix dri_test.c for non-TLS build)

[Luca B. <luc...@gm...>]

According to the logs, that build was not based on that commit, which
instead actually fixes that issue.

http://tinderbox.x.org/builds/2010-03-23-0040/ was actually the first
tinderbox build using that, and it went past that issue to fail on
xeglthreads problem, which is unrelated.

Thanks anyway for reporting this.

[Mesa3d-dev] [Bug 27273] Lightsmark2008 robot model is drawn flat

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=27273





--- Comment #1 from Ruslan <b7....@gm...>  2010-03-23 15:37:47 PST ---
Maybe this matters, i tested windows version of it, using WINE. Anyway, it does
work correctly on nVidia proprietary driver, so i guess it's Mesa bug.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

[Mesa3d-dev] [Bug 27273] New: Lightsmark2008 robot model is drawn flat

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=27273

           Summary: Lightsmark2008 robot model is drawn flat
           Product: Mesa
           Version: 7.6
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: Mesa core
        AssignedTo: mes...@li...
        ReportedBy: b7....@gm...


I tried this using software rasterizer in Mesa 7.7. Screenshot is in the
attachment.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Re: [Mesa3d-dev] Makefile.egl missing

[Sedat D. <sed...@go...>]

A fix was pushed to mesa-7.8 GIT branch [1]:

commit 2ded27b2f0a7b01f5db77ea9a2a25df5baa876b3
"Add missing EGL files to the tarballs."

--
Sedat

[1] http://cgit.freedesktop.org/mesa/mesa/commit/?h=7.8&id=2ded27b2f0a7b01f5db77ea9a2a25df5baa876b3

Re: [Mesa3d-dev] Move lists to freedesktop.org?

[Michel D. <mi...@da...>]

On Die, 2010-03-23 at 12:32 -0700, Jesse Barnes wrote: 
> On Thu, 4 Mar 2010 15:20:46 -0800
> Jesse Barnes <jb...@vi...> wrote:
> 
> > On Fri, 05 Mar 2010 00:16:45 +0100
> > Michel Dänzer <mi...@da...> wrote:
> > 
> > > On Thu, 2010-03-04 at 16:09 -0700, Brian Paul wrote: 
> > > > Jesse Barnes wrote:
> > > > > Would anyone have objections if these lists moved to freedesktop.org?
> > > > > The recent thread with Linus about the drm pull request highlights the
> > > > > post lag and non-subscriber aspect of the current lists, and that
> > > > > leaves aside sf.net's horrible mail archive interface and poor
> > > > > performance.
> > > > > 
> > > > > If spam is an issue, another option would be vger.kernel.org.  That
> > > > > team runs lkml and several other very high traffic, high profile lists
> > > > > and manages quite well; performance is always high and spam is nearly
> > > > > non-existent given the amount of traffic.
> > > > 
> > > > Jesse, can you set up the new lists?  Or does someone else need to do 
> > > > that?
> > > > 
> > > > I can send you (or whoever) the current subscriber lists.
> > > 
> > > Ditto for dri-devel.
> > > 
> > > > BTW, I'm the current admin for the Mesa lists on SourceForge.  I 
> > > > manually unsubscribe people who can't figure it out for themselves, 
> > > > allow posts from non-members (sometimes), etc.  I'd gladly pass on 
> > > > that responsibility to someone else.  Would that automatically become 
> > > > the job of the current fd.o admins?
> > > 
> > > Not really, the lists should still have their own admins.
> > > 
> > > I've been going through the moderation queues for both lists on a daily
> > > basis and am volunteering to continue doing so, but other than that I'm
> > > not really keen on being a list admin.
> > 
> > I don't have access to create the new lists, but Daniel or Tollef
> > should.
> > 
> > We may as well keep you guys as admins unless someone volunteers that
> > you're ok with; but hopefully FDO will make the admin job a little
> > easier/faster.
> 
> Brian and Michel, did you guys get what you need to move the lists?
> AFAIK Tollef created them, you just need to copy the subscriber lists
> over and announce it I think?

This is the first time I've heard of new lists having been created...


-- 
Earthling Michel Dänzer           |                http://www.vmware.com
Libre software enthusiast         |          Debian, X and DRI developer

[Mesa3d-dev] Current tinderbox regression (dri: fix dri_test.c for non-TLS build)

[Chris B. <cj...@la...>]

Hi,

   > dri: fix dri_test.c for non-TLS build
   > 
   > _glapi_Context and _glapi_Dispatch have different constness
   > between TLS and non-TLS builds.

Breaks the build here, on Fedora 11/ppc64:

http://tinderbox.x.org/builds/2010-03-23-0038/logs/libGL/#build

../../../../../src/mesa/drivers/dri/common/dri_test.c:22: error: conflicting types for '_glapi_Dispatch'
../../../../../src/mesa/glapi/glapi.h:97: note: previous declaration of '_glapi_Dispatch' was here
../../../../../src/mesa/drivers/dri/common/dri_test.c:23: error: conflicting types for '_glapi_Context'
../../../../../src/mesa/glapi/glapi.h:99: note: previous declaration of '_glapi_Context' was here

- Chris.
-- 
Chris Ball   <cj...@la...>
One Laptop Per Child

Re: [Mesa3d-dev] Current tinderbox regression (dri)

[Sedat D. <sed...@go...>]

On Tue, Mar 23, 2010 at 11:03 PM, Luca Barbieri <luc...@gm...> wrote:
> On Tue, Mar 23, 2010 at 10:45 PM, Sedat Dilek
> <sed...@go...> wrote:
>>>The issue should be hopefully completely fixed by
>>>7e246e6aa63979d53731a591f4caee3651c1d96b.
>>
>> Unfortunately, build breaks here.
>> Not sure which of the last changes really breaks it.
>
> Hopefully fixed that too now.
>

Looks good with:

commit 3790199e041236ab8db1effaba2922e10b8b81ac
"dri: fix dri_test.c for non-TLS build"

--
Sedat

[Mesa3d-dev] Makefile.egl missing

[Filip <gf...@ee...>]

Makefile.egl is missing in src/gallium/winsys/drm/ when getting MesaLib
from tarball. E.g., from
ftp://ftp.freedesktop.org/pub/mesa/7.8/RC/MesaLib-7.8-rc2.tar.gz

Curiously, the file is present in the rc2-tagged git commit:
http://cgit.freedesktop.org/mesa/mesa/tree/src/gallium/winsys/drm?id=4eead425504057e0862bc214bceaa512775973f1

[Mesa3d-dev] [Bug 27266] Cubosphere: undefined function 'texture2D' / incompatible types in assignment

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=27266





--- Comment #1 from Brian Paul <bri...@gm...>  2010-03-23 15:15:23 PST ---
The problem is this line:

  vec4 base = texture2D(base, uv);

base was previously declared as sampler2D.  We're getting the scoping wrong
with the initializer.  Perhaps you could suggest to the game's authors to
rename 'vec4 base' to something else.  I won't have time to fix the compiler
for a while.


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Re: [Mesa3d-dev] Current tinderbox regression (dri)

[Luca B. <luc...@gm...>]

On Tue, Mar 23, 2010 at 10:45 PM, Sedat Dilek
<sed...@go...> wrote:
>>The issue should be hopefully completely fixed by
>>7e246e6aa63979d53731a591f4caee3651c1d96b.
>
> Unfortunately, build breaks here.
> Not sure which of the last changes really breaks it.

Hopefully fixed that too now.

Re: [Mesa3d-dev] Current tinderbox regression (xeglthreads)

[Sedat D. <sed...@go...>]

On Tue, Mar 23, 2010 at 10:14 PM, Dan Nicholson <dbn...@gm...> wrote:
> On Tue, Mar 23, 2010 at 2:04 PM, Sedat Dilek <sed...@go...> wrote:
>>>We have a hack in the xdemos directory to link the programs with
>>>-lpthread for the same reason (I think). Probably need to carry that
>>>hack to the progs/egl directory for xeglthreads, too.
>>
>> Reasons for the hack in xdemos was linking with binutils-gold.
>> See explanations in [1] concerning X11.
>
> Well, there's also progs/xdemos/glthreads.c, which is directly using
> the pthread API and wasn't previously linking to the library.
>

Remember it again:
glthreads.c required -lpthread while experimenting with binutils-gold.

--
Sedat

Re: [Mesa3d-dev] Current tinderbox regression (dri)

[Sedat D. <sed...@go...>]

>The issue should be hopefully completely fixed by
>7e246e6aa63979d53731a591f4caee3651c1d96b.

Unfortunately, build breaks here.
Not sure which of the last changes really breaks it.

[build.log]
...
/bin/bash ../../../../../bin/mklib -o r300_dri.so.tmp -noprefix
-linker 'ccache gcc' -ldflags '' \
		../common/utils.o ../common/vblank.o ../common/dri_util.o
../common/xmlconfig.o ../../common/driverfuncs.o ../common/texmem.o
../common/drirenderbuffer.o ../common/dri_metaops.o radeon_screen.o
r300_blit.o r300_context.o r300_draw.o r300_cmdbuf.o r300_state.o
r300_render.o r300_tex.o r300_texstate.o r300_vertprog.o
r300_fragprog_common.o r300_shader.o radeon_mesa_to_rc.o r300_emit.o
r300_swtcl.o radeon_bo_legacy.o radeon_buffer_objects.o
radeon_common_context.o radeon_common.o radeon_cs_legacy.o
radeon_dma.o radeon_debug.o radeon_fbo.o radeon_lock.o
radeon_mipmap_tree.o radeon_pixel_read.o radeon_queryobj.o
radeon_span.o radeon_texture.o radeon_tex_copy.o radeon_tex_getimage.o
radeon_tile.o   ../../../../../src/mesa/libmesa.a
compiler/libr300compiler.a   -ldrm   -lexpat -lm -lpthread -ldl
-ldrm_radeon -ldrm
mklib: Making Linux shared library:  r300_dri.so.tmp
ccache gcc -o r300_dri.so.test
../../../../../src/mesa/drivers/dri/common/dri_test.o r300_dri.so.tmp
 -ldrm   -lexpat -lm -lpthread -ldl -ldrm_radeon -ldrm
r300_dri.so.tmp: undefined reference to `_glthread_GetID'
collect2: ld returned 1 exit status
make[6]: *** [r300_dri.so] Error 1
make[6]: Leaving directory `/home/sd/src/mesa/mesa/src/mesa/drivers/dri/r300'
make[5]: *** [lib] Error 2
make[5]: Leaving directory `/home/sd/src/mesa/mesa/src/mesa/drivers/dri/r300'
make[4]: *** [subdirs] Error 1
make[4]: Leaving directory `/home/sd/src/mesa/mesa/src/mesa/drivers/dri'
make[3]: *** [default] Error 1
make[3]: Leaving directory `/home/sd/src/mesa/mesa/src/mesa/drivers'
make[2]: *** [driver_subdirs] Error 2
make[2]: Leaving directory `/home/sd/src/mesa/mesa/src/mesa'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/home/sd/src/mesa/mesa/src'
make: *** [default] Error 1

Re: [Mesa3d-dev] Current tinderbox regression (xeglthreads)

[Dan N. <dbn...@gm...>]

On Tue, Mar 23, 2010 at 2:04 PM, Sedat Dilek <sed...@go...> wrote:
>>We have a hack in the xdemos directory to link the programs with
>>-lpthread for the same reason (I think). Probably need to carry that
>>hack to the progs/egl directory for xeglthreads, too.
>
> Reasons for the hack in xdemos was linking with binutils-gold.
> See explanations in [1] concerning X11.

Well, there's also progs/xdemos/glthreads.c, which is directly using
the pthread API and wasn't previously linking to the library.

--
Dan

Re: [Mesa3d-dev] Current tinderbox regression (xeglthreads)

[Sedat D. <sed...@go...>]

>We have a hack in the xdemos directory to link the programs with
>-lpthread for the same reason (I think). Probably need to carry that
>hack to the progs/egl directory for xeglthreads, too.

Reasons for the hack in xdemos was linking with binutils-gold.
See explanations in [1] concerning X11.

--
Sedat

[1] http://wiki.debian.org/qa.debian.org/FTBFS#A2009-11-02Packagesfailingbecausebinutils-gold.2BAC8-indirectlinking

Re: [Mesa3d-dev] Current tinderbox regression (dri)

[Luca B. <luc...@gm...>]

The issue should be hopefully completely fixed by
7e246e6aa63979d53731a591f4caee3651c1d96b.

Re: [Mesa3d-dev] Current tinderbox regression (xeglthreads)

[Dan N. <dbn...@gm...>]

On Tue, Mar 23, 2010 at 12:27 PM, Chris Ball <cj...@la...> wrote:
> Hi,
>
> http://tinderbox.x.org/builds/2010-03-23-0034/logs/libGL/#build
>
> /usr/bin/ld: xeglthreads.o: undefined reference to symbol 'pthread_join@@GLIBC_2.0'
> /usr/bin/ld: note: 'pthread_join@@GLIBC_2.0' is defined in DSO /lib/libpthread.so.0 so try adding it to the linker command line
> /lib/libpthread.so.0: could not read symbols: Invalid operation
> collect2: ld returned 1 exit status
> gmake[2]: *** [xeglthreads] Error 1
>
> This error started after upgrading one of the build machines to Fedora
> 14 (Rawhide).  Any ideas?

We have a hack in the xdemos directory to link the programs with
-lpthread for the same reason (I think). Probably need to carry that
hack to the progs/egl directory for xeglthreads, too.

--
Dan

Re: [Mesa3d-dev] gallium cached bufmgr busy change

[Dave A. <ai...@gm...>]

On Tue, Mar 23, 2010 at 11:41 PM, Luca Barbieri <luc...@gm...> wrote:
> Do Radeons have a CP command to write an arbitrary value to some place
> in memory?
>
> If so, you may want to use that to implement userspace-accessible
> fencing in the obvious way and then use the fenced bufmgr, which would
> do that with no pipebuffer changes and no kernel calls.
>
> Otherwise, maybe change the kernel module to write a fence number in
> an mmapable place on fence irqs?

Why? I don't need any of this.

exposing 32-bit numbers to userspace means you have to make sure
everyone correctly deals with wrapping, its not worth the effort, and I've
no idea why you keep pushing for it, when I've demonstrated I've no
need for it at all.

Dave.
>

Re: [Mesa3d-dev] Move lists to freedesktop.org?

[Jesse B. <jb...@vi...>]

On Thu, 4 Mar 2010 15:20:46 -0800
Jesse Barnes <jb...@vi...> wrote:

> On Fri, 05 Mar 2010 00:16:45 +0100
> Michel Dänzer <mi...@da...> wrote:
> 
> > On Thu, 2010-03-04 at 16:09 -0700, Brian Paul wrote: 
> > > Jesse Barnes wrote:
> > > > Would anyone have objections if these lists moved to freedesktop.org?
> > > > The recent thread with Linus about the drm pull request highlights the
> > > > post lag and non-subscriber aspect of the current lists, and that
> > > > leaves aside sf.net's horrible mail archive interface and poor
> > > > performance.
> > > > 
> > > > If spam is an issue, another option would be vger.kernel.org.  That
> > > > team runs lkml and several other very high traffic, high profile lists
> > > > and manages quite well; performance is always high and spam is nearly
> > > > non-existent given the amount of traffic.
> > > 
> > > Jesse, can you set up the new lists?  Or does someone else need to do 
> > > that?
> > > 
> > > I can send you (or whoever) the current subscriber lists.
> > 
> > Ditto for dri-devel.
> > 
> > > BTW, I'm the current admin for the Mesa lists on SourceForge.  I 
> > > manually unsubscribe people who can't figure it out for themselves, 
> > > allow posts from non-members (sometimes), etc.  I'd gladly pass on 
> > > that responsibility to someone else.  Would that automatically become 
> > > the job of the current fd.o admins?
> > 
> > Not really, the lists should still have their own admins.
> > 
> > I've been going through the moderation queues for both lists on a daily
> > basis and am volunteering to continue doing so, but other than that I'm
> > not really keen on being a list admin.
> 
> I don't have access to create the new lists, but Daniel or Tollef
> should.
> 
> We may as well keep you guys as admins unless someone volunteers that
> you're ok with; but hopefully FDO will make the admin job a little
> easier/faster.

Brian and Michel, did you guys get what you need to move the lists?
AFAIK Tollef created them, you just need to copy the subscriber lists
over and announce it I think?

Thanks,
-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Mesa3d-dev] GSOC: Gallium R300 driver

[Tom S. <tst...@gm...>]

On Tue, Mar 23, 2010 at 12:13:25AM -0700, Corbin Simpson wrote:
> On Mon, Mar 22, 2010 at 11:39 PM, Tom Stellard <tst...@gm...> wrote:
> >
> > Thanks for the information.
> >
> > After spending some time learning about the Gallium driver architecture, I
> > think it might be better to set a goal to implement or improve a specific
> > feature of the Gallium R300 driver rather than trying to get a specific
> > game or application to work.  Is there a feature that is currently missing
> > from the R300 driver that might make a good project for the summer?
> 
> Good question. There's a handful of things. Passing piglit might be a
> good goal. Bumping the GL version further up, or solidifying the GLSL
> support, might be good too.
>

I think the GLSL compiler would be an interesting project for me to work
on.  What is the current status of GLSL on R300 cards?  Would something
like passing a subset of the GLSL piglit tests, or being able to correctly
handle a certain version of GLSL be a good goal for the summer?

-Tom Stellard

[Mesa3d-dev] Current tinderbox regression (xeglthreads)

[Chris B. <cj...@la...>]

Hi,

http://tinderbox.x.org/builds/2010-03-23-0034/logs/libGL/#build

/usr/bin/ld: xeglthreads.o: undefined reference to symbol 'pthread_join@@GLIBC_2.0'
/usr/bin/ld: note: 'pthread_join@@GLIBC_2.0' is defined in DSO /lib/libpthread.so.0 so try adding it to the linker command line
/lib/libpthread.so.0: could not read symbols: Invalid operation
collect2: ld returned 1 exit status
gmake[2]: *** [xeglthreads] Error 1

This error started after upgrading one of the build machines to Fedora
14 (Rawhide).  Any ideas?

Thanks,

- Chris.
-- 
Chris Ball   <cj...@la...>
One Laptop Per Child

Re: [Mesa3d-dev] [PATCH] dri: test whether the built drivers have unresolved symbols

[Jesse B. <jb...@vi...>]

On Fri, 19 Mar 2010 23:05:27 +0100
Luca Barbieri <lu...@lu...> wrote:

> > For developers that makes a lot of sense, but I've never seen any
> > other projects impose this type of thing on regular users.
> 
> Why do you see it as an onerous imposition?
> It just tries to compile a program linked with a couple of libraries
> (the DRI driver, plus libGL) and makes the build fail if that fails.
> It doesn't even execute the built program (and could not always do so
> even if it were desired, since you could be cross-compiling).

This seems to be killing my build at least:

gmake[6]: Entering directory `/home/jbarnes/working/mesa/src/mesa/drivers/dri/i915'
/bin/sh ../../../../../bin/mklib -o i915_dri.so.tmp -noprefix -linker 'gcc' -ldflags '' \
		../common/utils.o ../common/vblank.o ../common/dri_util.o ../common/xmlconfig.o ../../common/driverfuncs.o ../common/texmem.o ../common/drirenderbuffer.o ../common/dri_metaops.o i830_context.o i830_state.o i830_texblend.o i830_texstate.o i830_vtbl.o intel_render.o intel_regions.o intel_buffer_objects.o intel_batchbuffer.o intel_clear.o intel_extensions.o intel_mipmap_tree.o intel_tex_layout.o intel_tex_image.o intel_tex_subimage.o intel_tex_copy.o intel_tex_validate.o intel_tex_format.o intel_tex.o intel_pixel.o intel_pixel_bitmap.o intel_pixel_copy.o intel_pixel_draw.o intel_pixel_read.o intel_buffers.o intel_blit.o i915_tex_layout.o i915_texstate.o i915_context.o i915_debug.o i915_debug_fp.o i915_fragprog.o i915_program.o i915_state.o i915_vtbl.o intel_context.o intel_decode.o intel_screen.o intel_span.o intel_state.o intel_syncobj.o intel_tris.o intel_fbo.o   ../../../../../src/mesa/libmesa.a    -L/opt/gfx-test/lib -ldrm   -lexpat -lm -lpthread -ldl -L/opt/gfx-test/lib -ldrm_intel -ldrm  
mklib: Making Linux shared library:  i915_dri.so.tmp
gcc -o i915_dri.so.test ../../../../../src/mesa/drivers/dri/common/dri_test.o i915_dri.so.tmp -L../../../../../lib -lGL
i915_dri.so.tmp: undefined reference to `drm_intel_bo_emit_reloc_fence'
i915_dri.so.tmp: undefined reference to `drm_intel_bufmgr_gem_enable_fenced_relocs'
collect2: ld returned 1 exit status
gmake[6]: *** [i915_dri.so] Error 1

Looks like the mklib call has the right flags, but the test link
doesn't, so it tries to link against a libdrm w/o these functions
exported.

-- 
Jesse Barnes, Intel Open Source Technology Center

Re: [Mesa3d-dev] [PATCH] configure.ac: Bump LIBDRM_RADEON_REQUIRED to 2.4.19

[Sedat D. <sed...@go...>]

On Tue, Mar 23, 2010 at 6:37 PM, Marek Olšák <ma...@gm...> wrote:
> On Tue, Mar 23, 2010 at 1:57 PM, Sedat Dilek <sed...@go...>
> wrote:
>>
>> Thanks for the turbo fix, but you workarounded the "real" bug.
>
> Frankly, the Mesa build system isn't my area and I don't want to have
> anything to do with it.
>

This was the first time for me to have a closer look into the
build-system and I am still learning to understand.

> The square microtiling is now disabled on both older kernels which don't
> support it and older libdrm's which don't have the flag defined. No need to
> have bleeding-edge stuff of everything is the way to go as long as it
> doesn't get messy.
>

No problem with that kind of strategy and I am really happy we don't
need a depends version-bump.

One small critic as I have noticed several times in your commits:
It's helpful for people following the WIP development to have some
documented text in the commit-body especially when it is fixing:
* a previous b0rked commit - by adding its commit-no
* an fd.o bug - by adding its bug-no
* ...

--
Sedat

[Mesa3d-dev] [Bug 27268] using step function in vec4 constructor is not completely correct

[<bug...@fr...>]

http://bugs.freedesktop.org/show_bug.cgi?id=27268





--- Comment #2 from Karthik Hariharakrishnan <kar...@ar...>  2010-03-23 11:42:05 PST ---
Created an attachment (id=34373)
 --> (http://bugs.freedesktop.org/attachment.cgi?id=34373)
Reference image with no step constructor


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.