28 Jun
2012
28 Jun
'12
3:59 a.m.
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 C. Rankin, J.D.,P.E.
28 Jun
28 Jun
4:30 a.m.
New subject: [trinity-devel] Port gcc 4.7.1 patches into 3.5.13.1
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
6:46 p.m.
New subject: [trinity-devel] Port gcc 4.7.1 patches into 3.5.13.1
On 06/27/2012 11:30 PM, Timothy Pearson wrote:
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...
--
David C. Rankin, J.D.,P.E.
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
5:10 p.m.
New subject: [trinity-devel] Port gcc 4.7.1 patches into 3.5.13.1
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
--
6:49 p.m.
New subject: [trinity-devel] Port gcc 4.7.1 patches into 3.5.13.1
On 06/28/2012 12:10 PM, Slávek Banko wrote:
On Thursday 28 of June 2012 05:59:38 David C. Rankin
wrote:
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.
--
David C. Rankin, J.D.,P.E.
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
8:23 p.m.
New subject: [trinity-devel] Port gcc 4.7.1 patches into 3.5.13.1
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
11:54 p.m.
New subject: [trinity-devel] Port gcc 4.7.1 patches into 3.5.13.1
On Thursday 28 of June 2012 22:23:11 Darrell Anderson 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
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
--
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
29 Jun
29 Jun
1:36 a.m.
New subject: [trinity-devel] Port gcc 4.7.1 patches into 3.5.13.1
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
--
30 Jun
30 Jun
3:57 a.m.
New subject: [trinity-devel] Port gcc 4.7.1 patches into 3.5.13.1
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... :)
--
David C. Rankin, J.D.,P.E.
1 Jul
1 Jul
12:15 a.m.
New subject: [trinity-devel] Port gcc 4.7.1 patches into 3.5.13.1
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
--
3 Jul
3 Jul
3:34 a.m.
New subject: [trinity-devel] Port gcc 4.7.1 patches into 3.5.13.1
On 06/30/2012 07:15 PM, Slávek Banko wrote:
On Saturday 30 of June 2012 05:57:03 David C. Rankin
wrote:
Thank you Slavek!
I'll work with it over the holiday...
--
David C. Rankin, J.D.,P.E.
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
4555
days inactive
4560
days old
10 comments
4 participants
participants (4)
-
Darrell Anderson -
David C. Rankin -
Slávek Banko -
Timothy Pearson