tde-devels

devels@trinitydesktop.org

5 participants
3805 discussions

Adding new API/ABI features to TDE
by Darrell Anderson 30 Mar '12

30 Mar '12

In the Commit Patches web page is the following patch: [tdelibs] Add initial tdehardwaredevices skeleton to tdecore Do not use the added classes yet, as the API and ABI are still under heavy construction! The work on tdehardwaredevices is important to remove the dependency on HAL. Yet skeleton or not, could we please NOT push any API/ABI changes until after R14? Pushing eventual API/ABI changes will create hardships, especially something as monumental as removing HAL dependencies. As important as that might seem, the bug tracker receives very little attention. Are we developing a reputation of ignoring bug reports? David and I seem to be the only ones actively trying to squash build issues. Obvious from the messages we post is there are many build related issues that need attention. David and I post a lot of build related questions to this list and frequently nobody answers. Many build related bug reports have been filed and remain untouched. Not to mention a few hundred unanswered bug reports regarding usability. According to a previous discussion, the math indicates that we won't resolve many bugs before R14 is released. That implies we are going to push R14 on schedule --- buggy. Now that we have news about a significant customer using Trinity (LiMux project in Munich), should we be making every effort to quash a significant portion of the bugs and release an R14 that all users relish and even want to join us to help develop further? We sure could use that kind of extra help and publicity. Darrell

6 10

Re: [trinity-devel] Seeking python expertise
by Leandro Nini 30 Mar '12

30 Mar '12

> > > Building kstreamripper is broken because the python build script can't parse the new TDE versioning scheme and looks for kde-config rather than tde-config. > > I tried fixing things but fell short and filed bug report 946: > > http://bugs.pearsoncomputing.net/show_bug.cgi?id=946 > > I don't think the changes need be prolific. If you have any python experience you probably can make the changes in short order. > > As always am I ready to test any patches. > Not a Python expert but you can try this: tde_version = os.popen("tde-config --version|grep TDE").read().strip().split()[1] tde_major = tde_version.split('.')[0].lstrip('R') tde_minor = tde_version.split('.')[1] tde_patch = tde_version.split('.')[2] if int(tde_major) != 14: print RED + tde_version print RED + "Your tde version can be too old" + NORMAL print RED + "Please make sure tde is at least R14.0" + NORMAL else: print GREEN + tde_version + NORMAL -- Leandro -- Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it: http://www.email.it/f Sponsor: Vuoi fare un regalo davvero originale? Su MisterCupido.com puoi crearlo tu! Personalizza con le tue foto: quadri, tazze, puzzle, cuscini, peluche... Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=11450&d=20120330 -- Caselle da 1GB, trasmetti allegati fino a 3GB e in piu' IMAP, POP3 e SMTP autenticato? GRATIS solo con Email.it http://www.email.it/f Sponsor: Offerta speciale: a partire da soli Euro 18.90 puoi stampare le tue Foto su vera Tela Pittorica e creare Quadri fino a 80x50 cm! Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=11453&d=30-3

2 1

mlt++ can only build without compiling 'test' files (Makefile patch required)
by David C. Rankin 30 Mar '12

30 Mar '12

All, The current mlt++ source Makefile requires that the 'test' directory be compiles as part of the build. This fails on Arch. I have disabled the build of the 'test' dir files with: sed -i '/\$(MAKE) -C test \$@/d' Makefile Is there any reason they should be built by the current Makefile to begin with? Isn't that something that is normally done by the user AFTER the package is installed? Since the 'test' Makefile requires -lmlt++ and that lib isn't installed until the package is installed - this will cause a build failure every time. -- David C. Rankin, J.D.,P.E.

2 3

mlt - assembler error have_mmx.S: Assembler messages: Error: operand type mismatch for `push'
by David C. Rankin 30 Mar '12

30 Mar '12

Guys, Strange build failure with libraries/mlt. It fails with an assembler error that I know nothing about: cc -march=x86-64 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -Wall -fPIC -DPIC -O4 -pipe -fomit-frame-pointer -ffast-math -DUSE_MMX -g -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -pthread -Wall -fPIC -DPIC -O4 -pipe -fomit-frame-pointer -ffast-math -DUSE_MMX -g -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -pthread -Wall -fPIC -DPIC -O4 -pipe -fomit-frame-pointer -ffast-math -DUSE_MMX -g -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -pthread `pkg-config gtk+-2.0 --cflags` `pkg-config gdk-pixbuf-2.0 --cflags` `pkg-config pangoft2 --cflags` -I../.. -c -o producer_pango.o producer_pango.c cc -o have_mmx.o -c have_mmx.S have_mmx.S: Assembler messages: have_mmx.S:20: Error: operand type mismatch for `push' have_mmx.S:24: Error: invalid instruction suffix for `pushf' have_mmx.S:25: Error: invalid instruction suffix for `pop' have_mmx.S:28: Error: invalid instruction suffix for `push' have_mmx.S:29: Error: invalid instruction suffix for `popf' have_mmx.S:30: Error: invalid instruction suffix for `pushf' have_mmx.S:31: Error: invalid instruction suffix for `pop' have_mmx.S:51: Error: invalid instruction suffix for `pop' Does this mean I'm missing a library that it needs. I can't ready the assembler code for nothing, so I hope so. What's the trick? -- David C. Rankin, J.D.,P.E.

4 9

Seeking python expertise
by Darrell Anderson 30 Mar '12

30 Mar '12

Building kstreamripper is broken because the python build script can't parse the new TDE versioning scheme and looks for kde-config rather than tde-config. I tried fixing things but fell short and filed bug report 946: http://bugs.pearsoncomputing.net/show_bug.cgi?id=946 I don't think the changes need be prolific. If you have any python experience you probably can make the changes in short order. As always am I ready to test any patches. Thanks! Darrell

1 0

*intermittent* sip4-tqt build failure on first try ( /usr/bin/flex: Unrecognized option `W' )
by David C. Rankin 30 Mar '12

30 Mar '12

All, GIGO right - computers, given the same input should produce the same output every time. If it's garbage in it's garbage out. The build of sip4-tqt seems to violate that adage. When attempt to build sip4-tqt (the first time/randomly), I get a failure: gcc -c -march=i686 -mtune=generic -O2 -pipe -fstack-protector --param=ssp-buffer-size=4 -D_FORTIFY_SOURCE=2 -I/usr/include/tqt -I/opt/trinity/include -I/opt/tqt3/include -O2 -w -DNDEBUG -I. -o parser.o parser.c lex -Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu -t lexer.l > lexer.c /usr/bin/flex: Unrecognized option `W' Try `flex --help' for more information. make[1]: *** [lexer.c] Error 1 make[1]: Leaving directory `/build/src/sipPy3/sipgen' make: *** [all] Error 2 The only 'W' that could be causing the error is the LDFLAGS string '-Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu', but that hasn't caused a problem before so I just issue the build command again - and it builds without issue - WTF? Looking at the lex command above I see: lex -Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu -t lexer.l > lexer.c That doesn't seem right. I don't know lex from fred, passing 'lex ${LDFLAGS} -t lexer.l > lexer.c' doesn't seem right because there is no '-Wl,-O1,--sort-common,--as-needed,-z,relro,--hash-style=gnu' c syntax that I know of :) Has anyone else seen this spurious behavior? I kills rebuilds when it causes sip build failures I haven't changed a thing, and I get different results. The build is simple: <snip> cd ${srcdir} ## copy source for Python build cp -r ${pkgbase#*-} sipPy3 ## Python version msg "Running python configure.py (python3 based sip)...." cd ${srcdir}/sipPy3 python configure.py CFLAGS="${CFLAGS}" LFLAGS="${LDFLAGS}" msg "Building - tde-sip (python3 based sip)..." make ## Python2 version msg "Running python2 configure.py (sip4-tqt)...." cd ${srcdir}/${pkgbase#*-} python2 configure.py CFLAGS="${CFLAGS}" LFLAGS="${LDFLAGS}" msg "Building - ${pkgbase}..." make } Any thoughts? -- David C. Rankin, J.D.,P.E.

3 3

No! 42 minutes building koffice down the tubes :( libpng... ) kis_png_converter.cc
by David C. Rankin 30 Mar '12

30 Mar '12

Darrell, koffice was building perfectly -- until it hit: /bin/sh ../../../libtool --tag=CXX --mode=compile g++ -DHAVE_CONFIG_H -I. -I../../.. -I. -I../../../lib/kofficeui -I../../../lib/kofficeui -I../../../lib/kofficecore -I../../../lib/kofficecore -I../../../lib/store -I../../../lib/store -I../../../lib/kwmf -I../../../lib/kwmf -I../../../lib/kopalette -I../../../lib/kopalette -I../../../chalk -I../../../chalk/core -I../../../chalk/sdk -I../../../chalk/core/tiles -I../../../chalk/chalkcolor -I../../../chalk/ui -I../../../lib/kofficeui -I../../../lib/kofficeui -I../../../lib/kofficecore -I../../../lib/kofficecore -I../../../lib/store -I../../../lib/store -I../../../lib/kwmf -I../../../lib/kwmf -I../../../lib/kopalette -I../../../lib/kopalette -I../../../lib/interfaces -I../../../lib/kopainter -I../../../lib/kopainter -I/opt/trinity/include -I/opt/tqt3/include -I. -include tqt.h -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=x86-64 -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 -DHAVE_KNEWSTUFF -fexceptions -MT kis_png_converter.lo -MD -MP -MF .deps/kis_png_converter.Tpo -c -o kis_png_converter.lo kis_png_converter.cc libtool: compile: g++ -DHAVE_CONFIG_H -I. -I../../.. -I. -I../../../lib/kofficeui -I../../../lib/kofficeui -I../../../lib/kofficecore -I../../../lib/kofficecore -I../../../lib/store -I../../../lib/store -I../../../lib/kwmf -I../../../lib/kwmf -I../../../lib/kopalette -I../../../lib/kopalette -I../../../chalk -I../../../chalk/core -I../../../chalk/sdk -I../../../chalk/core/tiles -I../../../chalk/chalkcolor -I../../../chalk/ui -I../../../lib/kofficeui -I../../../lib/kofficeui -I../../../lib/kofficecore -I../../../lib/kofficecore -I../../../lib/store -I../../../lib/store -I../../../lib/kwmf -I../../../lib/kwmf -I../../../lib/kopalette -I../../../lib/kopalette -I../../../lib/interfaces -I../../../lib/kopainter -I../../../lib/kopainter -I/opt/trinity/include -I/opt/tqt3/include -I. -include tqt.h -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=x86-64 -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 -DHAVE_KNEWSTUFF -fexceptions -MT kis_png_converter.lo -MD -MP -MF .deps/kis_png_converter.Tpo -c kis_png_converter.cc -fPIC -DPIC -o .libs/kis_png_converter.o In file included from kis_png_converter.cc:40:0: ../../../chalk/core/kis_layer.h:170:34: warning: type qualifiers ignored on function return type [-Wignored-qualifiers] kis_png_converter.cc: In member function 'KisImageBuilder_Result KisPNGConverter::decode(const KURL&)': kis_png_converter.cc:233:97: error: invalid conversion from 'char**' to 'png_bytepp {aka unsigned char**}' [-fpermissive] /usr/include/png.h:2267:1: error: initializing argument 5 of 'png_uint_32 png_get_iCCP(png_const_structp, png_const_infop, png_charpp, int*, png_bytepp, png_uint_32*)' [-fpermissive] kis_png_converter.cc: In member function 'KisImageBuilder_Result KisPNGConverter::buildFile(const KURL&, KisPaintLayerSP, vKisAnnotationSP_it, vKisAnnotationSP_it, int, bool, bool)': kis_png_converter.cc:528:43: error: 'Z_DEFAULT_STRATEGY' was not declared in this scope kis_png_converter.cc:630:143: error: invalid conversion from 'char*' to 'png_const_bytep {aka const unsigned char*}' [-fpermissive] /usr/include/png.h:2274: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] kis_png_converter.cc:643:47: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] kis_png_converter.cc:649:53: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] kis_png_converter.cc:656:49: warning: deprecated conversion from string constant to 'char*' [-Wwrite-strings] In file included from kis_png_converter.cc:793:0: kis_png_converter.cc: In member function 'KisImageBuilder_Result KisPNGConverter::decode(const KURL&)': kis_png_converter.cc:164:31: warning: ignoring return value of 'size_t fread(void*, size_t, size_t, FILE*)', declared with attribute warn_unused_result [-Wunused-result] make[4]: *** [kis_png_converter.lo] Error 1 make[4]: Leaving directory `/build/src/koffice/filters/chalk/png' make[3]: *** [all-recursive] Error 1 make[3]: Leaving directory `/build/src/koffice/filters/chalk' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/build/src/koffice/filters' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/build/src/koffice' make: *** [all] Error 2 Looks like kis_png_converter.cc needs patching. I'll see if I can figure it out based on the gwenview patch. I think that is all it needs. If anyone is good with this and can beat me to it, my hat is off to you. And wow - processor speed really makes a huge difference in build times. For the packages I'm building on arch: i686 build - old p4 2800 Build time 462 min. ~ 7.7 hours x86_64 build - newer (but old) 9850 X4 Build time 224 min. ~ 3.7 hours Never really built projects this large before, but speed -- does matter :) -- David C. Rankin, J.D.,P.E.

4 7

eg. kima - why do some sources still have the 'config.log' files in the source?
by David C. Rankin 30 Mar '12

30 Mar '12

Tim, All, Do we want to flag packages that still have old build files in them? Look at kima - it still has somebody's old config.log in the kima dir. Etherpad issue? -- David C. Rankin, J.D.,P.E.

2 3

'tsak' and 'tdmtsak' still using ~100% of CPU when TDM used
by David C. Rankin 30 Mar '12

30 Mar '12

Tim, Slavek tsak/tdmtsak are still broken and taking almost 100% of the cpu when TDM is used as the login manager. This is with 'todays' (03/29) build from the GIT tree: http://www.3111skyline.com/dl/dt/trinity/ss/tsak-96-cpu.jpg I thought this was fixed?? -- David C. Rankin, J.D.,P.E.

3 6

Fixing What's This and Tooltip text strings
by Darrell Anderson 30 Mar '12

30 Mar '12

I would like to update branding issues in all of the What's This and Tooltip text strings. Primarily changing KDE -> TDE. A challenge is many of the text strings are multiple lines. A simple find/sed one-liner will be insufficient. The What's This strings are contained in TQString functions and end with the traditional semi-colon. Additional What's This strings are in XML files enclosed in <whatsthis> and </whatsthis> tags. The tool tips are embedded in i18n functions. I'm no expert with awk or perl and I'm guessing either is better for addressing this challenge. A good way for me to learn some basics about awk or perl is to update these text strings. I would appreciate some awk/perl tips or pointers for approaching this mini project. Thanks! Darrell

2 2

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels