Re: Gitlab CI Dashboards and retirement of build.kde.org
Hi Ben, With build/binary-factory , it was possible to get an Embeddable Build Status Icon as this one : https://binary-factory.kde.org/view/AppImage/job/Digikam_Nightly_appimage-centos7/badge/ Does this feature still exist with Gitlab infrastructure ? Thanks Gilles Le sam. 27 août 2022 à 11:45, Ben Cooksley a écrit : > > Hi all, > > This evening I completed the necessary setup required to complete our Gitlab > CI dashboards, which can now be found at > https://metrics.kde.org/dashboards/f/aNxvXJW4k/gitlab-ci (KDE Developer > account login required) > > These allow any developer to get a view on the current CI status of projects > and groups of projects on a branch and platform basis - and should hopefully > provide useful insight into the overall status that can currently be obtained > from Jenkins. > > As this was the last thing holding us back from shutting down build.kde.org, > i'd like to proceed with retiring and shutting down build.kde.org as soon as > possible so the capacity it occupies can be released and reallocated to > Gitlab. > > If anyone would like to experiment with customised views for their own > purposes (where the above provided ones are insufficient) please file a > Sysadmin ticket. > > Please let me know if there are any questions on the above. > > Thanks, > Ben
Re: KSANECore in KDE review
Hi, Just a question about Qt6 support in KSane* API. Do you plan this kind of support in a near future? As i can see libksane is not yet ported. Best regards Gilles Caulier Le sam. 2 avr. 2022 à 11:26, Alexander Stippich a écrit : > > On Sunday, 27 March 2022 21:28:38 CEST Harald Sitter wrote: > > On Sun, Mar 27, 2022 at 6:29 PM Alexander Stippich > wrote: > > > Hello everyone, > > > > > > KSANECore is now in KDE review. Kåre and I mentioned it in previous emails > > > before, but as a short summary: > > > KSANECore is a Qt interface to the SANE scanner library. It is stripped > out of > > > the KSaneWidget of libksane without any QWidget dependency. It is > currently > > > located inside the libksane repository as KSaneCore and basically just > copied > > > into the new repository. > > > > > > Due to breaking API anyway, the code was cleaned up, better named as well > as > > > smaller API fixes made on top. Also, KSANECore is fully REUSE compliant. > > > KSaneWidget of libksane will remain ABI compatible. > > > > > > I don't know if it is strictly required to move the new repo with already > > > existing code through KDE review, but I guessed it is better to be on the > safe > > > side :) > > > > > > The plan is to switch libksane and Skanpage over to the new library during > the > > > KDE Gear 22.08 release cycle. The adaptions are located at > > > https://invent.kde.org/astippich/skanpage/-/commits/ksanecore > > > and > > > https://invent.kde.org/astippich/libksane/-/commits/ksanecoreSplit > > > > amazing! > > > > for everyone's convenience here's the url to the lib ;) > > https://invent.kde.org/libraries/ksanecore > > Thanks! Could have thought about this myself... > > > some comments from scrolling through the code: > > > > you may want to reconsider how stringEnumTranslation works > > https://github.com/KDE/clazy/blob/master/docs/checks/README-non-pod-global-static.md > > either use q_global_static, or - IMHO neater - move it into the > > function loadDeviceOptions as function local static since we don't > > need it outside that function anyway. > > > > CoreInterface, CoreInterfacePrivate, InternalOption, ScanThread and > > CoreOption should have their constructors marked explicit > > > > the typedefs in coreoption.h are super old school maybe modernize them? ;) > > > > some of the API documentation still refers to libksane, should that be > changed? > > All done. > > > on a similar note, you still use the KSane namespace and include > > guards. It may make sense to rename them KSaneCore and KSANECORE > > respectively? for consistency if nothing else > > KSane was chosen deliberately here. The plan is to have a KSane::Core... and > the KSane::Widget in the future. libksane would become KSaneWidget later > during the Qt 6 transition, to keep ABI compatibility for now. > > > if you havent considered this: you might want to use the clang-format > > rules from ECM to join the common formatting we have (and apply that > > via commit hooks) > > Not done yet, but I will look into it. > > > I would argue that reloadDevicesList and getOption(const OptionName > > optionEnum); should have their const dropped. the const there doesn't > > impact the signature and as such is confusing from an API POV > > > > on a matter of less code noise I would use std::make_unique when > > creating new unique ptrs instead of manually passing a raw pointer to > > the ctor. > > > > in CoreInterfacePrivate m_batchMode + Delay are uninitialized in the > > ctor. please initialize them nullptr > > > > since you have Qt6 ifdefs you may want to enable qt6 CI as well > > > > the shebang line in your Messages.sh appears to have lost its position > > and is no longer at the top of the file > > All fixed. > > > you appear to have an autotests dir and cmakelists but no actual tests? :O > > That is reserved for the future when I find the time to actually write the > tests :) > > Thanks for the review! > > Best regards, > Alex > > >
Re: Gitlab CI - Inbound
Congratulations to Ben for this important step in the KDE CI workflow. I'm sure that it's too far ahead, but we will be interested later, when the infrastructure is ready in gitlab, to run all gitlab CI with digiKam code. Of course this requires solving a lot of dependencies, but please keep in mind in the future. This can also be a project to delegate to a student later : "port digiKam CI to Gitlab"... My best regards Gilles Caulier Gilles Caulier Le dim. 5 sept. 2021 à 10:38, Halla Rempt a écrit : > On zondag 5 september 2021 08:13:09 CEST Ben Cooksley wrote: > > Hi all, > > > > This morning after much work i'm happy to announce that the new > generation > > CI scripts intended for use with Gitlab CI successfully completed their > > first build (of ECM, and then subsequently of KCoreAddons). > > > > Yay! > > Halla > > > >
Re: Transition to new mirror infrastructure
Hi all, Until milonia to deino transition stage, we can access to milonia with ssh to transfer weekly build of digiKam bundles, available at this url: https://files.kde.org/digikam/ Now, we get this error message: [gilles@pc-gilles mxe]$ ssh digi...@deino.kde.org Welcome to Ubuntu 20.04.1 LTS (GNU/Linux 5.4.0-52-generic x86_64) * Documentation: https://help.ubuntu.com * Management: https://landscape.canonical.com * Support:https://ubuntu.com/advantage You do not have interactive login access to this machine. Contact the systems administrator for further assistance. Connection to deino.kde.org closed. On of the scripts to manage remote files (Windows bundles in this case) is this one : https://invent.kde.org/graphics/digikam/-/blob/master/project/bundles/mxe/04-build-installer.sh#L297 As you can see, it use ssh, scp, and rsync. We have the same for MacOS, and Linux AppImage... Best regards Gilles Caulier Le ven. 30 oct. 2020 à 09:56, Ben Cooksley a écrit : > > Hi all, > > Just a heads up that over the weekend we're going to be migrating from the > existing mirror master server (known as milonia.kde.org) to the new master > server (which can be found under the name deino.kde.org). > > While this is not expected to have any impact on public access (as both > systems will continue to serve download.kde.org and files.kde.org in the same > form), it does mean that it may not be possible to upload new files for a > short period of time. > > For those who are looking to upload files or perform releases over the > weekend, it would be appreciated if you could please contact us so we can > ensure that you are guided to the correct system. > > Thanks, > Ben Cooksley > KDE Sysadmin
Re: http://commitfilter.kde.org/ ?
My solution, to follow all *digiKam* is to susbcribe to kde-commits mailing list and to make a mail filter with "digikam" inside. All others go to trash as well. It work well. It's not the best because it require more mail workflow from the server to send all commits mail, the filtering is done on my side. Cheer Gilles Caulier 2017-11-03 15:07 GMT+01:00 Dominik Haumann <dhaum...@kde.org>: > Hi, > > On Mon, Oct 30, 2017 at 8:38 AM, Ben Cooksley <bcooks...@kde.org> wrote: > > On Mon, Oct 30, 2017 at 6:38 PM, Martin Koller <kol...@aon.at> wrote: > >>> On Sun, Oct 29, 2017 at 9:47 PM, Martin Koller <kol...@aon.at> wrote: > >>> > Should http://commitfilter.kde.org/ still exist ? > >>> > Currently I get "unknown host" > >>> > >> On Sonntag, 29. Oktober 2017 22:33:20 CET Harald Sitter wrote: > >>> See > >>> > >>> http://markmail.org/thread/hekkp2rcdvir732q > >>> http://markmail.org/thread/b6neyhjak2h4g2yd > >> > >> rephrasing: is there still a way to receive commit mails to the various > git repositories > >> or is this feature completely gone ? > > My solution was to subscribe to kde-comm...@kde.org + add filters there. > > Even if getting emails from phabricator would work, I'm pretty sure I > would not like the format. > > The mails send from our commit scripts to kde-comm...@kde.org are > exactly what I want, with the information just right, and not too much > noise. > > Greetings > Dominik >
Re: KTabWidget vs QTabWidget
Into digiKam, i do exactly a pure Qt5 port of KTabWidget to QTabWidget, especially about D Look my commit : https://quickgit.kde.org/?p=digikam.git=commit=11b5e18d24d80a1bf34fdcc78064a7cb8a26fabc Best Gilles Caulier 2015-09-19 9:19 GMT+02:00 Thomas Lübking <thomas.luebk...@gmail.com>: > Disclaimer: I've no knowledge about the made decision process/intentions. > > On Samstag, 19. September 2015 02:46:24 CEST, Jeremy Whiting wrote: > >> KTabWidget documentation on api.kde.org it still says that KTabWidget is >> preferred over QTabWidget [1]. >> > > Wild guess: the class was moved, but nobody took a close look at the > comments, so the API docu remained the same and on Qt4 level. > > In reading Qt documentation about drag and drop [2] it seems that you >> need to subclass widgets in order to specify any additional mime types >> that should be handled by a drop event >> > > No, you can also install an eventfilter (on QTabBar/QTabWidget, the > feature code was/is mostly in KTabBar, KTabWidget largely only forwards it) > > (which we have in KTabWidget... so why not just use it...) >> > > Probably because it contains much additional code and dropping mime is too > rare - and usually only required from one location. > The effort to bind the signals isn't much different from providing an > eventfilter, QTabBar has ::tabAt(), so you already have the index for the > event position. > > Am I missing something? If not I suggest we reconsider and maybe >> move/copy? >> > > "move". Having the same symbol in KWidgetAddons and kde4libssupport is > gonna break things - badly. > > or maybe users of KTabWidget should just keep using KDELibs4Support? >> > > I assume this is why the support lib exists - you can keep the widget > until you ported away :-P > > Cheers, > Thomas >
Re: libkgeomap
2015-01-30 11:18 GMT+01:00 Pino Toscano p...@kde.org: On Friday 30 January 2015 09:16:47 Raymond Wooninck wrote: But as that Digikam is moving more and more to a Qt5 application, then a Frameworks based one I wonder if the maintainers will go for this separation. I don't see how things will change because of this. Currently, the kdegraphics libraries (libkipi, libkexiv2, libdcraw, and recently also libkface) have regular release together with KDE SC/whatever; however, they are bundled (as snapshots from git/master, even) in the digikam release tarball as well, and possibly digikam even requires (it did a couple of times in the past) functions added only to master in those libraries, and not available in their last stable series. False. libs are bundled in tarball, but not used at compilation time (look cmake options in SC repository). In short: maintainers should simply stop bundling libraries together with digikam, and just make sure digikam (and kipi-plugins as well) builds and work fine at least with the latest stable series of them. Back to the topic of this thread: I'd mildly oppose to move libkgeomap to kdegraphics, since: a) its API and ABI get broken from time to time (even too often), with no actual bump of SONAME false. Look API and ABI history in top of lead cmake scripts for each projects... b) digikam people rarely care about non-master branches of those libraries, fixing bugs in master only and leaving stable series without fixes (and distros usually have to backport those on their own) false. When it's possible we do it, when time permit. c) there is simply nothing that prevents something in extragear/libs to have own releases (and actually, that's exactly what extragear is for), and to be used by other applications This join my older viewpoint (5/6 years ago) to NOT share libkipi, libkdcraw, libkexiv2, etc with the rest of the world because it will be amount to work to solve problems due to sharing rules. I remember peoples from KDE who ask to changes my viewpoint... We have tried to do the best, and as i can see it's never enough... Gilles Caulier
Re: libkgeomap
Hi, Happy New Year to all in this room. Thanks Micheal for all details about libkgeomap history, especially GoogleMaps rules. Just few words about libkgeomap KF5 port : - Library is fully ported as QT5/KF5 and sound work fine. - Alin Marin Elen alinm.el...@gmail.com currently work on KGeoMap::HTMLWidget class to port from KHTML to Qt5::Webkit. All details are listed in this wiki page section : https://techbase.kde.org/Projects/Digikam/CodingSprint2014#Libkgeomap Michael, if you have some free time to review code later, it will be great. Thanks in advance. Best Gilles Caulier 2015-01-04 20:21 GMT+01:00 Michael G. Hansen m...@mghansen.de: On 03.01.2015 15:09, Tobias Leupold wrote: IMHO, the real question is, shouldn't that pointless wrapper be deprecated in favor of just using Marble directly? Can marble be used in an identical way as libkgeomap, as a QWidget only displaying a map with not only coordinates but also photo thumbnails (grouping the coordinates when the zoom factor is too low to display them all etc.), GPX tracks and so on? If so, we (at KPA) should rethink our implementation (but I don't think that libkgeomap has been written for no reason ...). But after all, it's a eligible question (which surely can be answered by Gilles Caulier and/or Michael Hansen). In the beginning, there was code in digikam that displayed and grouped thumbnails of images on Marble, while in kipi-plugins there was a KHTML-based viewer for Google Maps, which only showed a marker at the position of the photo. Since we wanted both Marble and Google Maps in both places, we went the natural way of turning that code into a library so that it can be used in both places without duplicating code. Originally, we also wanted to show a web-based OpenStreetMap directly via KHTML to allow for more interaction with OpenStreetMap's layering options, but that option was abandoned because of incompatibilities between KHTML and OpenStreetMap's OpenLayer Javascript code at that time. Apart from that: If Google's terms of service allow using Google maps like libkgeomap does, I think it should be a decision of the user which map he/she wants to see. From the way I understood the terms of service, yes, this usage is ok. We also had a Google Summer of Code student work on the library, and the project was not rejected by Google. Of course I would rather see a collection of open data satellite imagery to be used instead, but I could not find any yet. Best regards, Michael Hansen
Re: libkgeomap
2015-01-01 23:16 GMT+01:00 Albert Astals Cid aa...@kde.org: El Diumenge, 21 de desembre de 2014, a les 19:39:27, Tobias Leupold va escriure: Am Sonntag 21 Dezember 2014, 19:27:48 schrieb Albert Astals Cid: H, i understand you're the only user at the moment, but how is libkgeomap is a wrapper between marble for local map, OpenStreetMap, and GoogleMaps, to display geolocated items place over a world map. A widget is provided, and collection of tools to process : - Reverse Geocoding, - Tracks management, - Selection over map to process searches. * Photo Management related? We use it to display the location(s) where (a) photo(s) has/have been taken. It helps tagging photos, and later, you can simply see that place when viewing a photo. That's what you use it for, but can I use it to show the places my bank has offices? I'm not sure to understand... Typically, libkgeomap don't care about files to manage. It's item to geolocalize. In digiKam we have a small interface to wrap libkgeomap with image geolocation stored in database. The real link between GPS info to display over the map and image/Video are done here. So, you can wrap your main data to geolocalize by the same way. libkgeompa do care about data which will store GPS info. Gilles Caulier
Re: libkgeomap
2015-01-01 23:40 GMT+01:00 Albert Astals Cid aa...@kde.org: El Dijous, 1 de gener de 2015, a les 23:23:16, Gilles Caulier va escriure: 2015-01-01 23:16 GMT+01:00 Albert Astals Cid aa...@kde.org: El Diumenge, 21 de desembre de 2014, a les 19:39:27, Tobias Leupold va escriure: Am Sonntag 21 Dezember 2014, 19:27:48 schrieb Albert Astals Cid: H, i understand you're the only user at the moment, but how is libkgeomap is a wrapper between marble for local map, OpenStreetMap, and GoogleMaps, to display geolocated items place over a world map. A widget is provided, and collection of tools to process : - Reverse Geocoding, - Tracks management, - Selection over map to process searches. * Photo Management related? We use it to display the location(s) where (a) photo(s) has/have been taken. It helps tagging photos, and later, you can simply see that place when viewing a photo. That's what you use it for, but can I use it to show the places my bank has offices? I'm not sure to understand... Typically, libkgeomap don't care about files to manage. It's item to geolocalize. Right, so it doesn't have much to do with graphics, right? That's what i'm saying. in theory, yes. Gilles
Re: libkgeomap
If kdegraphics/libs is possible, it will be the best, because all other Photo Management shared libs are already in this module (libkipi, libkdcraw, libkexiv2, libkface, etc...). 2014-12-21 17:50 GMT+01:00 Albert Astals Cid aa...@kde.org: El Diumenge, 21 de desembre de 2014, a les 23:26:04, Ben Cooksley va escriure: On Sun, Dec 21, 2014 at 5:31 AM, Albert Astals Cid aa...@kde.org wrote: El Diumenge, 14 de desembre de 2014, a les 18:57:44, Tobias Leupold va escriure: Hi list! recently, I requested to move libkface from extragear/libs to to kdegraphics/libs, because KPhotoAlbum began to use it as the first non-Digikam program. This has been done in the meantime and now, we have a Digikam- independent libkface release to be found in unstable/applications (which can be used by distributors to create Digikam-independent libkface packages). Thanks again for the move :-) Recently, we started to use another library from Digikam in KPhotoAlbum, libkgeomap. Would it be possible (of course after some review etc.) to do the same with this library, for the same reasons? Probably, kdegraphics/libs would not be the right place for libkgeomap, as it depends on Marble, but kde-edu. Gilles Caulier from Digikam recently suggested that I asked for that, because apparently a lot of patching has been done to libkgeomap so that a stand-alone library release would be possible. I'm sure that the libkgeomap maintainers (esp. Gilles Caulier) will gladly change what has to be changed to get an independent release, and we would get the same benefits of it as the libkface move made. What do you think? Noone else has an opinion at all? This seems like a sound move from my perspective - ensuring libraries get regular releases is important for both future users of the library and ensuring users get the fixes which are made over time without having to do a feature upgrade. Does someone has a suggestion for a module for this new library? Cheers, Albert Cheers, Albert Thanks, Ben Cheers, Tobias
Re: libkgeomap
I would just to indicate that libkgeomap is already ported to KF5, as libkipi, libkexiv2, libkface, and libkdcraw. see this wiki page for details : https://techbase.kde.org/Projects/Digikam/CodingSprint2014#KF5.2FQt5_Port_Status Gilles Caulier 2014-12-14 18:57 GMT+01:00 Tobias Leupold tobias.leup...@web.de: Hi list! recently, I requested to move libkface from extragear/libs to to kdegraphics/libs, because KPhotoAlbum began to use it as the first non-Digikam program. This has been done in the meantime and now, we have a Digikam- independent libkface release to be found in unstable/applications (which can be used by distributors to create Digikam-independent libkface packages). Thanks again for the move :-) Recently, we started to use another library from Digikam in KPhotoAlbum, libkgeomap. Would it be possible (of course after some review etc.) to do the same with this library, for the same reasons? Probably, kdegraphics/libs would not be the right place for libkgeomap, as it depends on Marble, but kde-edu. Gilles Caulier from Digikam recently suggested that I asked for that, because apparently a lot of patching has been done to libkgeomap so that a stand-alone library release would be possible. I'm sure that the libkgeomap maintainers (esp. Gilles Caulier) will gladly change what has to be changed to get an independent release, and we would get the same benefits of it as the libkface move made. What do you think? Cheers, Tobias
Re: libkgeomap
libkgeomap is a wrapper between marble for local map, OpenStreetMap, and GoogleMaps, to display geolocated items place over a world map. A widget is provided, and collection of tools to process : - Reverse Geocoding, - Tracks management, - Selection over map to process searches. It used in digiKam to : - show geolocation info about selected items from icon view, - show a map with region selector to process searches - show a big map view to replace icon-view by a map with all items superimposed. It used too, in kipi-plugins with GPSSync tool to : - Correlate items with a GPX track - Made GPS track - Perform reverse Geocoding using Internet server. Project page : https://projects.kde.org/projects/extragear/libs/libkgeomap API Doc : http://api.kde.org/extragear-api/libs-apidocs/libkgeomap/libkgeomap/html/index.html Gilles Caulier 2014-12-15 21:46 GMT+01:00 Albert Astals Cid aa...@kde.org: El Diumenge, 14 de desembre de 2014, a les 18:57:44, Tobias Leupold va escriure: Hi list! recently, I requested to move libkface from extragear/libs to to kdegraphics/libs, because KPhotoAlbum began to use it as the first non-Digikam program. This has been done in the meantime and now, we have a Digikam- independent libkface release to be found in unstable/applications (which can be used by distributors to create Digikam-independent libkface packages). Thanks again for the move :-) Recently, we started to use another library from Digikam in KPhotoAlbum, libkgeomap. Would it be possible (of course after some review etc.) to do the same with this library, for the same reasons? Probably, kdegraphics/libs would not be the right place for libkgeomap, as it depends on Marble, but kde-edu. Gilles Caulier from Digikam recently suggested that I asked for that, because apparently a lot of patching has been done to libkgeomap so that a stand-alone library release would be possible. I'm sure that the libkgeomap maintainers (esp. Gilles Caulier) will gladly change what has to be changed to get an independent release, and we would get the same benefits of it as the libkface move made. What do you think? What does libkgeomap do? Cheers, Albert Cheers, Tobias
Re: libkgeomap
2014-12-15 22:01 GMT+01:00 Albert Astals Cid aa...@kde.org: El Dilluns, 15 de desembre de 2014, a les 21:57:05, Gilles Caulier va escriure: libkgeomap is a wrapper between marble for local map, OpenStreetMap, and GoogleMaps, to display geolocated items place over a world map. A widget is provided, and collection of tools to process : - Reverse Geocoding, - Tracks management, - Selection over map to process searches. It used in digiKam to : - show geolocation info about selected items from icon view, - show a map with region selector to process searches - show a big map view to replace icon-view by a map with all items superimposed. It used too, in kipi-plugins with GPSSync tool to : - Correlate items with a GPX track - Made GPS track - Perform reverse Geocoding using Internet server. So kipi-plugins depends on digikam? Random questions: * Where does marble come in? It's a external dependency from KDE-edu. We use marble widget. * How is google maps handled? AFAIR you can't just embed it like that in an app. Through Khtml currently. For KF5, we will port to webkkit as well. Gilles Caulier
Re: libkgeomap
2014-12-15 22:01 GMT+01:00 Albert Astals Cid aa...@kde.org: El Dilluns, 15 de desembre de 2014, a les 21:57:05, Gilles Caulier va escriure: libkgeomap is a wrapper between marble for local map, OpenStreetMap, and GoogleMaps, to display geolocated items place over a world map. A widget is provided, and collection of tools to process : - Reverse Geocoding, - Tracks management, - Selection over map to process searches. It used in digiKam to : - show geolocation info about selected items from icon view, - show a map with region selector to process searches - show a big map view to replace icon-view by a map with all items superimposed. It used too, in kipi-plugins with GPSSync tool to : - Correlate items with a GPX track - Made GPS track - Perform reverse Geocoding using Internet server. So kipi-plugins depends on digikam? No. kipi-plugins and digiKam depends of libkgeomap which host common implementations. Gilles Caulier
Fwd: kdepimlibs Coverity Scan Report, Oct 14 2014
Allen, Just a workflow question : why to export Coverity report to CSV where you can send automatically a mail to devel mailing list when scan is complete, with a a list of new defect found in code. I use Coverity since more than one year with whole digiKam code, and we have already fixed more than 500 entries detected. The Coverity web interface is really more suitable than a export to CSV. Defect are very well explained in source context, with all conditions used to check implementation. The only constrain is to have an account for each contributors who will fixed entries. After one year to use this tool, the feedback is really excellent, especially to check new code from students. Best Gilles Caulier 2014-10-14 14:30 GMT+02:00 Allen Winter allen.d.win...@gmail.com: Howdy, Attached is the Coverity Scan report for kdepimlibs 4.14 as of today. You might feel like fixing some of the issues. Let me know if you find false positives or stuff we can ignore (like in test programs).
Re: libkface
2014-10-15 22:56 GMT+02:00 Albert Astals Cid aa...@kde.org: Hi Gilles we just found a problem in libkface. It has i18n() calls but no Messages.sh and no KCatalogLoader to load it's translation catalog. Can you please take care of fixing that? Done : http://commits.kde.org/libkface/2a80e6681fc98c9acba3dda00e33cbb894870857 Gilles
Re: libkface
2014-10-10 23:21 GMT+02:00 Tobias Leupold tobias.leup...@web.de: Am Freitag 10 Oktober 2014, 23:03:26 schrieb Albert Astals Cid: Before it happening at least i'd like to have: * identity.h fixed to have a d-pointer At least, this has already been done. The respective patch is ready, cf. Bug #339524. Gilles said it will be applied after the latest Digikam release, so I think he'll do it soon. * dataproviders.h to not have code in the header I think (hope ;-) Gilles and/or Marcel will answer/do this as well. Tobias, Both problems are already fixed in git/master. Bug #339524 is closed. Gilles
Re: libkface
So, what's missing to process migration from extragear/libs to kdegraphics/libs ? Who process migration ? KDE admin ? Gilles 2014-10-11 11:23 GMT+02:00 Gilles Caulier caulier.gil...@gmail.com: 2014-10-10 23:21 GMT+02:00 Tobias Leupold tobias.leup...@web.de: Am Freitag 10 Oktober 2014, 23:03:26 schrieb Albert Astals Cid: Before it happening at least i'd like to have: * identity.h fixed to have a d-pointer At least, this has already been done. The respective patch is ready, cf. Bug #339524. Gilles said it will be applied after the latest Digikam release, so I think he'll do it soon. * dataproviders.h to not have code in the header I think (hope ;-) Gilles and/or Marcel will answer/do this as well. Tobias, Both problems are already fixed in git/master. Bug #339524 is closed. Gilles
Re: libkface
2014-10-10 23:03 GMT+02:00 Albert Astals Cid aa...@kde.org: El Dijous, 25 de setembre de 2014, a les 12:14:43, Tobias Leupold va escriure: Hi list! The discussion on kde-graphics-devel finished with the statement this had to be determined by kde-core-devel. So what do you think? From reading the emails i understand there's no problem and we should include libkface in next KDE Applications 14.12 release? Before it happening at least i'd like to have: * identity.h fixed to have a d-pointer Fixed with these commits : http://commits.kde.org/libkface/cc6a4ca7d7b61eeebe8438bcec2a93659af2a745 * dataproviders.h to not have code in the header http://commits.kde.org/libkface/707bd3694872f3a8e150b907368221ba5e8a67fa Gilles
Re: libkface
2014-09-30 7:44 GMT+02:00 Gilles Caulier caulier.gil...@gmail.com: 2014-09-30 3:06 GMT+02:00 Vishesh Handa m...@vhanda.in: Hey Tobias Some comments about the code - 1. The code seems to be licensed under GPL. In order to make it into a framework, it will need to be re-licensed. This library seems like an ideal candidate for becoming a framework. libkface have been writted in same way than libkipi, libkexiv2, and libkdcraw, already in KDEGraphics. https://projects.kde.org/projects/kde/kdegraphics/libs/libkipi https://projects.kde.org/projects/kde/kdegraphics/libs/libkexiv2 https://projects.kde.org/projects/kde/kdegraphics/libs/libkdcraw 2. The copyright header seems to say Part of the Digikam Project. You may want to change that. Idem here. libkface follow exactly the same way than libkipi, libkexiv2, libkdcraw. 3. There is an empty TODO file yes, this need to be filled. 4. The coding style uses seems a little unorthdox. Could you perhaps add a link to where one can know what style is being followed? Maybe this could go in the README file. coding style follow instructions from digiKam project : https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/HACKING It's the same coding style that libkexiv2, libkipi, and libkdcraw. 5. Identity ABI - The Identity class seems to be missing a d pointer. New bugzilla entry created with patch : https://bugs.kde.org/show_bug.cgi?id=339524 Tobias, this need to be tested. Also, PhotoAlbum code need to be adapted. Gilles
Re: libkface
2014-09-30 11:28 GMT+02:00 Martin Klapetek martin.klape...@gmail.com: On Tue, Sep 30, 2014 at 7:44 AM, Gilles Caulier caulier.gil...@gmail.com wrote: 2014-09-30 3:06 GMT+02:00 Vishesh Handa m...@vhanda.in: Hey Tobias Some comments about the code - 1. The code seems to be licensed under GPL. In order to make it into a framework, it will need to be re-licensed. This library seems like an ideal candidate for becoming a framework. libkface have been writted in same way than libkipi, libkexiv2, and libkdcraw, already in KDEGraphics. Hi Martin, The thing is - if libkface is set to become a framework and be part of the KDE Frameworks effort, it has to follow KDE Frameworks policies and rules. One of those is that the code is licensed under LGPLv2.1+ (I think, someone correct me if I'm wrong). So libkface would have to be relicensed. Unfortunately same for the other listed libraries if they should become frameworks. And we would most certainly welcome that ;) Sure, libkipi, libkexiv2, and libkdcraw will be ported to KF5, as they are already included into kdegraphics. I don't have any objection to re-license these libs... Gilles
Re: libkface
2014-09-30 11:57 GMT+02:00 David Edmundson da...@davidedmundson.co.uk: On Tue, Sep 30, 2014 at 11:38 AM, Gilles Caulier caulier.gil...@gmail.com wrote: 2014-09-30 11:28 GMT+02:00 Martin Klapetek martin.klape...@gmail.com: On Tue, Sep 30, 2014 at 7:44 AM, Gilles Caulier caulier.gil...@gmail.com wrote: 2014-09-30 3:06 GMT+02:00 Vishesh Handa m...@vhanda.in: Hey Tobias Some comments about the code - 1. The code seems to be licensed under GPL. In order to make it into a framework, it will need to be re-licensed. This library seems like an ideal candidate for becoming a framework. libkface have been writted in same way than libkipi, libkexiv2, and libkdcraw, already in KDEGraphics. Hi Martin, The thing is - if libkface is set to become a framework Right now it's only targeting a lib in kdegraphics, not a framework. yes, this is the first stage. Note : libkexiv2, libkdcraw, and libkipi are not yet ported to KF5, but it's planed in the future... Gilles Caulier
Re: libkface
2014-09-30 3:06 GMT+02:00 Vishesh Handa m...@vhanda.in: Hey Tobias Some comments about the code - 1. The code seems to be licensed under GPL. In order to make it into a framework, it will need to be re-licensed. This library seems like an ideal candidate for becoming a framework. libkface have been writted in same way than libkipi, libkexiv2, and libkdcraw, already in KDEGraphics. https://projects.kde.org/projects/kde/kdegraphics/libs/libkipi https://projects.kde.org/projects/kde/kdegraphics/libs/libkexiv2 https://projects.kde.org/projects/kde/kdegraphics/libs/libkdcraw 2. The copyright header seems to say Part of the Digikam Project. You may want to change that. Idem here. libkface follow exactly the same way than libkipi, libkexiv2, libkdcraw. 3. There is an empty TODO file yes, this need to be filled. 4. The coding style uses seems a little unorthdox. Could you perhaps add a link to where one can know what style is being followed? Maybe this could go in the README file. coding style follow instructions from digiKam project : https://projects.kde.org/projects/extragear/graphics/digikam/repository/revisions/master/entry/HACKING It's the same coding style that libkexiv2, libkipi, and libkdcraw. 5. Identity ABI - The Identity class seems to be missing a d pointer. yes, this need to be fixed. libkface ABI / API id need to be increased. 6. From what I understand, facial recognition is not particularly cheap. However, the APIs appear to be blocking. What is the correct way to use them? Spawn a new thread? Run under a QRunnable? in digiKam, Face Recognition run in separated threads through QThread. Best Gilles Caulier
Re: libkface
2014-09-27 12:55 GMT+02:00 David Edmundson da...@davidedmundson.co.uk: And then digikam will stop using their own copy? If so this change makes complete sense to me. yes, it is. this is the goal. You could also consider making it a framework in the future if you think it would have wider usage outside kdegraphics apps. We will see. Step by step... Gilles Caulier
Re: libkface
2014-09-27 12:59 GMT+02:00 David Edmundson da...@davidedmundson.co.uk: Please make sure to add license headers on all files in libkface before release. There seem to be a lot missing. Hum, which one ? I review all code in libkface in-deep while 2 weeks this summer and i think to not have forget something here... Gilles Caulier
Re: projects page dead ?
same here... Gilles Caulier 2013/11/29 Hugo Pereira Da Costa hugo.pere...@free.fr: https://projects.kde.org/projects/ gives 'bad gateway'. Is it just me ? A known (hopefully temporary) issue ? Has the page moved ? Thanks in advance, Hugo
Re: Review Request 112991: Fix compilation rules of KDE-Workspace under OSX/Macports
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112991/ --- (Updated Oct. 26, 2013, 4:57 a.m.) Review request for kde-workspace. Changes --- New patch to fix compile rules under OSX with KDE 4.11 branch Bugs: https://trac.macports.org/ticket/33780 http://bugs.kde.org/show_bug.cgi?id=https://trac.macports.org/ticket/33780 Repository: kde-workspace Description --- This patch fix broken compilation under OSX / macports about kde-workspace. Patch do not touch implementation. Only compilation rules are changed in cmake script to follow the way way than Windows rules, where no X11 lib are available. By this way, Oxygen is compiled and installed to macport and digiKam has a suitable GUI under OSX. See my Macports bug report for details : https://trac.macports.org/ticket/33780 Gilles Caulier Diffs - CMakeLists.txt c37ab8b kcontrol/CMakeLists.txt a25aaa0 libs/CMakeLists.txt 9d71a03 Diff: http://git.reviewboard.kde.org/r/112991/diff/ Testing --- I tested this patch under my macbook pro, using a fresh install of Macports (KDE 4.11.1 / Qt 4.8.5) As kde-workspace macports package is broken, i checkout code from KDE git/master repository and fixed compilation rules as well. File Attachments (updated) patch to fix compilation rules under OSX with KDE 4.11 branch http://git.reviewboard.kde.org/media/uploaded/files/2013/10/26/644e987a-967f-44f0-a266-428f4c9b9579__compilerulesOSX-KDE411.patch Thanks, Gilles Caulier
Re: Review Request 112991: Fix compilation rules of KDE-Workspace under OSX/Macports
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112991/#review42169 --- Martin, KDE 4.11 or master (Qt5) _must_ compile under OSX. My current patch work fine against master and can be applied to git repository. I currently working to adjust this patch with KDE 4.11 branch. I know that most of developers work under Linux and X11 based system. But this must not be a portability limitation, especially when people provide a patch on other platform. After all, Windows is also supported by KDE-Workspace, why not OSX. My patch simply reproduce compilation rules defined by Windows to OSX. Gilles Caulier - Gilles Caulier On Sept. 29, 2013, 5:15 p.m., Gilles Caulier wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112991/ --- (Updated Sept. 29, 2013, 5:15 p.m.) Review request for kde-workspace. Bugs: https://trac.macports.org/ticket/33780 http://bugs.kde.org/show_bug.cgi?id=https://trac.macports.org/ticket/33780 Repository: kde-workspace Description --- This patch fix broken compilation under OSX / macports about kde-workspace. Patch do not touch implementation. Only compilation rules are changed in cmake script to follow the way way than Windows rules, where no X11 lib are available. By this way, Oxygen is compiled and installed to macport and digiKam has a suitable GUI under OSX. See my Macports bug report for details : https://trac.macports.org/ticket/33780 Gilles Caulier Diffs - CMakeLists.txt c37ab8b kcontrol/CMakeLists.txt a25aaa0 libs/CMakeLists.txt 9d71a03 Diff: http://git.reviewboard.kde.org/r/112991/diff/ Testing --- I tested this patch under my macbook pro, using a fresh install of Macports (KDE 4.11.1 / Qt 4.8.5) As kde-workspace macports package is broken, i checkout code from KDE git/master repository and fixed compilation rules as well. Thanks, Gilles Caulier
Re: Dependency to unreleased versions
Fixed with this commit : http://commits.kde.org/libkdcraw/6c91e18cedfe5ef37d202f6d0cf4fde1a607a9a9 I just tested with official Libraw 0.14.7 from my Mageia Linux box, and all digiKam co compile fine. It must be the same for the rest of KDE. But, as i explain in commit log, in case of Libraw version is 0.16.0, not all features from Libraw can be used in client applications due to missing libraw-config.h which has be introduced by me in 0.16. Typically, it's not a too much important regression. All default features will work in most of case to demosaic RAW file. Only speed optimization will miss in client applications. I will check under OSX and Windows today, but i'm sure that all will work perfectly... Gilles Caulier 2013/10/21 Gilles Caulier caulier.gil...@gmail.com: 2013/10/21 Albert Astals Cid aa...@kde.org: El Diumenge, 20 d'octubre de 2013, a les 22:53:22, Gilles Caulier va escriure: Soon will be few days. But it will be just a beta release, not a stable. I will try to find a way next week to check libraw 0.16 with cmake to solve this issue. Does that mean that: * libkdcraw for the 4.12 release will only compile with a beta release of libraw or * libkdcraw for the 4.12 release will compile with both libraw 0.15 and a beta release of libraw? I will find a way to support both version, 0.15. and 0.16 Gilles
Re: Dependency to unreleased versions
Problem already reported here : https://bugs.kde.org/show_bug.cgi?id=326368 It's completly different issue. Sound like client libraw code (as libkdcraw) need to be linked to libgomp when libraw OpenMP support is enabled. As libraw has already resolved OpenMP symbols at packaging time, why libkdcraw need again to resolve these ? OpenMP support is internal to libraw. Client code as libkdcraw do not use OpenMP API. I suspect something wrong in libraw packaging. Under Mageia, i cannot reproduce the problem... Gilles Caulier 2013/10/21 Albert Astals Cid aa...@kde.org: El Dilluns, 21 d'octubre de 2013, a les 09:14:54, Gilles Caulier va escriure: Fixed with this commit : http://commits.kde.org/libkdcraw/6c91e18cedfe5ef37d202f6d0cf4fde1a607a9a9 I just tested with official Libraw 0.14.7 from my Mageia Linux box, and all digiKam co compile fine. It must be the same for the rest of KDE. Still red on build.kde.org Can you have a look? http://build.kde.org/view/All/job/libkdcraw_master/ Cheers, Albert But, as i explain in commit log, in case of Libraw version is 0.16.0, not all features from Libraw can be used in client applications due to missing libraw-config.h which has be introduced by me in 0.16. Typically, it's not a too much important regression. All default features will work in most of case to demosaic RAW file. Only speed optimization will miss in client applications. I will check under OSX and Windows today, but i'm sure that all will work perfectly... Gilles Caulier 2013/10/21 Gilles Caulier caulier.gil...@gmail.com: 2013/10/21 Albert Astals Cid aa...@kde.org: El Diumenge, 20 d'octubre de 2013, a les 22:53:22, Gilles Caulier va escriure: Soon will be few days. But it will be just a beta release, not a stable. I will try to find a way next week to check libraw 0.16 with cmake to solve this issue. Does that mean that: * libkdcraw for the 4.12 release will only compile with a beta release of libraw or * libkdcraw for the 4.12 release will compile with both libraw 0.15 and a beta release of libraw? I will find a way to support both version, 0.15. and 0.16 Gilles
Re: Dependency to unreleased versions
Hi, The first beta of libraw 0.16 will be done soon, accordingly with libraw team. 0.16 release will introduce whole compilation rules driven by cmake (completed by me). Best Gilles Caulier 2013/10/20 Torgny Nyblom nyb...@kde.org: Hi, What is the policy of depending on unreleased libraries? And is that written down somewhere? Reason I'm asking is this commit http://build.kde.org/view/FAILED/job/libkdcraw_master/83/changes#detail1 It introduces a dependency to libraw 0.16 witch is not released. /Regards Torgny
Re: Dependency to unreleased versions
Soon will be few days. But it will be just a beta release, not a stable. I will try to find a way next week to check libraw 0.16 with cmake to solve this issue. Gilles Caulier 2013/10/20 Alexander Neundorf neund...@kde.org: On Sunday 20 October 2013, Torgny Nyblom wrote: Hi, What is the policy of depending on unreleased libraries? And is that written down somewhere? Reason I'm asking is this commit http://build.kde.org/view/FAILED/job/libkdcraw_master/83/changes#detail1 It introduces a dependency to libraw 0.16 witch is not released. IMO it's a pain to depend on unreleased versions of anything. Alex
Re: Dependency to unreleased versions
2013/10/21 Albert Astals Cid aa...@kde.org: El Diumenge, 20 d'octubre de 2013, a les 22:53:22, Gilles Caulier va escriure: Soon will be few days. But it will be just a beta release, not a stable. I will try to find a way next week to check libraw 0.16 with cmake to solve this issue. Does that mean that: * libkdcraw for the 4.12 release will only compile with a beta release of libraw or * libkdcraw for the 4.12 release will compile with both libraw 0.15 and a beta release of libraw? I will find a way to support both version, 0.15. and 0.16 Gilles
Re: Review Request 112991: Fix compilation rules of KDE-Workspace under OSX/Macports
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112991/#review41897 --- Ok, thanks for you feedback. I make patch with git/master, not KDE/4.11 branch. I will checkout this code and adapt patch accordingly Gilles Caulier - Gilles Caulier On Sept. 29, 2013, 5:15 p.m., Gilles Caulier wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112991/ --- (Updated Sept. 29, 2013, 5:15 p.m.) Review request for kde-workspace. Bugs: https://trac.macports.org/ticket/33780 http://bugs.kde.org/show_bug.cgi?id=https://trac.macports.org/ticket/33780 Repository: kde-workspace Description --- This patch fix broken compilation under OSX / macports about kde-workspace. Patch do not touch implementation. Only compilation rules are changed in cmake script to follow the way way than Windows rules, where no X11 lib are available. By this way, Oxygen is compiled and installed to macport and digiKam has a suitable GUI under OSX. See my Macports bug report for details : https://trac.macports.org/ticket/33780 Gilles Caulier Diffs - CMakeLists.txt c37ab8b kcontrol/CMakeLists.txt a25aaa0 libs/CMakeLists.txt 9d71a03 Diff: http://git.reviewboard.kde.org/r/112991/diff/ Testing --- I tested this patch under my macbook pro, using a fresh install of Macports (KDE 4.11.1 / Qt 4.8.5) As kde-workspace macports package is broken, i checkout code from KDE git/master repository and fixed compilation rules as well. Thanks, Gilles Caulier
Re: Review Request 112991: Fix compilation rules of KDE-Workspace under OSX/Macports
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112991/#review41727 --- There is nobody to review this simple complation fix for OSX ? Let's me hear if you need info relevant. Thanks in advance. Gilles Caulier - Gilles Caulier On Sept. 29, 2013, 5:15 p.m., Gilles Caulier wrote: --- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112991/ --- (Updated Sept. 29, 2013, 5:15 p.m.) Review request for kde-workspace. Bugs: https://trac.macports.org/ticket/33780 http://bugs.kde.org/show_bug.cgi?id=https://trac.macports.org/ticket/33780 Repository: kde-workspace Description --- This patch fix broken compilation under OSX / macports about kde-workspace. Patch do not touch implementation. Only compilation rules are changed in cmake script to follow the way way than Windows rules, where no X11 lib are available. By this way, Oxygen is compiled and installed to macport and digiKam has a suitable GUI under OSX. See my Macports bug report for details : https://trac.macports.org/ticket/33780 Gilles Caulier Diffs - CMakeLists.txt c37ab8b kcontrol/CMakeLists.txt a25aaa0 libs/CMakeLists.txt 9d71a03 Diff: http://git.reviewboard.kde.org/r/112991/diff/ Testing --- I tested this patch under my macbook pro, using a fresh install of Macports (KDE 4.11.1 / Qt 4.8.5) As kde-workspace macports package is broken, i checkout code from KDE git/master repository and fixed compilation rules as well. Thanks, Gilles Caulier
Review Request 112991: Fix compilation rules of KDE-Workspace under OSX/Macports
--- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/112991/ --- Review request for kde-workspace. Description --- This patch fix broken compilation under OSX / macports about kde-workspace. Patch do not touch implementation. Only compilation rules are changed in cmake script to follow the way way than Windows rules, where no X11 lib are available. By this way, Oxygen is compiled and installed to macport and digiKam has a suitable GUI under OSX. See my Macports bug report for details : https://trac.macports.org/ticket/33780 Gilles Caulier This addresses bug https://trac.macports.org/ticket/33780. http://bugs.kde.org/show_bug.cgi?id=https://trac.macports.org/ticket/33780 Diffs - CMakeLists.txt c37ab8b kcontrol/CMakeLists.txt a25aaa0 libs/CMakeLists.txt 9d71a03 Diff: http://git.reviewboard.kde.org/r/112991/diff/ Testing --- I tested this patch under my macbook pro, using a fresh install of Macports (KDE 4.11.1 / Qt 4.8.5) As kde-workspace macports package is broken, i checkout code from KDE git/master repository and fixed compilation rules as well. Thanks, Gilles Caulier
Re: What to do with KScanDialog
Hi, libksane in kdegraphics/libs is the right alternative, very well maintained : https://projects.kde.org/projects/kde/kdegraphics/libs/libksane It work under Linux and OSX using libsane. Under Windows it use Twain interface. Best Gilles Caulier 2013/8/31 Àlex Fiestas afies...@kde.org: KScanDialog is currently being used by two apps: kolourpaint and kooka-git according to lxr. This makes me wonder if we should move it to a tier (forcing us to maintain it) or just move it to kde4support and deprecated it. In my opinion if none of the users of this class wants to maintain it we should move ahead and deprecated it. What do you think? Cheers.
Re: What to do with KScanDialog
I don't know exactly (i don't know KSCanDialog in fact, so i cannot compare). Ask to kare Sars who maintain this code. I can respond better than me... Gilles Caulier 2013/8/31 Àlex Fiestas afies...@kde.org: On Saturday 31 August 2013 19:42:02 Gilles Caulier wrote: Hi, libksane in kdegraphics/libs is the right alternative, very well maintained : https://projects.kde.org/projects/kde/kdegraphics/libs/libksane It work under Linux and OSX using libsane. Under Windows it use Twain interface. Best Awesome! Is there anything like KScanDialog on it? If not, do you think it could be interesting to add it? Cheers !
Re: Plans for SVN infrastructure shutdown
right Ben, I used wrong url... It work now... Gilles Caulier 2013/2/8 Ben Cooksley bcooks...@kde.org On Fri, Feb 8, 2013 at 10:30 PM, Gilles Caulier caulier.gil...@gmail.com wrote: It must be a right access failure i think Hi Gilles, I process private repository using my account name cgilles... but : [gilles@localhost Devel]$ git clone g...@git.kde.org:cgilles ./cgilles Cloning into './cgilles'... X11 forwarding request failed on channel 0 R access for cgilles DENIED to cgilles (Or there may be no repository at the given path. Did you spell it correctly?) fatal: The remote end hung up unexpectedly [gilles@localhost Devel]$ Your scratch namespace is located at scratch/cgilles/reponame. For me, I would use: git clone g...@git.kde.org:scratch/bcooksley/foobar Gilles Caulier Regards, Ben Cooksley KDE Sysadmin 2013/2/7 Ivan Čukić ivan.cu...@kde.org You should migrate those to repositories under your scratch namespace on git.kde.org. Hi Ben, My scratch namespace ? I'm not sure to understand... http://community.kde.org/Sysadmin/GitKdeOrgManual#Personal_scratch_repositories Cheerio, Ivan
Re: Plans for SVN infrastructure shutdown
Hi all, What's about user home dir hosted in SVN repository which must be moved somewhere is GIT. Typically, mine is here : http://websvn.kde.org/branches/work/~cgilles/ Best Gilles Caulier 2013/2/7 Marco Martin notm...@gmail.com On Wednesday 02 January 2013, Nicolás Alvarez wrote: The initial draft of the SVN shutdown plan is available on the community wiki: http://community.kde.org/Sysadmin/SVNInfrastructureShutdown As you can see this is a long-term plan. None of this is written in stone; any feedback is welcome! Is this still the active plan? in plasma we have some stuff into svn, kept here because git doesn't work that well, basically artwork: kde-artwork kde-wallpapers kde-artwork-active all of that can be moved, but will probably be among most problematic repositories that still have to be migrated.. suggestions for those? Cheers, Marco Martin
Re: Plans for SVN infrastructure shutdown
2013/2/7 Ben Cooksley bcooks...@kde.org On Fri, Feb 8, 2013 at 1:38 AM, Gilles Caulier caulier.gil...@gmail.com wrote: Hi all, Hi Gilles, What's about user home dir hosted in SVN repository which must be moved somewhere is GIT. Typically, mine is here : http://websvn.kde.org/branches/work/~cgilles/ You should migrate those to repositories under your scratch namespace on git.kde.org. Hi Ben, My scratch namespace ? I'm not sure to understand... Gilles
Re: Plans for SVN infrastructure shutdown
Thanks Gilles 2013/2/7 Ivan Čukić ivan.cu...@kde.org You should migrate those to repositories under your scratch namespace on git.kde.org. Hi Ben, My scratch namespace ? I'm not sure to understand... http://community.kde.org/Sysadmin/GitKdeOrgManual#Personal_scratch_repositories Cheerio, Ivan
Re: Color Managing KDE
If KDE include a color management based on Oyranos, what's about applications which have already a Color Management system, based on another library ? For ex, in digiKam we have used LCMS ver1 and we currently port to LCMS ver 2 (http://www.littlecms.com) We will need to break all LCMS based implementation in digiKam and port all again to another library as Oyranos ??? Which CM sub-system is used by Gnome Desktop ? They uses Oyranos too ? Gilles Caulier 2012/2/22 Christoph Feck christ...@maxiom.de: On Wednesday 22 February 2012 11:46:53 Richard Hughes wrote: GNOME has been a color managed desktop by default for two releases [...] Basically, I need a KDE dude. Our color management KDE dude is Kai-Uwe Behrmann from Oyranos team. See git/playground/graphics/kolor-manager for what is already available. Christoph Feck (kdepepo) KDE Quality Team
Re: moving libkface and libkmap from kdereview to extragear/libs.
2011/7/12 İsmail Dönmez ism...@namtrac.org Hi; 2011/7/12 Alexander Neundorf neund...@kde.org On Tuesday 12 July 2011, Gilles Caulier wrote: 2011/7/12 Alex Merry k...@randomguy3.me.uk On 12/07/11 08:06, Gilles Caulier wrote: It's fine for me to change libkmap to libkgeomap. What's about libkface, which is a KDE libface interface to perform facial detection on image and later (under development) facial recognition. I wouldn't mind libkfacerecognition. Makes it completely clear what it is. Please decide on names version numbers before we (distro packagers) ship it. Version numbers are fine. For name i resume by : - libkmap need to be changed to libkgeomap - libkface still libkface Fine for all ? If yes i will open first a file in B.K.O about moving libkface to extragear/libs In second stage libkmap need to be patched (+ digiKam and kipi-plugins) before to open a new file in B.K.O about. Gilles Caulier Thanks, ismail
Re: moving libkface and libkmap from kdereview to extragear/libs.
I take a look into Mailing list archives given as link in the previous post. It's fine for me to change libkmap to libkgeomap. What's about libkface, which is a KDE libface interface to perform facial detection on image and later (under development) facial recognition. http://libface.sourceforge.net/file/Home.html I would like to solve this problem quickly, because digiKam 2.0.0 will be released at end of July and the way to checkout these dependencies must be clean. Gilles Caulier 2011/7/11 Allen Winter win...@kde.org There is a libkimap in kdepimlibs. I could see people confusing libkmap with libkimap On Monday, July 11, 2011 01:57:20 pm Gilles Caulier wrote: Too generic. Ah. I don't know this information. Do you remember the thread about ? it's in mailing list or in IRC ? Gilles 2011/7/11 Albert Astals Cid aa...@kde.org A Monday, July 11, 2011, Gilles Caulier va escriure: Hi all, It's possible to move libkface : https://projects.kde.org/projects/kdereview/libkface and libkmap : https://projects.kde.org/projects/kdereview/libkmap from kdereview to extragear/libs (as it have been done for libmediawiki) ? https://projects.kde.org/projects/extragear/libs These libs have been reviewed for a long time now. There is no reason to lets this code into kdereview... Or i miss something ? I remember a bunch of people complaining the names are too generic. What was the decision? Albert Best Gilles Caulier
Re: moving libkface and libkmap from kdereview to extragear/libs.
2011/7/12 Alex Merry k...@randomguy3.me.uk On 12/07/11 08:06, Gilles Caulier wrote: It's fine for me to change libkmap to libkgeomap. What's about libkface, which is a KDE libface interface to perform facial detection on image and later (under development) facial recognition. http://libface.sourceforge.**net/file/Home.htmlhttp://libface.sourceforge.net/file/Home.html I would like to solve this problem quickly, because digiKam 2.0.0 will be released at end of July and the way to checkout these dependencies must be clean. libkface seems fine to me - unlike map, face doesn't really have a generic meaning in computing, and the fact it is based on libface makes libkface the obvious choice for the name. So, this one can be moved to extragear/libs as well... A Git/Redmine admin can do it please. Thanks in advance Gilles Caulier
moving libkface and libkmap from kdereview to extragear/libs.
Hi all, It's possible to move libkface : https://projects.kde.org/projects/kdereview/libkface and libkmap : https://projects.kde.org/projects/kdereview/libkmap from kdereview to extragear/libs (as it have been done for libmediawiki) ? https://projects.kde.org/projects/extragear/libs These libs have been reviewed for a long time now. There is no reason to lets this code into kdereview... Or i miss something ? Best Gilles Caulier
moving libkface and libkmap from kdereview to extragear/libs.
Hi all, It's possible to move libkface : https://projects.kde.org/projects/kdereview/libkface and libkmap : https://projects.kde.org/projects/kdereview/libkmap from kdereview to extragear/libs (as it have been done for libmediawiki) ? https://projects.kde.org/projects/extragear/libs These libs have been reviewed for a long time now. There is no reason to lets this code into kdereview... Or i miss something ? Best Gilles Caulier
Re: moving libkface and libkmap from kdereview to extragear/libs.
Too generic. Ah. I don't know this information. Do you remember the thread about ? it's in mailing list or in IRC ? Gilles 2011/7/11 Albert Astals Cid aa...@kde.org A Monday, July 11, 2011, Gilles Caulier va escriure: Hi all, It's possible to move libkface : https://projects.kde.org/projects/kdereview/libkface and libkmap : https://projects.kde.org/projects/kdereview/libkmap from kdereview to extragear/libs (as it have been done for libmediawiki) ? https://projects.kde.org/projects/extragear/libs These libs have been reviewed for a long time now. There is no reason to lets this code into kdereview... Or i miss something ? I remember a bunch of people complaining the names are too generic. What was the decision? Albert Best Gilles Caulier
Re: Projects in KDE Review for more than two weeks
Hi Ben, libkface, libkmap and libmediawiki need to be move into extragear/libs component. All are used by digiKam and kipi-plugins for the moment. we have already discuted about this move in the past (we cannot find a right way to move this libs in an official KDE component as kdegraphics. So extragear/libs is fine for the moment. next move can be done later in another place if necessary. Q: how do you perform a move from a KDE component as kdereview to extragear/libs WITHOUT to lost git commit history ? In the past, a simple svn mv been enough. With git it's impossible to do... Do you use git export/import feature ? If yes, it sound a complex task to do, to simply move code around global git KDE repository. Can you post here the command line to use, just to learn this stuff. Thanks in advance... Gilles Caulier 2011/5/12 Ben Cooksley bcooks...@kde.org: Hi all, The following projects have been in KDE Review for more than 2 weeks. For those projects which have passed review, please reply indicating the final module they need to be moved to. Those modules whose review failed, or whom do not reply need to be moved back to playground. The projects in review for more than two weeks: Control Flow Graph libkface libkmap libtagaro Nepomuk System Tray libmediawiki Those people in CC are the people marked as KDE Project Managers for one or more of the projects. Please respond. Regards, Ben Cooksley
Re: Introducing libmediawiki
Albert, If you look on my commit comment, it's explained. https://projects.kde.org/projects/extragear/graphics/digikam/digikam-software-compilation/repository/revisions/ce696373b95a2bb5d8ec4760c5061e17ef602266 In fact, it's temporally. I request a project creation into kdereview for libkmediawiki. So i wait it: https://bugs.kde.org/show_bug.cgi?id=269220 Best Gilles Caulier 2011/3/26 Albert Astals Cid aa...@kde.org: A Dissabte, 19 de març de 2011, Alexandre Mendes va escriure: Hello, We worked on a library, libmediawiki, to interface the MediaWiki API with Qt, which is a part of the project silk. Also we have produce two new widgets and a kipi plugin to export images to commons.wikimedia.org. They use our library . We think our work can interest some kde developpers and we want to know if you can introduce it in your release schedule. You can find our work at the same place as project-silk. https://projects.kde.org/projects/playground/base/silk/repository/revisions /master/show/mediawiki Any reason why that library got copied to kipi-plugins in extragear? What about kdereview? What about not duplicating code? Albert Best regards, The IUP ISI Team.
