filelight-l10n package is completely unnecessary. In my build script I omit building this package.
I don't build the package either --- duplicate of filelight.
Why don't we purge the sources?
Also applications/kuickshow, which is an exact duplicate of tdegraphics/kuickshow?
And mlt/mlt++, which nothing in Trinity uses, and is horribly outdated from upstream?
Darrell
filelight-l10n package is completely unnecessary. In my build script I omit building this package.
I don't build the package either --- duplicate of filelight. Why don't we purge the sources? Also applications/kuickshow, which is an exact duplicate of tdegraphics/kuickshow? And mlt/mlt++, which nothing in Trinity uses, and is horribly outdated from upstream?
Slavek, Darrell, sorry for the late reply, I am having 10 very busy days :( I have started a new full build, which should be ready by tomorrow if there aren't any FTBFS on the major packages. After that I will test again and let you know if there are other problems.
I agree with Darrell suggestion: if there are packages that are no longer needed, why don't we purge them from the git repo? If we ever need them in the future, we can always "git checkout" them.
In addition to filelight-l10n (which I don't use too, even though I haven been building it), applications/kuickshow and mlt/mlt++, I am also thinking about knetworkmanager8 and kpowersave. AFAIK, they have been replaced by tdenetworkmanager and tdepowersave and I don't use them anymore (knetworkmanager8 also FTBFS).
Slavek, in the git packaging repo, under Ubuntu there are a lot of folders. Are they all necessary or can we purge some? I am thinking about lucid_automake and maverick_automake, plus the 'kdegraphics.automake' and 'kdevelop.cmake' that are in almost all Ubuntu distros. There may be some more, but in general I wonder if we can do a little of clean-up. Debian distros packaging folders are much cleaner IMO.
Cheers Michele
On 02/15/2014 10:10 PM, Michele Calgaro wrote:
In addition to filelight-l10n (which I don't use too, even though I haven been building it), applications/kuickshow and mlt/mlt++, I am also thinking about knetworkmanager8 and kpowersave. AFAIK, they have been replaced by tdenetworkmanager and tdepowersave and I don't use them anymore (knetworkmanager8 also FTBFS).
Slavek, in the git packaging repo, under Ubuntu there are a lot of folders. Are they all necessary or can we purge some? I am thinking about lucid_automake and maverick_automake, plus the 'kdegraphics.automake' and 'kdevelop.cmake' that are in almost all Ubuntu distros. There may be some more, but in general I wonder if we can do a little of clean-up. Debian distros packaging folders are much cleaner IMO.
Let's not throw the baby out with the bathwater. kuickshow can go as it is duplicated in tdegraphics or one of the others. mlt/mtt++ do have dependency value (I forget which package, but I chased that dependency down 2 or 3 years ago and it was still worth keeping even being i686 only).
If I recall correctly knetworkmanager8 AND kpowersave ARE required for QT3 3.5.13 builds. Let make sure our decisions are technically correct and not simply based on whether anyone chooses to build them anymore.
What I would like to know is "What in the heck are 'l10n' packages anyway?"
mlt/mtt++ do have dependency value (I forget which package, but I chased that dependency down 2 or 3 years ago and it was still worth keeping even being i686 only). If I recall correctly knetworkmanager8 AND kpowersave ARE required for QT3 3.5.13 builds. Let make sure our decisions are technically correct and not simply based on whether anyone chooses to build them anymore.
IMO, I would prefer a GIT repo which is relevant to the current development trunk (less code to maintain, less code to look through in case of bug searching, less code to build, less building time, less of all :) ) Yes, some of the mentioned packages may be required for building older TDE versions (such as 3.5.13), but we have tags and as I already said, a simple git checkout would restore your local repo to the exact point of when a particular version was tagged and built in a matter of seconds, including folders no longer present in the current repo.
Anyhow, just my 2 cents.
Cheers Michele
On 02/15/2014 11:11 PM, Michele Calgaro wrote:
mlt/mtt++ do have dependency value (I forget which package, but I chased that dependency down 2 or 3 years ago and it was still worth keeping even being i686 only). If I recall correctly knetworkmanager8 AND kpowersave ARE required for QT3 3.5.13 builds. Let make sure our decisions are technically correct and not simply based on whether anyone chooses to build them anymore.
IMO, I would prefer a GIT repo which is relevant to the current development trunk (less code to maintain, less code to look through in case of bug searching, less code to build, less building time, less of all :) ) Yes, some of the mentioned packages may be required for building older TDE versions (such as 3.5.13), but we have tags and as I already said, a simple git checkout would restore your local repo to the exact point of when a particular version was tagged and built in a matter of seconds, including folders no longer present in the current repo.
Anyhow, just my 2 cents.
Cheers Michele
All good 2 cents.
I agree if the packages server no purposes for anyone any longer, then let's get rid of them. However, if you still use a package and I delete it from the tree just because I don't use it anymore, I would expect you to be a bit perturbed... and vice versa. So if we are going to start lopping directories off the tree, I would suggest we open a "Directories to be Pruned from Git Tree" bug, list the candidates for removal, allow a reasonable time for comment (say 30 days), then with consensus prune those that are no longer needed.
That provides a mechanism for reasoned discussion and should prevent surprises. I know everyone on this list is busy, and for an action like this to be taken based on a couple of e-mails and replies in a 24 hour period does not seem right. There is no rush.
I have opened the bug:
http://bugs.pearsoncomputing.net/show_bug.cgi?id=1937
Add candidates for removal there.
On 02/15/2014 11:11 PM, Michele Calgaro wrote:
Yes, some of the mentioned packages may be required for building older TDE versions (such as 3.5.13), but we have tags and as I already said
Tags are NOT a sufficient safeguard for removing directories from the development tree if they are needed by anyone. Attempting to use tags and introducing the requirement that developers pull multiple "tags" or "branches" within a local repository to get needed code can completely break a local copy causing hours upon hours to correct/rebase/clean/etc... especially with the numerous submodules woven into the TDE git tree. In some cases requiring a complete new clone to be pulled. (I know, I've been there)
I for one do not want to find I need a directory that has been deleted only to have to checkout some past branch or tag to get the code to in turn find that updates to the tree can no longer be pulled due to outstanding or conflicting commits that cause chaos to try and sort out. There are still those building from the tree that use the qt3/3.5.13 codebase. All of the directories applicable to that build knetworkmanager8, etc. should remain in the tree.
As for the directories and a duplicated code or are no longer used by anyone, let's add them to http://bugs.pearsoncomputing.net/show_bug.cgi?id=1937, confirm they are safe to remove and then delete them. Thanks.
I have opened the bug: http://bugs.pearsoncomputing.net/show_bug.cgi?id=1937
Good idea and well thought :)
There are still those building from the tree that use the qt3/3.5.13 codebase. All of the directories applicable to that build knetworkmanager8, etc. should remain in the tree.
I am not the one deciding what goes and what stays, just expressing my opinion (and even less I want to start a "holy war" on this subject). Those building on qt3/3.5.13 have all my respect, but to build 3.5.13 you either 1) already have the code for 3.5.13 locally or 2) you have checkout a 3.5.13 branch/tag or equivalent list of commits. What is in the main trunk at the moment is very different from 3.5.13. As a matter of fact, even trying to build R14 from the repository of one year ago requires considerable manual effort to get everything to build properly (being there while investigating bug 1825).
IMO, the trunk should reflect what is needed now, for R14. For past versions, there is git. Packages required for branch x.y.z should be in the x.y.z branch; packages that are not, should not. As simple as that. If package abc is required for branch x1.y1.z1 but not x2.y2.z2, package abc should be in the branch x1.y1.z1 and *not* in the branch x2.y2.z2. The same applies to the trunk.
If I want to build version x3.y7.z5, I checkout version x3.y7.z5 and git takes care of doing all the dirty work to give me the sources of that version.
Following your logic for knetworkmanager8, then we should also keep the original version of all modules that have been renamed (kde -> tde) because they are needed in 3.5.13. The trunk would quickly "explode" :)
Cheers Michele
On Sunday 16 of February 2014 10:30:44 Michele Calgaro wrote:
Following your logic for knetworkmanager8, then we should also keep the original version of all modules that have been renamed (kde -> tde) because they are needed in 3.5.13. The trunk would quickly "explode" :)
With knetworkmanager8 is another problem. As I recently discovered with dismay, backend for NetworkManager in tdehw-lib only supports NetworkManager 9 and later. With NetworkManager 8 does not work. Therefore, it is necessary either add support for NetworkManager 8 to tdehw-lib or fix knetworkmanager8.
See: http://trinity-devel.pearsoncomputing.net/?0::12085 http://trinity-devel.pearsoncomputing.net/?0::12089
Slavek --
With knetworkmanager8 is another problem. As I recently discovered with dismay, backend for NetworkManager in tdehw-lib only supports NetworkManager 9 and later. With NetworkManager 8 does not work. Therefore, it is necessary either add support for NetworkManager 8 to tdehw-lib or fix knetworkmanager8. http://trinity-devel.pearsoncomputing.net/?0::12085 http://trinity-devel.pearsoncomputing.net/?0::12089
Ah ah! I didn't know that, thanks. So knetworkmanager8 is still relevant to the trunk and will have to stay until support for NM0.8 is added to tdehw-lib. What about kpowersave? Is it still needed for some reasons?
Cheers Michele
Le 16/02/2014 12:58, Michele Calgaro a écrit :
With knetworkmanager8 is another problem. As I recently discovered with dismay, backend for NetworkManager in tdehw-lib only supports NetworkManager 9 and later. With NetworkManager 8 does not work. Therefore, it is necessary either add support for NetworkManager 8 to tdehw-lib or fix knetworkmanager8. http://trinity-devel.pearsoncomputing.net/?0::12085 http://trinity-devel.pearsoncomputing.net/?0::12089
Ah ah! I didn't know that, thanks. So knetworkmanager8 is still relevant to the trunk and will have to stay until support for NM0.8 is added to tdehw-lib. What about kpowersave? Is it still needed for some reasons?
Cheers Michele
Hello, Networkmanager 0.8 is used in RHEL 6, which will be supported until the end of year 2023. (it was released in 2011) https://access.redhat.com/site/support/policy/updates/errata/
So there are some professional users (like me) which would be interested in NM 0.8 support ...
About tdepowersave, I believe that the current powersaving features in R14 already work in RHEL6.
Francois
On Sunday 16 of February 2014 13:29:58 François Andriot wrote:
Le 16/02/2014 12:58, Michele Calgaro a écrit :
With knetworkmanager8 is another problem. As I recently discovered with dismay, backend for NetworkManager in tdehw-lib only supports NetworkManager 9 and later. With NetworkManager 8 does not work. Therefore, it is necessary either add support for NetworkManager 8 to tdehw-lib or fix knetworkmanager8. http://trinity-devel.pearsoncomputing.net/?0::12085 http://trinity-devel.pearsoncomputing.net/?0::12089
Ah ah! I didn't know that, thanks. So knetworkmanager8 is still relevant to the trunk and will have to stay until support for NM0.8 is added to tdehw-lib. What about kpowersave? Is it still needed for some reasons?
Cheers Michele
Hello, Networkmanager 0.8 is used in RHEL 6, which will be supported until the end of year 2023. (it was released in 2011) https://access.redhat.com/site/support/policy/updates/errata/
So there are some professional users (like me) which would be interested in NM 0.8 support ...
About tdepowersave, I believe that the current powersaving features in R14 already work in RHEL6.
Francois
This is a very good reason to NetworkManager 8 was supported!
Slavek --
On Sunday 16 of February 2014 12:58:55 Michele Calgaro wrote:
With knetworkmanager8 is another problem. As I recently discovered with dismay, backend for NetworkManager in tdehw-lib only supports NetworkManager 9 and later. With NetworkManager 8 does not work. Therefore, it is necessary either add support for NetworkManager 8 to tdehw-lib or fix knetworkmanager8. http://trinity-devel.pearsoncomputing.net/?0::12085 http://trinity-devel.pearsoncomputing.net/?0::12089
Ah ah! I didn't know that, thanks. So knetworkmanager8 is still relevant to the trunk and will have to stay until support for NM0.8 is added to tdehw-lib. What about kpowersave? Is it still needed for some reasons?
Cheers Michele
Theoretically, there could be a need to use kpowersave. Because tdehw-lib is based on the sysfs, it is bound to the Linux kernel. If anyone will be interested in TDE on another Unix system, then will either have to use HAL or implement tdehw-lib for another kernel.
Slavek, I completed a full rebuild and update. The file conflicts in amarok/konqplugins and tdenetwork/kopete are gone.
Cheers Michele
I doggy On Feb 16, 2014 9:06 AM, "Slávek Banko" slavek.banko@axis.cz wrote:
On Sunday 16 of February 2014 12:58:55 Michele Calgaro wrote:
With knetworkmanager8 is another problem. As I recently discovered with dismay, backend for NetworkManager in tdehw-lib only supports NetworkManager 9 and later. With NetworkManager 8 does not work. Therefore, it is necessary either add support for NetworkManager 8 to tdehw-lib or fix knetworkmanager8. http://trinity-devel.pearsoncomputing.net/?0::12085 http://trinity-devel.pearsoncomputing.net/?0::12089
Ah ah! I didn't know that, thanks. So knetworkmanager8 is still relevant
to
the trunk and will have to stay until support for NM0.8 is added to tdehw-lib. What about kpowersave? Is it still needed for some reasons?
Cheers Michele
Theoretically, there could be a need to use kpowersave. Because tdehw-lib is based on the sysfs, it is bound to the Linux kernel. If anyone will be interested in TDE on another Unix system, then will either have to use HAL or implement tdehw-lib for another kernel.
-- Slavek
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Lol,
I wouldn't keep it around because half is also unmaintained. Who are we talking about? BSD? On Feb 17, 2014 8:29 AM, "Calvin Morrison" mutantturkey@gmail.com wrote:
I doggy On Feb 16, 2014 9:06 AM, "Slávek Banko" slavek.banko@axis.cz wrote:
On Sunday 16 of February 2014 12:58:55 Michele Calgaro wrote:
With knetworkmanager8 is another problem. As I recently discovered with dismay, backend for NetworkManager in tdehw-lib only supports NetworkManager 9 and later. With NetworkManager 8 does not work. Therefore, it is necessary either add support for NetworkManager 8 to tdehw-lib or fix knetworkmanager8. http://trinity-devel.pearsoncomputing.net/?0::12085 http://trinity-devel.pearsoncomputing.net/?0::12089
Ah ah! I didn't know that, thanks. So knetworkmanager8 is still
relevant to
the trunk and will have to stay until support for NM0.8 is added to tdehw-lib. What about kpowersave? Is it still needed for some reasons?
Cheers Michele
Theoretically, there could be a need to use kpowersave. Because tdehw-lib is based on the sysfs, it is bound to the Linux kernel. If anyone will be interested in TDE on another Unix system, then will either have to use HAL or implement tdehw-lib for another kernel.
-- Slavek
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
Dne po 17. února 2014 Calvin Morrison napsal(a):
I wouldn't keep it around because half is also unmaintained. Who are we talking about? BSD?
Yes, if I remember well, a long time ago there was a query from FreeBSD. Another option would be Debian with FreeBSD kernel.
Slavek --
-
Calvin Morrison -
Darrell Anderson -
David C. Rankin -
François Andriot -
Michele Calgaro -
Slávek Banko