Hi
In the user-list, I announced the state of preparation updates for 3.5.13:
http://trinity-users.pearsoncomputing.net/?0::3008
I also strongly modify the article in Etherpad. Now there is also a
current listing of included patches. This will be easier for me to keep
it up to date... and perhaps even easier for you:
http://trinity.etherpad.trinitydesktop.org/16
I would like to discuss with you whether further delay the official
release updates? I intended to add to updates all packages for which were
following patches:
- Remove additional unneeded tq method conversions
- Rename obsolete tq methods to standard names
- Rename a few stragglers
- Fix inadvertent "TQ" changes
For some packages, already contained in the update, these patches solve
tricky problems. But these patches applies to almost all the remaining
packages. Therefore, I ask if I should go into it (will take some time to
process it), or ask Tim whether to issue updates as they are ready now?
Personally, I tend to do - to release as soon as possible. Updates already
solves many errors. And that's why I find it useful to release as soon as
possible. What is your opinion?
I attach link to archive containing the current set of patches (5.4 MiB).
Maybe useful for others who prepare packages for other distributions.
http://www.axis.cz/linux/trinity-3.5.13-udpate-patches-1.tgz
Slávek
--
In the TDE menu there are two menu options named "Settings," both inherited from 3.5.10.
One Settings menu option is static and contains various items to configure application settings, not necessarily TDE related. The other Settings menu is dynamic, optional, and is related only to KControl preferences.
Having two menu options with the same name is potentially confusing.
Translations pose a challenge for renaming the static Settings menu (tdebase/applnk/tde-settingsmenu.directory). Renaming that menu option is further complicated because of XDG expectations. Renaming this menu option is best avoided.
Renaming the dynamic menu option to "Control Center" or "Preferences" seems straightforward. There are at least two files that need editing: tdebase/kicker/menuext/prefmenu/prefmenu.desktop and prefmenu.cpp. Whereas translating to "Preferences" would be a steep uphill challenge, renaming to "Control Center" is almost painless. Although not a perfect one-to-one correspondence but very close, we would use KControl.desktop to copy and repopulate the Name keys. In all, quite doable.
I don't know how renaming the dynamic menu option affects the Konqueror "settings:/" kio slave, if at all.
Thoughts? Comments?
Darrell
Tim, All,
After the discussion both here and on the suse list about the removal of HAL,
that brought up a question that I don't fully understand. I know that everyone
is moving away from HAL and that it is the way of the future, but "Why?"
Briefly - what is wrong with HAL? Is it dead upstream? Does is pose
limitations on the ability to do X or Y going forward? If so what are X or Y? Is
it udev? What?
Like Qt3, all of the past versions of KDE3 and TDE have used HAL and work
fantastically - what is the motivation for dumping it?
A short sentence or two would help me understand -- or a simply link to why if
you have one will do. Thanks, I just want to make sure I understand the issue
better...
--
David C. Rankin, J.D.,P.E.
On 05/07/2012 01:19 AM, Ilya Chernykh wrote:
> On Monday 07 May 2012 08:12:48 Carolin Liefke wrote:
>
>> I asked about that before, but you didn't comment on it - what happened to
>> this package in 12.1 since it's not in the repos?
>
> It requires hal.
The reality is there is NO 'drop-in' replacement for HAL for either openSuSE's
builds of KDE3 or TDE -- yet.
HAL will be removed from both and all of the desired functionality WILL be
preserved going forward -- BUT -- it will take time to iron all the issues out
and make the transition. HAL is tightly integrated with the core of KDE3. As a
result, moving away from HAL will take significant effort both from the gifted
developers that code the removal AND from the user-base to provide feedback and
bug reports of what does and does not work.
If we were smart, we would coordinate the transition away from HAL among all the
projects that support and develop KDE3 so that all projects can collaborate on
the effort and benefit from what has already been done. Primarily to keep from
reinventing the wheel and prevent against inconstancies being introduced by
independent solutions.
There is nothing wrong with exploring and attempting different solutions along
the way, but there should be a common road-map to insure we all end up at the
same finish line.
What are your thoughts on where/how to coordinate these efforts?
cc: trinity-devel
--
David C. Rankin, J.D.,P.E.
Tim, All,
Just updated a suse box to get the backport of the sftp fix and noticed that
Ilya (or somebody) had implemented a 2-row kicker patch that allow you to have a
2-row systray instead of a 1 row systray. This is a great space saver for
kicker. Probably only works for taskbar >= 35px since the 2-row tray uses 16px
icons. Regardless, this is a cool trick that we may want to implement in tde.
Now, instead of having to hide most of the systray icons to keep it within a
2-icon space (my preference) I can unhide everything and still take up less
space. It's a 4-for-1 space saving.
Here is a quick screenshot:
http://www.3111skyline.com/dl/dt/trinity/ss/suse-11.4-systray.jpg
Ilya, can you point us to the patch?
--
David C. Rankin, J.D.,P.E.
Guys,
Don't give this a lot of time (3.5.12 backport of sftp fix). I have kdebase
successfully configuring, but I get an early error building kate. The build
can't find kdebase/kate/app/.libs/libkdeinit_kate.so
The build is correct, it's not there. The .la and .lai files are there, but
not the .so. The .so is already on the system as /opt/kde3/lib/libkdeinit_kate.so.
I don't know if the build fail is caused by the .lai saying it is already
installed or the .la saying it isn't, or if this is just some gcc47 hiccup
that we just are not going to get past. It seems I've been hit by this issue
before, but I cannot recall for the life of me what the fix was.
There is no question that the build finds the existing lib, but then
somehow isn't doing something right. The error is:
libtool: link: ( cd ".libs" && rm -f "kwrite.la" && ln -s "../kwrite.la"
"kwrite.la" )
/bin/sh ../../libtool --tag=CXX --mode=link g++ -DNDEBUG -DNO_DEBUG
-fpermissive -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL
-DQT_NO_COMPAT -DQT_NO_TRANSLATION -D_GNU_SOURCE -o kate -R /opt/kde3/lib
-R /opt/kde3/lib -R /opt/qt/lib -R /opt/kde3/lib -no-undefined -L/opt/kde3/lib
-L/opt/qt/lib -L/opt/kde3/lib kate.la.o libkdeinit_kate.la
libtool: link: LD_RUN_PATH="/opt/kde3/lib:/opt/qt/lib:" g++ -DNDEBUG
-DNO_DEBUG -fpermissive -DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL
-DQT_NO_COMPAT -DQT_NO_TRANSLATION -D_GNU_SOURCE -o .libs/kate kate.la.o
-L/opt/kde3/lib -L/opt/qt/lib ./.libs/libkdeinit_kate.so -L/usr/lib
/home/david/tde/kdemod3/bld/kdebase/src/kdebase/kate/app/.libs/libkateinterfaces.so
/opt/kde3/lib/libkatepartinterfaces.so /opt/kde3/lib/libktexteditor.so
/opt/kde3/lib/libkabc.so /opt/kde3/lib/libvcard.so
/opt/kde3/lib/libkresources.so /opt/kde3/lib/libkparts.so
/opt/kde3/lib/libkutils.so
/home/david/tde/kdemod3/bld/kdebase/src/kdebase/kate/utils/.libs/libkateutils.so
/opt/kde3/lib/libkio.so /opt/kde3/lib/libkdeui.so /opt/kde3/lib/libkdesu.so
/opt/kde3/lib/libkwalletclient.so /usr/lib/libfam.so -lacl -lattr
/opt/kde3/lib/libkdecore.so -lart_lgpl_2 -lidn /opt/kde3/lib/libkdefx.so
-lXrender -ldl /opt/kde3/lib/libDCOP.so /opt/qt/lib/libtqt.so -lqt-mt -lpng
-lz -lXext -lSM -lICE -lpthread -lX11
g++: error: ./.libs/libkdeinit_kate.so: No such file or directory
g++: error:
/home/david/tde/kdemod3/bld/kdebase/src/kdebase/kate/app/.libs/libkateinterfaces.so:
No such file or directory
g++: error:
/home/david/tde/kdemod3/bld/kdebase/src/kdebase/kate/utils/.libs/libkateutils.so:
No such file or directory
The .libs dir has the following:
-rw-r--r-- 1 david david 936 May 2 13:14 kate_dummy.o
lrwxrwxrwx 1 david david 10 May 2 14:13 kate.la -> ../kate.la
-rw-r--r-- 1 david david 1560 May 2 14:13 kate.lai
-rw-r--r-- 1 david david 51964 May 2 14:13 katemain.o
-rw-r--r-- 1 david david 940 May 2 13:15 kwrite_dummy.o
lrwxrwxrwx 1 david david 12 May 2 14:13 kwrite.la -> ../kwrite.la
-rw-r--r-- 1 david david 1512 May 2 14:13 kwrite.lai
-rw-r--r-- 1 david david 99804 May 2 13:15 kwritemain.o
lrwxrwxrwx 1 david david 23 May 2 14:13 libkateinterfaces.la ->
../libkateinterfaces.la
-rw-r--r-- 1 david david 1216780 May 2 14:13 libkateinterfaces_la.all_cpp.o
-rw-r--r-- 1 david david 1574 May 2 14:13 libkateinterfaces.lai
lrwxrwxrwx 1 david david 26 May 2 14:13 libkateinterfaces.so ->
libkateinterfaces.so.0.0.0
lrwxrwxrwx 1 david david 26 May 2 14:13 libkateinterfaces.so.0 ->
libkateinterfaces.so.0.0.0
lrwxrwxrwx 1 david david 21 May 2 14:13 libkdeinit_kate.la ->
../libkdeinit_kate.la
-rw-r--r-- 1 david david 1587 May 2 14:13 libkdeinit_kate.lai
lrwxrwxrwx 1 david david 23 May 2 14:13 libkdeinit_kwrite.la ->
../libkdeinit_kwrite.la
-rw-r--r-- 1 david david 1537 May 2 14:13 libkdeinit_kwrite.lai
If anyone has a quick fix, I'd be glad to try it, if not, I'll just put
this on the back burner for now... IIRC this might take a makefile sed or patch..
--
David C. Rankin, J.D.,P.E.
Tim, All,
Building kipi-plugins today I received the following:
libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../..
-I../../kipi-plugins/common/include -I/opt/trinity/include
-I/opt/trinity/include -I/opt/trinity/include -I/opt/trinity/include
-I/opt/tqt3/include -I. -include tqt.h -I/opt/trinity/include/tde
-DQT_THREAD_SUPPORT -D_REENTRANT -Wno-long-long -Wundef -ansi
-D_XOPEN_SOURCE=500 -D_BSD_SOURCE -Wcast-align -Wchar-subscripts -Wall -W
-Wpointer-arith -fno-builtin -g3 -fno-inline -march=i686 -mtune=generic -O2
-pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2
-Wformat-security -Wmissing-format-attribute -Wno-non-virtual-dtor
-fno-exceptions -fno-check-new -fno-common -I/usr/include/tqt
-DQT_CLEAN_NAMESPACE -DQT_NO_ASCII_CAST -DQT_NO_STL -DQT_NO_COMPAT
-DQT_NO_TRANSLATION -MT rawdecodingiface.lo -MD -MP -MF
.deps/rawdecodingiface.Tpo -c rawdecodingiface.cpp -fPIC -DPIC -o
.libs/rawdecodingiface.o
rawdecodingiface.cpp: In member function 'bool
KIPIRawConverterPlugin::RawDecodingIface::loadedFromDcraw(const TQString&,
TQString&, KIPIRawConverterPlugin::SaveSettingsWidget::OutputFormat, const
TQByteArray&, int, int)':
rawdecodingiface.cpp:302:76: error: invalid conversion from 'char*' to
'png_const_bytep {aka const unsigned char*}' [-fpermissive]
In file included from rawdecodingiface.h:35:0,
from rawdecodingiface.cpp:65:
/usr/include/png.h:2276:1: error: initializing argument 5 of 'void
png_set_iCCP(png_structp, png_infop, png_const_charp, int, png_const_bytep,
png_uint_32)' [-fpermissive]
rawdecodingiface.cpp:309:25: warning: deprecated conversion from string
constant to 'png_charp {aka char*}' [-Wwrite-strings]
rawdecodingiface.cpp:320:100: warning: deprecated conversion from string
constant to 'char*' [-Wwrite-strings]
rawdecodingiface.cpp:324:92: warning: deprecated conversion from string
constant to 'char*' [-Wwrite-strings]
rawdecodingiface.cpp: In member function 'long int
KIPIRawConverterPlugin::RawDecodingIface::formatStringList(char*, size_t,
const char*, va_list)':
rawdecodingiface.cpp:660:55: warning: function might be possible candidate for
'gnu_printf' format attribute [-Wmissing-format-attribute]
rawdecodingiface.cpp: In member function 'bool
KIPIRawConverterPlugin::RawDecodingIface::loadedFromDcraw(const TQString&,
TQString&, KIPIRawConverterPlugin::SaveSettingsWidget::OutputFormat, const
TQByteArray&, int, int)':
rawdecodingiface.cpp:481:59: warning: ignoring return value of 'size_t
fwrite(const void*, size_t, size_t, FILE*)', declared with attribute
warn_unused_result [-Wunused-result]
I was thinking Darrell already had a patch for this that allowed it to
build w/o -fpermissive. This might just be one of the -fpermissive issues that
needs fixing. Anybody know if a patch exists for this on gcc 4.7?
--
David C. Rankin, J.D.,P.E.
> Darn. I was running out the door when I wrote that; I'll try to get
something better to you later.
> All of these crashes appear to be the result of a TQString passed by
reference from katerenderer.cpp that is disappearing before it is fully
processed.
> Tim
Try the attached patch please. :-)
Tim
Tim, Darrell, All,
tdelibs is the package that causes the kwrite/kate/etc.. crash when built on
gcc 47. The backtrace is good this time and points to:
at (i=<optimized out>, this=<optimized out>) at /opt/tqt3/include/ntqstring.h:641
641 { return i < d->len ? d->unicode[i] : TQChar::null; }
(full backtrace below)
This last night/this morning I build gcc 4.6 and gcc 4.7 packages from 5/3 GIT
sources. The test was as follows (removing ksycoca between each):
(1) I installed the gcc 4.6 packages -- no crash occurred.
(2) installed tqt3 built on gcc 4.7 -- no crash occurred.
(3) uninstalled tqt3, reinstalled tqt3 built on gcc 4.6
(4) installed tdelibs built on gcc 4.7 -- kwrite CRASH
** Note: tdelibs built on gcc 4.7 is 9.64 MIB larger than when built on gcc 4.6
A summary of the test is in the following chart:
tqt3-46 tdelibs-46 tdebase-46 tqt3-47 tdelibs-47 tdebase-47
tqt3-46 -- OK OK ++ CRASH no test
tdelibs-46 OK -- OK OK ++ no test
tdebase-46 OK OK -- OK CRASH ++
FULL BACKTRACE:
at (i=<optimized out>, this=<optimized out>) at /opt/tqt3/include/ntqstring.h:641
641 { return i < d->len ? d->unicode[i] : TQChar::null; }
(gdb) bt
#0 at (i=<optimized out>, this=<optimized out>) at
/opt/tqt3/include/ntqstring.h:641
#1 operator[] (this=<optimized out>, i=<optimized out>) at
/opt/tqt3/include/ntqstring.h:642
#2 width (tabWidth=<optimized out>, italic=<optimized out>, bold=<optimized out>,
col=<optimized out>, text=..., this=<optimized out>)
at /build/src/tdelibs/kate/part/katefont.h:67
#3 width (tabWidth=<optimized out>, col=<optimized out>, text=..., fs=...,
this=<optimized out>)
at /build/src/tdelibs/kate/part/kateattribute.h:55
#4 KateRenderer::textWidth (this=0x22fc280, textLine=..., startcol=0, maxwidth=817,
needWrap=0x7fff8df70e98, endX=0x7fff8df70e8c)
at /build/src/tdelibs/kate/part/katerenderer.cpp:797
#5 0x00007fe5ae37f674 in KateViewInternal::range (this=this@entry=0x23fa0c0,
realLine=realLine@entry=0, previous=previous@entry=0x0)
at /build/src/tdelibs/kate/part/kateviewinternal.cpp:1331
#6 0x00007fe5ae380b32 in KateViewInternal::range (this=this@entry=0x23fa0c0,
realLine=0,
viewLine=viewLine@entry=1) at
/build/src/tdelibs/kate/part/kateviewinternal.cpp:1418
#7 0x00007fe5ae3824c9 in KateViewInternal::viewLineOffset
(this=this@entry=0x23fa0c0,
virtualCursor=..., offset=0, keepX=keepX@entry=false)
at /build/src/tdelibs/kate/part/kateviewinternal.cpp:1578
#8 0x00007fe5ae385d25 in KateViewInternal::makeVisible
(this=this@entry=0x23fa0c0, c=...,
endCol=117, force=force@entry=false, center=center@entry=false,
calledExternally=calledExternally@entry=false)
at /build/src/tdelibs/kate/part/kateviewinternal.cpp:781
#9 0x00007fe5ae386352 in KateViewInternal::updateCursor (this=this@entry=0x23fa0c0,
newCursor=..., force=force@entry=true, center=center@entry=false,
calledExternally=calledExternally@entry=false)
at /build/src/tdelibs/kate/part/kateviewinternal.cpp:2204
#10 0x00007fe5ae38a4c0 in KateViewInternal::editEnd (this=0x23fa0c0,
editTagLineStart=0,
editTagLineEnd=<optimized out>, tagFrom=<optimized out>)
at /build/src/tdelibs/kate/part/kateviewinternal.cpp:3385
#11 0x00007fe5ae326ef0 in KateDocument::editEnd (this=0x232f2c0)
at /build/src/tdelibs/kate/part/katedocument.cpp:1032
#12 0x00007fe5ae320f5b in KateDocument::paste (this=0x232f2c0, view=0x24352e0)
at /build/src/tdelibs/kate/part/katedocument.cpp:3249
#13 0x00007fe5ae358a53 in KateView::paste (this=0x24352e0)
at /build/src/tdelibs/kate/part/kateview.cpp:1597
#14 0x00007fe5ae388102 in KateViewInternal::mouseReleaseEvent (this=0x23fa0c0,
e=0x7fff8df71920)
at /build/src/tdelibs/kate/part/kateviewinternal.cpp:2965
#15 0x00007fe5b424b0b3 in TQWidget::event (this=0x23fa0c0, e=0x7fff8df71920)
at kernel/qwidget.cpp:4725
#16 0x00007fe5b41b5f9d in TQApplication::internalNotify (this=0x7fff8df71ff0,
receiver=0x23fa0c0,
e=0x7fff8df71920) at kernel/qapplication.cpp:2638
#17 0x00007fe5b41b5627 in TQApplication::notify (this=0x7fff8df71ff0,
receiver=0x23fa0c0,
e=0x7fff8df71920) at kernel/qapplication.cpp:2424
#18 0x00007fe5b5177894 in KApplication::notify (this=0x7fff8df71ff0,
receiver=0x23fa0c0,
event=0x7fff8df71920) at /build/src/tdelibs/tdecore/kapplication.cpp:583
#19 0x00007fe5b4148e59 in TQApplication::sendSpontaneousEvent (receiver=0x23fa0c0,
event=0x7fff8df71920) at kernel/ntqapplication.h:526
#20 0x00007fe5b4142735 in TQETWidget::translateMouseEvent (this=0x23fa0c0,
event=0x7fff8df71ce0)
at kernel/qapplication_x11.cpp:4380
#21 0x00007fe5b414005d in TQApplication::x11ProcessEvent (this=0x7fff8df71ff0,
event=0x7fff8df71ce0) at kernel/qapplication_x11.cpp:3557
#22 0x00007fe5b415b2c8 in TQEventLoop::processEvents (this=0x2272f90, flags=4)
at kernel/qeventloop_x11.cpp:195
#23 0x00007fe5b41c9118 in TQEventLoop::enterLoop (this=0x2272f90) at
kernel/qeventloop.cpp:201
#24 0x00007fe5b41c8fe9 in TQEventLoop::exec (this=0x2272f90) at
kernel/qeventloop.cpp:148
#25 0x00007fe5b41b60cd in TQApplication::exec (this=0x7fff8df71ff0) at
kernel/qapplication.cpp:2761
#26 0x00007fe5b84f1448 in kdemain (argc=1, argv=0x7fff8df72688)
at /build/src/tdebase/kate/app/kwritemain.cpp:692
#27 0x00000000004007a4 in main (argc=1, argv=0x7fff8df72688)
at /build/src/build/kate/app/kwrite_tdeinit_executable.cpp:2
(gdb)
I think this should help isolate where the crash is coming from. I will need
to punt to the experts. This backtrace seems to point to the crash in kate/part,
but I don't understand why it is blowing up in tqt3. That's where you experts
will have to figure it out.
Let me know if you want additional tests. I have my box set up for it now, so
all you have to do it tell me what to run. Let's get this bug squashed and R14
will be the best and most up-to-date release ever!
--
David C. Rankin, J.D.,P.E.