Summary from Buildsystem BoF at Desktop Summit
Hi, last week at Desktop Summit we had a KDE buildsystem BoF, where we discussed the state of our buildsystem with regard to Qt5 and the KDE frameworks modularization efforts. The nice thing is it seems there is a small community building up around this topic :-) Attendees were: Marco Martin, Marcus Hanwell, Heinz Wiesinger (Slackware), David Faure, Sebastian Kuegler, Stephen Kelly, Guillaume (yoms), Sune Vuorela, John Layt, Volker Krause, Tobias Koenig, Alex Neundorf, Dirk Mueller, Emanuele Taponi and Raphael Cubo da Kosta. The following topics were discussed, details see below 1) Upstreaming stuff into cmake 2) Creating a separate project/package for not-upstreamable cmake modules 3) release tarballs 4) Superbuild 5) Required cmake version 6) finding KDE frameworks 7) (Getting rid of) kdeinit 8) Testing 9) a temporarily collapsing Sebas... 1) Upstreaming stuff into CMake This came up first in the platform meeting in Randa. People developing projects outside KDE (i.e. not depending on kdelibs), would like to use some of the cmake macros/modules we have in kdelibs, so we try to get things upstreamed into cmake. Not everything is suitable for being added to cmake, for different reasons, e.g. too specific, or nobody volunteering to maintain it in cmake. Things which will probably be in the next cmake include: - automoc - improved FeatureSummary.cmake, deprecating MacroLogFeature.cmake - a switch CMAKE_DISABLE_FIND_PACKAGE_PackageName to disable each find_package() explicitely, deprecating MacroOptionalFindPackage.cmake - synced most of our changes to Find-modules which exist in kdelibs and in CMake to CMake A full list can be found here: http://community.kde.org/KDE_Core/Platform_11/Buildsystem/FindFilesSurvey To make it short, most of our custom macros and our copies of existing Find- modules in kdelibs will not be necessary anymore. There was a discussion about kde4_add_executable()/add_library() and whether they are necessary or not and whether they are candidates for merging into CMake or not. David argued that if the logic contained in the macros is reasonable, it should qualify for being merged into CMake. Me (Alex) argued that most of the stuff in these macros adds only convenience for (lazy) KDE developers, and will probably not be accepted. David volunteered to make a list of features from kde4_add_executable()/add_library() he considers suitable for merging into CMake. All changes requiring modifications in the CMakeLists.txt are/will be documented here: http://techbase.kde.org/Development/ECM_SourceIncompatChanges 2) Creating a separate project/package for not-upstreamable cmake modules We have around 100 or more Find-modules in kdelibs. Most of them can be also useful to non-KDE projects and have no dependencies to KDE at all. It is not realistic to expect that all or most of them will be merged into CMake. For each of those module one volunteer would have to be found willing to maintain the Find-module in CMake. I don't see this happening. Beside that, it would also mean that we would depend always on the latest version of cmake which already ships with some new Find-module. So, instead, there'll be a separate project just containing custom Find- modules, named extra-cmake-modules: https://projects.kde.org/projects/kdesupport/extra-cmake-modules - not only targeted on KDE, but any project using cmake as its buildsystem - Needs a proper home page. Alex would love to use the Redmine wiki for that. - needs out of band, frequent releases - releases with Frameworks, but also intermediate releases possible - Find-modules from kdelibs have been copied by Allen to extra-cmake- modules/attic/, and need to be reviewed for coding style etc. before added to extra-cmake-modules for real - Stephen takes care of the releases of extra-cmake-modules - Alex will write a guideline for how to review the modules 3) Release tarballs We discussed released tarballs. With the transition to git not all packagers were happy about how the tarballs changed, the dependencies between them etc. Conclusions: - release tarball layout should not change (often) - if it does, needs documentation - dependencies / structure *inside* tarballs don't matter for packagers - dependency information should be available in a clear way (FindPackageLog.txt basically, which is created automatically in the build directory) - dependency version information not well maintained anyway - a web page which documents the dependencies would be nice, but it would have to be generated automatically - last but not least: also the Slackware packagers are ok with the new smaller modular tarballs, as long as the points above are met. There were no explicit actions planned beside that. 4) Superbuild
kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
On Monday, 15 de August de 2011 23:31:26 Alexander Neundorf wrote: - 7) (Getting rid of) kdeinit - There was a discussion about what makes a KDE application different from a non-KDE application. One thing is kdeinit, which is used to speed up load time of applications by running a daemon (kdeinit) which is linked against a set of shared libraries, and which dlopen()s the applications (i.e. their plugin) instead of simply executing them normally. - somebody (Volker ?) said that this speedup is still very much needed, especially on slower platforms, e.g. tablets - Dirk mentioned that at least on Linux, when building PIE executables (position independent executables), executables can be loaded also as shared object, and our special buildsystem magic would not be required anymore. But this would work only on Linux, with kernels = 2.6.10 (or so, i.e. already since a few years). Proposal: get rid of our build magic to create kdeinit modules, and simply create PIE executables on platforms that support it (i.e. at least Linux, no problem for Windows), keeping the advantages we have there. PIE executables do not have the same gain that kdeinit introduces. It's not at all the same thing. kdeinit can be replaced by prelinking, assuming you are not a user of the NVidia binary drivers. If you are, you can't prelink, so kdeinit is a help: /usr/sbin/prelink: /usr/bin/gears: Cannot prelink against non-PIC shared library /usr/lib/nvidia-current/libGL.so.1 Another advantage of kdeinit is to run the static constructors in libraries, something that prelinking can't do. I've been meaning to add an initialisation mode to Qt that would initialise things that can be safely shared, especially the loading of plugins. In my opinion, kdeinit should stay. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
On Tue, Aug 16, 2011 at 10:59:18AM +0200, Thiago Macieira wrote: In my opinion, kdeinit should stay. try to convince lennart of that. when i suggested to add kdeinit-like functionality to systemd his response was no way. and if we ignore systemd, we'll lose in the longer run. the selinux guys and some others hate us for kdeinit anyway. regarding nvidia, they know about the issue and have been enlightened about its severity? btw, why cannot non-pic libs be prelinked? works for non-pie executables, after all. Another advantage of kdeinit is to run the static constructors in libraries, [...] good luck with that... :}
Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
Hi, kdeinit can be replaced by prelinking, assuming you are not a user of the NVidia binary drivers. If you are, you can't prelink, so kdeinit is a help: /usr/sbin/prelink: /usr/bin/gears: Cannot prelink against non-PIC shared library /usr/lib/nvidia-current/libGL.so.1 The nvidia driver does a lot of tricks and libGL is not a PIC library, but that does not matter. My understanding was that kdeinit cannot be replaced by prelinking in any case since they are two different things. In harmattan the preloader is called booster, and it basically does a dlopen() on important libraries and we also use prelinking. They live together. I think prelink and kdeinit could work together, but please fix me. Prelink or cross-prelink could just be used by the distributions (but it should be done after install, just like debian does, prelink is setup in cron) to make it clear. :) Unfortunately I missed this session because of the football match. I think kdeinit is a nice thing over there. PIE executables had some different purpose, mostly security related. For some reason, some people started abusing them. There was an article by Jakub explaining this. I can not seem to find it right now. In any case, the main advantage of PIE executables was that the executable address space could be randomized, and ldconfig does randomize the address. Basically, this makes buffer-overruns more difficult. One thing is that ld.so ignores prelink information for PIE executables. Other than this I really see no point in them Best Regards, Laszlo Papp
Re: Summary from Buildsystem BoF at Desktop Summit
On Monday 15 August 2011 Aug, Alexander Neundorf wrote: Me (Alex) argued that most of the stuff in these macros adds only convenience for (lazy) KDE developers, and will probably not be accepted. Lazy is good... When doing a pure Qt app with CMake, I actually use a copy of all the KDE cmake extensions :-). - requiring that developers add find_package(kcore), find_package(kio), find_package(kjob) etc. is acceptable - there won't be a KDE4 compatibility file, among others because due to the reorganization there may not be libraries which exactly represent the functionality contained e.g. in kio now Altogether it looks like there will be a huge porting effort needed for a suite like calligra :-( -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
There was an article by Jakub explaining this. I can not seem to find it right now. Found! :) The first one: http://lwn.net/Articles/190495/ Why PIE should not be prelinked and in general about the main purpose of PIE. btw, why cannot non-pic libs be prelinked? works for non-pie executables, after all. Well, by definition, non-pic libraries cannot be prelinked since the symbols are at fixed addresses. You can not change the symbols using prelink. It is mentioned in the prelink manual [1], and prelink goes out of its way to find non-pic libraries and ignore them. You can just read the preface where it says why the libraries should be PIC, and how only PIC libraries can actually be prelinked. Oh, and one point. I am not familiar with systemd, but AFAIK too bloated as it is. It has a lot of code in it that should not be in the startup program, for instance: it has code to plymouth in it. That is a bit funny, but it might be just that I am lacking something... :) Best Regards, Laszlo Papp [1] http://docs.google.com/viewer?url=http%3A%2F%2Fpeople.redhat.com%2Fjakub%2Fprelink.pdf
Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
On Tuesday, 16 de August de 2011 12:50:47 Laszlo Papp wrote: Hi, kdeinit can be replaced by prelinking, assuming you are not a user of the NVidia binary drivers. If you are, you can't prelink, so kdeinit is a help: /usr/sbin/prelink: /usr/bin/gears: Cannot prelink against non-PIC shared library /usr/lib/nvidia-current/libGL.so.1 The nvidia driver does a lot of tricks and libGL is not a PIC library, but that does not matter. My understanding was that kdeinit cannot be replaced by prelinking in any case since they are two different things. They are different things, but in the end they are trying to solve the same problem: slowness at startup due to the loading of libraries and the processing of their relocations, plus sharing the otherwise non-sharable memory resulting from it. Unfortunately, comparing the results of the best that prelink can do (prelinked system, libs compiled with -Wl,-z,relro) and kdeinit, done by launching kwrite twice from the command-line and twice using kdeinit4_wrapper, I still see that kdeinit produces better results. My findings are: 1) the kdeinit executable is far larger in VSZ and just a bit larger in RSS (that's expected and is not a problem) 2) the kdeinit instance shares 32120 kB, whereas the non-kdeinit one shares 28536 kB. Again, no conclusion from here (the kdeinit instance is sharing memory that it won't need). 3) the kdeinit instance has 10120 kB non-shared, whereas the non-kdeinit one has 10296 kB. If we take away the heap and stack, we get the breakdown: kdeinit: 88 kB code, 244 kB RO data, 376 kB RW data non-kdeinit: 0 kB code, 620 kB RO data, 992 kB RW data All of the memory above is dirty, meaning in principle that it's non-sharable. That includes the 88 kB of code, which makes no sense at all to me. I'm guessing it's an effect of the prelinking, but still at loss to explain. Also note that those RO pages, due to the way that the loader and the linker work, do *not* include the .rodata sections. They are only the relro data -- that is, read-only data that requires relocations. In harmattan the preloader is called booster, and it basically does a dlopen() on important libraries and we also use prelinking. They live together. I think prelink and kdeinit could work together, but please fix me. Prelink or cross-prelink could just be used by the distributions (but it should be done after install, just like debian does, prelink is setup in cron) to make it clear. :) The booster also dlopens the plugins, I think, which further improves performance. The prelinker does not properly prelink plugins, since it doesn't know what uses them. That means a set of applications heavily dependent on plugins, like the Qt- and KDE-based apps, will still not be at ideal conditions with the prelinker. A workaround is to create a dummy binary or library that links to the plugins (violation of the definition, I know), so that the prelinker knows that it should work on them. Unfortunately I missed this session because of the football match. I think kdeinit is a nice thing over there. PIE executables had some different purpose, mostly security related. For some reason, some people started abusing them. There was an article by Jakub explaining this. I can not seem to find it right now. In any case, the main advantage of PIE executables was that the executable address space could be randomized, and ldconfig does randomize the address. Basically, this makes buffer-overruns more difficult. One thing is that ld.so ignores prelink information for PIE executables. Other than this I really see no point in them Another advantage of PIE is that the executable itself is position- independent, meaning that the code can be shared if more than one instance is loaded. For single-instance applications, this is not a gain. The disadvantage of PIE is the same of any position-independent code: one register is reserved (big problem on a register-starved CPU like the x86), data accesses are indirect, via the GOT, and function calls are also indirect via the PLT. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
On Tuesday, 16 de August de 2011 13:16:44 Laszlo Papp wrote: btw, why cannot non-pic libs be prelinked? works for non-pie executables, after all. Well, by definition, non-pic libraries cannot be prelinked since the symbols are at fixed addresses. You can not change the symbols using prelink. It is mentioned in the prelink manual [1], and prelink goes out of its way to find non-pic libraries and ignore them. You can just read the preface where it says why the libraries should be PIC, and how only PIC libraries can actually be prelinked. Technically, there two dimensions here and the PIC / non-PIC naming is misleading. Code position: fixed / movable Code cleanliness: clean (no relocations) / dirty (has text relocations) -fPIC creates clean, movable code. Without it, shared libraries are dirty, but still movable. Non-PIE applications, however, are both dirty and fixed. So the NVidia libraries have text relocations, but they are still position- independent. They can be loaded anywhere. The prelinker should be able to prelink it. A prelinked, non-PIC library is just like a Windows DLL: the PIC register is free and, if the loader can load it at its preferred address, will not dirty its pages (i.e., will be sharable). -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
On Tue, Aug 16, 2011 at 03:40:22PM +0200, Albert Astals Cid wrote: A Dimarts, 16 d'agost de 2011, Oswald Buddenhagen vàreu escriure: On Tue, Aug 16, 2011 at 10:59:18AM +0200, Thiago Macieira wrote: In my opinion, kdeinit should stay. try to convince lennart of that. when i suggested to add kdeinit-like functionality to systemd his response was no way. and if we ignore systemd, we'll lose in the longer run. So you are going to let a guy that has stated publicly that hates KDE where has he done that? and i mean literally, not according to your interpretation. decide KDE's future? it's a simple fact that gnome will determine the future of the linux desktop platform, simply because they have the people working on it and we don't. in fact, the pragmatic solution would be dropping the kde platform and concentrating on what we are good at: applications (and the underlying qt-based frameworks). and a workspace, for those 50% of our community who can believe in that plasma thingie.
Re: Summary from Buildsystem BoF at Desktop Summit
Boudewijn Rempt wrote: Lazy is good... When doing a pure Qt app with CMake, I actually use a copy of all the KDE cmake extensions :-). Which do you use? Do you also use them when creating libraries, not just apps?
Re: Re: Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
A Dimarts, 16 d'agost de 2011, Oswald Buddenhagen vàreu escriure: On Tue, Aug 16, 2011 at 03:40:22PM +0200, Albert Astals Cid wrote: A Dimarts, 16 d'agost de 2011, Oswald Buddenhagen vàreu escriure: On Tue, Aug 16, 2011 at 10:59:18AM +0200, Thiago Macieira wrote: In my opinion, kdeinit should stay. try to convince lennart of that. when i suggested to add kdeinit-like functionality to systemd his response was no way. and if we ignore systemd, we'll lose in the longer run. So you are going to let a guy that has stated publicly that hates KDE where has he done that? and i mean literally, not according to your interpretation. decide KDE's future? it's a simple fact that gnome will determine the future of the linux desktop platform, simply because they have the people working on it and we don't. in fact, the pragmatic solution would be dropping the kde platform and concentrating on what we are good at: applications (and the underlying qt-based frameworks). and a workspace, for those 50% of our community who can believe in that plasma thingie. I can't answer to so much enthusiasm. Albert ___ Kde-buildsystem mailing list kde-buildsys...@kde.org https://mail.kde.org/mailman/listinfo/kde-buildsystem
Re: Summary from Buildsystem BoF at Desktop Summit
On Tuesday 16 August 2011 Aug, Stephen Kelly wrote: Boudewijn Rempt wrote: Lazy is good... When doing a pure Qt app with CMake, I actually use a copy of all the KDE cmake extensions :-). Which do you use? Do you also use them when creating libraries, not just apps? Yes, also for creating libraries, unittests -- not for plugins, but that's all. -- Boudewijn Rempt http://www.valdyas.org, http://www.krita.org, http://www.boudewijnrempt.nl
Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
On Tuesday 16 August 2011, Albert Astals Cid wrote: A Dimarts, 16 d'agost de 2011, Oswald Buddenhagen vàreu escriure: On Tue, Aug 16, 2011 at 03:40:22PM +0200, Albert Astals Cid wrote: A Dimarts, 16 d'agost de 2011, Oswald Buddenhagen vàreu escriure: On Tue, Aug 16, 2011 at 10:59:18AM +0200, Thiago Macieira wrote: In my opinion, kdeinit should stay. try to convince lennart of that. when i suggested to add kdeinit-like functionality to systemd his response was no way. and if we ignore systemd, we'll lose in the longer run. So you are going to let a guy that has stated publicly that hates KDE where has he done that? and i mean literally, not according to your interpretation. decide KDE's future? it's a simple fact that gnome will determine the future of the linux desktop platform, simply because they have the people working on it and we don't. in fact, the pragmatic solution would be dropping the kde platform and concentrating on what we are good at: applications (and the underlying qt-based frameworks). and a workspace, for those 50% of our community who can believe in that plasma thingie. I can't answer to so much enthusiasm. When looking at this statement carefully, applications, the underlying qt- based frameworks and a workspace is actually pretty much what we do. Alex
Re: Summary from Buildsystem BoF at Desktop Summit
On Monday 15 August 2011 23.31.26 Alexander Neundorf wrote: [...] - 8) Testing - We shortly discussed testing, continuous builds and nightly builds. I hope Volker (or somebody) can write a better summary. Volker has a prototype for easily running VM-based builds on Linux-machines, which contribute their results to a cdash dashboard. Marcus introduced us to cdash@home, which has a similar purpose, i.e. make it very easy for people to contribute their machine as a continuous-build host to a project. It seems there is growing interest in establishing structured testing for KDE, also highlighted by Till's talk The limits of portability. More details to come... Don't forget that there is a trial up and running on http://build.kde.org This is a Jenkins installation that is currently triggered by the commit hooks and do continious build + test of kdelibs (KDE/4.7), kde-runtime (master), kdepimlibs (master), kdepim (master) and kdepim-runtime (master). The plan is to expand this to all (former) modules and atleast the stable and master branches. Any feedback regarding this site would be appreciated. /Regards Torgny signature.asc Description: This is a digitally signed message part.
Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
On Tuesday 16 August 2011, Thiago Macieira wrote: ... Another advantage of PIE is that the executable itself is position- independent, meaning that the code can be shared if more than one instance is loaded. For single-instance applications, this is not a gain. The disadvantage of PIE is the same of any position-independent code: one register is reserved (big problem on a register-starved CPU like the x86), data accesses are indirect, via the GOT, and function calls are also indirect via the PLT. ...not sure which email to reply too, so I just use this one. Maybe I didn't express clearly what I wanted to say, or I misunderstood Dirk, or Dirk was wrong. So, I try again, just to make sure there are no misunderstandings. Right now, for kdeinit-apps, we create a kdeinit module or plugin, which contains the actual application code, and additionally a tiny executable which loads this plugin and so runs the application. Beside that, we run a kdeinit instance, which can dlopen these plugins, and start the applications they contain. By doing this we save memory and time e.g. for relocations. The idea here was not to get rid of this mechanism completely. If I understood correctly, with a PIE executable it is possible to dlopen the executable and call a symbol from it. This would make it possible to simply create regular-looking, standalone executables instead of the combination of plugin+tiny executable, and at the same time keep the kdeinit instance around, which would then not dlopen the plugin, but dlopen the PIE executable, and call the symbol from the PIE executable instead of from the plugin, this way providing the same benefits as we have now. I.e. keep the mechanism, but without the necessity to split the executable into plugin+loader executable. Alex
Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
On Tue, Aug 16, 2011 at 07:24:19PM +0200, Alexander Neundorf wrote: When looking at this statement carefully, applications, the underlying qt- based frameworks and a workspace is actually pretty much what we do. we actually do a bit more, and the side threads of the recent systemsettings thread show that this is against the user's best interest (as kde failed to establish THE linux desktop platform as it was supposed to be). where exactly to draw the line between platform and just frameworks needs to be determined on a case by case basis, and depending on the cooperativeness of the respective gnomers.
Re: Summary from Buildsystem BoF at Desktop Summit
On Tuesday 16 August 2011, Boudewijn Rempt wrote: On Tuesday 16 August 2011 Aug, Stephen Kelly wrote: Boudewijn Rempt wrote: Lazy is good... When doing a pure Qt app with CMake, I actually use a copy of all the KDE cmake extensions :-). Which do you use? Do you also use them when creating libraries, not just apps? Yes, also for creating libraries, unittests -- not for plugins, but that's all. Can you please explain which macros exactly you are using, and why ? Thanks Alex
Re: Summary from Buildsystem BoF at Desktop Summit
On Tuesday 16 August 2011, Torgny Nyblom wrote: On Monday 15 August 2011 23.31.26 Alexander Neundorf wrote: [...] - 8) Testing - We shortly discussed testing, continuous builds and nightly builds. I hope Volker (or somebody) can write a better summary. Volker has a prototype for easily running VM-based builds on Linux-machines, which contribute their results to a cdash dashboard. Marcus introduced us to cdash@home, which has a similar purpose, i.e. make it very easy for people to contribute their machine as a continuous-build host to a project. It seems there is growing interest in establishing structured testing for KDE, also highlighted by Till's talk The limits of portability. More details to come... Don't forget that there is a trial up and running on http://build.kde.org This is a Jenkins installation that is currently triggered by the commit hooks and do continious build + test of kdelibs (KDE/4.7), kde-runtime (master), kdepimlibs (master), kdepim (master) and kdepim-runtime (master). The plan is to expand this to all (former) modules and atleast the stable and master branches. Any feedback regarding this site would be appreciated. There are currently several parties interested in running builds/test. There is you working on Jenkins, Volker is working on setting up virtual machines so users can do builds in a seti@home style, and Marcus is trying to see how cdash@home could fit for KDE. It would be good to coordinate the plans of the different people in some way. Should we do this on kde-buildsystem or somewhere else ? Do we want to set up machines which build everythings regularly ? Or do we want to find users interested in specific applications or libs setting up builds just for this one part ? How do we want to deal with covering different build options ? And how about the different operating systems we support ? Do we care more about fast turn around times for continuous builds and targeted email notifications (so I get an email really fast if I broke something), or are we more interested in getting complete builds done from time to time ? Alex
Re: Summary from Buildsystem BoF at Desktop Summit
On Tuesday 16 August 2011 19.48.39 Alexander Neundorf wrote: [...] There are currently several parties interested in running builds/test. There is you working on Jenkins, Volker is working on setting up virtual machines so users can do builds in a seti@home style, and Marcus is trying to see how cdash@home could fit for KDE. It would be good to coordinate the plans of the different people in some way. Should we do this on kde-buildsystem or somewhere else ? Anywhere is fine with me, but as we already have started (sort of) in kde- buildsystem lets stay there. (My view on the below might be biased as I'm pushing for the CI solution) Do we want to set up machines which build everythings regularly ? I don't realy see the point of this if (almost) every commit is built. Then those machines would only build stuff that is already built elsewhere. It is essentially a continious setup with a big polling window. Or do we want to find users interested in specific applications or libs setting up builds just for this one part ? The issue with this as I see it would be to ensure that they all use a valid environment. How do we want to deal with covering different build options ? Idealy every combination should be checked, but in reality I don't know. It will be quite hard to descide what combinations to try as the number of possibilities are almost endless. And how about the different operating systems we support ? Best case scenario would be a farm of machines (VMs?) that are triggered by a commit and build on every supported platform. Sort of parallell CI. Do we care more about fast turn around times for continuous builds and targeted email notifications (so I get an email really fast if I broke something), or are we more interested in getting complete builds done from time to time ? What is preventing both of these? A continious build machine will do a the equivivalent of a full build just that it does it in chunks. As for turnarond times, that depends on the participating HW and setups. There is some work to go as the state of our (at least the modules I've tried) unit tests are poor. /Regards Torgny signature.asc Description: This is a digitally signed message part.
Re: Summary from Buildsystem BoF at Desktop Summit
On Mon, Aug 15, 2011 at 3:31 PM, Alexander Neundorf neund...@kde.orgwrote: ** snip - 7) (Getting rid of) kdeinit - There was a discussion about what makes a KDE application different from a non-KDE application. One thing is kdeinit, which is used to speed up load time of applications by running a daemon (kdeinit) which is linked against a set of shared libraries, and which dlopen()s the applications (i.e. their plugin) instead of simply executing them normally. - somebody (Volker ?) said that this speedup is still very much needed, especially on slower platforms, e.g. tablets - Dirk mentioned that at least on Linux, when building PIE executables (position independent executables), executables can be loaded also as shared object, and our special buildsystem magic would not be required anymore. But this would work only on Linux, with kernels = 2.6.10 (or so, i.e. already since a few years). - on Windows kdeinit is not used at all - there was nobody there who knew exactly about the situation on OSX - not sure about FreeBSD Proposal: get rid of our build magic to create kdeinit modules, and simply create PIE executables on platforms that support it (i.e. at least Linux, no problem for Windows), keeping the advantages we have there. somebody said it's still important/needed, then dirk said we don't need it because of PIE executables on linux? Are we (cmake, etc.) building kde as PIE on linux already? thanks, Jeremy
Review Request: Handle focus in KUrlNavigator
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102345/ --- Review request for kdelibs. Summary --- This patch makes KUrlNavigator focusable. Also, QStyle::drawControl is used instead of QPainter::drawText in KUrlNavigatorButton, because accelerators are set in the buttons and drawText did not display them correctly. Diffs - kfile/kurlnavigator.cpp e71c979 kfile/kurlnavigatorbutton.cpp 5d38e56 kfile/kurlnavigatorbuttonbase.cpp 45f8eee kfile/kurlnavigatorbuttonbase_p.h 70aacb3 Diff: http://git.reviewboard.kde.org/r/102345/diff Testing --- Thanks, José
Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
On Tuesday, 16 de August de 2011 19:36:17 Alexander Neundorf wrote: The idea here was not to get rid of this mechanism completely. If I understood correctly, with a PIE executable it is possible to dlopen the executable and call a symbol from it. This would make it possible to simply create regular-looking, standalone executables instead of the combination of plugin+tiny executable, and at the same time keep the kdeinit instance around, which would then not dlopen the plugin, but dlopen the PIE executable, and call the symbol from the PIE executable instead of from the plugin, this way providing the same benefits as we have now. Ah, that makes a lot more sense. It's also closer to what the Harmattan booster does: it dlopens the actual binaries, not a kdenit module. However, it's still not perfectly correct: the issue is the difference between -fPIE and -fPIC. In a PIE, the compiler and linker *know* that this ELF module is the first open loaded, so they may take assumptions to that effect. In PIC, that isn't the case. So we're using an option that is specifically intended for stuff that is NOT dlopened. In practice, I don't know what optimisations may be attempted that would be problematic. It might just work, as Harmattan can show. Also: we need to be sure that prelinkers do prelink PIE, despite the article that Laszlo linked to. -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
On Tuesday 16 August 2011, Thiago Macieira wrote: On Tuesday, 16 de August de 2011 19:36:17 Alexander Neundorf wrote: The idea here was not to get rid of this mechanism completely. If I understood correctly, with a PIE executable it is possible to dlopen the executable and call a symbol from it. This would make it possible to simply create regular-looking, standalone executables instead of the combination of plugin+tiny executable, and at the same time keep the kdeinit instance around, which would then not dlopen the plugin, but dlopen the PIE executable, and call the symbol from the PIE executable instead of from the plugin, this way providing the same benefits as we have now. Ah, that makes a lot more sense. It's also closer to what the Harmattan booster does: it dlopens the actual binaries, not a kdenit module. However, it's still not perfectly correct: the issue is the difference between -fPIE and -fPIC. In a PIE, the compiler and linker *know* that this ELF module is the first open loaded, Sorry, I don't understand that sentence. Is there something missing ? Linker as in build time linker, or the loader ? Alex
Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
On Tuesday, 16 de August de 2011 16:55:57 Oswald Buddenhagen wrote: in fact, the pragmatic solution would be dropping the kde platform and concentrating on what we are good at: applications (and the underlying qt-based frameworks). and a workspace, for those 50% of our community who can believe in that plasma thingie. frameworks (qt-based), applications and workspace, that sounds pretty much what the KDE Platform is. What are you excluding in your definition? kded, klauncher, kdeinit, kglobalaccel, kwallet? -- Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org Software Architect - Intel Open Source Technology Center PGP/GPG: 0x6EF45358; fingerprint: E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358 signature.asc Description: This is a digitally signed message part.
Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
On Tuesday 16 Aug 2011 15:55:57 Oswald Buddenhagen wrote: On Tue, Aug 16, 2011 at 03:40:22PM +0200, Albert Astals Cid wrote: A Dimarts, 16 d'agost de 2011, Oswald Buddenhagen vàreu escriure: On Tue, Aug 16, 2011 at 10:59:18AM +0200, Thiago Macieira wrote: In my opinion, kdeinit should stay. try to convince lennart of that. when i suggested to add kdeinit-like functionality to systemd his response was no way. and if we ignore systemd, we'll lose in the longer run. So you are going to let a guy that has stated publicly that hates KDE where has he done that? and i mean literally, not according to your interpretation. I've certainly seen him state that he doesn't care about KDE, that we are irrelevent to anything he does, and he sees no reason to collaborate on anything with us. It's similar to his attitude towards *BSD. For someone working on key parts of the shared stack it is a disappointing attitude to have. decide KDE's future? it's a simple fact that gnome will determine the future of the linux desktop platform, simply because they have the people working on it and we don't. in fact, the pragmatic solution would be dropping the kde platform and concentrating on what we are good at: applications (and the underlying qt-based frameworks). and a workspace, for those 50% of our community who can believe in that plasma thingie. Walking away from the platform will eventually leave us with no future other than chasing Gnome's tail-lights and patching around infrastructure that doesn't meet our needs. If we leave Gnome to define the platform on their own then we let them define the desktop, and then we might as well all pack up and go home. To remain relevent we need to not only remain engaged in defining the platform but increase our involvement, we've allowed too many of the recent platform changes to be defined without our involvement and our devs and users have suffered as a result. The DS BoFs I participated in show that in most areas we can work productively with the Gnome developers and that they can benefit from working with us, we need to push those relationship building efforts more and stay engaged. Yes, reality is a lot of the platform now comes from funded Gnome / Red Hat work that we may not have the money or manpower to match, but that just means we have to learn to work with them where appropriate and leverage off the work they do. The hard part is figuring out how to convince them that their solutions will be better with our involvement early on rather than tacked on at the end. John.
Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
On Tuesday, 16 de August de 2011 20:53:45 Alexander Neundorf wrote:
However, it's still not perfectly correct: the issue is the difference
between -fPIE and -fPIC. In a PIE, the compiler and linker *know* that
this ELF module is the first open loaded,
Sorry, I don't understand that sentence. Is there something missing ?
Linker as in build time linker, or the loader ?
Both.
Rephrasing: when you use -fPIE to compile and -pie to link, the compiler, the
build-time linker and the runtime linker are under the assumption that your
code is the first ELF module to be loaded. That means the compiler and the
build-time linker may make use of certain constructions or relocations that
only work in the first ELF module and break elsewhere.
One such example are copy relocations, at least in non-PIC non-PIE code. When
you write in your code:
int main()
{
errno = 0;
}
The variable errno is exported from libc.so.6. But instead of fetching the
address of that variable via GOT from libc.so.6, or even instead of leaving a
relocation for the address of that variable in your main function's code, what
the linker does is *copy* the variable.
Your main function will contain an absolute, non-relocatable address to a
variable in the application's .data segment. Then, the .data segment contains
an R_386_COPY (or R_ARM_COPY) relocation, that tells ld.so to get the value
from libc.so.6, write it there, and then make every other ELF module refer to
this symbol, not the one in libc.so.6.
The same applies to another symbol familiar to us: QCoreApplication::self (a
private, static variable accessed in the inline QCoreApplication::instance
function).
If PIE executables still have copy relocations, we cannot dlopen them.
--
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
Software Architect - Intel Open Source Technology Center
PGP/GPG: 0x6EF45358; fingerprint:
E067 918B B660 DBD1 105C 966C 33F5 F005 6EF4 5358
signature.asc
Description: This is a digitally signed message part.
Re: Review Request: Handle focus in KUrlNavigator
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102345/#review5753 --- kfile/kurlnavigatorbutton.cpp http://git.reviewboard.kde.org/r/102345/#comment5108 The problem with using CE_PushButtonLabel is that the text is painted against the background color suited for buttons, i.e. QPalette::Button. The setPen stuff above the call has been added to make sure the text is visible on the background the navigator uses, which is QPalette::Window. There are several ways to resolve that: a. Keep using drawText, and add the correct Qt flag for accelerator drawing b. Use QStyle::drawItemText c. Adjust the palette, as is done some lines above (or reuse that palette by code refactoring). I would use b if you ask me. Note that you can remove the setPen stuff if you no longer use drawText. - Christoph On Aug. 16, 2011, 6:24 p.m., José Millán Soto wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/102345/ --- (Updated Aug. 16, 2011, 6:24 p.m.) Review request for kdelibs. Summary --- This patch makes KUrlNavigator focusable. Also, QStyle::drawControl is used instead of QPainter::drawText in KUrlNavigatorButton, because accelerators are set in the buttons and drawText did not display them correctly. Diffs - kfile/kurlnavigator.cpp e71c979 kfile/kurlnavigatorbutton.cpp 5d38e56 kfile/kurlnavigatorbuttonbase.cpp 45f8eee kfile/kurlnavigatorbuttonbase_p.h 70aacb3 Diff: http://git.reviewboard.kde.org/r/102345/diff Testing --- Thanks, José
Re: kdeinit (was: Summary from Buildsystem BoF at Desktop Summit)
Also: we need to be sure that prelinkers do prelink PIE, despite the article that Laszlo linked to. 1) prelink tries very very hard to skip PIE 2) ld.so ignores prelink information for PIE anyways so even if you force a PIE prelink you don't get anything There is no point in prelinking PIE since the prelink information is ignored. Best Regards, Laszlo Papp
How to see the resolution of merge of KDE/4.7 into KF5
Hi, I've just locally merged KDE/4.7 into frameworks. Before I push I want to review the conflicts and their resolutions, and I expect other developers would want to do the same. The merge showed that some commits in 4.7 have not made it into frameworks. We really should merge in that direction, not cherry-pick as everyone is currently doing. I couldn't make git show me the conflicts. I tried git show, which surprises me as it shows a 3 way diff of a single file which was apparently not in conflict (full output at http://steveire.com/mergecommit). I also tried several variations of git diff frameworks^...origin/KDE/4.7. How can I see the conflicts resolved in a merge? Do I just see no conlicts because I chose the frameworks branch in every hunk (which actually I don't think I did)? Thanks, Steve.
Re: Re: playground-libs/libkvkontakte has moved to kdereview
2011/8/15 Albert Astals Cid aa...@kde.org: A Dilluns, 15 d'agost de 2011, Alexander Potashev vàreu escriure: How about adding a QMapQString, QVariant m_ext; to *Info classes, so that I can store additional variables there? Most (but not all) *Job classes are unlikely to be expanded later, because they perform very simple operations. Why not simply use a d-pointer like it is explained in techbase? I thought about QMapQString, QVariant as of an easier solution since you won't need to declare the NoteInfoPrivate class. If I'll add just a forward declaration like class NoteInfoPrivate; and a NoteInfoPrivate *p; into the NoteInfo class, will it be OK? I guess you mean using a d-pointer, yes, that's the suggested way of dealing with this kind of issue. So, the NoteInfoPrivate class may not have any declaration (except for the forward declaration) until it will be necessary, right? -- Alexander Potashev
Re: Review Request: Avoid terminating a QThread in kio/kio/hostinfo.cpp
---
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/102238/
---
(Updated Aug. 17, 2011, 5:40 a.m.)
Review request for kdelibs, David Faure and Thiago Macieira.
Changes
---
- Modified the last patch so that the lookup thread is recycled and reused
instead of being discarded.
- Moved the timeout based name lookup code into an overloaded function in
HostInfoAgentPrivate.
- Changed keywords signals - Q_SIGNALS and slots - Q_SLOTS.
Summary (updated)
---
The attached patch is an alternate approach to address the issue of crashes
that arise from terminating an active thread than the one proposed at
https://git.reviewboard.kde.org/r/102179/. With this patch the function
QHostInfo::lookupHost(QString, int) avoids the use of QThread::terminate with
the following fairly simple changes:
- Connect its finished signal to its parent deleteLater slot in the ctor so
that the thread is automatically deleted later.
- Store the looked up DNS info in the global cache to avoid unnecessary
queries for the same request.
- Check for cached DNS information and avoid doing reverse look ups before
resorting to performing DNS queries in a separate thread.
Diffs (updated)
-
kio/kio/hostinfo.cpp 344b1d8
Diff: http://git.reviewboard.kde.org/r/102238/diff
Testing (updated)
---
Tested with the following code based on Albert's post.
#include hostinfo_p.h
#include QtGui/QApplication
#include QtCore/QElapsedTimer
#include QtNetwork/QHostInfo
int main(int a, char **b)
{
QApplication app(a, b);
QElapsedTimer t;
t.start();
qDebug() KIO::HostInfo::lookupHost(www.kde.org, 0).addresses();
qDebug() Time: t.elapsed() ms;
}
Thanks,
Dawit
Re: Re: playground-libs/libkvkontakte has moved to kdereview
2011/8/17 Alexander Potashev aspotas...@gmail.com: So, the NoteInfoPrivate class may not have any declaration (except for the forward declaration) until it will be necessary, right? There is Q_DECLARE_PRIVATE macro, interesting... Should I use it instead? -- Alexander Potashev
Re: Problems with checking out the code.
Hi, on Tuesday 16 August 2011 10:04:29 dmitry chernov wrote: I generated key with ssh-keygen -t dsa added ~/.ssh/config file as described here: http://techbase.kde.org/Contribute/Get_a_Contributor_Account Host *.kde.org User dmitryvchernov IdentityFile ~/.ssh/id_dsa uploaded my dsa public key to identity.kde.org, still it doesn't work for me: svn checkout svn+ssh://dmitryvcher...@svn.kde.org/home/kde/trunk/playground/games/backg ammon svn: To better debug SSH connection problems, remove the -q option from 'ssh' in the [tunnels] section of your Subversion configuration file. svn: Network connection closed unexpectedly Try this: thb@thb-nb:~/devel/kmymoney4 netcat svn.kde.org 22 SSH-2.0-OpenSSH_5.2 ^C punt! to check if you have a general connection problem. The line 'SSH-2.0 ...' is sent by the svn.kde.org server. -- Regards Thomas Baumgart GPG-FP: E55E D592 F45F 116B 8429 4F99 9C59 DB40 B75D D3BA - Embedded Linux: because you can't do control-alt-delete on a pacemaker. - signature.asc Description: This is a digitally signed message part. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Problems with checking out the code.
On Tue, Aug 16, 2011 at 8:04 PM, dmitry chernov diman4ik.cher...@gmail.com wrote: I generated key with ssh-keygen -t dsa added ~/.ssh/config file as described here: http://techbase.kde.org/Contribute/Get_a_Contributor_Account Host *.kde.org User dmitryvchernov IdentityFile ~/.ssh/id_dsa uploaded my dsa public key to identity.kde.org, still it doesn't work for me: Keys need to be synced from KDE Identity to the KDE Subversion and Git servers by a KDE Sysadmin at this time. I have now synced the keys, so you should be able to access svn.kde.org and git.kde.org now. svn checkout svn+ssh://dmitryvcher...@svn.kde.org/home/kde/trunk/playground/games/backgammon svn: To better debug SSH connection problems, remove the -q option from 'ssh' in the [tunnels] section of your Subversion configuration file. svn: Network connection closed unexpectedly On Mon, Aug 15, 2011 at 11:22 PM, Ludovic Grossard gross...@kde.org wrote: Le lundi 15 août 2011 20:57:21, dmitry chernov a écrit : If I generate a new key and submit it to https://identity.kde.org will it work? yes, it should Or I need kde sysadmin? no Maybe I can copy old key and store it in ~/.ssh? Will this work? It should work as well Ludo Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe Regards, Ben Cooksley KDE Sysadmin Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Removed folder icons in 4.7
Sorry, but I can´t understand how somebody can have such damaged ideas... It seems like a fair question to ask but you might want to wait for the explanation before you start labeling someone's thinking as 'damaged'. Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Removed folder icons in 4.7
Am 16.08.2011 15:42, schrieb Nathan Bradshaw: It seems like a fair question to ask but you might want to wait for the explanation before you start labeling someone's thinking as 'damaged'. Maybe I should... you´re right. Sorry, I was a bit angry about because I really couldn´t understand why... So, sorry for that. -- -o) Kim Leyendecker /\\ openSUSE Ambassador, openSUSE Wiki Team DE _\_v http://www.opensuse.org - Linux for open minds Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Problems with checking out the code.
Still it doesn't work. Maybe you can give me some hint how to debug the problem? On Tue, Aug 16, 2011 at 1:04 PM, Ben Cooksley bcooks...@kde.org wrote: On Tue, Aug 16, 2011 at 8:04 PM, dmitry chernov diman4ik.cher...@gmail.com wrote: I generated key with ssh-keygen -t dsa added ~/.ssh/config file as described here: http://techbase.kde.org/Contribute/Get_a_Contributor_Account Host *.kde.org User dmitryvchernov IdentityFile ~/.ssh/id_dsa uploaded my dsa public key to identity.kde.org, still it doesn't work for me: Keys need to be synced from KDE Identity to the KDE Subversion and Git servers by a KDE Sysadmin at this time. I have now synced the keys, so you should be able to access svn.kde.org and git.kde.org now. svn checkout svn+ssh:// dmitryvcher...@svn.kde.org/home/kde/trunk/playground/games/backgammon svn: To better debug SSH connection problems, remove the -q option from 'ssh' in the [tunnels] section of your Subversion configuration file. svn: Network connection closed unexpectedly On Mon, Aug 15, 2011 at 11:22 PM, Ludovic Grossard gross...@kde.org wrote: Le lundi 15 août 2011 20:57:21, dmitry chernov a écrit : If I generate a new key and submit it to https://identity.kde.orgwill it work? yes, it should Or I need kde sysadmin? no Maybe I can copy old key and store it in ~/.ssh? Will this work? It should work as well Ludo Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe Regards, Ben Cooksley KDE Sysadmin Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Removed folder icons in 4.7
Speaking of icons: is it my distribution's fault if I still have a mixture of the new and the old folder icon (the older one glossy, the newer one rather Gnome-y)? In most icon sizes I have the new icon, but in some (smaller) sizes and in KMail, I have the old one. I don't like the new one too much, but I'd like it to be consistent at least. I'm asking because with some KDE 4.6.x update these new icons were accidentally and partly introduced and I'm not sure if it is meant to be fixed now. Regards, Moritz Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Removed folder icons in 4.7
On Tue, Aug 16, 2011 at 07:28, Moritz Hobe m...@online.de wrote: Speaking of icons: is it my distribution's fault if I still have a mixture of the new and the old folder icon (the older one glossy, the newer one rather Gnome-y)? In most icon sizes I have the new icon, but in some (smaller) sizes and in KMail, I have the old one. I don't like the new one too much, but I'd like it to be consistent at least. I'm asking because with some KDE 4.6.x update these new icons were accidentally and partly introduced and I'm not sure if it is meant to be fixed now. Are you using Arch by any chance? I did a reinstall after the release of 4.7 and haven't seen that problem since, but I'm not sure if that's coincidental or not. Cheers, - Jeffery MacEachern Regards, Moritz Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Re: Removed folder icons in 4.7
Am Dienstag, 16. August 2011, 17:17:01 schrieb Matthias Fuchs: Am 16.08.2011 16:50, schrieb Moritz Hobe: Am Dienstag, 16. August 2011, 07:42:30 schrieb Jeffery MacEachern: On Tue, Aug 16, 2011 at 07:28, Moritz Hobem...@online.de wrote: Speaking of icons: is it my distribution's fault if I still have a mixture of the new and the old folder icon (the older one glossy, the newer one rather Gnome-y)? In most icon sizes I have the new icon, but in some (smaller) sizes and in KMail, I have the old one. I don't like the new one too much, but I'd like it to be consistent at least. I'm asking because with some KDE 4.6.x update these new icons were accidentally and partly introduced and I'm not sure if it is meant to be fixed now. Are you using Arch by any chance? I did a reinstall after the release of 4.7 and haven't seen that problem since, but I'm not sure if that's coincidental or not. Yes, I am :) Seems like something went wrong with the update then, but it's nothing to completely reinstall my machine for. Most likely the reason is that you still have some icons cached. Unfortunately I can't tell you where the icon cache resides straigt away. Nice. I removed it (it's a file called icon-cache.kcache in ~/.kde[4]/cache-[your hostname] if someone needs it) and it's fixed now. Thanks! Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Re: Removed folder icons in 4.7
On Tue, Aug 16, 2011 at 08:32, Moritz Hobe m...@online.de wrote: Am Dienstag, 16. August 2011, 17:17:01 schrieb Matthias Fuchs: Am 16.08.2011 16:50, schrieb Moritz Hobe: Am Dienstag, 16. August 2011, 07:42:30 schrieb Jeffery MacEachern: On Tue, Aug 16, 2011 at 07:28, Moritz Hobem...@online.de wrote: Speaking of icons: is it my distribution's fault if I still have a mixture of the new and the old folder icon (the older one glossy, the newer one rather Gnome-y)? In most icon sizes I have the new icon, but in some (smaller) sizes and in KMail, I have the old one. I don't like the new one too much, but I'd like it to be consistent at least. I'm asking because with some KDE 4.6.x update these new icons were accidentally and partly introduced and I'm not sure if it is meant to be fixed now. Are you using Arch by any chance? I did a reinstall after the release of 4.7 and haven't seen that problem since, but I'm not sure if that's coincidental or not. Yes, I am :) Seems like something went wrong with the update then, but it's nothing to completely reinstall my machine for. Oh, I wasn't suggesting that, of course - just mentioning it for the record. As you found below, that would indeed have been what fixed it (incidentally) in my case. Most likely the reason is that you still have some icons cached. Unfortunately I can't tell you where the icon cache resides straigt away. Nice. I removed it (it's a file called icon-cache.kcache in ~/.kde[4]/cache-[your hostname] if someone needs it) and it's fixed now. Thanks! Good to know! - Jeffery MacEachern Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
Re: Problems with checking out the code.
On 8/17/11, dmitry chernov diman4ik.cher...@gmail.com wrote: Still it doesn't work. Maybe you can give me some hint how to debug the problem? Make sure your key is properly uploaded to KDE Identity, save it, then ok that. On Tue, Aug 16, 2011 at 1:04 PM, Ben Cooksley bcooks...@kde.org wrote: On Tue, Aug 16, 2011 at 8:04 PM, dmitry chernov diman4ik.cher...@gmail.com wrote: I generated key with ssh-keygen -t dsa added ~/.ssh/config file as described here: http://techbase.kde.org/Contribute/Get_a_Contributor_Account Host *.kde.org User dmitryvchernov IdentityFile ~/.ssh/id_dsa uploaded my dsa public key to identity.kde.org, still it doesn't work for me: Keys need to be synced from KDE Identity to the KDE Subversion and Git servers by a KDE Sysadmin at this time. I have now synced the keys, so you should be able to access svn.kde.org and git.kde.org now. svn checkout svn+ssh:// dmitryvcher...@svn.kde.org/home/kde/trunk/playground/games/backgammon svn: To better debug SSH connection problems, remove the -q option from 'ssh' in the [tunnels] section of your Subversion configuration file. svn: Network connection closed unexpectedly On Mon, Aug 15, 2011 at 11:22 PM, Ludovic Grossard gross...@kde.org wrote: Le lundi 15 août 2011 20:57:21, dmitry chernov a écrit : If I generate a new key and submit it to https://identity.kde.orgwill it work? yes, it should Or I need kde sysadmin? no Maybe I can copy old key and store it in ~/.ssh? Will this work? It should work as well Ludo Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe Regards, Ben Cooksley KDE Sysadmin Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe Regards, Ben Cooksley KDE Sysadmin Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe
