Hi all,
who are using my PPA with preliminary packages for stable branch 3.5.13.x, note that you can expect in the coming days massive update. Currently I am uploading packages with the final version 3.5.13.2 to build. Since the speed of buildes is different for each platform, you may encounter occasional inconsistencies - in this case, simply wait for the update.
Complete list of changes since version 3.5.13.1 can be found on wiki: http://www.trinitydesktop.org/wiki/bin/view/Documentation/Releases_3_5_13_2_...
A complete set of package builds for these versions distributions: + Debian 6.0 - Squeeze + Debian 7.0 - Wheezy + Ubuntu 10.04 - Lucid + Ubuntu 10.10 - Maverick + Ubuntu 11.04 - Natty + Ubuntu 11.10 - Oneiric + Ubuntu 12.04 - Precise + Ubuntu 12.10 - Quantal + Ubuntu 13.04 - Raring
The official announcement of the new version will follow after the completion of build and subsequent publishing packages on the mirror.
Thank you for your patience.
Slavek
Le 09/06/2013 01:58, Slávek Banko a écrit :
[...] A complete set of package builds for these versions distributions:
- Debian 6.0 - Squeeze
- Debian 7.0 - Wheezy
- Ubuntu 10.04 - Lucid
- Ubuntu 10.10 - Maverick
- Ubuntu 11.04 - Natty
- Ubuntu 11.10 - Oneiric
- Ubuntu 12.04 - Precise
- Ubuntu 12.10 - Quantal
- Ubuntu 13.04 - Raring
Hello, following Slavek's announcement, the following RPM-distributions will have TDE 3.5.13.2 too: + RHEL / CentOS 4 (partial package set) + RHEL / CentOS 5 + RHEL / CentOS 6 + Fedora 15 + Fedora 16 + Fedora 17 + Fedora 18 + Mageia 2 + Mageia 3 + Mandriva 2011 + openSUSE 11.4 + openSUSE 12.2 + openSUSE 12.3 + PCLinuxOS 2013
Of course it will take some more days to build everything and then synchronize the mirrors.
Francois
On 2013-06-09 09:58 (GMT+0200) François Andriot composed:
Hello, following Slavek's announcement, the following RPM-distributions will have TDE 3.5.13.2 too:
- Mageia 2
- Mageia 3
- Mandriva 2011
- openSUSE 11.4
- openSUSE 12.2
- openSUSE 12.3
Of course it will take some more days to build everything and then synchronize the mirrors.
Are they done yet? I have http://ppa.quickbuild.pearsoncomputing.net/trinity/trinity/rpm/opensuse12.2/... configured, but no updates are reported from currently installed 3.5.13.1. Has the URL been changed?
Le 21/06/2013 09:20, Felix Miata a écrit :
On 2013-06-09 09:58 (GMT+0200) François Andriot composed:
Hello, following Slavek's announcement, the following RPM-distributions will have TDE 3.5.13.2 too:
- Mageia 2
- Mageia 3
- Mandriva 2011
- openSUSE 11.4
- openSUSE 12.2
- openSUSE 12.3
Of course it will take some more days to build everything and then synchronize the mirrors.
Are they done yet? I have http://ppa.quickbuild.pearsoncomputing.net/trinity/trinity/rpm/opensuse12.2/... configured, but no updates are reported from currently installed 3.5.13.1. Has the URL been changed?
Hello, all packages were built and uploaded on the main server, alas, it takes a lot of time to synchronize all other mirrors. The URL have not changed and you should not need to modify your configuration to receive updates when they are available.
Francois
Hello, all packages were built and uploaded on the main server, alas, it takes a lot of time to synchronize all other mirrors. The URL have not changed and you should not need to modify your configuration to receive updates when they are available.
Francois
Hello Francois,
I'm currently making my PCLinuxOS non-official TDE remaster, and each time I update my package list in Synaptic, it says that md5 checksums files are unavailable. It works right as it should after I clear the message, but I guess that users doesn't want to see that.
By the way, it is very stable and it will be a great release! My remaster will be ready soon, even before the release announcement of 3.5.13.2 ... I'll wait for the release announcement before making it available!
Thanks! -Alexandre
That's great news! Can we expect new packages to appear (other than the ones mentioned in the link)? I'm being a bit selfish here, but for me lack of kbibtex in trinity is a blocker and a reason not to upgrade to Debian 7.0 from an ancient Suse distribution.
Janek
On Sunday 09 of June 2013 19:07:56 Jan Stolarek wrote:
That's great news! Can we expect new packages to appear (other than the ones mentioned in the link)? I'm being a bit selfish here, but for me lack of kbibtex in trinity is a blocker and a reason not to upgrade to Debian 7.0 from an ancient Suse distribution.
Yes, I will not forget your request to KBibTeX. However, before the integration package to the stable branch I first need to prepare it for inclusion in the official GIT tree => prepare for the master branch R14. And with this I will deal after release v3.5.13.2.
Please a little patience. Slavek
Le 09/06/2013 19:22, Slávek Banko a écrit :
On Sunday 09 of June 2013 19:07:56 Jan Stolarek wrote:
That's great news! Can we expect new packages to appear (other than the ones mentioned in the link)? I'm being a bit selfish here, but for me lack of kbibtex in trinity is a blocker and a reason not to upgrade to Debian 7.0 from an ancient Suse distribution.
Yes, I will not forget your request to KBibTeX. However, before the integration package to the stable branch I first need to prepare it for inclusion in the official GIT tree => prepare for the master branch R14. And with this I will deal after release v3.5.13.2.
Please a little patience. Slavek
Slavek, I already manage to build kbibtex (and other applications) against 3.5.13.2 / QT3. To achieve that, I had to write some patches to avoid FTBFS. I can post the patches in bugtracker. So, people, do not forget to create a bug for each packaging request so that I can post patches.
The thing I'm currently lacking is an easy way to convert QT3=>TQT3 in the application source code, so that we can import in the GIT repository.
Francois
Thank you Slávek and François. I certainly can wait a little longer. I just wanted to make sure that I will be able to upgrade to Wheezy.
Janek
On Sunday 09 June 2013 21:59:10 you wrote:
Thank you Slávek and François. I certainly can wait a little longer. I just wanted to make sure that I will be able to upgrade to Wheezy.
Janek
Please clarify, Trinity does not officialy support Wheezy, Slávek's repo's do support Wheezy. Slávek's repo's are not on the Trinitydesktop web site.
Official Trinity support for wheezy will be R14 ?
On Sunday 09 June 2013 21:59:10 you wrote:
Thank you Slávek and François. I certainly can wait a little longer. I just wanted to make sure that I will be able to upgrade to Wheezy.
Janek
Please clarify, Trinity does not officialy support Wheezy, Slávek's repo's do support Wheezy. Slávek's repo's are not on the Trinitydesktop web site.
Official Trinity support for wheezy will be R14 ?
-- Peace,
Greg
Actually, Slavek's packages are merged into the official repositories at each point release. Therefore, after 3.5.13.2 is released, TDE will officially support Wheezy. :-)
Tim
Le 09/06/2013 19:22, Slávek Banko a écrit :
On Sunday 09 of June 2013 19:07:56 Jan Stolarek wrote:
That's great news! Can we expect new packages to appear (other than the ones mentioned in the link)? I'm being a bit selfish here, but for me lack of kbibtex in trinity is a blocker and a reason not to upgrade to Debian 7.0 from an ancient Suse distribution.
Yes, I will not forget your request to KBibTeX. However, before the integration package to the stable branch I first need to prepare it for inclusion in the official GIT tree => prepare for the master branch R14. And with this I will deal after release v3.5.13.2.
Please a little patience. Slavek
Slavek, I already manage to build kbibtex (and other applications) against 3.5.13.2 / QT3. To achieve that, I had to write some patches to avoid FTBFS. I can post the patches in bugtracker. So, people, do not forget to create a bug for each packaging request so that I can post patches.
The thing I'm currently lacking is an easy way to convert QT3=>TQT3 in the application source code, so that we can import in the GIT repository.
Francois
You can try using the automated conversion script here: http://git.trinitydesktop.org/cgit/experimental/tree/qt3-tqt3/convert_existi...
Be warned that it takes a LOT of CPU time to run, and that the result probably won't compile the first time around. However, it will deal with 99% of the tedious renaming without intervention.
You then need to take into account the more recent TDE header file and class name changes. Unfortunately, I do not have a script to automatically convert a project to use the new TDE class names and header files, so you would need to make those changes by hand or via your own scripts.
How I typically handle import of a new application is I first commit the last known working version of the application from the original source (i.e. the original project website) to a new GIT repository. I then apply and commit all changes needed to get it building on Qt3 with TDE 3.5.13.x, then finally run the autoconversion tools and commit the first working version for TDE R14. This keeps the original versions around in the GIT history in case something broke during build fixes and/or R14 conversion and is not noticed until far in the future (this has happened many times before!)
Tim
On Monday 10 of June 2013 09:18:15 Timothy Pearson wrote:
Slavek, I already manage to build kbibtex (and other applications) against 3.5.13.2 / QT3. To achieve that, I had to write some patches to avoid FTBFS. I can post the patches in bugtracker. So, people, do not forget to create a bug for each packaging request so that I can post patches.
The thing I'm currently lacking is an easy way to convert QT3=>TQT3 in the application source code, so that we can import in the GIT repository.
Francois
You can try using the automated conversion script here: http://git.trinitydesktop.org/cgit/experimental/tree/qt3-tqt3/convert_exist ing_qt3_app_to_tqt3
Be warned that it takes a LOT of CPU time to run, and that the result probably won't compile the first time around. However, it will deal with 99% of the tedious renaming without intervention.
You then need to take into account the more recent TDE header file and class name changes. Unfortunately, I do not have a script to automatically convert a project to use the new TDE class names and header files, so you would need to make those changes by hand or via your own scripts.
How I typically handle import of a new application is I first commit the last known working version of the application from the original source (i.e. the original project website) to a new GIT repository. I then apply and commit all changes needed to get it building on Qt3 with TDE 3.5.13.x, then finally run the autoconversion tools and commit the first working version for TDE R14. This keeps the original versions around in the GIT history in case something broke during build fixes and/or R14 conversion and is not noticed until far in the future (this has happened many times before!)
Tim
Script to convert K/KDE to TDE is exactly what I am going to prepare...
Slavek
Tons of bugfixes on an already very stable desktop environment: Very nice! I'd like to thank all the TDE dev team for their hard work at keeping KDE 3 computing alive as TDE!
-Alexandre
On Tuesday 11 June 2013 16:23:25 Alexandre Couture wrote:
Tons of bugfixes on an already very stable desktop environment: Very nice! I'd like to thank all the TDE dev team for their hard work at keeping KDE 3 computing alive as TDE!
+1 :-)
Lisi
On Tuesday 11 June 2013 11:23:25 am Alexandre Couture wrote:
Tons of bugfixes on an already very stable desktop environment: Very nice! I'd like to thank all the TDE dev team for their hard work at keeping KDE 3 computing alive as TDE!
-Alexandre
Yes, indeed! +1
Andy
Le 11/06/2013 17:23, Alexandre Couture a écrit :
Tons of bugfixes on an already very stable desktop environment: Very nice! I'd like to thank all the TDE dev team for their hard work at keeping KDE 3 computing alive as TDE!
-Alexandre
Hello Alexandre, since it will take days before the mirrors are synchronized, you may want to get packages immediatly to build your LiveCD. Then you can download packages for PCLinuxOS from my repository. This time I've built TDE 3.5.13.2 for PCLinuxOS 2013, both i586 and x86_64.
APT list for i586 http://trinity.mangafrance.com/pclinuxos/trinity32.list
APT list for x86_64 http://trinity.mangafrance.com/pclinuxos/trinity64.list
Then install packages using: apt-get update apt-get install trinity-desktop apt-get install trinity- .....
Have fun Francois
Hello Alexandre,
since it will take days before the mirrors are synchronized, you may want to get packages immediatly to build your LiveCD.
Then you can download packages for PCLinuxOS from my repository.
This time I've built TDE 3.5.13.2 for PCLinuxOS 2013, both i586 and x86_64.
APT list for i586
http://trinity.mangafrance.com/pclinuxos/trinity32.list
APT list for x86_64
http://trinity.mangafrance.com/pclinuxos/trinity64.list
Then install packages using:
apt-get update
apt-get install trinity-desktop
apt-get install trinity- .....
Have fun
Francois
Thanks! I don't know if it's right to have it before the official release announcement, but thanks! I'll start to work on my LiveCD. My remaster has now a special permission to exist from the PCLinuxOS team, but, of course, it will totally stay ''unofficial'' and not supported by the PCLinuxOS team.
Have a nice day! -Alexandre
On Saturday 15 June 2013 04:05:24 pm Alexandre Couture wrote: ...
My remaster has now a special permission to exist from the PCLinuxOS team, but, of course, it will totally stay ''unofficial'' and not supported by the PCLinuxOS team.
Still excellent news!
Andy
Have a nice day! -Alexandre
On Monday 10 of June 2013 09:18:15 Timothy Pearson wrote:
You can try using the automated conversion script here: http://git.trinitydesktop.org/cgit/experimental/tree/qt3-tqt3/convert_e xisting_qt3_app_to_tqt3
Be warned that it takes a LOT of CPU time to run, and that the result probably won't compile the first time around. However, it will deal with 99% of the tedious renaming without intervention.
You then need to take into account the more recent TDE header file and class name changes. Unfortunately, I do not have a script to automatically convert a project to use the new TDE class names and header files, so you would need to make those changes by hand or via your own scripts.
How I typically handle import of a new application is I first commit the last known working version of the application from the original source (i.e. the original project website) to a new GIT repository. I then apply and commit all changes needed to get it building on Qt3 with TDE 3.5.13.x, then finally run the autoconversion tools and commit the first working version for TDE R14. This keeps the original versions around in the GIT history in case something broke during build fixes and/or R14 conversion and is not noticed until far in the future (this has happened many times before!)
Tim
Because my home machine is pretty slow, I noticed a high demands of script. On one smaller test project ran over 24 minutes.
I've done in this script some optimizations:
1) Instead of starting sed using "find -exec sed" I used the "find | xargs sed". With xargs not run sed for each file, but one sed for multiple files.
2) Instead of starting sed for each replacement I'm using "-e" amassed more replacements to the single sed.
After this optimizations on the same small test project I'm got the same result in 2.5 minutes. Updated script pushed to git in hash 5fc3ba9a.
Slavek --
On Sunday 30 June 2013 10:47:54 am Slávek Banko wrote:
On Monday 10 of June 2013 09:18:15 Timothy Pearson wrote:
You can try using the automated conversion script here: http://git.trinitydesktop.org/cgit/experimental/tree/qt3-tqt3/convert_e xisting_qt3_app_to_tqt3
Be warned that it takes a LOT of CPU time to run, and that the result probably won't compile the first time around. However, it will deal with 99% of the tedious renaming without intervention.
You then need to take into account the more recent TDE header file and class name changes. Unfortunately, I do not have a script to automatically convert a project to use the new TDE class names and header files, so you would need to make those changes by hand or via your own scripts.
How I typically handle import of a new application is I first commit the last known working version of the application from the original source (i.e. the original project website) to a new GIT repository. I then apply and commit all changes needed to get it building on Qt3 with TDE 3.5.13.x, then finally run the autoconversion tools and commit the first working version for TDE R14. This keeps the original versions around in the GIT history in case something broke during build fixes and/or R14 conversion and is not noticed until far in the future (this has happened many times before!)
Tim
Because my home machine is pretty slow, I noticed a high demands of script. On one smaller test project ran over 24 minutes.
I've done in this script some optimizations:
- Instead of starting sed using "find -exec sed" I used the "find | xargs
sed". With xargs not run sed for each file, but one sed for multiple files.
- Instead of starting sed for each replacement I'm using "-e" amassed
more replacements to the single sed.
After this optimizations on the same small test project I'm got the same result in 2.5 minutes. Updated script pushed to git in hash 5fc3ba9a.
Slavek
+1! Teamwork, it's great!
Andy
On Sunday 30 of June 2013 17:20:47 Andy wrote:
On Sunday 30 June 2013 10:47:54 am Slávek Banko wrote:
On Monday 10 of June 2013 09:18:15 Timothy Pearson wrote:
You can try using the automated conversion script here: http://git.trinitydesktop.org/cgit/experimental/tree/qt3-tqt3/convert_e xisting_qt3_app_to_tqt3
Be warned that it takes a LOT of CPU time to run, and that the result probably won't compile the first time around. However, it will deal with 99% of the tedious renaming without intervention.
You then need to take into account the more recent TDE header file and class name changes. Unfortunately, I do not have a script to automatically convert a project to use the new TDE class names and header files, so you would need to make those changes by hand or via your own scripts.
How I typically handle import of a new application is I first commit the last known working version of the application from the original source (i.e. the original project website) to a new GIT repository. I then apply and commit all changes needed to get it building on Qt3 with TDE 3.5.13.x, then finally run the autoconversion tools and commit the first working version for TDE R14. This keeps the original versions around in the GIT history in case something broke during build fixes and/or R14 conversion and is not noticed until far in the future (this has happened many times before!)
Tim
Because my home machine is pretty slow, I noticed a high demands of script. On one smaller test project ran over 24 minutes.
I've done in this script some optimizations:
- Instead of starting sed using "find -exec sed" I used the "find |
xargs sed". With xargs not run sed for each file, but one sed for multiple files.
- Instead of starting sed for each replacement I'm using "-e" amassed
more replacements to the single sed.
After this optimizations on the same small test project I'm got the same result in 2.5 minutes. Updated script pushed to git in hash 5fc3ba9a.
Slavek
+1! Teamwork, it's great!
Andy
During testing, the success of the conversion, I noticed a significant problem - Q_OBJECT is renamed to TQ_OBJECT. And consequently fails building MOC files - more precisely, they are not builded, and this leads to FTBFS.
It is either unwanted rename, or should be the same renaming done throughout whole GIT tree, including the admin module in order to properly work generating MOC files.
Tim, please, what is the correct way?
Thanks Slavek --
On Sunday 30 of June 2013 17:20:47 Andy wrote:
On Sunday 30 June 2013 10:47:54 am Slávek Banko wrote:
On Monday 10 of June 2013 09:18:15 Timothy Pearson wrote:
You can try using the automated conversion script here: http://git.trinitydesktop.org/cgit/experimental/tree/qt3-tqt3/convert_e xisting_qt3_app_to_tqt3
Be warned that it takes a LOT of CPU time to run, and that the
result
probably won't compile the first time around. However, it will deal with 99% of the tedious renaming without intervention.
You then need to take into account the more recent TDE header file
and
class name changes. Unfortunately, I do not have a script to automatically convert a project to use the new TDE class names and header files, so you would need to make those changes by hand or via your own scripts.
How I typically handle import of a new application is I first commit the last known working version of the application from the original source (i.e. the original project website) to a new GIT repository.
I
then apply and commit all changes needed to get it building on Qt3
with
TDE 3.5.13.x, then finally run the autoconversion tools and commit
the
first working version for TDE R14. This keeps the original versions around in the GIT history in case something broke during build fixes and/or R14 conversion and is not noticed until far in the future
(this
has happened many times before!)
Tim
Because my home machine is pretty slow, I noticed a high demands of script. On one smaller test project ran over 24 minutes.
I've done in this script some optimizations:
- Instead of starting sed using "find -exec sed" I used the "find |
xargs sed". With xargs not run sed for each file, but one sed for multiple files.
- Instead of starting sed for each replacement I'm using "-e" amassed
more replacements to the single sed.
After this optimizations on the same small test project I'm got the
same
result in 2.5 minutes. Updated script pushed to git in hash 5fc3ba9a.
Slavek
+1! Teamwork, it's great!
Andy
During testing, the success of the conversion, I noticed a significant problem - Q_OBJECT is renamed to TQ_OBJECT. And consequently fails building MOC files - more precisely, they are not builded, and this leads to FTBFS.
It is either unwanted rename, or should be the same renaming done throughout whole GIT tree, including the admin module in order to properly work generating MOC files.
Tim, please, what is the correct way?
Thanks Slavek --
Use Q_OBJECT. Eventually we might need to change to TQ_OBJECT, but I don't want to make that large of a change in the R14 soft freeze. ;-)
Tim
On Tuesday 02 of July 2013 00:53:09 Timothy Pearson wrote:
On Sunday 30 of June 2013 17:20:47 Andy wrote:
On Sunday 30 June 2013 10:47:54 am Slávek Banko wrote:
On Monday 10 of June 2013 09:18:15 Timothy Pearson wrote:
You can try using the automated conversion script here: http://git.trinitydesktop.org/cgit/experimental/tree/qt3-tqt3/conver t_e xisting_qt3_app_to_tqt3
Be warned that it takes a LOT of CPU time to run, and that the
result
probably won't compile the first time around. However, it will deal with 99% of the tedious renaming without intervention.
You then need to take into account the more recent TDE header file
and
class name changes. Unfortunately, I do not have a script to automatically convert a project to use the new TDE class names and header files, so you would need to make those changes by hand or via your own scripts.
How I typically handle import of a new application is I first commit the last known working version of the application from the original source (i.e. the original project website) to a new GIT repository.
I
then apply and commit all changes needed to get it building on Qt3
with
TDE 3.5.13.x, then finally run the autoconversion tools and commit
the
first working version for TDE R14. This keeps the original versions around in the GIT history in case something broke during build fixes and/or R14 conversion and is not noticed until far in the future
(this
has happened many times before!)
Tim
Because my home machine is pretty slow, I noticed a high demands of script. On one smaller test project ran over 24 minutes.
I've done in this script some optimizations:
- Instead of starting sed using "find -exec sed" I used the "find |
xargs sed". With xargs not run sed for each file, but one sed for multiple files.
- Instead of starting sed for each replacement I'm using "-e" amassed
more replacements to the single sed.
After this optimizations on the same small test project I'm got the
same
result in 2.5 minutes. Updated script pushed to git in hash 5fc3ba9a.
Slavek
+1! Teamwork, it's great!
Andy
During testing, the success of the conversion, I noticed a significant problem - Q_OBJECT is renamed to TQ_OBJECT. And consequently fails building MOC files - more precisely, they are not builded, and this leads to FTBFS.
It is either unwanted rename, or should be the same renaming done throughout whole GIT tree, including the admin module in order to properly work generating MOC files.
Tim, please, what is the correct way?
Thanks Slavek --
Use Q_OBJECT. Eventually we might need to change to TQ_OBJECT, but I don't want to make that large of a change in the R14 soft freeze. ;-)
Tim
Ok, fixed in GIT hash d40da524 :)
Slavek --
Hi everyone,
I'll ask a child's question: Is it finally coming?
Does the new Ubuntu R14 nightly builds causes a slow down to the sync of the mirrors? Maybe a weekly build of it would be enough? Or is it possible that some servers don't sync anymore and we are waiting for nothing?
I'm asking because the new release of my remaster is ready and uploaded, but for the respect of the TDE dev team, I'd prefer to wait for the release announcement of 3.5.13.2 before I release it. TDE 3.5.13.2 packages for PCLinuxOS are ready since the first half of June, so the sync of the mirrors should be almost done, no?
Thank you! -Alexandre
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Saturday 06 of July 2013 00:08:37 Alexandre Couture wrote:
Hi everyone,
I'll ask a child's question: Is it finally coming?
Does the new Ubuntu R14 nightly builds causes a slow down to the sync of the mirrors? Maybe a weekly build of it would be enough? Or is it possible that some servers don't sync anymore and we are waiting for nothing?
I'm asking because the new release of my remaster is ready and uploaded, but for the respect of the TDE dev team, I'd prefer to wait for the release announcement of 3.5.13.2 before I release it. TDE 3.5.13.2 packages for PCLinuxOS are ready since the first half of June, so the sync of the mirrors should be almost done, no?
Thank you! -Alexandre
Status of mirrors I watch for some time. I watch only state Debian / Ubuntu packages. I suppose RPM packages already have synchronization completed. Unfortunately not yet synchronized the updated LiveCD for TDE 3.5.13.2 on Ubuntu 12.04.2.
+ Mirror 1: UK Mirror Service [United Kingdom] -- completed a few hours ago
+ Mirror 2: Nathaniel Taylor [Sweden] -- last few remaining packages - a few hours
+ Mirror 3: DotRiver [France] -- outdated - last sync 2013-12-23
+ Mirror 4: Rezopole [France] -- outdated - last sync 2012-01-20
+ Mirror 5: Ivan Ganchev [Bulgaria] -- outdated - long time
+ Mirror 6: NetLinux [United Kingdom] -- outtdated - long time
Apparently the synchronization is performed only on the mirror 1 and 2. On the other mirrors it makes no sense to wait. I believe that the final release date for 3.5.13.2 may be 6. or 7. July.
Slavek --
On Saturday 06 of July 2013 10:09:33 Lisi Reisz wrote:
On Saturday 06 July 2013 00:47:46 Slávek Banko wrote:
- Mirror 3: DotRiver [France]
-- outdated - last sync 2013-12-23
Clearly to be avoided since my time machine is in for repairs. ;-)
Lisi
:D Sure - there should be 2012-12-23.
Slavek --
Le 06/07/2013 01:47, Slávek Banko a écrit :
Status of mirrors I watch for some time. I watch only state Debian / Ubuntu packages. I suppose RPM packages already have synchronization completed. Unfortunately not yet synchronized the updated LiveCD for TDE 3.5.13.2 on Ubuntu 12.04.2.
- Mirror 1: UK Mirror Service [United Kingdom]
-- completed a few hours ago
- Mirror 2: Nathaniel Taylor [Sweden]
-- last few remaining packages - a few hours
- Mirror 3: DotRiver [France]
-- outdated - last sync 2013-12-23
- Mirror 4: Rezopole [France]
-- outdated - last sync 2012-01-20
- Mirror 5: Ivan Ganchev [Bulgaria]
-- outdated - long time
- Mirror 6: NetLinux [United Kingdom]
-- outtdated - long time
Apparently the synchronization is performed only on the mirror 1 and 2. On the other mirrors it makes no sense to wait. I believe that the final release date for 3.5.13.2 may be 6. or 7. July.
Slavek
Hello, I watch everyday too for the RPM part, and it is FAR from being synchronized ! For me, it looks like neither Mirror1 nor Mirror2 have changed in the last 10 days... I guess they were/are too busy syncing the debian/ubuntu part... I hope it will go on now.
Francois
On Saturday 06 of July 2013 10:48:07 François Andriot wrote:
Le 06/07/2013 01:47, Slávek Banko a écrit :
Status of mirrors I watch for some time. I watch only state Debian / Ubuntu packages. I suppose RPM packages already have synchronization completed. Unfortunately not yet synchronized the updated LiveCD for TDE 3.5.13.2 on Ubuntu 12.04.2.
- Mirror 1: UK Mirror Service [United Kingdom]
-- completed a few hours ago
- Mirror 2: Nathaniel Taylor [Sweden]
-- last few remaining packages - a few hours
- Mirror 3: DotRiver [France]
-- outdated - last sync 2013-12-23
- Mirror 4: Rezopole [France]
-- outdated - last sync 2012-01-20
- Mirror 5: Ivan Ganchev [Bulgaria]
-- outdated - long time
- Mirror 6: NetLinux [United Kingdom]
-- outtdated - long time
Apparently the synchronization is performed only on the mirror 1 and 2. On the other mirrors it makes no sense to wait. I believe that the final release date for 3.5.13.2 may be 6. or 7. July.
Slavek
Hello, I watch everyday too for the RPM part, and it is FAR from being synchronized ! For me, it looks like neither Mirror1 nor Mirror2 have changed in the last 10 days... I guess they were/are too busy syncing the debian/ubuntu part... I hope it will go on now.
Francois
Oh, that's important information. I had assumed that the RPM packages managed to sync before was started synchronization DEB packages. I see that I assumed incorrectly. RPM synchronization packages, therefore abstained due to synchronization DEB packages. And while both were delayed due to synchronization LiveCD R14 (nightly).
However, the mirror 2 has apparently completed synchronization DEB packages. So both are now working on synchronize the RPM packages. But I am afraid that it will take several days (I expect beetween 3 and 5), and that we will have to wait for the official announcement.
Note for Darrell: Note that version was finally tagged just a month ago. And since that time goes building and publishing packages. It is seen that for the maintenance releases we need schedule interval longer than one month.
Slavek --
Hi,
Can I proceed with release of my LiveCD or should I wait for the normal release of 3.5.13.2?
Thanks! -Alexandre
From: slavek.banko@axis.cz To: trinity-users@lists.pearsoncomputing.net Date: Sat, 6 Jul 2013 18:59:57 +0200 Subject: Re: [trinity-users] 3.5.13.2 coming soon
On Saturday 06 of July 2013 10:48:07 François Andriot wrote:
Le 06/07/2013 01:47, Slávek Banko a écrit :
Status of mirrors I watch for some time. I watch only state Debian / Ubuntu packages. I suppose RPM packages already have synchronization completed. Unfortunately not yet synchronized the updated LiveCD for TDE 3.5.13.2 on Ubuntu 12.04.2.
- Mirror 1: UK Mirror Service [United Kingdom]
-- completed a few hours ago
- Mirror 2: Nathaniel Taylor [Sweden]
-- last few remaining packages - a few hours
- Mirror 3: DotRiver [France]
-- outdated - last sync 2013-12-23
- Mirror 4: Rezopole [France]
-- outdated - last sync 2012-01-20
- Mirror 5: Ivan Ganchev [Bulgaria]
-- outdated - long time
- Mirror 6: NetLinux [United Kingdom]
-- outtdated - long time
Apparently the synchronization is performed only on the mirror 1 and 2. On the other mirrors it makes no sense to wait. I believe that the final release date for 3.5.13.2 may be 6. or 7. July.
Slavek
Hello, I watch everyday too for the RPM part, and it is FAR from being synchronized ! For me, it looks like neither Mirror1 nor Mirror2 have changed in the last 10 days... I guess they were/are too busy syncing the debian/ubuntu part... I hope it will go on now.
Francois
Oh, that's important information. I had assumed that the RPM packages managed to sync before was started synchronization DEB packages. I see that I assumed incorrectly. RPM synchronization packages, therefore abstained due to synchronization DEB packages. And while both were delayed due to synchronization LiveCD R14 (nightly).
However, the mirror 2 has apparently completed synchronization DEB packages. So both are now working on synchronize the RPM packages. But I am afraid that it will take several days (I expect beetween 3 and 5), and that we will have to wait for the official announcement.
Note for Darrell: Note that version was finally tagged just a month ago. And since that time goes building and publishing packages. It is seen that for the maintenance releases we need schedule interval longer than one month.
Slavek
To unsubscribe, e-mail: trinity-users-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-users-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-users.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Wednesday 10 of July 2013 16:34:21 Alexandre Couture wrote:
Can I proceed with release of my LiveCD or should I wait for the normal release of 3.5.13.2?
Great it would be if at the time of the official release 3.5.13.2 your CD was available on the Trinity mirrors.
Slavek --
On Wednesday 10 of July 2013 16:34:21 Alexandre Couture wrote:
Can I proceed with release of my LiveCD or should I wait for the normal release of 3.5.13.2?
Great it would be if at the time of the official release 3.5.13.2 your CD was available on the Trinity mirrors.
Slavek
Good, so to save disk space, bandwidth, mirror sync time and money to TDE project, I'll make a small ReadMe file with the instructions to download my livecd where it is hosted (on Filefactory).
That said, as PCLinuxOS is a rolling release, the old image should be removed right away to avoid update problems.
-Alexandre
Le 12/07/2013 01:13, Alexandre Couture a écrit :
On Wednesday 10 of July 2013 16:34:21 Alexandre Couture wrote:
Can I proceed with release of my LiveCD or should I wait for the
normal
release of 3.5.13.2?
Great it would be if at the time of the official release 3.5.13.2
your CD was
available on the Trinity mirrors.
Slavek
Good, so to save disk space, bandwidth, mirror sync time and money to TDE project, I'll make a small ReadMe file with the instructions to download my livecd where it is hosted (on Filefactory).
That said, as PCLinuxOS is a rolling release, the old image should be removed right away to avoid update problems.
-Alexandre
Alexandre, after the mirrors have finished synchronzing RPM packages, I will download your ISO and put it in the "pclinuxos" directory so that it will be downloadable from the mirrors too.
Francois
Le 06/07/2013 18:59, Slávek Banko a écrit :
Oh, that's important information. I had assumed that the RPM packages managed to sync before was started synchronization DEB packages. I see that I assumed incorrectly. RPM synchronization packages, therefore abstained due to synchronization DEB packages. And while both were delayed due to synchronization LiveCD R14 (nightly).
However, the mirror 2 has apparently completed synchronization DEB packages. So both are now working on synchronize the RPM packages. But I am afraid that it will take several days (I expect beetween 3 and 5), and that we will have to wait for the official announcement.
Note for Darrell: Note that version was finally tagged just a month ago. And since that time goes building and publishing packages. It is seen that for the maintenance releases we need schedule interval longer than one month.
Slavek
Hello, good news today ! It looks like the 2 main mirrors have mostly finished synchronization !
+ Mirror 1: UK Mirror Service [United Kingdom] All 3.5.13.2 files look to be here, still some 3.5.13.1 files that are not yet deleted.
+ Mirror 2: Nathaniel Taylor [Sweden] Everything looks OK
This time we are really close to release, but this synchronization time took lot of time !
Francois
On Saturday 20 of July 2013 10:01:51 François Andriot wrote:
Le 06/07/2013 18:59, Slávek Banko a écrit :
Oh, that's important information. I had assumed that the RPM packages managed to sync before was started synchronization DEB packages. I see that I assumed incorrectly. RPM synchronization packages, therefore abstained due to synchronization DEB packages. And while both were delayed due to synchronization LiveCD R14 (nightly).
However, the mirror 2 has apparently completed synchronization DEB packages. So both are now working on synchronize the RPM packages. But I am afraid that it will take several days (I expect beetween 3 and 5), and that we will have to wait for the official announcement.
Note for Darrell: Note that version was finally tagged just a month ago. And since that time goes building and publishing packages. It is seen that for the maintenance releases we need schedule interval longer than one month.
Slavek
Hello, good news today ! It looks like the 2 main mirrors have mostly finished synchronization !
- Mirror 1: UK Mirror Service [United Kingdom]
All 3.5.13.2 files look to be here, still some 3.5.13.1 files that are not yet deleted.
- Mirror 2: Nathaniel Taylor [Sweden]
Everything looks OK
This time we are really close to release, but this synchronization time took lot of time !
Francois
Good news!
For Debian and Ubuntu also seems to have everything in order on both mirrors. It appears that on 21. July could be the final release date. So, if Tim is not gone for whole weekend :)
François, you're looking to prepared release notes and press release? http://www.trinitydesktop.org/wiki/bin/view/Documentation/Releases_3_5_13_2 http://trinity.etherpad.trinitydesktop.org/55
Slavek --
On Saturday 20 of July 2013 10:01:51 François Andriot wrote:
Le 06/07/2013 18:59, Slávek Banko a écrit :
Oh, that's important information. I had assumed that the RPM packages managed to sync before was started synchronization DEB packages. I see that I assumed incorrectly. RPM synchronization packages, therefore abstained due to synchronization DEB packages. And while both were delayed due to synchronization LiveCD R14 (nightly).
However, the mirror 2 has apparently completed synchronization DEB packages. So both are now working on synchronize the RPM packages. But
I
am afraid that it will take several days (I expect beetween 3 and 5),
and
that we will have to wait for the official announcement.
Note for Darrell: Note that version was finally tagged just a month
ago.
And since that time goes building and publishing packages. It is seen that for the maintenance releases we need schedule interval longer
than
one month.
Slavek
Hello, good news today ! It looks like the 2 main mirrors have mostly finished synchronization !
- Mirror 1: UK Mirror Service [United Kingdom]
All 3.5.13.2 files look to be here, still some 3.5.13.1 files that are not yet deleted.
- Mirror 2: Nathaniel Taylor [Sweden]
Everything looks OK
This time we are really close to release, but this synchronization time took lot of time !
Francois
Good news!
For Debian and Ubuntu also seems to have everything in order on both mirrors. It appears that on 21. July could be the final release date. So, if Tim is not gone for whole weekend :)
François, you're looking to prepared release notes and press release? http://www.trinitydesktop.org/wiki/bin/view/Documentation/Releases_3_5_13_2 http://trinity.etherpad.trinitydesktop.org/55
Slavek
I'm here, ready for release!
Tim
On Saturday 20 of July 2013 21:09:38 Timothy Pearson wrote:
On Saturday 20 of July 2013 10:01:51 François Andriot wrote:
Le 06/07/2013 18:59, Slávek Banko a écrit :
Oh, that's important information. I had assumed that the RPM packages managed to sync before was started synchronization DEB packages. I see that I assumed incorrectly. RPM synchronization packages, therefore abstained due to synchronization DEB packages. And while both were delayed due to synchronization LiveCD R14 (nightly).
However, the mirror 2 has apparently completed synchronization DEB packages. So both are now working on synchronize the RPM packages. But
I
am afraid that it will take several days (I expect beetween 3 and 5),
and
that we will have to wait for the official announcement.
Note for Darrell: Note that version was finally tagged just a month
ago.
And since that time goes building and publishing packages. It is seen that for the maintenance releases we need schedule interval longer
than
one month.
Slavek
Hello, good news today ! It looks like the 2 main mirrors have mostly finished synchronization !
- Mirror 1: UK Mirror Service [United Kingdom]
All 3.5.13.2 files look to be here, still some 3.5.13.1 files that are not yet deleted.
- Mirror 2: Nathaniel Taylor [Sweden]
Everything looks OK
This time we are really close to release, but this synchronization time took lot of time !
Francois
Good news!
For Debian and Ubuntu also seems to have everything in order on both mirrors. It appears that on 21. July could be the final release date. So, if Tim is not gone for whole weekend :)
François, you're looking to prepared release notes and press release? http://www.trinitydesktop.org/wiki/bin/view/Documentation/Releases_3_5_13 _2 http://trinity.etherpad.trinitydesktop.org/55
Slavek
I'm here, ready for release!
Tim
Some final corrections for the press release? If not, we can go ahead to the release.
Slavek --
Le 21/07/2013 01:44, Slávek Banko a écrit :
--
I'm here, ready for release!
Tim
Some final corrections for the press release? If not, we can go ahead to the release.
Slavek
No more notes from me. You can release now :-)
Francois
On Sunday 21 of July 2013 11:15:08 François Andriot wrote:
Le 21/07/2013 01:44, Slávek Banko a écrit :
--
I'm here, ready for release!
Tim
Some final corrections for the press release? If not, we can go ahead to the release.
Slavek
No more notes from me. You can release now :-)
Francois
Right now, I happened to notice that the link to the Fedora LiveCD in wiki is invalid. Please, is available new LiveCD?
Slavek --
Le 21/07/2013 12:40, Slávek Banko a écrit :
No more notes from me. You can release now :-)
Francois
Right now, I happened to notice that the link to the Fedora LiveCD in wiki is invalid. Please, is available new LiveCD?
Slavek
Alas, I did not manage to build a Fedora 18 LiveCD. It looks like the LiveCD utilities are broken in this version :-/ So you can remove the link for now.
Francois
Hey guys,
I took a good look at the conversion script here: http://git.trinitydesktop.org/cgit/experimental/tree/qt3-tqt3/convert_existi... and I see several opportunities for improvement. Slavek recently noted a 10-fold speed improvement in execution time after making some tweaks, and I think we can gain an additional 10-fold speed improvement with some more refinements. I would also like to attempt to address some of the issues that the script still misses.
Before I spend time on this, I just wanted to verify two things: 1. Is this something that people are still using, and thus would this work be worthwhile? 2. Just to be sure, C++ is the language used, and it is case-sensitive, correct?
Could someone please point me to a directory on which I would execute the script for testing purposes? I have not done any trinity/qt/kde development so I don't have an execution target. Once I get that, I can easily use diff -r to compare the results of the current script to any new versions.
Or perhaps it would be better to use a git repo which has undergone the conversion that Timothy described? Please advise :-)
(I'm eager to make some kind of contribution, however small, to this project that is so crucial to my day-to-day computing!)
Cheers, David
Quoting the "3.5.13.2 coming soon" thread:
On 06/30/2013 07:47 AM, Slávek Banko wrote:
On Monday 10 of June 2013 09:18:15 Timothy Pearson wrote:
You can try using the automated conversion script here: http://git.trinitydesktop.org/cgit/experimental/tree/qt3-tqt3/convert_e xisting_qt3_app_to_tqt3
Be warned that it takes a LOT of CPU time to run, and that the result probably won't compile the first time around. However, it will deal with 99% of the tedious renaming without intervention.
You then need to take into account the more recent TDE header file and class name changes. Unfortunately, I do not have a script to automatically convert a project to use the new TDE class names and header files, so you would need to make those changes by hand or via your own scripts.
How I typically handle import of a new application is I first commit the last known working version of the application from the original source (i.e. the original project website) to a new GIT repository. I then apply and commit all changes needed to get it building on Qt3 with TDE 3.5.13.x, then finally run the autoconversion tools and commit the first working version for TDE R14. This keeps the original versions around in the GIT history in case something broke during build fixes and/or R14 conversion and is not noticed until far in the future (this has happened many times before!)
Tim
Because my home machine is pretty slow, I noticed a high demands of script. On one smaller test project ran over 24 minutes.
I've done in this script some optimizations:
- Instead of starting sed using "find -exec sed" I used the "find | xargs
sed". With xargs not run sed for each file, but one sed for multiple files.
- Instead of starting sed for each replacement I'm using "-e" amassed
more replacements to the single sed.
After this optimizations on the same small test project I'm got the same result in 2.5 minutes. Updated script pushed to git in hash 5fc3ba9a.
Slavek
Le 10/06/2013 09:18, Timothy Pearson a écrit :
You can try using the automated conversion script here: http://git.trinitydesktop.org/cgit/experimental/tree/qt3-tqt3/convert_existi...
Be warned that it takes a LOT of CPU time to run, and that the result probably won't compile the first time around. However, it will deal with 99% of the tedious renaming without intervention.
You then need to take into account the more recent TDE header file and class name changes. Unfortunately, I do not have a script to automatically convert a project to use the new TDE class names and header files, so you would need to make those changes by hand or via your own scripts.
How I typically handle import of a new application is I first commit the last known working version of the application from the original source (i.e. the original project website) to a new GIT repository. I then apply and commit all changes needed to get it building on Qt3 with TDE 3.5.13.x, then finally run the autoconversion tools and commit the first working version for TDE R14. This keeps the original versions around in the GIT history in case something broke during build fixes and/or R14 conversion and is not noticed until far in the future (this has happened many times before!)
Tim
Hello, I've posted in bug report 531 http://bugs.trinitydesktop.org/show_bug.cgi?id=531 a "sed" command to convert ksensors to TDE R14.
It could be a starting point for a more generic script, as the one for QT3/TQT3 .
Francois
On Wednesday 24 of July 2013 16:29:28 François Andriot wrote:
Le 10/06/2013 09:18, Timothy Pearson a écrit :
You can try using the automated conversion script here: http://git.trinitydesktop.org/cgit/experimental/tree/qt3-tqt3/convert_exi sting_qt3_app_to_tqt3
Be warned that it takes a LOT of CPU time to run, and that the result probably won't compile the first time around. However, it will deal with 99% of the tedious renaming without intervention.
You then need to take into account the more recent TDE header file and class name changes. Unfortunately, I do not have a script to automatically convert a project to use the new TDE class names and header files, so you would need to make those changes by hand or via your own scripts.
How I typically handle import of a new application is I first commit the last known working version of the application from the original source (i.e. the original project website) to a new GIT repository. I then apply and commit all changes needed to get it building on Qt3 with TDE 3.5.13.x, then finally run the autoconversion tools and commit the first working version for TDE R14. This keeps the original versions around in the GIT history in case something broke during build fixes and/or R14 conversion and is not noticed until far in the future (this has happened many times before!)
Tim
Hello, I've posted in bug report 531 http://bugs.trinitydesktop.org/show_bug.cgi?id=531 a "sed" command to convert ksensors to TDE R14.
It could be a starting point for a more generic script, as the one for QT3/TQT3 .
Francois
Sorry, I updated your script by my own, which I have previously successfully tested with the recently added applications. In this is addressed more renaming than in your initial script. Is located in experimental/kde-tde/convert_existing_kde3_app_to_tde
François, if you're not against it, I'll take care of integrating into GIT applications on which you have worked.
Slavek --
On Wednesday 24 of July 2013 19:11:47 Slávek Banko wrote:
On Wednesday 24 of July 2013 16:29:28 François Andriot wrote:
Le 10/06/2013 09:18, Timothy Pearson a écrit :
You can try using the automated conversion script here: http://git.trinitydesktop.org/cgit/experimental/tree/qt3-tqt3/convert_e xi sting_qt3_app_to_tqt3
Be warned that it takes a LOT of CPU time to run, and that the result probably won't compile the first time around. However, it will deal with 99% of the tedious renaming without intervention.
You then need to take into account the more recent TDE header file and class name changes. Unfortunately, I do not have a script to automatically convert a project to use the new TDE class names and header files, so you would need to make those changes by hand or via your own scripts.
How I typically handle import of a new application is I first commit the last known working version of the application from the original source (i.e. the original project website) to a new GIT repository. I then apply and commit all changes needed to get it building on Qt3 with TDE 3.5.13.x, then finally run the autoconversion tools and commit the first working version for TDE R14. This keeps the original versions around in the GIT history in case something broke during build fixes and/or R14 conversion and is not noticed until far in the future (this has happened many times before!)
Tim
Hello, I've posted in bug report 531 http://bugs.trinitydesktop.org/show_bug.cgi?id=531 a "sed" command to convert ksensors to TDE R14.
It could be a starting point for a more generic script, as the one for QT3/TQT3 .
Francois
Sorry, I updated your script by my own, which I have previously successfully tested with the recently added applications. In this is addressed more renaming than in your initial script. Is located in experimental/kde-tde/convert_existing_kde3_app_to_tde
François, if you're not against it, I'll take care of integrating into GIT applications on which you have worked.
Slavek
Note: In script is not done conversion qt3 => tqt intentionally, so that it can be incorporated into GIT as a separate commit prior to conversion kde => tde. As it can be seen in the recently integrated applications.
Slavek --
On Wednesday 24 of July 2013 16:29:28 François Andriot wrote:
Le 10/06/2013 09:18, Timothy Pearson a écrit :
You can try using the automated conversion script here: http://git.trinitydesktop.org/cgit/experimental/tree/qt3-tqt3/convert_exi sting_qt3_app_to_tqt3
Be warned that it takes a LOT of CPU time to run, and that the result probably won't compile the first time around. However, it will deal
with
99% of the tedious renaming without intervention.
You then need to take into account the more recent TDE header file and class name changes. Unfortunately, I do not have a script to automatically convert a project to use the new TDE class names and
header
files, so you would need to make those changes by hand or via your own scripts.
How I typically handle import of a new application is I first commit
the
last known working version of the application from the original source (i.e. the original project website) to a new GIT repository. I then apply and commit all changes needed to get it building on Qt3 with TDE 3.5.13.x, then finally run the autoconversion tools and commit the
first
working version for TDE R14. This keeps the original versions around
in
the GIT history in case something broke during build fixes and/or R14 conversion and is not noticed until far in the future (this has
happened
many times before!)
Tim
Hello, I've posted in bug report 531 http://bugs.trinitydesktop.org/show_bug.cgi?id=531 a "sed" command to convert ksensors to TDE R14.
It could be a starting point for a more generic script, as the one for QT3/TQT3 .
Francois
Sorry, I updated your script by my own, which I have previously successfully tested with the recently added applications. In this is addressed more renaming than in your initial script. Is located in experimental/kde-tde/convert_existing_kde3_app_to_tde
François, if you're not against it, I'll take care of integrating into GIT applications on which you have worked.
Slavek
I have done the initial import/conversion of the applications that are ready, but building has not been tested, and I suspect the Debian/Ubuntu packaging files have bugs of varying severity right now. Feel free to fix up the repositories as needed! :-)
Tim
Le 24/07/2013 19:11, Slávek Banko a écrit :
Sorry, I updated your script by my own, which I have previously successfully tested with the recently added applications. In this is addressed more renaming than in your initial script. Is located in experimental/kde-tde/convert_existing_kde3_app_to_tde
François, if you're not against it, I'll take care of integrating into GIT applications on which you have worked.
Slavek
No problem, I'm testing your script right now. It looks good but is slow: I'll try to enhance the speed. Since I'll need to update both QT3/TQT3 and KDE3/TDE scripts, I'll need to have write access to "experimental" repository. Tim can you please add me ?
Thanks Francois
On Wednesday 24 of July 2013 19:32:37 François Andriot wrote:
Le 24/07/2013 19:11, Slávek Banko a écrit :
Sorry, I updated your script by my own, which I have previously successfully tested with the recently added applications. In this is addressed more renaming than in your initial script. Is located in experimental/kde-tde/convert_existing_kde3_app_to_tde
François, if you're not against it, I'll take care of integrating into GIT applications on which you have worked.
Slavek
No problem, I'm testing your script right now. It looks good but is slow: I'll try to enhance the speed. Since I'll need to update both QT3/TQT3 and KDE3/TDE scripts, I'll need to have write access to "experimental" repository. Tim can you please add me ?
Thanks Francois
Note: script convert_existing_kde3_app_to_tde still retains the advantage that it can be safely executed repeatedly.
I'm sorry that I'm not incorporate script into GIT much earlier.
I got caught up in testing convert_existing_kde3_app_to_tde script on kdocker, which I planned to convert from native Qt application to tde application. Likewise, I planned to convert to tde application also twinkle.
Slavek --
Le 24/07/2013 20:11, Slávek Banko a écrit :
Note: script convert_existing_kde3_app_to_tde still retains the advantage that it can be safely executed repeatedly.
I'm sorry that I'm not incorporate script into GIT much earlier.
I got caught up in testing convert_existing_kde3_app_to_tde script on kdocker, which I planned to convert from native Qt application to tde application. Likewise, I planned to convert to tde application also twinkle.
Slavek
I've already fixed 2 issues in your script: 1) Missing "KIO;" string conversion (required for kftpgrabber) 2) KDE_LANG should NOT be translated to TDE_LANG, at least, in ".am" files
For information, in several "Makefile.am" files, we find some KDE variables that must NOT be translated. I've currently found 3: KDE_DOCS KDE_LANG KDE_ICON ... because some macros in "admin" subfolder uses them. Modifying them result in doc, translation or icons being incorrectly installed, or not installed at all, which does NOT cause FTBFS...
Currently, conversion of kasablanca (bug 570) will fail because of TDE_LANG (translations won't be installed).
Also, I've updated QT3/TQT3 script so that it parses/replaces in ".kcfg" files too.
Francois
On Wednesday 24 of July 2013 20:27:27 François Andriot wrote:
Le 24/07/2013 20:11, Slávek Banko a écrit :
Note: script convert_existing_kde3_app_to_tde still retains the advantage that it can be safely executed repeatedly.
I'm sorry that I'm not incorporate script into GIT much earlier.
I got caught up in testing convert_existing_kde3_app_to_tde script on kdocker, which I planned to convert from native Qt application to tde application. Likewise, I planned to convert to tde application also twinkle.
Slavek
I've already fixed 2 issues in your script:
- Missing "KIO;" string conversion (required for kftpgrabber)
- KDE_LANG should NOT be translated to TDE_LANG, at least, in ".am" files
For information, in several "Makefile.am" files, we find some KDE variables that must NOT be translated. I've currently found 3: KDE_DOCS KDE_LANG KDE_ICON ... because some macros in "admin" subfolder uses them. Modifying them result in doc, translation or icons being incorrectly installed, or not installed at all, which does NOT cause FTBFS...
Currently, conversion of kasablanca (bug 570) will fail because of TDE_LANG (translations won't be installed).
Also, I've updated QT3/TQT3 script so that it parses/replaces in ".kcfg" files too.
Francois
Thank you for the good comments and corrections.
Note: Attached convert_existing_kde3_app_to_tde is identical to the one that is in the git repository.
Slavek --
Le 24/07/2013 20:50, Slávek Banko a écrit :
On Wednesday 24 of July 2013 20:27:27 François Andriot wrote:
I've already fixed 2 issues in your script:
- Missing "KIO;" string conversion (required for kftpgrabber)
- KDE_LANG should NOT be translated to TDE_LANG, at least, in ".am" files
For information, in several "Makefile.am" files, we find some KDE variables that must NOT be translated. I've currently found 3: KDE_DOCS KDE_LANG KDE_ICON ... because some macros in "admin" subfolder uses them. Modifying them result in doc, translation or icons being incorrectly installed, or not installed at all, which does NOT cause FTBFS...
Currently, conversion of kasablanca (bug 570) will fail because of TDE_LANG (translations won't be installed).
Also, I've updated QT3/TQT3 script so that it parses/replaces in ".kcfg" files too.
Francois
Thank you for the good comments and corrections.
Note: Attached convert_existing_kde3_app_to_tde is identical to the one that is in the git repository.
Slavek
Sorry for my mistake, here is the correct script.
Francois
Le 09/06/2013 01:58, Slávek Banko a écrit :
The official announcement of the new version will follow after the completion of build and subsequent publishing packages on the mirror.
Speaking of mirrors, Tim, can you please add the following new replications from my repository to the official mirrors ?
el4 (for RHEL/CentOS 4) f18 (for Fedora 18) mga3 (for Mageia 3) opensuse11.4 opensuse12.3 pclinuxos
I will update the wiki pages accordingly. I hope we still have enough disk space on mirrors :-)
Thanks Francois
Le 09/06/2013 01:58, Slávek Banko a écrit :
The official announcement of the new version will follow after the completion of build and subsequent publishing packages on the mirror.
Speaking of mirrors, Tim, can you please add the following new replications from my repository to the official mirrors ?
el4 (for RHEL/CentOS 4) f18 (for Fedora 18) mga3 (for Mageia 3) opensuse11.4 opensuse12.3 pclinuxos
I will update the wiki pages accordingly. I hope we still have enough disk space on mirrors :-)
Thanks Francois
Mirror pull updated.
Tim
-
Alexandre Couture -
Andy -
David Emerson -
Felix Miata -
François Andriot -
Greg Madden -
Jan Stolarek -
Lisi Reisz -
Slávek Banko -
Timothy Pearson