tde-devels

devels@trinitydesktop.org

3 participants
3808 discussions

Re: [trinity-devel] about pmount and R14 new backends
by Darrell Anderson 06 Aug '13

06 Aug '13

>I've seen that the "pmount" utility is used in TDE R14 for >removable >devices. >I've also seen that this utility is NOT provided at all in some >distributions, e.g. Mageia 3. > >Questions: >1) If pmount does not exist, is there any alternative in TDE R14 >to >mount/umount devices ? (I'd say no, because I have an error >message >saying pmount was not found) >2) This utility looks like it is not maintained anymore upstream. >I've >built 0.9.99-alpha, and it works but needs some patches. Could we >import >into our Git to have our own "TDE-certified" pmount utility ? >3) Could'nt udisks2 do the same as pmount ? > >And some more questions about R14 new features ... >1) Is HAL/Halbackend code still entirely present ? (for old distro >NOT >having udisks, upower, etc ... but having HAL out of the box) >2) Do we have a summary of "what libraries are used for" in >tdelibs/tdebase ? For example, if I build with "udisks" but no >"udisks2" >support, what feature will I lose exactly ? And what alternatives >do I >have ? > >Up to 3.5.13.x, the situation seemed clear: without HAL, there was >no >alternative :-) Many months ago when I started testing tdehwlibs with Tim, I too noticed the pmount requirement. The package is not part of the stock Slackware but easily compiled and installed in Slackware. Nonetheless, that pmount is not a standard package in many distros does raise the question of how to best handle that discrepancy. If pmount is no longer maintained upstream, and if pmount is the only palatable method for supporting tdehwlib, then perhaps we ought to slip pmount into our dependencies tree. We have libart_gpl as a precendent for such a move. I'm using pmount 0.93, which is the current stable version. If there are alternatives to pmount, that nonetheless means extensive rewrites and testing. We already have enough on our plate to get R14.0.0 out the door in a timely fashion, and progress toward that has somewhat stalled of late. Replacing pmount also likely means an ABI change and according to our new versioning scheme, would mean such changes should wait until R14.1.0 (and not R14.0.1, which would be a bug-fix and maintenance release). As Alexander noted in another response, Trinity can be compiled with HAL or TDEHWLIB support, but not both. For a couple of months I built both ways as Slackware 13.1 uses HAL and 14.0 uses the udisks framework. I'm no longer using 13.1 and can't say how well we've maintained HAL support. I now only use 14.0 and I am not experiencing any serious problems with tdehwlib. Darrell

2 1

Moving tdehwlib to a standalone library
by Fat-Zer 05 Aug '13

05 Aug '13

Hi, as I claimed just now on the neighbor thread, I'm working on the move tdehwlib out of tdecore. why so: 1. it provides specific functionality. 2. Only few apps are using it. 3. It's not integrated into tdecore except of couple unnecessary and ugly hacks to KInstace. 4. It's code is too robust while it's located in a single file. What changes are introduced: 1. TDEHW namespace for all exported classes. 2. Some specific macros. 3. Move includes to tdehw directory. 4. Strip TDE prefix from classes and file names. What is already done: 1-4. 5. Split tdehardwaredevices.{h,cpp} into several headers 6. repair tdebase according to the changes What is to be done before merging the changes: 1. Repair any other modules. (Is there any?) 2. Some repair is needed to tdenetworkconnections.{cpp,h} and to modules which use it. 3. Testing. Further plans: 1. Introduce the backend framework. On first stage in the most basic way. 2. Split tdenetworkconnections.cpp in the same way it was done for tdehardwaredevices. The repositories are here: https://github.com/Fat-Zer/tdelibs.git https://github.com/Fat-Zer/tdebase.git See libtdehw branch. !WARNING! It supposed to be built and work but my be broken in some options. Some questions: Is there any ather modules outside tdebase which use tdehw? Is there anything what uses tdenetworkconnections? Any other thoughts?

1 0

about pmount and R14 new backends
by François Andriot 05 Aug '13

05 Aug '13

Hello, I've seen that the "pmount" utility is used in TDE R14 for removable devices. I've also seen that this utility is NOT provided at all in some distributions, e.g. Mageia 3. Questions: 1) If pmount does not exist, is there any alternative in TDE R14 to mount/umount devices ? (I'd say no, because I have an error message saying pmount was not found) 2) This utility looks like it is not maintained anymore upstream. I've built 0.9.99-alpha, and it works but needs some patches. Could we import into our Git to have our own "TDE-certified" pmount utility ? 3) Could'nt udisks2 do the same as pmount ? And some more questions about R14 new features ... 1) Is HAL/Halbackend code still entirely present ? (for old distro NOT having udisks, upower, etc ... but having HAL out of the box) 2) Do we have a summary of "what libraries are used for" in tdelibs/tdebase ? For example, if I build with "udisks" but no "udisks2" support, what feature will I lose exactly ? And what alternatives do I have ? Up to 3.5.13.x, the situation seemed clear: without HAL, there was no alternative :-) Thanks Francois

2 1

Re: [trinity-devel] Artwork branding help needed
by Darrell Anderson 03 Aug '13

03 Aug '13

>These should hopefully be what you wanted. > >E. Liddell The look great! Thank you! :-) Darrell

1 0

Re: [trinity-devel] Artwork branding help needed
by Darrell Anderson 03 Aug '13

03 Aug '13

>You just want "KDevelop" -> "TDevelop" and "KDE Development" -> >"TDE Development" ? >I can give them a shot tomorrow if no one else gets there first. Sounds great! Darrell

2 1

Artwork branding help needed
by Darrell Anderson 02 Aug '13

02 Aug '13

Artists, I filed bug report 1607 against the TDevelop splash image branding. If you feel up to the task please help with updating the images. http://bugs.trinitydesktop.org/show_bug.cgi?id=1607 There are three images located in git: main/tdevelop/pics/misc. kdevassistant-splash.png kdevdesigner-splash.png tdevelop-splash.png Thanks :-) Darrell

2 1

Building from GIT source & tde-packaging
by Michele Calgaro 29 Jul '13

29 Jul '13

Hi there, after several months, I have started to rebuild TDE from the current GIT sources on Debian/Testing, but I have soon noticed that the "tde-packaging" repository is not up to date with the "tde" repository. Namely, when trying to build "tdelibs" I run into a broken dependency for "libart-2.0-dev" version >=14.0.0. The current files in the "tde-packaging" repository for "libart" builds to a version which is 2.3.22. I double-checked the nightly builds on the web site, and I saw that the correct package (version 14.0.0) is created. So my questions are: 1) is there a date already scheduled for an update of the "tde-packaging" repository, and if so when 2) otherwise, is there any other place where I can find the updated packaging files (other than download the .dsc and .tar.xz file for each package from the nightly build website and then extract the packaging scripts)? Thanks Michele

1 0

Re: [trinity-devel] R14.0.0 Hard Freeze
by Darrell Anderson 24 Jul '13

24 Jul '13

>So, if I think they should be applied, am I supposed to add them >to some >list or as a depend for some bug or mark up them somehow? I updated the etherpad. Please remember the etherpad list is not all-inclusive of every unresolved bug report. The etherpad is a list of selected bug reports from the various categories that we believe must be fixed for the official R14 release. Feel free to voice opinions about the contents of the list. Just please remember that everybody involved has bug reports that are not in the etherpad list. The goal is to release R14 and not to resolve all outstanding bug reports in the next couple of weeks. That would be impossible. The remaining unresolved bug reports number far too many to add to this list. The etherpad list is a triage of sorts. There will be plenty of opportunity to resolve remaining open bug reports with each subsequent minor point release (R14.0.1, R14.0.2, etc.) and this is exactly how we will resolve them all. :-) All bug reports cause some pain to one degree or another. The etherpad list contains those reports we believe cause the most pain. :-) Alexander, I saw your additions to the etherpad. I moved them to different categories but all of the items are still there. :-) Darrell

2 1

R14.0.0 Hard Freeze
by Timothy Pearson 23 Jul '13

23 Jul '13

All, TDE R14.0.0 will be entering a hard freeze 00:00GMT 07/23/2013. A hard freeze means that only patches which resolve bug reports will be accepted. For additional details on our R14 release schedule and critical bugs that need to be resolved, please visit the TDE R14 release Etherpad at http://trinity.etherpad.trinitydesktop.org/39 If you can help out with the open bugs listed at that Etherpad, please do so. R14.0.0 cannot be delayed much further due to HAL and NetworkManager changes, and if necessary any remaining open bugs listed as of R14.0.0 release will need to be addressed in an R14.0.1 SRU. Thanks! Timothy Pearson Trinity Desktop Project

3 6

knetworkmanager8 vs tdenetworkmanager
by François Andriot 23 Jul '13

23 Jul '13

Hello, I'm building R14 for CentOS 6. This distribution is using NetworkManager 0.8 . Is the Knetworkmanager8 package still relevant for this distribution ? Because I've got FTBFS with it (see bottom of this mail). But I've built by error tdenetworkmanager (aka knetworkmanager9), and it built correctly, but it also looks like it works correctly (not really tested but it shows my wireless network). Is "tdenetworkmanager" supposed to replace both versions of knetworkmanager ? Thanks François FTBFS in knetworkmanager8: [ 20%] Building CXX object knetworkmanager-0.8/src/CMakeFiles/tdeinit_knetworkmanager-shared.dir/knetworkmanager-connection.cpp.o cd "/dev/shm/BUILD.el6.x86_64/trinity-knetworkmanager8-14.0.0~pre106+401c11db/build/knetworkmanager-0.8/src" && /usr/lib64/ccache/c++ -DHAVE_CONFIG_H -Dtdeinit_knetworkmanager_shared_EXPORTS -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -include tqt.h -I/usr/include/tqt3 -I/usr/include/tqt -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -include tqt.h -fPIC -I"/dev/shm/BUILD.el6.x86_64/trinity-knetworkmanager8-14.0.0~pre106+401c11db/build/knetworkmanager-0.8/src" -I"/dev/shm/BUILD.el6.x86_64/trinity-knetworkmanager8-14.0.0~pre106+401c11db/build" -I/opt/trinity/include/tde -I/usr/include/tqt3 -I/usr/include/tqt -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include -I/usr/include/NetworkManager -I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -UQT_NO_ASCII_CAST -o CMakeFiles/tdeinit_knetworkmanager-shared.dir/knetworkmanager-connection.cpp.o -c "/dev/shm/BUILD.el6.x86_64/trinity-knetworkmanager8-14.0.0~pre106+401c11db/knetworkmanager-0.8/src/knetworkmanager-connection.cpp" /dev/shm/BUILD.el6.x86_64/trinity-knetworkmanager8-14.0.0~pre106+401c11db/knetworkmanager-0.8/src/knetworkmanager-connection.cpp: In constructor 'ConnectionSettings::ConnectionPrivate::ConnectionPrivate(ConnectionSettings::Connection*)': /dev/shm/BUILD.el6.x86_64/trinity-knetworkmanager8-14.0.0~pre106+401c11db/knetworkmanager-0.8/src/knetworkmanager-connection.cpp:64: error: cannot allocate an object of abstract type 'ConnectionSettings::ConnectionSecretsDBus' /dev/shm/BUILD.el6.x86_64/trinity-knetworkmanager8-14.0.0~pre106+401c11db/knetworkmanager-0.8/src/knetworkmanager-connection_secrets_dbus.h:51: note: because the following virtual functions are pure within 'ConnectionSettings::ConnectionSecretsDBus': /dev/shm/BUILD.el6.x86_64/trinity-knetworkmanager8-14.0.0~pre106+401c11db/build/knetworkmanager-0.8/src/dbus/connection.h:94: note: virtual bool DBus::Secrets::GetSecrets(const TQString&, const TQStringList&, bool, TQT_DBusDataMap<TQString>&, TQT_DBusError&) make[2]: *** [knetworkmanager-0.8/src/CMakeFiles/tdeinit_knetworkmanager-shared.dir/knetworkmanager-connection.cpp.o] Error 1 make[2]: Leaving directory `/dev/shm/BUILD.el6.x86_64/trinity-knetworkmanager8-14.0.0~pre106+401c11db/build' make[1]: *** [knetworkmanager-0.8/src/CMakeFiles/tdeinit_knetworkmanager-shared.dir/all] Error 2 make[1]: Leaving directory `/dev/shm/BUILD.el6.x86_64/trinity-knetworkmanager8-14.0.0~pre106+401c11db/build' make: *** [all] Error 2

2 1

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels