>uugh... I was really trying to avoid that. I'll have to find my
>notes how to
>move tde git from machine-to-machine (changing some tags in
>.git/... so that
>they will re-sync from the other boxes when git pull is run. (I
>have my tde &
>tde_3.5.13 on multiple-boxes for building. Oh well, that will
>teach me to let
>the repos get so stale..
Not that misery loves company, :) but about two weeks ago I had all
kinds of git problems. Check the mail list archives. Basically I
wasted an entire Saturday fixing everything. I still don't know the
root cause why everything blew up. "Oh, but wait, git is free/libre
software and Linus is a god --- please roll over in the mud. Then
pee all over yourself and pretend your happy!" ;)
Darrell
>Adding main/thirdparty/libreoffice/3.3.2/patches/libreoffice-
>trinity-debian.diff
>Adding main/thirdparty/libreoffice/3.3.2/patches/NOTES
>CONFLICT (directory/file): There is a directory with name
>main/thirdparty in
>HEAD. Adding main/thirdparty as
>main/thirdparty~023b18ec6b52629d8666d284152f6147af098595
>Auto-merging main/tdewebdev
>CONFLICT (submodule): Merge conflict in main/tdewebdev
>Auto-merging main/tdevelop
>CONFLICT (submodule): Merge conflict in main/tdevelop
>Auto-merging main/tdeutils
>CONFLICT (submodule): Merge conflict in main/tdeutils
>Auto-merging main/tdetoys
>...
>
>The concern I have is I get those CONFLICT messages even if I re-
>run the script
>after it completes. Is there some magic git command I should run
>to resolve the CONFLICT?
I never have seen those errors and I'm the last person around here
to ask for help with git. I hate git. Yet Another Overly
Complicated Tool Created By Masochistic Geeks Intended Only for
Masochistic Geeks. :)
I hold my breath every time I resync my local tree.
My guess is you are seeing those errors because your local tree is
long out-of-date. Perhaps delete each affected CONFLICT module and
then run the switch_all_submodules_to_head_and_clean script. Yeah,
again and again. Or, consider deleting the entire local tree and
perform a git clone --- overnight because the repo is 5.5 GB or so.
tde-i18n is the biggest pig module of them all and will take the
longest.
Darrell
>Additionally,
>
> I have hit numerous fatal errors running the
>switch_all_submodules_to_head_and_clean script. Examples:
>I have had similar failures with:
>
>kdmtheme
>kio-apt
>kio-locate
>kio-umountwrapper
>networkmanager9
All of those modules have been renamed.
>I guess these have all been removed from the tree, but is there a
>way to tell git to just erase them and keep going instead of
failing?
After you manually update the
switch_all_submodules_to_head_and_clean script all modules should
update correctly, which will include removing the old modules and
pulling the renamed modules.
Darrell
Tim, all,
After a hiatus, I was updating my tde repos to see how horribly screwed I am
attempting to build on Arch after their LSB and systemd changes. Pulling head I
noted several new branch and tag names. I know what they are, but they look like
they have added origin as a path component to 3.5.13-sru, etc.. Specifically, I saw:
From http://scm.trinitydesktop.org/scm/git/tde
+ 8303efe...6fd6395 master -> origin/master (forced update)
* [new branch] v3.5.13-sru -> origin/v3.5.13-sru
So it looks like v3.5.13-sru is now origin/v3.5.13-sru. The question that
brought up was "do I need to modify any of the scripts I use that update my
local git repo to handle the 'origin/v3.5.13-sru' designation, or will the
change be handled by the .gitmodule data?
Additionally, there were new tags noted:
ec1d9d9..9ec64b2 master -> origin/master
5ae82a0..169c39a v3.5.13-sru -> origin/v3.5.13-sru
* [new tag] v3.5.13.1 -> v3.5.13.1
* [new tag] v3.5.13.2 -> v3.5.13.2
Same question, is there anything I would need to change in my existing
checkout scripts such as:
git submodule foreach --recursive "git checkout v3.5.13-sru"
to reflect the new branch or tag designations? Like:
git submodule foreach --recursive "git checkout origin/v3.5.13-sru"
Also, if there are any new links or pointers for building 3.5.13 on bleeding
edge distros like Arch, I would appreciate them as well.
What is the state of HAL requirements? I presume it is still fully required in
3.5.13, but what about 14? I will be building 3.5.13, so I'll start by checking
on the state of HAL in the Arch user repository.
Thanks for any help you can give :)
--
David C. Rankin, J.D.,P.E.
>Is it still actual?
>Anyway... for future generations... the syntax is:
>
>Exec=@CMAKE_VARIABLE@
>
>The desktop file is supposed to have ".cmake" extension.
>In CMakeLists.txt use configure_file() statement.
>
>You can use e.g. tdebase/kdesktop/kdesktop.desktop.cmake as an
>example...
Thank you. As Slavek mentioned, I did learn how to do this. The
challenge now is remembering. :)
Darrell
>I assume that the scale will help to Darrell, and there is no need
>to change
>the default font size. By the way, I sometimes adjusts to 85%.
You must have a very large monitor. I have a 19" wide screen.
Between the newly discovered magnifier option and browser fonts, I
now have something --- acceptable.
I notice the past many years an obsession by software and web site
developers to use the smallest damn fonts possible. I presume the
real problem is people using TVs for computer monitors and never
testing anything on a standard desktop monitor.
I notice the etherpad does not remember my magnification setting.
Is there a way to preserve that?
Darrell
All,
What are the latest versions of various upstream packages that
Trinity supports and compiles?
Packages such as gcc, glibc, automake, cmake, libpng, cups, ffmpeg,
etc.
I am asking because I am updating the R14 press release draft. The
more recent the list the better.
Thank you! :-)
Darrell
All,
Is there anything I or we can do to increase the font sizes in
etherpad? I'm not talking about hitting the browser page size
button a bazillion times to completely distort the whole page.
The fonts sizes are just too damn small.
Thanks.
Darrell
All,
I want to create a patch that modifies two *.desktop files during
compile time. What is the correct syntax to use for the cmake
variable in the *.desktop files?
For example:
Exec=%CMAKE_VARIABLE%
Thanks. :-)
Darrell
>Ok... I'll add both my patches there too... I suppose the further
>discussion will take place there...
Good idea because all of this is way over my head. :)
Darrell