tde-devels

devels@trinitydesktop.org

3 participants
3808 discussions

Placing the Release Notes on the Desktop
by Darrell Anderson 17 Jan '14

17 Jan '14

All, The eventual release of R14 will mark a turning point in Trinity history. The R14 release is significant because of the many class and branding renaming changes. While we have drafted a README document to explain such changes, we have no mechanism for users to read the document. I would like to see us patch the sources such that a Release Notes document is always placed on the user's desktop when updating to a new release. That practice would continue with maintenance releases too. While the drafted README for R14.0.0 lists many changes, subsequent copies would only list bug and security fixes in that release and will not be large documents. Of course, the user is free to delete the document from the desktop at any time. The document reappears on the desktop only with new releases. We would need to update the document before officially releasing each subsequent release, but this simple mechanism would ensure users are updated with changes. Thoughts? Darrell

3 2

Seeking a Russian-to-English translator
by Darrell Anderson 16 Jan '14

16 Jan '14

All, The ksquirrel help handbook is written in Russian. We would like to have an English version. Please contact me if you want to help translate and need help with English. Or, just hack the Russian to English as best as possible and we'll coordinate the English later. Here is a link to the git version: http://git.trinitydesktop.org/cgit/ksquirrel/tree/doc/ru Don't worry about html or docbook. Plain text files will suffice. :) Thank you! Darrell

2 1

Uugh! Arch! - Calvin - what changed in makechrootpkg?
by David C. Rankin 16 Jan '14

16 Jan '14

All, Calvin, Building in a clean chroot has changed significantly on Arch. My TDE build relies on being able to create and index a 'local' repo in $CHROOT/root/repo and add packages and update the index as each package is built. The appropriate entry is in $CHROOT/root/etc/pacman.conf: [local] Server = file:///repo The files are copied to $CHROOT/root/repo and the index built with: repo-add local.db.tar.gz *.xz A stub PKGBUILD is then created with: depends=('apetag-git' 'libkarma' 'libnjb' 'libutempter' 'mt-daapd' 'musepack-tools-svn' 'tde-tqt3' 'wv2' 'xmedcon') Now 'sudo mkchrootpkg -c -r $CHROOT' results in the following error: 21:25 phoinix:/dat_f/tde/stub> sudo makechrootpkg -c -r $CHROOT ==> Creating clean working copy [david]...done ==> Making package: tde-stub 0.1-1 (Thu Jan 16 21:25:34 CST 2014) ==> WARNING: Using a PKGBUILD without a package() function is deprecated. ==> Retrieving sources... ==> Making package: tde-stub 0.1-1 (Thu Jan 16 21:25:34 CST 2014) ==> WARNING: Using a PKGBUILD without a package() function is deprecated. ==> Checking runtime dependencies... warning: database file for 'local' does not exist ==> Installing missing dependencies... warning: database file for 'local' does not exist error: target not found: apetag-git error: target not found: libkarma error: target not found: libnjb error: target not found: mt-daapd error: target not found: musepack-tools-svn error: target not found: tde-tqt3 error: target not found: wv2 error: target not found: xmedcon ==> ERROR: 'pacman' failed to install missing dependencies. ==> ERROR: Build failed, check /dat_e/ch14/david/build Calvin, do you know what changed in chroot building on Arch that causes the local repo to no longer be found? I've posted on arch-general as well. -- David C. Rankin, J.D.,P.E.

1 0

Seeking a kstreamripper user
by Darrell Anderson 16 Jan '14

16 Jan '14

All, Currently the kstreamripper help handbook is only a handbook template. We could use a basic English handbook. The app does not look complicated or involved. A single window interface. Probably won't take long to describe the basic features. As with kquirrel, don't worry about html or docbook. Plain text files will suffice. :) Thank you! Darrell

1 0

Re: [trinity-devel] hal & 3.5.13-sru - future -> argument to bring hal in-house
by Darrell Anderson 16 Jan '14

16 Jan '14

> All, what is the consensus? Will you need hal and if so, would >you help update it if Tim set it up here? Me personally? No. :) How many Trinity users are still using HAL based distros? Does Trinity build on those older releases? The oldest Slackware release upon which I can build Trinity is 13.1, which is HAL based. Trinity won't build on older releases for other reasons but HAL is not one of those reasons. Rather than supporting a full blown HAL git branch, how about just uploading upstream patches? Nothing more. For example, we don't have a wv2 branch, but we do need knowledge where to find wv2 patches. Likewise for HAL. Right now we already have a git module called thirdparty. The only submodule now is libreoffice. Add appropriate submodules as needed: wv2, HAL, etc. Add the necessary patches there. Post a wiki article with links to the thirdparty patches. Darrell

2 1

Re: [trinity-devel] Final inspection for KDE-TDE/kde/tde rebranding issues
by Darrell Anderson 16 Jan '14

16 Jan '14

>I'm not really clear on what it is you want to search for. Here is a sample of the type of multiple line strings I want to search: TQWhatsThis::add( clickRaiseOn, i18n("When this option is enabled, the active window will be brought to the" " front when you click somewhere into the window contents. To change" " it for inactive windows, you need to change the settings" " in the Actions tab.") ); The important point is the string is multiple lines. The only known constants are the first line contains a call to TQWhatsThis and the end of the string is a semi-colon. More than likely, the last two characters are known: a closing parentheses and a semi-colon. I want to run a comprehensive check against the entire source tree looking inside these types of strings for references to "KDE" or "kde." For branding purposes we want to update most of those references to "TDE" and "tde" respectively. This example string does not contain a KDE/kde reference. I would not want this particular string to bubble up in my search. Only those multiple line strings that contain "KDE or "kde." There are legitimate strings where KDE/kde should be left as is, such as accreditations to past developers. I don't want to perform a search-and-replace. I only want to perform a search. I want to manually read any remaining KDE/kde remnants in context to decide whether to update to TDE/tde. grep won't do the job. Something likely could be wrangled out of the -A option. but I suspect that kind of script would be slow, needing to continually test whether the last line contains a closing parentheses and a semi-colon. I presumed somebody skilled in perl would be able to see the light but I am not a perl user. I also want to perform the same type of search against TQTooTip multiple line strings. There are also multiple line strings in *.ui files containing What's This and Tooltip strings. There the usage is different: <property name="whatsThis" stdset="0"> <string>Enter the command you wish to execute or the address of the resource you want to open. This can be a remote URL like "www.kde.org" or a local one like "~/.tderc".</string> </property> <property name="toolTip" stdset="0"> <string>Slow processors perform poorly with effects</string> </property> In the *.ui files the known constants are <property name=xxx > and </property>. Darrell

2 2

hal & 3.5.13-sru - future -> argument to bring hal in-house
by David C. Rankin 16 Jan '14

16 Jan '14

Slavek/Tim, All, I don't know what the lifetime plans for 3.5.13 are, but given upcoming automake 2.0 issues facing hal, if 3.5.13 will be around for more than a year or so, it would make sense to bring hal/hal-info in-house while the updates to the source tree are still manageable. (as done with Qt3) As of automake 1.14, hundreds of warnings are generated regarding 'subdir-objects' being disabled in automake and build fails due to obsolete macros. I have added the subdir-objects option to AM_INIT_AUTOMAKE in configure.in for Archlinux builds and added 'autoupdate' to correct the obsolete macro build failure. Hal then builds fine. Currently there are over 1M of patches applied to the hal 0.5.14 source. When 6 patch files encompassing over a megabyte of diffs are required, the chance for subsequent patches breaking prior patches poses a real problem. If 3.5.13 will be around for a while and still need hal/hal-info, it may make sense to bring hal in-house and clean it up/apply the current patch sets and make it available to those still working with 3.5.13. The last updates applied to the hal code date back to 2011 - centuries ago in Linux terms. Hal and hal-info presently exist in a git repository. That may make it easier to bring the code in-house for update. These are just thoughts I had after going though the process to update and build hal yesterday. Here are the locations of the two git repositories. Git repositories: git://anongit.freedesktop.org/hal git://anongit.freedesktop.org/hal-info It may not be worth the effort, but for those distros on automake 1.14 that will be moving to automake 2.0 when released, I doubt hal will build without some significant updates. If 3.5.13 will continue to need hal and will be around for a while, some planning and effort now (after R14 is out the door) may pay dividends in the future... Apparently automake 2.0 will force object files to be produced in the current directory deprecating the multiple subdirectory Makefile source references that hal currently uses. E.g. from partutil/Makefile.am: libpartutil_la_SOURCES = partutil.h partutil.c ../hald/logger.c ../hald/logger.c produces the subdir-objects warning that from my understanding will cause failure in automake 2.0. If the AM_INIT_AUTOMAKE([subdir-objects]) option will take care of this problem in 2.0, then it isn't that much of a problem, but if not, then a bit of work will be needed on hal. I am still not very clear on all the implications, but from working through the build on automake 1.14, this was the impression I got. Think about it, you all decide, I'm going to try R14 and nohal and see how it goes... -- David C. Rankin, J.D.,P.E.

2 2

Re: [trinity-devel] Final inspection for KDE-TDE/kde/tde rebranding issues
by Darrell Anderson 16 Jan '14

16 Jan '14

>> >I would like to inspect source tree text strings for instances >of >> >KDE/kde rebranding issues and update to TDE/tde. Mostly in >> >tooltips >> >and What's This help strings. My challenge is being able to >> >efficiently grep only those strings, which often in the sources >> >are multiple lines. >> > >> >I would appreciate shell scripting advice to find such text >> >strings. >> >> Nobody knows? > >It would help to search whole words - grep option '-w'? I don't understand how that helps. For example, I want to find all TQWhatsThis strings, which often are multiple lines, and ensure I am searching the entire string, which includes all the multiple lines. About the only thing I know is the search will key on something like TQWhatsThis and the entire glob of text to search will end with an apostrophe (;). All of that constitutes the entire string that must be searched for 'KDE/kde'. Darrell

3 2

Darrell - Build Script Updates - go bys online?
by David C. Rankin 15 Jan '14

15 Jan '14

Darrell, I am having to go one-by-one through my build scripts for each tde package and remove old patches, etc. I don't know which ones are still needed. Eg (for tdebase): msg "Patching - tdebase patch set...." for patch in ${srcdir}/patches/*.patch; do _p=`basename $patch` msg "Applying patch $_p..." patch -Np0 -i $patch done Do you still have your build scripts online? I see you closed humanreadable.nfshost, so I'm looking for a current set of "go bys" to prevent repeated build failures figuring out which current patches I need :) Help a brother out? -- David C. Rankin, J.D.,P.E.

1 0

Re: [trinity-devel] Need debian help - what fixed: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=707417
by Darrell Anderson 15 Jan '14

15 Jan '14

>That fixed the FTBFS - Why the FILE_OFFSET_BITS=64?? There is no >way file size exceeds (2<<31)-1 bits?? I don't know. I only remember seeing the same build failure as you described. What I shared is the result of my repairs. Darrell

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels