tde-devels

devels@trinitydesktop.org

1 participants
3754 discussions

Re: [trinity-devel] tdelibs FTBFS: cmake 2.8.12: INTERFACE_LINK_LIBRARIES vs. LINK_INTERFACE_LIBRARIES

by Darrell Anderson

>Incidentally, proposed patch from Darrell seems to me as a better >solution >than workaroung from Fat-Zer. Darrell's patch looks like the right >response >to change in CMake. My proposed patch was only a conceptual patch. I have not been able to get anything like that proposal to work. One of you cmake experts will have to dazzle us all. :-) Darrell

11 years, 1 month

Re: [trinity-devel] tdelibs FTBFS: cmake 2.8.12: INTERFACE_LINK_LIBRARIES vs. LINK_INTERFACE_LIBRARIES

by Darrell Anderson

>However, yes, publication time should be shortened - during the building >arm packages >may be published packages for other distributions, that not depend >on arm >packages (for example all Ubuntu versions). Then let's do that? >Sending one announcement after tagging the sources in GIT and then >after every >publishing binary package to me does not seem like a good idea. >Immediately >after announcement users will ask just for binary packages. Please let me clarify. Announcing availability in a press release would be by full package sets, not individual packages. For example, the initial press release would include all of the supported Debian/Ubuntu package sets and any other distro package sets that have been made available, such as those from Francois. The site web page contains the links for those full package sets. After that initial batch of package sets are uploaded and mirrored, and announced, then begin building ARM package sets. When the ARM packages are ready then issue another press release. Likewise with all package sets for other distros. Something like this: 1st press release: ...full package sets are available now for Debian XX, XX, XX; Ubuntu XX, XX, XX; Fedora XX, XX. Build scripts are available for Slackware 14.0. Package sets for ARM are forthcoming. 2nd press release (whenever needed): ...full package sets are now available for ARM; OpenSuse XX, XX, Mageia XX. Build scripts are available for Slackware 13.1, 13.37, and 14.1. 3rd press release (whenever needed): ... The picture I'm trying to paint is we don't wait 18 or more days to start the release cycle. If the Debian and Ubuntu packages build quickly on the build farm, get those prepared first. Then focus on the next wave of package sets. Something like an 80/20 principle: Have 80% of the most needed package sets ready, then with those out of the way, prepare 80% of the remaining 20%. Etc. Darrell

11 years, 1 month

Re: [trinity-devel] tqt FTBFS: something about TQAssistantClient

by Darrell Anderson

>4) tdevelop doesn't build and interestingly it is something >related to tqassistantclient. I haven't got the time to look at >that properly yet, but the obvious patch or remaning - >lqassistantclient to -ltqassistantclient is not enough. I will >work on this as soon as I have enough time > >The problems with TQAssistantClient seems to come after commit >5445c25f on Dec 02. I filed bug report 1761 for tdevelop and attached a proposed patch that works for me. Darrell

11 years, 1 month

Re: [trinity-devel] tdelibs FTBFS: cmake 2.8.12: INTERFACE_LINK_LIBRARIES vs. LINK_INTERFACE_LIBRARIES

by Darrell Anderson

>Just as a word of warning, this would push R14 to January 2014 at >the earliest due to the time required to rebuild the entire package >set for Debian/Ubuntu. I had already filed bug report 1759: http://bugs.trinitydesktop.org/show_bug.cgi?id=1759 cmake_policy(SET CMP0022 OLD) seems like a temporary work-around --- cmake 2.8.12 is here to stay and we might as well adapt sooner rather than later. :-) I just love how upstream changes keep breaking things for everybody downstream.... C'est la vie. Darrell

11 years, 1 month

Re: [trinity-devel] tqt FTBFS: something about TQAssistantClient

by Darrell Anderson

>tqt FTBFS with next message: > >x86_64-pc-linux-gnu-g++ -luuid -fno-exceptions -Wl,-O1 -Wl,--as- >needed -o >../../../bin/tqdesigner .obj/release-shared-mt/main.o -L/usr/lib64 >-L/var/tmp/portage/dev-qt/tqt-3.9999/work/tqt-3.9999/lib - >L/usr/X11R6/lib64 >-L/var/tmp/portage/dev-qt/tqt-3.9999/work/tqt-3.9999/lib - >L/usr/lib64 >-ltqtdesignercore -ltqui -ltqassistantclient -luuid -ltqt-mt -lmng >-ljpeg >-lpng -lz -lXi -lXrender -lXrandr -lXcursor -lXinerama -lXft - >lfreetype >-lfontconfig -lXext -lX11 -lm -lSM -lICE -ldl -lpthread >/var/tmp/portage/dev-qt/tqt-3.9999/work/tqt- >3.9999/lib/libtqtdesignercore.a(mainwindow.o): >In function `MainWindow::MainWindow(bool, bool, TQString const&)': >mainwindow.cpp:(.text+0x15bd5): undefined reference to >`TQAssistantClient::TQAssistantClient(TQString const&, TQObject*, >char >const*)' > > >Full Build log is in the attach. There was a bug report the past couple of days and related patch committed. Probably need to update your local source tree? Darrell

11 years, 2 months

Amarok (x86) fails scanning files whose inode value exceeds "uint32 max value" (XFS/inode64)

by Nicolas Bercher

Hi, I just submitted a bug report regarding this issue: http://bugs.pearsoncomputing.net/show_bug.cgi?id=1758 Any clue on this? I'm not yet involved in TDE development, but I'd be willing to try to fix this if some people could give me few advices and directions. And basically, I don't want to dig in it if it's a well known fact that such inode64 issues on x86 platforms are not not fixable (in the context of TDE code only). I think I have to start analyzing the scanning code of course and check C types used to handle inode values, if such things occur within Amarok code. Another option might be that the bug lives in an external library that open the files for Amarok. (People might ask me "Why I don't you swich to amd64 distro?" But that is not the question here.) Nicolas

11 years, 2 months

Re: [trinity-devel] Trinity on older hardware

by Darrell Anderson

>as further thing to consider, have 3.5.10 and R14 been compiled in >the same configuration (either release-release or debug-debug)? On >some intensive programs I noticed a speed difference ratio or 3-to- >1 between the two. 3-to-1 ratio --- which one was faster? Speaking of debugging, does including the debugging symbols affect run-time operation? I would not think so but on old hardware might that be true? I wonder because now in hindsight I remember I never built or installed the debugging symbols for the 3.5.10 or TDE 3.5.x packages. (I'm still not letting newer versions of X and the kernel off the hook. Just wondering out loud.) Darrell

11 years, 2 months

Re: [trinity-devel] Trinity on older hardware

by Darrell Anderson

>Well, you are very much correct on the watts/performance issue, I >look at >it this way. Your average PII/PIII is about as powerful as some >of the >ultra-efficient Arm-based SBC devices now available for Linux >users. If >TDE can run well on PII/PIII hardware, then it will likely run >well on >those very efficient Arm-based systems as well. I don't run the PI and PII all day. I use them because they provide a nice way for corner case testing. For example, a while back I noted problems with the logout status dialog because only the PI or PII would show them. Darrell

11 years, 2 months

Re: [trinity-devel] Trinity on older hardware

by Darrell Anderson

>> That said what kinds of system or usability tests would be >> representative? >You bring up a long-standing problem here. :-) Without an >automated >performance test suite, all we can go in is the system "feel" and >"snappiness" when trying to use it. > >I would still like to put together a test suite (ideally generic >enough >that we can also benchmark Qt4/Qt5 for comparison purposes), but >don't >have time at the moment with trying to get R14 out the door and >all. Sounds like a great post-R14 project. Until then I'll have to settle for a stopwatch and the time command. :-) Darrell

11 years, 2 months

Trinity on older hardware

by Darrell Anderson

All, Do you have experience with running Trinity on older hardware? I have a PI and a PII. For years I ran KDE 3.5.10 on both. While hardly the fastest hardware, and 3.5.10 hardly the snappiest desktop environment, the system was usable. Trinity R14 on both systems is almost unusable. Starting Trinity takes a minute or two. Opening konsole takes 7-10 seconds. Opening a preloaded konqueror takes 20-25 seconds. I realize free/libre software never truly supported older hardware despite claims otherwise and developers instead move relentlessly onward with bleeding edge hardware. Still, because of the many improvements I would think Trinity R14 would fare better, at least as good as 3.5.10. Any ideas? Any help? Darrell

11 years, 2 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels