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. 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 2 May 2012, Timothy Pearson told this: 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 2 May 2012, Timothy Pearson uttered the following: I thought you did, hence my confusion :) 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. -- NULL && (void)

On 2 May 2012, Slávek Banko told this: 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 -- NULL && (void)

Le 01/05/2012 22:09, Slávek Banko a écrit : 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 : 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/kdeut… That's all what I see for now. Good job BTW :-) Francois

On Thursday 03 of May 2012 23:51:44 Francois Andriot wrote: 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 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. :) 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 --

On Saturday 05 of May 2012 18:51:51 Francois Andriot wrote: 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 --

On Saturday 05 of May 2012 19:40:47 Francois Andriot wrote: Patch bp003 for kdiff3 depends on the patch bp036 for kdebase. It should compile kdiff3 after compiling updated kdebase. Slavek --

Hey just a word ; 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: 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 --

Le 07/05/2012 22:41, Calvin Morrison a écrit : 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

Le 09/05/2012 19:43, Slávek Banko a écrit : 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