Re: Review Request 123707: Set session manager discard command
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123707/ --- (Updated May 11, 2015, 4:20 a.m.) Review request for KDE Frameworks and Rex Dieter. Changes --- replaced filePath() with isFileLocal() Bugs: 346768 https://bugs.kde.org/show_bug.cgi?id=346768 Repository: kconfig Description --- If KConfig object provides a non-empty file path then set the session manager discard command to rm file path. This makes sure that obsolete session files are deleted after creating a new one. Diffs (updated) - src/core/kconfig.h 6cc7323 src/core/kconfig.cpp 3819716 src/gui/kconfiggui.h 173400f src/gui/kconfiggui.cpp 0048c60 Diff: https://git.reviewboard.kde.org/r/123707/diff/ Testing --- F22 kwrite konsole, ksmserver and Save Session... Thanks, Stefan Becker ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Mon, May 11, 2015, at 12:05 AM, Albert Astals Cid wrote: El Diumenge, 10 de maig de 2015, a les 23:47:32, Christian Mollekopf va escriure: On Sun, May 10, 2015, at 11:23 PM, Albert Astals Cid wrote: El Diumenge, 10 de maig de 2015, a les 22:31:10, Alexander Neundorf va escriure: On Sunday, May 10, 2015 15:39:02 David Faure wrote: On Sunday 10 May 2015 12:36:53 Christian Mollekopf wrote: * I'd consider Qt to be a lower level library. Qt mostly provides fundamentals just like libc or the STL, and it's therefore okay for me to just work with what I have available. I hope you can understand that the decision on how Qt (on one side) and KDE Frameworks (on the other side) should be released, does not only depend on the way *you* consider Qt and KF5. Other people have a different view on both (e.g. Qt developers do work on Qt, while app developers might treat KF5 as something fundamental where they just work with what they have available). You want to draw a line somewhere, while others draw it elsewhere, and yet we have to make decisions that work for everyone, not just for you. it's not just him. It's me (at work) too. Maybe many developers which use Qt at work (with an commercial license). There I have Qt available, as Christian says, it feels like a system library, our application is built on it. Now from time to time we need some additional functionality. This is the place where frameworks libraries could come in. The easier this is, the better. Easy would mean that if I need kfoo, and this depends on kcoreaddons and kwidgetaddons, I need to add only those three libs to my build, and when kfoo has a bugfix I need, I don't have to automatically update also kcoreaddons and kwidgetaddons, but only if this is really necessary (i.e. kfoo started using functionality from newer versions). This indeed requires that maintainers carefully maintain which versions of their dependencies are needed (sometimes not requiring the newest version is also a good thing). Honestly it is your job as creator of a product based on this libraries to decide if to upate to the next version with what it entails or to cherry-pick the bugfix into your code (as you do with Qt). What you're dreaming is a library that does what you want and has no dependencies, because for you the problem is not that updating kfoo may depends on kcoreaddons and kwidgetaddons, it is that has any dependencies at all, what if the same release that fixes the bug you need adds a new feature that introduces a dependency in liblava? You have the same problem. There's always the possibility of such problems, but they can be greatly reduced. Of course I understand that you'd prefer that we did this stabilization work instead of you, but you have to understand there's simply not the manpower to do this. I'd like to point out that all that is wanted that I'm allowed to do this for the libraries where I do the work, I don't exactly get what is do this, is it only not autoupdate the depencency versions to the other frameworks? Is it also not autoincreasing the version number? Is it something else? It's not autoincreasing the version number, and not autobumping the dependencies. As a maintainer I'd bump the version and dependencies myself, and the latest stable version could be released at any time from i.e. an always releasable master. So there would IMO be no additional overhead for other people. Cheers, Christian ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Opinions on KIO Slave side sorting? Possible GSoC project?
On Sun, May 3, 2015 at 12:44 AM, David Faure fa...@kde.org wrote: On Thursday 08 January 2015 10:45:13 Mark Gaiser wrote: (wow, time flies) The issue i see here is different processes. KIO::listDir is a process, KDirListerCache lives in the client process. I guess you didn't mean this litterally, because in that case it's wrong, both happen in the client process. You want to do sorting in both processes. 1. When the client initially asks a listing you want to do the sorting as quick as possible to send back as little data as possible. So sorting on the SlaveBase side. As long as not all data is known in the KDirListerCache sorting would have to be done on the SlaveBase side. That would be the case to change sort order _while_ data is dripping in. 2. When all data is fetched you don't want to go over a socket to request a different sorting method so then you would need to have the same sorting operations on the KIO client side with data fed from KDirListerCache. Obviously more complex than the current solution, but OK, let's see where that leads us. I do think that KIO would need a new class for this that can handle a set of predefined sorting and filtering operations if this entire slave side sorting is to be considered for KIO. Just to be clear, when i said slave side sorting i meant sorting in - for instance - SlaveBase. Not in the actual slave plugins. Where exactly, i don't know, but certainly before data is being send back to the application that requested a KIO::listDir. Sorry if i confused you here. Well, this requires the actual kioslave to first give all items to SlaveBase, doesn't it? Otherwise it can't sort them. So instead of incremental listing, this would wait until everything is available and then send everything; not sure it would appear faster to the user. (this depends on whether the time is spent doing the actually listing and creating of UDSEntries, or if more time is spent sending the stuff over the socket --- but you optimized that :-) The advantage i see with doing this is allowing data to be visible for the user as soon as data is available which will give the user a smoother and faster experience. Interesting you should say that, I think the suggested approach actually goes into the opposite direction from this goal. You need for all udsentries to exist before sorting, so it might take longer for the first items to appear, compared to the current solution, where a first set of items get sent over as soon as they are available, and then the other batch comes in and the two get sorted together. Which can make items move down, so I'm not saying it's ideal, but it technically does reach the above goal better :) It allows for a mechanism of show me the first 100 items of this massive folder in this particular sort order. Something that isn't fully possible right now since the client would have to wait till all data has arrived over the socket, then sort it, then present it. All data would still have to be fetched on the slave side, but only X number of entries would have to be send to the client allowing it to immediately present the data. The rest of the data can then be fetched on a need to know basis. Eg. when scrolling down for the next batch of 100 items. By that time the slave would probably (depending on the folder size and sort order) be done fetching all items and is ready to immediately send those pre sorted batches to the client. So the very first step is to find out how long it takes to create udsentries in the slave, and how long it takes to transfer them over the socket. If the first one is much bigger than the second one, then this idea would delay quite a lot the time until when the first items appear... An added advantage is that the client could then just use KIO as streaming API. Just like a youtube api or whatever streaming api. The client would just have to implement canFetchMode and fetchMode if the Qt classes are used. It should prevent the client from needing to implement complicated threading and UI tricks to keep the UI smooth. fetchMore is pull (get me more now), while entries get listed asynchronously and pushed via a signal, so I don't see how that would work, what would fetchMore really do? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 Time flies indeed! I completely forgot about this thread. Just going to respond here instead of inline. I fully agree with your comments and actually start to doubt the usefulness (again) of having a SlaveBase side sorting approach. I theory it sounds so neat to have a streaming api approach, but in practice the SlaveBase side would just have to wait till all items are fetched before it can sort. There would be a measurable time difference between: 1. SlaveBase fetching all items and sending a sorted batch to the client 2. and SlaveBase
Re: Versioning of Frameworks
On Sun, May 10, 2015, at 11:13 PM, David Faure wrote: On Sunday 10 May 2015 22:31:10 Alexander Neundorf wrote: There I have Qt available, as Christian says, it feels like a system library, our application is built on it. Well, I wish you would see KF5 as a natural extension of Qt, therefore a system library too, if you want to call it that. Now from time to time we need some additional functionality. This is the place where frameworks libraries could come in. The easier this is, the better. Easy would mean that if I need kfoo, and this depends on kcoreaddons and kwidgetaddons, I need to add only those three libs to my build, and when kfoo has a bugfix I need, I don't have to automatically update also kcoreaddons and kwidgetaddons, but only if this is really necessary (i.e. kfoo started using functionality from newer versions). Then just grab the bugfix, or adjust the required-version if you see it doesn't need functionality from a newer version. This indeed requires that maintainers carefully maintain which versions of their dependencies are needed You realize that many frameworks don't have a maintainer, right? At least 17 have officially none, others might have an inactive one. It's perfectly fine to continue doing what you do where noone is offering to do the work. I'd like to opt out of the version bumping practice for where I can do the work. Are you volunteering, or just making demands for others to do work for you? I'm volunteering to do the maintenance and release engineering for the libraries that matter to me, and I'm also prepared to work out a proposal on how to i.e. implement that opt-out mechanism. If such a change would make your job somehow more difficult I'd definitely also work on that if you tell me what breaks or just what you're release work currently is so I can figure it out myself. From my perspective you could simply release from an always releasable master and would get no additional effort. Cheers, Christian ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
El Diumenge, 10 de maig de 2015, a les 22:33:30, Christian Mollekopf va escriure: On Sun, May 10, 2015, at 03:39 PM, David Faure wrote: On Sunday 10 May 2015 12:36:53 Christian Mollekopf wrote: * I'd consider Qt to be a lower level library. Qt mostly provides fundamentals just like libc or the STL, and it's therefore okay for me to just work with what I have available. I hope you can understand that the decision on how Qt (on one side) and KDE Frameworks (on the other side) should be released, does not only depend on the way *you* consider Qt and KF5. Other people have a different view on both (e.g. Qt developers do work on Qt, while app developers might treat KF5 as something fundamental where they just work with what they have available). You want to draw a line somewhere, while others draw it elsewhere, and yet we have to make decisions that work for everyone, not just for you. I completely understand that. I'm searching for a solution that works for everyone, and I'm pointing out that the current situation does not work for me (as a maintainer of kimap that should become a framework, as a KDE PIM developer and as kolab developer). I only wanted to elaborate on why I can deal with the Qt situation, but can't really with the one in frameworks. I just want to point the obvious solution of you don't need to make kimap a framework, you can just release it yourself and problem fixed (not sure if anyone had before, it's a long thread :D) So for me each framework is an individual library, and should be treated as such, because I do want to work on the respective framework instead of running in my own circles in wherever I use the framework. I therefore need to be able to use the results of that work on all my target platforms, otherwise working on the framework is just having me implement the same thing twice. Making it possible for people to work on frameworks and then use the result in their applications quickly is exactly the reason why we have a monthly release cycle (unlike Qt). I'm trying to point out that this solution does not work for the scenario I want to use certain (soon to be) frameworks, which is deployed on a server in an enterprise environment. In these scenarios I can't just tell to run the proverbial yum update to pull in as many packages as I like. Either I manage to keep changes to a justifiable minimum that we can be tested sufficiently, or I have to implement a workaround. And implementing workarounds to use the real fixes a year later once we actually get to upgrade all systems to the required frameworks version is not a sustainable solution. You can implement stuff in KF5 and use it the month that follows in the layers above. In an enterprise environment I simply can't. This works very well for the developer on his bleeding edge machine, but in other cases just doesn't. In an enterprise environment, you control everything, just cherry-pick the fixes you need, since we're assuming here you need exactly the bugfixes you want (since you know which versions to update and where, etc) This is orthogonal to the discussion on version numbering, i.e. I definitely don't see this as an argument in favour of version hell. There are numerous reasons for me to advocate individual version numbers per library that are controlled by the maintainer, but I don't see the discussions as orthogonal: * I need the version number as a tool as maintainer to do some release engineering. * Bumping version numbers and dependencies periodically doesn't work for the enterprise usecase (due to random changes getting pulled in for an otherwise trivial update). That's nothing to do with bumping version numbers, and everything to do with the lack of a stable version, again as an enterprise, it's your task to productize the library if the library doesn't do everything you need. * By removing the version number we remove a valuable communication tool from the individual libraries. I appreciate all the work you're doing, and I'm certainly not trying to make your life or anyone elses harder, but these are actual problems I'm facing that I need to solve somehow, and that I think are solvable. But it would help to get some more input on what the actual problems on your end are other than some references to version hell. If we can solve the problems I'm also perfectly willing to do the work that is necessary. Cheers, Christian ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
El Diumenge, 10 de maig de 2015, a les 23:47:32, Christian Mollekopf va escriure: On Sun, May 10, 2015, at 11:23 PM, Albert Astals Cid wrote: El Diumenge, 10 de maig de 2015, a les 22:31:10, Alexander Neundorf va escriure: On Sunday, May 10, 2015 15:39:02 David Faure wrote: On Sunday 10 May 2015 12:36:53 Christian Mollekopf wrote: * I'd consider Qt to be a lower level library. Qt mostly provides fundamentals just like libc or the STL, and it's therefore okay for me to just work with what I have available. I hope you can understand that the decision on how Qt (on one side) and KDE Frameworks (on the other side) should be released, does not only depend on the way *you* consider Qt and KF5. Other people have a different view on both (e.g. Qt developers do work on Qt, while app developers might treat KF5 as something fundamental where they just work with what they have available). You want to draw a line somewhere, while others draw it elsewhere, and yet we have to make decisions that work for everyone, not just for you. it's not just him. It's me (at work) too. Maybe many developers which use Qt at work (with an commercial license). There I have Qt available, as Christian says, it feels like a system library, our application is built on it. Now from time to time we need some additional functionality. This is the place where frameworks libraries could come in. The easier this is, the better. Easy would mean that if I need kfoo, and this depends on kcoreaddons and kwidgetaddons, I need to add only those three libs to my build, and when kfoo has a bugfix I need, I don't have to automatically update also kcoreaddons and kwidgetaddons, but only if this is really necessary (i.e. kfoo started using functionality from newer versions). This indeed requires that maintainers carefully maintain which versions of their dependencies are needed (sometimes not requiring the newest version is also a good thing). Honestly it is your job as creator of a product based on this libraries to decide if to upate to the next version with what it entails or to cherry-pick the bugfix into your code (as you do with Qt). What you're dreaming is a library that does what you want and has no dependencies, because for you the problem is not that updating kfoo may depends on kcoreaddons and kwidgetaddons, it is that has any dependencies at all, what if the same release that fixes the bug you need adds a new feature that introduces a dependency in liblava? You have the same problem. There's always the possibility of such problems, but they can be greatly reduced. Of course I understand that you'd prefer that we did this stabilization work instead of you, but you have to understand there's simply not the manpower to do this. I'd like to point out that all that is wanted that I'm allowed to do this for the libraries where I do the work, I don't exactly get what is do this, is it only not autoupdate the depencency versions to the other frameworks? Is it also not autoincreasing the version number? Is it something else? Cheers, Albert ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123700: Fix build with cmake 2.8.12.2
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123700/#review80188 --- Ship it! Ship It! - Aleix Pol Gonzalez On May 9, 2015, 1:26 p.m., Jan Kundrát wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123700/ --- (Updated May 9, 2015, 1:26 p.m.) Review request for KDE Frameworks, KDEPIM and Albert Astals Cid. Bugs: 347399 http://bugs.kde.org/show_bug.cgi?id=347399 Repository: kpeople Description --- Fix build with cmake 2.8.12.2 Prior to 3.0, CMake didn't know how to handle the Q_GADGET macro, which means that its presence was not enough to trigger automoc run on these files. See [1] for a summary of the situation. [1] https://mail.kde.org/pipermail/kde-frameworks-devel/2014-December/020713.html BUG: 347399 REVIEW: 123700 Diffs - src/match.cpp f84a824 Diff: https://git.reviewboard.kde.org/r/123700/diff/ Testing --- Thanks, Jan Kundrát ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: changelog for 5.10
On Sat, May 9, 2015 at 3:00 PM, Sebastian Kügler se...@kde.org wrote: On Saturday, May 09, 2015 13:06:57 David Faure wrote: On Saturday 09 May 2015 12:52:52 Albert Astals Cid wrote: Why do we need a blog if we have an announcement? https://www.kde.org/announcements/kde-frameworks-5.10.0.php For the notification aspect of it, I think. The text is up there, but how do people know it's up there? If the announcement is also posted to the Dot, which we do with releases, it'll show up on planetkde and in feedreaders automatically. -- sebas http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel If it went to the dot that would be fine, definitely. I don't think it's the case though. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123654: Improve performance of KFileItem and KDirSortFilterProxyModel
On mei 10, 2015, 10:43 p.m., David Faure wrote: src/core/kfileitem.cpp, line 1115 https://git.reviewboard.kde.org/r/123654/diff/1/?file=366630#file366630line1115 I had the same thought as Milian... but I wonder why I wrote that comment. m_strText is the displayName, m_strName is not. Maybe I confused the two when I wrote it. That's my best guess right now. Mark: the first commit is about the current directory (.), the second commit is about urls without a filename, how does it make the first one obsolete? I don't see the relation. Well, i could be wrong (likely ;) if so, please correct me) but the return statement is checking if m_strName is 1 in length and if that string starts with a dot. By having the second commit the first one (the if statement) just doesn't seem to be needed anymore. Which is probably also what Aleix thought and removed the if. - Mark --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123654/#review80189 --- On mei 6, 2015, 2:35 a.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123654/ --- (Updated mei 6, 2015, 2:35 a.m.) Review request for KDE Frameworks. Repository: kio Description --- Reduces some operations in KDirSortFilterProxyModel. Removes usage of QUrl::fileName() in KFileItem::isHidden(), it comprised 75% of the time spent running the benchmark in here. Diffs - autotests/CMakeLists.txt 010074d autotests/kdirsortfilterproxymodel_benchmark.cpp PRE-CREATION src/core/kfileitem.cpp 344ac67 src/filewidgets/kdirsortfilterproxymodel.cpp 22ac025 Diff: https://git.reviewboard.kde.org/r/123654/diff/ Testing --- Everything seems to be working still, including tests. There was a comment about trash:/ triggering an assert, but I couldn't reproduce. Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123714: Only accept existing directories in FileMode::Directory mode
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123714/ --- (Updated May 10, 2015, 10:01 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Changes --- Submitted with commit 55fba9000550c4a043961631d435069226aaea27 by David Rosca to branch master. Repository: frameworkintegration Description --- This also implements other modes for fileMode command line option in qfiledialogtest. Diffs - src/platformtheme/kdeplatformfiledialoghelper.cpp 6178af4 tests/qfiledialogtest.cpp 4540e42 Diff: https://git.reviewboard.kde.org/r/123714/diff/ Testing --- Non-existant directories are no longer accepted. Thanks, David Rosca ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123713: KFileWidget: Don't accept files in directory only mode
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123713/ --- (Updated May 10, 2015, 10:01 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Changes --- Submitted with commit 74e7f27a41b76635dd5172f9dfd57deb882c794d by David Rosca to branch master. Repository: kio Description --- Don't accept files entered in location line edit when in directory only (KFile::Directory) mode. Diffs - src/filewidgets/kfilewidget.cpp 58dd92e Diff: https://git.reviewboard.kde.org/r/123713/diff/ Testing --- Files are no longer accepted in directory only mode Thanks, David Rosca ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: changelog for 5.10
On Mon, May 11, 2015 at 12:48 AM, David Faure fa...@kde.org wrote: On Saturday 09 May 2015 13:00:54 Sebastian Kügler wrote: On Saturday, May 09, 2015 13:06:57 David Faure wrote: On Saturday 09 May 2015 12:52:52 Albert Astals Cid wrote: Why do we need a blog if we have an announcement? https://www.kde.org/announcements/kde-frameworks-5.10.0.php For the notification aspect of it, I think. The text is up there, but how do people know it's up there? If the announcement is also posted to the Dot, which we do with releases, it'll show up on planetkde and in feedreaders automatically. If you think a monthly post about a KF5 release isn't too much, I can try posting there next time. My writing style is quite concise though, as you probably noticed in the kde-announce emails :-) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel After thinking about it a bit further, yeah maybe it would be best not to get it raw to the dot. Planet may be enough. Aleix ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Sunday, May 10, 2015 15:39:02 David Faure wrote: On Sunday 10 May 2015 12:36:53 Christian Mollekopf wrote: * I'd consider Qt to be a lower level library. Qt mostly provides fundamentals just like libc or the STL, and it's therefore okay for me to just work with what I have available. I hope you can understand that the decision on how Qt (on one side) and KDE Frameworks (on the other side) should be released, does not only depend on the way *you* consider Qt and KF5. Other people have a different view on both (e.g. Qt developers do work on Qt, while app developers might treat KF5 as something fundamental where they just work with what they have available). You want to draw a line somewhere, while others draw it elsewhere, and yet we have to make decisions that work for everyone, not just for you. it's not just him. It's me (at work) too. Maybe many developers which use Qt at work (with an commercial license). There I have Qt available, as Christian says, it feels like a system library, our application is built on it. Now from time to time we need some additional functionality. This is the place where frameworks libraries could come in. The easier this is, the better. Easy would mean that if I need kfoo, and this depends on kcoreaddons and kwidgetaddons, I need to add only those three libs to my build, and when kfoo has a bugfix I need, I don't have to automatically update also kcoreaddons and kwidgetaddons, but only if this is really necessary (i.e. kfoo started using functionality from newer versions). This indeed requires that maintainers carefully maintain which versions of their dependencies are needed (sometimes not requiring the newest version is also a good thing). Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Sunday 10 May 2015 22:31:10 Alexander Neundorf wrote: There I have Qt available, as Christian says, it feels like a system library, our application is built on it. Well, I wish you would see KF5 as a natural extension of Qt, therefore a system library too, if you want to call it that. Now from time to time we need some additional functionality. This is the place where frameworks libraries could come in. The easier this is, the better. Easy would mean that if I need kfoo, and this depends on kcoreaddons and kwidgetaddons, I need to add only those three libs to my build, and when kfoo has a bugfix I need, I don't have to automatically update also kcoreaddons and kwidgetaddons, but only if this is really necessary (i.e. kfoo started using functionality from newer versions). Then just grab the bugfix, or adjust the required-version if you see it doesn't need functionality from a newer version. This indeed requires that maintainers carefully maintain which versions of their dependencies are needed You realize that many frameworks don't have a maintainer, right? At least 17 have officially none, others might have an inactive one. Are you volunteering, or just making demands for others to do work for you? -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Monday 11 May 2015 00:13:27 Christian Mollekopf wrote: Are you volunteering, or just making demands for others to do work for you? I'm volunteering to do the maintenance and release engineering for the libraries that matter to me, and I'm also prepared to work out a proposal on how to i.e. implement that opt-out mechanism. Gah, this discussion is really not helped by the fact that I'm asking *Alex* some questions based on *his* requests, and *you* reply to these questions, while you have *other* requests to start with. You two are not asking for the same thing, so please don't mix up the two subthreads, it makes no sense for you to answer the questions that I'm asking Alex, who has different demands than you. Alex wants all frameworks to have tightly controlled separate version numbers, which therefore raises the question of who does that work. His request is as user of the frameworks. Your request is as a future maintainer of some frameworks, which is different, and only for the frameworks you'll maintain, which is different. If you want to increase version numbers at your own pace in your frameworks, then it means you are releasing them at your own pace. Basically it means a bunch of libs which are not part of the monthly KF5 release, but which have their own release schedule. They can be excluded from the release scripts by simply having release: false in their *.yaml file. I'll have to double-check that all scripts honour this (I think I have to fix the version-increasing scripts to check that), but that's doable. It just makes these libs not really frameworks, since they won't be part of the KF 5.11 release, but I guess that's fine, you'll sort out the versioning and messaging around them. From my perspective you could simply release from an always releasable master and would get no additional effort. I don't see how that would work. Say there was only one bugfix in kimap during one month, and no version number increase. What then? I can't just release from master since it would be a release with the same version number as the last release but with different contents. Don't assume you'll always remember to increase the version number every month, that's just wishful thinking. This case *will* happen and I don't want to have to handle it. If the versioning is independent, then the release schedule is independent, by definition. So basically you'd have libs which are released separately, whether we call them frameworks or not becomes purely a marketing question. When it comes to the version of the *dependencies* of your libs, they don't have to use the auto-increased KF5_DEP_VERSION. That's easy to opt out from. We'll just come back shouting when someone forgets to increase it correctly in your frameworks or some code that depends on them, but for now you have the benefit of the doubt :-) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123595: Fix KUser test for Mac.
On May 6, 2015, 5:40 p.m., René J.V. Bertin wrote: I'm not sure, after reading http://pig.made-it.com/uidgid.html also: ``` id nobody uid=4294967294(nobody) gid=4294967294(nobody) groups=4294967294(nobody),12(everyone),61(localaccounts),402(com.apple.sharepoint.group.1),403(com.apple.sharepoint.group.2),100(_lpoperator) ``` and ``` id unknown uid=99(_unknown) gid=99(_unknown) groups=99(_unknown),402(com.apple.sharepoint.group.1),12(everyone),61(localaccounts),403(com.apple.sharepoint.group.2),100(_lpoperator) ``` David Faure wrote: nobody is a special user, let's put that one aside since the unittest doesn't need it. I'm not sure `id` works like the APIs KUser uses. What does the unittest say for you, in fact? (with or without my patch, doesn't matter for debugging this) René J.V. Bertin wrote: I certainly hope that KUser agrees with `id` ... Sorry I can't answer your question, I haven't been touching KF5 at all until now. KUser just uses the stanard `getpwuid(3)`/`getpwnam(3)` function which AFAIK will also be used by `id`. - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123595/#review79976 --- On May 6, 2015, 5:08 p.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123595/ --- (Updated May 6, 2015, 5:08 p.m.) Review request for KDE Software on Mac OS X, KDE Frameworks and Marko Käning. Repository: kcoreaddons Description --- According to CI [1], an invalid user belongs to nogroup on Mac. Not sure if this is true on all OSX installations though? https://build.kde.org/view/Frameworks%20kf5-qt5/job/kcoreaddons%20master%20kf5-qt5/PLATFORM=OSX,compiler=clang/19/testReport/%28root%29/TestSuite/kusertest/ Diffs - autotests/kusertest.cpp d17a2d3e97d5056524281eb18766377e48a0da35 Diff: https://git.reviewboard.kde.org/r/123595/diff/ Testing --- Still passes on Linux; should fix the CI for mac, AFAICS. Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 123719: kbuildsycoca: parse all the mimeapps.list files mentionned in the new spec.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123719/ --- Review request for KDE Frameworks and Luc Menut. Repository: kservice Description --- http://standards.freedesktop.org/mime-apps-spec/mime-apps-spec-latest.html For now we treat Default Applications like Added Associations though. Separating the two requires quite many API changes in upper levels. Diffs - src/kbuildsycoca/kmimeassociations.h a7177370b1099f79e286b845495f3e8b06cb2363 src/kbuildsycoca/kmimeassociations.cpp 563fb04e4926731a21126cc75fb23b66bc14a177 Diff: https://git.reviewboard.kde.org/r/123719/diff/ Testing --- kservice unittests still pass, didn't add new tests for this though. Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Sun, May 10, 2015, at 03:39 PM, David Faure wrote: On Sunday 10 May 2015 12:36:53 Christian Mollekopf wrote: * I'd consider Qt to be a lower level library. Qt mostly provides fundamentals just like libc or the STL, and it's therefore okay for me to just work with what I have available. I hope you can understand that the decision on how Qt (on one side) and KDE Frameworks (on the other side) should be released, does not only depend on the way *you* consider Qt and KF5. Other people have a different view on both (e.g. Qt developers do work on Qt, while app developers might treat KF5 as something fundamental where they just work with what they have available). You want to draw a line somewhere, while others draw it elsewhere, and yet we have to make decisions that work for everyone, not just for you. I completely understand that. I'm searching for a solution that works for everyone, and I'm pointing out that the current situation does not work for me (as a maintainer of kimap that should become a framework, as a KDE PIM developer and as kolab developer). I only wanted to elaborate on why I can deal with the Qt situation, but can't really with the one in frameworks. So for me each framework is an individual library, and should be treated as such, because I do want to work on the respective framework instead of running in my own circles in wherever I use the framework. I therefore need to be able to use the results of that work on all my target platforms, otherwise working on the framework is just having me implement the same thing twice. Making it possible for people to work on frameworks and then use the result in their applications quickly is exactly the reason why we have a monthly release cycle (unlike Qt). I'm trying to point out that this solution does not work for the scenario I want to use certain (soon to be) frameworks, which is deployed on a server in an enterprise environment. In these scenarios I can't just tell to run the proverbial yum update to pull in as many packages as I like. Either I manage to keep changes to a justifiable minimum that we can be tested sufficiently, or I have to implement a workaround. And implementing workarounds to use the real fixes a year later once we actually get to upgrade all systems to the required frameworks version is not a sustainable solution. You can implement stuff in KF5 and use it the month that follows in the layers above. In an enterprise environment I simply can't. This works very well for the developer on his bleeding edge machine, but in other cases just doesn't. This is orthogonal to the discussion on version numbering, i.e. I definitely don't see this as an argument in favour of version hell. There are numerous reasons for me to advocate individual version numbers per library that are controlled by the maintainer, but I don't see the discussions as orthogonal: * I need the version number as a tool as maintainer to do some release engineering. * Bumping version numbers and dependencies periodically doesn't work for the enterprise usecase (due to random changes getting pulled in for an otherwise trivial update). * By removing the version number we remove a valuable communication tool from the individual libraries. I appreciate all the work you're doing, and I'm certainly not trying to make your life or anyone elses harder, but these are actual problems I'm facing that I need to solve somehow, and that I think are solvable. But it would help to get some more input on what the actual problems on your end are other than some references to version hell. If we can solve the problems I'm also perfectly willing to do the work that is necessary. Cheers, Christian ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123654: Improve performance of KFileItem and KDirSortFilterProxyModel
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123654/#review80187 --- autotests/kdirsortfilterproxymodel_benchmark.cpp (line 2) https://git.reviewboard.kde.org/r/123654/#comment55016 I think this line should be you and 2015. autotests/kdirsortfilterproxymodel_benchmark.cpp (line 20) https://git.reviewboard.kde.org/r/123654/#comment55017 QTest src/core/kfileitem.cpp (line 1115) https://git.reviewboard.kde.org/r/123654/#comment55018 For reference, this has been touched twice by David. 1. http://quickgit.kde.org/?p=kdelibs.gita=commith=f02db3fdf69fd582baa05e0c7bbcf948648618df 2. http://quickgit.kde.org/?p=kdelibs.gita=commith=dc76b579b10a0e16930c4c9d7a067c97315d0e54 It does seem that his second commit made the first one obsolete butnever got removed. That's just wishful thinking though.. Heprobably knows best :) src/filewidgets/kdirsortfilterproxymodel.cpp (lines 46 - 51) https://git.reviewboard.kde.org/r/123654/#comment55019 I don't see a reason for this, i probably miss something. The line where this was used (in the compare function) could just remain m_collator.setCaseSensitivity(caseSensitivity); right? src/filewidgets/kdirsortfilterproxymodel.cpp (line 83) https://git.reviewboard.kde.org/r/123654/#comment55020 Why change this? The changes in KDirSortFilterProxyModel seem unrelated to the performance improvements in KFileItem. I think it would be best to split them in two seperate RR's. - Mark Gaiser On mei 6, 2015, 2:35 a.m., Aleix Pol Gonzalez wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123654/ --- (Updated mei 6, 2015, 2:35 a.m.) Review request for KDE Frameworks. Repository: kio Description --- Reduces some operations in KDirSortFilterProxyModel. Removes usage of QUrl::fileName() in KFileItem::isHidden(), it comprised 75% of the time spent running the benchmark in here. Diffs - autotests/CMakeLists.txt 010074d autotests/kdirsortfilterproxymodel_benchmark.cpp PRE-CREATION src/core/kfileitem.cpp 344ac67 src/filewidgets/kdirsortfilterproxymodel.cpp 22ac025 Diff: https://git.reviewboard.kde.org/r/123654/diff/ Testing --- Everything seems to be working still, including tests. There was a comment about trash:/ triggering an assert, but I couldn't reproduce. Thanks, Aleix Pol Gonzalez ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kbuildsycoca5 crashing
On Sun, May 10, 2015 at 5:43 PM, Jeremy Whiting jpwhit...@kde.org wrote: Somehow kbuildsycoca5 is crashing here lately. I nuked my whole kde prefix (/usr/local) and rebuilt with packaged qt from my distro (arch). But kbuildsycoca5 is crashing every time I run it with some issue in QByteArray. Has anyone seen this lately/before or know how I can get past it? One of my config files broken or something? (I miss the days of ~/.kde where I could move that out of the way to figure out issues like this...) Here's a backtrace of the crash. Currently running in a gnome terminal in a gnome session to test and such while the rest of kde builds... Is your /home/jeremy/.cache/ksycoca5 owned by root or something? -- Bhushan Shah http://bhush9.github.io IRC Nick : bshah on Freenode ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
kbuildsycoca5 crashing
Hey all, Somehow kbuildsycoca5 is crashing here lately. I nuked my whole kde prefix (/usr/local) and rebuilt with packaged qt from my distro (arch). But kbuildsycoca5 is crashing every time I run it with some issue in QByteArray. Has anyone seen this lately/before or know how I can get past it? One of my config files broken or something? (I miss the days of ~/.kde where I could move that out of the way to figure out issues like this...) Here's a backtrace of the crash. Currently running in a gnome terminal in a gnome session to test and such while the rest of kde builds... [jeremy@chrom ~]$ kbuildsycoca5 Could not find drkonqi at /usr/local/lib/libexec/drkonqi QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. kbuildsycoca5 running... kf5.kservice.sycoca: Trying to open ksycoca from /home/jeremy/.cache/ksycoca5 kf5.kservice.sycoca: Trying to open global ksycoca from /home/jeremy/.local/share/kservices5/ksycoca5 kf5.kservice.sycoca: Trying to open ksycoca from /home/jeremy/.cache/ksycoca5 kf5.kservice.sycoca: Trying to open global ksycoca from /home/jeremy/.local/share/kservices5/ksycoca5 kf5.kservice.sycoca: Trying to open ksycoca from /home/jeremy/.cache/ksycoca5 kf5.kservice.sycoca: Trying to open global ksycoca from /home/jeremy/.local/share/kservices5/ksycoca5 Recreating ksycoca file (/home/jeremy/.cache/ksycoca5, version 300) KCrash: crashing... crashRecursionCounter = 2 KCrash: Application Name = kbuildsycoca5 path = /usr/local/bin pid = 30152 KCrash: Arguments: /usr/local/bin/kbuildsycoca5 Segmentation fault (core dumped) [jeremy@chrom ~]$ gdb kbuildsycoca5 GNU gdb (GDB) 7.9 Copyright (C) 2015 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as x86_64-unknown-linux-gnu. Type show configuration for configuration details. For bug reporting instructions, please see: http://www.gnu.org/software/gdb/bugs/. Find the GDB manual and other documentation resources online at: http://www.gnu.org/software/gdb/documentation/. For help, type help. Type apropos word to search for commands related to word... Reading symbols from kbuildsycoca5...done. (gdb) r Starting program: /usr/local/bin/kbuildsycoca5 [Thread debugging using libthread_db enabled] Using host libthread_db library /usr/lib/libthread_db.so.1. Could not find drkonqi at /usr/local/lib/libexec/drkonqi QDBusConnection: session D-Bus connection created before QCoreApplication. Application may misbehave. kbuildsycoca5 running... kf5.kservice.sycoca: Trying to open ksycoca from /home/jeremy/.cache/ksycoca5 kf5.kservice.sycoca: Trying to open global ksycoca from /home/jeremy/.local/share/kservices5/ksycoca5 kf5.kservice.sycoca: Trying to open ksycoca from /home/jeremy/.cache/ksycoca5 kf5.kservice.sycoca: Trying to open global ksycoca from /home/jeremy/.local/share/kservices5/ksycoca5 kf5.kservice.sycoca: Trying to open ksycoca from /home/jeremy/.cache/ksycoca5 kf5.kservice.sycoca: Trying to open global ksycoca from /home/jeremy/.local/share/kservices5/ksycoca5 Recreating ksycoca file (/home/jeremy/.cache/ksycoca5, version 300) Program received signal SIGSEGV, Segmentation fault. 0x00433644 in loadint (_q_value=@0x: error reading variable) at /usr/include/qt/QtCore/qgenericatomic.h:90 90return _q_value; (gdb) bt #0 0x00433644 in loadint (_q_value=@0x: error reading variable) at /usr/include/qt/QtCore/qgenericatomic.h:90 #1 QBasicAtomicIntegerint::load (this=0x) at /usr/include/qt/QtCore/qbasicatomic.h:110 #2 0x00432038 in QtPrivate::RefCount::ref (this=0x) at /usr/include/qt/QtCore/qrefcount.h:49 #3 0x0043242b in QByteArray::QByteArray (this=0x69b900, a=...) at /usr/include/qt/QtCore/qbytearray.h:461 #4 0x004334b5 in KSycocaResource::KSycocaResource (this=0x69b900) at /home/jeremy/devel/kde/src/frameworks/kservice/src/kbuildsycoca/ksycocaresourcelist.h:25 #5 0x004363fb in QLinkedListNodeKSycocaResource::QLinkedListNode (this=0x69b8f0, arg=...) at /usr/include/qt/QtCore/qlinkedlist.h:65 #6 0x00437a59 in QLinkedListKSycocaResource::detach_helper2 (this=0x69b140, orgite=...) at /usr/include/qt/QtCore/qlinkedlist.h:275 #7 0x004363d0 in QLinkedListKSycocaResource::detach (this=0x69b140) at /usr/include/qt/QtCore/qlinkedlist.h:99 #8 0x00439209 in QLinkedListKSycocaResource::append (this=0x69b140, t=...) at /usr/include/qt/QtCore/qlinkedlist.h:366 #9 0x004391c2 in KSycocaResourceList::add (this=0x69b140, resource=..., subdir=..., filter=...) at /home/jeremy/devel/kde/src/frameworks/kservice/src/kbuildsycoca/ksycocaresourcelist.h:44 #10 0x0043bd8e in KBuildServiceTypeFactory::KBuildServiceTypeFactory (this=0x697520) at
Re: kbuildsycoca5 crashing
It sure isn't. I've also tried nuking ~/.cache/ksycoca5* and such. Same result. ~/.cache is owned by me and has decent permissions also. On Sun, May 10, 2015 at 6:21 AM, Bhushan Shah bhus...@gmail.com wrote: On Sun, May 10, 2015 at 5:43 PM, Jeremy Whiting jpwhit...@kde.org wrote: Somehow kbuildsycoca5 is crashing here lately. I nuked my whole kde prefix (/usr/local) and rebuilt with packaged qt from my distro (arch). But kbuildsycoca5 is crashing every time I run it with some issue in QByteArray. Has anyone seen this lately/before or know how I can get past it? One of my config files broken or something? (I miss the days of ~/.kde where I could move that out of the way to figure out issues like this...) Here's a backtrace of the crash. Currently running in a gnome terminal in a gnome session to test and such while the rest of kde builds... Is your /home/jeremy/.cache/ksycoca5 owned by root or something? -- Bhushan Shah http://bhush9.github.io IRC Nick : bshah on Freenode Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123713: KFileWidget: Don't accept files in directory only mode
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123713/#review80162 --- Ship it! - David Faure On May 10, 2015, 9:37 a.m., David Rosca wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123713/ --- (Updated May 10, 2015, 9:37 a.m.) Review request for KDE Frameworks. Repository: kio Description --- Don't accept files entered in location line edit when in directory only (KFile::Directory) mode. Diffs - src/filewidgets/kfilewidget.cpp 58dd92e Diff: https://git.reviewboard.kde.org/r/123713/diff/ Testing --- Files are no longer accepted in directory only mode Thanks, David Rosca ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123714: Only accept existing directories in FileMode::Directory mode
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123714/#review80163 --- Ship it! Ship It! - David Faure On May 10, 2015, 9:56 a.m., David Rosca wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123714/ --- (Updated May 10, 2015, 9:56 a.m.) Review request for KDE Frameworks. Repository: frameworkintegration Description --- This also implements other modes for fileMode command line option in qfiledialogtest. Diffs - src/platformtheme/kdeplatformfiledialoghelper.cpp 6178af4 tests/qfiledialogtest.cpp 4540e42 Diff: https://git.reviewboard.kde.org/r/123714/diff/ Testing --- Non-existant directories are no longer accepted. Thanks, David Rosca ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123706: Forward QSessionManager to KConfigGui
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123706/#review80164
---
src/kmainwindow.cpp (line 122)
https://git.reviewboard.kde.org/r/123706/#comment55008
If you keep this (see below), then use ctor initialization syntax
: initial(true)
{
...
}
src/kmainwindow.cpp (line 151)
https://git.reviewboard.kde.org/r/123706/#comment55009
It does that, but on X11 only, and to perform an initial checkpoint. Why
not actually honour the request and save settings as requested? I guess it's
useful in case the app crashes.
Why does saving here orphan session files?
Would QSessionManager::setDiscardCommand() help?
- David Faure
On May 10, 2015, 10:15 a.m., Stefan Becker wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/123706/
---
(Updated May 10, 2015, 10:15 a.m.)
Review request for KDE Frameworks and Rex Dieter.
Bugs: 346768
https://bugs.kde.org/show_bug.cgi?id=346768
Repository: kxmlgui
Description
---
Get a KConfig object that corresponds to the QSessionManager object that is
passed in with the saveStateRequest signal.
To make sure that the data is stored to disk we have to call sync() on the
object after the application has updated it. As the session manager always
emits a saveStateRequest after starting the application we need to skip the
sync() for the first request and instead mark it as clean.
Diffs
-
src/kmainwindow.cpp 15eecb7
src/kmainwindow_p.h 8204ce1
Diff: https://git.reviewboard.kde.org/r/123706/diff/
Testing
---
On F22 with kwrite konsole
Thanks,
Stefan Becker
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 123713: KFileWidget: Don't accept files in directory only mode
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123713/ --- Review request for KDE Frameworks. Repository: kio Description --- Don't accept files entered in location line edit when in directory only (KFile::Directory) mode. Diffs - src/filewidgets/kfilewidget.cpp 58dd92e Diff: https://git.reviewboard.kde.org/r/123713/diff/ Testing --- Files are no longer accepted in directory only mode Thanks, David Rosca ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123705: Add 2nd variant for KConfigGui::sessionConfig()
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123705/ --- (Updated May 10, 2015, 10:30 a.m.) Review request for KDE Frameworks and Rex Dieter. Changes --- updated based on review comments Bugs: 346768 https://bugs.kde.org/show_bug.cgi?id=346768 Repository: kconfig Description (updated) --- When the application receives a saveState signal it needs to replace the current KConfig object with a new one based on the QSessionManager information. Add a new variant that accepts the session manager object. Diffs (updated) - src/gui/kconfiggui.h 173400f src/gui/kconfiggui.cpp 0048c60 Diff: https://git.reviewboard.kde.org/r/123705/diff/ Testing --- On F22 with kwrite konsole Thanks, Stefan Becker ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123707: Set session manager discard command
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123707/ --- (Updated May 10, 2015, 10:47 a.m.) Review request for KDE Frameworks and Rex Dieter. Changes --- updated based on review comments Bugs: 346768 https://bugs.kde.org/show_bug.cgi?id=346768 Repository: kconfig Description (updated) --- If KConfig object provides a non-empty file path then set the session manager discard command to rm file path. This makes sure that ksmserver removes old obsolete session files after storing a new session. Diffs (updated) - src/core/kconfig.h 6cc7323 src/core/kconfig.cpp 3819716 src/gui/kconfiggui.h 173400f src/gui/kconfiggui.cpp 0048c60 Diff: https://git.reviewboard.kde.org/r/123707/diff/ Testing --- F22 kwrite konsole, ksmserver and Save Session... Thanks, Stefan Becker ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Sat, May 9, 2015, at 01:27 PM, David Faure wrote: On Saturday 09 May 2015 13:08:35 Alexander Neundorf wrote: we pretend it's all independent libraries but still they all depend on the latest version of all other libs. It's a question of the definition of independent. E.g. KCoreAddons and Solid are independent because you can use either one without being forced to use the other. The fact that they are released together doesn't change that. Indeed, the split up is in any case a valuable change from what it used to be. KCoreAddons and KIO are partially independent because KIO depends on KCoreAddons, but still there is a huge improvement there compared to the kdelibs4 situation where such inter-library-dependencies were far too numerous so it was basically all-or-nothing. Having split two such libraries still helps tremendously, since one can use KCoreAddons without using KIO. The fact that KIO-5.10 requires KCoreAddons-5.10 is IMHO no different from the fact that QtGui-5.6 requires QtCore-5.6. Are you saying that Qt didn't go all the way or didn't split properly because of the fact that QtGui-5.6 requires QtCore-5.6? (same thing with other Qt libs from other modules than qtbase, this isn't limited to qtbase) I do think the same problem applies to Qt, and yes as long as they have the same version for all libraries they are not completely independent. It may be less of a problem for Qt though than it is for frameworks IMO. I still don't understand why this is fine for Qt and not for KDE Frameworks. Two reasons why Qt can get away with treating it as a single library (which it IMO largely does): * Qt libraries tend to be less volatile. I can implement most functionality I require today on top of Qt 4.6. That means I simply implement workarounds for what I don't have available on an older system, and I typically don't even consider changing something in Qt (which is a shame because it keeps me from improving Qt). We therefore simply avoid updating Qt as far as possible, because if we have to we indeed also have this giant blob to update. * I'd consider Qt to be a lower level library. Qt mostly provides fundamentals just like libc or the STL, and it's therefore okay for me to just work with what I have available. Qt does include a *lot* of stuff though, which I think Qt would also benefit from truly splitting up libraries. Frameworks for me is an umbrella for various libraries, and not a single library. If it were a single library it would be an everything and the kitchen sink library, which I really don't think is something we should be aiming for. So for me each framework is an individual library, and should be treated as such, because I do want to work on the respective framework instead of running in my own circles in wherever I use the framework. I therefore need to be able to use the results of that work on all my target platforms, otherwise working on the framework is just having me implement the same thing twice. So as a summary, it's only fine for Qt because I never ever have to touch Qt, which is not a good thing either. Cheers, Christian ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123706: Forward QSessionManager to KConfigGui
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123706/ --- (Updated May 10, 2015, 10:15 a.m.) Review request for KDE Frameworks and Rex Dieter. Changes --- updated after kconfig review comments Bugs: 346768 https://bugs.kde.org/show_bug.cgi?id=346768 Repository: kxmlgui Description (updated) --- Get a KConfig object that corresponds to the QSessionManager object that is passed in with the saveStateRequest signal. To make sure that the data is stored to disk we have to call sync() on the object after the application has updated it. As the session manager always emits a saveStateRequest after starting the application we need to skip the sync() for the first request and instead mark it as clean. Diffs (updated) - src/kmainwindow.cpp 15eecb7 src/kmainwindow_p.h 8204ce1 Diff: https://git.reviewboard.kde.org/r/123706/diff/ Testing --- On F22 with kwrite konsole Thanks, Stefan Becker ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 123714: Only accept existing directories in FileMode::Directory mode
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123714/ --- Review request for KDE Frameworks. Repository: frameworkintegration Description --- This also implements other modes for fileMode command line option in qfiledialogtest. Diffs - src/platformtheme/kdeplatformfiledialoghelper.cpp 6178af4 tests/qfiledialogtest.cpp 4540e42 Diff: https://git.reviewboard.kde.org/r/123714/diff/ Testing --- Non-existant directories are no longer accepted. Thanks, David Rosca ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: debugfull - debug
On Thursday 07 May 2015 22:57:47 Jaroslaw Staniek wrote: Hi, As with some other bits of knowledge during porting today I just share this one: https://community.kde.org/index.php?title=Calligra/Building/3diff=42353old id=42349 When you use Qt4/KF5, debugfull is dead [1] so you'd be surprised debugging isn't working for you. We don't have any precise recipe from the core folks involved in the kf5, I can only say the above works like before when you also set CMAKE_CXX_FLAGS_DEBUG:STRING=-g3 CMAKE_C_FLAGS_DEBUG:STRING=-g3 in your cmake cache. CC'd the kf list so maybe my lame solution could be improved and find its way to the porting notes [2]. Yep, I think that's the best approach if you want to replicate the old debugfull behaviour. I've added it to the porting notes. Alex ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123705: Add KConfigGui::setSessionConfig()
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123705/#review80176 --- Ship it! So now we have a setter that returns a value ;) Unusual, but ok, I'm not sure the alternative is better (setSessionConfig + calling sessionConfig() to get it). src/gui/kconfiggui.h (line 68) https://git.reviewboard.kde.org/r/123705/#comment55013 Needs to be more complete: @deprecated since 5.11, use sessionConfig()-name() - David Faure On May 10, 2015, 4:01 p.m., Stefan Becker wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123705/ --- (Updated May 10, 2015, 4:01 p.m.) Review request for KDE Frameworks and Rex Dieter. Bugs: 346768 https://bugs.kde.org/show_bug.cgi?id=346768 Repository: kconfig Description --- When the application receives a saveState signal it needs to replace the current KConfig object with a new one based on the QSessionManager information. Add a new interface that accepts the session manager object. Diffs - src/gui/kconfiggui.h 173400f src/gui/kconfiggui.cpp 0048c60 Diff: https://git.reviewboard.kde.org/r/123705/diff/ Testing --- On F22 with kwrite konsole Thanks, Stefan Becker ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123706: Forward QSessionManager to KConfigGui
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123706/#review80177 --- Ship it! Ship It! - David Faure On May 10, 2015, 4:05 p.m., Stefan Becker wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123706/ --- (Updated May 10, 2015, 4:05 p.m.) Review request for KDE Frameworks and Rex Dieter. Bugs: 346768 https://bugs.kde.org/show_bug.cgi?id=346768 Repository: kxmlgui Description --- Get a KConfig object that corresponds to the QSessionManager object that is passed in with the saveStateRequest signal. To make sure that the data is stored to disk we have to call sync() on the object after the application has updated it. Diffs - src/kmainwindow.cpp 15eecb7 Diff: https://git.reviewboard.kde.org/r/123706/diff/ Testing --- On F22 with kwrite konsole Thanks, Stefan Becker ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123706: Forward QSessionManager to KConfigGui
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123706/ --- (Updated May 10, 2015, 5:12 p.m.) Review request for KDE Frameworks and Rex Dieter. Changes --- updated Bugs: 346768 https://bugs.kde.org/show_bug.cgi?id=346768 Repository: kxmlgui Description --- Get a KConfig object that corresponds to the QSessionManager object that is passed in with the saveStateRequest signal. To make sure that the data is stored to disk we have to call sync() on the object after the application has updated it. Diffs (updated) - src/kmainwindow.cpp 15eecb7 Diff: https://git.reviewboard.kde.org/r/123706/diff/ Testing --- On F22 with kwrite konsole Thanks, Stefan Becker ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123707: Set session manager discard command
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123707/ --- (Updated May 10, 2015, 5:11 p.m.) Review request for KDE Frameworks and Rex Dieter. Changes --- rebased Bugs: 346768 https://bugs.kde.org/show_bug.cgi?id=346768 Repository: kconfig Description --- If KConfig object provides a non-empty file path then set the session manager discard command to rm file path. This makes sure that obsolete session files are deleted after creating a new one. Diffs (updated) - src/core/kconfig.h 6cc7323 src/core/kconfig.cpp 3819716 src/gui/kconfiggui.h 173400f src/gui/kconfiggui.cpp 0048c60 Diff: https://git.reviewboard.kde.org/r/123707/diff/ Testing --- F22 kwrite konsole, ksmserver and Save Session... Thanks, Stefan Becker ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123705: Add KConfigGui::setSessionConfig()
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123705/ --- (Updated May 10, 2015, 5:10 p.m.) Review request for KDE Frameworks and Rex Dieter. Changes --- make it a real setter and update the deprecated information Bugs: 346768 https://bugs.kde.org/show_bug.cgi?id=346768 Repository: kconfig Description --- When the application receives a saveState signal it needs to replace the current KConfig object with a new one based on the QSessionManager information. Add a new interface that accepts the session manager object. Diffs (updated) - src/gui/kconfiggui.h 173400f src/gui/kconfiggui.cpp 0048c60 Diff: https://git.reviewboard.kde.org/r/123705/diff/ Testing --- On F22 with kwrite konsole Thanks, Stefan Becker ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123705: Add 2nd variant for KConfigGui::sessionConfig()
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123705/#review80165 --- src/gui/kconfiggui.cpp (line 45) https://git.reviewboard.kde.org/r/123705/#comment55010 Ah, so basically sessionConfig() is used for restoring, while sessionConfig(QSessionManager) is used for saving. Right? Maybe the naming could be improved then, to make this clearer. I.e. the new method could be called something like sessionSavingConfig(). And it should use a different pointer than the one used for restoring, maybe? There's little point in mixing the two, then. src/gui/kconfiggui.cpp (line 74) https://git.reviewboard.kde.org/r/123705/#comment55011 So this method returns the config file for restoring or for saving depending on when it's called... sounds a bit unclean. Anyhow the only user of that method was the commented out code in kdelibs4support's kapplication.cpp. So I suggest we deprecate this method and tell people to use sessionConfig()-name() or sessionSavingConfig()-name() depending on what they wanted (restoring or saving). - David Faure On May 10, 2015, 10:30 a.m., Stefan Becker wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123705/ --- (Updated May 10, 2015, 10:30 a.m.) Review request for KDE Frameworks and Rex Dieter. Bugs: 346768 https://bugs.kde.org/show_bug.cgi?id=346768 Repository: kconfig Description --- When the application receives a saveState signal it needs to replace the current KConfig object with a new one based on the QSessionManager information. Add a new variant that accepts the session manager object. Diffs - src/gui/kconfiggui.h 173400f src/gui/kconfiggui.cpp 0048c60 Diff: https://git.reviewboard.kde.org/r/123705/diff/ Testing --- On F22 with kwrite konsole Thanks, Stefan Becker ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kbuildsycoca5 crashing
Also, while this is happening I did a package upgrade to see if it's a Qt packaging problem. I got another update of Qt packages from the arch repo (5.4.1-6 now) But I still get the same issues (kbuildsycoca5 crash and login dbus issue). I'll start a fresh rebuild and look later today I guess. BR, Jeremy On Sun, May 10, 2015 at 7:49 AM, Jeremy Whiting jpwhit...@kde.org wrote: Yep, it's Qt5. After rebuilding everything trying to log into a plasma session I get startkde: could not sync environment to dbus in .xsession-errors, not much before that besides a bad dbus call. Seems very similar to https://bugzilla.redhat.com/show_bug.cgi?id=1191171 I've never thought valgrind would help much with a crashing application, but here's the log of that. Nothing obvious jumping out at me anyway: [jeremy@chrom ~]$ ldd /usr/local/bin/kbuildsycoca5 linux-vdso.so.1 (0x7ffda46b) libKF5Service.so.5 = /usr/local/lib/libKF5Service.so.5 (0x7f37ad81) libKF5Crash.so.5 = /usr/local/lib/libKF5Crash.so.5 (0x7f37ad608000) libKF5CoreAddons.so.5 = /usr/local/lib/libKF5CoreAddons.so.5 (0x7f37ad367000) libKF5I18n.so.5 = /usr/local/lib/libKF5I18n.so.5 (0x7f37ad11b000) libQt5Xml.so.5 = /usr/lib/libQt5Xml.so.5 (0x7f37adc44000) libKF5ConfigCore.so.5 = /usr/local/lib/libKF5ConfigCore.so.5 (0x7f37acead000) libQt5DBus.so.5 = /usr/lib/libQt5DBus.so.5 (0x7f37adbc2000) libQt5Core.so.5 = /usr/lib/libQt5Core.so.5 (0x7f37ac9db000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x7f37ac659000) libm.so.6 = /usr/lib/libm.so.6 (0x7f37ac355000) libgcc_s.so.1 = /usr/lib/libgcc_s.so.1 (0x7f37ac13f000) libc.so.6 = /usr/lib/libc.so.6 (0x7f37abd9d000) libKF5DBusAddons.so.5 = /usr/local/lib/libKF5DBusAddons.so.5 (0x7f37abb86000) libKF5WindowSystem.so.5 = /usr/local/lib/libKF5WindowSystem.so.5 (0x7f37ab916000) libQt5X11Extras.so.5 = /usr/lib/libQt5X11Extras.so.5 (0x7f37adbbb000) libSM.so.6 = /usr/lib/libSM.so.6 (0x7f37ab70e000) libICE.so.6 = /usr/lib/libICE.so.6 (0x7f37ab4f1000) libX11.so.6 = /usr/lib/libX11.so.6 (0x7f37ab1af000) libXext.so.6 = /usr/lib/libXext.so.6 (0x7f37aaf9d000) libQt5Widgets.so.5 = /usr/lib/libQt5Widgets.so.5 (0x7f37aa8fd000) libQt5Gui.so.5 = /usr/lib/libQt5Gui.so.5 (0x7f37aa3b5000) libfam.so.0 = /usr/lib/libfam.so.0 (0x7f37aa1ae000) libpthread.so.0 = /usr/lib/libpthread.so.0 (0x7f37a9f91000) libdbus-1.so.3 = /usr/lib/libdbus-1.so.3 (0x7f37a9d48000) libz.so.1 = /usr/lib/libz.so.1 (0x7f37a9b32000) libicui18n.so.55 = /usr/lib/libicui18n.so.55 (0x7f37a96cc000) libicuuc.so.55 = /usr/lib/libicuuc.so.55 (0x7f37a9339000) libpcre16.so.0 = /usr/lib/libpcre16.so.0 (0x7f37a90d4000) libdl.so.2 = /usr/lib/libdl.so.2 (0x7f37a8ed) libglib-2.0.so.0 = /usr/lib/libglib-2.0.so.0 (0x7f37a8bc2000) librt.so.1 = /usr/lib/librt.so.1 (0x7f37a89ba000) libsystemd.so.0 = /usr/lib/libsystemd.so.0 (0x7f37adb8c000) /lib64/ld-linux-x86-64.so.2 (0x7f37ada9d000) libXfixes.so.3 = /usr/lib/libXfixes.so.3 (0x7f37a87b4000) libXrender.so.1 = /usr/lib/libXrender.so.1 (0x7f37a85aa000) libxcb.so.1 = /usr/lib/libxcb.so.1 (0x7f37a8388000) libxcb-keysyms.so.1 = /usr/lib/libxcb-keysyms.so.1 (0x7f37a8185000) libuuid.so.1 = /usr/lib/libuuid.so.1 (0x7f37a7f8) libgobject-2.0.so.0 = /usr/lib/libgobject-2.0.so.0 (0x7f37a7d2f000) libpng16.so.16 = /usr/lib/libpng16.so.16 (0x7f37a7af9000) libharfbuzz.so.0 = /usr/lib/libharfbuzz.so.0 (0x7f37a789c000) libGL.so.1 = /usr/lib/libGL.so.1 (0x7f37a760) libicudata.so.55 = /usr/lib/libicudata.so.55 (0x7f37a5b4a000) libpcre.so.1 = /usr/lib/libpcre.so.1 (0x7f37a58da000) libcap.so.2 = /usr/lib/libcap.so.2 (0x7f37a56d6000) liblzma.so.5 = /usr/lib/liblzma.so.5 (0x7f37a54b) liblz4.so.1 = /usr/lib/liblz4.so.1 (0x7f37a52a5000) libgcrypt.so.20 = /usr/lib/libgcrypt.so.20 (0x7f37a4fc4000) libgpg-error.so.0 = /usr/lib/libgpg-error.so.0 (0x7f37a4db1000) libresolv.so.2 = /usr/lib/libresolv.so.2 (0x7f37a4b9a000) libXau.so.6 = /usr/lib/libXau.so.6 (0x7f37a4996000) libXdmcp.so.6 = /usr/lib/libXdmcp.so.6 (0x7f37a479) libffi.so.6 = /usr/lib/libffi.so.6 (0x7f37a4587000) libfreetype.so.6 = /usr/lib/libfreetype.so.6 (0x7f37a42ca000) libgraphite2.so.3 = /usr/lib/libgraphite2.so.3 (0x7f37a40ac000) libexpat.so.1 = /usr/lib/libexpat.so.1 (0x7f37a3e82000) libglapi.so.0 = /usr/lib/libglapi.so.0 (0x7f37a3c57000) libXdamage.so.1 = /usr/lib/libXdamage.so.1 (0x7f37a3a54000) libX11-xcb.so.1 = /usr/lib/libX11-xcb.so.1 (0x7f37a3852000) libxcb-glx.so.0 = /usr/lib/libxcb-glx.so.0 (0x7f37a3638000) libxcb-dri2.so.0 = /usr/lib/libxcb-dri2.so.0 (0x7f37a3433000) libxcb-dri3.so.0 = /usr/lib/libxcb-dri3.so.0 (0x7f37a323) libxcb-present.so.0 = /usr/lib/libxcb-present.so.0 (0x7f37a302d000) libxcb-randr.so.0 = /usr/lib/libxcb-randr.so.0
Re: Review Request 123595: Fix KUser test for Mac.
On May 6, 2015, 4:40 p.m., René J.V. Bertin wrote: I'm not sure, after reading http://pig.made-it.com/uidgid.html also: ``` id nobody uid=4294967294(nobody) gid=4294967294(nobody) groups=4294967294(nobody),12(everyone),61(localaccounts),402(com.apple.sharepoint.group.1),403(com.apple.sharepoint.group.2),100(_lpoperator) ``` and ``` id unknown uid=99(_unknown) gid=99(_unknown) groups=99(_unknown),402(com.apple.sharepoint.group.1),12(everyone),61(localaccounts),403(com.apple.sharepoint.group.2),100(_lpoperator) ``` nobody is a special user, let's put that one aside since the unittest doesn't need it. I'm not sure `id` works like the APIs KUser uses. What does the unittest say for you, in fact? (with or without my patch, doesn't matter for debugging this) - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123595/#review79976 --- On May 6, 2015, 4:08 p.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123595/ --- (Updated May 6, 2015, 4:08 p.m.) Review request for KDE Software on Mac OS X, KDE Frameworks and Marko Käning. Repository: kcoreaddons Description --- According to CI [1], an invalid user belongs to nogroup on Mac. Not sure if this is true on all OSX installations though? https://build.kde.org/view/Frameworks%20kf5-qt5/job/kcoreaddons%20master%20kf5-qt5/PLATFORM=OSX,compiler=clang/19/testReport/%28root%29/TestSuite/kusertest/ Diffs - autotests/kusertest.cpp d17a2d3e97d5056524281eb18766377e48a0da35 Diff: https://git.reviewboard.kde.org/r/123595/diff/ Testing --- Still passes on Linux; should fix the CI for mac, AFAICS. Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kbuildsycoca5 crashing
On Sunday 10 May 2015 07:49:48 Jeremy Whiting wrote: ==2883== Address 0x is not stack'd, malloc'd or (recently) free'd This must be a miscompilation, I see no other reason for the refcount of a QByteArray to be at address 0x. Try rebuilding kservice from scratch. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kbuildsycoca5 crashing
On Sunday 10 May 2015 08:24:48 Jeremy Whiting wrote: Rebuilt kservice (and nuked my build folder and /usr/local just to be doubly sure.) kbuildsycoca5 still crashes with this same backtrace, no idea why. Could it be a bug in QtCore? Arch testing packages of Qt? I doubt it. More likely a compiler bug or a BIC or a miscompile. Try running a few Qt examples from your Qt build, to at least make sure that works. 0x is -1, no? did it get decreased one too many times somehow? You don't understand. This isn't the value of the refcount, it's the address in memory of the variable holding the refcount. Which means a serious mixup somewhere lowlevel (e.g. compiler). -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123705: Add 2nd variant for KConfigGui::sessionConfig()
On May 9, 2015, 7:42 p.m., David Faure wrote: With this API change, I wonder if it makes sense for kconfiggui.cpp to retain ownership of the KConfig object. Wouldn't it be safer if the caller got ownership of it, saved into it, and then discarded the KConfig instance? Then we wouldn't have this lose unsaved changes code path. Or is the idea that multiple parts of the code could connect to the qApp signal, so they should share the same KConfig instance? Stefan Becker wrote: I understood that KConfigGui is responsible for the applications' session configuration. I.e. there are the following situations: 1. application started without -session command line argumen:t KConfigGui::sessionConfig() must never be called. That's what canBeRestored() is all about. 2. application started with -session command line argument: KConfig::sessionConfig() needs to create KConfig object based on that name so that the application can restore its state. 3. session manager emits saveStateRequest signal. At this point the old session config file has become obsolete and a new one needs to be generated - KConfigGui::sessionConfig(sm). The application must file that KConfig object with the new status. If code calls KConfigGui::sessionConfig() it must return the new object. I agree that if kxmlgui KMainWindow is the only user of KConfigGui then the code could be refactored to squash KConfigGui into KMainWindow. But IMHO that is beyond the scope of this bug/review. It should definitely be possible to do session management with KConfig and without KXmlGui. I wasn't suggesting otherwise. I was only suggesting to move ownership, i.e. KConfigGui::sessionSavingConfig() saying the returned KConfig instance is yours, you must delete it once you're done with it. But I'm not 100% sure about this idea. In fact it would break the case were independent slots want to save stuff, so let's forget about that idea. Your description does confirm my thinking that the new method should rather be called something like sessionSavingConfig(). Different signature, different method name, different purpose, different filename... and different underlying KConfig object. - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123705/#review80136 --- On May 10, 2015, 10:30 a.m., Stefan Becker wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123705/ --- (Updated May 10, 2015, 10:30 a.m.) Review request for KDE Frameworks and Rex Dieter. Bugs: 346768 https://bugs.kde.org/show_bug.cgi?id=346768 Repository: kconfig Description --- When the application receives a saveState signal it needs to replace the current KConfig object with a new one based on the QSessionManager information. Add a new variant that accepts the session manager object. Diffs - src/gui/kconfiggui.h 173400f src/gui/kconfiggui.cpp 0048c60 Diff: https://git.reviewboard.kde.org/r/123705/diff/ Testing --- On F22 with kwrite konsole Thanks, Stefan Becker ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kbuildsycoca5 crashing
I see. Some kde applications segfault (klettres, okular) other's run ok (dolphin, khangman) I haven't tried others. As for qt binaries I checked the binaries that come with the arch package, and assistant, designer, qdbusviewer all work fine. Is there one in particular I should check? On Sun, May 10, 2015 at 8:45 AM, David Faure fa...@kde.org wrote: On Sunday 10 May 2015 08:24:48 Jeremy Whiting wrote: Rebuilt kservice (and nuked my build folder and /usr/local just to be doubly sure.) kbuildsycoca5 still crashes with this same backtrace, no idea why. Could it be a bug in QtCore? Arch testing packages of Qt? I doubt it. More likely a compiler bug or a BIC or a miscompile. Try running a few Qt examples from your Qt build, to at least make sure that works. 0x is -1, no? did it get decreased one too many times somehow? You don't understand. This isn't the value of the refcount, it's the address in memory of the variable holding the refcount. Which means a serious mixup somewhere lowlevel (e.g. compiler). -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123707: Set session manager discard command
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123707/ --- (Updated May 10, 2015, 4:03 p.m.) Review request for KDE Frameworks and Rex Dieter. Changes --- rebased Bugs: 346768 https://bugs.kde.org/show_bug.cgi?id=346768 Repository: kconfig Description (updated) --- If KConfig object provides a non-empty file path then set the session manager discard command to rm file path. This makes sure that obsolete session files are deleted after creating a new one. Diffs (updated) - src/core/kconfig.h 6cc7323 src/core/kconfig.cpp 3819716 src/gui/kconfiggui.h 173400f src/gui/kconfiggui.cpp 0048c60 Diff: https://git.reviewboard.kde.org/r/123707/diff/ Testing --- F22 kwrite konsole, ksmserver and Save Session... Thanks, Stefan Becker ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123706: Forward QSessionManager to KConfigGui
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123706/ --- (Updated May 10, 2015, 2:39 p.m.) Review request for KDE Frameworks and Rex Dieter. Changes --- removed initial instance variable Bugs: 346768 https://bugs.kde.org/show_bug.cgi?id=346768 Repository: kxmlgui Description (updated) --- Get a KConfig object that corresponds to the QSessionManager object that is passed in with the saveStateRequest signal. To make sure that the data is stored to disk we have to call sync() on the object after the application has updated it. Diffs (updated) - src/kmainwindow.cpp 15eecb7 Diff: https://git.reviewboard.kde.org/r/123706/diff/ Testing --- On F22 with kwrite konsole Thanks, Stefan Becker ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kbuildsycoca5 crashing
Also, none of the recent patches on https://projects.archlinux.org/svntogit/packages.git/log/trunk?h=packages/qt5 make me nervous, all seem to be pretty straightforward. Could it be lower level as in my glibc is too new, or the compiler itself (GCC 5.1.0) On Sun, May 10, 2015 at 8:54 AM, Jeremy Whiting jpwhit...@kde.org wrote: I see. Some kde applications segfault (klettres, okular) other's run ok (dolphin, khangman) I haven't tried others. As for qt binaries I checked the binaries that come with the arch package, and assistant, designer, qdbusviewer all work fine. Is there one in particular I should check? On Sun, May 10, 2015 at 8:45 AM, David Faure fa...@kde.org wrote: On Sunday 10 May 2015 08:24:48 Jeremy Whiting wrote: Rebuilt kservice (and nuked my build folder and /usr/local just to be doubly sure.) kbuildsycoca5 still crashes with this same backtrace, no idea why. Could it be a bug in QtCore? Arch testing packages of Qt? I doubt it. More likely a compiler bug or a BIC or a miscompile. Try running a few Qt examples from your Qt build, to at least make sure that works. 0x is -1, no? did it get decreased one too many times somehow? You don't understand. This isn't the value of the refcount, it's the address in memory of the variable holding the refcount. Which means a serious mixup somewhere lowlevel (e.g. compiler). -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123705: Add 2nd variant for KConfigGui::sessionConfig()
On May 9, 2015, 7:42 p.m., David Faure wrote: With this API change, I wonder if it makes sense for kconfiggui.cpp to retain ownership of the KConfig object. Wouldn't it be safer if the caller got ownership of it, saved into it, and then discarded the KConfig instance? Then we wouldn't have this lose unsaved changes code path. Or is the idea that multiple parts of the code could connect to the qApp signal, so they should share the same KConfig instance? Stefan Becker wrote: I understood that KConfigGui is responsible for the applications' session configuration. I.e. there are the following situations: 1. application started without -session command line argumen:t KConfigGui::sessionConfig() must never be called. That's what canBeRestored() is all about. 2. application started with -session command line argument: KConfig::sessionConfig() needs to create KConfig object based on that name so that the application can restore its state. 3. session manager emits saveStateRequest signal. At this point the old session config file has become obsolete and a new one needs to be generated - KConfigGui::sessionConfig(sm). The application must file that KConfig object with the new status. If code calls KConfigGui::sessionConfig() it must return the new object. I agree that if kxmlgui KMainWindow is the only user of KConfigGui then the code could be refactored to squash KConfigGui into KMainWindow. But IMHO that is beyond the scope of this bug/review. David Faure wrote: It should definitely be possible to do session management with KConfig and without KXmlGui. I wasn't suggesting otherwise. I was only suggesting to move ownership, i.e. KConfigGui::sessionSavingConfig() saying the returned KConfig instance is yours, you must delete it once you're done with it. But I'm not 100% sure about this idea. In fact it would break the case were independent slots want to save stuff, so let's forget about that idea. Your description does confirm my thinking that the new method should rather be called something like sessionSavingConfig(). Different signature, different method name, different purpose, different filename... and different underlying KConfig object. OK, but sessionConfig() must still return the new object. Just in case some other code in the application calls that function after sessionSavingConfig(sm) has been called. - Stefan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123705/#review80136 --- On May 10, 2015, 10:30 a.m., Stefan Becker wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123705/ --- (Updated May 10, 2015, 10:30 a.m.) Review request for KDE Frameworks and Rex Dieter. Bugs: 346768 https://bugs.kde.org/show_bug.cgi?id=346768 Repository: kconfig Description --- When the application receives a saveState signal it needs to replace the current KConfig object with a new one based on the QSessionManager information. Add a new variant that accepts the session manager object. Diffs - src/gui/kconfiggui.h 173400f src/gui/kconfiggui.cpp 0048c60 Diff: https://git.reviewboard.kde.org/r/123705/diff/ Testing --- On F22 with kwrite konsole Thanks, Stefan Becker ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123705: Add 2nd variant for KConfigGui::sessionConfig()
On May 9, 2015, 7:42 p.m., David Faure wrote: With this API change, I wonder if it makes sense for kconfiggui.cpp to retain ownership of the KConfig object. Wouldn't it be safer if the caller got ownership of it, saved into it, and then discarded the KConfig instance? Then we wouldn't have this lose unsaved changes code path. Or is the idea that multiple parts of the code could connect to the qApp signal, so they should share the same KConfig instance? Stefan Becker wrote: I understood that KConfigGui is responsible for the applications' session configuration. I.e. there are the following situations: 1. application started without -session command line argumen:t KConfigGui::sessionConfig() must never be called. That's what canBeRestored() is all about. 2. application started with -session command line argument: KConfig::sessionConfig() needs to create KConfig object based on that name so that the application can restore its state. 3. session manager emits saveStateRequest signal. At this point the old session config file has become obsolete and a new one needs to be generated - KConfigGui::sessionConfig(sm). The application must file that KConfig object with the new status. If code calls KConfigGui::sessionConfig() it must return the new object. I agree that if kxmlgui KMainWindow is the only user of KConfigGui then the code could be refactored to squash KConfigGui into KMainWindow. But IMHO that is beyond the scope of this bug/review. David Faure wrote: It should definitely be possible to do session management with KConfig and without KXmlGui. I wasn't suggesting otherwise. I was only suggesting to move ownership, i.e. KConfigGui::sessionSavingConfig() saying the returned KConfig instance is yours, you must delete it once you're done with it. But I'm not 100% sure about this idea. In fact it would break the case were independent slots want to save stuff, so let's forget about that idea. Your description does confirm my thinking that the new method should rather be called something like sessionSavingConfig(). Different signature, different method name, different purpose, different filename... and different underlying KConfig object. Stefan Becker wrote: OK, but sessionConfig() must still return the new object. Just in case some other code in the application calls that function after sessionSavingConfig(sm) has been called. Ah I see what you mean. This bugfix in the libs doesn't change what apps do. My idea (splitting loading and saving) is too radical at this point then. Maybe KConfigGui's new API should look more like a setter then, if we are changing state. (We are not just requesting something, that method changes what sessionConfig() returns.) So maybe the new method should be setSessionConfig(QSessionManager) (but the naming isn't great) or maybe setSessionConfig(QString) and the caller (xmlgui) would use KConfigGui::setSessionConfig(KConfigGui::sessionConfigName(QSessionManager)). - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123705/#review80136 --- On May 10, 2015, 10:30 a.m., Stefan Becker wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123705/ --- (Updated May 10, 2015, 10:30 a.m.) Review request for KDE Frameworks and Rex Dieter. Bugs: 346768 https://bugs.kde.org/show_bug.cgi?id=346768 Repository: kconfig Description --- When the application receives a saveState signal it needs to replace the current KConfig object with a new one based on the QSessionManager information. Add a new variant that accepts the session manager object. Diffs - src/gui/kconfiggui.h 173400f src/gui/kconfiggui.cpp 0048c60 Diff: https://git.reviewboard.kde.org/r/123705/diff/ Testing --- On F22 with kwrite konsole Thanks, Stefan Becker ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123706: Forward QSessionManager to KConfigGui
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123706/ --- (Updated May 10, 2015, 4:05 p.m.) Review request for KDE Frameworks and Rex Dieter. Changes --- updated for new KConfigGui interface name Bugs: 346768 https://bugs.kde.org/show_bug.cgi?id=346768 Repository: kxmlgui Description --- Get a KConfig object that corresponds to the QSessionManager object that is passed in with the saveStateRequest signal. To make sure that the data is stored to disk we have to call sync() on the object after the application has updated it. Diffs (updated) - src/kmainwindow.cpp 15eecb7 Diff: https://git.reviewboard.kde.org/r/123706/diff/ Testing --- On F22 with kwrite konsole Thanks, Stefan Becker ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kbuildsycoca5 crashing
On Sunday 10 May 2015 06:13:15 Jeremy Whiting wrote: #7 0x004363d0 in QLinkedListKSycocaResource::detach (this=0x69b140) at /usr/include/qt/QtCore/qlinkedlist.h:99 Is that Qt4 or Qt5? Use ldd on your kbuildsycoca5 binary to check which Qt libs it's using. (and the next step if all looks fine at that level: valgrind) -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Sunday 10 May 2015 12:36:53 Christian Mollekopf wrote: * I'd consider Qt to be a lower level library. Qt mostly provides fundamentals just like libc or the STL, and it's therefore okay for me to just work with what I have available. I hope you can understand that the decision on how Qt (on one side) and KDE Frameworks (on the other side) should be released, does not only depend on the way *you* consider Qt and KF5. Other people have a different view on both (e.g. Qt developers do work on Qt, while app developers might treat KF5 as something fundamental where they just work with what they have available). You want to draw a line somewhere, while others draw it elsewhere, and yet we have to make decisions that work for everyone, not just for you. Qt does include a *lot* of stuff though, which I think Qt would also benefit from truly splitting up libraries. Qt *is* splitted. It's just that the splitted libs are released together. Frameworks for me is an umbrella for various libraries, and not a single library. If it were a single library it would be an everything and the kitchen sink library, which I really don't think is something we should be aiming for. One could say the same about Qt, but this argument won't lead us anywhere so let's skip that. So for me each framework is an individual library, and should be treated as such, because I do want to work on the respective framework instead of running in my own circles in wherever I use the framework. I therefore need to be able to use the results of that work on all my target platforms, otherwise working on the framework is just having me implement the same thing twice. Making it possible for people to work on frameworks and then use the result in their applications quickly is exactly the reason why we have a monthly release cycle (unlike Qt). You can implement stuff in KF5 and use it the month that follows in the layers above. This is orthogonal to the discussion on version numbering, i.e. I definitely don't see this as an argument in favour of version hell. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kbuildsycoca5 crashing
Yep, it's Qt5. After rebuilding everything trying to log into a plasma session I get startkde: could not sync environment to dbus in .xsession-errors, not much before that besides a bad dbus call. Seems very similar to https://bugzilla.redhat.com/show_bug.cgi?id=1191171 I've never thought valgrind would help much with a crashing application, but here's the log of that. Nothing obvious jumping out at me anyway: [jeremy@chrom ~]$ ldd /usr/local/bin/kbuildsycoca5 linux-vdso.so.1 (0x7ffda46b) libKF5Service.so.5 = /usr/local/lib/libKF5Service.so.5 (0x7f37ad81) libKF5Crash.so.5 = /usr/local/lib/libKF5Crash.so.5 (0x7f37ad608000) libKF5CoreAddons.so.5 = /usr/local/lib/libKF5CoreAddons.so.5 (0x7f37ad367000) libKF5I18n.so.5 = /usr/local/lib/libKF5I18n.so.5 (0x7f37ad11b000) libQt5Xml.so.5 = /usr/lib/libQt5Xml.so.5 (0x7f37adc44000) libKF5ConfigCore.so.5 = /usr/local/lib/libKF5ConfigCore.so.5 (0x7f37acead000) libQt5DBus.so.5 = /usr/lib/libQt5DBus.so.5 (0x7f37adbc2000) libQt5Core.so.5 = /usr/lib/libQt5Core.so.5 (0x7f37ac9db000) libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x7f37ac659000) libm.so.6 = /usr/lib/libm.so.6 (0x7f37ac355000) libgcc_s.so.1 = /usr/lib/libgcc_s.so.1 (0x7f37ac13f000) libc.so.6 = /usr/lib/libc.so.6 (0x7f37abd9d000) libKF5DBusAddons.so.5 = /usr/local/lib/libKF5DBusAddons.so.5 (0x7f37abb86000) libKF5WindowSystem.so.5 = /usr/local/lib/libKF5WindowSystem.so.5 (0x7f37ab916000) libQt5X11Extras.so.5 = /usr/lib/libQt5X11Extras.so.5 (0x7f37adbbb000) libSM.so.6 = /usr/lib/libSM.so.6 (0x7f37ab70e000) libICE.so.6 = /usr/lib/libICE.so.6 (0x7f37ab4f1000) libX11.so.6 = /usr/lib/libX11.so.6 (0x7f37ab1af000) libXext.so.6 = /usr/lib/libXext.so.6 (0x7f37aaf9d000) libQt5Widgets.so.5 = /usr/lib/libQt5Widgets.so.5 (0x7f37aa8fd000) libQt5Gui.so.5 = /usr/lib/libQt5Gui.so.5 (0x7f37aa3b5000) libfam.so.0 = /usr/lib/libfam.so.0 (0x7f37aa1ae000) libpthread.so.0 = /usr/lib/libpthread.so.0 (0x7f37a9f91000) libdbus-1.so.3 = /usr/lib/libdbus-1.so.3 (0x7f37a9d48000) libz.so.1 = /usr/lib/libz.so.1 (0x7f37a9b32000) libicui18n.so.55 = /usr/lib/libicui18n.so.55 (0x7f37a96cc000) libicuuc.so.55 = /usr/lib/libicuuc.so.55 (0x7f37a9339000) libpcre16.so.0 = /usr/lib/libpcre16.so.0 (0x7f37a90d4000) libdl.so.2 = /usr/lib/libdl.so.2 (0x7f37a8ed) libglib-2.0.so.0 = /usr/lib/libglib-2.0.so.0 (0x7f37a8bc2000) librt.so.1 = /usr/lib/librt.so.1 (0x7f37a89ba000) libsystemd.so.0 = /usr/lib/libsystemd.so.0 (0x7f37adb8c000) /lib64/ld-linux-x86-64.so.2 (0x7f37ada9d000) libXfixes.so.3 = /usr/lib/libXfixes.so.3 (0x7f37a87b4000) libXrender.so.1 = /usr/lib/libXrender.so.1 (0x7f37a85aa000) libxcb.so.1 = /usr/lib/libxcb.so.1 (0x7f37a8388000) libxcb-keysyms.so.1 = /usr/lib/libxcb-keysyms.so.1 (0x7f37a8185000) libuuid.so.1 = /usr/lib/libuuid.so.1 (0x7f37a7f8) libgobject-2.0.so.0 = /usr/lib/libgobject-2.0.so.0 (0x7f37a7d2f000) libpng16.so.16 = /usr/lib/libpng16.so.16 (0x7f37a7af9000) libharfbuzz.so.0 = /usr/lib/libharfbuzz.so.0 (0x7f37a789c000) libGL.so.1 = /usr/lib/libGL.so.1 (0x7f37a760) libicudata.so.55 = /usr/lib/libicudata.so.55 (0x7f37a5b4a000) libpcre.so.1 = /usr/lib/libpcre.so.1 (0x7f37a58da000) libcap.so.2 = /usr/lib/libcap.so.2 (0x7f37a56d6000) liblzma.so.5 = /usr/lib/liblzma.so.5 (0x7f37a54b) liblz4.so.1 = /usr/lib/liblz4.so.1 (0x7f37a52a5000) libgcrypt.so.20 = /usr/lib/libgcrypt.so.20 (0x7f37a4fc4000) libgpg-error.so.0 = /usr/lib/libgpg-error.so.0 (0x7f37a4db1000) libresolv.so.2 = /usr/lib/libresolv.so.2 (0x7f37a4b9a000) libXau.so.6 = /usr/lib/libXau.so.6 (0x7f37a4996000) libXdmcp.so.6 = /usr/lib/libXdmcp.so.6 (0x7f37a479) libffi.so.6 = /usr/lib/libffi.so.6 (0x7f37a4587000) libfreetype.so.6 = /usr/lib/libfreetype.so.6 (0x7f37a42ca000) libgraphite2.so.3 = /usr/lib/libgraphite2.so.3 (0x7f37a40ac000) libexpat.so.1 = /usr/lib/libexpat.so.1 (0x7f37a3e82000) libglapi.so.0 = /usr/lib/libglapi.so.0 (0x7f37a3c57000) libXdamage.so.1 = /usr/lib/libXdamage.so.1 (0x7f37a3a54000) libX11-xcb.so.1 = /usr/lib/libX11-xcb.so.1 (0x7f37a3852000) libxcb-glx.so.0 = /usr/lib/libxcb-glx.so.0 (0x7f37a3638000) libxcb-dri2.so.0 = /usr/lib/libxcb-dri2.so.0 (0x7f37a3433000) libxcb-dri3.so.0 = /usr/lib/libxcb-dri3.so.0 (0x7f37a323) libxcb-present.so.0 = /usr/lib/libxcb-present.so.0 (0x7f37a302d000) libxcb-randr.so.0 = /usr/lib/libxcb-randr.so.0 (0x7f37a2e1f000) libxcb-xfixes.so.0 = /usr/lib/libxcb-xfixes.so.0 (0x7f37a2c17000) libxcb-render.so.0 = /usr/lib/libxcb-render.so.0 (0x7f37a2a0d000) libxcb-shape.so.0 = /usr/lib/libxcb-shape.so.0 (0x7f37a2809000) libxcb-sync.so.1 = /usr/lib/libxcb-sync.so.1 (0x7f37a2602000) libxshmfence.so.1 = /usr/lib/libxshmfence.so.1 (0x7f37a23ff000) libXxf86vm.so.1 = /usr/lib/libXxf86vm.so.1 (0x7f37a21f9000) libdrm.so.2 = /usr/lib/libdrm.so.2
Re: kbuildsycoca5 crashing
Rebuilt kservice (and nuked my build folder and /usr/local just to be doubly sure.) kbuildsycoca5 still crashes with this same backtrace, no idea why. Could it be a bug in QtCore? Arch testing packages of Qt? 0x is -1, no? did it get decreased one too many times somehow? On Sun, May 10, 2015 at 8:04 AM, David Faure fa...@kde.org wrote: On Sunday 10 May 2015 07:49:48 Jeremy Whiting wrote: ==2883== Address 0x is not stack'd, malloc'd or (recently) free'd This must be a miscompilation, I see no other reason for the refcount of a QByteArray to be at address 0x. Try rebuilding kservice from scratch. -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123705: Add 2nd variant for KConfigGui::sessionConfig()
On May 9, 2015, 7:42 p.m., David Faure wrote: With this API change, I wonder if it makes sense for kconfiggui.cpp to retain ownership of the KConfig object. Wouldn't it be safer if the caller got ownership of it, saved into it, and then discarded the KConfig instance? Then we wouldn't have this lose unsaved changes code path. Or is the idea that multiple parts of the code could connect to the qApp signal, so they should share the same KConfig instance? I understood that KConfigGui is responsible for the applications' session configuration. I.e. there are the following situations: 1. application started without -session command line argumen:t KConfigGui::sessionConfig() must never be called. That's what canBeRestored() is all about. 2. application started with -session command line argument: KConfig::sessionConfig() needs to create KConfig object based on that name so that the application can restore its state. 3. session manager emits saveStateRequest signal. At this point the old session config file has become obsolete and a new one needs to be generated - KConfigGui::sessionConfig(sm). The application must file that KConfig object with the new status. If code calls KConfigGui::sessionConfig() it must return the new object. I agree that if kxmlgui KMainWindow is the only user of KConfigGui then the code could be refactored to squash KConfigGui into KMainWindow. But IMHO that is beyond the scope of this bug/review. On May 9, 2015, 7:42 p.m., David Faure wrote: src/gui/kconfiggui.cpp, line 58 https://git.reviewboard.kde.org/r/123705/diff/1/?file=367967#file367967line58 This looks dangerous. Are we 100% sure that this is safe? To ask this otherwise: how can this config object actually have any uncommitted changes? It's only used during session saving, no? Moved to the change in review /r/123706 instead On May 9, 2015, 7:42 p.m., David Faure wrote: src/gui/kconfiggui.cpp, line 78 https://git.reviewboard.kde.org/r/123705/diff/1/?file=367967#file367967line78 why not just return sessionConfig()-name() ? Then there's no need for the separate ensureSessionConfig() (which always has the risk that someone forgets to call it, after a refactoring). Thanks, my brain was still stuck in the old code structure, which of course now is obsolete. - Stefan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123705/#review80136 --- On May 10, 2015, 10:30 a.m., Stefan Becker wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123705/ --- (Updated May 10, 2015, 10:30 a.m.) Review request for KDE Frameworks and Rex Dieter. Bugs: 346768 https://bugs.kde.org/show_bug.cgi?id=346768 Repository: kconfig Description --- When the application receives a saveState signal it needs to replace the current KConfig object with a new one based on the QSessionManager information. Add a new variant that accepts the session manager object. Diffs - src/gui/kconfiggui.h 173400f src/gui/kconfiggui.cpp 0048c60 Diff: https://git.reviewboard.kde.org/r/123705/diff/ Testing --- On F22 with kwrite konsole Thanks, Stefan Becker ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123707: Set session manager discard command
On May 9, 2015, 7:52 p.m., David Faure wrote: src/core/kconfig.h, line 368 https://git.reviewboard.kde.org/r/123707/diff/1/?file=367996#file367996line368 I don't think this API is good to have (which is why it was never added). Most kconfig instances are a view over multiple files on disk, merged. So a single full path isn't enough. (backend-filePath() can be relative, too; this method could forward that, but then it would need to be properly documented what will be returned here, and that would be sometimes relative, sometimes absolute... not really convenient to work with). You can use this instead, right? QStandardPaths::writableLocation(GenericConfigLocation) + config.fileName() (If you end up keeping this method, remove application from the docu, this is for any KConfig object, not just the main config. and add @since 5.11.) I thought I can't make this assumption, because it would hard-code what KConfigBackend is used and how is implemented. Now the code checks if KConfigBackend has set a local file name or not. Please note that filePath() != name(). As far as I can tell filePath() is always relative. Unfortunately KConfigGui is not a class so I can't mark filePath() as protected interface. Would it be acceptable to declare kxmlgui KMainWindow as friend of KConfig, mark filePath() as protected and then move the discard command generation to kxmlgui (see also /r/123706)? Then QSessionManager can also stay const. - Stefan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123707/#review80138 --- On May 10, 2015, 10:47 a.m., Stefan Becker wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123707/ --- (Updated May 10, 2015, 10:47 a.m.) Review request for KDE Frameworks and Rex Dieter. Bugs: 346768 https://bugs.kde.org/show_bug.cgi?id=346768 Repository: kconfig Description --- If KConfig object provides a non-empty file path then set the session manager discard command to rm file path. This makes sure that ksmserver removes old obsolete session files after storing a new session. Diffs - src/core/kconfig.h 6cc7323 src/core/kconfig.cpp 3819716 src/gui/kconfiggui.h 173400f src/gui/kconfiggui.cpp 0048c60 Diff: https://git.reviewboard.kde.org/r/123707/diff/ Testing --- F22 kwrite konsole, ksmserver and Save Session... Thanks, Stefan Becker ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kbuildsycoca5 crashing
El Diumenge, 10 de maig de 2015, a les 08:57:28, Jeremy Whiting va escriure: Also, none of the recent patches on https://projects.archlinux.org/svntogit/packages.git/log/trunk?h=packages/qt 5 make me nervous, all seem to be pretty straightforward. Could it be lower level as in my glibc is too new, or the compiler itself (GCC 5.1.0) I hear nothing else than scary stories about people mixing stuff compiled with the new gcc and older versions, there's supposedly a switch that makes the abi be compatible, but the switch seems to be failing at properly make things compatible. I'd suggest to either recompile everything or to downgrade to old gcc. Cheers, Albert On Sun, May 10, 2015 at 8:54 AM, Jeremy Whiting jpwhit...@kde.org wrote: I see. Some kde applications segfault (klettres, okular) other's run ok (dolphin, khangman) I haven't tried others. As for qt binaries I checked the binaries that come with the arch package, and assistant, designer, qdbusviewer all work fine. Is there one in particular I should check? On Sun, May 10, 2015 at 8:45 AM, David Faure fa...@kde.org wrote: On Sunday 10 May 2015 08:24:48 Jeremy Whiting wrote: Rebuilt kservice (and nuked my build folder and /usr/local just to be doubly sure.) kbuildsycoca5 still crashes with this same backtrace, no idea why. Could it be a bug in QtCore? Arch testing packages of Qt? I doubt it. More likely a compiler bug or a BIC or a miscompile. Try running a few Qt examples from your Qt build, to at least make sure that works. 0x is -1, no? did it get decreased one too many times somehow? You don't understand. This isn't the value of the refcount, it's the address in memory of the variable holding the refcount. Which means a serious mixup somewhere lowlevel (e.g. compiler). -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123705: Add KConfigGui::setSessionConfig()
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123705/ --- (Updated May 10, 2015, 4:01 p.m.) Review request for KDE Frameworks and Rex Dieter. Changes --- renamed the new interface Summary (updated) - Add KConfigGui::setSessionConfig() Bugs: 346768 https://bugs.kde.org/show_bug.cgi?id=346768 Repository: kconfig Description (updated) --- When the application receives a saveState signal it needs to replace the current KConfig object with a new one based on the QSessionManager information. Add a new interface that accepts the session manager object. Diffs (updated) - src/gui/kconfiggui.h 173400f src/gui/kconfiggui.cpp 0048c60 Diff: https://git.reviewboard.kde.org/r/123705/diff/ Testing --- On F22 with kwrite konsole Thanks, Stefan Becker ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kbuildsycoca5 crashing
I only built kf5/kde applications. Though I've no idea what compiler was used to build the Qt packages. probably g++ 4.9 from arch stable I bet. /me removes testing, downgrades the dozen packages from it and will rebuild. Thanks for the tips both of you. Hopefully I can finish the 15.04.1 release tuesday from within a plasma 5 session instead of this fallback gnome session :) (and have konversation running again also...) thanks, Jeremy On Sun, May 10, 2015 at 9:46 AM, Albert Astals Cid aa...@kde.org wrote: El Diumenge, 10 de maig de 2015, a les 08:57:28, Jeremy Whiting va escriure: Also, none of the recent patches on https://projects.archlinux.org/svntogit/packages.git/log/trunk?h=packages/qt 5 make me nervous, all seem to be pretty straightforward. Could it be lower level as in my glibc is too new, or the compiler itself (GCC 5.1.0) I hear nothing else than scary stories about people mixing stuff compiled with the new gcc and older versions, there's supposedly a switch that makes the abi be compatible, but the switch seems to be failing at properly make things compatible. I'd suggest to either recompile everything or to downgrade to old gcc. Cheers, Albert On Sun, May 10, 2015 at 8:54 AM, Jeremy Whiting jpwhit...@kde.org wrote: I see. Some kde applications segfault (klettres, okular) other's run ok (dolphin, khangman) I haven't tried others. As for qt binaries I checked the binaries that come with the arch package, and assistant, designer, qdbusviewer all work fine. Is there one in particular I should check? On Sun, May 10, 2015 at 8:45 AM, David Faure fa...@kde.org wrote: On Sunday 10 May 2015 08:24:48 Jeremy Whiting wrote: Rebuilt kservice (and nuked my build folder and /usr/local just to be doubly sure.) kbuildsycoca5 still crashes with this same backtrace, no idea why. Could it be a bug in QtCore? Arch testing packages of Qt? I doubt it. More likely a compiler bug or a BIC or a miscompile. Try running a few Qt examples from your Qt build, to at least make sure that works. 0x is -1, no? did it get decreased one too many times somehow? You don't understand. This isn't the value of the refcount, it's the address in memory of the variable holding the refcount. Which means a serious mixup somewhere lowlevel (e.g. compiler). -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: kbuildsycoca5 crashing
\o/ KService built with a downgraded (4.9.1) g++ works fine. Sorry for the noise. Should be able to detect this sort of problem quickly in the future though. I'll stick with non testing arch for the time being. On Sun, May 10, 2015 at 10:07 AM, Jeremy Whiting jpwhit...@kde.org wrote: I only built kf5/kde applications. Though I've no idea what compiler was used to build the Qt packages. probably g++ 4.9 from arch stable I bet. /me removes testing, downgrades the dozen packages from it and will rebuild. Thanks for the tips both of you. Hopefully I can finish the 15.04.1 release tuesday from within a plasma 5 session instead of this fallback gnome session :) (and have konversation running again also...) thanks, Jeremy On Sun, May 10, 2015 at 9:46 AM, Albert Astals Cid aa...@kde.org wrote: El Diumenge, 10 de maig de 2015, a les 08:57:28, Jeremy Whiting va escriure: Also, none of the recent patches on https://projects.archlinux.org/svntogit/packages.git/log/trunk?h=packages/qt 5 make me nervous, all seem to be pretty straightforward. Could it be lower level as in my glibc is too new, or the compiler itself (GCC 5.1.0) I hear nothing else than scary stories about people mixing stuff compiled with the new gcc and older versions, there's supposedly a switch that makes the abi be compatible, but the switch seems to be failing at properly make things compatible. I'd suggest to either recompile everything or to downgrade to old gcc. Cheers, Albert On Sun, May 10, 2015 at 8:54 AM, Jeremy Whiting jpwhit...@kde.org wrote: I see. Some kde applications segfault (klettres, okular) other's run ok (dolphin, khangman) I haven't tried others. As for qt binaries I checked the binaries that come with the arch package, and assistant, designer, qdbusviewer all work fine. Is there one in particular I should check? On Sun, May 10, 2015 at 8:45 AM, David Faure fa...@kde.org wrote: On Sunday 10 May 2015 08:24:48 Jeremy Whiting wrote: Rebuilt kservice (and nuked my build folder and /usr/local just to be doubly sure.) kbuildsycoca5 still crashes with this same backtrace, no idea why. Could it be a bug in QtCore? Arch testing packages of Qt? I doubt it. More likely a compiler bug or a BIC or a miscompile. Try running a few Qt examples from your Qt build, to at least make sure that works. 0x is -1, no? did it get decreased one too many times somehow? You don't understand. This isn't the value of the refcount, it's the address in memory of the variable holding the refcount. Which means a serious mixup somewhere lowlevel (e.g. compiler). -- David Faure, fa...@kde.org, http://www.davidfaure.fr Working on KDE Frameworks 5 ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Versioning of Frameworks
On Sunday, 10 May 2015 15:39:02 CEST, David Faure wrote: Qt *is* splitted. It's just that the splitted libs are released together. The splitting of Qt is not full and complete, however. Modules tend to use each other's internal APIs, and that's the biggest reason for not supporting random mixing of different versions of Qt modules. Reducing the supported space of all possible combinations is another reason for sure, so I understand your point about doing the same in KF -- just explaining that in case of Qt5, there are other reasons as well. Making it possible for people to work on frameworks and then use the result in their applications quickly is exactly the reason why we have a monthly release cycle (unlike Qt). You can implement stuff in KF5 and use it the month that follows in the layers above. This is orthogonal to the discussion on version numbering, i.e. I definitely don't see this as an argument in favour of version hell. I think that Christian is saying that he can't really just use a new version of a particular framework because that new version brings along a lot of unrelated changes as well. For some reason (extra testing is required, we want stability) he doesn't want to follow that path. I think that it's a useful feedback from a user's point of view. I don't have an answer on how to fix this without introducing extra work to KF5 maintainers, though. Cheers, Jan -- Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123595: Fix KUser test for Mac.
On May 6, 2015, 6:40 p.m., René J.V. Bertin wrote: I'm not sure, after reading http://pig.made-it.com/uidgid.html also: ``` id nobody uid=4294967294(nobody) gid=4294967294(nobody) groups=4294967294(nobody),12(everyone),61(localaccounts),402(com.apple.sharepoint.group.1),403(com.apple.sharepoint.group.2),100(_lpoperator) ``` and ``` id unknown uid=99(_unknown) gid=99(_unknown) groups=99(_unknown),402(com.apple.sharepoint.group.1),12(everyone),61(localaccounts),403(com.apple.sharepoint.group.2),100(_lpoperator) ``` David Faure wrote: nobody is a special user, let's put that one aside since the unittest doesn't need it. I'm not sure `id` works like the APIs KUser uses. What does the unittest say for you, in fact? (with or without my patch, doesn't matter for debugging this) I certainly hope that KUser agrees with `id` ... Sorry I can't answer your question, I haven't been touching KF5 at all until now. - René J.V. --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123595/#review79976 --- On May 6, 2015, 6:08 p.m., David Faure wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123595/ --- (Updated May 6, 2015, 6:08 p.m.) Review request for KDE Software on Mac OS X, KDE Frameworks and Marko Käning. Repository: kcoreaddons Description --- According to CI [1], an invalid user belongs to nogroup on Mac. Not sure if this is true on all OSX installations though? https://build.kde.org/view/Frameworks%20kf5-qt5/job/kcoreaddons%20master%20kf5-qt5/PLATFORM=OSX,compiler=clang/19/testReport/%28root%29/TestSuite/kusertest/ Diffs - autotests/kusertest.cpp d17a2d3e97d5056524281eb18766377e48a0da35 Diff: https://git.reviewboard.kde.org/r/123595/diff/ Testing --- Still passes on Linux; should fix the CI for mac, AFAICS. Thanks, David Faure ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 123707: Set session manager discard command
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123707/#review80186 --- If filePath() is relative, it can't be used in a discard command. I assume you meant always absolute. This is true in your case (SimpleConfig) but not in all cases. The method filePath() itself assumes a file-based backend (once in the past there was an idea of an ldap-based backend, or a binary db...). I'm not sure which of the two solutions I prefer: 1) filePath() method, but documented to only make sense for SimpleConfig objects 2) using QStandardPaths to find the file from KConfig::name(). This is done a lot more than you think ;) In fact the KConfig constructor takes a QStandardPaths::StandardLocation optional 3rd argument. So it's not unreasonable to look up KConfig::name() in there it's just that in general it'll be a locateAll(), not just a locate() (which is good enough for SimpleConfig). So yeah no LDAP there :-) I think option 2 is better than providing an API that will make KConfig users shoot themselves in the foot. - David Faure On May 10, 2015, 5:11 p.m., Stefan Becker wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/123707/ --- (Updated May 10, 2015, 5:11 p.m.) Review request for KDE Frameworks and Rex Dieter. Bugs: 346768 https://bugs.kde.org/show_bug.cgi?id=346768 Repository: kconfig Description --- If KConfig object provides a non-empty file path then set the session manager discard command to rm file path. This makes sure that obsolete session files are deleted after creating a new one. Diffs - src/core/kconfig.h 6cc7323 src/core/kconfig.cpp 3819716 src/gui/kconfiggui.h 173400f src/gui/kconfiggui.cpp 0048c60 Diff: https://git.reviewboard.kde.org/r/123707/diff/ Testing --- F22 kwrite konsole, ksmserver and Save Session... Thanks, Stefan Becker ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
