tde-devels

devels@trinitydesktop.org

9 participants
3819 discussions

Revert GIT to a specific date
by Darrell Anderson 30 Sep '12

30 Sep '12

What is the proper way to revert my local GIT repo to a specific date (commit)? I want to modify the sources as they would have looked on a specific day. I've read to run git reset --hard {HEAD} where {HEAD} is the commit to rest. Does that command truly reset the repo? That is does the command only reset indexes and leave the sources intact or are sources modified to that specific commit and all subsequent pulls are deleted? I realize that resetting my local repo will mean a bandwidth hit when I restore everything. :) Darrell

4 15

Last patches to 3.5.13.1?
by Slávek Banko 28 Sep '12

28 Sep '12

Attention, attention, last call for patches that want to fly with flight number 3.5.13.1. I would as soon froze source code for release 3.5.13.1. Please decide if we should incorporate before freezing any more patches. Definitely will be integrated patch to sets the version number. Like other candidates I see: k3b: Update libisofs to read files greater than 2GB This partially resolves Bug 1111 http://git.trinitydesktop.org/cgit/k3b/commit/?id=8ade4e21303eb4feed76a9d8b… tdepim: Fix the addquotes/removequots functions Attachment 826 in bug report 1235 http://bugs.pearsoncomputing.net/show_bug.cgi?id=1235 But, I am not sure if these patches are ready to include for 3.5.13.1. Your opinion? Any other patches? Many thanks, Slavek --

2 3

Commit patches web page
by Darrell Anderson 27 Sep '12

27 Sep '12

I understand wanting to grab CPU time from the servers to build packages, but the commit patches web page has not been updated in 10 days. We're flying blind. Can we get the page updated? Darrell

2 1

TDE running on real ARM hardware!
by Timothy Pearson 27 Sep '12

27 Sep '12

Some of you might find this interesting...attached is a screenshot of TDE running on actual (physical) ARM hardware! To accomplish this I used Debian Squeeze with TDE running on a Raspberry Pi over tightvnc. I did need to disable artsd due to some kind of ALSA bug on this hardware, but this was a minor inconvenience. Next steps include testing Debian Wheezy and trying to get the built-in graphics hardware running with Xorg. Let me know what you think! Tim

2 2

Update for some packages in build-deps
by Slávek Banko 26 Sep '12

26 Sep '12

Tim, During the preparation of 3.5.13.1 for Precise, I had to also deal with packages in the build-deps. Before I included these packages into my ppa, I always tested whether can build on the Precise. For some packages therefore I have an update: + hal-trinity - see package in my PPA -- updated set of patches (based on Debian upstream package) https://quickbuild.pearsoncomputing.net/~slavek-banko/+archive/axis/+source… + libwpd-0.8.14 - see libwpd-0.8.14.diff -- fixed typecast + opensync-0.22 - see opensync-0.22.diff -- fixed crappy test swig version -- removed unused variables + qca-tls - see qca-tls-1.0.diff -- fixed typecast (based on tqca-tls from git) I believe that this patches are interesting also for nightly-build-deps. Note: Due to problems with building old compiz packages on Precise I did not include Compiz related TDE packages into 3.5.13.1 for Precise. Slavek --

1 0

3.5.13.1 finishing
by Slávek Banko 25 Sep '12

25 Sep '12

François, David, all, After incorporation of patches to change the path to the documentation, the current state of the GIT branches v3.5.13-sru seems to be ready to release 3.5.13.1. Please, are there any other patches that should be included? Errors that should be resolved? Anything else for what should be a release postponed? For example: Should I incorporate the latest patches from Darrell for KPDF? + http://trinity-devel.pearsoncomputing.net/?0::10089 + http://trinity-devel.pearsoncomputing.net/?0::10090 It should first resolve bugs reported by François? As: + http://bugs.pearsoncomputing.net/show_bug.cgi?id=1151 + http://bugs.pearsoncomputing.net/show_bug.cgi?id=1159 Furthermore, I would like to ask: François, David, can you test build using GIT branch v3.5.13-sru or you need first tarballs? Note: With updated scripts and branch v3.5.13-sru on meta-project 'tde' is now easy switching GIT to branch v3.5.13-sru. I look forward to hearing your opinions and comments. Slávek --

9 17

"If you believe you can assist in these areas, contact us."
by Juergen Beisert 19 Sep '12

19 Sep '12

Hi, still any help needed for the "Language translation/support" topic? Or in general improving documentation? Regards, Juergen

2 3

integrating korganizer and the clock calendar
by Calvin Morrison 18 Sep '12

18 Sep '12

Tim, How feasible would it be to integrate the clock calendar with our korganizer calendar? It would be awesome! I am looking into it now Calvin

1 0

Why not standardize kde_htmldir='\${datadir}/doc/HTML' ??
by David C. Rankin 18 Sep '12

18 Sep '12

Tim, Darrell, All, In the process of attempting to get the khelpcenter documents all collected in one spot in 3513-sru, I have found a simple setting that will allow both R14 and 3513-sru to standardize their document locations. The primary issue is that the base document path is hardcoded in tdelibs/kdecore/kstandarddirs.cpp on lines 1041-1042: 1041 if (!strcmp(type, "html")) 1042 return "share/doc/kde/HTML/"; All autotools build packages, on the other hand, set the equivalent path to: return "share/doc/HTML/"; During April (10 & 11), Darrell fixed the R14 document locations. At that time there was no focus on 3513-sru as a branch. Instead of changing the hardcoded location in tdelibs to remove ../kde/.. to match all autotools package locations and changing the CMake files as originally envisioned, hundreds of individual patches were submitted to change all autotools acinclude.m4 files to move helpcenter docs from: kde_htmldir='\${datadir}/doc/HTML' to kde_htmldir='\${datadir}/doc/tde/HTML' That works fine for R14, but interjects incompatibility between R14 and 3513 essentially requiring 2-sets of hundreds of patches just to change the kde_htmldir to '\${datadir}/doc/tde/HTML' (in the case of R14) and to '\${datadir}/doc/kde/HTML' (for 3513). Why not fix this once and for all, fix tdelibs, and just set: kde_htmldir='\${datadir}/doc/HTML' for all?? That way, instead of patching hundreds of autotools packages, the original location in tdelibs is standardized where it should be in 'kstandarddirs.cpp', the CMake files are corrected to match the original kde_htmldir locations in their sources, and all future CMake migration can go forward without every set of files having to set kde_htmldir and reset it for 3513 in another set of patches... (this stuff should be standard anyway -- there is absolutely no need to have 'kde' or 'tde' in the middle of kde_htmldir) This would eliminate hundreds of patches required to change to 'tde' for R14 and to 'kde' for 3513 and move all sources back closer to their pristine state. This couldn't have been envisioned in April, but if we are serious about providing a 3513-sru branch and R14, then I think this is the right way to do it. See: http://www.trinitydesktop.org/patches/ The set of commits at issue are between the following: 398ef116 2012-04-10 4e430ec6 2012-04-11 Thoughts? -- David C. Rankin, J.D.,P.E.

4 6

Patch to control kpdf saving document viewing metadata
by Darrell Anderson 17 Sep '12

17 Sep '12

I created and tested a patch to add an option in kpdf Settings->General to control whether kpdf stores viewing metadata files. http://bugs.pearsoncomputing.net/show_bug.cgi?id=1215 The patch works for me in R14 GIT. I'd be grateful if somebody else would test the patch. I believe the patch is backwards compatible with 3.5.13.1, although not necessary for 3.5.13.1. Darrell

1 0

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

tde-devels