[00:35] apachelogger: that on the doodle is just one meeting? [02:26] congratulations ovidiu-florin! [03:06] right! [03:06] ovidiu-florin: congratulations! Hope everything went awesome! [03:33] shadeslayer: what Riddell says, also you are welcome to add ppa:mitya57/test2, upgrade and test. [03:34] (Please disable the ppa after upgrade, I like uploading broken packages there) [03:37] More fun if he doesn't disable it and wonders later why his computer is broken. [04:15] How can I do the equivalent of if [-e filename ]; then .... endif in GNU make? It seems I need ifeq and some thing, but what equals true? === Toadnohyp is now known as Hypnotoad [06:38] Good morning. [06:39] good morning lordievader [06:39] Hey soee, how are you? [06:40] lordievader: tbh fantastic :) you ? [06:40] Doing good. May I ask what made your day fantastic? [06:49] lordievader: new office :) [06:50] :) === soee_ is now known as soee === who_da_fly is now known as superfly [09:43] hi ho [09:52] hi shadeslayer [09:53] hello world [09:53] valorie jose thank you [09:56] hey soee [10:01] "Myriam Schweingruber (myriam) renewed their own membership in the Kubuntu Members (kubuntu-members) team" yay Mamarok still loves us! [10:03] eh, what, how does opengl work on arm64 but not on armhf? [10:03] -- Found OpenGL: /usr/lib/aarch64-linux-gnu/libGL.so [10:04] if you install it it'll work anywhere to compile, may run slow as treacle when you use it though [10:06] 'Morning folks [10:24] Riddell: of course I do, how did you ever doubt that :) [10:25] I am a trusty user since your first packages on Ubuntu :) [10:25] and promote Kubuntu whenever I can [10:25] * Riddell beams with pride [10:26] W: libkf5codecs-data: unknown-locale-code x-test hah [10:26] agateau: I wonder if the release scripts should be adjusted to remove that ↑ [10:27] Riddell: would make sense, ping dfaure about this [10:28] * agateau is off for lunch === who_da_fly is now known as superfly [10:29] oh oh oh [10:30] tsdgeos: please poke ScottK to accept kde-workspace 4.11.9 in trusty [10:30] tsdgeos: I've already solved your issue a day or two ago :P [10:31] shadeslayer: :) [10:36] uff, turns out my upload was rejected [10:36] Why? [10:36] Wasn't me. [10:37] no not you .. something else [10:37] twas batman [10:37] ^^ [10:38] some days you just can't get rid of a bomb [10:41] ScottK: btw any thoughts on https://launchpadlibrarian.net/174680022/buildlog_ubuntu-utopic-armhf.kubrick_4%3A4.13.0-0ubuntu2_FAILEDTOBUILD.txt.gz [10:41] i.e. what would be a fix for it apart from disabling kubrick for armhf [10:41] Port it not to use GL directly. [10:43] ScottK: so GL is supported on arm64 but not on hf? [10:43] shadeslayer: BTW, unless you're going to port it, make the architecture list !armhf and then your "exotic" archs are taken care of. [10:43] Yes [10:43] interesting [10:43] ScottK: yeah, that's what I was thinking [10:43] Supported in Debian on armhf too. That's an Ubuntu change. [10:44] :/ [10:45] ScottK: dpkg-source: error: `!armhf' is not a legal architecture string [10:45] so I guess I'll have to manually list every one :( [10:45] Hmm. I thought you could do that now. [10:45] I guess not. [10:46] hm? [10:46] shadeslayer: please post control [10:47] http://paste.ubuntu.com/7403832/ [10:49] ah, that architecture field [10:49] I don't think you can do it there [10:49] also [10:49] if you did that, then the package would not generate any binaries [10:49] ScottK: I also had a question about eglibc , the eglibc homepage says eglibc isn't maintained anymore [10:49] so why is ubuntu/debian still using it as default? [10:49] I know. [10:50] I assume infinity and the other GLIBC maintainers will sort it out. [10:51] shadeslayer: https://www.debian.org/doc/debian-policy/ch-customized-programs.html#s-arch-wildcard-spec [10:53] so, I dunno [10:54] personally I don't get why it would be any less than any though [10:54] oh [10:54] actually [10:55] shadeslayer: you may want to exclude armhf from the build depends [10:55] libglu1-mesa-dev [!armhf], libqt4-opengl-dev [!armhf] [10:55] apachelogger: but then kubrick won't build at all? [10:55] that would also then make sense in my mind ^^ [10:55] and hence won't migrate [10:56] -- This installation will have the extra features provided by these packages. [10:56] sounds optional to me [10:57] shadeslayer: In any case, I don't see -workspace in queue for trusty. [10:57] ScottK: should be up [10:57] just uploaded it [10:57] shadeslayer: It'll only block migration if it built before. [10:57] there it is [11:01] apachelogger: ok, lets try your approach [11:04] apachelogger: http://paste.ubuntu.com/7403915/ [11:05] this is on amd64 though [11:06] shadeslayer: ah yes, will need manual promotion then [11:07] also tell upstream to learn to use cmake :P [11:07] ye consider everything non-essential and let feature_summary fail depending on what you tell feature_summary to be essential [11:09] apachelogger: http://paste.ubuntu.com/7403947/ [11:09] that would work right? [11:13] yes [11:13] shadeslayer: dat changelog is shit tho [11:13] :O [11:13] if I look at the diff I see that clearly the intention is that it does not dep on kubrick on armhf [11:13] I do not know why [11:13] and the changelog does not tell me why [11:13] so, the changelog tells me something I can see anyway when looking at the diff :'< [11:14] fixed and pushed [11:39] ::workspace-bugs:: [1312806] Please update kde-workspace to 4.11.9 @ https://bugs.launchpad.net/bugs/1312806 (by Kubuntu IRC Bot) [11:44] shadeslayer: bug 1316563 did I break the "yo, you got no drivers" message we had? [11:44] bug 1316563 in kubuntu-driver-manager (Ubuntu) "Kubuntu driver manager shows nothing, even after refreshing driver list" [Undecided,New] https://launchpad.net/bugs/1316563 [11:45] indeed, m_label never gets shown [11:47] guis desperately need unit testing [11:49] hi sgclark [11:50] Riddell: morning === debfx_ is now known as debfx [12:00] Riddell: ok so I am doing ldd on all the shared libs in those two and so far all of them have them both [12:01] gosh [12:01] so may be unfixable [12:02] sgclark: which are the two packages again? [12:02] yeah both sides, all of declarative and two in gui [12:02] libqt4-declarative libqt4gui [12:05] /usr/lib/x86_64-linux-gnu/qt4/plugins/accessible/libqtaccessiblewidgets.so seems to be the problem one [12:05] in libqtgui4 but needs both declarative and gui [12:06] sgclark: so options are a) to ignore it or b) to split out libqtaccessiblewidgets.so into a separate package and have libqt4gui recommend it [12:06] b) seems quite do-able but dunno if it's worth it [12:08] * ScottK wonders what mitya57 thinks. [12:10] Will do whatever you tell me to. [12:10] sgclark: give it a try [12:11] will do [12:21] Riddell: also libqt4-declarative: symbols-declares-dependency-on-other-package libqtdeclarative [12:26] * Riddell looks [12:27] sgclark: pastebin output of: head debian/libqt4-declarative.symbols [12:30] Riddell: http://paste.ubuntu.com/7404280/ [12:33] sgclark: second line should be http://paste.ubuntu.com/7404280/ [12:33] sgclark: second line should be "libQtDeclarative.so.4 libqtdeclarative #MINVER#" [12:33] hmm no [12:34] surely you mean libqtdeclarative4? [12:34] sgclark: second line should be "libQtDeclarative.so.4 libqt4-declarative #MINVER#" [12:34] that works too ^^ [12:34] sgclark: I guess that change came from debian, check the changelog if there's a reason for it but if not go with "libQtDeclarative.so.4 libqt4-declarative #MINVER#" [12:35] ok thank you [12:56] Riddell: FYI I'm tracking merges on https://notes.kde.org/p/kubuntu-ninjas [13:00] shadeslayer: cool [13:36] Riddell: ScottK should I drop the extra packages from http://paste.kde.org/p9e8ujozp [13:37] extra = everything not libplasma-dev [13:38] yofel: neon5 orchestration has been reorganized and now lives at lp:~neon/project-neon5/orchestration/ ... and all bits should be there to replicate the setup we run on a bluesystems server [13:38] albeit, I am being lazy and haven't actually documented much, so you better hope I don't get hit by a bus :P [13:38] sweet [13:41] shadeslayer: drop because we're after LTS? [13:41] yep [13:42] shadeslayer: yes, unless the replace/breaks is also in debian [13:42] right, ofcourse [13:45] we last merged kdelibs in 2009 :S [13:46] that doesn't seem right, didn't we pick up a whole pile of splitting? [13:46] that certainly was after 2009 [13:46] yes I'm sure I merged it last year when in that sunny place north of barcelona [13:50] Any ideas why libqt5webkit5 is 5.1 when there rest of Qt 5.2 ? [13:51] ah yeah, I see another one in 2013 now [13:51] Ask mitya57 or mirv. [13:51] ScottK: Okay, I wanted to package otter for now but I can't :S [13:51] Quintasan: I think there were regressions in 5.2 [13:51] Quintasn: or just merge from Debian and don't sweat it. [13:52] Utopic chain is up? [13:52] Has been for a while. [13:53] Quintasan: they found some regressions in 5.2 so kept it at 5.1+a load of backports [13:54] ScottK: Looks like it, I already have a toolchain on my desktop [13:54] * Quintasan is so forgetful [13:54] Riddell: Thanks. [13:55] Riddell time to move forward though. [13:55] hope so [14:06] btw any recommendations for this conflict : debian symbols file for libkio is older , but has more symbols as compared to ours which is newer [14:06] should I just copy over the one from debian and adjust ours during the first build? [14:06] * apachelogger scratches head and wonders how that even happens [14:06] shadeslayer: maybe just redo the symbols file ^^ [14:07] shadeslayer: start from debian I guess [14:07] it's peculiar that ours would have fewer symbols tho [14:07] unless there's arch specific ones [14:08] yeah, my plan was, copy over debian one, adjust as required during build [14:08] apachelogger: I see armhf symbols [14:08] which are not in our symbols file [14:08] well [14:09] it's a crap situation [14:09] shadeslayer: the best results would be to continue using ours and perhaps find out why we are missing symbols [14:09] actually, wait, maybe .. yeah , reading it the wrong way [14:09] nvm me [14:09] the thing is... since symbols have their introducing version noted you'd loose metadata unless you continue using our symbols file [14:10] but yeah, it'd be nice to know what to do in such a situation [14:11] is there a way to fix this backtrace? https://errors.ubuntu.com/problem/96becd9a35ea3f1b2a5841dd058629ecf20c5673 ? an user had it again yesterday and it is failing to produce an userful bt [14:12] Elv1313: no backtrace, can't do anything [14:13] shadeslayer: I know, I am asking if there is something I can do to "fix" my code so a backtrace will be produced correctly. I don't like seeing crash report and doing nothing ;) [14:14] Elv1313: not really, you could ask the user to acquire core dumps [14:14] then debug on your machine [14:14] is it possible to contact them? [14:15] via e.u.c ? nope [14:16] !info sflphone [14:16] Package sflphone does not exist in saucy [14:16] saucy :O [14:16] saucy he said [14:16] * shadeslayer hates merging kdelibs [14:16] !info sflphone-kde [14:16] Package sflphone-kde does not exist in saucy [14:17] Elv1313: you could ask ev in #ubuntu-devel if there's any more information on why the retracing failed, because it appears to me that the debug symbols should have been there [14:17] https://launchpad.net/ubuntu/+source/sflphone [14:17] otherwise, if you wait long enough it might just be that a retrace eventually yields a trace ^^ [14:18] ok, thanks [14:35] ScottK: I have another kde-workspace upload for you btw [14:35] in about 30 minutez [14:43] shadeslayer: man you so street with your z's ;) [14:43] xD [14:43] genuine typo btw :P [14:43] debfx: ping [14:43] debfx: +override_dh_makeshlibs: [14:43] + $(overridden_command) -- -c0 [14:43] shadeslayer: :D [14:43] debfx: any ideas why ou did that? [14:44] Quintasan, ScottK: http://irclogs.ubuntu.com/2014/05/03/%23ubuntu-devel.html#t09:32 [14:45] In short: it is already in Bzr, and Timo wants to synchronize it with Touch stuff [14:45] debfx: ideally, don't we want that in pkg-kde-tools to make sure if that there's no tolerance towards new symbols? [14:45] oh [14:45] debfx: level 0 never fails :O [14:45] why is kdelibs level 0? [14:46] so we can fix the whole package post-build, instead of it failing on symbols, then later you have to fix new files etc. in another pass [14:47] although we don't do that for all packages, nor am I sure whether it's that useful these days as LP does the building [14:47] shadeslayer: I added that? :O [14:48] debfx: bzr log -p shows that rev 342 added that [14:48] http://websvn.kde.org/trunk/?rev=342&view=rev | svn://anonsvn.kde.org/home/kde/trunk -r 342 [14:48] ah ubottu, u so silly [14:48] yofel: thoughts on dropping it? [14:51] well, depends. It's useful as it doesn't block the rest of the SC on a kdelibs ABI break (possibly private/gcc), but on the other hand if it's gone you don't have to rebuild stuff if you bump the ABI later as everything is waiting [14:51] I would rather not have it personally [14:52] shadeslayer: likely came from Debian since that commit is a merge [14:52] mm [14:53] debfx: yeah, you're right [14:53] it already was that way before: -DEB_DH_MAKESHLIBS_ARGS_ALL := -V -u-c0 [14:54] but I agree -c0 shouldn't be used for kde4libs [14:54] * shadeslayer removes it since debian removed it [14:59] ScottK: kde-workspace for your approval [15:03] Riddell: (/me reads backscroll) So is there anything wrong with the current libqt4-declarative.symbols? [15:04] mitya57: nope, just in what sgclark ended up with [15:04] Are you using lp:~k-packagers/k-packaging/qt or something else? [15:05] mitya57: I don't know if she started with that or with the trusty package [15:06] sgclark: ^ [15:07] Riddell: In my branch that symbols file was correct from the beginning, and there is no loop between gui and declarative. [15:08] (where "my branch" = lp:~kubuntu-packagers/kubuntu-packaging/qt) [15:11] I used grab merge. I had to create symbols files to fix a different error. [15:12] But even so I had the circular error prior to that [15:47] my head hurts from the kdelibs merge :( [15:48] and I still have to deal with symbols [15:50] my brain has melted from qt4 merge, but finally done. [15:51] sgclark: Hi, can you please show me your qt4 code? Or, even better, commit it to Bzr? [15:53] mitya57: I am only packaging a merge. I do not have bzr access to that. I will have a my dropbox link here in a sec [15:53] the circular dependency is resolved though [15:54] I am asking because: In my branch that symbols file was correct from the beginning, and there is no loop between gui and declarative. [15:54] sgclark: you can just commit locally and push to a private branch [15:54] I.e., maybe it is better if we take my code as a base [15:56] This is a merge with debian which is a newer version, What version are you using? [15:57] sgclark: What I prepared was also a merge with Debian. [15:58] http://paste.kde.org/pyqgmkbpl [15:58] I'm also a co-maintainer of Qt in Debian :) [15:58] That is wonderful, why am I merging it lol [15:58] (My bad that I didn't coordinate it before committing.) [15:59] Riddell: ^^ [16:00] * BluesKaj wonders if the word mistake is no longer cool ...my bad this, my bad that .... [16:00] Oh well, it was a good learning experience. If you have merged it already, there is no point messing with mine. [16:00] sgclark: In any case, please show me your code, maybe you've done some parts better than I. [16:01] thanks mitya57 [16:01] sgclark: yeah let us see what you have and we'll grab the best bits of both [16:01] http://bazaar.launchpad.net/~kubuntu-packagers/kubuntu-packaging/kdelibs/revision/586 [16:01] incase someone wants to review [16:02] https://www.dropbox.com/sh/p8hlhv9lztlyyjl/4RjZyLGlfY/kubuntu-files [16:02] * mitya57 looks [16:02] Riddell: anything left for me withh frameworks? [16:04] sgclark: loads http://qa.kubuntu.co.uk/kf5-status/build_status_4.99.0_trusty.html [16:04] https://notes.kde.org/p/kubuntu-ninjas-frameworks [16:07] shadeslayer: please reupload using -v. [16:07] ScottK: I did? [16:07] which is why it has both the 0.1 and 0.2 entry? [16:08] * ScottK checks again. [16:08] sgclark: a lot of them have had translations added and need qttools5-dev, qttools5-dev-tools, qt5-default added and a -data package added [16:08] ScottK: http://paste.kde.org/p7dnbc8gt [16:08] is what I have [16:08] Riddell: ok [16:09] sgclark: and some of the paths have been changed [16:09] shadeslayer: Sorry. Misread. Accepted. [16:09] ScottK: thx :) [16:11] sgclark: To be honest, my branch looks better to me :) As an example, you for some reason removed aarch64 & ppc64el patches from series, and they don't apply cleanly. [16:11] * Riddell out [16:13] mitya57: removed because they would not apply. I am still learning and qt4 was a monster to me. I have fought with this for many days and so I accept the fact that it is all probably a waste. [16:13] sgclark: There is at least one thing that you noticed but I did not [16:13] (and that thing is a changelog entry for 4:4.8.5+git192-g085f851+dfsg-2ubuntu4) === pcwhite is now known as PaulW2U [16:28] Riddell: pushed that bit to Bzr (actually it was not just changelog entry, but half of upload). Now it should be ready. [16:41] sgclark: your code *was* helpful [16:46] mitya57: thank you. as for the patches I dropped because they ould not apply, what should I have done? For the future of learning :) [16:52] sgclark: They did not apply because we (Lisandro PM and I) forwarded some bits upstream. After removing those bits, the patch applies. === jmux_ is now known as jmux [16:52] Check what I've done in Bzr [16:52] mitya57: ok. will do thank you [18:15] yofel, hi, does project neon have debug symbols for all packages? [18:15] any package should have a -dbg as long as it has binaries [18:16] ok thanks [18:16] yofel: there are still packages for the kde 4 based stuff right? [18:16] not really, there are for saucy, but for trusty it's rather broken [18:17] thats bad ... then I have to compile the whole kdepim stack myself :-( [18:17] Is anyone else working on https://notes.kde.org/p/kubuntu-ninjas-frameworks? I seem to be working on packages that are already being worked on again... [18:21] * yofel isn't [18:21] kdeuser56: there's kdesrc build, which should make that rather easy [18:21] it's even in the archive [18:21] yofel: yeah it is ... but it takes a long time [18:34] G'day folks. [18:35] ovidiu-florin: I can't post a question in the support forums for Evolve unless the theme has been purchased. I did send them an email using their contact form with the details of the scenario. [18:41] mh, aren't council elections supposed to be held in may btw? [19:04] Anyone available to review kcompletion and kjobwidgets in bzr? [19:19] apachelogger: yep, we should discuss that at the meeting on monday [19:20] sgclark: yep (probably) [19:21] Riddell: yep probably what? :) [19:21] sgclark: probably can review [19:21] oh ok, great, ki18n will done here shortly as well [19:23] sgclark: all the packages are in the PPA just most of them need fixes [19:24] sgclark: I just did a mass upload to start which is also in bzr, but that's just adding a changelog [19:24] so new paths, translations and other things need fixed [19:24] Riddell: right, I am grabbing them from PPA [19:24] ppa and bzr should be the same [19:24] and fixing. kcompletion was only one that had some changes done in bzr [19:26] oh yes sorry I see I did half start that and then forgot about it :( [19:27] hehe it's ok [19:28] sgclark: you removed the top of the changelog in kcompletion [19:28] Riddell: I did? was not intentional [19:30] Riddell: ki18n ready [19:31] That is all the reds, want me to retry the dependency waits when these build? [19:31] sgclark: yeah please [19:31] will do! [19:32] I will list any I work on in the sheet , as you will be awake before me tomorrow :) [19:37] sgclark: uploaded your three packages [19:37] sgclark: I also committed my incomplete changes for kauth to bzr so you can complete that if you so wish [19:42] Riddell: will do [19:50] shadeslayer, apachelogger: Hi again, about my unusable e.u.c backtraces pronlem, I made a script that transform incomplete e.u.c backtraces into usable ones https://gist.github.com/Elv13/76aac9356171de13e352 It does a good enough job to solve most problems [20:40] Riddell: or anyone available kauth ready in bzr [20:43] Riddell: we don't have pressed Kubuntu DVDs anymore, right? [20:46] nope [20:46] kinda sad :( [20:47] some guy asked for a Kubuntu DVD to be shipped (I ship DVDs in my country) and for any weird reason *all* my DVDs and burners decided to fail [20:48] heh [20:48] jose: though I guess you can order one from the Canonical store, maybe [20:48] they don't sell kubuntu ones anymore :( [20:48] hm, nope [20:48] and the Ubuntu Desktop and Server ones I already got [20:49] they finally do have properly priced tshirts [20:49] really?! [20:49] yeah, 10 GBP [20:49] http://shop.canonical.com/index.php?cPath=14 [20:49] oh, but I'm sure shipping is 3x the price of the shirt [20:50] * shadeslayer checks [20:51] hmm, shipping to Peru: 6.50 GBP for a tshirt [20:51] Expedited, arriving in 1 week: 39.42 GBP [20:51] shipping within GB is 5 GBP [20:51] Express, arriving in 5 days: 120.32 GBP [20:51] shipping to Spain is 7-8 [20:51] heh :P [20:51] I think I'll choose... Express [20:52] xD [21:14] sgclark: kauth uploaded! [22:19] Riddell: or anyone available kservice is ready in bzr