All,
Also noted from the meeting, the current 3.5.13 will _not_ build on gcc 4.7.1. There is _no_ reason not to port the patches to the 3.5.13 code base. All the patches simply cleaned up the code from a syntax standpoint and will not impact it building on earlier gcc releases. The closed bug 979 holds the collection of gcc 4.7 patches that could easily be applied to 3.5.13 to make it gcc 4.7.1 compliant.
All,
Also noted from the meeting, the current 3.5.13 will _not_ build on gcc 4.7.1. There is _no_ reason not to port the patches to the 3.5.13 code base. All the patches simply cleaned up the code from a syntax standpoint and will not impact it building on earlier gcc releases. The closed bug 979 holds the collection of gcc 4.7 patches that could easily be applied to 3.5.13 to make it gcc 4.7.1 compliant.
Have those applications that were affected by the gcc patches been fully and completely tested? If not we would risk introducing regressions into an SRU.
Tim
On 06/27/2012 11:30 PM, Timothy Pearson wrote:
All,
Also noted from the meeting, the current 3.5.13 will _not_ build on gcc 4.7.1. There is _no_ reason not to port the patches to the 3.5.13 code base. All the patches simply cleaned up the code from a syntax standpoint and will not impact it building on earlier gcc releases. The closed bug 979 holds the collection of gcc 4.7 patches that could easily be applied to 3.5.13 to make it gcc 4.7.1 compliant.
Have those applications that were affected by the gcc patches been fully and completely tested? If not we would risk introducing regressions into an SRU.
Tim
I have beat up on them fairly well -- all the way down to correcting konsole 'tips of the day'.. Darrell has been testing heavily as well. I do think your caution is well founded though and I would like to see the development get to the point where 14 is considered "ready for a major code change freeze" so we can get binaries out to more people for testing. I don't think they will uncover much, but I would like the confirmation from multiple distros and multiple users. How many is enough?? 50? 100 installs? Worth considering and setting a target...
On Thursday 28 of June 2012 05:59:38 David C. Rankin wrote:
All,
Also noted from the meeting, the current 3.5.13 will _not_ build on gcc 4.7.1. There is _no_ reason not to port the patches to the 3.5.13 code base. All the patches simply cleaned up the code from a syntax standpoint and will not impact it building on earlier gcc releases. The closed bug 979 holds the collection of gcc 4.7 patches that could easily be applied to 3.5.13 to make it gcc 4.7.1 compliant.
David,
I have to clarify information. While working on 3.5.13-sru, I am aware that gcc 4.7 fixes are necessary at least for Fedora. Therefore, in v3.5.13-sru branch I incorporate these patches. I could say that packages which have passed through my hands, can be compiled with gcc 4.7. :)
Slavek --
On 06/28/2012 12:10 PM, Slávek Banko wrote:
On Thursday 28 of June 2012 05:59:38 David C. Rankin wrote:
All,
Also noted from the meeting, the current 3.5.13 will _not_ build on gcc 4.7.1. There is _no_ reason not to port the patches to the 3.5.13 code base. All the patches simply cleaned up the code from a syntax standpoint and will not impact it building on earlier gcc releases. The closed bug 979 holds the collection of gcc 4.7 patches that could easily be applied to 3.5.13 to make it gcc 4.7.1 compliant.
David,
I have to clarify information. While working on 3.5.13-sru, I am aware that gcc 4.7 fixes are necessary at least for Fedora. Therefore, in v3.5.13-sru branch I incorporate these patches. I could say that packages which have passed through my hands, can be compiled with gcc 4.7. :)
Slavek
Wow!
That's excellent. Where can I get the -sru sources? I was (in my spare time -- ha) going to apply and build the latest 3.5.13 on Arch with all the latest libs and gcc 4.7.1. Thinking through it, libpng15 and gcc47 changes should be the only changes required. If you can give me a link to the -sru sources, that would be great and cut down on the tinkering I have to do. Thanks.
That's excellent. Where can I get the -sru sources? I was (in my spare time -- ha) going to apply and build the latest 3.5.13 on Arch with all the latest libs and gcc 4.7.1. Thinking through it, libpng15 and gcc47 changes should be the only changes required. If you can give me a link to the -sru sources, that would be great and cut down on the tinkering I have to do.
Slavek,
If you provide a link to 3.5.13.1 tarballs, I'll build packages here and test (Slackware).
I believe a set of 3.5.13.1 tarballs is best because then everybody who tests is building from the same source set, rather than trying to patch 3.5.13 sources with patches. If we release 3.5.13.1 as a community then we need to all build from the exact same sources.
We probably should have a punch list of what to test. Nothing extravagant but we need to know which specific bugs have been patched and what kind of test proves functionality. For example, if the kaffeine screen saver patch was backported, then we would need to test that the screen saver is controlled correctly by kaffeine.
Darrell
On Thursday 28 of June 2012 22:23:11 Darrell Anderson wrote:
That's excellent. Where can I get the -sru sources? I was (in my spare time -- ha) going to apply and build the latest 3.5.13 on Arch with all the latest libs and gcc 4.7.1. Thinking through it, libpng15 and gcc47 changes should be the only changes required. If you can give me a link to the -sru sources, that would be great and cut down on the tinkering I have to do.
Slavek,
If you provide a link to 3.5.13.1 tarballs, I'll build packages here and test (Slackware).
I believe a set of 3.5.13.1 tarballs is best because then everybody who tests is building from the same source set, rather than trying to patch 3.5.13 sources with patches. If we release 3.5.13.1 as a community then we need to all build from the exact same sources.
We probably should have a punch list of what to test. Nothing extravagant but we need to know which specific bugs have been patched and what kind of test proves functionality. For example, if the kaffeine screen saver patch was backported, then we would need to test that the screen saver is controlled correctly by kaffeine.
Darrell
David, Darrell,
I am glad for your interest. I will be very glad if you test compilation on your distributions. I was hoping we could then coordinate the SRU release, including packages for various distributions. Source packages are not yet available as a tarballs, but current state are available in the GIT as a branch named v3.5.13-sru - see for example:
http://git.trinitydesktop.org/cgit/tdebase/?h=origin/v3.5.13-sru
There are several packages on which I currently work to "cherry-picking" patches, which I consider as necessary == inadvert tqt changes and gcc 4.7 fixes:
[ ] tdebindings [= ] tdesvn [= ] tde-style-qtcurve [ ] rosegarden [ ] tqscintilla [ ] python-tqt [ ] python-trinity [ ] libqt-perl
Then I must go also through the tde-packaging...
It would be good to incorporate potential other necessary patches before the official release 3.5.13.1. I know that now I have to incorporate several new patches - for example fixes for PNG images. To them I get soon...
By the way: BasKet I liked. But I miss the possibility to copy the selected notes to the clipboard directly as text - not as links to files.
Slavek --
On Friday 29 of June 2012 01:54:29 Slávek Banko wrote:
There are several packages on which I currently work to "cherry-picking" patches, which I consider as necessary == inadvert tqt changes and gcc 4.7 fixes:
[ ] tdebindings [= ] tdesvn [= ] tde-style-qtcurve [ ] rosegarden [ ] tqscintilla [ ] python-tqt [ ] python-trinity [ ] libqt-perl
Update: tqscintilla, python-tqt and libqt-perl are not part of 3.5.13 == I do not need to deal with these packages.
Slavek --
On 06/28/2012 06:54 PM, Slávek Banko wrote:
David, Darrell,
I am glad for your interest. I will be very glad if you test compilation on your distributions. I was hoping we could then coordinate the SRU release, including packages for various distributions. Source packages are not yet available as a tarballs, but current state are available in the GIT as a branch named v3.5.13-sru - see for example:
http://git.trinitydesktop.org/cgit/tdebase/?h=origin/v3.5.13-sru
I saw the 3.5.13-sru label when I updated an old GIT repository to current. It looked to me it was updating from 3.5.13-sru -> origin/3.5.13-sru. That confused me a bit.
How would I do a checkout to make sure I have 3.5.13-sru to build from?
(I know -- stupid questions -- work with me here, I'm not GIT fluent... :)
On Saturday 30 of June 2012 05:57:03 David C. Rankin wrote:
I saw the 3.5.13-sru label when I updated an old GIT repository to current. It looked to me it was updating from 3.5.13-sru -> origin/3.5.13-sru. That confused me a bit.
How would I do a checkout to make sure I have 3.5.13-sru to build from?
(I know -- stupid questions -- work with me here, I'm not GIT fluent... :)
-- David C. Rankin, J.D.,P.E.
As you saw when you update, v3.5.13-sru is a branch in Git, so you also have it already. So far I have not done v3.5.13-sru branch in the "meta package tde". So you have to switch to v3.5.13-sru in the individual packages. Switching doing the following:
(switch to v3.5.13-sru branch) git checkout v3.5.13-sru && git pull && git submodule update
(switch back to master branch) git checkout master && git pull && git submodule update
"checkout" is to switch to the desired branch, "pull" subsequently update to the latest head position in the branch and "submodule update" switch submodules to ensure the appropriate version for the currently active branch.
Slavek --
On 06/30/2012 07:15 PM, Slávek Banko wrote:
On Saturday 30 of June 2012 05:57:03 David C. Rankin wrote:
I saw the 3.5.13-sru label when I updated an old GIT repository to current. It looked to me it was updating from 3.5.13-sru -> origin/3.5.13-sru. That confused me a bit.
How would I do a checkout to make sure I have 3.5.13-sru to build from?
(I know -- stupid questions -- work with me here, I'm not GIT fluent... :)
-- David C. Rankin, J.D.,P.E.
As you saw when you update, v3.5.13-sru is a branch in Git, so you also have it already. So far I have not done v3.5.13-sru branch in the "meta package tde". So you have to switch to v3.5.13-sru in the individual packages. Switching doing the following:
(switch to v3.5.13-sru branch) git checkout v3.5.13-sru && git pull && git submodule update
(switch back to master branch) git checkout master && git pull && git submodule update
"checkout" is to switch to the desired branch, "pull" subsequently update to the latest head position in the branch and "submodule update" switch submodules to ensure the appropriate version for the currently active branch.
Slavek
Thank you Slavek!
I'll work with it over the holiday...
-
Darrell Anderson -
David C. Rankin -
Slávek Banko -
Timothy Pearson