[00:00] <soee> ok im going to sleep, lets hope tomorrow raring packages are ready :)
[00:45] <manchicken> Riddell: You wouldn't be around by some odd coincidence, would you?
[00:52] <yofel> yep, plenty of the new symbols are arch=armhf
[00:52]  * yofel uploads kdelibs and falls off the chair
[00:52] <yofel> good night
[01:13] <ScottK> manchicken: calligra
[01:18] <ScottK> manchicken: You want another one?  https://launchpadlibrarian.net/143377794/buildlog_ubuntu-saucy-armhf.kubrick_4%3A4.10.80-0ubuntu1_FAILEDTOBUILD.txt.gz
[01:24] <manchicken> Un moment...
[01:24] <manchicken> This one isn't so easy.
[01:37] <manchicken> I've gotta download the libqt4-dev package in order to get the headers.
[02:08] <manchicken> Stupid question: GLES and glext... what's the difference?
[02:08] <manchicken> Why include both?
[02:29] <manchicken> ScottK: You're going to need someone who knows these APIs.
[02:30] <manchicken> ScottK: The typedef's result in the exact same size and precision (8-byte int on amd64 at least), but there is a conflict btween the GLES2 and the glext includes which I don't know how to resolve without breaking stuff.
[02:30] <manchicken> I'm gonna run, and then I'll be back.
[03:08] <manchicken> I'm back.
[03:08] <manchicken> ScottK: Does anybody know this library?
[03:23] <ScottK> manchicken: Not in Kubuntu.  I know on armhf, which is the only place this fails, we have only GLES and not GL.
[03:23] <ScottK> So it's going to work with GLES or not at all.
[03:26] <manchicken> So then maybe we should throw a conditional around the includes for GL.
[03:26] <manchicken> There's gotta be an arch-specific preprocessor symbol we could test for
[03:32] <ScottK> I'm sure there is.
[04:10] <ScottK> manchicken: I think it should look for GL/GLES as that's what the code cares about.  We know how that relates to architectures in Ubuntu, but it's not a fundamental relationship.
[04:10] <ahoneybun> hey manchicken
[04:10] <manchicken> ahoneybun: Hey
[04:10] <ahoneybun> manchicken: are you working on the script to pull things from the wiki?
[04:11] <manchicken> ahoneybun: I am, kinda... I don't have much information about the specs.
[04:12] <ahoneybun> manchicken: oh ok
[04:12] <manchicken> I have a script which is mostly working against Wikipedia (nobody told me which wiki, so I'm assuming mediawiki and wikipedia is an obvious choice).
[04:12] <manchicken> ahoneybun: If you have more specs I'd be happy to take them into account here.
[04:12] <ahoneybun> no sure what you mean by specs
[04:12] <ahoneybun> *not
[04:13] <manchicken> Requirements
[04:13] <manchicken> Like, Riddell said he didn't want to pass in a URL, but I don't know what he wants to take as input then.
[04:14] <manchicken> So I changed it up and now you pass in a wikiword.
[04:20] <ahoneybun> maybe anything with the categorydocumentation?
[04:22] <ahoneybun> I mean we can just take the text from each page, more work but still a option
[04:23] <manchicken> Which wiki is this gonna hit? Ubuntu?
[04:23] <manchicken> Then, the other two questions are does the Wiki have an API, and which flavor of WikiMarkup is it?
[04:24] <ahoneybun> kubuntu wiki, idk, moinmoin
[04:26] <manchicken> What do you want for the input?
[04:27] <manchicken> You want to provide a page name or a URL or what?
[04:27] <ahoneybun> like have it take the content from a page name I gues
[04:27] <ahoneybun>  /kubuntu/kubuntudocs/welcome
[04:29] <manchicken> ahoneybun: As much as I'd love to code something new (no joke, I would), what about this: http://moinmo.in/MoinDump
[04:32] <ahoneybun> so it can dump page content to html?
[04:34] <ahoneybun> kubuntu wiki uses moinmoin but they limit the the abilities we have
[04:42] <manchicken> Well it says it can
[04:42] <ahoneybun> yea I'm wondering if I should test it
[04:42] <manchicken> We probably should.
[04:43] <manchicken> The question is does whether it makes a web request or a DB query :)
[04:43] <ahoneybun> not for me today off to bed
[04:46] <ahoneybun> anyway off I go
[06:37] <smartboyhw> Anyone doing 4.10.5 upload?
[06:51] <smartboyhw> Damn, that script failed for 4.10.5.
[06:51] <smartboyhw> yofel, Riddell ScottK do you guys get Permission denied (publickey) when running the kubuntu-initial-upload script!?
[06:52] <smartboyhw> shadeslayer, apachelogger ^
[06:54] <smartboyhw> ... Why does new symbols in analitza appear not in a saucy build but in a raring build!?
[07:12] <smartboyhw> ahoneybun, how's digikam?
[07:17] <valorie> smartboyhw: he went to bed quite awhile ago
[07:17] <valorie> last I saw, Riddell was telling him to rebuild it
[07:17] <valorie> perhaps when R comes back online he'll know the status
[08:12] <lordievader> Good morning.
[08:31] <soee> good morning
[08:34] <lordievader> Hey soee, how are you?
[08:35] <soee> lordievader, fine, thank you and you ?
[08:36] <lordievader> I'm doing good too, editing the Kubuntu Docs a bit :)
[08:37] <soee> im waiting for yofel to fix raring packages :)
[09:03] <yofel> smartboyhw: raring has a different compiler, so far no 2 versions of gcc provided a matching list of symbols :/
[09:03] <yofel> it's usually no problem though
[09:09] <shadeslayer> smartboyhw: 4.10.5 is broken
[09:09] <shadeslayer> split packages et all
[09:13] <yofel> brrr
[09:14] <yofel> smartboyhw: note that you can really only run that script once 4.10.4 is in updates
[09:14] <yofel> otherwise it'll fetch the wrong packages
 pinotree: abi-compliance-checker says there is no ABI/API change in akonadi
[09:19] <yofel> what in hell is abi-compliance-checker
[09:21] <debfx> yofel: afaik the backend of http://upstream-tracker.org/
[09:22] <yofel> interesting
[09:25] <debfx> seems to be able to detect more types of ABI breakage than symbol files
[09:31] <soee> yofel, so if the packages that are building now are fine we can test raring ?
[09:33] <yofel> it should be fine, the rest is only symbol file diff
[09:33] <yofel> nothing worse than beta1
[09:34] <soee> ;p
[09:34] <yofel> hm, mouse cursor motion doesn't really work right under XMir
[09:35] <yofel> if I move it very fast on the touchpad, then it jumps instead of moving
[09:39] <shadeslayer> http://adarkroom.doublespeakgames.com/
[09:40] <shadeslayer> ^^ seems like a fun game 
[09:45] <shadeslayer> why this is odd
[09:45] <shadeslayer> if you have your adapter plugged in and you click the battery plasmoid, nothing happens
[09:46] <shadeslayer> hm, and suddenly it works
[09:55] <soee> yofel, 3 packagets waits for okular-dev but okular was build already ?
[09:56] <soee> i dont get it how it works ;)
[09:59] <smartboyhw> shadeslayer, ah alright..
[10:01] <smartboyhw> yofel, ah alright.
[10:03] <BluesKaj> Hiyas all
[10:09] <yofel> soee: the dependency check is only run ~hourly or so
[10:09] <yofel> I'll force them
[10:10] <yofel>  Start in 1 hour 
[10:10] <yofel> :/
[10:12] <Esokrates> shadeslayer: it seems our problem from yesterday behaves very very randomly ... reproducing is not always possible
[10:12] <soee> building ?
[10:21] <yofel> meh, I played with the kwin rendering settings a bit on my netbook, and now I've managed to get X stuck for the 4th time in one hour on XMir
[10:32] <smartboyhw> yofel, yes!:P
[11:10] <yofel> btw. anyone else getting this?
[11:10] <yofel> [   42.796587] ksplashqml[2452]: segfault at 0 ip b74b3eb7 sp bfedf640 error 4 in libQtCore.so.4.8.4[b7323000+2db000]
[11:11] <yofel> that would explain why ksplash quits before plasma is started
[11:12] <soee> yofel, all packages ready ?
[11:12] <yofel> checking, got distracted debugging X
[11:13] <yofel> yeah, everything seems ready. let me do a dep check then I'll copy them
[11:13] <soee> pk
[11:14] <soee> *ok
[11:22] <smartboyhw> yofel, you're copying to the backports PPA?
[11:22] <yofel> no beta, beta's and RC's never go into backports
[11:22] <smartboyhw> yofel, beta backports?
[11:22] <yofel> right
[11:22] <smartboyhw> yofel, now? Wow, that's quick.
[11:22] <smartboyhw> This is much MORE better than 4.10.80:P
[11:23] <yofel> well, yeah ^^
[11:23] <smartboyhw> yofel, when can we un-stuck 4.10.4 in raring-proposed!?
[11:23] <yofel> build queues were empty too so thing finished building overnight mostly
[11:23] <yofel> *things
[11:23]  * smartboyhw rather wants soee to test 4.10.4 to make it through.:P
[11:23] <smartboyhw> So we can start working on 4.10.5!
[11:24] <BluesKaj> is it in the raring backports yet ?, because ai have issues with the desktop atm , after the last upgrade a few days ago
[11:25] <yofel> smartboyhw: hm, it's been 7 days, so ScottK should be able to release it when he gets to it
[11:25] <BluesKaj> taskmanager and pasgers don't show in th epanel and the titlebars are missing from the windows
[11:25] <yofel> smartboyhw: kde folks need to fix kdeadmin and kdenetwork first though
[11:25] <smartboyhw> BluesKaj, not 4.10.5. 4.10.90 soon be.
[11:25] <smartboyhw> yofel, that's the issue really:P
[11:25] <yofel> BluesKaj: I'll have it in the beta backport in ~half an hour
[11:26] <yofel> need to do a quick upgrade test first
[11:26] <BluesKaj> yes I mean  4.10.90 , smartboyhw
[11:26] <BluesKaj> yofel , good , thanks
[11:27] <soee> smartboyhw, 4.10.4 on raring ?
[11:27] <smartboyhw> soee, yeah.
[11:27] <smartboyhw> It's stuck there for a long time. 
[11:27] <soee> i would have to install it on VM
[11:27] <yofel> not long, no
[11:27] <smartboyhw> yofel, you don't understand.
[11:27] <smartboyhw> Hong Kong people are VERY impatient.
[11:27] <yofel> 7 days it's minimum, and the proposed testing mail was sent on the 21st
[11:28] <yofel> well, blame the paperwork :P
[11:28] <smartboyhw> yofel, we have some build-dep problems for okular and kdepim-runtime in the archive.
[11:29] <yofel> note for upgraders, this *should* happen:
[11:29] <yofel> The following packages will be REMOVED:
[11:29] <yofel>   libtaskmanager4abi3
[11:31] <yofel> smartboyhw: kdepim-runtime looks ok to me, okular retried
[11:31] <smartboyhw> yofel, kdepimlibs?
[11:31] <yofel> fine too
[11:32] <yofel> Scott usually tracks the failures there, so I guess he already retried those
[11:32] <smartboyhw> yofel, ah.
[11:32] <smartboyhw> Heck, I can't access the website admin page using rekonq.
[11:33] <smartboyhw> Riddell, can you help?
[11:33] <smartboyhw> The certificate problems seems VERY annoying....
[11:33] <yofel> which one?
[11:33] <smartboyhw> Just keep popping up.
[11:34] <smartboyhw> yofel, https://www-admin.kubuntu.org
[11:34] <yofel> ah, last time I tried I had lots of issues with rekonq there, try with konqueror
[11:34] <yofel> (login worked, but the page itself not really)
[11:34] <smartboyhw> yofel, :P
[11:34] <soee> so are you pushing 4.10.4 or testing ?
[11:34] <smartboyhw> soee, testing.
[11:34] <smartboyhw> not.
[11:34] <smartboyhw> :P
[11:35] <yofel> we're working on a bunch of things in parallel ;P
[11:35] <soee> thats not good :)
[11:35] <soee> mark one taks, do it.  go next task :)
[11:35] <yofel> my upgrade test is still running, will be done in a minute
[11:35] <yofel> gotta love SSD's :D
[11:36] <soee> will love them to when get some:)
[11:36] <smartboyhw> yofel, even worse. Konqueror I can't even type the login details to the main page.
[11:36] <yofel> ok, passed
[11:36] <yofel> copying
[11:36] <yofel> lolwhat?
[11:36] <yofel> I'll try in a minute
[11:39] <smartboyhw> yofel, um kdeadmin & network are uploaded I think.
[11:39] <yofel> soee: copied, you'll have to wait on launchpad's publisher now
[11:40] <yofel> and I forgot l10n, that'll follow now
[11:40] <smartboyhw> yofel, and BTW why do I get permission denied (publickey) when running the scripts?
[11:40] <yofel> do you have a new ssh key?
[11:40] <soee> yofel, ok
[11:40] <smartboyhw> yofel, I did. But Riddell did upload that for me.
[11:40] <smartboyhw> I'm able to access using dolphin.
[11:41] <smartboyhw> So, can't understand.
[11:41] <yofel> you are connecting as ftpubuntu?
[11:41] <smartboyhw> yofel, do I have to connect WHILE I'm running the scripts?
[11:41] <smartboyhw> yofel, ofc.
[11:41] <yofel> no, but you need a) an ssh-agent, b) a setting in .ssh/config so it uses the correct user
[11:42] <smartboyhw> yofel, probably the second.
[11:42] <smartboyhw> is the problem.
[11:42]  * smartboyhw does have ssh-agent.
[11:44] <yofel> see README
[11:44] <yofel> in kubuntu-automation
[11:49] <ScottK> yofel: I plan to release it on Monday.
[11:49] <yofel> hm, then we'll have to wait till monday, ok
[11:50] <ScottK> Wait for what?
[11:50] <yofel> uploading 4.10.5, the script can't pull packages from -proposed right now
[11:50] <ScottK> It's policy not to release SRUs on Friday or on the weekend.
[11:50] <ScottK> That or fix the script ...
[11:50] <yofel> ah, makes sense I guess ^^
[11:51] <yofel> yeah, should be doable I guess.
[11:51] <yofel> smartboyhw: want to do some python scripting? ^^
[11:53] <soee> yofel, libtaskmanager4abi3 is going to be removed and libtaskmanager4abi4 installed right ?
[11:53] <yofel> rigt
[11:53] <yofel> +h
[11:53] <soee> ok starting
[11:54] <yofel> ok, as expected, that my rendering issues are gone isn't thanks to XMir but thanks to the ppa shipping a newer mesa version
[12:03] <allee> smartboyhw: do you plan to backport *kscreen 1.0 pkg to raring (and maybe even precise?)
[12:04] <yofel> Bug 1195806
[12:04] <ScottK> allee: There's an SRU pending for raring
[12:04] <yofel> precise we can do as backport, yeah
[12:05] <allee> ScottK: thx.  I'll check it
[12:06] <ScottK> allee: It's not in yet.
[12:07] <BluesKaj> SRU ? , ScottK 
[12:07] <ScottK> stable release update
[12:08] <BluesKaj> thanks
[12:08] <ScottK> The process that gets a fix into -updates.
[12:08] <BluesKaj> yes
[12:08] <allee> yofel: fwiw: for precise we should add divert on to kscreen for krandrstartup
[12:08] <allee> otherwise startupkde exits with error and kdm greeter takes control again ;-)
[12:09] <yofel> allee: we try not to do technology transitions for backports, that's why the backport packages have the disable-krandr patch removed
[12:10] <yofel> or is it broken right now?
[12:10] <BluesKaj> yofel, ok , should I update/upgrade raring now ?
[12:10] <allee> yofel: kscreen in precise breaks startupkde
[12:10] <yofel> ah, so I guess we would need a selective check whether kscreen is there or not :/
[12:11] <yofel> can you file a bug against kubuntu-ppa please?
[12:14] <yofel> BluesKaj: you can if you want, everything's published
[12:15] <BluesKaj> ok yofel , vg
[12:17] <soee> reboot
[12:18] <allee> yofel: well, kscreen in precise does not conflict with kde-workspace-randr, so I maybe removed it by hand and broke startupkde that way. 
[12:18] <yofel> uhm, yeah. kde-workspace-randr should not be optional in precise
[12:19] <BluesKaj> presently upgrading the latest 13.10 kernel to 3.10.0.1.10
[12:19] <yofel> I once tried to make it optional in startkde but completely broke the script on my system so I postponed that
[12:21] <allee> yofel: as kscreen is only in backports ppa a test -r $(which krandrstartup) && . krandrstartup
[12:21] <allee> should do the trick
[12:21] <soee> yofel, smoth upgrade
[12:21] <soee> *o
[12:21] <allee> or kscreen divert it to and empty file
[12:21] <yofel> allee: we already have package tests in there but something didn't work out, I'll give it another try later
[12:24] <smartboyhw> yofel, what the hell python !?
[12:25] <yofel> yeah, python ^^
[12:26] <smartboyhw> yofel, I know VERY FEW python.
[12:27] <smartboyhw> Anyways, what's the task!/
[12:27] <smartboyhw> ?
[12:27] <yofel> pulling packages from -proposed if possible
[12:28] <yofel> I think that would be something like trying it and check if it worked, otherwise pull from regular release
[12:28] <smartboyhw> yofel, that's too difficult for me I think...
[12:28] <yofel> ok
[12:29] <ryanakca> smartboyhw: I've never been able to login to the admin page with anything but Firefox/Iceweasel. Don't ask me why...
[12:29] <smartboyhw> ryanakca, heh
[12:30] <yofel> smartboyhw: works for me with konqueror, what was broken again?
[12:30] <smartboyhw> yofel, certificates.
[12:30] <yofel> no warning here
[12:30] <smartboyhw> Both rekonq and konqueror complains.
[12:30] <smartboyhw> yofel, :O
[12:30] <yofel> though maybe I already ignored it
[12:30] <yofel> dunno
[12:31] <smartboyhw> yofel, wait. You mean I really can't run the kubuntu-initlal-upload script even I set -v 4.10.5 ?
[12:31] <smartboyhw> It's for PPA isn't it?'
[12:31] <yofel> well, you'll base those on the 4.10.3 packages currently
[12:31] <yofel> that's not what you want
[12:32] <smartboyhw> yofel, ...
[12:32] <smartboyhw> I think the "no SRU release on Friday" rule should change...
[12:32] <yofel> no. seriously. no
[12:33] <yofel> you do not put things on production on friday
[12:33] <yofel> never
[12:33] <yofel> ever
[12:33] <ScottK> smartboyhw: No.  We put it there because some bad SRUs got release on Friday and then it was the weekend when someone noticed and no one was around to fix it.
[12:34] <ScottK> I sometime push things on the other end and release late Sunday on the theory that someone will be around by the time someone notices a problem.
[12:36] <soee> this is interesting Chrome eats more memory with one tab than Firefox with 3
[12:41] <allee> ScottK: kscreen SRU: didn't find the pkg in raring-proposed and no SRU bug, so  pending means  noone works on it yet?
[12:41] <ScottK> It's in the queue for the SRU team to review/accept.
[12:42] <allee> ScottK: ah, oh.  Thx
[12:42] <ScottK> BTW, if someone could actually finish digikam and upload it, that would help immensely with getting some saucy proposed -> release migrations unstuck.
[12:44] <ScottK> smartboyhw: symbols for okteta on armhf need fixing, if you're looking for something productive to do.
[12:46] <yofel> I'll try to get to digikam later if time permits. I have access to that ec2 I think
[12:49] <ScottK> Thanks.
[12:51] <smartboyhw> ScottK, alright then.
[12:51] <smartboyhw> Should be simple.
[12:51] <ScottK> Thanks.
[12:59] <smartboyhw> ScottK, actually, it's symbols problem EVERYWHERE...
[12:59] <BluesKaj> yofel, unfortunately plasma is still mucked up in 13.04 
[12:59] <smartboyhw> On all arches. 
[13:00] <smartboyhw> BluesKaj, a X problem?
[13:01] <BluesKaj> smartboyhw, a plasma widgets problem and windows titlebars 
[13:01] <smartboyhw> BluesKaj, hmm...
[13:01] <ScottK> smartboyhw: Well have fun then.
[13:04] <apachelogger> yofel: ping
[13:24] <smartboyhw> ScottK, dget -xu https://launchpad.net/~smartboyhw/+archive/ppa/+files/okteta_4.10.90-0ubuntu2.dsc
[13:24] <smartboyhw> Diff: https://launchpad.net/~smartboyhw/+archive/ppa/+files/okteta_4%3A4.10.90-0ubuntu1_4%3A4.10.90-0ubuntu2.diff.gz
[13:24] <smartboyhw> Uploaded to bzr already.
[13:26] <kubotu> ::workspace-bugs:: [1196018] kwin with wayland support? @ https://bugs.launchpad.net/bugs/1196018 (by Sandra Karuving)
[13:26]  * ScottK tries
[13:27] <apachelogger> build log is ok
[13:28] <apachelogger> also rekonq is getting worse to use -.-
[13:28] <apachelogger> searching the workspace log from within rekonq goes ... "char.............................char....................................................................................charcharcharchar"
[13:29] <apachelogger> could be a not installed file though, I fail to find output for that
[13:30] <apachelogger> yofel: didn't ninjas builds used to have list-missing or something?
[13:31] <yofel> apachelogger: they did?
[13:31] <yofel> erm yes, they did
[13:32] <apachelogger> can't see no nothing now :(
[13:32] <yofel> if you use debian-qt-kde.mk I think
[13:32] <yofel> buildlog?
[13:51] <ScottK> smartboyhw: I started a test build on one of the armhf boxes.
[13:51] <smartboyhw> ScottK, great.
[13:58] <apachelogger> yofel: https://launchpad.net/~kubuntu-ninjas/+archive/ppa/+build/4754496/+files/buildlog_ubuntu-saucy-amd64.kde-workspace_4%3A4.10.90-0ubuntu2~ubuntu13.10~ppa6_UPLOADING.txt.gz
[13:58] <smartboyhw> apachelogger, check i386.
[13:59] <smartboyhw> --list-missing and lintian doesn't run in amd64 I think.
[13:59] <apachelogger> curious
[14:00] <Esokrates> afiestas_: have you found the reason for the black screen problem?
[14:01] <smartboyhw> apachelogger, https://i143672214.restricted.launchpadlibrarian.net/143672214/buildlog_ubuntu-saucy-i386.kde-workspace_4%3A4.10.90-0ubuntu2~ubuntu13.10~ppa6_UPLOADING.txt.gz?token=0a462bf31fa34eed8052d13227246a77
[14:01] <smartboyhw> i386 does have --list-missing and lintian.
[14:08] <markey> what's the equivalent of qt4-doc for kde docs?
[14:09] <apachelogger> no such package
[14:09] <markey> i.e. kde api docs in help format for Qt Creator
[14:09] <markey> oh
[14:20] <smartboyhw> yofel, 4.10.90 fully copied to kubuntu-ppa/beta right?
[14:24] <apachelogger> ehm
[14:24] <apachelogger> 600mb tar
[14:24] <apachelogger> DAFUQ
[14:24] <apachelogger> yofel: it would appear shipping with .git is also not the solution :S
[14:26] <smartboyhw> ScottK, how's the armhf build of okteta?
[14:30] <kubotu> ::workspace-bugs:: [1196018] kwin with wayland support? @ https://bugs.launchpad.net/bugs/1196018 (by Sandra Karuving)
[14:31] <apachelogger> yofel: think we'll have to go back to foreach f in *; mkdir $f/.git
[14:33] <soee> any idea why when i start my system 2 instances of dolphin are opened ?
[14:33] <soee> i checked startup programs and thers nothig related
[14:35] <soee> brb
[14:38] <manchicken> Mornin'
[14:38] <manchicken> ScottK: You ever find anybody who knew your GLES/glext question?
[14:39] <manchicken> ahoneybun: Did you get a chance to look at MoinDump?
[14:46] <ScottK> manchicken: No.
[14:46] <ScottK> smartboyhw: 92%
[14:47] <smartboyhw> ScottK, :) (ARM is slow:P)
[14:47] <manchicken> ScottK: I can see if I can try to fake it, but it probably won't work.
[14:47] <ScottK> Worth a try.
[14:48] <manchicken> First step is to figure out what the preprocessor symbol is for arm, second is to just throw in the conditional around the glext include. I suspect there will be a third step of figuring out which symbols we have to chase down without glext, or which other symbols we have to wrap in conditionals.
[14:48] <manchicken> ScottK: I wonder if you could just configure it without glext...
[14:54] <manchicken> I wonder if `#ifdef __arm__` would work... I'm seeing some of it on googling.
[14:54] <manchicken> I'm gonna go swim in the headers.
[14:55] <apachelogger> ScottK: what problem is that?
[15:13] <manchicken> ScottK: I've got an idea. On line 34 append « #endif /* __arm__ */ » and then on line 32 append « #ifndef __arm__ »
[15:14] <manchicken> ScottK: Try that. I expect that to cause new build errors, though.
[15:16] <yofel> apachelogger: meh, does it always remove it or what?
[15:19] <yofel> ahoneybun: in what state is digikam on the ec2?
[15:38] <yofel> nvm, fetching
[15:38] <smartboyhw> Hmm, interesting e-mail in kubuntu-devel about kopete.
[15:39] <apachelogger> yofel: no, the tar just ends up being 600mib with git ^^
[15:39] <apachelogger> vs. 160 without
[15:40] <apachelogger> so packing .git seems not very practical
[15:40] <yofel> right...
[15:40] <apachelogger> Project ERROR: Module does not define version.
[15:40] <apachelogger> it also fails with .git
[15:40] <apachelogger> dafuq
[15:40] <apachelogger> .....
[15:40] <smartboyhw> LOL
[15:40] <yofel> maybe you shouldn't take *all* modules?
[15:41] <apachelogger> that's the standard way to build it
[15:41] <apachelogger> and it still doesn't flipping build :@
[15:42] <apachelogger> and I have no clue why
[15:46] <apachelogger> shadeslayer: https://code.launchpad.net/~kubuntu-packagers/kubuntu-packaging/kopete preserving history is usually what we tend to do :S
[15:46] <smartboyhw> shadeslayer, heh
[15:46] <smartboyhw> apachelogger, hehj
[15:46] <smartboyhw> Well, why did we change it then in the first place?:P
[15:48] <smartboyhw> I think for googletalk it's because we don't have expat.
[15:48] <smartboyhw> as build-dep
[15:49] <smartboyhw> As for disabling video support and skype protocol: Dunno,
[15:56] <yofel> ahoneybun: I copied the digikam state you had over and shut the ec2 down
[16:01] <ScottK> smartboyhw: https://paste.debian.net/13313/ - it didn't end well.
[16:02] <ScottK> apachelogger: manchicken wanted some coding stuff to do so I asked him to look at one of the armhf build failures caused by GL/GLES.
[16:02] <apachelogger> that sounds like nto fun at all :P
[16:05] <ScottK> Got something more fun we can give him?
[16:05] <ScottK> He fixed the calligra FTBFS on arm for me already.
[16:06] <ScottK> apachelogger: Can you commit stuff to the calligra repos?
[16:06] <apachelogger> yes
[16:08] <ScottK> let me get you the patch.
[16:10] <smartboyhw> ScottK, um, I did run ALL patches  for ALL archs into pkgkde-symbolshelper
[16:10] <smartboyhw> So, maybe needing to do it MANUALLY.
[16:10] <smartboyhw> !!??!?!?!?
[16:10] <smartboyhw> I really can't help now, sleep time.
[16:12] <ScottK> apachelogger: https://paste.debian.net/13315/ joint credit for the patch to jr and manchicken (Michael D. Stemle, Jr).
[16:13] <smartboyhw> ScottK, if you want to do it manually, it will take a LONG time...
[16:13] <smartboyhw> I'm starting to think if these needed sudo:P
[16:13] <smartboyhw> Bye for now, sorry ScottK:P
[16:16] <apachelogger> KisFixedPoint(qreal(0.5));
[16:16] <apachelogger> that explicit construction seems unnecessary
[16:17] <apachelogger> also, the repository is huge, still cloning ^^
[16:17] <ScottK> Could be.
[16:17] <ScottK> jr tried qreal(0.5) and that didn't work.
[16:18] <ScottK> manchicken added the KisFixedPoint().
[16:18] <ScottK> I didn't notice until later it was a patch of a patch.
[16:18] <apachelogger> Oo
[16:18] <apachelogger> (dst_c_in_src - qreal(0.5))
[16:18] <apachelogger> that is the very same expression and it works there...
[16:19] <manchicken> Yay, I have my tethering set up, and my tiny laptop and I are in business.
[16:19] <ScottK> Heya manchicken.
[16:19] <manchicken> hiya
[16:19] <ScottK> apachelogger claims to have some less awful coding work than the arm stuff needing doing.
[16:19] <apachelogger> that ain't true :P
[16:20] <apachelogger> I have management work though :P
[16:20] <ScottK> Meh.
[16:20] <apachelogger> I know I know
[16:20] <ScottK> We have plenty of managers.
[16:20] <manchicken> Heh
[16:20] <manchicken> I have no idea what we're talking about, weeeeee!
[16:20] <apachelogger> ScottK: do we have a build log of Riddell's inferior patch?
[16:20] <ScottK> Yes.
[16:20] <ScottK> Look at the version before the one in the archive.
[16:21]  * apachelogger takes a looksy
[16:21] <ScottK> manchicken: One thing we're doing is sorting out the proper way to upstream your calligra patch.
[16:22] <manchicken> ScottK: Step 1: tell them not to use C++ overrides to add scalars to objects :)
[16:23] <manchicken> You get into trouble using overrides of operators to add numeric types to object types. I'm still a little surprised that this thing built at all on Intel.
[16:25] <apachelogger> ScottK: https://launchpadlibrarian.net/143393859/buildlog_ubuntu-saucy-armhf.calligra_1%3A2.6.92-0ubuntu5_FAILEDTOBUILD.txt.gz seems to be the last fail on armhf
[16:25] <apachelogger> and that was because of GL stuff
[16:26]  * ScottK looks
[16:28] <apachelogger> ubuntu7 built just fine https://launchpad.net/ubuntu/+source/calligra/1:2.6.92-0ubuntu7/+build/4748640
[16:28] <ScottK> Now I've really confused
[16:28] <ScottK> s/I've/I'm//
[16:28] <kubotu> ScottK meant: "Now I'm really confused"
[16:28] <manchicken> Nice!
[16:29] <manchicken> s/(N.*?)(\!)/Weeee\2/
[16:29] <kubotu> manchicken meant: "Weeee!"
[16:29] <manchicken> SWEET
[16:29] <ScottK> So ubuntu7 had failed.
[16:29] <manchicken> I like this bot.
[16:29] <ScottK> It looks like someone retried it and it magically worked.
[16:32] <apachelogger> ^^
[16:33] <ScottK> apachelogger: In any case, we were working of the ubuntu3 build log, which is https://launchpadlibrarian.net/143047036/buildlog_ubuntu-saucy-armhf.calligra_1%3A2.6.92-0ubuntu3_FAILEDTOBUILD.txt.gz
[16:33] <ScottK> of/off
[16:34] <manchicken> So, I'm going to play in libmanchicken land for a little while. Today, I'm doing dynamic lists! Let me know if you need me.
[16:34] <ScottK> manchicken: Thanks.
[16:35] <apachelogger> ScottK: yeah that log makes sense, through qreal(n) we then have one candidate only ... KisFixedPoint(qreal) 
[16:37] <ScottK> Explicit is better than implicit though.
[16:37] <ScottK> BBL
[16:38] <manchicken> apachelogger: I'm still trying to figure out how that compiled on any arch.
[16:39]  * apachelogger scratches head
[16:39] <manchicken> apachelogger: It doesn't make sense unless it was implying the constructor around the qreal() return.
[16:39] <manchicken> Essentially, implicitly doing the thing I gave an update to do explicitly.
[16:40] <manchicken> That's all I've got.
[16:40] <apachelogger> the problem was that n.n is double and a double could be coerced into int or qreal to construct a KisFixedPoint
[16:42] <apachelogger> manchicken: why it compiled on other archs is a good story though ^^
[16:42] <manchicken> Yes, except that KisFixedPoint doesn't store in a double.
[16:42] <manchicken> It stores in 4 bytes always.
[16:42] <apachelogger> so, qreal is a qt typedef for very precise number
[16:42] <manchicken> But that qreal will be 8 bytes
[16:42] <apachelogger> nono
[16:42] <manchicken> (or 16 bytes on 64bit?)
[16:42] <apachelogger> qreal is double!
[16:43] <apachelogger> BUT
[16:43] <apachelogger> not on arm, on arm it is float ;)
[16:43] <manchicken> Yes, but KisFixedPoint stores quint32.
[16:43] <apachelogger> best thing in the Qt api ^^
[16:43] <apachelogger> manchicken: yeah that doesn't matter though
[16:43] <manchicken> L119 of kis_fixed_point_maths
[16:43] <apachelogger> you can give it an int or a qreal and it will make it a 32bit integer
[16:43] <manchicken> But you could have truncation.
[16:44] <manchicken> Though I suppose that could be unlikely.
[16:44] <manchicken> (still a bad practice though)
[16:44] <manchicken> But qreal is a float on arm?
[16:44] <apachelogger> yes
[16:44] <apachelogger> that is why it built elsewhere
[16:44] <apachelogger> n.n is double
[16:44] <apachelogger> n.nf is float
[16:45] <apachelogger> n.n has one non-coercive candidate to get to KisFixedPoint
[16:45] <manchicken> That really shouldn't matter though since they're using qreal all over the place, right?
[16:45] <apachelogger> qreal(double)
[16:45] <apachelogger> but on arm that is qreal(float), so it's coercive, so the compiler has two equally shitty options ... cast to float and loose precision or cast to int and loose precision, so it gives up
[16:46] <apachelogger> manchicken: n.n is only equal to qreal on !arm
[16:46] <apachelogger> on arm n.nf is equal to qreal
[16:46] <manchicken> Yeah... another reason to make sure you don't use implicit coercion.
[16:46] <apachelogger> i.e. !arm -> 1.1 == qreal(1.1)      arm -> 1.1f == qreal(1.1)
[16:47] <manchicken> Gotcha.
[16:47] <apachelogger> manchicken: yeah the KisFixedPoint + double thing is shitty
[16:47] <manchicken> I've never done anything outside of a JVM or Obj-C on arm.
[16:47] <apachelogger> single most occuring problem with arm building
[16:48] <apachelogger> as it will work on !arm just fine as it's double everywhere else
[16:48] <manchicken> Yeah... at work we have a lot of fun with people not knowing the difference between C strings and character arrays.
[16:48] <apachelogger> ^^
[16:49] <manchicken> It seems silly that 15 years into my career I'm still having to deal with elementary stuff as my primary headache... but it is what it is.
[16:49] <apachelogger> honestly though IMO the issue lies with Qt there... from an API POV you should be able to coerce any real value (be it float or double or whatever) into a qreal as that is the abstract concept qreal represents... a real number.
[16:50] <manchicken> Is the need for that precision just due to GL stuff?
[16:50] <manchicken> If we're doing pixel math I don't think you really need that much in the way of precision.
[16:50] <manchicken> Seems like overkill.
[16:50] <apachelogger> no clue, I am not working on calligra
[16:50] <apachelogger> probably GL though
[16:51] <manchicken> Well, there's vector graphics there, too, so I suppose there's a fair amount of trig going on.
[16:51] <manchicken> Bloody triangles.
[16:53] <apachelogger> krita does vectors now? :O
[16:56] <manchicken> Isn't it a paint program?
[16:56] <apachelogger> http://commits.kde.org/calligra/c660f2637374f5081c83f11b1bb2720c05ae0485
[16:56] <manchicken> I will admit that I have only a vague apprehension of this program's functionality.
[16:56] <apachelogger> manchicken: more like drawing I guess
[16:56] <manchicken> I thought that would maybe include lines and angles and circles.
[16:57] <apachelogger> it maybe includes it... guess it shares libraries with the vector drawing app of calligra
[16:57] <apachelogger> but it's not the core feature set
[16:58] <manchicken> I love this touchscreen laptop.
[16:58] <apachelogger> that's the brushes and whatnot
[16:58] <manchicken> Yeah, either way that coercion is naughy.
[16:59] <apachelogger> also pushed to 2.7
[17:00] <apachelogger> yofel: that build fail doesn't even make much sense
[17:01] <apachelogger> svg.pro has load(qt_module) and that has as one of the first things isEmpty(VERSION): VERSION = $$MODULE_VERSION
[17:01] <yofel> what's MODULE_VERSION?
[17:03] <apachelogger> something abstracted through all sorts of places
[17:03] <apachelogger> actually, perhaps ossi would know what goes wrong there
 looks saucy, in any case :D
[17:07] <yofel> great... ^^
[17:10] <apachelogger> yofel: <ossi> apachelogger: then you are building an older version of qtsvg against a too new qtbase. hmmpf. now that you mention it, this should have been designed to work ...
[17:10] <yofel> fun
[17:10] <yofel> yeah, I read it
[17:10] <apachelogger> k
[17:11]  * apachelogger wiped cache
[17:11] <apachelogger> all that booty :(
[17:19] <ScottK> As soon as https://launchpad.net/ubuntu/+source/smokekde/4:4.10.90-0ubuntu1/+build/4755370 is done and someone fixes the symbols for okteta, 4.9.90 is done.
[17:19] <ScottK> s/4.9.90/4.10.90//
[17:19] <kubotu> ScottK meant: "As soon as https://launchpad.net/ubuntu/+source/smokekde/4:4.10.90-0ubuntu1/+build/4755370 is done and someone fixes the symbols for okteta, 4.10.90 is done."
[17:20] <ScottK> (less the GL stuff on armhf, but meh)
[17:24] <ScottK> Double meh.  kde-workspace isn't going to migrate to the release pocket without digikam and contour builds.
[17:25] <manchicken> So, we're compiling stuff on an actual ARM?
[17:26] <yofel> I'm almost done with digikam
[17:26] <ScottK> Yes.
[17:27] <apachelogger> (we are actually at the point where PPA builds for i386 and amd64 are virtualized on arm :P)
[17:27] <manchicken> Why not cross-compile?
[17:27] <yofel> but as we already don't ship imgur and wikimedia icons because of trademark violations I'm a bit worried here: http://paste.kde.org/785414/
[17:27] <yofel> how do I find out what not to ship? :S
[17:27] <apachelogger> don't ship any? :P
[17:27] <yofel> great solution :P
[17:28] <yofel> well, why do the other 2 violate the trademark anyway?
[17:28] <apachelogger> dlna, facebook, flash, flickr, imgeshack, imgur, picasa, showup, piwigo, smugsmug, wikimedia and zoomr are definitely not that legal
[17:28] <apachelogger> assuming they are the actual logos (which is likely the case)
[17:30] <yofel> they are
[17:38] <ahoneybun> yofel: sorry about leaving it like that
[17:39] <yofel> nah. don't worry, it's one of the rather big packages. maybe a bit too large for that ec2
[17:39] <ahoneybun> I tried to compile at least lol
[17:39] <ahoneybun> manchicken: I looked at that page you linked me to
[17:40] <manchicken> Yeah?
[17:40] <manchicken> Does that look like it'll work?
[17:41] <manchicken> Again, I'm happy to write something, but I don't think it's useful to duplicate functionality.
[18:13]  * yofel tries to generate 4.10.5 packages
[18:13] <BluesKaj> ok , tracked down the dependency culprit and removed it  , but had to reinstall kwin , kde-worspace and plasma and kubuntu desktops 
[18:14] <yofel> what was it?
[18:14] <BluesKaj> libglapi-mesa:amd64
[18:15] <yofel> o.O
[18:15] <BluesKaj> yofel,buggy api ?
[18:16] <yofel> not sure, where did you have that package from? I never had problems here
[18:19] <BluesKaj> good question , it was after I updated to a new new kde version a few days ago  , but I have  4.10.09 which is working fine now
[18:20] <ScottK> s/09/90//
[18:20] <kubotu> ScottK: You did something wrong... Try s/you/me/ or tell me "help sed"
[18:20] <BluesKaj> must haver been 08
[18:33] <yofel> apachelogger: what cache?
[18:34] <yofel> I thought you meant the cmake cache, but what kde cache do you mean?
[18:34] <apachelogger> qt5
[18:34] <apachelogger> didn't read http://community.kde.org/Frameworks/Building carefully enough and hence did not notice that the repo changed to gitorious
[18:35] <yofel> aaaaah
[18:35] <apachelogger> essentially part of the kde qt5 repos have no HEAD
[18:35] <apachelogger> breaking git submodule
[18:35] <apachelogger> hence why it failed to build but worked locally (local clone was done per copynpaste so I got that from gitorious)
[18:36] <apachelogger> building a new qt5 cache on the server now and hopefully qt5 starts bulding then :S
[18:38] <manchicken> Looks like there's already a bug outstanding for kpanel not playing nice with touchscreens.
[19:10] <yofel> ahoneybun: you may feel important ;P https://launchpad.net/~aaronhoneycutt/+related-packages
[19:13] <manchicken> Awesome.
[19:13] <manchicken> Cobra makes a car adapter that gets all the way up to 120V.
[19:14] <manchicken> I was surprised it actually had a 120V output.
[19:14] <manchicken> For $20
[20:10]  * yofel works on okteta symbols
[20:11] <yofel> ah meh
[20:11] <yofel> howard already did
[20:12] <yofel> uploaded
[21:13] <ScottK> yofel: Howard's were wrong.
[21:13] <yofel> eh, really?
[21:13] <yofel> well, too late now. LP will tell me
[21:13] <ScottK> Yeah.  FTBFS badly on my armhf test build.
[21:14] <ScottK> That's why it wasn't uploaded.
[21:14] <ScottK> https://paste.debian.net/13313/
[21:16] <yofel> yeah, I wonder what's up with those 381 removed symbols at the top there o.O
[21:17]  * yofel checks if he can build just the kipi-plugins in qemu
[21:19] <yofel> I wonder if using CMAKE_LIBRARY_ARCHITECTURE to detect whether I'm on armhf makes sense
[21:20] <yofel> as I would tend to fix digikam by just not building that slideshow plugin on arm