QPixmap::handle(): Pixmap is not an X11 class pixmap
since updating to kubuntu 11.04 I am getting this message while KApplication is created, but only if I use raster or opengl as graphics system: kpat --graphicssystem raster QPixmap::handle(): Pixmap is not an X11 class pixmap this seems to happen with all KDE programs. Any idea? kdelibs 4.6.2 qt 4.7.2 -- Wolfgang
Re: Git Workflow - Outstanding Issues
On Freitag 18 März 2011, John Layt wrote: * Commit Template I've finally committed the Commit Template into kdelibs, any Git project that wants to use a different version can commit that to their own repo provided they follow the basic rules. would it be feasible to add a section like # --[ Notify packagers about changed dependencies ]---| #DEPS: -- Wolfgang
Re: Git Workflow - Outstanding Issues
On Samstag 19 März 2011, Parker Coates wrote: On Fri, Mar 18, 2011 at 23:25, Wolfgang Rohdewald wrote: On Freitag 18 März 2011, John Layt wrote: * Commit Template I've finally committed the Commit Template into kdelibs, any Git project that wants to use a different version can commit that to their own repo provided they follow the basic rules. would it be feasible to add a section like # --[ Notify packagers about changed dependencies ]---| #DEPS: Ideally, something as significant as changed dependencies should be discussed *before* the code is committed, no? Parker of course you are right in a stable branch of kdelibs, but in master, in smaller repos which might only have one or very few developers? For kajongg in KDE 4.6 some packagers did actually miss dependency changes, but I did not even know I should have actively notified them, I expected they would use some commit filters watching CMakeLists.txt. A reminder in the commit template seems like a good place to me for guiding the developers. so maybe not in kdelibs, but it might be useful in smaller repos like kajongg (assuming and hoping kdegames will be split into one repo per game) together with the server commit hook sending those mails to kde-build and kde-packager but then it should still be in the kdelibs commit template because that is the one other repos will copy and adapt. of course I could also do that in my local git repo commit hook - but that is not my point - if I don't know about the requirement to notify packagers, I dont do that anyway -- Wolfgang
need to backport patch in kinit/kinit_win.cpp to 4.6
Hi, when compiling kdelibs 4.6 on Windows, I get an error in kinit_win.cpp at line 110 (I am afraid I deleted it) but the commit in kdelibs below obviously fixes it. So I want to backport it to kdelibs. Would that be OK, and how would I do it? Like this: git checkout --track origin/KDE/4.6 git cherry-pick fd16288 git push or would I violate dozens of rules by doing so? i5:~/src/kdelibs.was/kinit$ git show fd16288 commit fd16288cedadf8ccf469df8a7be296763f5003d8 Author: Patrick Spendrin ps...@gmx.de Date: Sun Feb 20 21:39:20 2011 +0100 we need to cast by hand from wchar to ushort diff --git a/kinit/kinit_win.cpp b/kinit/kinit_win.cpp index 17266a4..9c1521a 100644 --- a/kinit/kinit_win.cpp +++ b/kinit/kinit_win.cpp @@ -107,7 +107,7 @@ QString toString(PSID sid) if (!ConvertSidToStringSid(sid, s)) return QString(); -QString result = QString::fromUtf16(s); +QString result = QString::fromUtf16(reinterpret_castushort*(s)); LocalFree(s); return result; } -- Wolfgang
Re: git workflow draft
On Freitag 18 Februar 2011, Parker Coates wrote: This is off topic, but is there a git tool to run a particular command (for example, cmake make ./test) for every commit in a range? Something like git-bisect without the bisecting. for commit in `git log 64d2c1e...ba634b6 --pretty='format:%h'` do echo test $commit done -- Wolfgang
Re: Usage of pull rebasing and merges
On Dienstag 08 Februar 2011, Christoph Feck wrote: I don't want to. Not yet. But the more I read here, the more confused I get. the book Pro Git was/is very helpful for me and easy to read. However my copy from 2009 does not mention rerere yet http://progit.org/2010/03/08/rerere.html -- Wolfgang
Re: Merge or Cherry-Pick?
On Mittwoch 02 Februar 2011, Thiago Macieira wrote: if I continue developing the app in master and fix some bugs on the way, the fixes will be in master first. I would not always want to put them into 4.6 at once because testing in master is much easier and comes at much less cost while development goes on. So I might even want to wait some days or even weeks until backporting fixes. Laziness is not an argument -- it's just an excuse. If you find a bug that applies to 4.6, why will you not fix it there? sometimes because 4.6 is already frozen, so I wait until I can commit for 4.6.1. In general I see first testing in master as an additional level of testing - after backporting to 4.6 I can still test that again as needed. and - how often did you test something only to find out later that the user does things differently and finds different bugs? using the bug-fixed master for development did already help me to avoid backporting bugs. In my experience, testing the stable releases is easier. Testing the development versions usually cause trouble because of unfinished features and untested new code. for Kajongg I am practically the only developer so I normally know what is going on but I like Felix's idea - create a new branch in master for every bug fix I expect to backport. I will definitely have to learn more about git... -- Wolfgang
Re: Merge or Cherry-Pick?
please ignore this - I should have first read the rest of the thread - others already had the same arguments On Donnerstag 03 Februar 2011, Wolfgang Rohdewald wrote: On Mittwoch 02 Februar 2011, Thiago Macieira wrote: if I continue developing the app in master and fix some bugs on the way, the fixes will be in master first. I would not always want to put them into 4.6 at once because testing in master is much easier and comes at much less cost while development goes on. So I might even want to wait some days or even weeks until backporting fixes. Laziness is not an argument -- it's just an excuse. If you find a bug that applies to 4.6, why will you not fix it there? sometimes because 4.6 is already frozen, so I wait until I can commit for 4.6.1. In general I see first testing in master as an additional level of testing - after backporting to 4.6 I can still test that again as needed. and - how often did you test something only to find out later that the user does things differently and finds different bugs? using the bug-fixed master for development did already help me to avoid backporting bugs. In my experience, testing the stable releases is easier. Testing the development versions usually cause trouble because of unfinished features and untested new code. for Kajongg I am practically the only developer so I normally know what is going on but I like Felix's idea - create a new branch in master for every bug fix I expect to backport. I will definitely have to learn more about git... -- Wolfgang
Re: Merge or Cherry-Pick?
On Dienstag 01 Februar 2011, Thiago Macieira wrote: That's not always true. Some changes will be specific to 4.6, because sections of code in master can get rewritten, features added or removed, so the changes won't be applicable there. That's not a problem or an excuse. Make the change in 4.6, merge to master, fix the conflicts and then push both branches. if I continue developing the app in master and fix some bugs on the way, the fixes will be in master first. I would not always want to put them into 4.6 at once because testing in master is much easier and comes at much less cost while development goes on. So I might even want to wait some days or even weeks until backporting fixes. -- Wolfgang
