Re: [Mingw-w64-public] RFE: New stable release
On 1/4/2015 05:56, Ruben Van Boxem wrote: > It would all depend on how the developers handle this, but here's an idea: > - keep master stable (even more than it is now), merging finished features > and bugfixes only. > - create a staging branch which would contain all new features whenever a > feature developer feels his work is ready enough for tessting. This would > take the place of current master, which contains everything from stable to > unstable commits. > - create true feature branches, which track either staging or master, and > develop each feature in here. Timely merges with staging will allow stuff > like upstream Fedora to keep testing the whole. When finished, a > feature-branch will merge with master, finalizing feature development. > > In this scheme, master is dead-stable, and releases are only for > distributors to have some form of "latest release". Heck, versioning could > take on a pure incremental scheme (see e.g. systemd), IMHO. I see no reason > why one would want to use an older version anyways. Most native toolchains > are based off of master currently! > The only issue I see right now with my suggestion is that staging and > master could diverge a bit, as the former contains a lot of other changes > not in master due to the different features. This will require quite some > discipline from the developers to keep each commit local to where it > belongs. But a normal staging branch which includes all changes isn't an > option, as that is the state of current master. We've been through this, nothing will be merged into master then, since it needs to be stable. We'd end up with the exact same situation currently, with "master" requiring extensive backports from "feature", not to mention the integration pains when there are multiple "feature" branches to track with varying levels of completeness and stability. What we will do is release an alpha version of 4.0 from master for testing and bugfixes only, this way, it is still close enough to master while no longer taking on untested code. 0xD4EBC740.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Mass rebuild report for January 03 2015
On 01/03/2015 01:43 PM, Erik van Pienbroek wrote: > mingw-libmicrohttpd-0.9.34-3 > ** Package failed to build while it succeeded during the previous mass > rebuild ** > Package owner: mooninite > Time to build: 9 seconds > Build > logs:http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-libmicrohttpd-0.9.34-3 I meant to drop the BR on plibc a year ago. A new build has been pushed now. -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Mass rebuild report for January 03 2015
Sandro Mani schreef op za 03-01-2015 om 22:24 [+0100]: > >> mingw-poppler-0.28.1-1 > >>** Package failed to build while it succeeded during the previous mass > >> rebuild ** > >>Package owner: smani > >>Time to build: 2 minutes, 25 seconds > >>Build logs: > >> http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-poppler-0.28.1-1 > > Failed with: error: 'gmtime_r' was not declared in this scope > > > gmtime_r in time.h is declared inside a > > #if defined(_POSIX) || defined(_POSIX_THREAD_SAFE_FUNCTIONS) > > block. Apparently, neither are defined when compiling with mingw. > > time.h has changed significantly (also with regard to gmtime_r) after > mingw-poppler was last built (using > mingw-headers-3.9.999-0.1.trunk.git.b08afb.20140912.fc22). I'm not sure > whether this is a mingw-headers bug or something else? These issues with gmtime_r and localtime_r are most likely issues in the mingw-w64 headers as multiple packages are affected by it. Please keep the CC intact as this report was sent to both the Fedora MinGW mailing list and the upstream mingw-w64 mailing list so we can help each other in resolving these issues. Regards, Erik -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] RFE: New stable release
2015-01-03 20:44 GMT+01:00 Kai Tietz : > Yeah, the issue about releasing something not really completing a > feature is ... well ... feeling bad. Nevertheless I admit that > already a lot of changes went into master already, and it is obvious > that our users are eager to get all this in an official released > version. Additionally it is getting latest with gcc 5.0 pretty > mandatory to build it with current trunk version due its new '(n)ftw' > feature. So latest March/April we will need to release trunk IMO. > But this raises some other questions we need to answer. What happens > to the already existing open branches? Do we plan do stop maintenance > at some point for them? Who will tend new branch? Latest thing I > remember is that JonY agreed to maintain 3.x. So will he agree to do > this also for upcoming 4.0? > > The idea of light release sounds interesting. But what shall we make > a release criteria then? Time, amount of commits, features, gut > feeling? > This isn't the first time, and probably won't be the last time that other projects are in need of features in the master branch of MinGW-w64. Perhaps it would be helpful to revise how new additions are made so that perhaps a time-based release scheme can be made more feasible and not just "feel bad" because some stuff isn't finished yet. This would allow for timely releases of whatever features are finished at a certain point in time without slowing development for maintenance. It would all depend on how the developers handle this, but here's an idea: - keep master stable (even more than it is now), merging finished features and bugfixes only. - create a staging branch which would contain all new features whenever a feature developer feels his work is ready enough for tessting. This would take the place of current master, which contains everything from stable to unstable commits. - create true feature branches, which track either staging or master, and develop each feature in here. Timely merges with staging will allow stuff like upstream Fedora to keep testing the whole. When finished, a feature-branch will merge with master, finalizing feature development. In this scheme, master is dead-stable, and releases are only for distributors to have some form of "latest release". Heck, versioning could take on a pure incremental scheme (see e.g. systemd), IMHO. I see no reason why one would want to use an older version anyways. Most native toolchains are based off of master currently! The only issue I see right now with my suggestion is that staging and master could diverge a bit, as the former contains a lot of other changes not in master due to the different features. This will require quite some discipline from the developers to keep each commit local to where it belongs. But a normal staging branch which includes all changes isn't an option, as that is the state of current master. Just my 2 cents. Ruben > Kai > > 2015-01-03 15:29 GMT+01:00 Jacek Caban : > > On 01/02/15 14:47, Erik van Pienbroek wrote: > >> It would definitely help us when mingw-w64 would do more frequent > >> releases. > > > > We had a discussion about that in the past, but there was no follow-up. > > The problem that I can see with past releases that I've been involved in > > is that there was always a lot of development work just before the > > release. How about we do an experiment and do a 'light' stable release > > off the master branch, with no time nor feature pressure. Master branch > > is pretty stable at this point and contains enough changes to be worth > > giving it in hands of users. We could just branch at any point soon and > > release a beta. Depending on how feedback goes, we decide on when to do > > the final release, but we don't push to have any new development done > > for the release nor block development on master branch. This should be > > mostly straightforward. > > > > Jacek > > > > > -- > > Dive into the World of Parallel Programming! The Go Parallel Website, > > sponsored by Intel and developed in partnership with Slashdot Media, is > your > > hub for all things parallel software development, from weekly thought > > leadership blogs to news, videos, case studies, tutorials and more. Take > a > > look and join the conversation now. http://goparallel.sourceforge.net > > ___ > > Mingw-w64-public mailing list > > Mingw-w64-public@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > > -- > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is > your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the convers
Re: [Mingw-w64-public] Mass rebuild report for January 03 2015
On 03.01.2015 23:07, Erik van Pienbroek wrote: > Erik van Pienbroek schreef op za 03-01-2015 om 20:43 [+0100]: >> mingw-libmicrohttpd-0.9.34-3 >> ** Package failed to build while it succeeded during the previous mass >> rebuild ** >> Package owner: mooninite >> Time to build: 9 seconds >> Build logs: >> http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-libmicrohttpd-0.9.34-3 > > Error: No Package found for mingw32-plibc > Error: No Package found for mingw64-plibc > > Seems to be caused by the mingw-plibc package being removed from Fedora > Rawhide Newer MHD dropped plibc dependency, AFAIK, so this problem should go away once Fedore upgrades. -- O< ascii ribbon - stop html email! - www.asciiribbon.org 0x922360B0.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Mass rebuild report for January 03 2015
Erik van Pienbroek schreef op za 03-01-2015 om 20:43 [+0100]: > The following packages FAILED to rebuild: > > mingw-cairo-1.14.0-1 > ** Package failed to build while it succeeded during the previous mass > rebuild ** > Package owner: rjones > Time to build: 1 minute, 32 seconds > Build logs: > http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-cairo-1.14.0-1 Failed with: implicit declaration of function 'ctime_r' > mingw-clucene-2.3.3.4-10 > Package owner: greghellings > Time to build: 1 minute, 41 seconds > Build logs: > http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-clucene-2.3.3.4-10 Also failed in the previous test mass rebuild, package apparently is trying to work around previously missing toolchain features which cause breakage on modern mingw-w64 environments: /builddir/build/BUILD/clucene-core-2.3.3.4/src/shared/CLucene/config/_threads.h:55:104: error: conflicting declaration of C function 'void* _beginthread(void (__attribute__((__stdcall__)) *)(void*), unsigned int, void*)' Needs to be fixed in CLucene upstream > mingw-glib2-2.42.1-1 > ** Package failed to build while it succeeded during the previous mass > rebuild ** > Package owner: epienbro > Time to build: 4 minutes, 7 seconds > Build logs: > http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-glib2-2.42.1-1 Failed with: implicit declaration of function 'localtime_r' > mingw-glibmm24-2.43.2-1 > ** Package failed to build while it succeeded during the previous mass > rebuild ** > Package owner: sailer > Time to build: 38 seconds > Build logs: > http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-glibmm24-2.43.2-1 Failed with: Requested 'glib-2.0 >= 2.43.1' but version of GLib is 2.42.1 Is caused by the mingw-glib2 build failure mentioned above > mingw-libgsf-1.14.30-2 > ** Package failed to build while it succeeded during the previous mass > rebuild ** > Package owner: greghellings > Time to build: 1 minute, 3 seconds > Build logs: > http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-libgsf-1.14.30-2 Failed with: implicit declaration of function 'gmtime_r' > mingw-libmicrohttpd-0.9.34-3 > ** Package failed to build while it succeeded during the previous mass > rebuild ** > Package owner: mooninite > Time to build: 9 seconds > Build logs: > http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-libmicrohttpd-0.9.34-3 Error: No Package found for mingw32-plibc Error: No Package found for mingw64-plibc Seems to be caused by the mingw-plibc package being removed from Fedora Rawhide > mingw-libsoup-2.48.0-2 > ** Package failed to build while it succeeded during the previous mass > rebuild ** > Package owner: epienbro > Time to build: 57 seconds > Build logs: > http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-libsoup-2.48.0-2 Failed with: implicit declaration of function 'gmtime_r' > mingw-libtheora-1.1.1-1 > Package owner: valtri > Time to build: 55 seconds > Build logs: > http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-libtheora-1.1.1-1 Failed with: error: static declaration of 'rint' follows non-static declaration (examples/encoder_example.c vs. mingw-w64 math.h) Needs to be fixed in libtheora upstream > mingw-poppler-0.28.1-1 > ** Package failed to build while it succeeded during the previous mass > rebuild ** > Package owner: smani > Time to build: 2 minutes, 25 seconds > Build logs: > http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-poppler-0.28.1-1 Failed with: error: 'gmtime_r' was not declared in this scope > mingw-qt-4.8.6-6 > ** Package failed to build while it succeeded during the previous mass > rebuild ** > Package owner: sailer > Time to build: 23 minutes, 1 second > Build logs: > http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-qt-4.8.6-6 Failed with: /usr/i686-w64-mingw32/sys-root/mingw/lib/libdbus-1.a(libdbus_1_la-dbus-sysdeps-win.o):(.text+0x3ce3): undefined reference to `GetExtendedTcpTable@24' /usr/i686-w64-mingw32/sys-root/mingw/lib/libdbus-1.a(libdbus_1_la-dbus-sysdeps-win.o):(.text+0x3ea8): undefined reference to `GetExtendedTcpTable@24' Seems to be caused by the update to dbus 1.8.12. Might need an additional -liphlpapi somewhere. > mingw-qt5-qtfeedback-5.0.0-0.9.git20140527.dea0da72 > ** Package failed to build while it succeeded during the previous mass > rebuild **
Re: [Mingw-w64-public] [PATCH] Do not include non-existent header file 'ansidecl.h'
Ok, so please apply patch. Thanks, Kai 2015-01-03 9:25 GMT+01:00 Dongsheng Song : > Yes, I can cross build binutils 2.24, gdb 7.8.1, gcc 4.8/4.9/5.0 (both > 32 bit and 64 bit). Then use these cross build compiler (gcc > 4.8/4.9/5.0) can build the native compiler (gcc 4.8/4.9/5.0) without > any regress. > > PS: this patch did not remove any header files, it just fix compile errors: > > fatal error: ansidecl.h: No such file or directory│ > #include > ^ > compilation terminated. > > On Fri, Jan 2, 2015 at 5:47 PM, Kai Tietz wrote: >> AFAI remember was this header necessary for some of this header users. >> Have you tried to bootstrap binutils/gcc with this change? I remember >> there was a reason to depend on this header, but I can recall why >> exactly. >> Anyway, if boostrap of binutils/gcc is fine without regressions, then >> I am ok with that patch. >> >> Thanks, >> Kai >> >> 2014-12-31 9:42 GMT+01:00 Alexpux : >>> 31 дек. 2014 г., в 6:19, dongsheng.s...@gmail.com написал(а): The header file 'ansidecl.h' did not in the repo, and not generated by any script. OK for commit ? >>> ansidecl.h is part of binutils/gdb >>> Regards, Dongsheng -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >>> >>> >>> -- >>> Dive into the World of Parallel Programming! The Go Parallel Website, >>> sponsored by Intel and developed in partnership with Slashdot Media, is your >>> hub for all things parallel software development, from weekly thought >>> leadership blogs to news, videos, case studies, tutorials and more. Take a >>> look and join the conversation now. http://goparallel.sourceforge.net >>> ___ >>> Mingw-w64-public mailing list >>> Mingw-w64-public@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >> >> -- >> Dive into the World of Parallel Programming! The Go Parallel Website, >> sponsored by Intel and developed in partnership with Slashdot Media, is your >> hub for all things parallel software development, from weekly thought >> leadership blogs to news, videos, case studies, tutorials and more. Take a >> look and join the conversation now. http://goparallel.sourceforge.net >> ___ >> Mingw-w64-public mailing list >> Mingw-w64-public@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > -- > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Mass rebuild report for January 03 2015
This is a report for the 20150103 mass rebuild of all Fedora MinGW packages against Fedora Rawhide and a list of all the changes which have been applied since the previous mass rebuild. During this mass rebuild the following toolchain was used: * mingw-w64 git f7337b 20141222 trunk snapshot * binutils 2.25 * gcc 4.9.2 Statistics about current mass rebuild: -- Timestamp of mass rebuild: 20150103 Total packages: 213 Number of failed packages: 16 Number of succeeded packages: 197 Number of added packages since previous mass rebuild: 14 Time needed to perform mass rebuild: 15 hours, 54 minutes, 27 seconds Statistics about previous mass rebuild: --- Timestamp of previous mass rebuild: 20140803 Total packages: 200 Number of failed packages: 3 Number of succeeded packages: 197 === The following packages were added since the previous rebuild: mingw-admesh mingw-adwaita-icon-theme mingw-colord mingw-colord-gtk mingw-colorhug-client mingw-gstreamer1-plugins-bad-free mingw-gstreamer1-plugins-good mingw-hicolor-icon-theme mingw-libcroco mingw-libgovirt mingw-libgusb mingw-librsvg2 mingw-libtheora mingw-rest === The following packages FAILED to rebuild: mingw-cairo-1.14.0-1 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: rjones Time to build: 1 minute, 32 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-cairo-1.14.0-1 mingw-clucene-2.3.3.4-10 Package owner: greghellings Time to build: 1 minute, 41 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-clucene-2.3.3.4-10 mingw-glib2-2.42.1-1 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: epienbro Time to build: 4 minutes, 7 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-glib2-2.42.1-1 mingw-glibmm24-2.43.2-1 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: sailer Time to build: 38 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-glibmm24-2.43.2-1 mingw-libgsf-1.14.30-2 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: greghellings Time to build: 1 minute, 3 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-libgsf-1.14.30-2 mingw-libmicrohttpd-0.9.34-3 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: mooninite Time to build: 9 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-libmicrohttpd-0.9.34-3 mingw-libsoup-2.48.0-2 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: epienbro Time to build: 57 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-libsoup-2.48.0-2 mingw-libtheora-1.1.1-1 Package owner: valtri Time to build: 55 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-libtheora-1.1.1-1 mingw-poppler-0.28.1-1 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: smani Time to build: 2 minutes, 25 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-poppler-0.28.1-1 mingw-qt-4.8.6-6 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: sailer Time to build: 23 minutes, 1 second Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-qt-4.8.6-6 mingw-qt5-qtfeedback-5.0.0-0.9.git20140527.dea0da72 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: epienbro Time to build: 1 minute, 21 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-qt5-qtfeedback-5.0.0-0.9.git20140527.dea0da72 mingw-qt5-qtpim-5.0.0-0.8.git20140527.98b9bf1 ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: epienbro Time to build: 3 minutes, 48 seconds Build logs: http://build1.vanpienbroek.nl/fedora-mingw-rebuild/20150103/mingw-qt5-qtpim-5.0.0-0.8.git20140527.98b9bf1 mingw-qt5-qtsystems-5.0.0-0.14.git20140323.3f65ffa ** Package failed to build while it succeeded during the previous mass rebuild ** Package owner: epienbro
Re: [Mingw-w64-public] RFE: New stable release
Yeah, the issue about releasing something not really completing a feature is ... well ... feeling bad. Nevertheless I admit that already a lot of changes went into master already, and it is obvious that our users are eager to get all this in an official released version. Additionally it is getting latest with gcc 5.0 pretty mandatory to build it with current trunk version due its new '(n)ftw' feature. So latest March/April we will need to release trunk IMO. But this raises some other questions we need to answer. What happens to the already existing open branches? Do we plan do stop maintenance at some point for them? Who will tend new branch? Latest thing I remember is that JonY agreed to maintain 3.x. So will he agree to do this also for upcoming 4.0? The idea of light release sounds interesting. But what shall we make a release criteria then? Time, amount of commits, features, gut feeling? Kai 2015-01-03 15:29 GMT+01:00 Jacek Caban : > On 01/02/15 14:47, Erik van Pienbroek wrote: >> It would definitely help us when mingw-w64 would do more frequent >> releases. > > We had a discussion about that in the past, but there was no follow-up. > The problem that I can see with past releases that I've been involved in > is that there was always a lot of development work just before the > release. How about we do an experiment and do a 'light' stable release > off the master branch, with no time nor feature pressure. Master branch > is pretty stable at this point and contains enough changes to be worth > giving it in hands of users. We could just branch at any point soon and > release a beta. Depending on how feedback goes, we decide on when to do > the final release, but we don't push to have any new development done > for the release nor block development on master branch. This should be > mostly straightforward. > > Jacek > > -- > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] RFE: New stable release
On 01/02/15 14:47, Erik van Pienbroek wrote: > It would definitely help us when mingw-w64 would do more frequent > releases. We had a discussion about that in the past, but there was no follow-up. The problem that I can see with past releases that I've been involved in is that there was always a lot of development work just before the release. How about we do an experiment and do a 'light' stable release off the master branch, with no time nor feature pressure. Master branch is pretty stable at this point and contains enough changes to be worth giving it in hands of users. We could just branch at any point soon and release a beta. Depending on how feedback goes, we decide on when to do the final release, but we don't push to have any new development done for the release nor block development on master branch. This should be mostly straightforward. Jacek -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Changes needed to get wine-gecko 2.34 built against mingw-w64 v3.3.0
Hi Erik, On 01/02/15 14:50, Erik van Pienbroek wrote: > Jacek Caban schreef op vr 02-01-2015 om 10:46 [+0100]: >> On 01/01/15 18:30, Erik van Pienbroek wrote: >>> Apparently wine-gecko fails to build when these symbols are only >>> available with _WIN32_WINNT >= 0x0600. @Jacek: could this be a >>> wine-gecko bug? I've workaround'ed this issue in Fedora 20 using >>> attached 0021-Lower-_WIN32_WINNT-requirements-for-Un-RegisterPower.patch >>> but my guess is this is not the right fix as I think wine-gecko should >>> set _WIN32_WINNT to 0x0600 while compiling the file >>> hal/windows/WindowsBattery.cpp. >> I don't see the problem here. I remember fixing some version handling >> version macros for similar reason. Maybe 4d7b86c46 would help. > Hi Jacek, > > I tried building wine-gecko without the > 0021-Lower-_WIN32_WINNT-requirements-for-Un-RegisterPower.patch > workaround which I mentioned in my initial post and replaced it with a > cherry-pick of commit 4d7b86c46. Unfortunately this combination fails > with: > > /home/erik/fedora/mingw-wine-gecko/mingw-wine-gecko-2.34/wine-mozilla-2.34/hal/windows/WindowsBattery.cpp:24:17: > error: 'RegisterPowerSettingNotification' was not declared in this scope > static decltype(RegisterPowerSettingNotification)* > sRegisterPowerSettingNotification = nullptr; I gave it another thought from another perspective. We don't need those notifications for wine-gecko anyway, so I will disable related code. I will let you know when I commit that. >>> Would it be possible to backport all the commits mentioned in this mail >>> to the mingw-w64 v3.x branch and release a mingw-w64 v3.4.0 soon so >>> others can benefit from these changes as well? >> I'm not really involved in stable branches. That's quite a few patches >> to cherry-pick, so it's not something an usual stable branch should >> take. On the other hand, if stable releases are so rare, maybe existing >> stable releases should take more cherry-picks. > I agree that the amount of changes is quite large and that is is > questionable whether this really is material for the v3.x branch..but on > the other hand it is the only realistic option we have if we want to be > able to get the latest wine working in Fedora 20. > >> Maybe we could find some long term solution. How did you deal with >> mingw-w64 requirements in the past, when wine-gecko was released every >> three months? How hard would it be to use some version off the master >> branch just for wine-gecko? > In the mailing list thread "RFE: New stable release" I just tried to > explain how we do things in Fedora (it's a bit off-topic for this > specific thread). In general I personally agree that we should release more, but I will reply in another thread to that. I don't want this to be mixed with wine-gecko releases discussion. Jacek -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [PATCH] Do not include non-existent header file 'ansidecl.h'
Yes, I can cross build binutils 2.24, gdb 7.8.1, gcc 4.8/4.9/5.0 (both 32 bit and 64 bit). Then use these cross build compiler (gcc 4.8/4.9/5.0) can build the native compiler (gcc 4.8/4.9/5.0) without any regress. PS: this patch did not remove any header files, it just fix compile errors: fatal error: ansidecl.h: No such file or directory│ #include ^ compilation terminated. On Fri, Jan 2, 2015 at 5:47 PM, Kai Tietz wrote: > AFAI remember was this header necessary for some of this header users. > Have you tried to bootstrap binutils/gcc with this change? I remember > there was a reason to depend on this header, but I can recall why > exactly. > Anyway, if boostrap of binutils/gcc is fine without regressions, then > I am ok with that patch. > > Thanks, > Kai > > 2014-12-31 9:42 GMT+01:00 Alexpux : >> >>> 31 дек. 2014 г., в 6:19, dongsheng.s...@gmail.com написал(а): >>> >>> >>> The header file 'ansidecl.h' did not in the repo, and not generated by any >>> script. >>> >>> OK for commit ? >>> >> ansidecl.h is part of binutils/gdb >> >>> Regards, >>> Dongsheng >>> >>> -- >>> Dive into the World of Parallel Programming! The Go Parallel Website, >>> sponsored by Intel and developed in partnership with Slashdot Media, is your >>> hub for all things parallel software development, from weekly thought >>> leadership blogs to news, videos, case studies, tutorials and more. Take a >>> look and join the conversation now. http://goparallel.sourceforge.net >>> ___ >>> Mingw-w64-public mailing list >>> Mingw-w64-public@lists.sourceforge.net >>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >> >> >> -- >> Dive into the World of Parallel Programming! The Go Parallel Website, >> sponsored by Intel and developed in partnership with Slashdot Media, is your >> hub for all things parallel software development, from weekly thought >> leadership blogs to news, videos, case studies, tutorials and more. Take a >> look and join the conversation now. http://goparallel.sourceforge.net >> ___ >> Mingw-w64-public mailing list >> Mingw-w64-public@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > -- > Dive into the World of Parallel Programming! The Go Parallel Website, > sponsored by Intel and developed in partnership with Slashdot Media, is your > hub for all things parallel software development, from weekly thought > leadership blogs to news, videos, case studies, tutorials and more. Take a > look and join the conversation now. http://goparallel.sourceforge.net > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Dive into the World of Parallel Programming! The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
