All,
Working further with kmymoney, I have run across a build failure due to a
missing icon: kmymoneytitlelabel.png. The failure occurs at the end of the build
during the packaging stage:
/usr/bin/install -c -p -m 644
/build/tde-kmymoney/src/kmymoney/kmymoney2/widgets/$file
/build/tde-kmymoney/pkg/tde-kmymoney/opt/trinity/share/apps/kmymoney2/pics; \
done
/usr/bin/install: cannot stat
'/build/tde-kmymoney/src/kmymoney/kmymoney2/widgets/kmymoneytitlelabel.png': No
such file or directory
The icons is not in the tde git tree:
15:23 phoinix:/dat_e/tde/tde/main/applications/kmymoney> find . -name
kmymoneytitlelabel.png
<nothing>
The build system looks for the icon here:
kmymoney2/widgets/Makefile:689:WIDGET_PNGS = kmymoneytitlelabel.png
kmymoney2/widgets/Makefile.am:54:WIDGET_PNGS = kmymoneytitlelabel.png
kmymoney2/widgets/Makefile.in:689:WIDGET_PNGS = kmymoneytitlelabel.png
Does anyone have a patch/substitute for this icon? It is apparently triggered
when building with 'libofx' features enabled:
./configure \
--prefix=${TDEDIR} \
--with-qmake=${QTDIR}/bin/tqmake \
--with-qt-dir=${QTDIR} \
--with-qt-includes=${QTDIR}/include \
--with-qt-libraries=${QTDIR}/lib \
--with-extra-includes="/usr/include/tqt:/usr/include/tqt/Qt" \
--with-extra-libs="${TDEDIR}/lib:${TDEDIR}/lib/trinity" \
--sysconfdir=${TDEDIR}/etc \
--localstatedir=/var \
--disable-dependency-tracking \
--disable-gcc-hidden-visibility \
$enable_pdfdocs \
--enable-new-ldflags \
--enable-rpath \
--enable-ofxplugin \
--enable-ofxbanking \
--enable-qtdesigner \
--disable-sqlite3 \
--enable-qtdesigner \
--disable-debug \
--disable-final \
--enable-closure
I am tinkering with enabling more of the options after Francios confirmed he
was able to build with those options enabled. The build completed fine, the
packaging of the icon is the problem.
--
David C. Rankin, J.D.,P.E.
Here is a link to a 13 MB patch that finishes renaming tdevelop components.
http://humanreadable.nfshost.com/misc/tdevelop-kdev-tdev-rename.diff
There are no build failures or errors or warnings. I don't know how to use tdevelop but my modest tests indicates the patch is stable. You folks who use tdevelop can test more thoroughly and update the patch as needed.
Darrell
All,
This is strange. After going through initial setup of kmymoney, I get a
segfault whenever I click in the account "ledger" window. I ran it in gdb and it
disclosed the following error:
17:32 valhalla:~/bld/bld/html2ps> gdb kmymoney
GNU gdb (GDB) 7.7
<snip>
Using host libthread_db library "/usr/lib/libthread_db.so.1".
reading file
start parsing file
startDocument
reading accounts
reading transactions
reading securities
reading prices
reading reports
endDocument
Program received signal SIGSEGV, Segmentation fault.
TQObject::controlElementDataObject (this=this@entry=0x0) at kernel/qobject.cpp:120
120 kernel/qobject.cpp: No such file or directory.
Here is a screenshot of the window immediately before the crash:
http://www.3111skyline.com/dl/dt/trinity/ss/kmymoney-ledger.jpg
Clicking on any of the tabs [Deposit] [Transfer] [Withdrawal] will cause the
segfault. What does the kernel/qobject.cpp error tell us? (anything? or do we
need to rebuild with debugging enabled?) The reason for the question is I don't
know if this clearly discloses a naming issue, or if it is just the start of the
debug chain that would tell us more with debugging enabled in the build. Let me
know. Thanks.
--
David C. Rankin, J.D.,P.E.
I want to add a couple of more points to my previous email below.
1) internationalization/translation (tde-i18n) is another area where users without any programming knowlegde can help a lot
2) the contribution a person can give to TDE does not depend on his/her skills but on the amount of time he/she is willing to put it TDE. You could be the best C++ programmer of the world, but if you only contribute 5 minutes a month your contribution would be very small indeed (but not futile though). Or you could be just a normal user without any programming experience who is willing to spend a couple of hours each week on updating documentation: in such case your contribution would definitely be bigger than the best C++ programmer of the world.
So it is not about skills, it is about time.
Feel free to pass this email to the user mailing list too (I know, I should subscribe... :) )
Cheers
Michele
>> The primary reason I got frutrated yesterday is not my lack of C++
>> skills. My frutration comes from the fact that asking for coaching
>> help in this list is futile.
> Yep - amen. I'd love to learn what is required to fix the systemd
> user session tracking issue, but for me, >at this point, to sit down
> and try to follow the c++ inheritance and polymophism through
> tdelibs/tdebase to >arrive at the points in the code that need
> attention -- is -- (looking for word stronger than >futile...checking
> kthesaurus...got it!) simply absurd, cockeyed, derisory, idiotic,
> laughable, ludicrous, > nonsensical, preposterous, ridiculous --
> to the point of making "a contribution so small as to belaughable."
> You c++ guys shell out some advise and guidance and we will be more than happy to help :)
As usual, different people have different opinions, so I will give mine too.
1) Number of bugs in bugszilla
As a developer, I prefer to have "10 bugs filed and one fixed" than "1 bug filed and 1 fixed". It means we are doing a good job with testing (and that we have too little active developers :( ).
Having a list of bugs that are almost all resolved, does not mean the project is better. It means we are not testing well at all. Luckily, we have people like Darrell, David, Francois, Alex and others that constantly report any issue they find. Maybe the issue will be resolved 2 years later, but at least we know it exists. So please keep up with filing bugs :)
2) Applications in the tree
The more we have, the better. Not because we want to show to the world how many beautiful applications we have (the first comment against that would be that most of them are 3-4 years old at least), but because when we need *that* particular application for *that* particular job in *that* particular day, the application is already available in our DE. If we don't have *that* application, we need to start looking around for an application doing *that* particular job, and Murphy's laws dictates that when we need *that* particular application, we are usually already short in time :)
3) Contribution to TDE
While I understand very well the frustration of Darrell, I strongly disagree with the comments marked as ">>" and ">" at the beginning of this email. No contribution to TDE, however small it could be, is ever going to be considered "futile" or "looking for word stronger than futile...checking kthesaurus...got it!) simply absurd, cockeyed, derisory, idiotic, laughable, ludicrous, nonsensical, preposterous, ridiculous -- to the point of making a contribution so small as to be laughable."
Please remember that TDE carries on thanks to the effort of us all, not just the (few active) C++ developers.
There are tons of things that need attention.
- testing: very important, so please keep up with it :)
- documentation review: don't need to be a C++ developer to edit docs. Darrell has been doing an outstanding job with it lately. Would be good if others could help him out too.
- website review: same as for the documentation, don't need to be a C++ developer to contribute to it.
- development: yes, here you need to know some C++ :) But not all bugs are major ones, so if your skills are somehow limited, you can try to target small bugs and leave the big ones to the other developers.
TDE lives thanks to the effort of us all. Please don't give up, whether you are testing, fixing paper cut issues, reviewing docs, fixing major problems or whatever else you are doing to contribute to it.
Cheers
Michele
All,
Attachment 1958 is the completed source code that contains both patches
supplied by Francios (attachment 1944 & 1945) applied. This code is ready to be
added to the git tree under tde/main/applications. Once there, we will submit by
patch a commit to change the menu location. Who will be the one that will push
this over?
Likewise, the code for the katesort-plugin (attachment 1956) is ready to be
added to the git tree as well. This as well go to tde/main/applications.
Who will be the one that can add the sources to the tree? Let's get this done
before the 2/28 target date for R14 freeze.
--
David C. Rankin, J.D.,P.E.
All,
Given the minimization of applications in kmenu, what is the proper way to
patch kmenu during packaging to move/add certain applications back to the menu?
Currently there is no konqueror-filemanager in the menu except for the
super-user apps and I will need to add that and a few others back to the menu in
some manner. The Arch crowd is no mom & pop group and I can hear the howls:
"Where is the file manager in the menu?"
I think we should come up with some common approach for TDE that allows
packagers to easily add/move apps around in the menu at package time. This would
allow packagers to meet the needs of the users that TDE is being packaged for.
If for mom & pop, package the basic menu, if for advanced users give them a
full-featured menu. I do not want to give Arch the impression that TDE is a
stripped-down version of kde.
How best to do it? Is it best to do it at the XDG level supplying a short menu
for merging, or is it better to just copy the .desktop files out of
/opt/trinity/share/applnk/.hidden to /opt/trinity/share/applications/tde? That
could be done with a few simple lines in a build script and sed can easily alter
the categories of others.
Developing a consistent way to easily customize the menu at packaging time
seems like a simple way for packagers to better tailor TDE to their target users
while providing a standard way to do it in TDE.
I welcome your thoughts on that.
--
David C. Rankin, J.D.,P.E.
All,
Looking at .xsession_errors knemo no longer launches leaving the following error:
kded: WARNING: [KDEDModule* Kded::loadModule(const KService*, bool)] Could not
load library. [ can't open the module ]
kded: WARNING: [KDEDModule* Kded::loadModule(const KService*, bool)] Could not
load library. [ Library files for "libkded_knemod.la" not found in paths. ]
I don't know what happened, but kded is now looking for "libkded_knemod.la".
That is wrong. The library is "kded_knemod.la" in /opt/trinity/lib/trinity:
01:47 valhalla:~> l1 /opt/trinity/lib/trinity/ | grep knemo
kcm_knemo.la
kcm_knemo.so
kded_knemod.la
kded_knemod.so
I know knemo was working within the last few weeks, I used it. I don't know
when it quit exactly, but something changed. Any ideas?
--
David C. Rankin, J.D.,P.E.
All,
Looking at tdeio, I selected everything in tdedebugdialog and got the wanted
reams of output in .xsession-errors. Is there a way in ServiceManager, or
otherwise, to simply turn tdedebugdialog output ON or OFF without having to
select-all/deselect-all and then apply?
--
David C. Rankin, J.D.,P.E.
While I appreciate enthusiasm to add new apps to the repository, we should convert all new apps to cmake right away. Otherwise we just keep digging ourselves a deeper hole with cmake conversions.
Thoughts?
Darrell
The previous bugzilla version displayed a total count of a search query in the upper left corner of the page. That count total no longer appears with the new version. Can we get feature working again?
Darrell