Re: RKWard is in kdereview
Yes, I have already begun the process of taking this over in debian official. Cheers, Scarlett On Mon, Oct 15, 2018 at 2:24 AM Jonathan Riddell wrote: > On Fri, Oct 12, 2018 at 10:03:16PM +0200, Thomas Friedrichsmeier wrote: > > Ok, will do. It may take me a while, though, as I'll have to be careful > > not to break our automated builds on our Ubuntu PPAs (as pointed out by > > Meik). But ideally, I'd also like to combine this step with handing > > over our official debian packaging (i.e. the "debian-official" folder) > > to the debian qt/kde-team. > > > > Is there any hope for that, or what can I do to make that happen? > > Talk to some folks on the team, maybe start with Scarlett (CCed) who is > getting some good stuff into there. > > Jonathan >
Re: CI Requirements - Lessons Not Learnt?
I have no problem adding a rolling release image to the stack like arch. Perhaps have this build master and stable - > lts image ? Scarlett On Wed, Jan 11, 2017 at 8:11 AM, Martin Gräßlin wrote: > Am 2017-01-11 13:40, schrieb Jan Kundrát: > >> On středa 11. ledna 2017 6:57:50 CET, Martin Gräßlin wrote: >> >>> That doesn't work. Such inflexibility take away the advantage of having >>> a CI. >>> >> >> What base system(s) do you prefer to target as a developer, Martin? >> > > We release software which will be combined with a future set of software. > E.g. for KWin it has always been a problem that we develop against e.g. > Mesa X, but it will be combined by the distros with Mesa X+1, which hasn't > seen any testing from our side. > > This resulted in lots of issues. For me as the maintainer of a high profile > application for our users the main need is to combine with the dependencies > the next version of KWin will use in real world. > > This means: latest and greatest released software. Ideally fast rolling > release distributions. > > Now that is for KWin master, for KWin stable or KWin LTS, the base doesn't > matter that much. > > And I think KWin is there different to other software we have. We hardly > anywhere have the need for the latest and greatest. KWin needs it as it > gets > integrated with it by the distros anyway. > > An example is currently Xwayland. I would love to have a runtime > dependency to the > latest released version as it fixes various issues. It will also be what > will be used > by the next distributions, but we don't have it yet on our stable base. It > means I have > to carry workarounds around, it means we have to put into the release > announcement that > it should be combined with this version. > > As I mentioned in another mail to this thread: KWin is pushing the stack. > Whether we like it or not. And I must say it's frustrating. > > Cheers > Martin >
Re: CI Requirements - Lessons Not Learnt?
On Wed, Jan 11, 2017 at 4:40 AM, Jan Kundrát wrote: > On středa 11. ledna 2017 6:57:50 CET, Martin Gräßlin wrote: > >> That doesn't work. Such inflexibility take away the advantage of having a >> CI. >> > > What base system(s) do you prefer to target as a developer, Martin? > > A CI system can have different sets of base images for different projects > (and different branches, etc). Something along these lines: > > - KF5 might care a bit about slow-moving distributions such as RHEL7 > (well, except for a requirement on Qt 5.6) > > - Plasma LTS might want to target versions of faster-moving distros which > were around at a time of their release. Say, Fedora 24? Ubuntu 16.04 LTS? > > - The master branches of Plasma might want to get rid of the legacy > workarounds. Can we use the latest Fedora with aggressive backports of > rawhide packages upon request for this? > > - Various applications within KDE might have completely different > requiremens. Some "leaf" applications might want to target slow-moving > distributions with their ancient Qt. > > So this incomplete set of requirements probably translates to four base > images. I'm using a RPM-centric terminology and picking these distros > because of my professional background with these systems: > > 1) CentOS 7 with Qt 5.6 from EPEL and installed devtoolset > 2) Ubuntu 16.04 LTS with a distro Qt (that is 5.5) > 3) latest Fedora with Qt from git and an unspecified number of packages > from rawhide > 4) Debian Jessie with a system Qt 5.3 > > Each project in KDE can then choose whether they care about these > individual base images (subject to the availability of dependencies, of > course -- if KF5 don't care about Jessie and Qt 5.3, no project which uses > any KF5 can possibly opt in to support that configuration for obvious > reasons). By default, all projects get just 3) for the "latest and > greatest" and for minimal wasted manpower. > > With my (non-KDE) sysadmin hat on, I believe that the infrastructure > should be provided as a service offering for developers. It is the > developer's job to produce working code which is packageable. I don't think > it's a developer's job to make a CI's sysadmin life uneventful, though. > Perhaps the architecture outlined above can help achieve these goals with > minimal manpower? > This seems like a good idea to me. I have always thought we should have more than one distro image. I will even take the responsibility of maintaining them. Scarlett > > Cheers, > Jan > > -- > Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/ >
Re: CI Requirements - Lessons Not Learnt?
Hello all, First my apologies, yes the CI system is behind, I had done significant work on a new revamp and then life, work and those other incredibly annoying things got in the way. The CI team is rather small and we are trying our best to move things forward. We are now getting back on track, but it will still be some time to get this out the door. The PIM team has worked with me directly and we have had very good luck getting their requirements satisfied working together. If anyone needs something extra, like a dependency built from source, just ask. Despite my best efforts, mailing lists, I simply can't keep up. Ping me, directly CC me, telegram me, anything. I am always accommodating. Again, sorry this has all come to this point. Thank you, Scarlett On Thu, Jan 5, 2017 at 12:44 AM, Ben Cooksley wrote: > Hi all, > > It seems that my previous vocal complaints about system level / > serious impact dependency bumps on the CI system have gone completely > unnoticed by (some) members of our Community. > > This was demonstrated earlier this week when components of Plasma > bumped their version requirements for XKBCommon and Appstream-Qt - > without even a thought about notifying Sysadmin or checking which > version the CI had, until their builds broke. > > Neither of these is easy to fix at this stage, as the system base is > now too old to receive updates such as these. Base upgrades require a > full rebuild of everything on the CI system, and usually involve > significant additional churn and is a process that must be done > roughly twice a year, depending on dependency bump demands. > > Does anyone have any suggestions as to how we may avoid this in the future? > > At this point i'm in favour of if you don't follow the rules your > dependency bump just gets reverted out of existence, then you get to > go through the process properly... > > Regards, > Ben >
Re: Review Request 128102: Set encoding on kconfig_compiler generated cpp and headers to utf-8 ( reproducible )
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128102/ --- (Updated June 22, 2016, 3:50 p.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks, kdelibs, David Faure, and Sune Vuorela. Changes --- Submitted with commit d6655e34f05516b9e857e8b2e1a9238c33875924 by Scarlett Clark to branch KDE/4.14. Repository: kdelibs Description --- Set encoding on kconfig_compiler generated cpp and headers to utf-8 ( reproducible builds ) Under certain locals non standard characters will get dropped making builds un reproducible. Setting the encoding to utf-8 on the files makes all builds reproducible no matter what ( or none ) locale is in use. Thereby making the build reproducible. Diffs - kdecore/kconfig_compiler/kconfig_compiler.cpp 30f52ab1 Diff: https://git.reviewboard.kde.org/r/128102/diff/ Testing --- Built kdelibs then installed it, rebuilt chokoq with patched kdelibs and the build is now reproducible. There are likley other kde projects affected and will be fixed with this patch. Thanks for your consideration. Thanks, Scarlett Clark
Re: Review Request 128102: Set encoding on kconfig_compiler generated cpp and headers to utf-8 ( reproducible )
> On June 11, 2016, 6:20 p.m., Albert Astals Cid wrote: > > Have you tried if this is needed for the KDE Frameworks version of the > > kconfig_compiler? I will into that today, thank - Scarlett --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128102/#review96365 --- On June 11, 2016, 6:19 p.m., Scarlett Clark wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/128102/ > --- > > (Updated June 11, 2016, 6:19 p.m.) > > > Review request for KDE Frameworks, kdelibs, David Faure, and Sune Vuorela. > > > Repository: kdelibs > > > Description > --- > > Set encoding on kconfig_compiler generated cpp and headers to utf-8 ( > reproducible builds ) > > Under certain locals non standard characters will get dropped making builds > un reproducible. Setting the encoding to utf-8 > on the files makes all builds reproducible no matter what ( or none ) locale > is in use. Thereby making the build reproducible. > > > Diffs > - > > kdecore/kconfig_compiler/kconfig_compiler.cpp 30f52ab1 > > Diff: https://git.reviewboard.kde.org/r/128102/diff/ > > > Testing > --- > > Built kdelibs then installed it, rebuilt chokoq with patched kdelibs and the > build is now reproducible. There are likley other kde projects affected and > will be fixed with this patch. > Thanks for your consideration. > > > Thanks, > > Scarlett Clark > >
Review Request 128102: Set encoding on kconfig_compiler generated cpp and headers to utf-8 ( reproducible )
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/128102/ --- Review request for kdelibs and Sune Vuorela. Repository: kdelibs Description --- Set encoding on kconfig_compiler generated cpp and headers to utf-8 ( reproducible builds ) Under certain locals non standard characters will get dropped making builds un reproducible. Setting the encoding to utf-8 on the files makes all builds reproducible no matter what ( or none ) locale is in use. Thereby making the build reproducible. Diffs - kdecore/kconfig_compiler/kconfig_compiler.cpp 30f52ab1 Diff: https://git.reviewboard.kde.org/r/128102/diff/ Testing --- Built kdelibs then installed it, rebuilt chokoq with patched kdelibs and the build is now reproducible. There are likley other kde projects affected and will be fixed with this patch. Thanks for your consideration. Thanks, Scarlett Clark
Re: kconfig_compiler help ( reproducible builds )
I still need help with this, hacking the packaging was not accepted. Here is the exact problem: https://reproducible-builds.org/docs/locales/#collation-order Looking at kconfig_compiler code that only thing that is standing out is: https://github.com/KDE/kdelibs/blob/23f0972e03d9d5f30412b7c9c74cb4cadef7293a/kdecore/kconfig_compiler/kconfig_compiler.cpp#L481 Am I on the right track? If so can someone with more C++ knowledge help me with a solution? Thank you, Scarlett On Wed, May 25, 2016 at 4:10 PM, Scarlett Clark < scarlett.gately.cl...@gmail.com> wrote: > Taking Albert's suggestion, this has been resolved. > > [16:07] tsdgeos: hiyas yep, was just about to write haha. One > char was indeed dropped when no locale was set. export LC_ALL=C.UTF-8 > before build made it reproducible which is what I needed. Thanks for your > help :) > > > On Wed, May 25, 2016 at 11:10 AM, Albert Astals Cid wrote: > >> El dimecres, 25 de maig de 2016, a les 10:55:25 CEST, Scarlett Clark va >> escriure: >> > Some relevant links. >> >> My suggestion in IRC so others can see it >> * Compile the code in the two locales that give different outputs >> * diff the two builddir/plugins/nowlistening/nowlisteningsettings.cpp to >> see >> if this is indeed the problem. >> >> Cheers, >> Albert >> >> > >> > On Wed, May 25, 2016 at 9:11 AM, Scarlett Clark < >> > >> > scarlett.gately.cl...@gmail.com> wrote: >> > > Hi all, >> > > >> > > I am having issue with trying to make a build reproducible [1] >> > > And I have narrowed this one down to a locale issue with >> kconfig_compiler >> > > code generation >> > > has different results due to locale. >> > > >> > > >> > > you are right with your assumption that it is locale-related. >> > > The second build has an additional 0xe19085 at the beginning, >> > > which is a unicode character (triangle pointed to the right [1][2]): >> > > The first build is running in a non-utf8 locale, in which the >> > > kconfig_compiler seems to drop unicode characters. >> > > (The zeroes at the end of the diff is probably just some padding to >> fill >> > > it up to a certain length.) >> > > >> > > >> > > Can anyone give me a hint as to where to start looking to fix this? Is >> > > there a missing setting for kconfig_compiler? Please remember I am a >> > > coding >> > > NEWB. >> > > >> > > Thanks for any help you can provide. >> > > Scarlett >> > >> > Links for the quoted text. >> > >> > [1]: http://www.decodeunicode.org/en/u+1405 >> > [2]: >> > >> https://sources.debian.net/src/choqok/1.5-5/plugins/nowlistening/nowlistenin >> > gsettings.kcfg/#L11 >> >> >> >
Re: kconfig_compiler help ( reproducible builds )
Taking Albert's suggestion, this has been resolved. [16:07] tsdgeos: hiyas yep, was just about to write haha. One char was indeed dropped when no locale was set. export LC_ALL=C.UTF-8 before build made it reproducible which is what I needed. Thanks for your help :) On Wed, May 25, 2016 at 11:10 AM, Albert Astals Cid wrote: > El dimecres, 25 de maig de 2016, a les 10:55:25 CEST, Scarlett Clark va > escriure: > > Some relevant links. > > My suggestion in IRC so others can see it > * Compile the code in the two locales that give different outputs > * diff the two builddir/plugins/nowlistening/nowlisteningsettings.cpp to > see > if this is indeed the problem. > > Cheers, > Albert > > > > > On Wed, May 25, 2016 at 9:11 AM, Scarlett Clark < > > > > scarlett.gately.cl...@gmail.com> wrote: > > > Hi all, > > > > > > I am having issue with trying to make a build reproducible [1] > > > And I have narrowed this one down to a locale issue with > kconfig_compiler > > > code generation > > > has different results due to locale. > > > > > > > > > you are right with your assumption that it is locale-related. > > > The second build has an additional 0xe19085 at the beginning, > > > which is a unicode character (triangle pointed to the right [1][2]): > > > The first build is running in a non-utf8 locale, in which the > > > kconfig_compiler seems to drop unicode characters. > > > (The zeroes at the end of the diff is probably just some padding to > fill > > > it up to a certain length.) > > > > > > > > > Can anyone give me a hint as to where to start looking to fix this? Is > > > there a missing setting for kconfig_compiler? Please remember I am a > > > coding > > > NEWB. > > > > > > Thanks for any help you can provide. > > > Scarlett > > > > Links for the quoted text. > > > > [1]: http://www.decodeunicode.org/en/u+1405 > > [2]: > > > https://sources.debian.net/src/choqok/1.5-5/plugins/nowlistening/nowlistenin > > gsettings.kcfg/#L11 > > >
Re: kconfig_compiler help ( reproducible builds )
Some relevant links. On Wed, May 25, 2016 at 9:11 AM, Scarlett Clark < scarlett.gately.cl...@gmail.com> wrote: > Hi all, > > I am having issue with trying to make a build reproducible [1] > And I have narrowed this one down to a locale issue with kconfig_compiler > code generation > has different results due to locale. > > > you are right with your assumption that it is locale-related. > The second build has an additional 0xe19085 at the beginning, > which is a unicode character (triangle pointed to the right [1][2]): > The first build is running in a non-utf8 locale, in which the > kconfig_compiler seems to drop unicode characters. > (The zeroes at the end of the diff is probably just some padding to fill > it up to a certain length.) > > > Can anyone give me a hint as to where to start looking to fix this? Is > there a missing setting for kconfig_compiler? Please remember I am a coding > NEWB. > > Thanks for any help you can provide. > Scarlett > > > Links for the quoted text. [1]: http://www.decodeunicode.org/en/u+1405 [2]: https://sources.debian.net/src/choqok/1.5-5/plugins/nowlistening/nowlisteningsettings.kcfg/#L11
kconfig_compiler help ( reproducible builds )
Hi all, I am having issue with trying to make a build reproducible [1] And I have narrowed this one down to a locale issue with kconfig_compiler code generation has different results due to locale. you are right with your assumption that it is locale-related. The second build has an additional 0xe19085 at the beginning, which is a unicode character (triangle pointed to the right [1][2]): The first build is running in a non-utf8 locale, in which the kconfig_compiler seems to drop unicode characters. (The zeroes at the end of the diff is probably just some padding to fill it up to a certain length.) Can anyone give me a hint as to where to start looking to fix this? Is there a missing setting for kconfig_compiler? Please remember I am a coding NEWB. Thanks for any help you can provide. Scarlett [1] https://reproducible-builds.org/
Re: kdewebkit?
Ben, as init-repository is not something we control ( we are now using qt repos ) I need your input. Cheers, Scarlett I will be traveling today so may not be responsive. On Thu, Apr 21, 2016 at 9:15 AM, David Edmundson wrote: > QtWebkit isn't being developed, but it does still build and work. There's > even a qt5.6 tag in the qtwebkit repo. > > From the Qt5 output > https://build.kde.org/job/qt5%205.6%20kf5-qt5/PLATFORM=Linux,compiler=gcc/lastBuild/consoleText > it looks like we're not building qtwebkit. > > I guess it's no longer included in the default list. > > try changing the script that calls ./init-repository to include the > argument > --module-subest=default,qtwebkit > >
Fwd: kdewebkit?
Meant for list sorry. -- Forwarded message -- From: Scarlett Clark Date: Thu, Apr 21, 2016 at 8:57 AM Subject: Re: kdewebkit? To: Luigi Toscano On Thu, Apr 21, 2016 at 8:50 AM, Luigi Toscano wrote: > On Thursday 21 of April 2016 08:45:44 Scarlett Clark wrote: > > > https://build.kde.org/job/kdewebkit%20master%20kf5-qt5/PLATFORM=Linux,compil > > er=gcc/32/console > > > > And if I understand correctly, qt webkit is no more? So should this > project > > be removed from CI? > > > IIRC as long as we support Qt <5.6, we can't kill it. Moreover, not all > software has been ported, (and you can always compile it even with newer > Qt). > > We can? Can someone fix it then? Because as of now, Qt 5.6 as seen above, I beg to differ. Stable of course (5.5) does build. Scarlett > -- > Luigi >
kdewebkit?
https://build.kde.org/job/kdewebkit%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/32/console And if I understand correctly, qt webkit is no more? So should this project be removed from CI? Cheers, Scarlett
Re: [Kde-pim] Qt 4 Builds
Thank you all for your input. We have decided to remove all Qt4 builds that a) Have a kf5 version in Release. b) Not actively developed. This thread is ONLY about KDE CI builds. Nothing else. Thank you Scarlett On Sun, Mar 27, 2016 at 3:50 PM, Kevin Kofler wrote: > laurent Montel wrote: > > Oh?:) > > Fedora continue to support some programs which are not supported from > > several years before kdepim5 ? > > Fedora would not have to do that if you were not removing functionality as > large as entire applications (!) between releases. > > Also, KNode still works great, maybe BECAUSE it is "not supported from > several years" and so did not get infected with Akonadi. KNode still works > as well as in the pre-Akonadi days. KMail 2 has become literally 100 to > 1000 > times slower (!) and a lot more buggy than KMail 1, simply from getting > ported to Akonadi. > > > Interesting good luck :) > > > > Better solution to find others new programs which are maintaining no ? > > Point me to a maintained NNTP client using Qt, and at least I will happily > consider switching to it. (At least if it doesn't use Akonadi. ;-) ) > > This message was brought to you by KNode (through Gmane). > > Kevin Kofler > >
Re: [Kde-pim] Qt 4 Builds
On Sun, Mar 27, 2016 at 11:47 AM, Martin Klapetek wrote: > On Sun, Mar 27, 2016 at 1:14 PM, Scarlett Clark < > scarlett.gately.cl...@gmail.com> wrote: > >> >> libaccounts-qt ( ktp stack I believe affected here ) will not build qt4 >> >> https://build.kde.org/job/libaccounts-qt%20master%20latest-qt4/PLATFORM=Linux,compiler=gcc/2/console >> Reading the log upstream I see qt4 is not supported now. >> > > KTp is Qt5-only for quite some time now. There is nothing > needing libaccounts-qt4 afaik. > Killing CI qt4 builds then :) Thanks! Scarlett > > Cheers > -- > Martin Klapetek | KDE Developer >
Re: [Kde-pim] Qt 4 Builds
On Sun, Mar 27, 2016 at 10:20 AM, Kai Uwe Broulik wrote: > Hi, > > > gwenview depends on baloo as well > > isn't Gwenview already released as kf5? At least I've been running it for > years almost without a problem. > > Most of these are. We are talking about the qt4 builds in the CI. Projects have the choice to keep these alive by keeping a branch in logical-module-structure. This thread is about the projects that no longer build due to dependency issues like qt4 is no longer supported. I am more than happy to kill the qt4 builds :) Cheers, Scarlett > Cheers, > Kai Uwe > >
Re: [Kde-pim] Qt 4 Builds
Unrelated to PIM We have others affected by various qt4 unsupported upstream. gwenview depends on baloo as well libaccounts-qt ( ktp stack I believe affected here ) will not build qt4 https://build.kde.org/job/libaccounts-qt%20master%20latest-qt4/PLATFORM=Linux,compiler=gcc/2/console Reading the log upstream I see qt4 is not supported now. Probably more as I work through these FTBFS Scarlett On Sun, Mar 27, 2016 at 10:01 AM, Thiago Macieira wrote: > On domingo, 27 de março de 2016 15:31:47 PDT Martin Koller wrote: > > The latest openSuse (Leap 42.1) ships the Qt4 based kdepim, although it > uses > > plasma5 desktop. > > > > Speaking of it: given that openSuse decided against shipping KF5-based > PIM, > > how stable is KF5-based PIM considered these days ? > > Is it ready for productive daily professional use ? > > Tumbleweed has already switched to the KF5-based PIM and it's working > mostly > fine. There are some minor issues like requiring the shortcut to go to the > next > unread message in any folder to be pressed multiple times before it > decides to > do its job, but nothing major. > > -- > Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org >Software Architect - Intel Open Source Technology Center > >
build.kde.org What have you done to it!?!?! Serious explanation inside.
Ok, so we are migrating to docker builds tomorrow, (Ben's available time) Rather than continually mess with two set of builds I am only working on sandbox in preparation. The good news is many unstable builds have gone green, but will not be seen until we are live :) So I am hereby giving NOTICE of disruption in service for build.kde.org We hope for a swift and smooth transition. Thanks!! Scarlett
Re: [Kde-pim] PIM dependency metadata
sandbox is where I test new features. Namely we are pushing docker builds. There is a new icu so we have to rebuild everything. There are more issues. For stable-kf5-qt5 only some of the pim stack has Applications 15.12 in the metadata so of course only part of the stack can build due to missing dependencies. Please update logical-module-structure to have all or none of pim in the stable builds. Thanks, Scarlett On Sat, Feb 27, 2016 at 4:51 AM, Sandro Knauß wrote: > Hey, > > > There are a couple of issues, namely: > > a) For some reason it depends on plasma-workspace - this seems > > completely wrong to me. Please be careful when adding items to the > > dependency chain > > this was added because of ktimezoned, that is part of plasma-workspace to > run > tests in kcalccore successfully. For further discussion see: > https://phabricator.kde.org/T1147 > > > b) kblog is unbuildable, due to CalendarCore being absent. I've no > > idea where to find this. See > > > https://build-sandbox.kde.org/job/kblog%20master%20kf5-qt5/3/PLATFORM=Linux > , > > compiler=gcc/console > > kcalcore is the needed package. But the Build runs successfully, don't see > any > problems. > > Btw. what is the difference between > https://build-sandbox.kde.org and https://build.kde.org > > Regards, > > sandro > ___ > KDE PIM mailing list kde-...@kde.org > https://mail.kde.org/mailman/listinfo/kde-pim > KDE PIM home page at http://pim.kde.org/
Fwd: RFC: Enabling -DECM_ENABLE_SANITIZERS='address' in jenkins
Resent - meant for list. Help please folks, I need someone with more knowledge with gcc and compiler flags / settings. I *think* what needs to be done is blacklists or some such. I don't think this should be *my* responsibility to fix. If it is.. then docker builds is back burnered for the unforeseeable future. I simply do not have time right now to try and figure this out. I accidentally overloaded myself with commitments. And holidays are arriving soon to top things off. It may very well be simple to fix... Sorry, but I need help here. Scarlett -- Forwarded message -- From: Scarlett Clark Date: Tue, Dec 1, 2015 at 10:55 AM Subject: Re: RFC: Enabling -DECM_ENABLE_SANITIZERS='address' in jenkins To: Albert Astals Cid OK, I am going to have to disagree here. Proof in case: https://build-sandbox.kde.org/job/kdoctools%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/2/console libxml2 and libxslt are the problem which *is* external. I tried removing the ecm flag for kdoctools but we still have asan errors now. Someone needs to step up and help me out here as I do not have time to try and figure out how to fix this mess. It is a blocker for CI to move to docker (more builders yay!) which I think everyone would like to see happen. Thanks, Scarlett On Thu, Sep 10, 2015 at 2:34 PM, Albert Astals Cid wrote: > El Dijous, 10 de setembre de 2015, a les 18:20:19, Lamarque Souza va > escriure: > > I agree but there is a problem: it can catch a lot of errors in our > > dependency libraries (upstream bugs). > > No, it can not, asan works only on code you have compiled with asan enabled > (which for most of our dependencies we do not compile or they don't use > ECM). > > Cheers, > Albert > > > I had this problem when I used it > > with a program I develop at my work. Enabling it for all programs at once > > and fixing all those upstream bugs can be overwhelming. Maybe we should > do > > it for a limited number of programs first and add more programs as we fix > > the errors. > > > > Lamarque V. Souza > > > > http://planetkde.org/pt-br > > > > On Thu, Sep 10, 2015 at 5:36 PM, Albert Astals Cid > wrote: > > > We have this nice ECM module that gives us the option to compile with > > > ASAN. > > > > > > I'd like to propose that we enable it by default in jenkins. > > > > > > This way we get all the autotests run with ASAN and potentially catch > more > > > bugs/regressions. > > > > > > Comments? > > > > > > Cheers, > > > > > > Albert > >
Re: Help please. Kdoctools build.
Oops, this has been my playground up until now. I have fixed ( I hope ) that developers should be able to access jobs and public can view jobs. Keep in mind this is my space to develop new stuff for CI and is generally a mess ! :) Thanks! Scarlett On Fri, Nov 27, 2015 at 4:12 PM, Luigi Toscano wrote: > Scarlett Clark ha scritto: > > I need some help please. I am working through a new rebuild on my > sandbox CI > > system and I was quickly halted due to kdoctools.I am not even sure > where to > > start with this. > > > > > https://build-sandbox.kde.org/job/kdoctools%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/2/console > > What is the login to access the logs? (I tried my identity login but I > don't > have the proper rights) > On the other side, could the jobs be made public? > > Ciao > -- > Luigi >
Help please. Kdoctools build.
I need some help please. I am working through a new rebuild on my sandbox CI system and I was quickly halted due to kdoctools.I am not even sure where to start with this. https://build-sandbox.kde.org/job/kdoctools%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/2/console Piles of memory leaks. I guess this is the new ASAN flag? Am I to guess libxml2 is somehow involved here? I can tell you ICU was updated so that is why I have to rebuild everything, is that somehow involved? I am integrating docker into our build system, though that should be irrelevant. Thanks to anyone that can shed some light on this for me. Scarlett
Re: SIC/BIC in Frameworks (NOT)
I guess I forgot to turn back on clean workspace? We were debugging qt5.5. I Am so sorry, been traveling home. Scarlett On Sep 14, 2015 12:59 PM, "Ben Cooksley" wrote: > On Mon, Sep 14, 2015 at 12:28 AM, David Faure wrote: > > This is clearly a CI issue, not a SIC/BIC, as both our investigations > prove. > > And now fixed. > > > > > On Sunday 13 September 2015 23:43:19 Ben Cooksley wrote: > >> This then causes KNotification to fail to build (as it depends on > >> netwm.h) which then leads to the rest of the failures we see. This > >> itself is probably a bug? > > > > If KWindowSystem is built with X11 forced OFF > > (via CMAKE_DISABLE_FIND_PACKAGE_X11) > > and KNotifications is built with X11 enabled > > (CMAKE_DISABLE_FIND_PACKAGE_X11 not being set), > > you end up with a compilation error. > > I think that's quite obvious, and I wouldn't consider that a bug. > > > > We only support X11 on everywhere or off everywhere. > > Combinations of "some frameworks with X11 enabled and some with > > X11 purposefully disabled" don't make sense to me. > > Indeed, but couldn't they raise an error if one is built without X11 > support but the others are trying to build with X11 support? > > > > > -- > > David Faure, fa...@kde.org, http://www.davidfaure.fr > > Working on KDE Frameworks 5 > > > > Cheers, > Ben >
Re: building kio on Mac
On Tuesday, May 26, 2015 12:06:22 PM Allen Winter wrote:
> % kdesrc-build kio
> Could not locate file "kf5/kdoctools/customization" in
> ("/Users/allenwinter/Library/Application Support", "/Library/Application
> Support") Could not locate file "kf5/kdoctools/customization" in
> ("/Users/allenwinter/Library/Application Support", "/Library/Application
> Support") Error: Could not find kdoctools catalogs
>
> kdesrc-build kdoctools succeeded though.
> I recall this was a QStandardPaths thing. but I forgot the trick to solving.
>
> help.
-DCMAKE_INSTALL_BUNDLEDIR="{instPrefix}/Applications/KF5" -
DDATA_INSTALL_DIR="{instPrefix}/Library/Application Support"
need to be in your cmake command.
Scarlett
signature.asc
Description: This is a digitally signed message part.
Something has gone horribly wrong.. Linux builds carnage.
I woke up this morning to a sea of red. Almost all of the linux builds are failing. It looks like QT5 was triggered by an scm change, but hard to tell as it was also started and aborted by kaning. The error: 15:16:38 /srv/jenkins/install/ubuntu/x86_64/g++/kf5- qt5/qt5/inst/include/QtCore/qglobal.h:1051:4: error: #error "You must build your code with position independent code if Qt was built with - reduce-relocations. " "Compile your code with -fPIC (-fPIE is not enough)." 15:16:38 # error "You must build your code with position independent code if Qt was built with -reduce-relocations. "\ 15:16:38 ^ Is present in most of the failures. Please help. I should know better than to sleep.. Scarlett signature.asc Description: This is a digitally signed message part.
IRC and Email notifications
Please help me help you, I do not have lists containing who needs / wants what and where.. I tried my best to make some educated guesses. I do not take rejection well and so I ask anyone that wishes to have your CI builds in email or IRC please tell me the rpoject and places you want them to go. If I already set you up and you wish for my bots to go away, speak now or forever hold your peace. I am available in many places, whatever is convenient for you.. 1) Reply to this email 2) Send email to sgcl...@kubuntu.org 3) ping sgclark on many irc channels including #kde-sysadmin 4) create a ticket on https://sysadmin.kde.org/tickets/ Thank you for your help, Scarlett PS: I promise to document all this so this will not happen again. signature.asc Description: This is a digitally signed message part.
Re: branchGroup stable-qt4 Compile failures. Need dev assistance please.
On Friday, May 01, 2015 12:56:26 AM Friedrich W. H. Kossebau wrote: > Hi Scarlett, > > Am Mittwoch, 29. April 2015, 23:26:14 schrieb Friedrich W. H. Kossebau: > > Am Dienstag, 21. April 2015, 13:45:06 schrieb Scarlett Clark: > > > I know this is an external depend, but I have no experience with it. > > > Can maybe a calligra dev take a look, as they need it. > > > VC > > > https://build-sandbox.kde.org/job/vc%20master%20stable-qt4/PLATFORM=Linu > > > x, > > > co mpiler=gcc/2/console > > > > Please build only the 0.7.4 release of vc, tagged with "0.7.4". So not > > "master" or anything else. That would be for any builds of vc, in any > > group > > (vc does not use qt anyway). AFAIK only Calligra uses vc right now, and in > > all branches Calligra needs vc 0.7(.4). > > See you changed that meanwhile, looks good WRT vc (and also the Calligra > master build), thanks :) > > But then there is still the following bummer: > > > With that said: > > > Calligra: (probably vc) > > > https://build-sandbox.kde.org/view/branchGroup%20stable-qt4/job/calligra > > > %2 > > > 0c alligra-2.9%20stable-qt4/10/ > > > > Yes, given so far no vc build completed, this seems to fail when trying to > > get a built version of vc. Should work better once there is one :) > > > > Though there seems also another problem: commits to the "calligra/2.9" > > branch are not triggering any builds of the qt4 stable build: > > https://build.kde.org/view/branchGroup%20stable-qt4/job/calligra%20calligr > > a-> 2.9%20stable-qt4/ > > > > That was not a problem in the old CI, but so far noone can tell what is > > wrong now. Commits to the "frameworks" and "master" branches seem to > > properly trigger builds of the respective build setups. Perhaps you might > > have an idea? > > Anything where we could help with to solve this? The calligra/2.9 branch is > actually the hot branch these weeks still, main work is done there > (especially the awesome Krita one), so not having CI as a reference up and > working for this branch is a loss at the moment :) (see, CI is important to > us :) so we appreciate your work even more) > > Cheers > Friedrich 18:08:53 Started by an SCM change I am happy to report this fixed itself by a manual trigger. Must have had corruption the old workspace. I will do the same for the other qt4 branch. Scarlett signature.asc Description: This is a digitally signed message part.
Re: branchGroup stable-qt4 Compile failures. Need dev assistance please.
On Friday, May 01, 2015 12:56:26 AM Friedrich W. H. Kossebau wrote: > Hi Scarlett, > > Am Mittwoch, 29. April 2015, 23:26:14 schrieb Friedrich W. H. Kossebau: > > Am Dienstag, 21. April 2015, 13:45:06 schrieb Scarlett Clark: > > > I know this is an external depend, but I have no experience with it. > > > Can maybe a calligra dev take a look, as they need it. > > > VC > > > https://build-sandbox.kde.org/job/vc%20master%20stable-qt4/PLATFORM=Linu > > > x, > > > co mpiler=gcc/2/console > > > > Please build only the 0.7.4 release of vc, tagged with "0.7.4". So not > > "master" or anything else. That would be for any builds of vc, in any > > group > > (vc does not use qt anyway). AFAIK only Calligra uses vc right now, and in > > all branches Calligra needs vc 0.7(.4). > > See you changed that meanwhile, looks good WRT vc (and also the Calligra > master build), thanks :) > > But then there is still the following bummer: > > > With that said: > > > Calligra: (probably vc) > > > https://build-sandbox.kde.org/view/branchGroup%20stable-qt4/job/calligra > > > %2 > > > 0c alligra-2.9%20stable-qt4/10/ > > > > Yes, given so far no vc build completed, this seems to fail when trying to > > get a built version of vc. Should work better once there is one :) > > > > Though there seems also another problem: commits to the "calligra/2.9" > > branch are not triggering any builds of the qt4 stable build: > > https://build.kde.org/view/branchGroup%20stable-qt4/job/calligra%20calligr > > a-> 2.9%20stable-qt4/ > > > > That was not a problem in the old CI, but so far noone can tell what is > > wrong now. Commits to the "frameworks" and "master" branches seem to > > properly trigger builds of the respective build setups. Perhaps you might > > have an idea? > > Anything where we could help with to solve this? The calligra/2.9 branch is > actually the hot branch these weeks still, main work is done there > (especially the awesome Krita one), so not having CI as a reference up and > working for this branch is a loss at the moment :) (see, CI is important to > us :) so we appreciate your work even more) > > Cheers > Friedrich Ahh, I see I think maybe git hooks are missing? Ben can you look into this or point me the way? Thanks! Scarlett signature.asc Description: This is a digitally signed message part.
kf5-qt5 compile failures, need developer assistance
These are from the kf5-qt5 branchGroup (usually master or frameworks branches) I realize many these are still under heavy development for porting. This is just a note to inform. Fixes welcome though. kcalcore: https://build-sandbox.kde.org/job/kcalcore%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/9/console libechonest: qjson does not exist in qt5 world, code must adapt to use qt5 json support https://build-sandbox.kde.org/job/libechonest%20qt5%20kf5-qt5/PLATFORM=Linux,compiler=gcc/9/console kget: It looks like it is looking for qt4 varients of qca and qgpgmepp Should be qca_qt5 and gpgmepp (no longer bundled in kdepimlibs) https://build-sandbox.kde.org/job/kget%20kf5_port%20kf5-qt5/PLATFORM=Linux,compiler=gcc/15/console choqok can't find qoauth in lib64 https://build-sandbox.kde.org/job/choqok%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/11/console marble: (this also breaks libkgeomap and digikam) https://build-sandbox.kde.org/job/marble%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/1/console kdev-go https://build-sandbox.kde.org/job/kdev-go%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/2/console kdev-python https://build-sandbox.kde.org/job/kdev-python%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/10/console tellico: https://build-sandbox.kde.org/job/tellico%20frameworks%20kf5-qt5/PLATFORM=Linux,compiler=gcc/13/console calligra: https://build-sandbox.kde.org/job/calligra%20frameworks%20kf5-qt5/lastFailedBuild/console kile: https://build-sandbox.kde.org/job/kile%20frameworks%20kf5-qt5/PLATFORM=Linux,compiler=gcc/17/ smokeqt: https://build-sandbox.kde.org/job/smokeqt%20Qt5%20kf5-qt5/PLATFORM=Linux,compiler=gcc/9/console libringclient: https://build-sandbox.kde.org/job/libringclient%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/10/console phonon-gstreamer: https://build-sandbox.kde.org/job/phonon-gstreamer%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/7/console plasma-nm: https://build-sandbox.kde.org/job/plasma-nm%20master%20kf5-qt5/PLATFORM=Linux,compiler=gcc/12/console wacomtablet: https://build-sandbox.kde.org/job/wacomtablet%20kf5-port%20kf5-qt5/PLATFORM=Linux,compiler=gcc/13/console signature.asc Description: This is a digitally signed message part.
latest-QT4 compile failures
Of course my previous email those that failed in stable failed here too. A big thank you to those that got fixed. latest compile failures: apper: https://build-sandbox.kde.org/job/apper%20master%20latest-qt4/PLATFORM=Linux,compiler=gcc/24/console choqok: This is likely because qoauth installs into lib64 and I cannot convince it otherwise. (this also affects kf5 builds too) https://build-sandbox.kde.org/job/choqok%201.0%20latest-qt4/PLATFORM=Linux,compiler=gcc/2/console dolphin-plugins: https://build-sandbox.kde.org/job/dolphin-plugins%20master%20latest-qt4/PLATFORM=Linux,compiler=gcc/17/console kdepim: can't find the grantlee bright in. https://build-sandbox.kde.org/job/kdepim%20KDE-4.14%20latest-qt4/PLATFORM=Linux,compiler=gcc/15/console Thanks, Scarlett signature.asc Description: This is a digitally signed message part.
Re: branchGroup stable-qt4 Compile failures. Need dev assistance please.
On 04/21/2015 03:08 PM, Albert Astals Cid wrote: El Dimarts, 21 d'abril de 2015, a les 23:42:36, Milian Wolff va escriure: On Tuesday 21 April 2015 13:45:06 Scarlett Clark wrote: kdev-crossfire: https://build-sandbox.kde.org/job/kdev-crossfire%20master%20stable-qt4/PLA TF ORM=Linux,compiler=gcc/11/ kdev-php-formatter: https://build-sandbox.kde.org/job/kdev-php-formatter%20master%20stable-qt4 /P LATFORM=Linux,compiler=gcc/10/console kdev-xtest: https://build-sandbox.kde.org/view/branchGroup%20stable-qt4/job/kdev-xtest %2 0master%20stable-qt4/PLATFORM=Linux,compiler=gcc/11/console All of the above are unmaintained and should not run through CI until someone spends time on fixing their issues. They are all in playground as well. kdev-css: https://build-sandbox.kde.org/job/kdev-css%201.7%20stable-qt4/PLATFORM=Lin ux ,compiler=gcc/5/console This one was easy and I fixed it. But in general, I don't think that adding all playground projects to the CI is a good idea, as many things in there are just historic artifacts. What we need is someone with some time to apply the life cycle policy and move those historic artifacts to unmaintained :) Cheers, Albert I have removed them from my job list, they probably should go through the above process pointed out by Albert. Scarlett Bye
Re: branchGroup stable-qt4 Compile failures. Need dev assistance please.
On 04/21/2015 02:42 PM, Milian Wolff wrote: On Tuesday 21 April 2015 13:45:06 Scarlett Clark wrote: kdev-crossfire: https://build-sandbox.kde.org/job/kdev-crossfire%20master%20stable-qt4/PLATF ORM=Linux,compiler=gcc/11/ kdev-php-formatter: https://build-sandbox.kde.org/job/kdev-php-formatter%20master%20stable-qt4/P LATFORM=Linux,compiler=gcc/10/console kdev-xtest: https://build-sandbox.kde.org/view/branchGroup%20stable-qt4/job/kdev-xtest%2 0master%20stable-qt4/PLATFORM=Linux,compiler=gcc/11/console All of the above are unmaintained and should not run through CI until someone spends time on fixing their issues. They are all in playground as well. kdev-css: https://build-sandbox.kde.org/job/kdev-css%201.7%20stable-qt4/PLATFORM=Linux ,compiler=gcc/5/console This one was easy and I fixed it. But in general, I don't think that adding all playground projects to the CI is a good idea, as many things in there are just historic artifacts. Bye Hi, thanks for fixing that. I do not make the call on what goes in the CI. Everything kde-build-metadata/logical-module-structure will land in CI. Thanks, Scarlett
branchGroup stable-qt4 Compile failures. Need dev assistance please.
I know this is an external depend, but I have no experience with it. Can maybe a calligra dev take a look, as they need it. VC https://build-sandbox.kde.org/job/vc%20master%20stable-qt4/PLATFORM=Linux,compiler=gcc/2/console With that said: Calligra: (probably vc) https://build-sandbox.kde.org/view/branchGroup%20stable-qt4/job/calligra%20calligra-2.9%20stable-qt4/10/ k3b: Found Kcddb: but fails on include file: https://build-sandbox.kde.org/job/k3b%202.0%20stable-qt4/PLATFORM=Linux,compiler=gcc/14/console kamoso: https://build-sandbox.kde.org/job/kamoso%202.1%20stable-qt4/PLATFORM=Linux,compiler=gcc/12/console kdeconnect-kde: fails to find qjson header. I brought it in as a dep but I don't think it actually looks for it because it still fails (and not listed in the configure section). https://build-sandbox.kde.org/job/kdeconnect-kde%20kde4%20stable-qt4/PLATFORM=Linux,compiler=gcc/13/console kdenlive: Please tell me the correct qt4 branches. The ones in LMS were kf5 builds. kaccount-integration: https://build-sandbox.kde.org/job/kaccounts-integration%20stable%20stable-qt4/PLATFORM=Linux,compiler=gcc/19/console kdepim: can't find the supplied grantlee https://build-sandbox.kde.org/job/kdepim%20KDE-4.14%20stable-qt4/PLATFORM=Linux,compiler=gcc/12/console kdev-crossfire: https://build-sandbox.kde.org/job/kdev-crossfire%20master%20stable-qt4/PLATFORM=Linux,compiler=gcc/11/ kdev-css: https://build-sandbox.kde.org/job/kdev-css%201.7%20stable-qt4/PLATFORM=Linux,compiler=gcc/5/console kdev-php-formatter: https://build-sandbox.kde.org/job/kdev-php-formatter%20master%20stable-qt4/PLATFORM=Linux,compiler=gcc/10/console kdev-xtest: https://build-sandbox.kde.org/view/branchGroup%20stable-qt4/job/kdev-xtest%20master%20stable-qt4/PLATFORM=Linux,compiler=gcc/11/console kstars: https://build-sandbox.kde.org/job/kstars%20Applications-14.12%20stable-qt4/PLATFORM=Linux,compiler=gcc/11/console Thanks, Scarlett signature.asc Description: This is a digitally signed message part.
Re: KF5-QT5 branchgroup - jobs that need developeer attention
On Friday, April 17, 2015 12:47:05 AM Gregor Mi wrote: > >> skanlite - all - wants a framework KF5Sane (does this exist?) > > > > > > > > > > > > Gregor Mi ported both libksane and Skanlite to KF5 last year. They are > > both in the frameworks branch. libksane is not yet a framework, but I > > think he prepared libksane for it.> > > > > > > > > > > For me Skanlite compiles fine with kdesrc-build... > > As I tried a few weeks ago, it compiled for me, too. Did not do a recent > build though. > > > > > > > > > > I have plans to split libksane into a non-gui and a gui library and it > > could be good to wait a bit with trying to get it into frameworks for BIC > > reasons. > > > > > > > > > > > > That said I think it would be nice to have a KF5 based release of both > > libksane and skanlite ASAP. skanlite is fine as far as developers go. There is a missing dep on Marko's OSX builder, as soon as he resolves that, the red should turn green. Thanks ! Scarlett signature.asc Description: This is a digitally signed message part.
Re: KF5-QT5 branchgroup - jobs that need developeer attention
On 04/15/2015 02:58 AM, Martin Klapetek wrote: On Wed, Apr 15, 2015 at 9:44 AM, Scarlett Clark <mailto:sgcl...@kubuntu.org>> wrote: Here is a list of mostly compile failures and other tid bits that need to be resolved by the respective developers. If you know the developer of a project and they are not on this list please forward this. All jobs can be viewed at : https://build-sandbox.kde.org/ Most of these are osx failures. If osx is not to be supported, I need to know that too. Questions - concerns - just ask. Thanks, Scarlett ktp-common-internals -Linux compile failure breaks: ktp* It's trying to build branch frameworks, which should not happen, everything for ktp* is in master. Where does it get the branch info from? Cheers -- Martin Klapetek | KDE Developer kde-build-metadata/logical-module-structure Scarlett
KF5-QT5 branchgroup - jobs that need developeer attention
Here is a list of mostly compile failures and other tid bits that need to be resolved by the respective developers. If you know the developer of a project and they are not on this list please forward this. All jobs can be viewed at : https://build-sandbox.kde.org/ Most of these are osx failures. If osx is not to be supported, I need to know that too. Questions - concerns - just ask. Thanks, Scarlett apper - kf5 does not appear to be complete. Nothing to deploy. qt-gstreamer/libaccount-qt - osx - can't find gstreamer and glib2 and pkgconfig breaks: analitza, artikulate,kaccounts-integration, ktp*, kalgebra, step - needs eigen3 3.2.2 (has to be backported to utopic) choqok - qoauth installs to lib64 and choqok can't find them. libkface - opencv2/core/internal.hpp: No such file or directory breaks digikam calligra - All - compile fail. kcachegrind - osx - compile failure qca broken osx - breaks: kdeconnect-kde,ksirk kdenlive osx - compile failure kdepimlibs - osx - compile failure breaks: kalarmcal, kdepim, kmailtransport kdeplasma-addons - osx - compile failure kdevplatform - osx - compile failure - breaks kdevelop*, plasma-sdk kgamma - osx - missing Qt5X11ExtrasConfig.cmake not sure this would be available in osx? kget - all - wants qca and kf5gpgmepp - pulled in as deps and not found. khotkeys,powerdevil - osx - baloo not supported? remove dep on milou? kio-mtp - osx - package 'libmtp' not found kmenuedit - osx - needs libkscreen - disabled by Marko - reason? kmix - osx - compile failure knights - all - compile failure - depends on kspeech needs changed to qtspeech for kf5. konversation - osx - compile failure kstars - osx - missing Eigen3 ktp-common-internals -Linux compile failure breaks: ktp* libechonest - all - qjson depend and qt5 has its own internal json now marble - all - fails at configure - can't get it to find phonon - (qextserialport - need help(this is an external depend and it installs into strange places) but all these claim to be optional so it should at least build without features - but will not proceed to build. Breaks: libkgeomap libksysguard - osx - compile failure libringclient - all - compile failure partitionmanager - osx - need help satisfying the depends (Marko?) purpose: CMake Error at src/plugins/CMakeLists.txt:17 (add_subdirectory): add_subdirectory given source "kdeconnect" which is not an existing directory. I tried to add kdeconnect as depend and that did not seem to help, not sure what it wants here. breaks: kamoso pyqt5 - linux - needs sip 4.16.4 (needs backport to utopic) sddm-kcm - osx - Qt5X11ExtrasConfig.cmake (not sure sddm would even be useful on osx) skanlite - all - wants a framework KF5Sane (does this exist?) tellico - compile failure wacomtablet - configure incomplete - xinput does not exist on debian/ubuntu
Jenkins CI help for compile failures!
KF5 knights fails to compile with: 23:47:49 make[2]: *** No rule to make target '/srv/jenkins/install/ubuntu/x86_64/g++/kf5- qt5/frameworks/kdelibs4support/inst/share/dbus-1/interfaces/org.kde.KSpeech.xml', needed by 'src/kspeechinterface.cpp'. Stop. 23:47:49 make[2]: *** Waiting for unfinished jobs 23:47:49 [ 26%] [ 28%] [ 30%] [ 32%] Generating ui_popup.h 23:47:49 Generating ui_enginesettings.h 23:47:49 Generating ui_customdifficultydialog.h 23:47:49 Generating settings.h, settings.cpp 23:47:49 CMakeFiles/Makefile2:107: recipe for target 'src/CMakeFiles/knights.dir/all' failed 23:47:49 make[1]: *** [src/CMakeFiles/knights.dir/all] Error 2 23:47:49 Makefile:126: recipe for target 'all' failed 23:47:49 make: *** [all] Error 2 Thoughts? ideas? Thanks for your help, Scarlett
Jenkins CI build help please
Next up is wacomtablet: *17:18:49* -- Could NOT find XCB_XINPUT (missing: XCB_XINPUT_LIBRARY XCB_XINPUT_INCLUDE_DIR) *17:18:49* CMake Error at /usr/share/cmake-3.2/Modules/FindPackageHandleStandardArgs.cmake:138 (message): *17:18:49* Could NOT find XCB (missing: XINPUT) (found version "1.10") *17:18:49* Call Stack (most recent call first): *17:18:49* /usr/share/cmake-3.2/Modules/FindPackageHandleStandardArgs.cmake:374 (_FPHSA_FAILURE_MESSAGE) *17:18:49* /srv/jenkins/install/ubuntu/x86_64/g++/kf5-qt5/kdesupport/extra-cmake-modules/inst/share/ECM/find-modules/FindXCB.cmake:173 (find_package_handle_standard_args) *17:18:49* CMakeLists.txt:17 (find_package) *17:18:49* *17:18:49* *17:18:49* -- Configuring incomplete, errors occurred! *17:18:49* See also "/home/jenkins/builds/wacomtablet/build/CMakeFiles/CMakeOutput.log". I have installed everything from the kubuntu packaging control file here: Build-Depends: debhelper (>= 7.3.16), cmake, kdelibs5-dev, pkg-kde-tools (>= 0.6.2), libxi-dev, libxrandr-dev, xserver-xorg-input-wacom, xvfb, xauth, dbus-x11 Well minus all the packaging and libs that are part of our build system. But you get the gist. And it still does not compile. Note: this is kde4 - we kubuntu/debian has not ported this kf5 version yet (unless they did it while I was not looking and hid it somewhere outside of our repos) Here is a list of all the failed tries: libxcb-composite0-dev libxcb-damage0-dev libxcb-dpms0-dev libraw-dev libxcb-image0- dev libxcb-xkb-dev libxkbfile-dev Anyone have a clue what I need to install on *ubuntu system to achieve this depend? CC'd my fellow packagers @ kubuntu-devel as well, they are much smarter than I am. thanks, Scarlett
Re: Help please with some builds in the new jenkins-ci for KDE Cont.. again
On 04/09/2015 04:08 AM, Aleix Pol wrote: On Thu, Apr 9, 2015 at 7:06 AM, Ben Cooksley wrote: On Thu, Apr 9, 2015 at 11:06 AM, Aleix Pol wrote: On Wed, Apr 8, 2015 at 10:53 PM, Scarlett Clark wrote: Hello all, I am to the point now with my ci that I just need help with some of these builds. While I am learning fast, some of these failures are stumpers. kde-runtime kf5 configures and pulls in all depends fine. But the build never happens... 20:34:24 == Commencing the Build 20:34:24 20:34:24 20:34:24 == Installing the Build 20:34:24 20:34:24 make: *** No rule to make target 'install'. Stop. It shouldn't be built anymore. I just pushed a commit so it's clear what happened. Please ensure kde-build-metadata is updated to reflect that kde-runtime does not have a kf5-qt5 / stable-kf5-qt5 entry anymore. That's the case, no project is pointing to kde-runtime. Aleix Fixed in logical-module-structure branches now. Thanks!
Help please with some builds in the new jenkins-ci for KDE Cont.. again
Hello all, I am to the point now with my ci that I just need help with some of these builds. While I am learning fast, some of these failures are stumpers. kde-runtime kf5 configures and pulls in all depends fine. But the build never happens... 20:34:24 == Commencing the Build 20:34:24 20:34:24 20:34:24 == Installing the Build 20:34:24 20:34:24 make: *** No rule to make target 'install'. Stop. libkface - I finally got opencv + opencv-contrib modules to build, which got rid of some missing opencv module errors, but now a pile of: 0:49:46 In file included from /home/jenkins/builds/libkface/src/recognition- opencv-lbph/lbphfacemodel.h:35:0, 20:49:46 from /home/jenkins/builds/libkface/src/recognition- opencv-lbph/lbphfacemodel.cpp:30: 20:49:46 /home/jenkins/builds/libkface/build/src/libopencv.h:55:37: fatal error: opencv2/core/internal.hpp: No such file or directory 20:49:46 #include 20:49:46 ^ 20:49:46 compilation terminated. 20:49:46 In file included from /home/jenkins/builds/libkface/src/detection/opencvfacedetector.h:40:0, 20:49:46 from /home/jenkins/builds/libkface/src/detection/opencvfacedetector.cpp:41: 20:49:46 /home/jenkins/builds/libkface/build/src/libopencv.h:55:37: fatal error: opencv2/core/internal.hpp: No such file or directory 20:49:46 #include 20:49:46 ^ 20:49:46 compilation terminated. This goes on for several. Looking at opencv the file does not exist at all. We have to use master to achieve a qt5 build... so I am at a loss here. This another one I have been fighting with too long... More coming as I work all this out.. Thanks so much for any help that you all can provide me. Scarlett
Help please with some builds in the new jenkins-ci for KDE Round 4
Hello all, I am to the point now with my ci that I just need help with some of these builds. While I am learning fast, some of these failures are stumpers. Ok, I fixed packagekit via ppa. So apper builds now, but I am not sure what is going on with the install: Install the project... 21:16:57 -- Install configuration: "Debug" 21:16:57 -- Installing: /home/jenkins/builds/apper/local- inst/apper/libapper.so 21:16:57 -- Removed runtime path from "/home/jenkins/builds/apper/local- inst/apper/libapper.so" 21:16:57 21:16:57 == Deploying Installation 21:16:57 21:16:57 sending incremental file list 21:16:57 rsync: change_dir "/home/jenkins/builds/apper/local- inst/srv/jenkins/install/ubuntu/x86_64/g++/kf5- qt5/extragear/sysadmin/apper/inst" failed: No such file or directory (2) 21:16:58 Is that correct only one file? and then removing it ? Help.. please. More coming as I work all this out.. Thanks so much for any help that you all can provide me. Scarlett
Help please with some builds in the new jenkins-ci for KDE Cont..
Hello all,
I am to the point now with my ci that I just need help with some of
these builds. While I am learning fast,
some of these failures are stumpers.
I have been fighting with kaccounts-integration much to long. I did finally
get it to find all its dependencies, including akonadi kf5, however...
compile failure:
19:56:27 In file included from /home/jenkins/builds/kaccounts-
integration/tests/testakonadiaccounts.cpp:19:0:
19:56:27 /home/jenkins/builds/kaccounts-
integration/tests/../src/daemon/akonadi/akonadiaccounts.h:25:33: fatal error:
AkonadiCore/Attribute: No such file or directory
19:56:27 #include
19:56:27 ^
19:56:27 compilation terminated.
I tried:
configureExtraArgs=-I{instPrefix}/include/KF5
and
configureExtraArgs=-I{instPrefix}/include/KF5/AkonadiCore
failures on both, even if it did work, defining all the includes seems clunky,
surely there is a magic answer here.
Please be patient with me as most of this is a huge learning experience for
me..
More coming as I work all this out..
Thanks so much for any help that you all can provide me.
Scarlett
Help please with some builds in the new jenkins-ci for KDE
Hello all, I am to the point now with my ci that I just need help with some of these builds. While I am learning fast, some of these failures are stumpers. qoauth - google leads me to believe that qt5 uses qca and not and that I should pass CONFIG += crypto to qmake. alas that did not work and it still wants QtCrypto. Has anyone built this for qt5? Can you tell me what flags I need to pass? Editing files in our system is not an option. dragon - I added kdbusaddons to the deps list but it fails mid compile at #include and I notice KF5DBusAddons is not on the find_packages list so I need to know... am I on the right track that adding it there will make everything happy and can I do that?, or someone related to the project? packagekit-qt - wants a much newer version than what is available in ubuntu 14.10 (or even 15.04) (compile error on a function not available in the version we have). Thoughts? ppa maybe? More coming as I work all this out.. Thanks so much for any help that you all can provide me. Scarlett
Re: Sysadmin report on the modernization of our infrastructure
When the test system is in place I would like to start my Jenkins integration. So let me know! Thanks Scarlett
Re: Problems with infrastructure
Hello all.. I have tried to stay way from this thread, but I have reached my breaking point. I have been literally killing myself working on my SoK project which entails upgrading our Jenkins CI system and getting all the projects working on Linux/Windows/OSX and I have moved to a docker based setup which will allow further growth and expansion, plus portability. Jenkins is compatible and works with Gerrit, so I don't understand why another CI is being considered. Reviewboard is on my to-do list as well as I have stated on several occasions. Anyway, I feel quite discarded in this thread. Back to not working on anything for long hours, everyday. Scarlett
Re: Review Request 119363: Port kde-baseapps to use docbook 4.5
> On Aug. 23, 2014, 9:26 a.m., Scarlett Clark wrote: > > I had to use this patch to get the frameworks branch to build while > > packaging for Kubuntu. Anyway we can get this pushed to at least frameworks > > branch? > > Marko Käning wrote: > I suggested the commit to frameworks to Luigi back then, but he had some > arguments against it at the time. > Let's see what he thinks now, as I don't want to override him there. > > Luigi Toscano wrote: > I don't find the discussion but I think I wrote something on the line of: > let's see if it can be made working without this, because, if kdelibs4support > is installed, this should work. Scarlett, can you please confirm that it does > not compile even if kdelibs4support is installed in the buildroot? Could you > please paste the error? > > Luigi Toscano wrote: > To be clear: I'm not against pushing this, you can commit it if no other > solutions works and it's the expected step anyway for a complete porting > (without kdelibs4support). My point is that the backward compatibility should > work; if not, I spent quite some time working on nothing. > > Scarlett Clark wrote: > http://goo.gl/mLRi02 I pasted my build depends and my failed build. > > Luigi Toscano wrote: > Sotty, I totally missed this comment! I think you miss kdelibs4support in > the build dependencies; with that package installed, compilation should work. > > Scarlett Clark wrote: > I already spoke to you today, but I just confirmed > libkf5kdelibs4support-dev (>= 5.1.0) is in the build depends. > > Luigi Toscano wrote: > Argh! Thanks for rechecking; I will try to solve this during Akademy. This is resolved as far as I am concerned, it was a packaging issue with kdelibs4support. Thanks Luigi! - Scarlett --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119363/#review65099 --- On Aug. 24, 2014, 9:33 a.m., Marko Käning wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/119363/ > --- > > (Updated Aug. 24, 2014, 9:33 a.m.) > > > Review request for KDE Base Apps, Luigi Toscano and Nicolás Alvarez. > > > Repository: kde-baseapps > > > Description > --- > > This suggests to upgrade the docbook DTD from 4.2 to 4.5. > > --- > > There is still an open issue here: > > Spaces in DATA_INSTALL_DIR need to be handled properly, so that the path in > the DTD file > > /Library/Application\ Support/kf5/kdoctools/customization/dtd/kdex.dtd > > is correctly set, i.e. using "%20" instead of a space. > > > Diffs > - > > doc/konqueror/index.docbook a1f8565404be0289b51af37df1687e0911a01fe5 > dolphin/docs/index.docbook 5fe85f5d130e3723af556fb02b53970206d1c765 > kdepasswd/docs/index.docbook 2ecef470ac8a9384b7aeb16f123f834d040ee375 > kfind/docs/index.docbook d46dfa4138991a356eec32a7043a883150eb81c2 > kfind/docs/man-kfind.1.docbook ef2eb3b9fb1ed1a84ae33fa631b0295a029444e0 > > Diff: https://git.reviewboard.kde.org/r/119363/diff/ > > > Testing > --- > > Builds/installs fine (if one doesn't use any white-space in DATA_INSTALL_DIR > path) > > > Thanks, > > Marko Käning > >
Re: Review Request 119363: Port kde-baseapps to use docbook 4.5
> On Aug. 23, 2014, 9:26 a.m., Scarlett Clark wrote: > > I had to use this patch to get the frameworks branch to build while > > packaging for Kubuntu. Anyway we can get this pushed to at least frameworks > > branch? > > Marko Käning wrote: > I suggested the commit to frameworks to Luigi back then, but he had some > arguments against it at the time. > Let's see what he thinks now, as I don't want to override him there. > > Luigi Toscano wrote: > I don't find the discussion but I think I wrote something on the line of: > let's see if it can be made working without this, because, if kdelibs4support > is installed, this should work. Scarlett, can you please confirm that it does > not compile even if kdelibs4support is installed in the buildroot? Could you > please paste the error? > > Luigi Toscano wrote: > To be clear: I'm not against pushing this, you can commit it if no other > solutions works and it's the expected step anyway for a complete porting > (without kdelibs4support). My point is that the backward compatibility should > work; if not, I spent quite some time working on nothing. > > Scarlett Clark wrote: > http://goo.gl/mLRi02 I pasted my build depends and my failed build. > > Luigi Toscano wrote: > Sotty, I totally missed this comment! I think you miss kdelibs4support in > the build dependencies; with that package installed, compilation should work. I already spoke to you today, but I just confirmed libkf5kdelibs4support-dev (>= 5.1.0) is in the build depends. - Scarlett --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119363/#review65099 --- On Aug. 24, 2014, 9:33 a.m., Marko Käning wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/119363/ > --- > > (Updated Aug. 24, 2014, 9:33 a.m.) > > > Review request for KDE Base Apps, Luigi Toscano and Nicolás Alvarez. > > > Repository: kde-baseapps > > > Description > --- > > This suggests to upgrade the docbook DTD from 4.2 to 4.5. > > --- > > There is still an open issue here: > > Spaces in DATA_INSTALL_DIR need to be handled properly, so that the path in > the DTD file > > /Library/Application\ Support/kf5/kdoctools/customization/dtd/kdex.dtd > > is correctly set, i.e. using "%20" instead of a space. > > > Diffs > - > > doc/konqueror/index.docbook a1f8565404be0289b51af37df1687e0911a01fe5 > dolphin/docs/index.docbook 5fe85f5d130e3723af556fb02b53970206d1c765 > kdepasswd/docs/index.docbook 2ecef470ac8a9384b7aeb16f123f834d040ee375 > kfind/docs/index.docbook d46dfa4138991a356eec32a7043a883150eb81c2 > kfind/docs/man-kfind.1.docbook ef2eb3b9fb1ed1a84ae33fa631b0295a029444e0 > > Diff: https://git.reviewboard.kde.org/r/119363/diff/ > > > Testing > --- > > Builds/installs fine (if one doesn't use any white-space in DATA_INSTALL_DIR > path) > > > Thanks, > > Marko Käning > >
Re: Review Request 119363: Port kde-baseapps to use docbook 4.5
> On Aug. 23, 2014, 9:26 a.m., Scarlett Clark wrote: > > I had to use this patch to get the frameworks branch to build while > > packaging for Kubuntu. Anyway we can get this pushed to at least frameworks > > branch? > > Marko Käning wrote: > I suggested the commit to frameworks to Luigi back then, but he had some > arguments against it at the time. > Let's see what he thinks now, as I don't want to override him there. > > Luigi Toscano wrote: > I don't find the discussion but I think I wrote something on the line of: > let's see if it can be made working without this, because, if kdelibs4support > is installed, this should work. Scarlett, can you please confirm that it does > not compile even if kdelibs4support is installed in the buildroot? Could you > please paste the error? > > Luigi Toscano wrote: > To be clear: I'm not against pushing this, you can commit it if no other > solutions works and it's the expected step anyway for a complete porting > (without kdelibs4support). My point is that the backward compatibility should > work; if not, I spent quite some time working on nothing. http://goo.gl/mLRi02 I pasted my build depends and my failed build. - Scarlett --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119363/#review65099 --- On Aug. 24, 2014, 9:33 a.m., Marko Käning wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/119363/ > --- > > (Updated Aug. 24, 2014, 9:33 a.m.) > > > Review request for KDE Base Apps, Luigi Toscano and Nicolás Alvarez. > > > Repository: kde-baseapps > > > Description > --- > > This suggests to upgrade the docbook DTD from 4.2 to 4.5. > > --- > > There is still an open issue here: > > Spaces in DATA_INSTALL_DIR need to be handled properly, so that the path in > the DTD file > > /Library/Application\ Support/kf5/kdoctools/customization/dtd/kdex.dtd > > is correctly set, i.e. using "%20" instead of a space. > > > Diffs > - > > doc/konqueror/index.docbook a1f8565404be0289b51af37df1687e0911a01fe5 > dolphin/docs/index.docbook 5fe85f5d130e3723af556fb02b53970206d1c765 > kdepasswd/docs/index.docbook 2ecef470ac8a9384b7aeb16f123f834d040ee375 > kfind/docs/index.docbook d46dfa4138991a356eec32a7043a883150eb81c2 > kfind/docs/man-kfind.1.docbook ef2eb3b9fb1ed1a84ae33fa631b0295a029444e0 > > Diff: https://git.reviewboard.kde.org/r/119363/diff/ > > > Testing > --- > > Builds/installs fine (if one doesn't use any white-space in DATA_INSTALL_DIR > path) > > > Thanks, > > Marko Käning > >
Re: Review Request 119363: Port kde-baseapps to use docbook 4.5
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/119363/#review65099 --- I had to use this patch to get the frameworks branch to build while packaging for Kubuntu. Anyway we can get this pushed to at least frameworks branch? - Scarlett Clark On July 19, 2014, 3:08 p.m., Marko Käning wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/119363/ > --- > > (Updated July 19, 2014, 3:08 p.m.) > > > Review request for KDE Base Apps, Luigi Toscano and Nicolás Alvarez. > > > Repository: kde-baseapps > > > Description > --- > > This suggests to upgrade the docbook DTD from 4.2 to 4.5. > > > Diffs > - > > doc/konqueror/index.docbook a1f8565404be0289b51af37df1687e0911a01fe5 > dolphin/docs/index.docbook 5fe85f5d130e3723af556fb02b53970206d1c765 > kdepasswd/docs/index.docbook 2ecef470ac8a9384b7aeb16f123f834d040ee375 > kfind/docs/index.docbook d46dfa4138991a356eec32a7043a883150eb81c2 > kfind/docs/man-kfind.1.docbook ef2eb3b9fb1ed1a84ae33fa631b0295a029444e0 > > Diff: https://git.reviewboard.kde.org/r/119363/diff/ > > > Testing > --- > > Builds/installs fine (if one doesn't use any white-space in DATA_INSTALL_DIR > path) > > > Thanks, > > Marko Käning > >
Re: Review Request 118851: Kde-baseapps- KF5 replace generic soversion.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118851/ --- (Updated June 20, 2014, 1:14 p.m.) Status -- This change has been marked as submitted. Review request for Dolphin, KDE Base Apps, Plasma, and Jonathan Riddell. Repository: kde-baseapps Description --- I was ending up with so.SOVERSION when building this, so through some research I have come up with this patch to correct the issue. If there is a better way, please let me know. Diffs - CMakeLists.txt a5588ea dolphin/src/CMakeLists.txt ce629fb lib/konq/CMakeLists.txt 6857e19 Diff: https://git.reviewboard.kde.org/r/118851/diff/ Testing --- Builds fine on Kubuntu Utopic frameworks chroot. Results in the expected: libdolphinprivate.so libdolphinprivate.so.4.97.0 libdolphinprivate.so.5 libkdeinit5_dolphin.so libkonq.so libkonq.so.4.97.0 libkonq.so.5 Thanks, Scarlett Clark
Re: Review Request 118851: Kde-baseapps- KF5 replace generic soversion.
> On June 20, 2014, 12:02 p.m., Alex Merry wrote: > > CMakeLists.txt, line 23 > > <https://git.reviewboard.kde.org/r/118851/diff/2/?file=282692#file282692line23> > > > > But now you'll want to put an actual version number in here (or remove > > the variable use altogether). I removed it all together, builds fine without it. thanks! - Scarlett --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118851/#review60618 --- On June 20, 2014, 11:44 a.m., Scarlett Clark wrote: > > --- > This is an automatically generated e-mail. To reply, visit: > https://git.reviewboard.kde.org/r/118851/ > --- > > (Updated June 20, 2014, 11:44 a.m.) > > > Review request for Dolphin, KDE Base Apps, Plasma, and Jonathan Riddell. > > > Repository: kde-baseapps > > > Description > --- > > I was ending up with so.SOVERSION when building this, so through some > research I have come up with this patch to correct the issue. > If there is a better way, please let me know. > > > Diffs > - > > CMakeLists.txt a5588ea > dolphin/src/CMakeLists.txt ce629fb > lib/konq/CMakeLists.txt 6857e19 > > Diff: https://git.reviewboard.kde.org/r/118851/diff/ > > > Testing > --- > > Builds fine on Kubuntu Utopic frameworks chroot. Results in the expected: > libdolphinprivate.so > libdolphinprivate.so.4.97.0 > libdolphinprivate.so.5 > libkdeinit5_dolphin.so > libkonq.so > libkonq.so.4.97.0 > libkonq.so.5 > > > Thanks, > > Scarlett Clark > >
Re: Review Request 118851: Kde-baseapps- KF5 replace generic soversion.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118851/ --- (Updated June 20, 2014, 11:44 a.m.) Review request for Dolphin, KDE Base Apps, Plasma, and Jonathan Riddell. Changes --- Implemented suggested changes, still builds with expected results. Repository: kde-baseapps Description --- I was ending up with so.SOVERSION when building this, so through some research I have come up with this patch to correct the issue. If there is a better way, please let me know. Diffs (updated) - CMakeLists.txt a5588ea dolphin/src/CMakeLists.txt ce629fb lib/konq/CMakeLists.txt 6857e19 Diff: https://git.reviewboard.kde.org/r/118851/diff/ Testing --- Builds fine on Kubuntu Utopic frameworks chroot. Results in the expected: libdolphinprivate.so libdolphinprivate.so.4.97.0 libdolphinprivate.so.5 libkdeinit5_dolphin.so libkonq.so libkonq.so.4.97.0 libkonq.so.5 Thanks, Scarlett Clark
Review Request 118851: Kde-baseapps- KF5 replace generic soversion.
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/118851/ --- Review request for Dolphin, KDE Base Apps, Plasma, and Jonathan Riddell. Repository: kde-baseapps Description --- I was ending up with so.SOVERSION when building this, so through some research I have come up with this patch to correct the issue. If there is a better way, please let me know. Diffs - CMakeLists.txt a5588ea dolphin/src/CMakeLists.txt ce629fb lib/konq/CMakeLists.txt 6857e19 Diff: https://git.reviewboard.kde.org/r/118851/diff/ Testing --- Builds fine on Kubuntu Utopic frameworks chroot. Results in the expected: libdolphinprivate.so libdolphinprivate.so.4.97.0 libdolphinprivate.so.5 libkdeinit5_dolphin.so libkonq.so libkonq.so.4.97.0 libkonq.so.5 Thanks, Scarlett Clark
