- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] 64 bit VM build problems: gl.h not found, or glRenderer conflicts

by Alistair Grant

Hi Subbu & Eliot, Thanks for your replies. They've made me realise that I'm looking in the wrong spot, so I'll take another look before asking any more questions. I'm also travelling tomorrow, so will be without internet for 3 or 4 days. Thanks again, Alistair On 26 January 2018 at 15:48, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > >> On Jan 26, 2018, at 3:00 AM, K K Subbu <kksubbu.ml(a)gmail.com> wrote: >> >> On Ubuntu 16.04, I had to use: >> >> sudo apt-get install uuid-dev libcairo2-dev libpango1.0-dev libgl1-mesa-dev libgl1-mesa-glx >> >> to get all dependencies. This was sometime ago and the change should have made it to build.linux64x64/HowToBuild by now. > > Thanks Subbu. Ignore my earlier message. Should have read you response first :-) > >> >> What exactly is your error message? >> >> Regards .. Subbu >> >>> On Friday 26 January 2018 01:24 AM, Alistair Grant wrote: >>> Hi, >>> I'm attempting to build the 64bit VM in a docker container on Ubuntu >>> 16.04 installing the required packages using >>> opensmalltalk-vm/.travis_install.sh, however B3DAcceleratorPlugin >>> fails to build because it can't find gl.h. >>> Installing mesa-common-dev (which is the most common answer when >>> searching for missing gl.h on google) changes the error to glRenderer >>> is redefined and has conflicting types. >>> Does anyone know what the correct combination of packages is? >>> Thanks! >>> Alistair >> >> >

Jan. 26, 2018

Re: [Pharo-dev] CI Hickups ...

by Stephane Ducasse

Yes now this is not easy to find the problems. I spent time reviewing your tearDown fixes and this is annoying to get broken tests when normally nothing should be red. On Fri, Jan 26, 2018 at 10:23 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > While our general build from Pharo 7 is (more or less often) green > > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > > I've noticed more and more that the CI builds for the PR's to Pharo 7 even for trivial changes are > often broken and not green > > https://github.com/pharo-project/pharo/pulls > > which is annoying and one still has the feeling to break the builds. > > As always I think getting a more stable CI is dependent on time, resources and priorities. But does anyone know > if this is a general issue or something that is already worked on? > > Thx > T. >

Jan. 26, 2018

Re: [Pharo-dev] Iceberg Loading issue

by Vincent.Blondeau＠lamresearch.com

Thanks Alistair! I'll try that. But, still, there is an issue somewhere in Iceberg. Cheers, Vincent -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Alistair Grant Sent: Friday, January 26, 2018 0:57 To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] Iceberg Loading issue Hi Vincent, Every time I've seen this question asked, the answer has been to checkout the branch that you want and then "Reload All" from the list of packages. Cheers, Alistair On 26 January 2018 at 00:42, <Vincent.Blondeau(a)lamresearch.com> wrote: > Hi, > > I am encountering some problems with Iceberg on the latest version. > > I want to load the commits I just made on a branch on my Pharo fork, let's say "21124". I set the local repo to the current version of my Pharo image, i.e. the development branch (commit 0dbf86). > Thanks to the iceberg interface, I change the current branch to "21124", there are 12 commits that are incoming. > Then, I then do "Pull incoming commit" to load them. > But after a few moment, instead of loading only the delta between the development branch and the "21124" one, iceberg goes further in the commit history and wants to load 174 commits... Including one that does not load. > > By debugging, it seems that there is a problem with LGitRepository>>fastForward:, the result of "self lookup: 'FETCH_HEAD'" gives not the good commit i.e. the one of the development branch (commit 0dbf86), but instead the one of "I do not what". > > Does this issue is known? And how can I bypass it or solve it? > > Thanks, > > Vincent

Jan. 26, 2018

[Pharo 7.0-dev] Build #462: 20757-Playground-should-be-extensible-as-GT-Inspector

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #462 was: SUCCESS. The Pull Request #745 was integrated: "20757-Playground-should-be-extensible-as-GT-Inspector" Pull request url: https://github.com/pharo-project/pharo/pull/745 Issue Url: https://pharo.fogbugz.com/f/cases/20757 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 26, 2018

[Pharo 7.0-dev] Build #461: 21110 Super tearDown need to be called as last message in tearDown ofâ¦

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #461 was: SUCCESS. The Pull Request #722 was integrated: "21110 Super tearDown need to be called as last message in tearDown ofâ¦" Pull request url: https://github.com/pharo-project/pharo/pull/722 Issue Url: https://pharo.fogbugz.com/f/cases/21110 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 26, 2018

[Pharo 7.0-dev] Build #460: 21108 Super tearDown need to be called as last message in tearDown of RGMethodDefinitionTest

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #460 was: SUCCESS. The Pull Request #723 was integrated: "21108 Super tearDown need to be called as last message in tearDown of RGMethodDefinitionTest" Pull request url: https://github.com/pharo-project/pharo/pull/723 Issue Url: https://pharo.fogbugz.com/f/cases/21108 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 26, 2018

Re: [Pharo-dev] 64 bit VM build problems: gl.h not found, or glRenderer conflicts

by Eliot Miranda

> On Jan 26, 2018, at 3:00 AM, K K Subbu <kksubbu.ml(a)gmail.com> wrote: > > On Ubuntu 16.04, I had to use: > > sudo apt-get install uuid-dev libcairo2-dev libpango1.0-dev libgl1-mesa-dev libgl1-mesa-glx > > to get all dependencies. This was sometime ago and the change should have made it to build.linux64x64/HowToBuild by now. Thanks Subbu. Ignore my earlier message. Should have read you response first :-) > > What exactly is your error message? > > Regards .. Subbu > >> On Friday 26 January 2018 01:24 AM, Alistair Grant wrote: >> Hi, >> I'm attempting to build the 64bit VM in a docker container on Ubuntu >> 16.04 installing the required packages using >> opensmalltalk-vm/.travis_install.sh, however B3DAcceleratorPlugin >> fails to build because it can't find gl.h. >> Installing mesa-common-dev (which is the most common answer when >> searching for missing gl.h on google) changes the error to glRenderer >> is redefined and has conflicting types. >> Does anyone know what the correct combination of packages is? >> Thanks! >> Alistair > >

Jan. 26, 2018

Re: [Pharo-dev] 64 bit VM build problems: gl.h not found, or glRenderer conflicts

by Eliot Miranda

Hi Alistair, > On Jan 25, 2018, at 11:54 AM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi, > > I'm attempting to build the 64 bit VM in a docker container on Ubuntu > 16.04 installing the required packages using > opensmalltalk-vm/.travis_install.sh, however B3DAcceleratorPlugin > fails to build because it can't find gl.h. > > Installing mesa-common-dev (which is the most common answer when > searching for missing gl.h on google) changes the error to glRenderer > is redefined and has conflicting types. > > Does anyone know what the correct combination of packages is? The information is supposed to be towards the bottom of build.linux64x64 so if it's missing and you find it please remember to add it there. > > Thanks! > Alistair >

Jan. 26, 2018

[Pharo 7.0-dev] Build #459: 21107 Super tearDown need to be called as last message in tearDown of RBRefactoringTest

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #459 was: FAILURE. The Pull Request #724 was integrated: "21107 Super tearDown need to be called as last message in tearDown of RBRefactoringTest" Pull request url: https://github.com/pharo-project/pharo/pull/724 Issue Url: https://pharo.fogbugz.com/f/cases/21107 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 26, 2018

Re: [Pharo-dev] CI Hickups ...

by Marcus Denker

> On 26 Jan 2018, at 14:42, Juraj Kubelka <juraj.kubelka(a)icloud.com> wrote: > > > >> On Jan 26, 2018, at 09:13, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> Hello, >> >> Yesâ¦ I try to make notes about all failing test so we can detect patterns >> > > Will you share the notes? > Here are some from todays reviews: testPatch â MacOS32.Zinc.Tests.ZnClientTests Failed to start server on port 1719. Is there one already? testTwiceDeliveredDataSholdBeDetected â MacOS32.GT.EventRecorder.Tests.Core.GTEventRecorderTest testTwiceDeliveredDataSholdBeDetected â Windows32.GT.EventRecorder.Tests.Core.GTEventRecorderTest testDeliverNow3 â Windows32.GT.EventRecorder.Tests.Core.GTEventRecorderTest testDeliverNow2 â Windows32.GT.EventRecorder.Tests.Core.GTEventRecorderTest testAddCollector3 â Windows32.GT.EventRecorder.Tests.Core.GTEventRecorderTest testNotDeliveredDataShouldBeResent â Windows32.GT.EventRecorder.Tests.Core.GTEventRecorderTest testGetPharoVersion â MacOS32.Zinc.Zodiac.ZnHTTPSTests testExecuteOnceAfterSchedulingMultipleTimes â MacOS32.OmbuTests.OmDeferrerTest

Jan. 26, 2018