On 07/28/2012 01:05 PM, Darrell Anderson wrote:

kde-config was renamed to tde-config after 3.5.13:

http://git.trinitydesktop.org/cgit/tdelibs/log/tdecore/tde-config.cpp.in

The solution then is the configure/make files should be looking for kde-config, unless slavek backported the name change to 3.5.13.1.

Darrell

Thank you Darrell!

I knew we nicked our own Achilles tendon when we went on the massive k->t rename. For graphics, etc. that are user seen it was a needed part of the normal progression of the desktop, but for unseen checks and items that do not conflict with kde4, we really need to think ahead and make sure we are not shooting ourselves in the foot. From a build system standpoint, accept for upstream changes, we should be able to build TDE 3.5.12, 3.5.13 and R14 without our naming system interjecting incompatibilities into the build.

I'll play with this and see if I can't come up with and conditional or pre-processor type check on the version number to use the right kde-config or tde-config, because it just seems like something like that should be simple. I'll have to look, because I can't explain why 70% of the sru branch built and 30% failed based on this tde-config/kde-config issue. But I'm completely encouraged by how well 3.5.13 built.

On 07/28/2012 07:31 PM, Slávek Banko wrote:

On Saturday 28 of July 2012 19:58:24 David C. Rankin wrote:

...

All,

Aside from the obvious (no tde-config), what is being checked for that causes this type of initial build failure. I am seeing it in several applications (abakus, amarok, etc..). This is with the 3.5.13-sru branch files. Obviously tde-config is present as tdelibs, tdebase, etc.. have built without issue. So anybody familiar with some check that will need to be adjusted to fix these? I'll dig into them, but if you have and idea -- let me know :)

To build packages that yet not have v3.5.13-sru branch, should be taken from their original v3.5.13, not the current git. You can use tag v3.5.13 for checkout: git checkout v3.5.13

I promise I will try to complete as soon as possible v3.5.13-sru branch to remaining packages, where it is useful. And also to 'tde'.

Slavek

No problem,

It is working really good. It's just filling in the holes with the correct files :) Let me know if I can do anything to help you.

On 29 Jul 2012, David C. Rankin outgrape:

22:30 archangel:/dat_f/tde/tde/main/applications/kbookreader> git branch -l

• master

You have new mail in /var/mail/david 16:21 archangel:/dat_f/tde/tde/main/applications/kbookreader> git branch -r origin/HEAD -> origin/master origin/master 16:21 archangel:/dat_f/tde/tde/main/applications/kbookreader> git checkout v3.5.13 warning: unable to rmdir admin: Directory not empty warning: unable to rmdir cmake: Directory not empty Note: checking out 'v3.5.13'.

Do you have a dirty working tree with stuff in the admin and cmake directories? git will refuse to remove them in that case, to avoid losing your work (though the pointless warning looks like a git bug).

You are in 'detached HEAD' state. You can look around, make experimental changes and commit them, and you can discard any commits you make in this state without impacting any branches by performing another checkout.

If you want to create a new branch to retain commits you create, you may do so (now or later) by using -b with the checkout command again. Example:

git checkout -b new_branch_name

HEAD is now at 12476d8... Link most Trinity DSOs against the most common kdelibs libraries to compensate for linking changes in modern distributions such as Ubuntu Oneiric

It looks like since it is a 'tag' and not a 'branch', git checkout won't work.

Uh, not only did it work, it told you it worked. You can check out *any* commit at all as a new branch, including commits referenced by refs such as branches or tags. But if you check out a tag without creating a new branch off of it, git will warn you, as above, that if you commit at this point and then switch away, your commit is pointed to by nothing and thus will eventually be lost (not at once -- the reflog will point to it for a while, but reflogs are routinely expired by automated 'git gc' runs, so your commit will eventually vanish).

(This state is called 'detached HEAD', because HEAD (which always points to your current checkout) is not pointing to the same place as the head of any branch, thus 'detached' from all branches.)

On 30 Jul 2012, David C. Rankin outgrape:

I think I got it! So I need to create the local branch v3.5.13-sru and then checkout 3.5.13 into that. (or whatever new name I dream up for the branch :)

Normally one creates the new branch straight from the remote-tracking branch, like so:

git branch v3.5.13-sru whatever-remote-name/v3.5.13-sru

though if your branch has the same name on the local and remote ends, there is a shortcut:

git checkout --track v3.5.13-sru

(where '--track' means 'this branch remains associated with the remote-tracking branch, and pushes and pulls go to it or come from it by default).

Personally, I never use this shortcut: branching and checking out are completely different operations, and it is not helpful to confuse the two. Also, 'git checkout --track BLAH' isn't actually much shorter than 'git branch BLAH remote/BLAH', and 'git branch' has the right defaults (i.e. making a tracking branch is automatic and you have to ask for the opposite).

Also, the 'git checkout' shorthand tends to cause the misconception I see above in new users, that branches are some sort of concrete thing into which you check out code. It is not so. All a branch is is a name: a pointer to a commit which is moved onto any new commit you make on top of that one: the growing tip of some line of development. The name of the branch is completely evanescent: nobody else ever sees it (except perhaps in default commit messages when merging): in particular it doesn't get wired into commits like in Mercurial, or into the filesystem like in Subverison.

This is actually very powerful, because it means branches are really free (not just 'free' in the Subversion sense of 'they don't cost much to create'). Want to create five hundred branches under script control and mess about with each one? Easy! Want to preserve your current state because you're about to do some history-rewriting or something and are scared of messing up? 'git branch a-backup-branch' and now nothing can disturb that backup (since git commits are tied to the *contents* of all their parents, history rewriting must necessarily create *new* commits, while a-backup-branch points to the old one, unaffected).

Many of us old git hands do *all* our significant development on temporary branches ('feature branches' because they often track the addition of some feature), doing a 'git rebase' on those branches whenever we want to catch up with work on our development trunk (also a local branch, but one untouched except for jobs so small they can be done in one commit), then merging at the end (and because it's rebased, that merge is seamless and undetectable to outsiders). e.g. we do this

master -> A -> B -> C \ temp-branch - my work -> more work

Now some complete bastard comes along and does *other* work, imagine it. We pull into our trunk with a simple 'git pull', leaving us with this:

master -> A -> B -> C -> D -> E \ temp-branch - my work -> more work

Now, on the temp branch, when we decide we want to catch up with what other people have done (and make any necessary changes to our code), a simple 'git rebase master' gives us:

master -> A -> B -> C -> D -> E \ temp-branch - my work -> more work

(If there are any conflicts with the new work D and E, git stops in the middle of the rebase and lets us fix it. If we're scared that there will be a lot of conflicts and things might get too hairy to untangle, we can just use 'git branch temp-branch-backup' to make a backup branch of temp-branch before we rebase it, or make a backup branch and rebase *that* -- there is no difference between the two.)

Now, when it comes time to merge, the 'merge' is utterly trivial. There's no change in the commit graph at all, just in a couple of labels:

master -> A -> B -> C -> D -> E -> my work -> more work

This is an *incredibly* powerful workflow, enormously better than the conventional workflow in other version control systems of working in master and coping with conflicts, or working on a branch and periodically merging from the master branch and *hoping* that things work out.