Okay, what happened to the configure script for tdemultimedia? The file is missing.
The cmake conversion looks incomplete and there were no announcements that tdemultimedia was ported to cmake.
Darrell
I don't know if this is the git config for tde or me that is causing the git
clone of the tde tree to fail to clone the needed admin, cmake and other
submodules when doing a clone of the entire project.
I cloned using:
git clone http://drankin@scm.trinitydesktop.org/scm/git/tde
./scripts/switch_all_submodules_to_head_and_clean
I have since used:
git pull
./scripts/switch_all_submodules_to_head_and_clean
git submodule update --init
git reports the tree is up to date:
10:00 archangel:/dat_f/tde> git pull
Already up-to-date.
However, working on tqtinterface, the tqtinterface/admin and
tqtinterface/cmake directories are empty -- and tqtinterface will not build.
Comparing what I see browsing the git repository online and what I have locally,
there is no question files are missing.
For example, browsing:
http://git.trinitydesktop.org/cgit/admin/treehttp://git.trinitydesktop.org/cgit/cmake/tree
both show fully populated directories on the server. However looking at the
local copy I have after cloning -- I have nothing in either directory:
10:00 archangel:/dat_f/tde> ls -al main/dependencies/tqtinterface/{admin,cmake}
main/dependencies/tqtinterface/admin:
total 8
drwxr-xr-x 2 david david 4096 Feb 8 18:47 .
drwxr-xr-x 5 david david 4096 Feb 8 18:47 ..
main/dependencies/tqtinterface/cmake:
total 8
drwxr-xr-x 2 david david 4096 Feb 8 18:47 .
drwxr-xr-x 5 david david 4096 Feb 8 18:47 ..
How is this possible? Is it me or git? Are there other command needed to
activate the submodules after cloning the entire project and running the
switch_all_submodules_to_head_and_clean script?
Also, when I run the switch_all_submodules_to_head_and_clean script, I get the
following error:
This script can only be run from a top level git directory. Exiting...
Stopping at 'experimental'; script returned non-zero status.
Now when I try and run the update_all_submodules script, I get errors like:
fatal: Not a git repository: /dat_e/tde/.git/modules/experimental
Unable to find current revision in submodule path 'experimental'
fatal: Not a git repository: /dat_e/tde/.git/modules/main/dependencies/tqtinterface
fatal: Not a git repository: /dat_e/tde/.git/modules/main/dependencies/tqtinterface
fatal: Not a git repository: /dat_e/tde/.git/modules/main/dependencies/tqtinterface
fatal: Not a git repository: /dat_e/tde/.git/modules/main/dependencies/tqtinterface
Committing changes to /home/david/tdegit/tde
fatal: Not a git repository: /dat_e/tde/.git/modules/main/dependencies/tqtinterface
fatal: Not a git repository: /dat_e/tde/.git/modules/main/dependencies/tqtinterface
fatal: Not a git repository: /dat_e/tde/.git/modules/experimental
Unable to find current revision in submodule path 'experimental'
fatal: Not a git repository: /dat_e/tde/.git/modules/main/dependencies/tqtinterface
fatal: Not a git repository: /dat_e/tde/.git/modules/main/dependencies/tqtinterface
fatal: Not a git repository: /dat_e/tde/.git/modules/main/dependencies/tqtinterface
fatal: Not a git repository: /dat_e/tde/.git/modules/main/dependencies/tqtinterface
Committing changes to /home/david/tdegit/tde
fatal: Path 'main/dependencies/tqtinterface/cmake' is in submodule
'main/dependencies/tqtinterface'
error: pathspec 'main/dependencies/tqtinterface/cmake' did not match any file(s)
known to git.
Can I fix this, or do I just need to pull another complete copy of the tree?
--
David C. Rankin, J.D.,P.E.
Hello,
I'd like to know if there is an existing script or method to build
"official" source tarballs from git.
I need to get tarballs that "look like" the ones that are delivered for
official releases, e.g. that I can build exactly in the same way that I
build official releases tarballs.
Thanks,
Francois
Hello,
I just added UPower support into ksmserver. This meaning that
Suspend/Hibernate will be available even if HAL is not present.
To enable it, pass -DWITH_UPOWER to cmake. If HAL support is activated too,
UPOWER will be preffered.
--
Serghei.
Hi,
I think that we should just do away with the shutdown dialog. The same
task could be easily achieved via the Kicker menu. A Leave submenu
would be present and would expand to have all the options. Users would
then be prompted with a dialog box "are you sure you want to X?"
This would:
1. Allow for a streamlined and efficient interface
2. create a more consistent interface, custom dialogs are not good
because they require more code, and are more complicated for a user to
learn. The KSM functionality would not be compromised anyway, and you
could still issue the same commands to it.
3. reduce clutter in the Kicker menu by moving Lock Session, Switch
User, and Save Session to the new Leave submenu.
What do you think?
Calvin
All, Calvin,
Continuing the current discussion about kcontrol, Calvin provided a current
kcontrol layout from 3.5.13 (I don't have a post 4/11 build). Regarding kcontrol
apps that were either not in 3.5.13 or had changed names, here are current
screenshots of those that were identified as either missing or renamed from
prior versions of 3.5.10:
The Appearance/Desktop-Texts app may be in another kcontrol, but if not, we
might want to get the source from Ilya/openSuSE:
http://www.3111skyline.com/dl/dt/trinity/ss/kcontrol-App_Desktop-Texts.jpg
I think this is probably Internet & Network/Samba Status. Could you compare
and let me know:
http://www.3111skyline.com/dl/dt/trinity/ss/kcontrol-Inet_samba.jpg
The old Component Chooser seems to now be KDE Components/Default Applications:
http://www.3111skyline.com/dl/dt/trinity/ss/kcontrol-KDEcomp_CompChooser.jpg
Lastly, the Sound & Multimedia/Music Manager applet that is not in 3.5.13 is
shown here. IIRC this was originally a feature request made against Digikam some
years ago that made its way into an applet. What I have in 3.5.10 is shown here.
If this functionality sets a default in TDE regarding sound file extension case,
then I think it would be worth it to see if the source can be included. Having
some application refuse to download files except with ALL UPPER CASE EXTENSIONS
is a real drag.
http://www.3111skyline.com/dl/dt/trinity/ss/kcontrol-SoundMM_MusicManager.j…
Currently, I have the KDE 3.5.10 Original, the TDE 3.5.13 Current and my hack
and a layout with new ordering (preserving 90% of the current) laid out in a
side-by-side page that allow you to look at each and compare on the same page.
Yes, the groups/subgroups expand and contract as they do in kcontrol.
Mutantturkey, i've pushed those over tonight if you want to take a look and
confirm. Anyone else interested in helping with the kcontrol layout revisions,
take a look at: http://www.3111skyline.com/dl/dt/trinity/kcontrol/
The menu generation is by bash script, so changes are easy to prototype and
compare with the current. If anyone is interested, the script is genmen.sh in
the same directory above along with a sample data file 'mlabels-trin.txt that
the script parses to create the dtree menu layout for kcontrol.
--
David C. Rankin, J.D.,P.E.
Guys,
I don't know if this is worth looking into from a TDE standpoint or if it is
still relevant, but HAL and udev stopped the boot process on my Arch box today.
Calvin had the issue that I believe he solved by removing an offending udev
rule[1]. That raised the question to me whether there is some standardization
that HAL will require across distros in order to support TDE or if there is some
part of udev that is needed to support HAL?
Arch no longer provides HAL as a standard package. I believe what triggered
the boot fail today was the loss of the 'udev-compat' package (unconfirmed). I'm
still digging into this, but if HAL will be required for TDE, then should we
look into either insuring that a generic HAL version that is compatible with
upstream udev is available to the project?
I don't know how HAL + udev affect TDE or what the long term thoughts are on
either, but I thought I would raise the issues to those smarter than I am in
case there is a looming issue coming down the road.
What say the experts? Is there any issue with HAL + udev on TDE, or is it just
a matter of the individual distro TDE builders to sort out? What worries me is
Arch no longer packages HAL and the version we have in the user supported
repository (done by 'l0ner' -- thank you!) is hal 0.5.14-7 with a *900K patch*
file. If this is where all the distros are ultimately going, we may be better
served by deciding how to handle it now rather than waiting until we run into
build problems later...
Footnote [1]: (which we are still trying to determine exactly what he removed :)
--
David C. Rankin, J.D.,P.E.