Hi.
If I remember correctly there was someone who was writing instructions
for BLFS book on compiling and getting to work TDE on LFS. I remember
using those instructions while writing PKGBUILDs for arch, since those
instructions were nicely detailed. I wanted to look at them, now that
I'm trying to compile TDE on my Gentoo installation.
But now they have vanished and I can't find them anywhere.
Any hopes on mirrors or direct contact with the person that was
writing them?
l0ner
Hi folks,
I will be pushing patches to update docbook related files. The
reason for the changes is to avoid potential conflicts with files
of the same name in KDE4 as reported in bug report 1446. These
patches affect GIT main trunk only.
The core of the changes are to the common/admin directory and
renaming files in tdelibs, although many modules are affected by
this renaming.
The changes to the common/admin files is the reason for this notice
because the main servers have to replicate those changes to all
other submodules. Updating your entire local GIT repository during
this period could mean build failures.
I tested the patches with full build runs and found no problems.
All help handbooks compile and work as expected.
From a user perspective nobody will notice any differences. These
patches only affect compiling.
I plan to push the patches after posting this message. Before
updating your local repository, please allow ample time for the
main servers to replicate the changes in common/admin to all
modules --- usually performed overnight.
After resyncing your local repository, a simple test to verify all
files have updated correctly is to grep your entire local
repository for kde-chunk.xsl. There are other changes too, but
there should be no such occurrences because the file is being
renamed to tde-chunk.xsl and all internal references as well.
Please let me know here should you notice build failures or
problems related to the help handbook (docbbook) files. Probably a
good idea to spot check the handbooks after installing updated
packages. :)
Thanks!
Darrell
List of all affected modules:
common:
-------
admin
base:
-----
tdelibs
tdebase
tdevelop
libraries:
----------
kipi-plugins
libkdcraw
libkexiv2
libkipi
libksquirrel
libtqt-perl
applications:
-------------
adept
basket
bibletime
compizconfig-backend-kconfig
digikam
dolphin
filelight
filelight-l10n
gwenview-i18n
k3b-i18n
kaffeine
katapult
kbarcode
kbookreader
kchmviewer
kcmautostart
kcpuload
kdiff3
kdirstat
kdpkg
keep
kerry
kile
kiosktool
kmplayer
kmyfirewall
kmymoney
knemo
knetload
knetstats
knights
knowit
knutclient
koffice
koffice-i18n
konversation
kopete-otr
kpicosim
kpowersave
kpowersave-nohal
krename
krusader
ksplash-engine-moodin
ksquirrel
ksystemlog
ktechlab
ktorrent
kuickshow
kvkbd
kvpnc
piklab
potracegui
smb4k
soundkonverter
tde-systemsettings
tdeio-apt
tdeio-umountwrapper
tderadio
tdesudo
tdmtheme
tellico
twin-style-crystal
yakuake
tde-i18n:
---------
tde-i18n
On Tue, 16 Apr 2013 12:53:25 -0500 "Calvin Morrison"
<mutantturkey(a)gmail.com> wrote:
>Hmmm, that works correctly.
How about file-picker dialogs, such as opening a file in kate?
Darrell
>I was thinking a little bit different way - for example:
>
>[R14 XDG Updates]
>Updated=R14.0.0
>
>or (maybe better - can cover also changes during development
>versions and also easier for comparison in shell)
>
>[R14 XDG Updates]
>Updated=20130407
>
>Where timestamp is not date of the conversion for user, but the
>internal date of r14-xdg-update script, which make conversion.
Makes sense. Or use the time stamp of tdelibs/tdecore/tdeversion.h
or TDE_VERSION_STRING from tdeversion.h
Darrell
>This is from the quickbuild nightly builds on quantal (might be an
>issue as well)
Could be.
What happens when you press F4 to open konsole in the respective
directory and then type the ls command?
Darrell
>> What happens in icon view?
>
>The icons appear, but no text.
>
>Also the system menu in kicker is blank, icons but no file names.
Rings a bell. I checked the bug tracker and found nothing. Found
nothing in the mail list archives.
Who built the packages?
Darrell
>I have one small suggestion. Script r14-xdg-update writes to the
>configuration key Updated. If the script could contain internal
>version
>number (or timestamp), it could to key Updated write this value
>and then
>this value use to decide whether to execute again or not.
>
>Such solution could cover any subsequent updates. And it would not
>depend on testing the specific renamed files. What do you think?
Sounds like a good idea.
I never envisioned needing the script long-term, but I'm horrible
at predicting the future. Hopefully by the time R15 is the main
trunk in GIT we no longer need the script. Until then, perhaps we
should embrace your suggestion. :)
Currently we use the following:
[R14 XDG Updates]
Updated=true
Perhaps change that to:
[R14 XDG Updates]
R14.0.0-Updated=true
If we do that then what mechanism do we use in the script itself to
track this? I'm thinking of corner cases such as a user updates
from 3.5.13.1 to R14.0.2 or something like that. Corner cases
always ruin parties. :)
Darrell
