Re: [E-devel] EFL Autotools freeze proposal
On Thu, Apr 25, 2019 at 04:40:40PM +, Jonathan Aquilina wrote: > Hi Ross thanks for the tips, I don't think it is that easy to get > something in to backports unless it fixes a bug or security > vulnerability hence the use of PPA's they allow for bleeding edge > stuff. I think you're mixing up backports & stable. Stable releases only accept security fixes & small changes. Backports provides a path for selectively providing newer versions of software to stable. It's an opt-in repo. See: https://help.ubuntu.com/community/UbuntuBackports (The same is true for Debian.) It shouldn't be too hard to get new backports accepted - the hardest piece is probably finding someone to do the testing. Ross ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL Autotools freeze proposal
Hi Ross thanks for the tips, I don't think it is that easy to get something in to backports unless it fixes a bug or security vulnerability hence the use of PPA's they allow for bleeding edge stuff. Jonathan -Original Message- From: Ross Vandegrift Sent: 25 April 2019 18:31 To: Enlightenment developer list Subject: Re: [E-devel] EFL Autotools freeze proposal On Thu, Apr 25, 2019 at 07:45:41AM +, Jonathan Aquilina wrote: > @Stefan Schmidt I did a bit of digging one would need to package and > setup a PPA to be able to support any and all versions of meason in > this case in terms of supported releases. If you like I can try and > learn how to package and get something going in terms of a PPA for > meason and hell maybe even a PPA for enlightenment. Hi Jonathan, if you're interested, start here: https://wiki.ubuntu.com/UbuntuBackports meson 0.49 from disco cleanly builds in bionic, though I didn't do any testing of the result. (the meson tests do pass during build) The Debian packages for efl 1.21 & e22 are in disco as well. efl could probably be backported now, e might need newer meson in bionic-backports first. Ross ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL Autotools freeze proposal
On Thu, Apr 25, 2019 at 07:45:41AM +, Jonathan Aquilina wrote: > @Stefan Schmidt I did a bit of digging one would need to package and > setup a PPA to be able to support any and all versions of meason in > this case in terms of supported releases. If you like I can try and > learn how to package and get something going in terms of a PPA for > meason and hell maybe even a PPA for enlightenment. Hi Jonathan, if you're interested, start here: https://wiki.ubuntu.com/UbuntuBackports meson 0.49 from disco cleanly builds in bionic, though I didn't do any testing of the result. (the meson tests do pass during build) The Debian packages for efl 1.21 & e22 are in disco as well. efl could probably be backported now, e might need newer meson in bionic-backports first. Ross ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL Autotools freeze proposal
On Wed, Apr 24, 2019 at 10:17:03AM +0200, Stefan Schmidt wrote: > If I look around at other long term distro releases I can see this: > - Debian stable has a recent backport > - Ubuntu 18.04 (LTS) does ship 0.45.1 and I can't find a backport -> problem > - Fedora has 0.47.2 back to fedora 28 and Fedora EPAL 7 > - OpenSuse Leap 15.0 actually offers 0.46.0 while Leap 42.3 is still on > 0.40.1 > > To mean that means I would like to know if you consider Leap 42.3 an > important target for an upcoming EFL release (does it actually have all > the other deps fr such a new release?). Also we need to find out if > there are backports of meson >= 0.46 for Ubuntu 18.04 which I have not > found. There's no existing backport but one has been requested: https://bugs.launchpad.net/bionic-backports/+bug/1815092 I did a quick test, meson 0.49 builds in 18.04 with no changes & no additional backports. So I think this can be overcome for Ubuntu 18.04, though it may need someone to push it along. Ross ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL Autotools freeze proposal
@Vincent I always forget we have heaps of information on the Wiki... I created a task to port the Windows installation instructions to the site docs! https://phab.enlightenment.org/T7827 Xavi On Thu, 25 Apr 2019 at 11:38, Vincent Torri wrote: > On Thu, Apr 25, 2019 at 10:59 AM Xavi Artigas > wrote: > > > > @Jonathan regarding documentation, this is what we currently have: > > https://www.enlightenment.org/docs/distros/start > > With specific instructions for many distros on the right-hand navigation > > bar. > > what about windows ? everything is in the wiki for windows btw. > > Vincent > > > However, they are outdated and do not include meson instructions. > > I just created a Phab task so we do not forget about this: > > https://phab.enlightenment.org/T7826 > > > > Xavi > > > > On Thu, 25 Apr 2019 at 09:50, Carsten Haitzler > wrote: > > > > > On Thu, 25 Apr 2019 08:18:49 +0200 Marcel Hollerbach > > > said: > > > > > > > Hi, > > > > > > > > you can find our build definitions for osx in > > > > > https://git.enlightenment.org/core/efl.git/tree/.ci/ci-configure.sh#n49 > > > > > > > > Things do work on macos, you can rendering with cocoa, beside the > normal > > > > rendering bugs, things are normal there. > > > > > > gl as well as software? > > > > > > > Greetings, > > > >bu5hm4n > > > > > > > > On 4/25/19 7:20 AM, Jonathan Aquilina wrote: > > > > > Hi Guys, > > > > > > > > > > Regarding the state of things on OSX is the documentation updated > to > > > > > reflect the changes for meason as I am willing to test and report > back > > > to > > > > > you guys with feed back. > > > > > > > > > > Regards, > > > > > Jonathan > > > > > > > > > > -Original Message- > > > > > From: Carsten Haitzler > > > > > Sent: 24 April 2019 23:24 > > > > > To: Enlightenment developer list < > > > enlightenment-devel@lists.sourceforge.net> > > > > > Subject: Re: [E-devel] EFL Autotools freeze proposal > > > > > > > > > > On Wed, 24 Apr 2019 10:27:26 +0200 Stefan Schmidt > > > > > said: > > > > > > > > > >> Hello. > > > > >> > > > > >> On 17.04.19 15:15, Carsten Haitzler (The Rasterman) wrote: > > > > >>> On Wed, 17 Apr 2019 08:19:35 -0400 Mike Blumenkrantz > > > > >>> said: > > > > >>> > > > > Hi, > > > > > > > > We are currently in the 1.23 release cycle, and it seems agreed > > > > upon that we are planning to remove autotools prior to the 1.23 > > > > release. Overall, the meson build is in reasonable shape--there > are > > > > some small issues on our main platforms (and larger ones for > > > > Windows)--and it should not be an issue to meet this goal. > > > > >>> > > > > >>> i thought meson was in better shape... > > > > >>> > > > > With this in mind, I would like to propose a freeze on the > > > > autotools build starting Friday. This means that we no longer > > > > modify the autotools build in any way in the master branch > > > > (excepting outstanding patches in phab), and instead focus > entirely > > > on > > > > ensuring the quality of the meson build system. > > > > >>> > > > > >>> i think we should push this off a few more weeks/month or 2. > > > > >> > > > > >> I would like to get reports on what is actually missing or > > > problematic. > > > > >> We can push back the freeze a bit, but its only a freeze, not the > > > > >> autotools removal. And we need people to switch over to see if all > > > the > > > > >> crazy use cases we do not have are covered. > > > > > > > > > > the issue i saw got fixed by bu5hm4n since, but we really need to > go > > > over > > > > > everything in detail before removing autofoo - ensure it matches up > > > > > correctly and installs the same things in the same places before > > > removal. > > > > > windows support is another big one. do we know the state on osx? > > > > > > > > > >>> > > > > There is not much action which would need to be taken for this: > > > > * stop patching build files > > > > * disable CI jobs for autotools > > > > > > > > > > > > I think this would help to streamline build system development > and > > > > reduce overhead for this release. > > > > >>> > > > > >>> i agree on this - but the autofoo needs to still work and be up > to > > > > >>> date until the point where meson is equivalent - the windows > work is > > > > >>> one ware it needs to catch up on for sure as well as some other > > > > >>> niggles. get all of these up to snuff and... yup. drop autotools. > > > > >> > > > > >> ok, so a concrete list of things that blocks autotools freeze and > > > removal: > > > > >> > > > > >> 1) Windows port: ecore_win32 (gdi and ddraw engines) need to work, > > > > >> maybe more to come, feedback from Vincent needed. > > > > > > > > > > yup. > > > > > > > > > >> 2) Meson minumim version requirement: Need to check if there is a > > > > >> backport for Ubuntu LTS, maybe a list with meson versions on > > > different > > > > >> distros? > > > > > > > > > > the
Re: [E-devel] Seeking inout for Enlightenment Developer Days 2019
On 4/25/19 11:48 AM, Stefan Schmidt wrote: > Hello. > > We did not come around to have EDDs last year and we shoul do better > this year again. :-) > > Right now I would like to seek some inout on where and when. > > Right now we seem to have the following location offers: > o Jonathan offered Malta again (Would that be the same location as last > time?) > o Stefan could offer the SRUK office in Staines, UK > o Marcel might be able to offer hosting at the University in Karlsruhe, > Germany > > I remember Paris was nice due to the french community parts. Anyone > could offer hosting there? > > > The other input vector would be dates. We normally aim for > Saturday+Sunday. That should work best for the community. Is that still > accurate? > > July and August have already been announced as problematic due to summer > vacations. May would be to early to make this happen. That leaves June > or September onwards. Preferences? Just as a sidenote: I needed to give informations *when* i wanted to have rooms in the university. So if there is room in the university, its the 22. / 23.06 or 29./30.06 > > regards > Stefan Schmidt > > > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > pEpkey.asc Description: application/pgp-keys ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
[E-devel] Seeking inout for Enlightenment Developer Days 2019
Hello. We did not come around to have EDDs last year and we shoul do better this year again. :-) Right now I would like to seek some inout on where and when. Right now we seem to have the following location offers: o Jonathan offered Malta again (Would that be the same location as last time?) o Stefan could offer the SRUK office in Staines, UK o Marcel might be able to offer hosting at the University in Karlsruhe, Germany I remember Paris was nice due to the french community parts. Anyone could offer hosting there? The other input vector would be dates. We normally aim for Saturday+Sunday. That should work best for the community. Is that still accurate? July and August have already been announced as problematic due to summer vacations. May would be to early to make this happen. That leaves June or September onwards. Preferences? regards Stefan Schmidt ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL Autotools freeze proposal
On Thu, Apr 25, 2019 at 10:59 AM Xavi Artigas wrote: > > @Jonathan regarding documentation, this is what we currently have: > https://www.enlightenment.org/docs/distros/start > With specific instructions for many distros on the right-hand navigation > bar. what about windows ? everything is in the wiki for windows btw. Vincent > However, they are outdated and do not include meson instructions. > I just created a Phab task so we do not forget about this: > https://phab.enlightenment.org/T7826 > > Xavi > > On Thu, 25 Apr 2019 at 09:50, Carsten Haitzler wrote: > > > On Thu, 25 Apr 2019 08:18:49 +0200 Marcel Hollerbach > > said: > > > > > Hi, > > > > > > you can find our build definitions for osx in > > > https://git.enlightenment.org/core/efl.git/tree/.ci/ci-configure.sh#n49 > > > > > > Things do work on macos, you can rendering with cocoa, beside the normal > > > rendering bugs, things are normal there. > > > > gl as well as software? > > > > > Greetings, > > >bu5hm4n > > > > > > On 4/25/19 7:20 AM, Jonathan Aquilina wrote: > > > > Hi Guys, > > > > > > > > Regarding the state of things on OSX is the documentation updated to > > > > reflect the changes for meason as I am willing to test and report back > > to > > > > you guys with feed back. > > > > > > > > Regards, > > > > Jonathan > > > > > > > > -Original Message- > > > > From: Carsten Haitzler > > > > Sent: 24 April 2019 23:24 > > > > To: Enlightenment developer list < > > enlightenment-devel@lists.sourceforge.net> > > > > Subject: Re: [E-devel] EFL Autotools freeze proposal > > > > > > > > On Wed, 24 Apr 2019 10:27:26 +0200 Stefan Schmidt > > > > said: > > > > > > > >> Hello. > > > >> > > > >> On 17.04.19 15:15, Carsten Haitzler (The Rasterman) wrote: > > > >>> On Wed, 17 Apr 2019 08:19:35 -0400 Mike Blumenkrantz > > > >>> said: > > > >>> > > > Hi, > > > > > > We are currently in the 1.23 release cycle, and it seems agreed > > > upon that we are planning to remove autotools prior to the 1.23 > > > release. Overall, the meson build is in reasonable shape--there are > > > some small issues on our main platforms (and larger ones for > > > Windows)--and it should not be an issue to meet this goal. > > > >>> > > > >>> i thought meson was in better shape... > > > >>> > > > With this in mind, I would like to propose a freeze on the > > > autotools build starting Friday. This means that we no longer > > > modify the autotools build in any way in the master branch > > > (excepting outstanding patches in phab), and instead focus entirely > > on > > > ensuring the quality of the meson build system. > > > >>> > > > >>> i think we should push this off a few more weeks/month or 2. > > > >> > > > >> I would like to get reports on what is actually missing or > > problematic. > > > >> We can push back the freeze a bit, but its only a freeze, not the > > > >> autotools removal. And we need people to switch over to see if all > > the > > > >> crazy use cases we do not have are covered. > > > > > > > > the issue i saw got fixed by bu5hm4n since, but we really need to go > > over > > > > everything in detail before removing autofoo - ensure it matches up > > > > correctly and installs the same things in the same places before > > removal. > > > > windows support is another big one. do we know the state on osx? > > > > > > > >>> > > > There is not much action which would need to be taken for this: > > > * stop patching build files > > > * disable CI jobs for autotools > > > > > > > > > I think this would help to streamline build system development and > > > reduce overhead for this release. > > > >>> > > > >>> i agree on this - but the autofoo needs to still work and be up to > > > >>> date until the point where meson is equivalent - the windows work is > > > >>> one ware it needs to catch up on for sure as well as some other > > > >>> niggles. get all of these up to snuff and... yup. drop autotools. > > > >> > > > >> ok, so a concrete list of things that blocks autotools freeze and > > removal: > > > >> > > > >> 1) Windows port: ecore_win32 (gdi and ddraw engines) need to work, > > > >> maybe more to come, feedback from Vincent needed. > > > > > > > > yup. > > > > > > > >> 2) Meson minumim version requirement: Need to check if there is a > > > >> backport for Ubuntu LTS, maybe a list with meson versions on > > different > > > >> distros? > > > > > > > > there has to be a line we draw. thing of this: RH support their distro > > for > > > > 10 years. does that means we need to also rely on 10 year old build > > tools > > > > too because that is what distro does? just because distros are > > conservative > > > > doesn't necessarily mean we have to also be. > > > > > > > > now, that being said, it does present a problem. this problem will > > > > eventually go away in time, so perhaps it means no efl upgrade on those > > > > distros unless they also get a backporte
Re: [E-devel] EFL Autotools freeze proposal
Hello. On 25.04.19 09:45, Jonathan Aquilina wrote: > @Stefan Schmidt I did a bit of digging one would need to package and setup a > PPA to be able to support any and all versions of meason in this case in > terms of supported releases. If you like I can try and learn how to package > and get something going in terms of a PPA for meason and hell maybe even a > PPA for enlightenment. The problem is that we would the official meson package in the distro to be updated. You could work the Ubuntu team to see if that is possible. Having a PPA for a newer meson might be an option if the other scenario fails. regards Stefan Schmidt ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL 1.22.2
Hi, Le 23/04/2019 à 15:16, Mike Blumenkrantz a écrit : > Hi, > > I am looking to attempt a stable release sometime around next Wednesday (1 > May 2019) so that we can pull in any fixes which have been made to catch > more noticeable issues. At that time, I will personally handle backporting > for any patches which are not already backported. > > If anyone has any suggestions or items to discuss regarding this schedule, > please bring them forward. EFL 1.22.x doesn't build with old compiler (gcc < 5): https://phab.enlightenment.org/T7818 Best regards, Romain > > > Regards, > Mike > > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL Autotools freeze proposal
@Jonathan regarding documentation, this is what we currently have: https://www.enlightenment.org/docs/distros/start With specific instructions for many distros on the right-hand navigation bar. However, they are outdated and do not include meson instructions. I just created a Phab task so we do not forget about this: https://phab.enlightenment.org/T7826 Xavi On Thu, 25 Apr 2019 at 09:50, Carsten Haitzler wrote: > On Thu, 25 Apr 2019 08:18:49 +0200 Marcel Hollerbach > said: > > > Hi, > > > > you can find our build definitions for osx in > > https://git.enlightenment.org/core/efl.git/tree/.ci/ci-configure.sh#n49 > > > > Things do work on macos, you can rendering with cocoa, beside the normal > > rendering bugs, things are normal there. > > gl as well as software? > > > Greetings, > >bu5hm4n > > > > On 4/25/19 7:20 AM, Jonathan Aquilina wrote: > > > Hi Guys, > > > > > > Regarding the state of things on OSX is the documentation updated to > > > reflect the changes for meason as I am willing to test and report back > to > > > you guys with feed back. > > > > > > Regards, > > > Jonathan > > > > > > -Original Message- > > > From: Carsten Haitzler > > > Sent: 24 April 2019 23:24 > > > To: Enlightenment developer list < > enlightenment-devel@lists.sourceforge.net> > > > Subject: Re: [E-devel] EFL Autotools freeze proposal > > > > > > On Wed, 24 Apr 2019 10:27:26 +0200 Stefan Schmidt > > > said: > > > > > >> Hello. > > >> > > >> On 17.04.19 15:15, Carsten Haitzler (The Rasterman) wrote: > > >>> On Wed, 17 Apr 2019 08:19:35 -0400 Mike Blumenkrantz > > >>> said: > > >>> > > Hi, > > > > We are currently in the 1.23 release cycle, and it seems agreed > > upon that we are planning to remove autotools prior to the 1.23 > > release. Overall, the meson build is in reasonable shape--there are > > some small issues on our main platforms (and larger ones for > > Windows)--and it should not be an issue to meet this goal. > > >>> > > >>> i thought meson was in better shape... > > >>> > > With this in mind, I would like to propose a freeze on the > > autotools build starting Friday. This means that we no longer > > modify the autotools build in any way in the master branch > > (excepting outstanding patches in phab), and instead focus entirely > on > > ensuring the quality of the meson build system. > > >>> > > >>> i think we should push this off a few more weeks/month or 2. > > >> > > >> I would like to get reports on what is actually missing or > problematic. > > >> We can push back the freeze a bit, but its only a freeze, not the > > >> autotools removal. And we need people to switch over to see if all > the > > >> crazy use cases we do not have are covered. > > > > > > the issue i saw got fixed by bu5hm4n since, but we really need to go > over > > > everything in detail before removing autofoo - ensure it matches up > > > correctly and installs the same things in the same places before > removal. > > > windows support is another big one. do we know the state on osx? > > > > > >>> > > There is not much action which would need to be taken for this: > > * stop patching build files > > * disable CI jobs for autotools > > > > > > I think this would help to streamline build system development and > > reduce overhead for this release. > > >>> > > >>> i agree on this - but the autofoo needs to still work and be up to > > >>> date until the point where meson is equivalent - the windows work is > > >>> one ware it needs to catch up on for sure as well as some other > > >>> niggles. get all of these up to snuff and... yup. drop autotools. > > >> > > >> ok, so a concrete list of things that blocks autotools freeze and > removal: > > >> > > >> 1) Windows port: ecore_win32 (gdi and ddraw engines) need to work, > > >> maybe more to come, feedback from Vincent needed. > > > > > > yup. > > > > > >> 2) Meson minumim version requirement: Need to check if there is a > > >> backport for Ubuntu LTS, maybe a list with meson versions on > different > > >> distros? > > > > > > there has to be a line we draw. thing of this: RH support their distro > for > > > 10 years. does that means we need to also rely on 10 year old build > tools > > > too because that is what distro does? just because distros are > conservative > > > doesn't necessarily mean we have to also be. > > > > > > now, that being said, it does present a problem. this problem will > > > eventually go away in time, so perhaps it means no efl upgrade on those > > > distros unless they also get a backported newer meson too. the pip > solution > > > also works in many cases but not so much for official packagers as they > > > have to stick to tools provided on the distro, but packages can be > built in > > > a users environment where they used pip to get a newer meson, so it > can be > > > done. it just requires being a bit dirty. > > > > > >> Pretty sure there will be more, but
Re: [E-devel] Jenkins (again)
hi guys, seems jenkins is already down, I would like to save the python-efl build configuration, it was part of the release process and now I miss some info. Is someone able to find the jenkins python-efl script in some way? Thanks in advance Il giorno mer 24 apr 2019 alle ore 09:49 Stefan Schmidt < ste...@datenfreihafen.org> ha scritto: > Hello. > > [Beber CC'ed] > > On 17.04.19 17:22, Mike Blumenkrantz wrote: > > Hi, > > > > I've been getting this when pushing to the efl repo lately: > > > > remote: post-receive-020-notify-jenkins: Notifying Jenkins > > remote: curl: (28) Connection timed out after 10004 milliseconds > > > > Does anyone know how to resolve this? > > Its part of the git server hook script that notifies Jenkins. I think we > should remove this now and tear down Jenkins. > > Beber, could you remove the Jenkins notification from the git server > hook? I also think that we can shutdown build.e.org now without a real > loss. > > regards > Stefan Schmidt > > > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL Autotools freeze proposal
On Thu, 25 Apr 2019 08:18:49 +0200 Marcel Hollerbach said: > Hi, > > you can find our build definitions for osx in > https://git.enlightenment.org/core/efl.git/tree/.ci/ci-configure.sh#n49 > > Things do work on macos, you can rendering with cocoa, beside the normal > rendering bugs, things are normal there. gl as well as software? > Greetings, >bu5hm4n > > On 4/25/19 7:20 AM, Jonathan Aquilina wrote: > > Hi Guys, > > > > Regarding the state of things on OSX is the documentation updated to > > reflect the changes for meason as I am willing to test and report back to > > you guys with feed back. > > > > Regards, > > Jonathan > > > > -Original Message- > > From: Carsten Haitzler > > Sent: 24 April 2019 23:24 > > To: Enlightenment developer list > > Subject: Re: [E-devel] EFL Autotools freeze proposal > > > > On Wed, 24 Apr 2019 10:27:26 +0200 Stefan Schmidt > > said: > > > >> Hello. > >> > >> On 17.04.19 15:15, Carsten Haitzler (The Rasterman) wrote: > >>> On Wed, 17 Apr 2019 08:19:35 -0400 Mike Blumenkrantz > >>> said: > >>> > Hi, > > We are currently in the 1.23 release cycle, and it seems agreed > upon that we are planning to remove autotools prior to the 1.23 > release. Overall, the meson build is in reasonable shape--there are > some small issues on our main platforms (and larger ones for > Windows)--and it should not be an issue to meet this goal. > >>> > >>> i thought meson was in better shape... > >>> > With this in mind, I would like to propose a freeze on the > autotools build starting Friday. This means that we no longer > modify the autotools build in any way in the master branch > (excepting outstanding patches in phab), and instead focus entirely on > ensuring the quality of the meson build system. > >>> > >>> i think we should push this off a few more weeks/month or 2. > >> > >> I would like to get reports on what is actually missing or problematic. > >> We can push back the freeze a bit, but its only a freeze, not the > >> autotools removal. And we need people to switch over to see if all the > >> crazy use cases we do not have are covered. > > > > the issue i saw got fixed by bu5hm4n since, but we really need to go over > > everything in detail before removing autofoo - ensure it matches up > > correctly and installs the same things in the same places before removal. > > windows support is another big one. do we know the state on osx? > > > >>> > There is not much action which would need to be taken for this: > * stop patching build files > * disable CI jobs for autotools > > > I think this would help to streamline build system development and > reduce overhead for this release. > >>> > >>> i agree on this - but the autofoo needs to still work and be up to > >>> date until the point where meson is equivalent - the windows work is > >>> one ware it needs to catch up on for sure as well as some other > >>> niggles. get all of these up to snuff and... yup. drop autotools. > >> > >> ok, so a concrete list of things that blocks autotools freeze and removal: > >> > >> 1) Windows port: ecore_win32 (gdi and ddraw engines) need to work, > >> maybe more to come, feedback from Vincent needed. > > > > yup. > > > >> 2) Meson minumim version requirement: Need to check if there is a > >> backport for Ubuntu LTS, maybe a list with meson versions on different > >> distros? > > > > there has to be a line we draw. thing of this: RH support their distro for > > 10 years. does that means we need to also rely on 10 year old build tools > > too because that is what distro does? just because distros are conservative > > doesn't necessarily mean we have to also be. > > > > now, that being said, it does present a problem. this problem will > > eventually go away in time, so perhaps it means no efl upgrade on those > > distros unless they also get a backported newer meson too. the pip solution > > also works in many cases but not so much for official packagers as they > > have to stick to tools provided on the distro, but packages can be built in > > a users environment where they used pip to get a newer meson, so it can be > > done. it just requires being a bit dirty. > > > >> Pretty sure there will be more, but the question is if we find out > >> before we drop autotools or not. > >> > >> regards > >> Stefan Schmidt > >> > >> > >> ___ > >> enlightenment-devel mailing list > >> enlightenment-devel@lists.sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > >> > > > > > > -- > > - Codito, ergo sum - "I code, therefore I am" -- > > Carsten Haitzler - ras...@rasterman.com > > > > > > > > ___ > > enlightenment-devel mailing list > > enlightenment-devel@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/enlig
Re: [E-devel] EFL Autotools freeze proposal
@Stefan Schmidt I did a bit of digging one would need to package and setup a PPA to be able to support any and all versions of meason in this case in terms of supported releases. If you like I can try and learn how to package and get something going in terms of a PPA for meason and hell maybe even a PPA for enlightenment. -Original Message- From: Stefan Schmidt Sent: 25 April 2019 09:43 To: Carsten Haitzler (The Rasterman) ; Enlightenment developer list Subject: Re: [E-devel] EFL Autotools freeze proposal Hello. On 24.04.19 23:23, Carsten Haitzler (The Rasterman) wrote: > On Wed, 24 Apr 2019 10:27:26 +0200 Stefan Schmidt > > said: > >> Hello. >> >> On 17.04.19 15:15, Carsten Haitzler (The Rasterman) wrote: >>> On Wed, 17 Apr 2019 08:19:35 -0400 Mike Blumenkrantz >>> said: >>> Hi, We are currently in the 1.23 release cycle, and it seems agreed upon that we are planning to remove autotools prior to the 1.23 release. Overall, the meson build is in reasonable shape--there are some small issues on our main platforms (and larger ones for Windows)--and it should not be an issue to meet this goal. >>> >>> i thought meson was in better shape... >>> With this in mind, I would like to propose a freeze on the autotools build starting Friday. This means that we no longer modify the autotools build in any way in the master branch (excepting outstanding patches in phab), and instead focus entirely on ensuring the quality of the meson build system. >>> >>> i think we should push this off a few more weeks/month or 2. >> >> I would like to get reports on what is actually missing or problematic. >> We can push back the freeze a bit, but its only a freeze, not the >> autotools removal. And we need people to switch over to see if all >> the crazy use cases we do not have are covered. > > the issue i saw got fixed by bu5hm4n since, but we really need to go > over everything in detail before removing autofoo - ensure it matches > up correctly and installs the same things in the same places before removal. One test that should shed some light one things is to build and install efl with autotools as well as meson and compare the two destirs to find differences in the install. windows support > is another big one. do we know the state on osx? OSX is building with meson for a long time on CI for every push. >>> There is not much action which would need to be taken for this: * stop patching build files * disable CI jobs for autotools I think this would help to streamline build system development and reduce overhead for this release. >>> >>> i agree on this - but the autofoo needs to still work and be up to >>> date until the point where meson is equivalent - the windows work is >>> one ware it needs to catch up on for sure as well as some other >>> niggles. get all of these up to snuff and... yup. drop autotools. >> >> ok, so a concrete list of things that blocks autotools freeze and removal: >> >> 1) Windows port: ecore_win32 (gdi and ddraw engines) need to work, >> maybe more to come, feedback from Vincent needed. > > yup. > >> 2) Meson minumim version requirement: Need to check if there is a >> backport for Ubuntu LTS, maybe a list with meson versions on >> different distros? > > there has to be a line we draw. thing of this: RH support their distro > for 10 years. does that means we need to also rely on 10 year old > build tools too because that is what distro does? just because distros > are conservative doesn't necessarily mean we have to also be. This is very similar to how we work with new dependencies or new version of deps. Aiming to support the *latest* LTS release from distros should be a goal, if possible. When the meson version was brought up as problem the last tiem I remember talking to Marcel to find out if that version is needed for performance improvements or if it has fixes that are needed to actually build efl with meson at all. IIRC it was the last one. Still waiting on Simotek about which version of Suse he wants to support. Also Ubuntu LTS needs digging if there is a backport. Right now I do not see this as a dramatic setback. We still have at least 4 months to go before the next release (new distros will ship or get updated). What we should avoid though is to update the meson version requirement. > now, that being said, it does present a problem. this problem will > eventually go away in time, so perhaps it means no efl upgrade on > those distros unless they also get a backported newer meson too. the > pip solution also works in many cases but not so much for official > packagers as they have to stick to tools provided on the distro, but > packages can be built in a users environment where they used pip to > get a newer meson, so it can be done. it just requires being a bit dirty. For developers and users building from git its most likely fi
Re: [E-devel] EFL Autotools freeze proposal
Hello. On 24.04.19 23:23, Carsten Haitzler (The Rasterman) wrote: > On Wed, 24 Apr 2019 10:27:26 +0200 Stefan Schmidt > said: > >> Hello. >> >> On 17.04.19 15:15, Carsten Haitzler (The Rasterman) wrote: >>> On Wed, 17 Apr 2019 08:19:35 -0400 Mike Blumenkrantz >>> said: >>> Hi, We are currently in the 1.23 release cycle, and it seems agreed upon that we are planning to remove autotools prior to the 1.23 release. Overall, the meson build is in reasonable shape--there are some small issues on our main platforms (and larger ones for Windows)--and it should not be an issue to meet this goal. >>> >>> i thought meson was in better shape... >>> With this in mind, I would like to propose a freeze on the autotools build starting Friday. This means that we no longer modify the autotools build in any way in the master branch (excepting outstanding patches in phab), and instead focus entirely on ensuring the quality of the meson build system. >>> >>> i think we should push this off a few more weeks/month or 2. >> >> I would like to get reports on what is actually missing or problematic. >> We can push back the freeze a bit, but its only a freeze, not the >> autotools removal. And we need people to switch over to see if all the >> crazy use cases we do not have are covered. > > the issue i saw got fixed by bu5hm4n since, but we really need to go over > everything in detail before removing autofoo - ensure it matches up correctly > and installs the same things in the same places before removal. One test that should shed some light one things is to build and install efl with autotools as well as meson and compare the two destirs to find differences in the install. windows support > is another big one. do we know the state on osx? OSX is building with meson for a long time on CI for every push. >>> There is not much action which would need to be taken for this: * stop patching build files * disable CI jobs for autotools I think this would help to streamline build system development and reduce overhead for this release. >>> >>> i agree on this - but the autofoo needs to still work and be up to date >>> until the point where meson is equivalent - the windows work is one ware it >>> needs to catch up on for sure as well as some other niggles. get all of >>> these up to snuff and... yup. drop autotools. >> >> ok, so a concrete list of things that blocks autotools freeze and removal: >> >> 1) Windows port: ecore_win32 (gdi and ddraw engines) need to work, maybe >> more to come, feedback from Vincent needed. > > yup. > >> 2) Meson minumim version requirement: Need to check if there is a >> backport for Ubuntu LTS, maybe a list with meson versions on different >> distros? > > there has to be a line we draw. thing of this: RH support their distro for 10 > years. does that means we need to also rely on 10 year old build tools too > because that is what distro does? just because distros are conservative > doesn't > necessarily mean we have to also be. This is very similar to how we work with new dependencies or new version of deps. Aiming to support the *latest* LTS release from distros should be a goal, if possible. When the meson version was brought up as problem the last tiem I remember talking to Marcel to find out if that version is needed for performance improvements or if it has fixes that are needed to actually build efl with meson at all. IIRC it was the last one. Still waiting on Simotek about which version of Suse he wants to support. Also Ubuntu LTS needs digging if there is a backport. Right now I do not see this as a dramatic setback. We still have at least 4 months to go before the next release (new distros will ship or get updated). What we should avoid though is to update the meson version requirement. > now, that being said, it does present a problem. this problem will eventually > go away in time, so perhaps it means no efl upgrade on those distros unless > they also get a backported newer meson too. the pip solution also works in > many > cases but not so much for official packagers as they have to stick to tools > provided on the distro, but packages can be built in a users environment where > they used pip to get a newer meson, so it can be done. it just requires being > a > bit dirty. For developers and users building from git its most likely fine as they tend to have newer distros. If not pip will do the trick for them. The issue is really more about official packages and distros that ship efl to give them a sane upgrade path. regards Stefan Schmidt ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
