Hi
In the user-list, I announced the state of preparation updates for 3.5.13: http://trinity-users.pearsoncomputing.net/?0::3008
I also strongly modify the article in Etherpad. Now there is also a current listing of included patches. This will be easier for me to keep it up to date... and perhaps even easier for you: http://trinity.etherpad.trinitydesktop.org/16
I would like to discuss with you whether further delay the official release updates? I intended to add to updates all packages for which were following patches:
- Remove additional unneeded tq method conversions - Rename obsolete tq methods to standard names - Rename a few stragglers - Fix inadvertent "TQ" changes
For some packages, already contained in the update, these patches solve tricky problems. But these patches applies to almost all the remaining packages. Therefore, I ask if I should go into it (will take some time to process it), or ask Tim whether to issue updates as they are ready now?
Personally, I tend to do - to release as soon as possible. Updates already solves many errors. And that's why I find it useful to release as soon as possible. What is your opinion?
I attach link to archive containing the current set of patches (5.4 MiB). Maybe useful for others who prepare packages for other distributions.
http://www.axis.cz/linux/trinity-3.5.13-udpate-patches-1.tgz
Slávek --
Hi
In the user-list, I announced the state of preparation updates for 3.5.13: http://trinity-users.pearsoncomputing.net/?0::3008
I also strongly modify the article in Etherpad. Now there is also a current listing of included patches. This will be easier for me to keep it up to date... and perhaps even easier for you: http://trinity.etherpad.trinitydesktop.org/16
I would like to discuss with you whether further delay the official release updates? I intended to add to updates all packages for which were following patches:
- Remove additional unneeded tq method conversions
- Rename obsolete tq methods to standard names
- Rename a few stragglers
- Fix inadvertent "TQ" changes
For some packages, already contained in the update, these patches solve tricky problems. But these patches applies to almost all the remaining packages. Therefore, I ask if I should go into it (will take some time to process it), or ask Tim whether to issue updates as they are ready now?
Personally, I tend to do - to release as soon as possible. Updates already solves many errors. And that's why I find it useful to release as soon as possible. What is your opinion?
I attach link to archive containing the current set of patches (5.4 MiB). Maybe useful for others who prepare packages for other distributions.
http://www.axis.cz/linux/trinity-3.5.13-udpate-patches-1.tgz
Slávek
Are you referring to a potential 3.5.13.1 source tarball release? If so, yes, it might be a good idea to release such a point update soon.
It would make everything easier for me to do that if a full patch file could be provided that would apply cleanly to the extracted TDE sources from the complete 3.5.13 tarball--this would avoid having to republish the 3.5.13 tarballs, which would add several gigabytes of files to the already strained mirror system.
Tim
On Tuesday 01 of May 2012 22:23:12 Timothy Pearson wrote:
Are you referring to a potential 3.5.13.1 source tarball release? If so, yes, it might be a good idea to release such a point update soon.
It would make everything easier for me to do that if a full patch file could be provided that would apply cleanly to the extracted TDE sources from the complete 3.5.13 tarball--this would avoid having to republish the 3.5.13 tarballs, which would add several gigabytes of files to the already strained mirror system.
Tim
Yes, I mean what we refer to 3.5.13.1.
My goal was to prepare an update so that it could replace existing packages from 3.5.13 (not to occupy more space). So that users who install the Trinity according to the instructions given update automatically. I assumed then you can simply move the packages from my PPA to the official.
In the source packages, patches have kept separately from the original sources (in debian/patches/bp*.diff). I was hoping they might be incorporated into Git branch for 3.5.13. I understand that you wanted a big diff instead of the set of patches?
Slavek --
On Tuesday 01 of May 2012 22:23:12 Timothy Pearson wrote:
Are you referring to a potential 3.5.13.1 source tarball release? If so, yes, it might be a good idea to release such a point update soon.
It would make everything easier for me to do that if a full patch file could be provided that would apply cleanly to the extracted TDE sources from the complete 3.5.13 tarball--this would avoid having to republish the 3.5.13 tarballs, which would add several gigabytes of files to the already strained mirror system.
Tim
Yes, I mean what we refer to 3.5.13.1.
My goal was to prepare an update so that it could replace existing packages from 3.5.13 (not to occupy more space). So that users who install the Trinity according to the instructions given update automatically. I assumed then you can simply move the packages from my PPA to the official.
Yes, this is correct. I am waiting to do so until I get an official sign-off that the new packages work better than the old ones (i.e. users are reporting that the new packages do not crash, etc.).
In the source packages, patches have kept separately from the original sources (in debian/patches/bp*.diff). I was hoping they might be incorporated into Git branch for 3.5.13. I understand that you wanted a big diff instead of the set of patches?
Honestly I'm not sure how to do this in anything resembling a sane manner in GIT. I was considering distribution of the large patch file as an update to the existing 3.5.13 sources, but comments and discussion are definitely welcome on this subject!
Tim
On 2 May 2012, Timothy Pearson told this:
In the source packages, patches have kept separately from the original sources (in debian/patches/bp*.diff). I was hoping they might be incorporated into Git branch for 3.5.13. I understand that you wanted a big diff instead of the set of patches?
Honestly I'm not sure how to do this in anything resembling a sane manner in GIT. I was considering distribution of the large patch file as an update to the existing 3.5.13 sources, but comments and discussion are definitely welcome on this subject!
I'm not quite sure what 'this' is. If you want to apply a bunch of patches to a git repo, there are multiple options:
git am -- Apply a series of patches from a mailbox git quiltimport -- Applies a quilt patchset onto the current branch git apply -- Apply a patch to files and/or to the index
and others.
For a set of Debian diffs, 'git quiltimport' is probably what you're looking for.
On 2 May 2012, Timothy Pearson told this:
In the source packages, patches have kept separately from the original sources (in debian/patches/bp*.diff). I was hoping they might be incorporated into Git branch for 3.5.13. I understand that you wanted a big diff instead of the set of patches?
Honestly I'm not sure how to do this in anything resembling a sane manner in GIT. I was considering distribution of the large patch file as an update to the existing 3.5.13 sources, but comments and discussion are definitely welcome on this subject!
I'm not quite sure what 'this' is. If you want to apply a bunch of patches to a git repo, there are multiple options:
git am -- Apply a series of patches from a mailbox git quiltimport -- Applies a quilt patchset onto the current branch git apply -- Apply a patch to files and/or to the index
and others.
For a set of Debian diffs, 'git quiltimport' is probably what you're looking for.
-- NULL && (void)
I know that. :-) The problem is "How do I apply patches to an existing tagged branch to create a new tagged branch that is completely independent of the main development branch".
Tim
On Tue, May 1, 2012 at 8:59 PM, Timothy Pearson kb9vqf@pearsoncomputing.net wrote:
On 2 May 2012, Timothy Pearson told this:
In the source packages, patches have kept separately from the original sources (in debian/patches/bp*.diff). I was hoping they might be incorporated into Git branch for 3.5.13. I understand that you wanted a big diff instead of the set of patches?
Honestly I'm not sure how to do this in anything resembling a sane manner in GIT. I was considering distribution of the large patch file as an update to the existing 3.5.13 sources, but comments and discussion are definitely welcome on this subject!
I'm not quite sure what 'this' is. If you want to apply a bunch of patches to a git repo, there are multiple options:
git am -- Apply a series of patches from a mailbox git quiltimport -- Applies a quilt patchset onto the current branch git apply -- Apply a patch to files and/or to the index
and others.
For a set of Debian diffs, 'git quiltimport' is probably what you're looking for.
-- NULL && (void)
I know that. :-) The problem is "How do I apply patches to an existing tagged branch to create a new tagged branch that is completely independent of the main development branch".
You should be able to create a branch based off of a tag like anything else. git branch <branchname> <tag> and then check it out git checkout <branchname>
On 2 May 2012, Robert Xu spake thusly:
You should be able to create a branch based off of a tag like anything else.
Yep. More generally, while you have a tag checked out, that 'detached HEAD' git talks about *is* a branch. It's a transient one that doesn't have a name, but if you look in 'git branch' while you're there, you'll see you still appear in there (even if as '(no branch)'). You can even commit, but unless you assign that branch a permanent name via 'git branch' it'll disappear when you move away from it in history: only 'git log -g' can recover it, and in the end it would expire from there, get garbage collected, and be gone.
Dne st 2. května 2012 Robert Xu napsal(a):
I know that. :-) The problem is "How do I apply patches to an existing tagged branch to create a new tagged branch that is completely independent of the main development branch".
You should be able to create a branch based off of a tag like anything else. git branch <branchname> <tag> and then check it out git checkout <branchname>
I think this should be exactly right - create a branch (named v3.5.13?) where is now tag v3.5.13, and then I can commit patches in that branch.
Slavek --
On 2 May 2012, Timothy Pearson uttered the following:
I'm not quite sure what 'this' is. If you want to apply a bunch of patches to a git repo, there are multiple options:
git am -- Apply a series of patches from a mailbox git quiltimport -- Applies a quilt patchset onto the current branch git apply -- Apply a patch to files and/or to the index
and others.
For a set of Debian diffs, 'git quiltimport' is probably what you're looking for.
I know that. :-)
I thought you did, hence my confusion :)
The problem is "How do I apply patches to an existingtagged branch to create a new tagged branch that is completely independent of the main development branch".
Branches aren't tagged in git, so the concept of 'tagged branch' is meaningless. I can't figure out what it might mean, even, which probably means I have been fully assimilated into the git monster and will never be seen again a sane man. (Maybe it's a mercurial concept from its weird world of branches whose names are hardwired into commits and stuff like that. I've never wrapped my head properly around mercurial.)
... but something like
git branch patched-branch git checkout patched-branch [apply and commit the patches however you wish]
should be all you need. Changes to one branch cannot mess up another in git -- since changing old commits without changing their SHA1 hashes is impossible, you need have no fear that e.g. tree rewrites or rebases on one branch will foul up the other: all they'll do is lead to the branches having a merge base further back than they did before (or, in the case of whole-history tree rewrites, not having any commits in common at all anymore).
I guess it all depends what you mean by 'completely independent' though.
On Wednesday 02 of May 2012 02:18:12 Timothy Pearson wrote:
Yes, this is correct. I am waiting to do so until I get an official sign-off that the new packages work better than the old ones (i.e. users are reporting that the new packages do not crash, etc.).
I pause tide of updates, so that users can test. :)
Honestly I'm not sure how to do this in anything resembling a sane manner in GIT. I was considering distribution of the large patch file as an update to the existing 3.5.13 sources, but comments and discussion are definitely welcome on this subject!
With Git I still do not know how much. But I was in CVS can be tagged branch, in which the patches can grow independently of the main branch. I suppose it is possible also in the GIT. And so - to separate branch - I thought the inclusion of patches for 3.5.13.1 (or how to be named).
Tim
Slavek --
On 2 May 2012, Slávek Banko told this:
With Git I still do not know how much. But I was in CVS can be tagged branch, in which the patches can grow independently of the main branch. I suppose it is possible also in the GIT. And so - to separate branch - I thought the inclusion of patches for 3.5.13.1 (or how to be named).
All branches in git have this property: in fact every single commit has this property, since all a branch is is a name (git parlance: a reference, or 'ref') pointing to a commit which can move forward to point at it's child if you hang a new commit off it. (CVS's branches are, well, I'm not sure there *is* a conceptual model for them other than 'we tried to make per-file RCS branching into something per-repository and it nearly worked', which isn't much of a model.)
Even better for patch tracking is 'git rebase', because it solves a perennial problem trying to use branches to track changes that apply to one release when the next one comes out. Say you have a tree with a release, and you have a branch with patches based on that that you applied:
- A - release 1.0 - B - C - D (trunk) \ -- patch -- patch -- patch (patch-branch)
Now a release 2.0 comes out... but you don't want to throw all those patches away, or run around reapplying them and damaging the history. So your tree currently looks like this:
- A - release 1.0 - B - C - D - release 2.0 (trunk) \ -- patch -- patch -- patch (patch-branch)
In this situation,
git rebase trunk patch-branch
will rewrite the patch-branch so it depends on the head of 'trunk' (if you want to rebase on some earlier commit in 'trunk', you can make a temporary branch at the appropriate point in 'trunk' and rebase off that).
This converts the history to look like this:
- A - release 1.0 - B - C - D - release 2.0 (trunk) \ -- patch -- patch -- patch (patch-branch)
If git finds conflicts while doing this -- patches that applied to release 1.0 that no longer applied to release 2.0 for some reason other than their being applied to upstream -- it'll stop you halfway, with all patches up to the conflicting patch applied and the conflicting one in a merge-conflict state, and let you fix the problem, resolve the merge conflict as usual (hack the files shown as conflicting by 'git status', 'git add' and 'git commit'), then 'git rebase --continue' or 'git rebase --abort' if you want to give up).
But note that while this is often thought of as changing the history of the patch-branch, it really isn't. Commits in git are pretty much immutable[1], so what it actually does is creates a *new* patch-branch with rewritten commits on it derived from the commits on the old branch, and gives it the same name as the old branch had. The old branch no longer has a name, but is still visible in e.g. 'git log -g' until garbage-collected in a few weeks time. (The existence of commands like this that can generate whole branches'-worth of garbage at once is one reason why garbage collection is so important in git's design, though it happens so automatically these days that you can mostly ignore it.)
Big caveat here, though: if anyone else was doing work on the tip of the patch-branch and you push your rewritten branch, all their work is gone unless they take special and annoying measures to preserve it -- and indeed git warns you of this by forcing you to push with 'git push -f' to emphasise to you that you might be about to spoil someone's day. So in general either one never rebases public branches, or one advertises that 'this branch is regularly rebased' and people take care not to base work on it directly. (Git's own 'pu' branch, and the linux-next tree, are examples of the latter).
One thing you *can* do if you want to rebase a branch full of changes against release 1.0 to changes against release 2.0 without messing up other people is
git branch patch-branch-2 patch-branch git rebase trunk patch-branch-2
and now the branch that got rebased (the patch branch for release 2.0) has a new name, and the old branch still exists, the same as ever; so the newly-named patch-branch-2 can be pushed without any worry about messing people up who happen to be playing with the patches against release 1.0 on the original patch-branch.
I also commend to you 'git rebase -i', which is a simply stunning way of reshuffling, merging, fixing up and magically manipulating commits before pushing them. Again, to play with this stuff on a branch, make a new branch out of it and play on that: the old branch will be quite safe from your history-defiling experiments.
Most of this stuff is thoroughly git-specific magic. I know of no other version control system that has anything really like 'git rebase': Mercurial is trying but has a long way to go to catch up. (I'd say that Mercurial's advantage these days lies in a much nicer little language for selecting changes to do things to, beside which git's looks rather like white noise.)
[1] 'pretty much' because if someone breaks SHA-1's security badly enough, they'll not be immutable anymore
On Wednesday 02 of May 2012 02:18:12 Timothy Pearson wrote:
On Tuesday 01 of May 2012 22:23:12 Timothy Pearson wrote:
Yes, I mean what we refer to 3.5.13.1.
My goal was to prepare an update so that it could replace existing packages from 3.5.13 (not to occupy more space). So that users who install the Trinity according to the instructions given update automatically. I assumed then you can simply move the packages from my PPA to the official.
Yes, this is correct. I am waiting to do so until I get an official sign-off that the new packages work better than the old ones (i.e. users are reporting that the new packages do not crash, etc.).
Tim,
together with François Andriot we have worked to unify the state of packages (backports) for Debian / Ubuntu and RedHat / Fedora. I will therefore update some (many) packages. You agree, that I called them "3.5.13.1 - revision" instead of the current "3.5.13 - out of date svn revision number + ax_revision_"? For example: kdebase-trinity 4:3.5.13.1-0.
Slavek --
Le 01/05/2012 22:09, Slávek Banko a écrit :
Hi
In the user-list, I announced the state of preparation updates for 3.5.13: http://trinity-users.pearsoncomputing.net/?0::3008
I also strongly modify the article in Etherpad. Now there is also a current listing of included patches. This will be easier for me to keep it up to date... and perhaps even easier for you: http://trinity.etherpad.trinitydesktop.org/16
I would like to discuss with you whether further delay the official release updates? I intended to add to updates all packages for which were following patches:
- Remove additional unneeded tq method conversions
- Rename obsolete tq methods to standard names
- Rename a few stragglers
- Fix inadvertent "TQ" changes
For some packages, already contained in the update, these patches solve tricky problems. But these patches applies to almost all the remaining packages. Therefore, I ask if I should go into it (will take some time to process it), or ask Tim whether to issue updates as they are ready now?
Personally, I tend to do - to release as soon as possible. Updates already solves many errors. And that's why I find it useful to release as soon as possible. What is your opinion?
I attach link to archive containing the current set of patches (5.4 MiB). Maybe useful for others who prepare packages for other distributions.
http://www.axis.cz/linux/trinity-3.5.13-udpate-patches-1.tgz
Slávek
Hello, what would be great (for me), is that patches for stable release (currently 3.5.13) are downloadable individually from a central/official place. So that every distro could keep in sync with updated packages, instead of doing the work separately.
I'd also like to have source tarballs for 3.5.13.1 when it's out, to eliminate the need for patches in packaging process.
About a release date, I'm not really in a hurry, since I already provide heavily patched packages for RHEL/Fedora. So TDE is already working very well and there will be no big difference between current 3.5.13 and 3.5.13.1 for the end-users.
BTW, the answer to a previous mail from you is below. (this is not top-posting)
Le 02/05/2012 17:35, Slávek Banko a écrit :
Dne út 24. dubna 2012 François Andriot napsal(a):
But I did not find a place to download your patches. (I haven't searched a lot ...) If you share them, I will happily use them too.
Francois
Please could you compare if you have included patches that I am not incorporated? If will be managed to set up a GIT branch for 3.5.13 updates, there would be good to incorporate also patches from you.
My patches are now available for download here: http://www.axis.cz/linux/trinity-3.5.13-udpate-patches-1.tgz
Slavek
It takes a long time to compare every patch you have to every patch I have :-) From what I've seen, we have both backported all (or almost all) patches from GIT to TDE 3.5.13 .
The most notable differences are: 1) I have skipped all patches about "QT=>TQT" (or TQT=>QT) renaming, because I thought it was a never-ending work in progress which could cause hard-to-fix regression. 2) I absolutely need all GCC 4.7 related patch (I see you have some, but not all of them). This also applies to ruby 1.9 and libpng 1.4/1.5 .
Also, there are lots of commits by Darell to remove "More applications" from program menu, and neither you nor me have taken them. Maybe we should consider taking them.
For now, I've seen (or I believe I've seen) that you are lacking the following patches:
Amarok: I have some FTBFS and some features added. See http://bugs.trinitydesktop.org/show_bug.cgi?id=984
Arts: I have some features added. See http://bugs.trinitydesktop.org/show_bug.cgi?id=747
Kdeadmin: I've just added a patch to add support for RHEL/Fedora in networkconf backend, see: See http://bugs.trinitydesktop.org/show_bug.cgi?id=619
Kdebase: Too many patches to compare ! I think the only ones I have that you don't are RHEL/Fedora specific, so they won't go upstream. An important point is the famous "startkde" script. Should we try to have a stable updated script upstream, or should we keep distro-specific changes in every packaging ?
Kdegraphics: I have some FTBFS on stock 3.5.13. See http://bugs.trinitydesktop.org/show_bug.cgi?id=984
Kdelibs: You do not have patch for bugs: 656 , 764 You do not have patch for commits: 24f144fa , 2b035349
Kdeutils: The "klaptopdaemon" from upstream will only work on debian/ubuntu because there is a hardcoded "dpkg" command in its source code. For all other distros, you should apply the following patch (should be upstream IMHO): http://git.trinitydesktop.org/cgit/tde-packaging/tree/redhat/kdeutils/kdeuti...
That's all what I see for now. Good job BTW :-)
Francois
Dne čt 3. května 2012 Francois Andriot napsal(a):
Hello, what would be great (for me), is that patches for stable release (currently 3.5.13) are downloadable individually from a central/official place. So that every distro could keep in sync with updated packages, instead of doing the work separately.
I'd also like to have source tarballs for 3.5.13.1 when it's out, to eliminate the need for patches in packaging process.
About a release date, I'm not really in a hurry, since I already provide heavily patched packages for RHEL/Fedora. So TDE is already working very well and there will be no big difference between current 3.5.13 and 3.5.13.1 for the end-users.
Hey. Precisely due to the central location of the patches I have stirred up the debate on the establishment of a 3.5.13 branch in the GIT. That seems like an ideal solution. Patches would be available and we can work on them together. And it also simplifies the new source tarballs ready for others, who creates packages.
Perhaps it would be helpful if he joined us and Tim Williams, who prepares packages for Mandriva. I am not clear whether he takes the specs and patches from your packages, or if he also backport patches?
Date of release interested me, because standard sources for Debian and Ubuntu still contain original 3.5.13 - that is, with a number of bugs. But I do not want to rush.
Slavek --
On Thursday 03 of May 2012 23:51:44 Francois Andriot wrote:
The most notable differences are:
- I have skipped all patches about "QT=>TQT" (or TQT=>QT) renaming,
because I thought it was a never-ending work in progress which could cause hard-to-fix regression.
At the beginning I was not planning to incorporate TQT repairs. But then just when such repairs have helped solve various tricky bugs, so I decided to incorporate them. The reactions of users of my PPA can assume that the boundaries that I set not cause regressions. As I mentioned in earlier mails, I have limited the inclusion of the following patches:
-- Remove additional unneeded tq method conversions -- Rename obsolete tq methods to standard names -- Rename a few stragglers -- Fix inadvertent "TQ" changes
If we agree on that, I would incorporate referred patches into all the other packages that are not yet included in the update. However it would require more time, so I prefer leaving it up to potential further update.
- I absolutely need all GCC 4.7 related patch (I see you have some, but
not all of them). This also applies to ruby 1.9 and libpng 1.4/1.5 .
I understand. For debian and ubuntu's patches are not yet substantial. The fact that I have some integrated and some are not, has a simple explanation - some patches were in GIT after I released the update. :)
Also, there are lots of commits by Darell to remove "More applications" from program menu, and neither you nor me have taken them. Maybe we should consider taking them.
Yes, I thought about them several times. When we think about it both equally, so it probably will be a good idea :) We will wait for GIT branch or incorporate it again each in yourself?
Slavek --
Le 05/05/2012 02:48, Slávek Banko a écrit :
On Thursday 03 of May 2012 23:51:44 Francois Andriot wrote:
The most notable differences are:
- I have skipped all patches about "QT=>TQT" (or TQT=>QT) renaming,
because I thought it was a never-ending work in progress which could cause hard-to-fix regression.
At the beginning I was not planning to incorporate TQT repairs. But then just when such repairs have helped solve various tricky bugs, so I decided to incorporate them. The reactions of users of my PPA can assume that the boundaries that I set not cause regressions. As I mentioned in earlier mails, I have limited the inclusion of the following patches:
-- Remove additional unneeded tq method conversions -- Rename obsolete tq methods to standard names -- Rename a few stragglers -- Fix inadvertent "TQ" changes
If we agree on that, I would incorporate referred patches into all the other packages that are not yet included in the update. However it would require more time, so I prefer leaving it up to potential further update.
- I absolutely need all GCC 4.7 related patch (I see you have some, but
not all of them). This also applies to ruby 1.9 and libpng 1.4/1.5 .
I understand. For debian and ubuntu's patches are not yet substantial. The fact that I have some integrated and some are not, has a simple explanation - some patches were in GIT after I released the update. :)
Also, there are lots of commits by Darell to remove "More applications" from program menu, and neither you nor me have taken them. Maybe we should consider taking them.
Yes, I thought about them several times. When we think about it both equally, so it probably will be a good idea :) We will wait for GIT branch or incorporate it again each in yourself?
Slavek
Hello, I've found that the ktorrent patch "bp006-5af9907f.diff" does not apply correctly because of modified strings in some files "ktorrent.po": kde-i18n was incorrectly renamed "tde-i18n" . Since it is part of an email address, it should be reverted.
Anyway, I've had to apply a part of commit #5dcbbbba before bp006 in order to get it to work. See attached patch.
Francois
On Saturday 05 of May 2012 18:51:51 Francois Andriot wrote:
Hello, I've found that the ktorrent patch "bp006-5af9907f.diff" does not apply correctly because of modified strings in some files "ktorrent.po": kde-i18n was incorrectly renamed "tde-i18n" . Since it is part of an email address, it should be reverted.
Anyway, I've had to apply a part of commit #5dcbbbba before bp006 in order to get it to work. See attached patch.
Francois
Ha, interesting. When applying patches on Debian probably allowed more fuzzy because it applied without a hitch. But I will fix the patch to go without applying the part 5dcbbbba... corrected patch attached :)
Slavek --
Le 05/05/2012 18:51, Francois Andriot a écrit :
Hello, I've found that the ktorrent patch "bp006-5af9907f.diff" does not apply correctly because of modified strings in some files "ktorrent.po": kde-i18n was incorrectly renamed "tde-i18n" . Since it is part of an email address, it should be reverted.
Anyway, I've had to apply a part of commit #5dcbbbba before bp006 in order to get it to work. See attached patch.
Francois
Continued:
kdiff3 : the bp003 patch makes FTBFS. You must have missed a previous commit, or we can simply ignore this patch.
konversation: bp004 does not apply correctly at file "konversation/src/quickbuttons_preferences.h". You must apply commit #96f2a488 before bp004.
That's all for today :-)
On Saturday 05 of May 2012 19:40:47 Francois Andriot wrote:
kdiff3 : the bp003 patch makes FTBFS. You must have missed a previous commit, or we can simply ignore this patch.
Patch bp003 for kdiff3 depends on the patch bp036 for kdebase. It should compile kdiff3 after compiling updated kdebase.
Slavek --
On Thursday 03 of May 2012 23:51:44 Francois Andriot wrote:
Amarok: I have some FTBFS and some features added. See http://bugs.trinitydesktop.org/show_bug.cgi?id=984
I also incorporate
Arts: I have some features added. See http://bugs.trinitydesktop.org/show_bug.cgi?id=747
I also incorporate
Kdeadmin: I've just added a patch to add support for RHEL/Fedora in networkconf backend, see: See http://bugs.trinitydesktop.org/show_bug.cgi?id=619
I also incorporate
Kdebase: Too many patches to compare ! I think the only ones I have that you don't are RHEL/Fedora specific, so they won't go upstream. An important point is the famous "startkde" script. Should we try to have a stable updated script upstream, or should we keep distro-specific changes in every packaging ?
I am definitely for it to have stable upstream updated script. And to solve specific distribution in it. I do not know how big parts are the distribution specific. But I believe it would go through to resolve by the conditions, or spin-off into a separate "include".
Kdegraphics: I have some FTBFS on stock 3.5.13. See http://bugs.trinitydesktop.org/show_bug.cgi?id=984
I also incorporate
Kdelibs: You do not have patch for bugs: 656 , 764 You do not have patch for commits: 24f144fa , 2b035349
I also incorporate
Kdeutils: The "klaptopdaemon" from upstream will only work on debian/ubuntu because there is a hardcoded "dpkg" command in its source code. For all other distros, you should apply the following patch (should be upstream IMHO): http://git.trinitydesktop.org/cgit/tde-packaging/tree/redhat/kdeutils/kdeut ils-3.5.13-klaptopdaemon_dpkg_command.patch
I also incorporate
That's all what I see for now. Good job BTW :-)
Francois
Thank you for comparing patches. I have added to their packages remaining gcc-4.7 patches. And patches for reorganization of the menu. Do I have to compile and test...
Slavek --
Hey just a word ;
Too many patches to compare ! I think the only ones I have that you don't are RHEL/Fedora specific, so they won't go upstream. An important point is the famous "startkde" script. Should we try to have a stable updated script upstream, or should we keep distro-specific changes in every packaging ?
I am definitely for it to have stable upstream updated script. And to solve specific distribution in it. I do not know how big parts are the distribution specific. But I believe it would go through to resolve by the conditions, or spin-off into a separate "include".
I don't think it's too smart to have distribution specific coding in the start file. I think that would be better to keep patched in. For example this leads to legacy code when a distribution is no longer included, then you end up with lots of extraneous checks that aren't really doing anything. That is my opinion. This is just a general principle, if something is actually broken (eg there is a incorrect path) it is often because things have been hardcoded a long time ago for a single distribution or method that has changed or outdated.
I think it's best to keep distribution specific patches in our git repository tde-packaging, that was it _is_ available for anyone else to see and use, and pull in to their sources, but it's not muddying up the main tree.
Calvin
On Monday 07 of May 2012 20:48:48 Calvin Morrison wrote:
Hey just a word ;
Too many patches to compare ! I think the only ones I have that you don't are RHEL/Fedora specific, so they won't go upstream. An important point is the famous "startkde" script. Should we try to have a stable updated script upstream, or should we keep distro-specific changes in every packaging ?
I am definitely for it to have stable upstream updated script. And to solve specific distribution in it. I do not know how big parts are the distribution specific. But I believe it would go through to resolve by the conditions, or spin-off into a separate "include".
I don't think it's too smart to have distribution specific coding in the start file. I think that would be better to keep patched in. For example this leads to legacy code when a distribution is no longer included, then you end up with lots of extraneous checks that aren't really doing anything. That is my opinion. This is just a general principle, if something is actually broken (eg there is a incorrect path) it is often because things have been hardcoded a long time ago for a single distribution or method that has changed or outdated.
I think it's best to keep distribution specific patches in our git repository tde-packaging, that was it _is_ available for anyone else to see and use, and pull in to their sources, but it's not muddying up the main tree.
Calvin
I thought if it was set aside for distribution-specific code, it would in starttde could be something like:
if [-e $ TDEDIR / bin / starttde_dist] then . $TDEDIR/bin/starttde_dist fi
The starttde_dist could be that simply executes at the moment of include. Or it could be that would define the functions that would be called in starttde, where applicable - as an events.
Distribution would thus maintain its own starttde_dist.
Slavek --
I thought if it was set aside for distribution-specific code, it would in starttde could be something like:
if [-e $ TDEDIR / bin / starttde_dist] then . $TDEDIR/bin/starttde_dist fi
The starttde_dist could be that simply executes at the moment of include. Or it could be that would define the functions that would be called in starttde, where applicable - as an events.
Distribution would thus maintain its own starttde_dist.
This is a good solution
Calvin
Le 07/05/2012 22:41, Calvin Morrison a écrit :
I thought if it was set aside for distribution-specific code, it would in starttde could be something like:
if [-e $ TDEDIR / bin / starttde_dist] then . $TDEDIR/bin/starttde_dist fi
The starttde_dist could be that simply executes at the moment of include. Or it could be that would define the functions that would be called in starttde, where applicable - as an events.
Distribution would thus maintain its own starttde_dist.
This is a good solution
Calvin
Hello, to avoid being stuck with only one sub-script, I think it would be even better to have a splitted script with a ".d" subfolder or something like the "/etc/profile.d" directory .. For example: /etc/starttde.d/ It would contain any number of scripts that would be called by the main "starttde" script.
Francois
Dne čt 3. května 2012 Francois Andriot napsal(a):
About a release date, I'm not really in a hurry, since I already provide heavily patched packages for RHEL/Fedora. So TDE is already working very well and there will be no big difference between current 3.5.13 and 3.5.13.1 for the end-users.
François,
you have in the drawer next handy updates appropriate for 3.5.13? :) It's just if I have to wait to publish the next prepared update... I got to expose my current set of patches? (yet unpublished packages)
Very good work.
Slávek --
Le 09/05/2012 19:43, Slávek Banko a écrit :
Dne čt 3. května 2012 Francois Andriot napsal(a):
About a release date, I'm not really in a hurry, since I already provide heavily patched packages for RHEL/Fedora. So TDE is already working very well and there will be no big difference between current 3.5.13 and 3.5.13.1 for the end-users.
François,
you have in the drawer next handy updates appropriate for 3.5.13? :) It's just if I have to wait to publish the next prepared update... I got to expose my current set of patches? (yet unpublished packages)
Very good work.
Slávek
Hello, here are the last-minute commits I'd like to see in 3.5.13.1 (if you did not take them already) : 8ecd1080 8f79beaa 5077913f That's all for me.
Francois
Dne čt 10. května 2012 François Andriot napsal(a):
Hello, here are the last-minute commits I'd like to see in 3.5.13.1 (if you did not take them already) : 8ecd1080 8f79beaa 5077913f That's all for me.
Francois
Thank you. All I had already incorporated. Furthermore: c4050cef 2cc2e3a2 15b9ce53
and fb4308f0 e8e118e2
I'll start uploading the next update. In doing so, I also publish the current set of patches.
Slavek --
-
Calvin Morrison -
Francois Andriot -
François Andriot
-
François ANDRIOT
-
Nix -
Robert Xu -
Slávek Banko -
Timothy Pearson