7 Oct
2012
7 Oct
'12
2:45 a.m.
Darrell,
I looked at the commit 58823f36, and I propose to adjust sanity checks so that
instead of binaries existence check the existence of configuration file.
For example: I had previously installed Krita => I have configuration. But at
this moment I have not installed Chalk => configuration is not converted.
When I install Chalk later, the configuration will be missing.
In addition, testing tdeprint based on the /opt/trinity/include/tdeprint is
not appropriate. I have installed package tdeprint-trinity,
but /opt/trinity/include/tdeprint not exists. This is a part of package
tdelibs-trinity-dev.
Slavek
--
7 Oct
7 Oct
3:40 a.m.
New subject: [trinity-devel] Sanity checks to the migratekde3 (commit 58823f36)
I looked at the commit 58823f36, and I propose to
adjust
sanity checks so that instead of binaries existence check the existence of
configuration file.
For example: I had previously installed Krita => I have
configuration. But at this moment I have not installed Chalk => configuration
is not converted. When I install Chalk later, the configuration will be
missing.
In addition, testing tdeprint based on the
/opt/trinity/include/tdeprint is not appropriate. I have installed package
tdeprint-trinity,
but /opt/trinity/include/tdeprint not exists. This is a part
of package tdelibs-trinity-dev.
How about this:
diff -urN tdebase/migratekde3 tdebase.new/migratekde3
--- tdebase/migratekde3 2012-09-29 01:35:28.000000000 -0500
+++ tdebase.new/migratekde3 2012-10-06 22:38:01.000000000 -0500
@@ -320,32 +320,32 @@
fi
echo "Renaming various configuration files and directories."
# Don't force renaming in case this cript is used to update an existing Trinity
profile.
- if [ -f $TDEDIR/bin/chalk ]; then
+ if [ -f $HOME/.trinity/share/config/kritarc ] || [ -d $HOME/.trinity/share/apps/krita
]; then
echo " krita->chalk"
mv $HOME/.trinity/share/config/kritarc $HOME/.trinity/share/config/chalkrc
2>/dev/null
mv $HOME/.trinity/share/apps/krita $HOME/.trinity/share/apps/chalk 2>/dev/null
fi
- if [ -d /opt/trinity/include/tdeprint ]; then
+ if [ -f $HOME/.trinity/share/config/kdeprintrc ] || [ -d
$HOME/.trinity/share/apps/kdeprint ]; then
echo " kdeprint->tdeprint"
mv $HOME/.trinity/share/config/kdeprintrc $HOME/.trinity/share/config/tdeprintrc
2>/dev/null
mv $HOME/.trinity/share/apps/kdeprint $HOME/.trinity/share/apps/tdeprint
2>/dev/null
fi
- if [ -f $TDEDIR/bin/tdesu ]; then
+ if [ -f $HOME/.trinity/share/config/kdesurc ]; then
echo " kdesurc->tdesurc"
mv $HOME/.trinity/share/config/kdesurc $HOME/.trinity/share/config/tdesurc
2>/dev/null
fi
- if [ -f $TDEDIR/bin/tdevelop ]; then
+ if [ -f $HOME/.trinity/share/config/kdeveloprc ]; then
echo " kdevelop->tdevelop"
mv $HOME/.trinity/share/config/kdeveloprc $HOME/.trinity/share/config/tdeveloprc
2>/dev/null
fi
- if [ -f $TDEDIR/bin/twin ]; then
+ if [ -f $HOME/.trinity/share/config/kwinrc ] || [ -d
$HOME/.trinity/share/apps/kwinrulesrc ]; then
echo " kwin->twin"
mv $HOME/.trinity/share/config/kwinrc $HOME/.trinity/share/config/twinrc
2>/dev/null
mv $HOME/.trinity/share/config/kwinrc.eventsrc
$HOME/.trinity/share/config/twinrc.eventsrc 2>/dev/null
mv $HOME/.trinity/share/config/kwinrc $HOME/.trinity/share/config/twinrc
2>/dev/null
mv $HOME/.trinity/share/apps/kwinrulesrc $HOME/.trinity/share/apps/twinrulesrc
2>/dev/null
fi
- if [ -f $TDEDIR/bin/twin4 ]; then
+ if [ -f $HOME/.trinity/share/config/kwin4rc ]; then
echo " kwin4->twin4"
mv $HOME/.trinity/share/config/kwin4rc $HOME/.trinity/share/config/twin4rc
2>/dev/null
fi
Darrell
3:51 a.m.
New subject: [trinity-devel] Sanity checks to the migratekde3 (commit 58823f36)
How about this:
That patch will not help.
Whereas krita was renamed to chalk before 3.5.13 was released, the others were not renamed
until after 3.5.13. Thus, renaming those respective config files for 3.5.13 or 3.5.13.1
users will make things worse. After I posted the patch I remembered that is why why I
tested the existence of the executables.
The patch for krita/chalk probably is safe. For tdeprint, rather than test for the include
file because Debian separates user and developer files, the next best test probably is [
-d $TDEDIR/share/apps/tdeprint].
Darrell
4:04 a.m.
New subject: [trinity-devel] Sanity checks to the migratekde3 (commit 58823f36)
That patch will not help.
Whereas krita was renamed to chalk before 3.5.13 was
released, the others were not renamed until after 3.5.13.
Thus, renaming those respective config files for 3.5.13 or
3.5.13.1 users will make things worse. After I posted the
patch I remembered that is why why I tested the existence of
the executables.
The patch for krita/chalk probably is safe. For tdeprint,
rather than test for the include file because Debian
separates user and developer files, the next best test
probably is [ -d $TDEDIR/share/apps/tdeprint].
How about this:
diff -urN tdebase/migratekde3 tdebase.new/migratekde3
--- tdebase/migratekde3 2012-09-29 01:35:28.000000000 -0500
+++ tdebase.new/migratekde3 2012-10-06 23:01:41.000000000 -0500
@@ -320,32 +320,32 @@
fi
echo "Renaming various configuration files and directories."
# Don't force renaming in case this cript is used to update an existing Trinity
profile.
- if [ -f $TDEDIR/bin/chalk ]; then
+ if [ -f $HOME/.trinity/share/config/kritarc ] || [ -d $HOME/.trinity/share/apps/krita
]; then
echo " krita->chalk"
mv $HOME/.trinity/share/config/kritarc $HOME/.trinity/share/config/chalkrc
2>/dev/null
mv $HOME/.trinity/share/apps/krita $HOME/.trinity/share/apps/chalk 2>/dev/null
fi
- if [ -d /opt/trinity/include/tdeprint ]; then
+ if [ -d $TDEDIR/share/apps/tdeprint ] && [ -f
$HOME/.trinity/share/config/kdeprintrc ] || [ -d $HOME/.trinity/share/apps/kdeprint ];
then
echo " kdeprint->tdeprint"
mv $HOME/.trinity/share/config/kdeprintrc $HOME/.trinity/share/config/tdeprintrc
2>/dev/null
mv $HOME/.trinity/share/apps/kdeprint $HOME/.trinity/share/apps/tdeprint
2>/dev/null
fi
- if [ -f $TDEDIR/bin/tdesu ]; then
+ if [ -f $TDEDIR/bin/tdesu ] && [ -f $HOME/.trinity/share/config/kdesurc ];
then
echo " kdesurc->tdesurc"
mv $HOME/.trinity/share/config/kdesurc $HOME/.trinity/share/config/tdesurc
2>/dev/null
fi
- if [ -f $TDEDIR/bin/tdevelop ]; then
+ if [ -f $TDEDIR/bin/tdevelop ] && [ -f $HOME/.trinity/share/config/kdeveloprc
]; then
echo " kdevelop->tdevelop"
mv $HOME/.trinity/share/config/kdeveloprc $HOME/.trinity/share/config/tdeveloprc
2>/dev/null
fi
- if [ -f $TDEDIR/bin/twin ]; then
+ if [ -f $TDEDIR/bin/twin ] && [ -f $HOME/.trinity/share/config/kwinrc ] || [ -d
$HOME/.trinity/share/apps/kwinrulesrc ]; then
echo " kwin->twin"
mv $HOME/.trinity/share/config/kwinrc $HOME/.trinity/share/config/twinrc
2>/dev/null
mv $HOME/.trinity/share/config/kwinrc.eventsrc
$HOME/.trinity/share/config/twinrc.eventsrc 2>/dev/null
mv $HOME/.trinity/share/config/kwinrc $HOME/.trinity/share/config/twinrc
2>/dev/null
mv $HOME/.trinity/share/apps/kwinrulesrc $HOME/.trinity/share/apps/twinrulesrc
2>/dev/null
fi
- if [ -f $TDEDIR/bin/twin4 ]; then
+ if [ -f $TDEDIR/bin/twin4 ] && [ -f $HOME/.trinity/share/config/kwin4rc ];
then
echo " kwin4->twin4"
mv $HOME/.trinity/share/config/kwin4rc $HOME/.trinity/share/config/twin4rc
2>/dev/null
fi
Darrell
2:20 p.m.
New subject: [trinity-devel] Sanity checks to the migratekde3 (commit 58823f36)
On Sunday 07 of October 2012 06:04:04 Darrell Anderson wrote:
> That patch will not help.
>
> Whereas krita was renamed to chalk before 3.5.13 was
> released, the others were not renamed until after 3.5.13.
> Thus, renaming those respective config files for 3.5.13 or
> 3.5.13.1 users will make things worse. After I posted the
> patch I remembered that is why why I tested the existence of
> the executables.
>
> The patch for krita/chalk probably is safe. For tdeprint,
> rather than test for the include file because Debian
> separates user and developer files, the next best test
> probably is [ -d $TDEDIR/share/apps/tdeprint].
I've combined your patch with my modification. Instead of renaming based
on the existence of binaries, I introduced a variable TDE_REBRAND.
What do you think about it?
Slavek
--
5:33 p.m.
New subject: [trinity-devel] Sanity checks to the migratekde3 (commit 58823f36)
I've combined your patch with my modification.
Instead of
renaming based on the existence of binaries, I introduced a variable
TDE_REBRAND.
What do you think about it?
Looks fine to me. Go ahead and push. :)
I was concerned about using tde-config because of the original bugs that created profile
directories in the system root or in the user's $HOME. Looking at the 3.5.13.1 change
log indicates the related patches were backported to 3.5.13.1 in kde-config, so I think
we're safe.
If somebody is using 3.5.10 - 3.5.13, the original kde-config will not have been patched,
but with the migratekde3 patching these config file renaming snippets will not execute
anyway. Further, previously I added a snippet to use konqueror to determine the version
rather than kde-config for those older Trinity versions.
I still have my 3.5.10 profiles, which I use to test migratekde3. I don't have 3.5.11
-> 3.5.13 profiles. Hopefully before R14 is released others with those previous Trinity
versions will have tested migratekde3.
We have to be careful to keep migratekde3 and r14-xdg-update unique. They serve two
different purposes and we don't want overlap. For example, my recent patch to support
Quanta Plus plugins.rc in r14-xdg-update. That involved renaming but the renaming occurred
in the R14 development.
Darrell
6:33 p.m.
New subject: [trinity-devel] Sanity checks to the migratekde3 (commit 58823f36)
On Sunday 07 of October 2012 19:33:47 Darrell Anderson wrote:
Pushed in GIT hash ad8633f6.
I understand - in startkde is also instead of kde-config used konqueror.
Also I understand the reasons to keep a separate script for migration
from KDE3 and migration XDG.
I have another suggestion for change. During the search in the profile is
treated, they are not searched folders in kmail/mail. But the same is
necessary for folders dimap, imap and also autosave. On the folder
kmail/search I'm not sure. Proposed patch attached.
Next, I wanted to ask whether we can assume the presence of xargs on the
users machines? It can in the replacement lower overhead of repeated
execution sed and thus increase the speed. For example:
find $HOME/.trinity \
-path $HOME/.trinity/share/apps/kmail/autosave -prune -o \
-path $HOME/.trinity/share/apps/kmail/dimap -prune -o \
-path $HOME/.trinity/share/apps/kmail/imap -prune -o \
-path $HOME/.trinity/share/apps/kmail/mail -prune -o \
-path $HOME/.trinity/share/apps/kmail/search -prune -o \
-type f -print0 | \
xargs -r0 sed -i "s|/opt/kde/|${TDEDIR}/|g"
Instead of launching many sed, how much will be files, can be run only one
sed, which will process all files that are found.
What is your opinion on this?
Slavek
--
I've
combined your patch with my modification. Instead of
renaming based on the existence of binaries, I introduced a variable
TDE_REBRAND.
What do you think about it?
Looks fine to me. Go ahead and push. :)
I was concerned about using tde-config because of the original bugs
that created profile directories in the system root or in the user's
$HOME. Looking at the 3.5.13.1 change log indicates the related patches
were backported to 3.5.13.1 in kde-config, so I think we're safe.
If somebody is using 3.5.10 - 3.5.13, the original kde-config will not
have been patched, but with the migratekde3 patching these config file
renaming snippets will not execute anyway. Further, previously I added
a snippet to use konqueror to determine the version rather than
kde-config for those older Trinity versions.
I still have my 3.5.10 profiles, which I use to test migratekde3. I
don't have 3.5.11 -> 3.5.13 profiles. Hopefully before R14 is released
others with those previous Trinity versions will have tested
migratekde3.
We have to be careful to keep migratekde3 and r14-xdg-update unique.
They serve two different purposes and we don't want overlap. For
example, my recent patch to support Quanta Plus plugins.rc in
r14-xdg-update. That involved renaming but the renaming occurred in the
R14 development.
Darrell
8:01 p.m.
New subject: [trinity-devel] Sanity checks to the migratekde3 (commit 58823f36)
I have another suggestion for change. During the
search in
the profile is treated, they are not searched folders in kmail/mail. But
the same is necessary for folders dimap, imap and also autosave. On the
folder kmail/search I'm not sure. Proposed patch attached.
I have no problem with excluding imap folders but I can't test because I don't use
imap.
Next, I wanted to ask whether we can assume the
presence of
xargs on the users machines? It can in the replacement lower overhead of
repeated execution sed and thus increase the speed. For example:
find $HOME/.trinity \
-path $HOME/.trinity/share/apps/kmail/autosave -prune -o \
-path $HOME/.trinity/share/apps/kmail/dimap -prune -o \
-path $HOME/.trinity/share/apps/kmail/imap -prune -o \
-path $HOME/.trinity/share/apps/kmail/mail -prune -o \
-path $HOME/.trinity/share/apps/kmail/search -prune -o \
-type f -print0 | \
xargs -r0 sed -i "s|/opt/kde/|${TDEDIR}/|g"
Instead of launching many sed, how much will be files, can
be run only one sed, which will process all files that are found.
What is your opinion on this?
If xargs on all systems is a safe presumption then I have no problem with that either. I
should make more use of xargs in my own habits. Just lazy. :)
If your testing of the imap and xarg changes work on your system, I say go ahead and push
the patch. I can test the xargs part here.
Darrell
11:56 p.m.
New subject: [trinity-devel] Sanity checks to the migratekde3 (commit 58823f36)
On Sunday 07 of October 2012 22:01:20 Darrell Anderson wrote:
Apart from KMail imap folders I added several other folders that contain user
data - see commit in GIT hash f88add0a.
Change to use xargs I will send soon as a separate commit.
Slavek
--
I have another
suggestion for change. During the search in
the profile is treated, they are not searched folders in kmail/mail. But
the same is necessary for folders dimap, imap and also autosave. On the
folder kmail/search I'm not sure. Proposed patch attached.
I have no problem with excluding imap folders but I can't test because I
don't use imap.
Next, I wanted to ask whether we can assume the
presence of
xargs on the users machines? It can in the replacement lower overhead of
repeated execution sed and thus increase the speed. For example:
find $HOME/.trinity \
-path $HOME/.trinity/share/apps/kmail/autosave -prune -o \
-path $HOME/.trinity/share/apps/kmail/dimap -prune -o \
-path $HOME/.trinity/share/apps/kmail/imap -prune -o \
-path $HOME/.trinity/share/apps/kmail/mail -prune -o \
-path $HOME/.trinity/share/apps/kmail/search -prune -o \
-type f -print0 | \
xargs -r0 sed -i "s|/opt/kde/|${TDEDIR}/|g"
Instead of launching many sed, how much will be files, can
be run only one sed, which will process all files that are found.
What is your opinion on this?
If xargs on all systems is a safe presumption then I have no problem with
that either. I should make more use of xargs in my own habits. Just lazy.
:)
If your testing of the imap and xarg changes work on your system, I say go
ahead and push the patch. I can test the xargs part here.
Darrell
9 Oct
9 Oct
3:10 p.m.
New subject: [trinity-devel] Sanity checks to the migratekde3 (commit 58823f36)
On 7 Oct 2012, Darrell Anderson said:
If xargs on all systems is a safe presumption
To a first approximation, nothing will work without xargs: it's in
POSIX and GNU coreutils. If distributors are leaving out core parts of a
working Unix system I don't think Trinity can be expected to run on
them.
(Any non-embedded distributor will be utterly certain to include it.
Heck, Android has a copy.)
--
NULL && (void)
4226
days inactive
4228
days old
9 comments
3 participants
participants (3)
-
Darrell Anderson -
Nix -
Slávek Banko