Re: [E-devel] EFL Autotools freeze proposal
On Fri, 3 May 2019 19:01:36 +0930 Simon Lees said: > > > On 03/05/2019 18:08, Carsten Haitzler wrote: > > On Fri, 3 May 2019 09:54:58 +0930 Simon Lees said: > > > >> > >> > >> On 02/05/2019 21:17, Carsten Haitzler (The Rasterman) wrote: > >>> On Thu, 2 May 2019 08:41:36 +0930 Simon Lees said: > >>> > I have ways of creating 3rd party repo's easily, but currently you can > install enlightenment from the openSUSE installer, and I'd like to keep > that at the latest version for each new version of leap, so i'd like e23 > or later in Leap 15.2 (about a year away), which will probably need a > reasonably new efl, but will likely only have meson 0.46.0 which is fine > for e but atm not for efl. > > There are alot of people using e from the installer, I keep bumping into > them at conferences etc, GNU Health have been using openSUSE + > enlightenment on all there raspberry pi's etc, so there is a significant > number of people using e in this way, and i'd like them to stay > reasonably up to date. > >>> > >>> at worst other rpm's can be provided for such upgrades - it's a temporary > >>> situation until the next suse release anyway which should have upgraded > >>> by then... :) > >>> > >> > >> Except it quite possibly will not, its not guarenteed until Leap 16 > >> which isn't really even been thought about much yet. > > > > Leave 16 will fix it. Other projects probably will push a newer meson > > version too, not just us. > > > > If susue doesn't want to upgrade meson because it's a requirement to do so > > due to bugs in it that needed fixing so efl can build, then I guess suse > > can live with not upgrading efl if we're that low priority. If it's > > important to suse to upgrade efl then it will be important to upgrade meson > > too. :) i don't see this as being an issue when the next version comes > > out. :) > > What bugs are these? and were they fixed between 0.46.0 and 0.47.0? I'm > only asking to go back one version from 0.47.0 to 0.46.0 which is what > were currently requiring for e. > > If there is a bug that causes 0.46.0 to fail to build efl then we can > get efl building with the Meson 0.46.0 api, keep the minimum version at > 0.47.0 and i'll get the fix backported into SUSE's version of meson then > patch efl to accept the older meson. See what Marcel said - I knew some of it, not all. Literally we have features that DEPEND on 0.47 or better or efl won't build. > But I don't really want to be working with a old e / efl for the next 2 > years possibly. See what Marcel said and pointed to. Basically in this case suse is wrong in its policy if it's going to not upgrade meson. the nature of meson is that it's new and still maturing and will need upgrades as a result to meet the needs of projects using it. if a distribution does not want to deal with that reality then unfortunately it's going to have to deal with "no upgrades of e or efl etc." either. this is the reality of the situation. we really have no choice but to march on - we can't have 2 build systems for another 2 years because of suse policy. not going to happen. suse will likely not be able to upgrade gnome either as i already mentioned, so ... :) -- - 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/enlightenment-devel
Re: [E-devel] EFL Autotools freeze proposal
On 5/3/19 11:31 AM, Simon Lees wrote: > > > On 03/05/2019 18:08, Carsten Haitzler wrote: >> On Fri, 3 May 2019 09:54:58 +0930 Simon Lees said: >> >>> >>> >>> On 02/05/2019 21:17, Carsten Haitzler (The Rasterman) wrote: On Thu, 2 May 2019 08:41:36 +0930 Simon Lees said: > I have ways of creating 3rd party repo's easily, but currently you can > install enlightenment from the openSUSE installer, and I'd like to > keep > that at the latest version for each new version of leap, so i'd > like e23 > or later in Leap 15.2 (about a year away), which will probably need a > reasonably new efl, but will likely only have meson 0.46.0 which is > fine > for e but atm not for efl. > > There are alot of people using e from the installer, I keep bumping > into > them at conferences etc, GNU Health have been using openSUSE + > enlightenment on all there raspberry pi's etc, so there is a > significant > number of people using e in this way, and i'd like them to stay > reasonably up to date. at worst other rpm's can be provided for such upgrades - it's a temporary situation until the next suse release anyway which should have upgraded by then... :) >>> >>> Except it quite possibly will not, its not guarenteed until Leap 16 >>> which isn't really even been thought about much yet. >> >> Leave 16 will fix it. Other projects probably will push a newer meson >> version >> too, not just us. >> >> If susue doesn't want to upgrade meson because it's a requirement to >> do so due >> to bugs in it that needed fixing so efl can build, then I guess suse >> can live >> with not upgrading efl if we're that low priority. If it's important >> to suse to >> upgrade efl then it will be important to upgrade meson too. :) i don't >> see this >> as being an issue when the next version comes out. :) > > What bugs are these? and were they fixed between 0.46.0 and 0.47.0? I'm > only asking to go back one version from 0.47.0 to 0.46.0 which is what > were currently requiring for e. > > If there is a bug that causes 0.46.0 to fail to build efl then we can > get efl building with the Meson 0.46.0 api, keep the minimum version at > 0.47.0 and i'll get the fix backported into SUSE's version of meson then > patch efl to accept the older meson. The reasons for our meson version are listed here: https://phab.enlightenment.org/w/efl_minimum_meson_version/ Additionally, there have been major performance improvements, which dragged the configure time from > 2 min. to something at 20 sec. A bug in the test runner lead to deadlocks when our testsuites have been running. Some .pc files contained wrongly generated flags. > But I don't really want to be working with a old e / efl for the next 2 > years possibly. > pEpkey.asc Description: application/pgp-keys ___ 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 03/05/2019 18:08, Carsten Haitzler wrote: On Fri, 3 May 2019 09:54:58 +0930 Simon Lees said: On 02/05/2019 21:17, Carsten Haitzler (The Rasterman) wrote: On Thu, 2 May 2019 08:41:36 +0930 Simon Lees said: I have ways of creating 3rd party repo's easily, but currently you can install enlightenment from the openSUSE installer, and I'd like to keep that at the latest version for each new version of leap, so i'd like e23 or later in Leap 15.2 (about a year away), which will probably need a reasonably new efl, but will likely only have meson 0.46.0 which is fine for e but atm not for efl. There are alot of people using e from the installer, I keep bumping into them at conferences etc, GNU Health have been using openSUSE + enlightenment on all there raspberry pi's etc, so there is a significant number of people using e in this way, and i'd like them to stay reasonably up to date. at worst other rpm's can be provided for such upgrades - it's a temporary situation until the next suse release anyway which should have upgraded by then... :) Except it quite possibly will not, its not guarenteed until Leap 16 which isn't really even been thought about much yet. Leave 16 will fix it. Other projects probably will push a newer meson version too, not just us. If susue doesn't want to upgrade meson because it's a requirement to do so due to bugs in it that needed fixing so efl can build, then I guess suse can live with not upgrading efl if we're that low priority. If it's important to suse to upgrade efl then it will be important to upgrade meson too. :) i don't see this as being an issue when the next version comes out. :) What bugs are these? and were they fixed between 0.46.0 and 0.47.0? I'm only asking to go back one version from 0.47.0 to 0.46.0 which is what were currently requiring for e. If there is a bug that causes 0.46.0 to fail to build efl then we can get efl building with the Meson 0.46.0 api, keep the minimum version at 0.47.0 and i'll get the fix backported into SUSE's version of meson then patch efl to accept the older meson. But I don't really want to be working with a old e / efl for the next 2 years possibly. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B ___ 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 Fri, 3 May 2019 09:54:58 +0930 Simon Lees said: > > > On 02/05/2019 21:17, Carsten Haitzler (The Rasterman) wrote: > > On Thu, 2 May 2019 08:41:36 +0930 Simon Lees said: > > > >> I have ways of creating 3rd party repo's easily, but currently you can > >> install enlightenment from the openSUSE installer, and I'd like to keep > >> that at the latest version for each new version of leap, so i'd like e23 > >> or later in Leap 15.2 (about a year away), which will probably need a > >> reasonably new efl, but will likely only have meson 0.46.0 which is fine > >> for e but atm not for efl. > >> > >> There are alot of people using e from the installer, I keep bumping into > >> them at conferences etc, GNU Health have been using openSUSE + > >> enlightenment on all there raspberry pi's etc, so there is a significant > >> number of people using e in this way, and i'd like them to stay > >> reasonably up to date. > > > > at worst other rpm's can be provided for such upgrades - it's a temporary > > situation until the next suse release anyway which should have upgraded > > by then... :) > > > > Except it quite possibly will not, its not guarenteed until Leap 16 > which isn't really even been thought about much yet. and then we wait until leap 16 then... until then non-distro supplied rpms can be offered for those willing to upgrade. those not willing to do this don't upgrade. a new meson version is a requirement for efl as meson has had bugs and issues. maintaining 2 build systems for longer than needed is unwise and if anything will result in future lower quality of efl releases. we should only keep autofoo around for as long as necessary (the meson build has not caught up - e.g. windows). if gnome said you needed a newer meson and suse wanted that upgrade, suse would upgrade meson or forego the gnome upgrade. the same applies to us. eventually suse will - probably not because of us but because gnome will push it since we don't matter enough. :( -- - 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/enlightenment-devel
Re: [E-devel] EFL Autotools freeze proposal
On Fri, 3 May 2019 09:54:58 +0930 Simon Lees said: > > > On 02/05/2019 21:17, Carsten Haitzler (The Rasterman) wrote: > > On Thu, 2 May 2019 08:41:36 +0930 Simon Lees said: > > > >> I have ways of creating 3rd party repo's easily, but currently you can > >> install enlightenment from the openSUSE installer, and I'd like to keep > >> that at the latest version for each new version of leap, so i'd like e23 > >> or later in Leap 15.2 (about a year away), which will probably need a > >> reasonably new efl, but will likely only have meson 0.46.0 which is fine > >> for e but atm not for efl. > >> > >> There are alot of people using e from the installer, I keep bumping into > >> them at conferences etc, GNU Health have been using openSUSE + > >> enlightenment on all there raspberry pi's etc, so there is a significant > >> number of people using e in this way, and i'd like them to stay > >> reasonably up to date. > > > > at worst other rpm's can be provided for such upgrades - it's a temporary > > situation until the next suse release anyway which should have upgraded > > by then... :) > > > > Except it quite possibly will not, its not guarenteed until Leap 16 > which isn't really even been thought about much yet. Leave 16 will fix it. Other projects probably will push a newer meson version too, not just us. If susue doesn't want to upgrade meson because it's a requirement to do so due to bugs in it that needed fixing so efl can build, then I guess suse can live with not upgrading efl if we're that low priority. If it's important to suse to upgrade efl then it will be important to upgrade meson too. :) i don't see this as being an issue when the next version comes out. :) -- - 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/enlightenment-devel
Re: [E-devel] EFL Autotools freeze proposal
On 03/05/2019 01:11, Stefan Schmidt wrote: Hello. On 02.05.19 01:11, Simon Lees wrote: I have ways of creating 3rd party repo's easily, but currently you can install enlightenment from the openSUSE installer, and I'd like to keep that at the latest version for each new version of leap, so i'd like e23 or later in Leap 15.2 (about a year away), which will probably need a reasonably new efl, but will likely only have meson 0.46.0 which is fine for e but atm not for efl. Wait, you are saying Leap 15.2 will still only ship with meson 0.46? One year in the future? Tumbleweed already has 0.49.2 and Leap 15.2 would not pick that up? Yep, thats correct, Leap won't be fully synced with tumbleweed again until Leap 16. The core system (both components and build tools) so systemd, dbus, meson, cmake, gcc etc all come directly from SUSE Linux Enterprise 15. So Leap 15.1 will use SLE 15-sp1 as its base, Leap 15.2 will use SLE 15-sp2 etc, this has a lot of benefits such as myself as the dbus maintainer can fix a bug in SLE and that same fix will automatically go into Leap. SUSE generally wont update any of these packages for service packs without a really good reason, because it causes significant extra work, if meson gets updated any packages using meson that get a bugfix / security update need to be re tested to check that the change in the buildsystem didn't cause regressions. What is with Leap 15.1? I was not able to find any package version for meson or EFL for it at all. Leap 15.1 is not released yet, thats due for the end of the month, it will still ship Meson 0.46.0, as for efl, i'm slightly torn there hasn't been a new e update, and efl 1.20.7 in Leap 15.0 has been really stable with no one reporting any bugs (i'm using it on my secondary system). So in some ways I can't see a compelling reason to update. Having said that i'm going to test 1.22.2 over the weekend and if it looks really good i'll probably try and push it in at the last minute. But my plan for Leap 15.2 will be to have e23 with latest efl again, the e22 maintenance branch is too far gone to be easy to maintain but once e23 is out i'll start putting out semi regular point releases as needed again, and the goal would be to send those point releases into Leap 15.2 as maintenance updates, for now if someone finds a bug (again there doesn't seem to be many atm) i'll probably just backport the fix. Cheers -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B ___ 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 02/05/2019 21:17, Carsten Haitzler (The Rasterman) wrote: On Thu, 2 May 2019 08:41:36 +0930 Simon Lees said: I have ways of creating 3rd party repo's easily, but currently you can install enlightenment from the openSUSE installer, and I'd like to keep that at the latest version for each new version of leap, so i'd like e23 or later in Leap 15.2 (about a year away), which will probably need a reasonably new efl, but will likely only have meson 0.46.0 which is fine for e but atm not for efl. There are alot of people using e from the installer, I keep bumping into them at conferences etc, GNU Health have been using openSUSE + enlightenment on all there raspberry pi's etc, so there is a significant number of people using e in this way, and i'd like them to stay reasonably up to date. at worst other rpm's can be provided for such upgrades - it's a temporary situation until the next suse release anyway which should have upgraded by then... :) Except it quite possibly will not, its not guarenteed until Leap 16 which isn't really even been thought about much yet. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL Autotools freeze proposal
Hello. On 02.05.19 01:11, Simon Lees wrote: > I have ways of creating 3rd party repo's easily, but currently you can > install enlightenment from the openSUSE installer, and I'd like to keep > that at the latest version for each new version of leap, so i'd like e23 > or later in Leap 15.2 (about a year away), which will probably need a > reasonably new efl, but will likely only have meson 0.46.0 which is fine > for e but atm not for efl. Wait, you are saying Leap 15.2 will still only ship with meson 0.46? One year in the future? Tumbleweed already has 0.49.2 and Leap 15.2 would not pick that up? What is with Leap 15.1? I was not able to find any package version for meson or EFL for it at all. 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, 2 May 2019 08:41:36 +0930 Simon Lees said: > I have ways of creating 3rd party repo's easily, but currently you can > install enlightenment from the openSUSE installer, and I'd like to keep > that at the latest version for each new version of leap, so i'd like e23 > or later in Leap 15.2 (about a year away), which will probably need a > reasonably new efl, but will likely only have meson 0.46.0 which is fine > for e but atm not for efl. > > There are alot of people using e from the installer, I keep bumping into > them at conferences etc, GNU Health have been using openSUSE + > enlightenment on all there raspberry pi's etc, so there is a significant > number of people using e in this way, and i'd like them to stay > reasonably up to date. at worst other rpm's can be provided for such upgrades - it's a temporary situation until the next suse release anyway which should have upgraded by then... :) > On 01/05/2019 16:12, Jonathan Aquilina wrote: > > Hi Simon, > > > > Open suse is an rpm based distro correct? > > > > If yes why not creat a copr repo that will contain the newer stuff? > > > > Get Outlook for iOS<https://aka.ms/o0ukef> > > > > > > From: Simon Lees > > Sent: Wednesday, May 1, 2019 02:13 > > To: Carsten Haitzler (The Rasterman); Enlightenment developer list > > Subject: Re: [E-devel] EFL Autotools freeze proposal > > > > > > > > On 30/04/2019 21:39, Carsten Haitzler (The Rasterman) wrote: > >> On Tue, 30 Apr 2019 18:30:20 +0930 Simon Lees said: > >> > >>> > >>> > >>> On 30/04/2019 17:40, Carsten Haitzler (The Rasterman) wrote: > >>>> On Mon, 29 Apr 2019 15:20:19 -0700 Ross Vandegrift > >>>> said: > >>>> > >>>>> On Mon, Apr 29, 2019 at 05:30:33AM +, Jonathan Aquilina wrote: > >>>>>> I think everyone is missing the point. What you are saying is true but > >>>>>> that is why then they say if you want newer stuff to use a PPA for it > >>>>>> even though its not in the main repo's > >>>>> > >>>>> Yes, anyone can make a PPA. But you're talking to the maintainers of > >>>>> distro packaging - we try to put packages into distros for real :) > >>>> > >>>> and i think this was covered - a stable distro release that will not > >>>> upgrade meson out of principle (that's the definition of stable) isn't > >>>> going to upgrade efl either for the same reasons... so i think the topic > >>>> is kind of moot. if someone wants to make pkgs for such distros they can > >>>> create upgraded meson packages too etc. if they want to go the "all done > >>>> by pkgs" path :) > >>>> > >>> > >>> This is kind of right, in an openSUSE context for a new service pack we > >>> probably won't update Meson because it effects alot but we can update > >>> efl / e because it doesn't affect as much, we could also add it if it > >>> didn't exist. Further if a new version of efl fixed a serious bug that > >>> was hard to backport we would also take the version update. > >> > >> tho meson doesn't affect THAT much... it's a build tool not a "runtime > >> tool". it isn't int he realms of libc, Xserver, bash etc. > >> > > > > Yeah there's a lot of stuff thats using meson to build now, and a meson > > update effects any updates we do for anything thats built with it due to > > needing full QA cycles to verify that the package was built correctly > > which is why enterprise distro's prefer not to update build tools mid cycle. > > > > > >>> In ubuntu's case from memory the service packs tend to only be a new > >>> installer containing all the updates so its probably less likely, but I > >>> don't remember how ubuntu works 100% so I could be wrong. > >> > >> in our case if a new efl needs a new meson, then... that's what it needs > >> and an efl upgrade is not likely to happen then from the core distro. > >> ppa's and equivalents can manage to fill that gap. this problem will go > >> away over time as meson matures etc. etc. so this is a short-term problem > >> as such. :) > >> > > > > Yep but in openSUSE's case that may mean keeping e22 through all the > > leap 15.X releases which I really don't want to do because I cant > > support it, so welcome back to the world of having bugs repor
Re: [E-devel] EFL Autotools freeze proposal
On Thu, 2 May 2019 08:52:01 + Jonathan Aquilina said: > For EFL cant we do like other projects do such as libreoffice set a minimum > base line version or newer for meason? that's EXACTLY what we do - and its too new for suse in this case as simon describes. this will get fixed eventually with newer suse's though so i'm a bit less worried about this and see it as a hiccup rather than a big issue. :) > Regards, > Jonathan > > Regards, > Jonathan Aquilina > Owner EagleEyeT > > > From: Simon Lees > Sent: Thursday, May 2, 2019 10:46 AM > To: enlightenment-devel@lists.sourceforge.net > Subject: Re: [E-devel] EFL Autotools freeze proposal > > Generally stable releases will get version updates for point releases, > and if there are any other major bugs that are fixed after i'll normally > backport them, if thats too hard I may consider a major version update. > > We tend to encourage people who want the latest everything to use the > rolling release instead, or wait for the next leap point release which > will be within a year. There are repo's that get used for development > where people could get a newer version but we generally don't encourage > it, and they would still require a new enough meson to be in the core > system in order to build. Because enabling a newer version of E > shouldn't force you onto a non system build of Meson thats not being as > well maintained. > > For the crazy adventurous there are repo's that even have git builds, > but generally normal openSUSE users shouldn't need to add any additional > repos to there system bar 1 or 2 where legal issues get in the way, > unlike ubuntu where not everything makes it into the core distro in > openSUSE we encourage everything possible to be in the main distro at an > appropriate version depending on whether users are expecting a "stable > system that changes less" or a "rolling release". So the problem we hit > and are discussing is that the appropriate version of meson in the next > point release of openSUSE is too old to build the ideal version of efl, > which will likely end up blocking a new version of e (which does work > with that version of meson). Extra repo's are not a solution for 99% of > users who will just use the version that ships in the distro, which in > fairness may not be that big an issue because it is rather stable and > works really well on X11, but there is the potential that they will > still be using that version in 2-3 years unless we lower the version of > meson required by efl slightly. > > On 02/05/2019 14:08, Jonathan Aquilina wrote: > > Hi Simon, > > > > What happens in terms of OpenSuse in the sense of giving those on stable > > versions of Suse the latest versions of e? Won’t a 3rd party repo still be > > needed until the next release is released with a newer version of e? > > > > Regards, > > Jonathan > > > > Regards, > > Jonathan Aquilina > > Owner EagleEyeT > > > > > > From: Simon Lees > > Sent: Thursday, May 2, 2019 1:12 AM > > To: enlightenment-devel@lists.sourceforge.net > > Subject: Re: [E-devel] EFL Autotools freeze proposal > > > > I have ways of creating 3rd party repo's easily, but currently you can > > install enlightenment from the openSUSE installer, and I'd like to keep > > that at the latest version for each new version of leap, so i'd like e23 > > or later in Leap 15.2 (about a year away), which will probably need a > > reasonably new efl, but will likely only have meson 0.46.0 which is fine > > for e but atm not for efl. > > > > There are alot of people using e from the installer, I keep bumping into > > them at conferences etc, GNU Health have been using openSUSE + > > enlightenment on all there raspberry pi's etc, so there is a significant > > number of people using e in this way, and i'd like them to stay > > reasonably up to date. > > > > On 01/05/2019 16:12, Jonathan Aquilina wrote: > >> Hi Simon, > >> > >> Open suse is an rpm based distro correct? > >> > >> If yes why not creat a copr repo that will contain the newer stuff? > >> > >> Get Outlook for iOS<https://aka.ms/o0ukef> > >> > >> > >> From: Simon Lees > >> Sent: Wednesday, May 1, 2019 02:13 > >> To: Carsten Haitzler (The Rasterman); Enlightenment developer list > >> Subject: Re: [E-devel] EFL Autotools freeze proposal > >> > >> > >> > >> On 30/04/2019 21:39, Carsten Haitzler (The Rasterman) wrote:
Re: [E-devel] EFL Autotools freeze proposal
Well, yes thats what this discussion is about, efl, isn't big enough though to force distro's to update to a newer version (gnome probably is) so the baseline needs to be low enough that the distro's we care about already ship it, which will probably end up being 0.46.0 I guess, which is lower then what efl has now but is what e's set to. On 02/05/2019 18:22, Jonathan Aquilina wrote: For EFL cant we do like other projects do such as libreoffice set a minimum base line version or newer for meason? Regards, Jonathan Regards, Jonathan Aquilina Owner EagleEyeT From: Simon Lees Sent: Thursday, May 2, 2019 10:46 AM To: enlightenment-devel@lists.sourceforge.net Subject: Re: [E-devel] EFL Autotools freeze proposal Generally stable releases will get version updates for point releases, and if there are any other major bugs that are fixed after i'll normally backport them, if thats too hard I may consider a major version update. We tend to encourage people who want the latest everything to use the rolling release instead, or wait for the next leap point release which will be within a year. There are repo's that get used for development where people could get a newer version but we generally don't encourage it, and they would still require a new enough meson to be in the core system in order to build. Because enabling a newer version of E shouldn't force you onto a non system build of Meson thats not being as well maintained. For the crazy adventurous there are repo's that even have git builds, but generally normal openSUSE users shouldn't need to add any additional repos to there system bar 1 or 2 where legal issues get in the way, unlike ubuntu where not everything makes it into the core distro in openSUSE we encourage everything possible to be in the main distro at an appropriate version depending on whether users are expecting a "stable system that changes less" or a "rolling release". So the problem we hit and are discussing is that the appropriate version of meson in the next point release of openSUSE is too old to build the ideal version of efl, which will likely end up blocking a new version of e (which does work with that version of meson). Extra repo's are not a solution for 99% of users who will just use the version that ships in the distro, which in fairness may not be that big an issue because it is rather stable and works really well on X11, but there is the potential that they will still be using that version in 2-3 years unless we lower the version of meson required by efl slightly. On 02/05/2019 14:08, Jonathan Aquilina wrote: Hi Simon, What happens in terms of OpenSuse in the sense of giving those on stable versions of Suse the latest versions of e? Won’t a 3rd party repo still be needed until the next release is released with a newer version of e? Regards, Jonathan Regards, Jonathan Aquilina Owner EagleEyeT From: Simon Lees Sent: Thursday, May 2, 2019 1:12 AM To: enlightenment-devel@lists.sourceforge.net Subject: Re: [E-devel] EFL Autotools freeze proposal I have ways of creating 3rd party repo's easily, but currently you can install enlightenment from the openSUSE installer, and I'd like to keep that at the latest version for each new version of leap, so i'd like e23 or later in Leap 15.2 (about a year away), which will probably need a reasonably new efl, but will likely only have meson 0.46.0 which is fine for e but atm not for efl. There are alot of people using e from the installer, I keep bumping into them at conferences etc, GNU Health have been using openSUSE + enlightenment on all there raspberry pi's etc, so there is a significant number of people using e in this way, and i'd like them to stay reasonably up to date. On 01/05/2019 16:12, Jonathan Aquilina wrote: Hi Simon, Open suse is an rpm based distro correct? If yes why not creat a copr repo that will contain the newer stuff? Get Outlook for iOS<https://aka.ms/o0ukef> From: Simon Lees Sent: Wednesday, May 1, 2019 02:13 To: Carsten Haitzler (The Rasterman); Enlightenment developer list Subject: Re: [E-devel] EFL Autotools freeze proposal On 30/04/2019 21:39, Carsten Haitzler (The Rasterman) wrote: On Tue, 30 Apr 2019 18:30:20 +0930 Simon Lees said: On 30/04/2019 17:40, Carsten Haitzler (The Rasterman) wrote: On Mon, 29 Apr 2019 15:20:19 -0700 Ross Vandegrift said: On Mon, Apr 29, 2019 at 05:30:33AM +, Jonathan Aquilina wrote: I think everyone is missing the point. What you are saying is true but that is why then they say if you want newer stuff to use a PPA for it even though its not in the main repo's Yes, anyone can make a PPA. But you're talking to the maintainers of distro packaging - we try to put packages into distros for real :) and i think this was covered - a stable distro release that will not upgrade meson out of principle (that's the definit
Re: [E-devel] EFL Autotools freeze proposal
For EFL cant we do like other projects do such as libreoffice set a minimum base line version or newer for meason? Regards, Jonathan Regards, Jonathan Aquilina Owner EagleEyeT From: Simon Lees Sent: Thursday, May 2, 2019 10:46 AM To: enlightenment-devel@lists.sourceforge.net Subject: Re: [E-devel] EFL Autotools freeze proposal Generally stable releases will get version updates for point releases, and if there are any other major bugs that are fixed after i'll normally backport them, if thats too hard I may consider a major version update. We tend to encourage people who want the latest everything to use the rolling release instead, or wait for the next leap point release which will be within a year. There are repo's that get used for development where people could get a newer version but we generally don't encourage it, and they would still require a new enough meson to be in the core system in order to build. Because enabling a newer version of E shouldn't force you onto a non system build of Meson thats not being as well maintained. For the crazy adventurous there are repo's that even have git builds, but generally normal openSUSE users shouldn't need to add any additional repos to there system bar 1 or 2 where legal issues get in the way, unlike ubuntu where not everything makes it into the core distro in openSUSE we encourage everything possible to be in the main distro at an appropriate version depending on whether users are expecting a "stable system that changes less" or a "rolling release". So the problem we hit and are discussing is that the appropriate version of meson in the next point release of openSUSE is too old to build the ideal version of efl, which will likely end up blocking a new version of e (which does work with that version of meson). Extra repo's are not a solution for 99% of users who will just use the version that ships in the distro, which in fairness may not be that big an issue because it is rather stable and works really well on X11, but there is the potential that they will still be using that version in 2-3 years unless we lower the version of meson required by efl slightly. On 02/05/2019 14:08, Jonathan Aquilina wrote: > Hi Simon, > > What happens in terms of OpenSuse in the sense of giving those on stable > versions of Suse the latest versions of e? Won’t a 3rd party repo still be > needed until the next release is released with a newer version of e? > > Regards, > Jonathan > > Regards, > Jonathan Aquilina > Owner EagleEyeT > > > From: Simon Lees > Sent: Thursday, May 2, 2019 1:12 AM > To: enlightenment-devel@lists.sourceforge.net > Subject: Re: [E-devel] EFL Autotools freeze proposal > > I have ways of creating 3rd party repo's easily, but currently you can > install enlightenment from the openSUSE installer, and I'd like to keep > that at the latest version for each new version of leap, so i'd like e23 > or later in Leap 15.2 (about a year away), which will probably need a > reasonably new efl, but will likely only have meson 0.46.0 which is fine > for e but atm not for efl. > > There are alot of people using e from the installer, I keep bumping into > them at conferences etc, GNU Health have been using openSUSE + > enlightenment on all there raspberry pi's etc, so there is a significant > number of people using e in this way, and i'd like them to stay > reasonably up to date. > > On 01/05/2019 16:12, Jonathan Aquilina wrote: >> Hi Simon, >> >> Open suse is an rpm based distro correct? >> >> If yes why not creat a copr repo that will contain the newer stuff? >> >> Get Outlook for iOS<https://aka.ms/o0ukef> >> >> ________________ >> From: Simon Lees >> Sent: Wednesday, May 1, 2019 02:13 >> To: Carsten Haitzler (The Rasterman); Enlightenment developer list >> Subject: Re: [E-devel] EFL Autotools freeze proposal >> >> >> >> On 30/04/2019 21:39, Carsten Haitzler (The Rasterman) wrote: >>> On Tue, 30 Apr 2019 18:30:20 +0930 Simon Lees said: >>> >>>> >>>> >>>> On 30/04/2019 17:40, Carsten Haitzler (The Rasterman) wrote: >>>>> On Mon, 29 Apr 2019 15:20:19 -0700 Ross Vandegrift >>>>> said: >>>>> >>>>>> On Mon, Apr 29, 2019 at 05:30:33AM +, Jonathan Aquilina wrote: >>>>>>> I think everyone is missing the point. What you are saying is true but >>>>>>> that is why then they say if you want newer stuff to use a PPA for it >>>>>>> even though its not in the main repo's >>>>>> >>>>>> Yes, anyone can make a PPA. But you're talking to the maintaine
Re: [E-devel] EFL Autotools freeze proposal
Generally stable releases will get version updates for point releases, and if there are any other major bugs that are fixed after i'll normally backport them, if thats too hard I may consider a major version update. We tend to encourage people who want the latest everything to use the rolling release instead, or wait for the next leap point release which will be within a year. There are repo's that get used for development where people could get a newer version but we generally don't encourage it, and they would still require a new enough meson to be in the core system in order to build. Because enabling a newer version of E shouldn't force you onto a non system build of Meson thats not being as well maintained. For the crazy adventurous there are repo's that even have git builds, but generally normal openSUSE users shouldn't need to add any additional repos to there system bar 1 or 2 where legal issues get in the way, unlike ubuntu where not everything makes it into the core distro in openSUSE we encourage everything possible to be in the main distro at an appropriate version depending on whether users are expecting a "stable system that changes less" or a "rolling release". So the problem we hit and are discussing is that the appropriate version of meson in the next point release of openSUSE is too old to build the ideal version of efl, which will likely end up blocking a new version of e (which does work with that version of meson). Extra repo's are not a solution for 99% of users who will just use the version that ships in the distro, which in fairness may not be that big an issue because it is rather stable and works really well on X11, but there is the potential that they will still be using that version in 2-3 years unless we lower the version of meson required by efl slightly. On 02/05/2019 14:08, Jonathan Aquilina wrote: Hi Simon, What happens in terms of OpenSuse in the sense of giving those on stable versions of Suse the latest versions of e? Won’t a 3rd party repo still be needed until the next release is released with a newer version of e? Regards, Jonathan Regards, Jonathan Aquilina Owner EagleEyeT From: Simon Lees Sent: Thursday, May 2, 2019 1:12 AM To: enlightenment-devel@lists.sourceforge.net Subject: Re: [E-devel] EFL Autotools freeze proposal I have ways of creating 3rd party repo's easily, but currently you can install enlightenment from the openSUSE installer, and I'd like to keep that at the latest version for each new version of leap, so i'd like e23 or later in Leap 15.2 (about a year away), which will probably need a reasonably new efl, but will likely only have meson 0.46.0 which is fine for e but atm not for efl. There are alot of people using e from the installer, I keep bumping into them at conferences etc, GNU Health have been using openSUSE + enlightenment on all there raspberry pi's etc, so there is a significant number of people using e in this way, and i'd like them to stay reasonably up to date. On 01/05/2019 16:12, Jonathan Aquilina wrote: Hi Simon, Open suse is an rpm based distro correct? If yes why not creat a copr repo that will contain the newer stuff? Get Outlook for iOS<https://aka.ms/o0ukef> From: Simon Lees Sent: Wednesday, May 1, 2019 02:13 To: Carsten Haitzler (The Rasterman); Enlightenment developer list Subject: Re: [E-devel] EFL Autotools freeze proposal On 30/04/2019 21:39, Carsten Haitzler (The Rasterman) wrote: On Tue, 30 Apr 2019 18:30:20 +0930 Simon Lees said: On 30/04/2019 17:40, Carsten Haitzler (The Rasterman) wrote: On Mon, 29 Apr 2019 15:20:19 -0700 Ross Vandegrift said: On Mon, Apr 29, 2019 at 05:30:33AM +, Jonathan Aquilina wrote: I think everyone is missing the point. What you are saying is true but that is why then they say if you want newer stuff to use a PPA for it even though its not in the main repo's Yes, anyone can make a PPA. But you're talking to the maintainers of distro packaging - we try to put packages into distros for real :) and i think this was covered - a stable distro release that will not upgrade meson out of principle (that's the definition of stable) isn't going to upgrade efl either for the same reasons... so i think the topic is kind of moot. if someone wants to make pkgs for such distros they can create upgraded meson packages too etc. if they want to go the "all done by pkgs" path :) This is kind of right, in an openSUSE context for a new service pack we probably won't update Meson because it effects alot but we can update efl / e because it doesn't affect as much, we could also add it if it didn't exist. Further if a new version of efl fixed a serious bug that was hard to backport we would also take the version update. tho meson doesn't affect THAT much... it's a build tool not a "runtime tool". it isn't int he realms of libc, Xse
Re: [E-devel] EFL Autotools freeze proposal
Hi Simon, What happens in terms of OpenSuse in the sense of giving those on stable versions of Suse the latest versions of e? Won’t a 3rd party repo still be needed until the next release is released with a newer version of e? Regards, Jonathan Regards, Jonathan Aquilina Owner EagleEyeT From: Simon Lees Sent: Thursday, May 2, 2019 1:12 AM To: enlightenment-devel@lists.sourceforge.net Subject: Re: [E-devel] EFL Autotools freeze proposal I have ways of creating 3rd party repo's easily, but currently you can install enlightenment from the openSUSE installer, and I'd like to keep that at the latest version for each new version of leap, so i'd like e23 or later in Leap 15.2 (about a year away), which will probably need a reasonably new efl, but will likely only have meson 0.46.0 which is fine for e but atm not for efl. There are alot of people using e from the installer, I keep bumping into them at conferences etc, GNU Health have been using openSUSE + enlightenment on all there raspberry pi's etc, so there is a significant number of people using e in this way, and i'd like them to stay reasonably up to date. On 01/05/2019 16:12, Jonathan Aquilina wrote: > Hi Simon, > > Open suse is an rpm based distro correct? > > If yes why not creat a copr repo that will contain the newer stuff? > > Get Outlook for iOS<https://aka.ms/o0ukef> > > > From: Simon Lees > Sent: Wednesday, May 1, 2019 02:13 > To: Carsten Haitzler (The Rasterman); Enlightenment developer list > Subject: Re: [E-devel] EFL Autotools freeze proposal > > > > On 30/04/2019 21:39, Carsten Haitzler (The Rasterman) wrote: >> On Tue, 30 Apr 2019 18:30:20 +0930 Simon Lees said: >> >>> >>> >>> On 30/04/2019 17:40, Carsten Haitzler (The Rasterman) wrote: >>>> On Mon, 29 Apr 2019 15:20:19 -0700 Ross Vandegrift said: >>>> >>>>> On Mon, Apr 29, 2019 at 05:30:33AM +, Jonathan Aquilina wrote: >>>>>> I think everyone is missing the point. What you are saying is true but >>>>>> that is why then they say if you want newer stuff to use a PPA for it >>>>>> even though its not in the main repo's >>>>> >>>>> Yes, anyone can make a PPA. But you're talking to the maintainers of >>>>> distro packaging - we try to put packages into distros for real :) >>>> >>>> and i think this was covered - a stable distro release that will not >>>> upgrade >>>> meson out of principle (that's the definition of stable) isn't going to >>>> upgrade efl either for the same reasons... so i think the topic is kind of >>>> moot. if someone wants to make pkgs for such distros they can create >>>> upgraded meson packages too etc. if they want to go the "all done by pkgs" >>>> path :) >>>> >>> >>> This is kind of right, in an openSUSE context for a new service pack we >>> probably won't update Meson because it effects alot but we can update >>> efl / e because it doesn't affect as much, we could also add it if it >>> didn't exist. Further if a new version of efl fixed a serious bug that >>> was hard to backport we would also take the version update. >> >> tho meson doesn't affect THAT much... it's a build tool not a "runtime >> tool". it >> isn't int he realms of libc, Xserver, bash etc. >> > > Yeah there's a lot of stuff thats using meson to build now, and a meson > update effects any updates we do for anything thats built with it due to > needing full QA cycles to verify that the package was built correctly > which is why enterprise distro's prefer not to update build tools mid cycle. > > >>> In ubuntu's case from memory the service packs tend to only be a new >>> installer containing all the updates so its probably less likely, but I >>> don't remember how ubuntu works 100% so I could be wrong. >> >> in our case if a new efl needs a new meson, then... that's what it needs and >> an >> efl upgrade is not likely to happen then from the core distro. ppa's and >> equivalents can manage to fill that gap. this problem will go away over time >> as >> meson matures etc. etc. so this is a short-term problem as such. :) >> > > Yep but in openSUSE's case that may mean keeping e22 through all the > leap 15.X releases which I really don't want to do because I cant > support it, so welcome back to the world of having bugs reported that > are already fixed. > > -- > > Simon Lees (Simotek) http://simotek.net > > Emergency Update Team keybase.io/simotek >
Re: [E-devel] EFL Autotools freeze proposal
I have ways of creating 3rd party repo's easily, but currently you can install enlightenment from the openSUSE installer, and I'd like to keep that at the latest version for each new version of leap, so i'd like e23 or later in Leap 15.2 (about a year away), which will probably need a reasonably new efl, but will likely only have meson 0.46.0 which is fine for e but atm not for efl. There are alot of people using e from the installer, I keep bumping into them at conferences etc, GNU Health have been using openSUSE + enlightenment on all there raspberry pi's etc, so there is a significant number of people using e in this way, and i'd like them to stay reasonably up to date. On 01/05/2019 16:12, Jonathan Aquilina wrote: Hi Simon, Open suse is an rpm based distro correct? If yes why not creat a copr repo that will contain the newer stuff? Get Outlook for iOS<https://aka.ms/o0ukef> From: Simon Lees Sent: Wednesday, May 1, 2019 02:13 To: Carsten Haitzler (The Rasterman); Enlightenment developer list Subject: Re: [E-devel] EFL Autotools freeze proposal On 30/04/2019 21:39, Carsten Haitzler (The Rasterman) wrote: On Tue, 30 Apr 2019 18:30:20 +0930 Simon Lees said: On 30/04/2019 17:40, Carsten Haitzler (The Rasterman) wrote: On Mon, 29 Apr 2019 15:20:19 -0700 Ross Vandegrift said: On Mon, Apr 29, 2019 at 05:30:33AM +, Jonathan Aquilina wrote: I think everyone is missing the point. What you are saying is true but that is why then they say if you want newer stuff to use a PPA for it even though its not in the main repo's Yes, anyone can make a PPA. But you're talking to the maintainers of distro packaging - we try to put packages into distros for real :) and i think this was covered - a stable distro release that will not upgrade meson out of principle (that's the definition of stable) isn't going to upgrade efl either for the same reasons... so i think the topic is kind of moot. if someone wants to make pkgs for such distros they can create upgraded meson packages too etc. if they want to go the "all done by pkgs" path :) This is kind of right, in an openSUSE context for a new service pack we probably won't update Meson because it effects alot but we can update efl / e because it doesn't affect as much, we could also add it if it didn't exist. Further if a new version of efl fixed a serious bug that was hard to backport we would also take the version update. tho meson doesn't affect THAT much... it's a build tool not a "runtime tool". it isn't int he realms of libc, Xserver, bash etc. Yeah there's a lot of stuff thats using meson to build now, and a meson update effects any updates we do for anything thats built with it due to needing full QA cycles to verify that the package was built correctly which is why enterprise distro's prefer not to update build tools mid cycle. In ubuntu's case from memory the service packs tend to only be a new installer containing all the updates so its probably less likely, but I don't remember how ubuntu works 100% so I could be wrong. in our case if a new efl needs a new meson, then... that's what it needs and an efl upgrade is not likely to happen then from the core distro. ppa's and equivalents can manage to fill that gap. this problem will go away over time as meson matures etc. etc. so this is a short-term problem as such. :) Yep but in openSUSE's case that may mean keeping e22 through all the leap 15.X releases which I really don't want to do because I cant support it, so welcome back to the world of having bugs reported that are already fixed. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B ___ 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 -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B ___ 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 Simon, Open suse is an rpm based distro correct? If yes why not creat a copr repo that will contain the newer stuff? Get Outlook for iOS<https://aka.ms/o0ukef> From: Simon Lees Sent: Wednesday, May 1, 2019 02:13 To: Carsten Haitzler (The Rasterman); Enlightenment developer list Subject: Re: [E-devel] EFL Autotools freeze proposal On 30/04/2019 21:39, Carsten Haitzler (The Rasterman) wrote: > On Tue, 30 Apr 2019 18:30:20 +0930 Simon Lees said: > >> >> >> On 30/04/2019 17:40, Carsten Haitzler (The Rasterman) wrote: >>> On Mon, 29 Apr 2019 15:20:19 -0700 Ross Vandegrift said: >>> >>>> On Mon, Apr 29, 2019 at 05:30:33AM +, Jonathan Aquilina wrote: >>>>> I think everyone is missing the point. What you are saying is true but >>>>> that is why then they say if you want newer stuff to use a PPA for it >>>>> even though its not in the main repo's >>>> >>>> Yes, anyone can make a PPA. But you're talking to the maintainers of >>>> distro packaging - we try to put packages into distros for real :) >>> >>> and i think this was covered - a stable distro release that will not upgrade >>> meson out of principle (that's the definition of stable) isn't going to >>> upgrade efl either for the same reasons... so i think the topic is kind of >>> moot. if someone wants to make pkgs for such distros they can create >>> upgraded meson packages too etc. if they want to go the "all done by pkgs" >>> path :) >>> >> >> This is kind of right, in an openSUSE context for a new service pack we >> probably won't update Meson because it effects alot but we can update >> efl / e because it doesn't affect as much, we could also add it if it >> didn't exist. Further if a new version of efl fixed a serious bug that >> was hard to backport we would also take the version update. > > tho meson doesn't affect THAT much... it's a build tool not a "runtime tool". > it > isn't int he realms of libc, Xserver, bash etc. > Yeah there's a lot of stuff thats using meson to build now, and a meson update effects any updates we do for anything thats built with it due to needing full QA cycles to verify that the package was built correctly which is why enterprise distro's prefer not to update build tools mid cycle. >> In ubuntu's case from memory the service packs tend to only be a new >> installer containing all the updates so its probably less likely, but I >> don't remember how ubuntu works 100% so I could be wrong. > > in our case if a new efl needs a new meson, then... that's what it needs and > an > efl upgrade is not likely to happen then from the core distro. ppa's and > equivalents can manage to fill that gap. this problem will go away over time > as > meson matures etc. etc. so this is a short-term problem as such. :) > Yep but in openSUSE's case that may mean keeping e22 through all the leap 15.X releases which I really don't want to do because I cant support it, so welcome back to the world of having bugs reported that are already fixed. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B ___ 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 30/04/2019 21:39, Carsten Haitzler (The Rasterman) wrote: On Tue, 30 Apr 2019 18:30:20 +0930 Simon Lees said: On 30/04/2019 17:40, Carsten Haitzler (The Rasterman) wrote: On Mon, 29 Apr 2019 15:20:19 -0700 Ross Vandegrift said: On Mon, Apr 29, 2019 at 05:30:33AM +, Jonathan Aquilina wrote: I think everyone is missing the point. What you are saying is true but that is why then they say if you want newer stuff to use a PPA for it even though its not in the main repo's Yes, anyone can make a PPA. But you're talking to the maintainers of distro packaging - we try to put packages into distros for real :) and i think this was covered - a stable distro release that will not upgrade meson out of principle (that's the definition of stable) isn't going to upgrade efl either for the same reasons... so i think the topic is kind of moot. if someone wants to make pkgs for such distros they can create upgraded meson packages too etc. if they want to go the "all done by pkgs" path :) This is kind of right, in an openSUSE context for a new service pack we probably won't update Meson because it effects alot but we can update efl / e because it doesn't affect as much, we could also add it if it didn't exist. Further if a new version of efl fixed a serious bug that was hard to backport we would also take the version update. tho meson doesn't affect THAT much... it's a build tool not a "runtime tool". it isn't int he realms of libc, Xserver, bash etc. Yeah there's a lot of stuff thats using meson to build now, and a meson update effects any updates we do for anything thats built with it due to needing full QA cycles to verify that the package was built correctly which is why enterprise distro's prefer not to update build tools mid cycle. In ubuntu's case from memory the service packs tend to only be a new installer containing all the updates so its probably less likely, but I don't remember how ubuntu works 100% so I could be wrong. in our case if a new efl needs a new meson, then... that's what it needs and an efl upgrade is not likely to happen then from the core distro. ppa's and equivalents can manage to fill that gap. this problem will go away over time as meson matures etc. etc. so this is a short-term problem as such. :) Yep but in openSUSE's case that may mean keeping e22 through all the leap 15.X releases which I really don't want to do because I cant support it, so welcome back to the world of having bugs reported that are already fixed. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL Autotools freeze proposal
The key with ubuntu to ensure if you need newer versions of meson is to ensure that Debian has the latest package and as long as Debian is kept up to date new ubuntu release will end up with them until package freeze that they have scheduled. Regards, Jonathan -Original Message- From: Carsten Haitzler Sent: 30 April 2019 14:09 To: Enlightenment developer list Subject: Re: [E-devel] EFL Autotools freeze proposal On Tue, 30 Apr 2019 18:30:20 +0930 Simon Lees said: > > > On 30/04/2019 17:40, Carsten Haitzler (The Rasterman) wrote: > > On Mon, 29 Apr 2019 15:20:19 -0700 Ross Vandegrift said: > > > >> On Mon, Apr 29, 2019 at 05:30:33AM +, Jonathan Aquilina wrote: > >>> I think everyone is missing the point. What you are saying is true > >>> but that is why then they say if you want newer stuff to use a PPA > >>> for it even though its not in the main repo's > >> > >> Yes, anyone can make a PPA. But you're talking to the maintainers > >> of distro packaging - we try to put packages into distros for real > >> :) > > > > and i think this was covered - a stable distro release that will not > > upgrade meson out of principle (that's the definition of stable) > > isn't going to upgrade efl either for the same reasons... so i think > > the topic is kind of moot. if someone wants to make pkgs for such > > distros they can create upgraded meson packages too etc. if they want to go > > the "all done by pkgs" > > path :) > > > > This is kind of right, in an openSUSE context for a new service pack > we probably won't update Meson because it effects alot but we can > update efl / e because it doesn't affect as much, we could also add it > if it didn't exist. Further if a new version of efl fixed a serious > bug that was hard to backport we would also take the version update. tho meson doesn't affect THAT much... it's a build tool not a "runtime tool". it isn't int he realms of libc, Xserver, bash etc. > In ubuntu's case from memory the service packs tend to only be a new > installer containing all the updates so its probably less likely, but > I don't remember how ubuntu works 100% so I could be wrong. in our case if a new efl needs a new meson, then... that's what it needs and an efl upgrade is not likely to happen then from the core distro. ppa's and equivalents can manage to fill that gap. this problem will go away over time as meson matures etc. etc. so this is a short-term problem as such. :) > -- > > Simon Lees (Simotek)http://simotek.net > > Emergency Update Team keybase.io/simotek > SUSE Linux Adelaide Australia, UTC+10:30 > GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B > > > ___ > 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/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 Tue, 30 Apr 2019 18:30:20 +0930 Simon Lees said: > > > On 30/04/2019 17:40, Carsten Haitzler (The Rasterman) wrote: > > On Mon, 29 Apr 2019 15:20:19 -0700 Ross Vandegrift said: > > > >> On Mon, Apr 29, 2019 at 05:30:33AM +, Jonathan Aquilina wrote: > >>> I think everyone is missing the point. What you are saying is true but > >>> that is why then they say if you want newer stuff to use a PPA for it > >>> even though its not in the main repo's > >> > >> Yes, anyone can make a PPA. But you're talking to the maintainers of > >> distro packaging - we try to put packages into distros for real :) > > > > and i think this was covered - a stable distro release that will not upgrade > > meson out of principle (that's the definition of stable) isn't going to > > upgrade efl either for the same reasons... so i think the topic is kind of > > moot. if someone wants to make pkgs for such distros they can create > > upgraded meson packages too etc. if they want to go the "all done by pkgs" > > path :) > > > > This is kind of right, in an openSUSE context for a new service pack we > probably won't update Meson because it effects alot but we can update > efl / e because it doesn't affect as much, we could also add it if it > didn't exist. Further if a new version of efl fixed a serious bug that > was hard to backport we would also take the version update. tho meson doesn't affect THAT much... it's a build tool not a "runtime tool". it isn't int he realms of libc, Xserver, bash etc. > In ubuntu's case from memory the service packs tend to only be a new > installer containing all the updates so its probably less likely, but I > don't remember how ubuntu works 100% so I could be wrong. in our case if a new efl needs a new meson, then... that's what it needs and an efl upgrade is not likely to happen then from the core distro. ppa's and equivalents can manage to fill that gap. this problem will go away over time as meson matures etc. etc. so this is a short-term problem as such. :) > -- > > Simon Lees (Simotek)http://simotek.net > > Emergency Update Team keybase.io/simotek > SUSE Linux Adelaide Australia, UTC+10:30 > GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B > > > ___ > 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/enlightenment-devel
Re: [E-devel] EFL Autotools freeze proposal
Hi Simon, What I have been mentioning was targeting Ubuntu distro’s and it is more or less along the same lines as you mentioned with OpenSuse Regards, Jonathan Aquilina Owner EagleEyeT From: Simon Lees Sent: Tuesday, April 30, 2019 11:00 AM To: enlightenment-devel@lists.sourceforge.net Subject: Re: [E-devel] EFL Autotools freeze proposal On 30/04/2019 17:40, Carsten Haitzler (The Rasterman) wrote: > On Mon, 29 Apr 2019 15:20:19 -0700 Ross Vandegrift said: > >> On Mon, Apr 29, 2019 at 05:30:33AM +, Jonathan Aquilina wrote: >>> I think everyone is missing the point. What you are saying is true but >>> that is why then they say if you want newer stuff to use a PPA for it >>> even though its not in the main repo's >> >> Yes, anyone can make a PPA. But you're talking to the maintainers of >> distro packaging - we try to put packages into distros for real :) > > and i think this was covered - a stable distro release that will not upgrade > meson out of principle (that's the definition of stable) isn't going to > upgrade > efl either for the same reasons... so i think the topic is kind of moot. if > someone wants to make pkgs for such distros they can create upgraded meson > packages too etc. if they want to go the "all done by pkgs" path :) > This is kind of right, in an openSUSE context for a new service pack we probably won't update Meson because it effects alot but we can update efl / e because it doesn't affect as much, we could also add it if it didn't exist. Further if a new version of efl fixed a serious bug that was hard to backport we would also take the version update. In ubuntu's case from memory the service packs tend to only be a new installer containing all the updates so its probably less likely, but I don't remember how ubuntu works 100% so I could be wrong. -- Simon Lees (Simotek) http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B ___ 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 30/04/2019 17:40, Carsten Haitzler (The Rasterman) wrote: On Mon, 29 Apr 2019 15:20:19 -0700 Ross Vandegrift said: On Mon, Apr 29, 2019 at 05:30:33AM +, Jonathan Aquilina wrote: I think everyone is missing the point. What you are saying is true but that is why then they say if you want newer stuff to use a PPA for it even though its not in the main repo's Yes, anyone can make a PPA. But you're talking to the maintainers of distro packaging - we try to put packages into distros for real :) and i think this was covered - a stable distro release that will not upgrade meson out of principle (that's the definition of stable) isn't going to upgrade efl either for the same reasons... so i think the topic is kind of moot. if someone wants to make pkgs for such distros they can create upgraded meson packages too etc. if they want to go the "all done by pkgs" path :) This is kind of right, in an openSUSE context for a new service pack we probably won't update Meson because it effects alot but we can update efl / e because it doesn't affect as much, we could also add it if it didn't exist. Further if a new version of efl fixed a serious bug that was hard to backport we would also take the version update. In ubuntu's case from memory the service packs tend to only be a new installer containing all the updates so its probably less likely, but I don't remember how ubuntu works 100% so I could be wrong. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B ___ 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 Mon, 29 Apr 2019 15:20:19 -0700 Ross Vandegrift said: > On Mon, Apr 29, 2019 at 05:30:33AM +, Jonathan Aquilina wrote: > > I think everyone is missing the point. What you are saying is true but > > that is why then they say if you want newer stuff to use a PPA for it > > even though its not in the main repo's > > Yes, anyone can make a PPA. But you're talking to the maintainers of > distro packaging - we try to put packages into distros for real :) and i think this was covered - a stable distro release that will not upgrade meson out of principle (that's the definition of stable) isn't going to upgrade efl either for the same reasons... so i think the topic is kind of moot. if someone wants to make pkgs for such distros they can create upgraded meson packages too etc. if they want to go the "all done by pkgs" path :) -- - 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/enlightenment-devel
Re: [E-devel] EFL Autotools freeze proposal
Hi Ross, I understand that, the issue becomes already released versions of Ubuntu and family. They do not just allow anything into backports unless it fixes a particular bug that is being encountered and it is absolutely necessary to update the version that was released. In other words for Ubuntu they will tell you put it in a ppa if users want the bleeding edge stuff. Other than that for Ubuntu package maintainers are asked to get newer versions into Debian which will trickle down then into subsequent Ubuntu releases. Regards, Jonathan Get Outlook for iOS<https://aka.ms/o0ukef> From: Ross Vandegrift Sent: Tuesday, April 30, 2019 12:20 AM To: Enlightenment developer list Subject: Re: [E-devel] EFL Autotools freeze proposal On Mon, Apr 29, 2019 at 05:30:33AM +, Jonathan Aquilina wrote: > I think everyone is missing the point. What you are saying is true but > that is why then they say if you want newer stuff to use a PPA for it > even though its not in the main repo's Yes, anyone can make a PPA. But you're talking to the maintainers of distro packaging - we try to put packages into distros for real :) 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 Mon, Apr 29, 2019 at 05:30:33AM +, Jonathan Aquilina wrote: > I think everyone is missing the point. What you are saying is true but > that is why then they say if you want newer stuff to use a PPA for it > even though its not in the main repo's Yes, anyone can make a PPA. But you're talking to the maintainers of distro packaging - we try to put packages into distros for real :) 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
Hello. On 29.04.19 05:04, Simon Lees wrote: > Hi > > On 24/04/2019 17:47, Stefan Schmidt wrote: >> Hello >> >> On 22.04.19 04:32, Simon Lees wrote: >>> >>> >>> On 17/04/2019 22:45, 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. > 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. >>> >>> Meson also doesn't work on some of the longer term distros that only >>> ship Meson 0.46 (while e does), at least from the last time I tried it. >> >> When you say some you mean only OpenSuSe or also other longer term >> distros? I am not the biggest fan either of having to use newish >> releases of build tools but meson develops more rapidly and we actually >> did fixes on meson itself to build efl ( as well as gaining the needed >> performance). >> >> We also need to see this in some context. Meson 0.46 was released on >> 23.04.2018, which makes it a full year old by now. There actually is a >> 0.50 release now. We are not just using the latest of meson here, we use >> what we need to have efl building sanely for us. >> > > At the same time, Debian, Ubuntu and openSUSE are all running Stable > releases that extend out to 2 years, when you consider that these also > generally have feature freezes for sometime before seeing a 2.5 year old > version of a build tool or other core OS components towards the end of > there lifecycle should not be surprising. Its obviously been less of an > issue with autotools / gcc / cmake as these projects are more mature and > are intoducing fewer really useful things. For me it is perfectly fine if they do a feature freeze and don't want to update their build tooling. In that case this stable and feature frozen version could have efl 1.22.x but not above. We talk about a scenario here where the distro is stable and version are pinned to keep it that way. Yet we should go make sure a not even released efl version from the future will work on it. These things do not mix well. If a user decides for a stable version now he should be fine with running efl 1.22.x until the next stable version of his distro comes out. >> 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. >> >> regards >> Stefan Schmidt >> > > I don't consider 42.3 important, its close to end of life, soon we will > have 15.1 as well. But for us 0.46.0 will be what we have for the 15.X > series, i'm guessing there will be atleast another 2 releases. 2 other releases of what? Meson? EFL? OpenSuSe? 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
Hello. On 25.04.19 17:57, Ross Vandegrift wrote: > 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 Thanks, so we are not the only ones with this requirement. Would have been surprising :-) I will keep this open to track the progress. > 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. Yeah, as so often. At least we know its possible if someone wants to do it. 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
I think everyone is missing the point. What you are saying is true but that is why then they say if you want newer stuff to use a PPA for it even though its not in the main repo's -Original Message- From: Simon Lees Sent: 29 April 2019 05:59 To: enlightenment-devel@lists.sourceforge.net Subject: Re: [E-devel] EFL Autotools freeze proposal We are talking about LTS Ubuntu here, which i'm guessing will get a new meson for the next LTS version which will be released in April 2020, I would not be surprised if like openSUSE they do not take newer versions of most software into there LTS versions because this is generally what people running LTS versions want. On 29/04/2019 12:51, Jonathan Aquilina wrote: > I think what we would really need to check is if Debian has a meason > maintainer if yes we need to work with them to keep meason up to date in > Debian unstable and then the newer version will trickle its way down to each > new release of ubuntu. > > -Original Message- > From: Simon Lees > Sent: 29 April 2019 05:16 > To: enlightenment-devel@lists.sourceforge.net > Subject: Re: [E-devel] EFL Autotools freeze proposal > > > > On 26/04/2019 17:10, Jonathan Aquilina wrote: >> Hi Ross, >> >> Why go through the headache of getting something backported when you can >> just create a ppa for all supported releases and one just add's a ppa? >> >> Regards, >> Jonathan >> > > Generally because if the package is in a PPA it can't be used to build an > official package, so you wouldn't be able to use it to update the current efl > version. I'm not sure if debian allows you to use a backports package to > build a package in stable, but i'm guessing you could use it to build a > package in backports. > > >> On 25/04/2019, 22:56, "Ross Vandegrift" wrote: >> >> 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 >> >> >> >> ___ >> enlightenment-devel mailing list >> enlightenment-devel@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/enlightenment-devel >> > -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B ___ 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
We are talking about LTS Ubuntu here, which i'm guessing will get a new meson for the next LTS version which will be released in April 2020, I would not be surprised if like openSUSE they do not take newer versions of most software into there LTS versions because this is generally what people running LTS versions want. On 29/04/2019 12:51, Jonathan Aquilina wrote: I think what we would really need to check is if Debian has a meason maintainer if yes we need to work with them to keep meason up to date in Debian unstable and then the newer version will trickle its way down to each new release of ubuntu. -Original Message- From: Simon Lees Sent: 29 April 2019 05:16 To: enlightenment-devel@lists.sourceforge.net Subject: Re: [E-devel] EFL Autotools freeze proposal On 26/04/2019 17:10, Jonathan Aquilina wrote: Hi Ross, Why go through the headache of getting something backported when you can just create a ppa for all supported releases and one just add's a ppa? Regards, Jonathan Generally because if the package is in a PPA it can't be used to build an official package, so you wouldn't be able to use it to update the current efl version. I'm not sure if debian allows you to use a backports package to build a package in stable, but i'm guessing you could use it to build a package in backports. On 25/04/2019, 22:56, "Ross Vandegrift" wrote: 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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL Autotools freeze proposal
I think what we would really need to check is if Debian has a meason maintainer if yes we need to work with them to keep meason up to date in Debian unstable and then the newer version will trickle its way down to each new release of ubuntu. -Original Message- From: Simon Lees Sent: 29 April 2019 05:16 To: enlightenment-devel@lists.sourceforge.net Subject: Re: [E-devel] EFL Autotools freeze proposal On 26/04/2019 17:10, Jonathan Aquilina wrote: > Hi Ross, > > Why go through the headache of getting something backported when you can just > create a ppa for all supported releases and one just add's a ppa? > > Regards, > Jonathan > Generally because if the package is in a PPA it can't be used to build an official package, so you wouldn't be able to use it to update the current efl version. I'm not sure if debian allows you to use a backports package to build a package in stable, but i'm guessing you could use it to build a package in backports. > On 25/04/2019, 22:56, "Ross Vandegrift" wrote: > > 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 > > > > ___ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B ___ 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 26/04/2019 17:10, Jonathan Aquilina wrote: Hi Ross, Why go through the headache of getting something backported when you can just create a ppa for all supported releases and one just add's a ppa? Regards, Jonathan Generally because if the package is in a PPA it can't be used to build an official package, so you wouldn't be able to use it to update the current efl version. I'm not sure if debian allows you to use a backports package to build a package in stable, but i'm guessing you could use it to build a package in backports. On 25/04/2019, 22:56, "Ross Vandegrift" wrote: 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 ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B ___ 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 On 24/04/2019 17:47, Stefan Schmidt wrote: Hello On 22.04.19 04:32, Simon Lees wrote: On 17/04/2019 22:45, 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. 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. Meson also doesn't work on some of the longer term distros that only ship Meson 0.46 (while e does), at least from the last time I tried it. When you say some you mean only OpenSuSe or also other longer term distros? I am not the biggest fan either of having to use newish releases of build tools but meson develops more rapidly and we actually did fixes on meson itself to build efl ( as well as gaining the needed performance). We also need to see this in some context. Meson 0.46 was released on 23.04.2018, which makes it a full year old by now. There actually is a 0.50 release now. We are not just using the latest of meson here, we use what we need to have efl building sanely for us. At the same time, Debian, Ubuntu and openSUSE are all running Stable releases that extend out to 2 years, when you consider that these also generally have feature freezes for sometime before seeing a 2.5 year old version of a build tool or other core OS components towards the end of there lifecycle should not be surprising. Its obviously been less of an issue with autotools / gcc / cmake as these projects are more mature and are intoducing fewer really useful things. 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. regards Stefan Schmidt I don't consider 42.3 important, its close to end of life, soon we will have 15.1 as well. But for us 0.46.0 will be what we have for the 15.X series, i'm guessing there will be atleast another 2 releases. Leap takes its build system components from SUSE enterprise, who really don't like updating build tool versions as it means that if any package using that buildsystem is updated even with just one patch it will likely need to undergo a full QA retest, where as if only a small area has been patched that will generally be tested. Having said that, there has been cases where a significant number of packages (most of gnome for example) have needed a newer cmake in a service pack update and it has been taken and people have dealt with it but such a thing shouldn't be counted on. Cheers -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B ___ 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 24/04/2019 17:59, Stefan Schmidt wrote: Hello. On 24.04.19 11:20, Vincent Torri wrote: On Wed, Apr 24, 2019 at 10:17 AM Stefan Schmidt wrote: Hello On 22.04.19 04:32, Simon Lees wrote: On 17/04/2019 22:45, 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. 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. Meson also doesn't work on some of the longer term distros that only ship Meson 0.46 (while e does), at least from the last time I tried it. When you say some you mean only OpenSuSe or also other longer term distros? I am not the biggest fan either of having to use newish releases of build tools but meson develops more rapidly and we actually did fixes on meson itself to build efl ( as well as gaining the needed performance). We also need to see this in some context. Meson 0.46 was released on 23.04.2018, which makes it a full year old by now. There actually is a 0.50 release now. We are not just using the latest of meson here, we use what we need to have efl building sanely for us. 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. meson is installed throughpython, no ? 'pip3 install --upgrade meson' should upgrade to latest meson on all distro no? Thsi is true and the common way for people to get it if the distro does not ship the version needed. Simon looks at this from a packagers point of view though. And to package it for OpenSuSe he could not rely on a meson install through pip. Yeah our build system intentionally has no internet connection so that it is not possible to use newer versions from language specific package managers or other external locations. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B ___ 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, Why go through the headache of getting something backported when you can just create a ppa for all supported releases and one just add's a ppa? Regards, Jonathan On 25/04/2019, 22:56, "Ross Vandegrift" wrote: 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 ___ 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 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 > > > > &g
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 nee
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 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. &g
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 packa
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
Re: [E-devel] EFL Autotools freeze proposal
Isn’t it better to get the documentation sorted so we can start encouraging people to test meson and report any issues they find with it? -Original Message- From: Marcel Hollerbach Sent: 25 April 2019 08:31 To: Enlightenment developer list Subject: Re: [E-devel] EFL Autotools freeze proposal There are no official docuemtnations on the website yet. And i think there will be none by the time autotools is still the prefered way of building. On 4/25/19 8:23 AM, Jonathan Aquilina wrote: > Hi Marcel, > > What about documentation on website on how to build with meason on osx is > there anything of that sort in place? > > Regards, > Jonathan > > -Original Message- > From: Marcel Hollerbach > Sent: 25 April 2019 08:19 > To: Enlightenment developer list > > Subject: Re: [E-devel] EFL Autotools freeze proposal > > Hi, > > you can find our build definitions for osx in > https://git.enlightenment.org/core/efl.git/tree/.ci/ci-configure.sh#n4 > 9 > > Things do work on macos, you can rendering with cocoa, beside the normal > rendering bugs, things are normal there. > > 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 versio
Re: [E-devel] EFL Autotools freeze proposal
There are no official docuemtnations on the website yet. And i think there will be none by the time autotools is still the prefered way of building. On 4/25/19 8:23 AM, Jonathan Aquilina wrote: > Hi Marcel, > > What about documentation on website on how to build with meason on osx is > there anything of that sort in place? > > Regards, > Jonathan > > -Original Message- > From: Marcel Hollerbach > Sent: 25 April 2019 08:19 > To: Enlightenment developer list > Subject: Re: [E-devel] EFL Autotools freeze proposal > > 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. > > 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 necess
Re: [E-devel] EFL Autotools freeze proposal
On 4/24/19 10:20 AM, Stefan Schmidt wrote: > Hello. > > On 17.04.19 20:16, Vincent Torri wrote: >> On Wed, Apr 17, 2019 at 2:20 PM Mike Blumenkrantz >> wrote: >>> >>> 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. >>> >>> 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 would really like to have a bit more time (i'll not be in front of a >> computer next week). And currently ecore_win32 and gdi and ddraw >> engines are even not set up (even if the meson.build files seem to be >> there). > > So far Mike only asked for a freeze of the autotools build files, not > the removal. Whihc means autotools would still be around until things > are building the way they should with meson. > >> At least ecore_win32 should be set so that i can try and compile it > > Sure, agreed. Are there other parts you find missing for the windows > port? Trying to get a better understanding of what is stil missing or > wrong so we can better judge the status to freeze and later remove > autotools. > https://phab.enlightenment.org/T7780 This is a task where you find the missing parts of the meson build. Or at least the problem parts. 3 of the Tasks is beeing worked on / have a revision. For the rest i am unsure what the tasks are for, or what they do. However, whenever the 3 tasks are done, we can basically remove autotools. My complete honest take on the autotools removal here is: The longer we wait, the more we will find things in meson that should be different. In the same way we find from time to time things in the autotools build. So i would say that by the time builds for windows work, we should just remove autotools and move on... Greetings, bu5hm4n > 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
Re: [E-devel] EFL Autotools freeze proposal
Hi Marcel, What about documentation on website on how to build with meason on osx is there anything of that sort in place? Regards, Jonathan -Original Message- From: Marcel Hollerbach Sent: 25 April 2019 08:19 To: Enlightenment developer list Subject: Re: [E-devel] EFL Autotools freeze proposal 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. 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 >&
Re: [E-devel] EFL Autotools freeze proposal
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. 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.
Re: [E-devel] EFL Autotools freeze proposal
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/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 Wed, 24 Apr 2019 10:20:50 +0200 Stefan Schmidt said: > Hello. > > On 17.04.19 20:16, Vincent Torri wrote: > > On Wed, Apr 17, 2019 at 2:20 PM Mike Blumenkrantz > > wrote: > >> > >> 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. > >> > >> 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 would really like to have a bit more time (i'll not be in front of a > > computer next week). And currently ecore_win32 and gdi and ddraw > > engines are even not set up (even if the meson.build files seem to be > > there). > > So far Mike only asked for a freeze of the autotools build files, not > the removal. Whihc means autotools would still be around until things > are building the way they should with meson. IMHO until meson takes over there is no point in freezing them... they are needed and if they have issues need fixing until that point :) > > At least ecore_win32 should be set so that i can try and compile it > > Sure, agreed. Are there other parts you find missing for the windows > port? Trying to get a better understanding of what is stil missing or > wrong so we can better judge the status to freeze and later remove > autotools. > > 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/enlightenment-devel
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/enlightenment-devel
Re: [E-devel] EFL Autotools freeze proposal
Morning Stefan, Take a look at https://launchpad.net/ubuntu/+source/meson That might be able to point you in the right direction as to what versions are available for what release. What I couldn't find though is if a PPA is available for newer versions on already released distro's such as 18.04 Regards, Jonathan -Original Message- From: Stefan Schmidt Sent: 24 April 2019 10:27 To: enlightenment-devel@lists.sourceforge.net Subject: Re: [E-devel] EFL Autotools freeze proposal 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. > >> 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. 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? 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 ___ 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:21 AM Stefan Schmidt wrote: > > Hello. > > On 17.04.19 20:16, Vincent Torri wrote: > > On Wed, Apr 17, 2019 at 2:20 PM Mike Blumenkrantz > > wrote: > >> > >> 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. > >> > >> 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 would really like to have a bit more time (i'll not be in front of a > > computer next week). And currently ecore_win32 and gdi and ddraw > > engines are even not set up (even if the meson.build files seem to be > > there). > > So far Mike only asked for a freeze of the autotools build files, not > the removal. Whihc means autotools would still be around until things > are building the way they should with meson. > > > At least ecore_win32 should be set so that i can try and compile it > > Sure, agreed. Are there other parts you find missing for the windows > port? Trying to get a better understanding of what is stil missing or > wrong so we can better judge the status to freeze and later remove > autotools. https://phab.enlightenment.org/T7786 <--if my patch is correct, feel free to apply it. It's compiling for me with meson gdi and directdraw engines must be setfor meson Vincent ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL Autotools freeze proposal
Hello. On 24.04.19 11:20, Vincent Torri wrote: > On Wed, Apr 24, 2019 at 10:17 AM Stefan Schmidt > wrote: >> >> Hello >> >> On 22.04.19 04:32, Simon Lees wrote: >>> >>> >>> On 17/04/2019 22:45, 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. > 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. >>> >>> Meson also doesn't work on some of the longer term distros that only >>> ship Meson 0.46 (while e does), at least from the last time I tried it. >> >> When you say some you mean only OpenSuSe or also other longer term >> distros? I am not the biggest fan either of having to use newish >> releases of build tools but meson develops more rapidly and we actually >> did fixes on meson itself to build efl ( as well as gaining the needed >> performance). >> >> We also need to see this in some context. Meson 0.46 was released on >> 23.04.2018, which makes it a full year old by now. There actually is a >> 0.50 release now. We are not just using the latest of meson here, we use >> what we need to have efl building sanely for us. >> >> 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. > > meson is installed throughpython, no ? 'pip3 install --upgrade meson' > should upgrade to latest meson on all distro no? Thsi is true and the common way for people to get it if the distro does not ship the version needed. Simon looks at this from a packagers point of view though. And to package it for OpenSuSe he could not rely on a meson install through pip. 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
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. > >> 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. 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? 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
Re: [E-devel] EFL Autotools freeze proposal
On Wed, Apr 24, 2019 at 10:17 AM Stefan Schmidt wrote: > > Hello > > On 22.04.19 04:32, Simon Lees wrote: > > > > > > On 17/04/2019 22:45, 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. > >> > >>> 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. > >> > > > > Meson also doesn't work on some of the longer term distros that only > > ship Meson 0.46 (while e does), at least from the last time I tried it. > > When you say some you mean only OpenSuSe or also other longer term > distros? I am not the biggest fan either of having to use newish > releases of build tools but meson develops more rapidly and we actually > did fixes on meson itself to build efl ( as well as gaining the needed > performance). > > We also need to see this in some context. Meson 0.46 was released on > 23.04.2018, which makes it a full year old by now. There actually is a > 0.50 release now. We are not just using the latest of meson here, we use > what we need to have efl building sanely for us. > > 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. meson is installed throughpython, no ? 'pip3 install --upgrade meson' should upgrade to latest meson on all distro no? Vincent ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] EFL Autotools freeze proposal
Hello. On 17.04.19 20:16, Vincent Torri wrote: > On Wed, Apr 17, 2019 at 2:20 PM Mike Blumenkrantz > wrote: >> >> 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. >> >> 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 would really like to have a bit more time (i'll not be in front of a > computer next week). And currently ecore_win32 and gdi and ddraw > engines are even not set up (even if the meson.build files seem to be > there). So far Mike only asked for a freeze of the autotools build files, not the removal. Whihc means autotools would still be around until things are building the way they should with meson. > At least ecore_win32 should be set so that i can try and compile it Sure, agreed. Are there other parts you find missing for the windows port? Trying to get a better understanding of what is stil missing or wrong so we can better judge the status to freeze and later remove autotools. 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
Hello On 22.04.19 04:32, Simon Lees wrote: > > > On 17/04/2019 22:45, 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. >> >>> 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. >> > > Meson also doesn't work on some of the longer term distros that only > ship Meson 0.46 (while e does), at least from the last time I tried it. When you say some you mean only OpenSuSe or also other longer term distros? I am not the biggest fan either of having to use newish releases of build tools but meson develops more rapidly and we actually did fixes on meson itself to build efl ( as well as gaining the needed performance). We also need to see this in some context. Meson 0.46 was released on 23.04.2018, which makes it a full year old by now. There actually is a 0.50 release now. We are not just using the latest of meson here, we use what we need to have efl building sanely for us. 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. 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 17/04/2019 22:45, 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. 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. Meson also doesn't work on some of the longer term distros that only ship Meson 0.46 (while e does), at least from the last time I tried it. -- Simon Lees (Simotek)http://simotek.net Emergency Update Team keybase.io/simotek SUSE Linux Adelaide Australia, UTC+10:30 GPG Fingerprint: 5B87 DB9D 88DC F606 E489 CEC5 0922 C246 02F0 014B ___ 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 17, 2019 at 2:20 PM Mike Blumenkrantz wrote: > > 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. > > 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 would really like to have a bit more time (i'll not be in front of a computer next week). And currently ecore_win32 and gdi and ddraw engines are even not set up (even if the meson.build files seem to be there). At least ecore_win32 should be set so that i can try and compile it thank you VIncent > 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. > > > 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
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. > 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. > Regards, > Mike > > ___ > 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/enlightenment-devel
