Yeh, to be more precise, * the problem is that the image somehow got it's display size modified to a very small one. * And that happenned while building an image in the CI in headless mode. * If the same image is built locally in a vm launched in non-headless mode, the issue cannot be reproduced. So my conjecture is that - either the image is changing the display size while loading pillar (less likely and not reproduceable locally) - either the latest stable VM messes the display size in the image header when running on headless (this is yet to reproduce) On Sun, Mar 12, 2017 at 10:52 AM, stepharong <stepharong@free.fr> wrote:
guillermo was suspecting a problem with the interpretatin of the image metadata
Maybe related?
http://forum.world.st/BUG-A-problem-with-callbacks-that-show s-up-in-64bits-but-is-on-32bits-too-td4938152.html
On Sat, Mar 11, 2017 at 2:22 AM, Cyril Ferlicot <cyril.ferlicot@gmail.com> wrote:
On ven. 10 mars 2017 at 18:42, stepharong <stepharong@free.fr> wrote:
We found the problem with Guillermo and this may be a problem of the last VM.
The image got its starting window size really small: some pixels on some pixles. So may be the metadata of the image are systematically corrupted.
Hi
I have a jenkins that produce an image that does not start when I try to open it locally.
Now if I take the image and load the "same" configuration I get a working image
I have not idea how to debug that.
Stef
-- Using Opera's mail client: http://www.opera.com/mail/
If it can help: here is the build:
https://ci.inria.fr/pharo-contribution/job/OOnoz/
It is happening in almost all Pharo 6 builds -- Cheers Cyril Ferlicot
-- Using Opera's mail client: http://www.opera.com/mail/