Re: KDE library compile error (on the ARM CORTEX-A8)

[Thiago Macieira]

On Tuesday, 18 de January de 2011 04:49:38 Andreas Hartmetz wrote:
> On Monday 17 January 2011 22:56:47 Thiago Macieira wrote:
> > On Monday, 17 de January de 2011 22:04:46 
> > АлексаМЎр
> > КузеЌкП
>
> wrote:
> > > Hello!
> > > I have beagleboard-xm with Gentoo distributive on it. I compile and
> > > can
> > > run Qt 4.7.1 demo. Now I decide install kde from 4.6 branch svn.
> > > When I
> > > emerge kde-base/kdelibs-4.6. I recive error.
> > > http://bugs.gentoo.org/show_bug.cgi?id51934
> >
> > That's only a warning. Unfortunately, there's no error condition in your
> > paste.
>
> The standard KDE compiler flags contain -Wl,--fatal-warnings, i.e. abort on
> linker *warnings*.
> I know because I'm using the gold linker, which is more picky, and I've had
> to remove the flag from kdelibs/cmake/modules/FindKDE4Internal.cm
ke
> occasionally to make some things build. The usefulness of this flag is
> debatable in that context...

Ah, I see. I didn't know that.

We need then to identify why a text relocation was created. Which .o contained
a text relocation -- which .o wasn't compiled with -fPIC. Either that, or it's
a toolchain bug.

--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358


pgpeO71PfmgHN.pgp
Description: This is a digitally signed message part.

Moving nepomuk-system-tray to kdereview

[Artem Serebriyskiy]

Hi everyone,
I would like to move Nepomuk-system-tray from playground to kdereview
Currently project is:
project 
page
git: g...@git.kde.org:nepomuk-system-tray

-- 
Sincerely yours,
Artem Serebriyskiy

kde-qt will move from gitorious and end of life for kde-developers

[Tom Albers]

Hi,

As announced last month, kdelibs and kdebase will move real soon now to git 
(this weekend?). At the same time kdelibs moves to git, sysadmin will also move 
kde-qt[1] from gitorious to git.kde.org. You would need to fix your setup 
anyway, so doing that for both at the same time makes sense. This will be the 
only announcement about this.

At the same time we will also remove the kde-developers group from gitorious. 
The remaining KDE projects *have* to migrate to git.kde.org before that. More 
specific, as far as we know this is about: silk, owncloud and direction (that 
one abandoned?). They are free to continue on gitorious of course, but without 
the kde-developers group, which gives most of access to those repo's. We've 
tried to approach all of them without success in the past.

Best.

Toma

[1] http://qt.gitorious.org/+kde-developers/qt/kde-qt
-- 
Tom Albers
KDE Sysadmin

Please test: [CMake] CMake 2.8.4-rc1 ready for testing!

[Alexander Neundorf]

Hi,

CMake is nearing its 2.8.4 release, and a first release candidate is 
available.

This version has a change which may affect the build of KDE, current KDE 
trunk, and it needs a special command line argument for KDE 4.5.0/4.5.1.

Maybe you remember that in the KDE 4.5 cycle there was for a short time a 
build breakage of KDE trunk with CMake HEAD. This was because these versions 
of KDE included a copy of FindPackageHandleStandardArgs.cmake from CMake 
2.8.0 or so.
Now with cmake 2.8.3 FindPackageHandleStandardArgs.cmake was enhanced, and the 
find-modules coming with cmake made use of these new features. This broke the 
build, because these updated find-modules got our (KDE's) version of 
FindPackageHandleStandardArgs.cmake, which didn't have that feature yet.

What I did back then was to add an updated version of 
FindPackageHandleStandardArgs.cmake to KDE, so KDE 4.5.2 works again.

Still was a general problem, that a project could override files shipped with 
cmake, so that other cmake modules which use these files could not rely on 
actually getting the files they expect.

So, now, with the coming 2.8.4 the behaviour of include() and find_package() 
has changed in this regard, and this comes with the new cmake policy CMP0017.
Now, when include() or find_package() is called by a file which is part of 
cmake, the cmake-files installed with cmake are prefered over those with the 
same name in CMAKE_MODULE_PATH.

This is somewhat similar to a RPATH for these files, with the "RPATH" pointing 
into cmake/share/Modules/.

So please, give this release candidate a good try, and let me know if 
something fails.

To build KDE 4.5.0 or 4.5.1 with it, you should have to 
add "-DCMAKE_POLICY_DEFAULT_CMP0017=NEW" to the cmake command.

Alex


--  Forwarded Message  --

Subject: [CMake] CMake 2.8.4-rc1 ready for testing!
Date: Thursday 13 January 2011
From: David Cole 
To: cm...@cmake.org

I am happy to announce that CMake 2.8.4 has entered the release
candidate stage! You can find the source and binaries here:
http://www.cmake.org/files/v2.8/?C=M;O=D

Following is the list of changes in this release. Please try this version
of CMake on your projects and report any issues to the list or the
bug tracker.

Happy building!

-Dave


Changes in CMake 2.8.4-rc1 (since 2.8.3)

Alex Neundorf (32):
  Add support for nasm assembler, patch by Peter Collingbourne (see 
#10069)
  Improve misleading comments.
  Add missing copyright headers
  We already have 2010, fix copyright year.
  Make FindBISON work properly with non-C locales (#11326)
  Add support for yasm, a nasm compatible assembler
  Use CMAKE_ASM_NASM_FLAGS for nasm instead of FLAGS
  Remove trailing whitespace and minor formatting changes for the dot-code
  Move the code for collecting targets and libraries into separate 
functions
  Properly insert all targets, also those which don't link to anything.
  Generate separate dot files for each target, and a big one with
everything.
  Move the code for generating dot-files into separate class
cmGraphVizWriter
  Fix #11421: FindQt3.cmake doesn't honor the REQUIRED keyword
  Remove trailing whitespace
  Don't enforce VERBOSE makefiles for the CodeBlocks generator
  Remove the "early alpha stage" comments about Eclipse and C::B
  Don't disable colors in the CodeBlocks generator and minor cleanup.
  Some more fixes for nasm support, from Etienne (#10069)
  Enable/disable generating graphs depending on the target type
  Use std::cout instead of fprintf
  Collect targets and libs on demand instead of in the ctor
  Exclude targets from the graphviz file based on a regex
  Include CMakeDetermineCompilerId in
CMakeDetermineASMCompiler.cmake (#11467)
  Fix typos in the doc
  Add cache var CMAKE_ECLIPSE_MAKE_ARGUMENTS when using the
Eclipse generator
  Add ECLIPSE_CDT4_GENERATE_SOURCE_PROJECT as a ADVANCED cache
variable (#9631)
  Fix crash in Eclipse generator with empty project (#11616)
  Fix indentation in cmPolicies::ApplyPolicyVersion()
  Remove trailing whitespace
  Prefer files from CMAKE_ROOT when including from CMAKE_ROOT
  Improve documentation and messages for the new CMP0017
  Remove usage of CMAKE_CURRENT_LIST_DIR now that we have CMP0017

Alexey Ozeritsky (5):
  FindBLAS works in C/C++ projects without Fortran
  ACML find fixes (issue 0011219)
  find ACML fixes
  fix for Fortran-only projects
  FindLAPACK works with C/C++ only projects (issue 0009976)

Andrius Štikonas (1):
  Modules: Fix spelling 'becase' -> 'because'.

Ben Boeckel (25):
  Fix parsing of cache variables without a type
  Use cmCacheManager to load entries from the cache
  Support manual cache entries
  Condense parsing of cache entries
  Use FPHSA in FindOpenGL
  Ignore strerror_r since CMake isn't threaded
  Use _P

splitting up kdebase in git

[Aaron J. Seigo]

hi all ...

when looking at migrating kdebase to git (thanks to Ian Monroe for his efforts 
there and for the support of KO Gmbh that helped make that happen), it was 
decided to split it up into chunks which are:

* kdebase runtime (git -> kderuntime)
* kdebase workspace (git -> kdeworkspace)
* kdebase apps, minus konsole (git -> kdebase-apps)
* konsole

runtime / workspace / apps as divisions already reflects changes made starting 
with 4.0. even now in svn, code in one of those is not allowed to have a 
compile time dependency on code in the other two. this is why, for instance, 
folderview is in kdebase/apps/: it relies on libkonq which is also in there.

kdebase-apps is being kept together because there is a lot of code sharing 
between the projects there, particularly in the form of file management code 
in libkonq. it was determined by the maintainers of each that there was 
nothing but a loss of efficiency and increased pain to be gained from 
splitting them up.

konsole, however, is a significant application in its own right that doesn't 
actually share code with the rest of the apps in there (besides Qt, kdelibs 
and runtime, of course ;). so it is getting its own repo.

if there are any questions / concerns / thoughts on this, please provide your 
feedback now as we'd like to make the move as soon as possible once 4.6.0 is 
released. 

also, please keep all relevant discussion on kde-core-devel rather than CC'ing 
all the lists; i just CC'd the lists so everyone there who may not be on k-c-d 
as well receives the information :)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks


signature.asc
Description: This is a digitally signed message part.

Re: Review Request: Makeobj variable substitution in $OBJ_SUBDIR and $OBJ_REPLACEMENT

[David Faure]

---
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/6354/#review9656
---

Ship it!


Good stuff.

At some point we should extract the "switch to build dir" code into a separate 
file, so that it can be used by the "cb" alias/script, too...

- David


On Jan. 17, 2011, 10:01 p.m., Allen Winter wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/6354/
> ---
> 
> (Updated Jan. 17, 2011, 10:01 p.m.)
> 
> 
> Review request for kdelibs.
> 
> 
> Summary
> ---
> 
> This patch adds variable substitution to makeobj's $OBJ_SUBDIR and 
> $OBJ_REPLACEMENT, allowing one to maintain multiple builddirs within the same 
> project directory. This is especially useful for keeping builddirs for 
> different branches in 1 git repo.
> 
> For example, one could set OBJ_SUBDIR=build-%GITBRANCH% and then have 
> build-branch1; build-branch2... within the same git repo.
> 
> Also, I added variables for keeping builddirs of different platforms inside 
> the same project dir.
> So you could have have build-master-gcc; build-master-icc; build-branch-gcc; 
> build-branch-icc all in the same project.
> 
> We could always add more variables as needed, but for now I only have these:
>  %BRANCH% with the name of the Git or SVN branch you are in (as applicable)
>  %GITBRANCH% with the name of the Git branch you are in (empty if not in a 
> Git branch)
>  %SVNBRANCH% with the name of the SVN branch you are in (empty if not in an 
> SVN branch)
>  %CC% with the basename of your C compiler set in $CC (gcc if empty)
>  %CXX% with the basename of your C++ compiler set in $CXX (g++ if empty)
>  %ARCH% with the machine architecture (i.e. 'uname -m')
>  %OS% with the operating system name (i.e. 'uname -o'), in lower-case without 
> "GNU"
> 
> 
> Diffs
> -
> 
>   trunk/KDE/kdesdk/scripts/makeobj 1208110 
> 
> Diff: http://svn.reviewboard.kde.org/r/6354/diff
> 
> 
> Testing
> ---
> 
> building kdepim-master and kdepim-enterprise and kdepim-4.4 all in the same 
> git repo.
> 
> 
> Thanks,
> 
> Allen
> 
>

Re: KDE library compile error (on the ARM CORTEX-A8)

[Thiago Macieira]

On Tuesday, 18 de January de 2011 22:23:11 Александр Куземко 
wrote:
> Thank you, this help. I remove this linker options, kdelibs compiled fine.

But you still generated a library with text relocations, which is bad. We need
to know why a text relocation happened.

May be related to http://bugs.meego.com/show_bug.cgi?idT20
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
  Senior Product Manager - Nokia, Qt Development Frameworks
  PGP/GPG: 0x6EF45358; fingerprint:
  E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358


pgpXiaa96qZMN.pgp
Description: This is a digitally signed message part.

Re: splitting up kdebase in git

[John Tapsell]

On 18 January 2011 21:34, Aaron J. Seigo  wrote:
> konsole, however, is a significant application in its own right that doesn't
> actually share code with the rest of the apps in there (besides Qt, kdelibs
> and runtime, of course ;). so it is getting its own repo.
>
> if there are any questions / concerns / thoughts on this, please provide your
> feedback now as we'd like to make the move as soon as possible once 4.6.0 is
> released.

apps/ksysguard could get its own repo as well.  It's completely
standalone, and (a few?) people want to compile ksysguardd (the
daemon) by itself.

John

Re: splitting up kdebase in git

[Allen Winter]

On Tuesday 18 January 2011 4:34:21 pm Aaron J. Seigo wrote:
> hi all ...
> 
> when looking at migrating kdebase to git (thanks to Ian Monroe for his 
> efforts 
> there and for the support of KO Gmbh that helped make that happen), it was 
> decided to split it up into chunks which are:
> 
> * kdebase runtime (git -> kderuntime)
> * kdebase workspace (git -> kdeworkspace)

could we do kde-runtime and kde-workspace instead?
only because it's traditional (and because we already have git kdepim-runtime)

> * kdebase apps, minus konsole (git -> kdebase-apps)

I guess kde-apps won't work.
maybe kde-baseapps?

> * konsole
> 
> runtime / workspace / apps as divisions already reflects changes made 
> starting 
> with 4.0. even now in svn, code in one of those is not allowed to have a 
> compile time dependency on code in the other two. this is why, for instance, 
> folderview is in kdebase/apps/: it relies on libkonq which is also in there.
> 
> kdebase-apps is being kept together because there is a lot of code sharing 
> between the projects there, particularly in the form of file management code 
> in libkonq. it was determined by the maintainers of each that there was 
> nothing but a loss of efficiency and increased pain to be gained from 
> splitting them up.
> 
> konsole, however, is a significant application in its own right that doesn't 
> actually share code with the rest of the apps in there (besides Qt, kdelibs 
> and runtime, of course ;). so it is getting its own repo.
> 
> if there are any questions / concerns / thoughts on this, please provide your 
> feedback now as we'd like to make the move as soon as possible once 4.6.0 is 
> released. 
> 
> also, please keep all relevant discussion on kde-core-devel rather than 
> CC'ing 
> all the lists; i just CC'd the lists so everyone there who may not be on 
> k-c-d 
> as well receives the information :)
> 

Having konsole, ksysguard, etc in their own git repo is fine.
But they still will reside logically inside kdebase-apps 

For example on api.kde.org the EBN and LXR.

Re: splitting up kdebase in git

[John Tapsell]

On 18 January 2011 22:05, Allen Winter  wrote:
> Having konsole, ksysguard, etc in their own git repo is fine.
> But they still will reside logically inside kdebase-apps
>
> For example on api.kde.org the EBN and LXR.

That's sounds great.

John

Re: splitting up kdebase in git

[Aaron J. Seigo]

On Tuesday, January 18, 2011, John Tapsell wrote:
> On 18 January 2011 21:34, Aaron J. Seigo  wrote:
> > konsole, however, is a significant application in its own right that
> > doesn't actually share code with the rest of the apps in there (besides
> > Qt, kdelibs and runtime, of course ;). so it is getting its own repo.
> > 
> > if there are any questions / concerns / thoughts on this, please provide
> > your feedback now as we'd like to make the move as soon as possible once
> > 4.6.0 is released.
> 
> apps/ksysguard could get its own repo as well.  It's completely
> standalone, and (a few?) people want to compile ksysguardd (the
> daemon) by itself.

the complication there is that krunner also relies on libksyguard, which lives 
in kdebase/workspace/libs/ksysguard. so we'd either end up with a really odd 
dependency in ksysguard on kde-workspace, or kde-workspace would end up 
depending on the ksysguard repository .. and then there's the matter of binary 
compatibility in the library due to that (a number of practical solutions 
there available to us, though).

a process table and such seems a fairly important piece to the workspace, at 
least the desktop (can't imagine shipping without it, really?) ... 

possible options i can think of:

* don't split out ksysguard
* give libksysguard a binary compat strategy, make kde-workspace depend on it
* make the process table a generic plugin of some sort that krunner tries to 
load at runtime, making ksysguard "only" a runtime dependency

any other ideas?

(administrivia bit: if we want it split out, we'll have to write some more git 
conversion rules)


-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks


signature.asc
Description: This is a digitally signed message part.

Re: splitting up kdebase in git

[Aaron J. Seigo]

On Tuesday, January 18, 2011, Allen Winter wrote:
> On Tuesday 18 January 2011 4:34:21 pm Aaron J. Seigo wrote:
> > hi all ...
> > 
> > when looking at migrating kdebase to git (thanks to Ian Monroe for his
> > efforts there and for the support of KO Gmbh that helped make that
> > happen), it was decided to split it up into chunks which are:
> > 
> > * kdebase runtime (git -> kderuntime)
> > * kdebase workspace (git -> kdeworkspace)
> 
> could we do kde-runtime and kde-workspace instead?
> only because it's traditional (and because we already have git
> kdepim-runtime)

oops, sorry, probably just my mistake for not including a dash in there .. 
yeah, that's fine :)
 
> > * kdebase apps, minus konsole (git -> kdebase-apps)
> 
> I guess kde-apps won't work.
> maybe kde-baseapps?

i like that better, yes.. 

> > also, please keep all relevant discussion on kde-core-devel rather than
> > CC'ing all the lists; i just CC'd the lists so everyone there who may
> > not be on k-c-d as well receives the information :)
> 
> Having konsole, ksysguard, etc in their own git repo is fine.
> But they still will reside logically inside kdebase-apps
> 
> For example on api.kde.org the EBN and LXR.

yes, that's cool :)

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks


signature.asc
Description: This is a digitally signed message part.

Re: splitting up kdebase in git

[John Tapsell]

On 18 January 2011 23:13, Aaron J. Seigo  wrote:
> the complication there is that krunner also relies on libksyguard, which lives
> in kdebase/workspace/libs/ksysguard. so we'd either end up with a really odd
> dependency in ksysguard on kde-workspace, or kde-workspace would end up
> depending on the ksysguard repository .. and then there's the matter of binary
> compatibility in the library due to that (a number of practical solutions
> there available to us, though).

Oh, what happened to the idea of making  kde-workspace-libs  a
standalone repo?  Wouldn't that make sense?

Re: splitting up kdebase in git

[Aaron J. Seigo]

On Tuesday, January 18, 2011, John Tapsell wrote:
> On 18 January 2011 23:13, Aaron J. Seigo  wrote:
> > the complication there is that krunner also relies on libksyguard, which
> > lives in kdebase/workspace/libs/ksysguard. so we'd either end up with a
> > really odd dependency in ksysguard on kde-workspace, or kde-workspace
> > would end up depending on the ksysguard repository .. and then there's
> > the matter of binary compatibility in the library due to that (a number
> > of practical solutions there available to us, though).
> 
> Oh, what happened to the idea of making  kde-workspace-libs  a
> standalone repo?  Wouldn't that make sense?

it could be done, but there was no use case for that. keeping the repos 
together lets us not worry so much about binary compat, too.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks


signature.asc
Description: This is a digitally signed message part.

Re: splitting up kdebase in git

[John Tapsell]

On 18 January 2011 23:55, Aaron J. Seigo  wrote:
>> Oh, what happened to the idea of making  kde-workspace-libs  a
>> standalone repo?  Wouldn't that make sense?
>
> it could be done, but there was no use case for that. keeping the repos
> together lets us not worry so much about binary compat, too.

Ah.

Just leave ksysguard where it is then. :-)