Dne Monday 22 of October 2012 21:41:45 jste napsal(a):
> On Monday 22 of October 2012 21:36:31 Francois Andriot wrote:
> > >> I show the following in my package sets:
> > >>
> > >> kbabel.png:
> > >> tdeartwork, tdesdk
> > >>
> > >> ktimemon.png:
> > >> tdeartwork, tdeaddons
> > >>
> > >> Darrell
> > >
> > > Yes, we have the same files - Debian binary packages are more
> > > granulary. I will update the installation, to be installed in only one
> > > of these packages. The question is, from which package?
> > >
> > > a) All from tdearwork
> > > b) From tdeaddons and tdesdk
> > > c) None of the above => another interesting idea :)
> > >
> > > Slavek
> >
> > I think the locolor icons should go with the package that provides the
> > "index" for the locolor theme.
> > Without the index installed, the icons are useless.
> > I believe the package providing locolor index is tdeartwork.
> >
> > Francois
>
> François, absolutely perfect note!
> The decision was made :)
>
> Thank you.
>
> Slavek
It's a little complicated. Icons are installed in the standard way (automake
as well as cmake) == automatically installs all variants of the icon that are
available. It appears that there are three possible solutions:
1) Remove locolor icon.
2) Rename icon or move to a subfolder.
3) Skip icon during packaging in individual distributions.
Any other ideas?
Which solution seems preferable?
Slavek
--
Some favorable comments here about Trinity:
http://lxer.com/module/forums/t/33920/
Folks are looking for 3.5.13.1 RPM packages but the Trinity web site has no links.
I recall reading Francois had made RPM packages for several distros. Where are the links on the web page?
Darrell
Hi all,
With commit e5a2da23 showed few duplicate locolor icons:
tdeartwork-theme-icon-trinity:
opt/trinity/share/icons/Locolor/16x16/apps/kbabel.png
opt/trinity/share/icons/Locolor/16x16/apps/ktimemon.png
opt/trinity/share/icons/Locolor/32x32/apps/kbabel.png
opt/trinity/share/icons/Locolor/32x32/apps/ktimemon.png
kicker-applets-trinity:
opt/trinity/share/icons/locolor/32x32/apps/ktimemon.png
opt/trinity/share/icons/locolor/16x16/apps/ktimemon.png
kbabel-trinity:
opt/trinity/share/icons/locolor/32x32/apps/kbabel.png
opt/trinity/share/icons/locolor/16x16/apps/kbabel.png
I have a very simple question is: From which package exclude their
installation? I'd recommend installing with the tdeartwork and exclude from
tdeaddons and tdesdk. What is your opinion?
Slavek
--
Been a long time since we discussed gcc hidden visibility for symbols. Last I remember, this was supported in (T)Qt3, arts, tdelibs, and tdebase.
I tried building my normal package suite with this option enabled in every package. Some packages built but ignored the configure option. Some failed to build. Some built and there were no messages at all about the option.
Removing the option from the failure group allowed the packages to build.
For the latter group, as no errors or build failures occurred, I presume the option is supported.
Still, is this a good idea? I read a bit about the topic and the information is way over my head. The only thing I do understand is using the option is supposed to reduce libary size and improve loading speeds.
Darrell
Tim, I pushed patches for koffice and kmymoney to update Q_ENUMS->TQ_ENUMS.
They both failed to build last night during my build run.
Both now build.
Darrell
I built my normal package set on Oct. 15. Today I can't. My local tree is current.
The failure messages with tdebindings:
x_16.cpp:5632: error: ISO C++ forbids initialization in array new
x_16.cpp:5632: error: no matching function for call to 'TQStyleControlElementGenericWidgetData::TQStyleControlElementGenericWidgetData(TQStyleControlElementGenericWidgetData [4])'
x_16.cpp:5656: error: expected primary-expression before '[' token
x_16.cpp:5656: error: expected primary-expression before ')' token
x_16.cpp:5656: error: expected ';' before 'x'
Looking at the commits since Oct. 15 I see f209ff4b, which has code that matches the failure messages.
x_16.cpp, which is generated during the build, has #include <ntqstyle.h>.
After rebuilding tqt3, /opt/trinity/include/ntqstyle.h includes class TQStyleControlElementGenericWidgetData.
How do we fix?
Darrell
Latest R14.
Would somebody please confirm this behavior?
Run crashtest.
Save the backtrace.
Open the file with kate or kwrite. Open directly from within or through konqueror.
On my dual core system with SATA II drives, opening a *.kcrash file takes more than a minute to open, creating the impression the app has stalled or locked.
Thanks.
Darrell
I'm trying to resolve bug report 1040 with respect to amarok not building with cmake.
Under normal conditions, the build always fails with the following:
/dev/shm/amarok/amarok/src/amarokcore/amarokdcophandler.cpp:914: error: 'ScriptManager' has not been declared
/dev/shm/amarok/amarok/src/amarokcore/amarokdcophandler.cpp:919: error: 'ScriptManager' has not been declared
/dev/shm/amarok/amarok/src/amarokcore/amarokdcophandler.cpp:924: error: 'ScriptManager' has not been declared
I concluded that amarokdcophandler.cpp was not finding scriptmanager.h, which is in the parent directory.
As a test, I copied scriptmanager.h to the same directory as amarokdcophandler.cpp. The build failures disappeared and the package built.
Seems that amarok/amarok/src/amarokcore/CMakeLists.txt needs to be fixed but I don't know what to do.
Thanks much!
Darrell
Darrell,
I have updated the bug tracker to automatically add you to the CC
list, and I have just added you as a CC for all current bugs. It may
take several minutes to complete that operation but should go through
fine.
Anyone else need bugzilla related things?
Calvin