...

On 03/09/2012 07:36 AM, David C. Rankin wrote:

...

Tim,

tdewebdev build fine from sources from 4 days ago, but now fails to build due to the following:

`QExtFileInfo::enter_loop()': qextfileinfo.cpp:(.text+0x1edf): undefined reference to `tqt_enter_modal(TQWidget*)' qextfileinfo.cpp:(.text+0x1ef7): undefined reference to `tqt_leave_modal(TQWidget*)'

What did you break? Do you want me to write a bug or do you want to look at it first? Full error below:

I just confirmed that this is a new error. I used an older tdewebdev source from 3/6 and the build completed just fine.

Is there a new bug? Or... Is this a "go back and rebuild tqtinterface" issue?

-- David C. Rankin, J.D.,P.E.

It is probably related to changes that went in a few days ago, but as of right now Darrell's commits overwrote some of my commits and it will take me a few days at least to figure out what happened and untangle it.

Darrell, please, please update your source trees with 'git pull' before committing changes. :-) Apparently GIT was not smart enough to merge both of our rather large commits without losing some of the changes.

Tim

UPDATE: GIT is actually smart enough it seems, but it is taking many hours for it to merge everything correctly. I wish I could upgrade that server...

Tim

On 03/09/2012 10:48 AM, Darrell Anderson wrote:

BTW, my previous link includes a patch for tdewebdev. David, please test!

Will do. How long should I wait before I pull & test?

On 03/09/2012 12:59 PM, Darrell Anderson wrote:

...

...

BTW, my previous link includes a patch for tdewebdev.

David, please test!

Will do. How long should I wait before I pull & test?

You can use any of them right now. I have built tdewebev with the patch. Tim will need to review the patches to verify my fixes are correct. :)

I ran across the same failure with tdevelop as with tdewebdev, but I can't fix with the same patch. That's why Tim will need to review to verify the patches.

Sorry Tim! I'm trying but I'm no tqt expert!

Darrell

When I pull this next set up updates, do I need to build tqtinterface and then everything after that again? Or, can I just rebuild tqtinterface and not everything else?

On 03/09/2012 02:23 PM, Darrell Anderson wrote:

Rebuild from scratch. :)

Darrell

Glad I took the time to write a 'one-shot' build script that does it for me :)

On 03/09/2012 03:39 PM, Darrell Anderson wrote:

...

Glad I took the time to write a 'one-shot' build script that does it for me :)

Yes, I have a master script too. :)

Darrell

Should I start at tqt3 or tqtinterface?

On 03/09/2012 03:39 PM, Darrell Anderson wrote:

...

Glad I took the time to write a 'one-shot' build script that does it for me :)

Yes, I have a master script too. :)

Darrell

Darrell, all:

I have my build scripts here. They are rough, but you might find some nuggets hidden in them. Likewise, I wouldn't mind taking a peek at how you are doing things either:

The scripts are:

bldtde.conf # common config file bldtde.sh # build beginning to end script bt.sh # build single module (will add flags to bldtde.sh to do this)

They are located here:

http://www.3111skyline.com/dl/dt/tde/scr/

On 03/09/2012 04:09 PM, Darrell Anderson wrote:

...

I have my build scripts here. They are rough, but you might find some nuggets hidden in them. Likewise, I wouldn't mind taking a peek at how you are doing things either:

http://humanreadable.nfshost.com/sdeg/trinity_desktop.htm

Darrell

Nice page. Now..., I guess I should actually organize my stuff into something 'humanreadable' as well :0

I just finished 'unroughing' my scripts enough to run end-to-end and have kicked off the build. It will build through the following:

# array for Archlinux specific dependencies (remote sources) declare -a archdeps archdeps=('hal-info' 'hal' 'libutempter')

## array of TDE modules to build (source from local GIT tree tarballs) declare -a tbo tbo=("dependencies/$useqt" 'dependencies/tqtinterface' 'dependencies/arts' 'dependencies/dbus-tqt' 'dependencies/dbus-1-tqt' 'dependencies/tqca-tls' 'dependencies/libart-lgpl' 'dependencies/avahi-tqt' 'dependencies/libcaldav' 'dependencies/libcarddav' 'tdelibs' 'tdebase')

# 'tdebindings' # 'tdeaccessibility' # 'tdeutils' # 'tdemultimedia' # 'tdenetwork' # 'tdeadmin' # 'tdeartwork' # 'tdegames' # 'tdetoys' # 'tdeedu' # 'tdegraphics' # 'tdevelop' # 'tdeaddons' # 'tdepim' # 'tdewebdev' # 'tdesdk'

Crap! I forgot to add tdegraphics, tdevelop & tdewebdev back into the tbo array!!! Oh well -- that's the way it goes -- I ain't touching it right now.

It's in TQt3 right now so the loop transition with all the installs and repo updates have worked ;-)

On 9 Mar 2012, Timothy Pearson told this:

UPDATE: GIT is actually smart enough it seems, but it is taking many hours for it to merge everything correctly.

This makes no sense, I'm afraid. git merging is done on the client side, always, and at pull time, never at push time (really at 'git merge' time, which is the second of two steps carried out by 'git pull').

Pushing never does a merge of any kind. You can only push on top of a remote branch containing content you haven't pulled if you do a push -f, and that *deletes* the content you haven't pulled (hence the need for a -f 'force' argument).

On 9 Mar 2012, Darrell Anderson spake thusly:

...

Pushing never does a merge of any kind. You can only push on top of a remote branch containing content you haven't pulled if you do a push -f, and that *deletes* the content you haven't pulled (hence the need for a -f 'force' argument).

What then is the correct way to push patches? Is this correct?

cd [module] git pull merge patches to module git commit -a git push

That's unpleasant to use: if that merge fails, you have no choice but to resolve the conflicts yourself, and you can't tell what sort of mess the system might make doing the working-tree merge. That's the CVS approach, where all pulls are fraught with fear because you don't know what might get dropped on top of your work, but you *do* know you'll have to clean up the mess before you do anything else.

Generally,

git branch working-branch write code commit -a write code commit -a git checkout master git pull git merge working-branch git push git branch -d working-branch # if you're done with this change

is the recommended git workflow for nontrivial changes. This leads to a tree looking like

A -- B -- C -- D -- E -- [merge] \ / --- a -- b -- c -------- (this was 'working-branch')

(where a, b, and c are commits you wrote, and B, C, D, and E are commits written upstream).

This lets you work on multiple changes in parallel, insulated from changes to upstream until *you* decide you want to adapt to them.

But, if you don't want to use a working branch, you can just say

write code commit -a write code commit -a git checkout master git pull # resolve conflicts git push

which has the effect of producing the same shape of tree without needing any sort of branch.

You can even say

git branch working-branch write code commit -a write code commit -a git checkout master git pull git checkout working-branch # more write/commit, more pulls from master # hmm, it's been a while, I've pulled from master several times, I want # to make this branch depend on whatever is master *now* git rebase master # now 'working-branch' is based on the tip of 'master' again, just as # if you branched from master one second ago and then did all your work # with the aid of a time machine. Test it, and then... git checkout master git merge working-branch git push

and now you'll find that there is no merge commit at all: everything is linear again, with the caveat that if there are any conflicts in *any* of your intervening while 'git rebase' is running, you have to fix them up one by one, with 'git rebase --continue' in between. (It warns you if you have to do this, and you can give up with 'git rebase --abort' and undo the whole thing.)

(In recent versions of git, 'git pull --rebase' will give you this workflow whenever you pull, if you don't want to use a branch.)

...

On 9 Mar 2012, Timothy Pearson told this:

...

UPDATE: GIT is actually smart enough it seems, but it is taking many hours for it to merge everything correctly.

This makes no sense, I'm afraid. git merging is done on the client side, always, and at pull time, never at push time (really at 'git merge' time, which is the second of two steps carried out by 'git pull').

Pushing never does a merge of any kind. You can only push on top of a remote branch containing content you haven't pulled if you do a push -f, and that *deletes* the content you haven't pulled (hence the need for a -f 'force' argument).

-- NULL && (void)

Not quite. I recognized some problems in GIT that could cause issues, so I wrote "babysitting" software that constantly combs through the GIT tree, making sure that all submodule references are up to date with the latest code and similar housekeeping tasks. That babysitting software can and does trigger commits to the tree, and it is these fixup commits that are taking a long time to carry out.

Whatever Darrell did would have effectively wiped out my changes if it weren't for the babysitting code. :-)

Tim

Oh, and I forgot to mention: you can in fact push to a tree that contains content that you have not pulled, and do it without deleting anything. :-) I and others have done it many times, and you can see the results here: http://git.trinitydesktop.org/cgit/tde-packaging/log/

Each one of those "Merge branch 'master' of http://scm.trinitydesktop.org/scm/git/tde-packaging" was initiated and computed on the server, not on the client, as a direct result of pushing to a tree that was newer on the server than it was on the client. This is actually one of GIT's strengths; the fact that multiple developers can work on their own local branches, and then GIT can merge them all together in a project's master repository at a later date.

Tim

Ah, nevermind, it looks like those merges are done transparently on the client side. Sorry for the noise; GIT is a very complex system that I do not have a complete grasp of (and I suspect most people don't either). :-)

So that leaves the main server resources being utilized for: 1.) Submodule babysitting, due to GIT not having a "real" remote submodule feature like SVN does 2.) Patchset generation

Both of those are CPU and disk intensive operations.

Okay, so a significant issue is the server response. Nonetheless, what is the/your preferred way to push patches? Is this correct?

cd [module] git pull [merge patches to module] git commit -a git push

Darrell

...

Okay, so a significant issue is the server response.

Nonetheless, what is

...

the/your preferred way to push patches? Is this

correct?

...

cd [module] git pull [merge patches to module] git commit -a git push

Yes, or this also works: cd [module] [merge patches to module] git pull git commit -a git push

Okay, so perform a git pull before the git commit.

The main problem that seems to have been caused by your last commits was silent rejection of a few of my commits at the push stage. This problem was difficult to hunt down due to GIT's rather opaque error messages.

Is everything going to be okay? All of my patches last night were resolving branding issues.

Moral of the story: GIT can be a royal pain at times. :-)

I already knew that. Designed by a geek for geeks. Screw everybody else. :)

Darrell

Back to the original topic. I was able to patch tdewebdev and the package built. My patch is here:

http://humanreadable.nfshost.com/trinity/patches/tqt-fixes/

Unfortunately, tdevelop and tdepim suffer from the same failure:

/dev/shm/tdevelop/lib/util/blockingkprocess.cpp:100: error: 'qt_enter_modal' was not declared in this scope /dev/shm/tdevelop/lib/util/blockingkprocess.cpp:102: error: 'qt_leave_modal' was not declared in this scope

/dev/shm/tdepim/kresources/lib/kcal_resourcegroupwarebase.cpp:221: error: 'qt_enter_modal' was not declared in this scope /dev/shm/tdepim/kresources/lib/kcal_resourcegroupwarebase.cpp:223: error: 'qt_leave_modal' was not declared in this scope

I am unable to resolve the errors with a similar patch. I particularly wanted tdepim to build so I can test where the libkcal headers get installed, to possibly resolve a related bug report.

Darrell

On 9 Mar 2012, Timothy Pearson stated:

...

Not quite. I recognized some problems in GIT that could cause issues, so I wrote "babysitting" software that constantly combs through the GIT tree, making sure that all submodule references are up to date with the latest code and similar housekeeping tasks. That babysitting software can and does trigger commits to the tree, and it is these fixup commits that are taking a long time to carry out.

Looks like that needs a bit of optimization. I can have a look at it and see if there's a faster way to do the same thing, if you like. (And if the code is publically visible.)

-- NULL && (void)

99% of the time is spent waiting for GIT to return from these commands: 'git pull' 'git reset --hard HEAD' 'git commit -a'

That last one especially eats up a lot of resources, but I have found no other way to commit changes to a submodule reference to the parent tree.

Tim

...

I just confirmed that this is a new error. I used an

older tdewebdev

...

source from 3/6 and the build completed just fine.

It is probably related to changes that went in a few days ago, but as of right now Darrell's commits overwrote some of my commits and it will take me a few days at least to figure out what happened and untangle it.

Darrell, please, please update your source trees with 'git pull' before committing changes. :-) Apparently GIT was not smart enough to merge both of our rather large commits without losing some of the changes.

git pull BEFORE pushing. Okay. :) Sorry!

Just to help, here are the patches I have created to fix recent tqt issues. I'm still building my entire package set, so check this location regularly for new or updated patches.

http://humanreadable.nfshost.com/trinity/patches/tqt-fixes/

The patch I created to fix the KControl privacy picture selection is here:

http://humanreadable.nfshost.com/trinity/patches/tdebase/tdebase-pick-pictur...

Although the patch works, somebody with C++ experience should check and ensure the solution is good.

My humble newbie apologies. :(

Darrell