[00:48] <valorie> Riddell, ahoneybun_, sorry, have been doing xmas prep rather than being at computer
[00:48] <valorie> and about to dance off to dinner now
[00:56] <shadeslayer> sounds like a neat xmas tradition
[00:56] <shadeslayer> great way to make space for all the food one cooks on xmas
[02:32] <ahoneybun_> Riddell: changed the link Riddell
[02:40] <kubotu> ::qt-bugs:: [1262465] package libqt4-network 4:4.8.4+dfsg-0ubuntu18 failed to install/upgrade: cannot copy extra... @ https://bugs.launchpad.net/bugs/1262465 (by Mal)
[03:02] <ahoneybun_> valorie: Riddell this is cool, that yellow box I put up http://userbase.kde.org/Kubuntu/Advanced#Install.2FUninstall_.deb_files
[03:07] <manchicken_> apachelogger: This ABI compliance checker program seems to have had a recent release in October.
[03:32] <manchicken_> apachelogger: Gotta love this warning: WARNING: Not working properly with GCC 4.8. Please update or downgrade GCC or use a local installation by --gcc-path=PATH option.
[03:35] <manchicken_> apachelogger: It still gave me results though, I think that should be enough to work with.
[03:35] <manchicken_> I'll pick this up again later during my lunch hour tomorrow.
[03:36] <manchicken_> Night all.
[04:47] <kubotu> ::qt-bugs:: [1262465] package libqt4-network 4:4.8.4+dfsg-0ubuntu18 failed to install/upgrade: cannot copy extra... @ https://bugs.launchpad.net/bugs/1262465 (by Mal)
[05:14] <utusan> oh  boy we are in dependency hell now with 4.12
[05:16] <utusan> I knew it when it wanted to remove kde-runtime
[05:48] <kubotu> ::qt-bugs:: [1242633] unity pointer barriers sru bug @ https://bugs.launchpad.net/bugs/1242633 (by Maarten Lankhorst)
[06:28] <jussi> ooh, new KDE stuff incoming :D
[06:32] <jussi> Packagers alert... bug! 
[06:32] <jussi> /var/cache/apt/archives/libakonadi-xml4_4%3a4.12.0-0ubuntu1~ubuntu13.10~ppa1_amd64.deb
[06:32] <jussi> trying to overwrite '/usr/lib/libakonadi-xml.so.4', which is also in package kdepim-runtime 4:4.11.2-0ubuntu1
[06:33] <jussi> I blame... shadeslayer :P :P :P 
[06:48] <kubotu> ::qt-bugs:: [1242633] unity pointer barriers sru bug @ https://bugs.launchpad.net/bugs/1242633 (by Maarten Lankhorst)
[06:49] <valorie> ahoneybun: yes, I love those special bits of mediawiki
[06:49] <valorie> they won't show up on our website like that or in the ISO docs though
[06:49] <valorie> I wonder now if we need to worry about mini-docs now?
[07:33] <jussi> yay, I mad a darktheme for KDE... similar to my Quassel darktheme
[07:34] <jussi> s/mad/made/
[07:34] <kubotu> jussi meant: "yay, I made a darktheme for KDE... similar to my Quassel darktheme"
[07:49] <valorie> pics or it didn't happen, jussi
[07:50] <jussi> hrm
[07:50] <jussi> I wonder what I can screenshot here...
[07:52] <jussi> http://i.imgur.com/bQMgxHB.png
[07:52] <jussi> valorie: ^^
[07:52] <jussi> Im still going to change hilight colour to green though
[08:02] <valorie> beautiful!
[08:02] <valorie> what will you call it?
[08:02] <jussi> http://i.imgur.com/8ylWZUv.png
[08:02] <jussi> jussi01-darktheme of course :D
[08:02] <valorie> lol
[08:04] <jussi> its a derivative of darktranslucent, but enough changes to really make it mine
[08:04] <jussi> Most dark theme authors forget the value of beige text for your eyes
[08:07] <valorie> how about something like Green Roast?
[08:12] <jussi> green roast? 
[08:14] <valorie> just a suggestion
[08:20] <jussi> what is/was green roast? 
[08:20] <jussi> name suggestion?
[08:21] <jussi> if so, jussi01-darktheme is the name of my quassel theme, and many users use it, so I aim to capitalise on that publicity :)
[08:24] <valorie> ah, ok
[08:24] <jussi> mrgh, something is broken with the system settings uploader to opendesktop.org - I cant loigin
[08:24] <valorie> yes, it was based on coffee roasting
[08:49] <kubotu> ::qt-bugs:: [1242633] unity pointer barriers sru bug @ https://bugs.launchpad.net/bugs/1242633 (by Maarten Lankhorst)
[09:30] <soee> good morning
[10:21] <jussi> valorie: and others: I blogged about it: http://jussi01.com/
[10:22] <jussi> or more precisely: http://jussi01.com/2013/12/19/themeing-kde/
[10:22] <valorie> very cool
[10:23] <valorie> did you see what I said to you the other day about getting a "merch" link on our main page?
[10:23] <valorie> or at least "support us" page
[10:23] <valorie> someone was asking in #kde and I saw it too late to point hir to holvi
[10:23] <valorie> i mean in #kubuntu
[10:24] <jussi> I did...
[10:24] <valorie> ok
[10:24] <jussi> but
[10:24] <valorie> just a suggestion
[10:24] <jussi> 2 things. no merch just now
[10:24] <jussi> and
[10:25] <jussi> I am not the official store...
[10:25] <valorie> BUT you support us
[10:25] <valorie> do we need an "official" store?
[10:25] <jussi> I dunno, talk to other ppls
[10:25] <valorie> after all, what we used to have was Canonical
[10:25] <valorie> and I bought from them, even though shipping was more than the merch
[10:27] <valorie> ok, I'm gonna address a few xmas cards and go to bed
[10:27] <valorie> suuuuper late this year, but oh well!
[10:28] <valorie> have a great day, jussi
[10:28] <jussi> nini
[10:43] <apachelogger> Riddell, yofel, shadeslayer: https://trello.com/c/62KBP9Ml
[10:43] <apachelogger> jussi: what's with the activity explaining acitivites btw
[10:44] <jussi> apachelogger: totally forgotten, Ill try get it done soon
[10:44] <apachelogger> no rush, just reminding you ;)
[10:44] <apachelogger> feature freeze is in two months
[10:44] <apachelogger> that is less than what it sounds like ^^
[10:45] <apachelogger> shadeslayer: https://trello.com/c/8Mj71DBy isn't that in progress?
[10:49] <jussi> apachelogger: could you test a small bug for me? Make a modification to a colour theme, then save, then try to upload? The uploader there doesnt seem to let me log into opendesktop...
[10:53] <apachelogger> jussi: kcmshell4 kcm_attica?
[10:53] <jussi> apachelogger: huh?
[10:53] <apachelogger> do you have the correct data in there
[10:54] <apachelogger> dat upload thing is broken
[10:54] <apachelogger> if I select an existing theme and don't apply it the button is enabled, if I apply it I can't, if I change it then I still can't
[10:54] <jussi> heh
[10:55] <apachelogger> you only get to upload existing schemes it appears
[10:55] <apachelogger> jussi: yeah, login is busted as well
[10:55] <jussi> I when I run kcmshell4 kcm_attica from cli, and I put details and click test login, it sjut sits for ages on testing login
[10:55] <jussi> ok, nice to hear it isnt just me.
[10:55] <apachelogger> broken unmaintained terrible
[10:56] <jussi> :/
[10:56] <apachelogger> this is why we can't have nice things, they go unmaintained and break and no one cares :'(
[10:56] <jussi> make shadeslayer fix it :P :P :P :P
[10:56]  * jussi hugs shadeslayer
[10:56] <apachelogger> hardly worth it TBH
[10:56] <jussi> why? 
[10:56] <apachelogger> that thing is going away (hopefully)
[10:57] <jussi> oh yeah... bodega
[10:57] <apachelogger> all hail bodega!
[10:57] <apachelogger> (I totally see that getting over adopted and then break as well though :P)
[10:57] <apachelogger> it's the cycle of software
[10:58] <apachelogger> invent stuff:adopt it everywhere:realize that you went too far:scared to fix the bugs you caused in the process:hide under rock :P
[10:58] <apachelogger> jussi: anywaysies, bugs.kde.org is your friend
[11:00] <jussi> yup
[11:01] <apachelogger> valorie, ahoneybun: https://help.ubuntu.com/community/Repositories/Kubuntu is terrifingly irrelevant for current Kubuntus (page is still talking about packagekit :S)
[11:02] <apachelogger> maybe someone could have a look at it
[11:03] <jussi> apachelogger: bug exists: Bug 327756
[11:03] <jussi> bah
[11:03] <jussi> kde Bug 327756
[11:04] <apachelogger> jussi: note the hide under rock step in the cycle of software :P
[11:04] <jussi> apachelogger: if you has rights, you could mark it confirmed for me...
[11:04] <apachelogger> curious that it would only get reported a month ago
[11:05] <apachelogger> (not that confirmation does anything for getting it actually fixed :P)
[11:06] <jussi> still...
[11:09]  * apachelogger returns to frameworks
[11:11] <jussi> thanks apachelogger
[11:37] <xnox> apachelogger: you around?
[11:39] <xnox> apachelogger: i've updated bug 1262273. as you can see the bug only affects a very specilies build-environment as produced by dpkg-buildpackage in ppa builders, and in no way affects direct compilation (e.g. ./debian/rules build). unmodified build-log attached with affected cmake upload.
[11:39] <xnox> apachelogger: thus it's quite an exaggeration that any upstream changes are required, or "don't work on kubuntu" or "don't work on trusty"
[11:40] <xnox> apachelogger: also please do not refer to "trusty" as 14.04 externally, as a release gets named 14.04 only at release time to signify that it is now stable. to avoid any confusion, we are always careful to refer to development releases by their codename.
[11:41] <xnox> apachelogger: so the bug your reported is nothing more than: a daily build failure, of daily experimental upstream snapshot, against a daily experimental snapshot of an unreleased distribution.
[11:42] <xnox> apachelogger: at the least it's a packaging bug in project-neon, at most it's a distribution bug report (affecting only package builds, on multiarch systems, with multiarch enabled, and build environment suggesting that multiarch is available, and a non-mutliarch qt used)
[11:42] <xnox> apachelogger: thus it's entirely inappropriate to get any upstreams involved, as there is no upstream bugs, neither in their code / buildsystems or build instructions.
[11:44] <xnox> apachelogger: i do appologise if I didn't convey the scope of the bug in question to you, but I thought that you did read the cmake upload diff to realise that it has been carefully guarded to not affect 3rd-party non-debian package builds in any way, shape or form.
[11:44] <xnox> apachelogger: whilst at the same time, saving packagers from adding un-necessory boilerplate to enable cross-compilation.
[11:45] <xnox> if it's not evident, no packaging changes required is the driving force behind the cmake upload.
[11:45] <xnox> apachelogger: anyway, i've added more guards in cmake toolchain changes to accomodate for the use-case you have shown.
[11:46] <xnox> apachelogger: the cmake changes planning was discussed at the vUDS with blueprints scheduled and with email announcements made to ubuntu-devel mailing list.
[11:46] <xnox> apachelogger: so if you do spot further differences, or unintentional exposure of implementation details, please report bugs to ubuntu distribution via launchpad.
[11:47] <xnox> apachelogger: instead of sending scary emails to upstreams, which typically do not follow bleeding edge developments of all the distributions out there.
[12:11] <xnox> apachelogger: Quintasan: please add me to ~neon
[12:11] <apachelogger> xnox: thanks for handling it and sorry for the miscommunication, I got the impression that KDE should in general use toolchain files (i.e. present workflow) otherwise I'd not have carried this upstream
[12:12] <xnox> apachelogger: i'm sorry, if i miscommunicated that to you.
[12:12] <apachelogger> ah, well, I should have asked. it's really my fault
[12:14] <xnox> apachelogger: i was talking about toolchain files, in the context, what is the cmake provided facility to force by-pass system-libraries and use your own locations/toolchains/etc. I think project neon should be using a toolchain file, given how it needs to mix & match system and non-system libraries/toolchain. KDE shouldn't in general use toolchain files =) end-distributors (e.g. neon, ubuntu, embedded developers) should use them.
[12:15] <xnox> apachelogger: if KDE starts enforcing their own toolchain file it will break cross-compilation for everybody, unless KDE started building qt & cross-compilers & redistributing those binaries =)))) 
[12:15] <apachelogger> xnox: right, the reason neon doesn't use toolchain files is because we wanted to stay as close to the upstream instructions such that it can act as compliance validation
[12:16] <xnox> apachelogger: sure, and cmake changes did not intend to affect that.
[12:16] <xnox> apachelogger: unfortunately my auto-detection did key-on DEB_BUILD_MULTIARCH environment variables, which are exported during dpkg/multiarch cross-builds. i did not expect that dpkg-buildpackages started to export those by default on any multiarch systems.
[12:18] <xnox> apachelogger: you can get /closer/ to upstream instructions by doing: unexport DEB_*, in the debian/rules or makefiles included thereof. Where the variable names are all those that are listed by dpkg-architecture.
[12:18] <xnox> apachelogger: unless of course you want to start supporting multiarch install locations.
[12:18] <xnox> apachelogger: why do KDE instructions not use, e.g. qtchooser?
[12:18] <xnox> to select the right QT ?
[12:18] <apachelogger> yofel: do we want multiarch?
[12:19] <apachelogger> xnox: I don't really think multiarch would be a target for neon at any point, as it's not supposed to be a complete replacement for the packaged KDE
[12:19] <xnox> apachelogger: i'm not sure how multiarch is suppose to work for installations into /opt/ though =) as far as I know it's only defined for /usr/ prefix at the momnet.
[12:21] <xnox> apachelogger: yeah, hence your claims in the email to upstream was widely exagerated. As automoc works complete fine with disto cmake & disto or non-distro qt. The bug really is limited to how neon is build and what it is for.
[12:21] <apachelogger> as for qtchooser ... I don't know, you don't really need to qtchoose if you have PATH set accordingly ... i.e. upstream's instructions basically will install to ~/ and adjust all envrionment variables this world has ever seen to look in ~ first
[12:21] <xnox> apachelogger: fair enough. and one might in that case have no control over system qtchooser.
[12:22] <apachelogger> exactly
[12:53] <apachelogger> Riddell: you know, packaging the frameworks is quite a bit of work
[12:53] <apachelogger> I would make that very low priority in terms of 14.04 todos since we target PPA deployment anyway
[13:20] <BluesKaj> Howsy all
[13:21] <BluesKaj> need coffee!
[13:24] <yofel> apachelogger: I don't think so, too much of a hassle for the current use case 
[14:03] <apachelogger> !find SMlib.h
[14:06] <apachelogger> !find jpeglib.h
[14:09] <skaet_> Riddell, ScottK - what's you're thoughts releasing alpha 1 today?   I'm seeing the release notes looking good, but not seeing the iso tracker updated or any specific bugs marked as blockers.   Just missing testing results being added to the iso tracker, or something more serious?
[14:18] <apachelogger> xnox: http://lists.kde.org/?l=kde-buildsystem&m=138746258019223&w=2 thoughts?
[14:19] <apachelogger> skaet_: it may be that no one tested yet
[14:19] <apachelogger> also Riddell is missing apprently
[14:20] <apachelogger> skaet_: I'll do a test run in a bit
[14:21] <xnox> apachelogger: i have very little context.
[14:22] <apachelogger> xnox: I don't have any more to be honest
[14:24] <apachelogger> xnox: I really think it would be good if you could subscribe to kde-buildsystem and have a discussion with them
[14:24] <apachelogger> xnox: http://lists.kde.org/?l=kde-buildsystem&m=138746278419271&w=2 "And why doesn't it also do the same with uic?" that's actually a good question
[14:27] <xnox> apachelogger: the changes are staged, and are not complete, and there is a bootstrap required on qt packaging, qmake, and cmake.
[14:27] <xnox> apachelogger: and only partial changes have been done in the archive so var.
[14:28] <xnox> apachelogger: and hence the complete goal and solution is not ready yet, and all the suggestions in that email are wrong, and don't understand the full scope here.
[14:29] <xnox> apachelogger: in particular what multi-arch is, how qt5 is in progress of being packaged to accomodate it, and how cross-compilation of distribution works in the multi-arch distributions.
[14:29] <xnox> apachelogger: some of the relevant changes will be fed back to affected upstreams - qmake, qt5 and cmake.
[14:29] <apachelogger> xnox: yeah, I am just saying ... kde-buildsystem is doing cmake foo since forever so they may be able to help with getting the best solution in the end
[14:29] <xnox> apachelogger: but none of it is of any concert of kde upstream.... despite the overlap and using same reverse dependenices.
[14:30] <xnox> apachelogger: sure, noted.
[14:30] <xnox> apachelogger: it's just i haven't finishing writting al the patches yet, to fully scope the problem here.
[14:30] <apachelogger> I see
[14:30] <xnox> apachelogger: so, again, on my own schedule it will be presented in time. i'm still prototyping, what i want to achieve and there are plenty of things to fix still.
[14:32] <xnox> apachelogger: also claims by stephen keelly and yourself are wrong in those replies as well.
[14:33] <xnox> apachelogger: if you have questions, ask me, i can explain them to you.
[14:33] <apachelogger> *shrug*
[14:33] <apachelogger> I am playing middleman :P
[14:33] <apachelogger> hence why I think you shoudl sub to the list
[14:34] <manchicken> apachelogger: It looks like only two of my changes were binary incompatible.
[14:35] <manchicken> apachelogger: I added a constructor to QApt::SourcesList which allows you to specify an arbitrary sources file, and I just added it to the existing constructor.
[14:36] <manchicken> The thing is, I think that overloading a constructor which previously wasn't overloaded will also break binary compatibility, no?
[14:36] <apachelogger> nope
[14:36] <manchicken> Oh, cool.
[14:36] <apachelogger> maybe in a non-leaf virtual class
[14:36] <manchicken> So then I'll just create a new constructor which allows the files.
[14:36] <apachelogger> yep
[14:37] <manchicken> That's cool, I thought I was going to have to move where it pulled the default files in, so this is cool.
[14:37] <manchicken> I'm probably not going to make the changes for the d-pointer alerts in krazy2 for the rest of the library in order to avoid breaking compatibility.
[14:38] <manchicken> The abi-compatibility-checker gave me what looked like useful results, so that's good.
[14:38] <xnox> apachelogger: there is still not enough context.
[14:38] <xnox> apachelogger: you seemed to have replied to an off-the-list  or other list email message?
[14:38] <xnox> apachelogger: where is the original email from Stephen Kelly, to which you are replying? http://mail.kde.org/pipermail/kde-buildsystem/2013-December/009516.html
[14:39] <manchicken> The warning about gcc 4.8 seemed a little worrying, but I'm not sure if it indicates a less-than-useful result. I'm debating on installing a different version of gcc in my home directory and then running this off of that.
[14:39] <apachelogger> xnox: http://lists.kde.org/?l=kde-core-devel&m=138745926018113&w=2
[14:39] <apachelogger> thread http://lists.kde.org/?t=138738660500006&r=1&w=2
[14:40] <xnox> apachelogger: i'm very busy at the moment. i'll do those replies later.
[14:40] <apachelogger> skaet_: what's the minimum amount of ISO tests we want to be done?
[14:41] <apachelogger> or, which tests rather
[14:41] <manchicken> I wonder if there's anybody who is working on an apt hacker's guide. Currently the apt documentation is pretty weak.
[14:41] <apachelogger> manchicken: I don't think so, JT simply asked the apt people directly
[14:41] <manchicken> libapt seems somewhat important.
[14:42] <apachelogger> well, it's hard to blame them for not documenting stuff... it's not like a lot of people will use libapt directly
[14:43] <manchicken> Yeah, I agree.
[14:43] <manchicken> I'm thinking of doing more tests and docs for libqapt once I get these changes done.
[14:44] <manchicken> But then again, I also need to get back to the original task of getting kubuntu-debug-installer doing what we wanted it to do.
[14:46] <apachelogger> "Use and execute the default applications found for the desktop enviroment being run"
[14:46] <apachelogger> why that's a silly test
[14:46] <apachelogger> manchicken: ultimately before feb 20 (feature freeze) ;)
[14:47] <manchicken> That's good to know.
[14:47] <skaet_> apachelogger,  making sure the images are booting.   The tests listed on the iso tracker are the ones defined as a minimum, so its up to the project's discretion if they are going to wave some.
[14:47] <manchicken> Assuming the code passes the RB, how fast does that get to someone who would then package it?
[14:48] <manchicken> The changes to kubuntu-debug-installer would depend on those changes to libqapt.
[14:49] <apachelogger> manchicken: depends on when someone creates a release
[14:49] <apachelogger> or we could patch it into the packaging
[14:49] <apachelogger> that really shouldn't be a blocking problem
[14:49] <manchicken> Who would do that if JonT isn't?
[14:50] <apachelogger> anyone really
[15:03] <Riddell> ahem, afternoon
[15:04] <Riddell> skaet_: if I'm not too late to the party I can crack on with testing now
[15:05] <apachelogger> Riddell: i386 needs testing, I am on amd64
[15:07]  * Riddell makes it sew
[15:11] <apachelogger> jolla shop is open
[15:11] <apachelogger> omg
[15:12] <Riddell> what's for sale?
[15:12] <jussi> jolla phones...
[15:12] <apachelogger> are they any good?
[15:12] <apachelogger> been wondering about getting a new phone
[15:13] <jussi> apachelogger: they are decent, still some bugs, but much better than the meego products
[15:13] <jussi> #jollamobile is the chnnel
[15:14] <jussi> I had a play with one recently, phone is ok... bit boring. OS is "decent"
[15:14] <apachelogger> boring?
[15:14] <jussi> you can load sailfish onto n9 or n950 for a semi ok idea of how it works....
[15:14] <Riddell> does it run kde apps?
[15:15] <Riddell> is it waterproof? because I only really want a phone which is waterproof
[15:15] <jussi> apachelogger: its a pretty bog standard android type phone. nothing special in the hw, but not bad either
[15:15] <apachelogger> smartphones aren't waterproof
[15:15] <jussi> Riddell: sony for you myfriend
[15:15] <jussi> sony has one
[15:15] <apachelogger> sony products do not convince :P
[15:15] <apachelogger> ask Riddell :P
[15:15] <jussi> http://www.sonymobile.com/global-en/products/phones/xperia-zr/
[15:16] <apachelogger> jussi: why does a phone need fancy hardware though? 
[15:16] <Riddell> apachelogger: tried using your N900?  that was underpowered hardware
[15:17] <apachelogger> how did one notice that?
[15:17] <apachelogger> because I didn't
[15:17] <apachelogger> Riddell: do we want oem install tested?
[15:17] <Riddell> apachelogger: sure
[15:18] <Riddell> usually I test that along with the first install I do
[15:18] <apachelogger> I totally find that over the top for alpha1
[15:18] <apachelogger> can't test autoresize btw
[15:18] <apachelogger> somehow it doesn't want to reszie an existing kubuntu installation
[15:19] <apachelogger> the tests are really inaccurate btw
[15:20] <Riddell> if it's not working best we know it now rather than one beta 1 release day
[15:21] <Riddell> use virtualbox for resize, or a handy spare netbook you keep for such occations
[15:21] <Riddell> inaccurate in what way?
[15:21] <ghostcube> hi folks updating from 13.10 to 14.04 alpha getting this at first libharfbuzz0b:i386 conflicts with libharfbuzz0a:amd64  and libharfbuzz0b:i386 conflicts with libharfbuzz0a:i386 just for info
[15:22] <apachelogger> Riddell: strings are all different for example
[15:22] <apachelogger> oem install started, taking the dog for a walk meanwhile
[15:23] <Riddell> i386 doesn't boot on this secureboot windows 8 computer I have, so I maintain we should follow ubuntu in recommending amd64
[15:25] <ghostcube> update in virtualbox is still running for amd64 will tell you if its done and if it works so far 
[15:26] <BluesKaj> don't suppose the alpha release will as such with lsb_release -a ?
[15:26] <BluesKaj> show
[15:27] <kubotu> ::workspace-bugs:: [1262700] KWin major memory leak @ https://bugs.launchpad.net/bugs/1262700 (by Falk Ahlendorf)
[15:27] <Riddell> it'll show Description:    Ubuntu Trusty Tahr (development branch)
[15:27] <Riddell> BluesKaj: so yes it will
[15:28] <BluesKaj> yeah, Riddell , that's what shows here , altho I haven't install alpha d]
[15:28] <BluesKaj> since I reinstalled the daily on tue
[15:28] <Riddell> oh right, no it won't be different from that
[15:29] <BluesKaj> so if dist-upgrade I'll have the alpha ?
[15:31] <BluesKaj> find it a bit confusing 
[15:32] <Riddell> yes
[15:32] <Riddell> an alpha is just a daily snapshot we've tested
[15:32] <BluesKaj> ok thanks
[15:32] <Riddell> which is why we need people to test and install it
[15:32] <Riddell> also test upgrade from saucy
[15:33] <BluesKaj> I have saucy as my back up "stable OS" on another partition :) 
[15:33] <skaet_> Riddell,  crack on with the testing please.    :-)   Steve's pushing the buttons on publishing today, so there is a window.
[15:36] <Riddell> hi Sick_Rimmit, alpha 1 candidate testing needed!
[15:37] <BluesKaj> actually , i'm running 14.04 on 2 machines , desktop and laptop , both are up to date
[15:38] <Riddell> then you can afford to run kubuntu-devel-release-upgrade on one of them :)
[15:39] <BluesKaj> no real problems so far, a small problem with the digital clock showing UTC as default time zome
[15:39] <BluesKaj> zone
[15:40] <BluesKaj> easily fixed by unchecking it in sttings
[15:42] <BluesKaj> still not used to this laptop KB , a bit small for these large phingers :)
[15:52] <Riddell> hmm, our default kwallet now asks for a gpg key to set up
[15:52] <Riddell> which isn't available on a fresh install
[16:02] <apachelogger> Riddell: is the ubiquity oem window supposed to not be fullscreen?
[16:02] <Riddell> apachelogger: preferably not but that's not a new issue
[16:02] <apachelogger> ok
[16:04] <apachelogger> Riddell: all done except for resize I simply don't get the resize option
[16:06] <Riddell> okay dokay, I'll try that on a virtualbox
[16:06] <Riddell> needs to be a large disk
[16:07] <Riddell> apachelogger: ug I just tried oem on i386 and it crashed
[16:07] <Riddell> apachelogger: yours completed ok?
[16:08] <apachelogger> yeah
[16:08] <apachelogger> Riddell: where did it crash?
[16:09] <Riddell> apachelogger: at the end of the oem setup tool after the second reboot
[16:09] <apachelogger> nope, loged successfully in
[16:09] <Riddell> lucky you
[16:10] <apachelogger> but while the config was going on the next button was active, so I clicked it
[16:10] <apachelogger> maybe that prevented the crash
[16:46] <Riddell> well uefi/secureboot/windows8 machine installs fine and all is good in kubuntu but the grub entry for windows doesn't work
[16:46] <Riddell> but that's the same for ubuntu desktop
[16:48] <Riddell> oops I made unity crash
[16:52] <manchicken> I had to play games to get Kubuntu to dual boot, I had to make Grub the default loader. I thought Windows 8 was supposed to have a boot loader that would play nice, but it doesn't.
[16:54] <Riddell> make Grub the default loader where, how?
[16:55] <manchicken> When I did it I had to it twice. I'm on an ASUS 11" touchscreen lappy.
[16:55] <manchicken> I can't remember what I had to do, but it wasn't fun.
[16:57] <manchicken> abi-compliance-checker may turn out to be a real life saver.
[16:57] <manchicken> Assuming its output is trustworthy.
[16:58] <Riddell> why not just compile a debian package?  that'll tell you if it has new symbols
[16:59] <manchicken_> I have new symbols, that was intended.
[16:59] <Riddell> new is fine
[16:59] <Riddell> missing is a problem (not a big one you can just change the soname version)
[17:00] <manchicken_> The verdict is that my version of libqapt (2.1.1-provisionally-labeled) is binary compatible with 2.0.65.
[17:00] <Riddell> infact if it's a hassle to care I'd say just change the soname version, it's not like we have many things to recompile
[17:01] <manchicken_> Well when I ran it the first time, the only thing that had to be fixed was that I modified the default constructor.
[17:01] <manchicken_> I just changed it so that I left the default constructor alone and then overloaded it with a second constructor using the functionality I wanted.
[17:02] <manchicken_> Fixed that one thing and now it's supposedly compatible :)
[17:03] <manchicken_> Changes pushed.
[17:03] <manchicken_> (to my github)
[17:17] <manchicken_> Well, I can't really think of anything else to do... so I'm going to go ahead and package this up for the RB tonight.
[17:17] <Riddell> RB?
[17:17] <manchicken_> KDE Review Board
[17:30] <Quintasan> ovidu-florin, ping 
[17:42] <ghostcube> booting 14.04 after update from 13.10 in virtualbox now.  got some probs while updating and had to run apt-get - f install and apt-get update && upgrade but kde comes up as it seems
[17:46] <Riddell> shadeslayer: pong
[17:56] <ghostcube> update worked 14.04 alpha up and running
[17:56] <Riddell> apachelogger: I've reported bug 1262779
[17:56] <ghostcube> nice job so far
[17:56] <Riddell> ghostcube: you upgraded from saucy?
[17:57] <ghostcube> yes
[18:46] <xnox> apachelogger: somehow i failed all the subscription loops and hoops, so my email reply is held for moderation =/
[18:47] <xnox> apachelogger: at least all the CCed should arrive to recepients.
[20:15]  * genii celebrates with a coffee
[20:16] <Riddell> whee
[20:16] <soee> *weed 
[20:16] <Quintasan> Do I hear iso testing?
[20:17]  * Quintasan grabs an ISO
[20:24] <Riddell> how's this? https://help.ubuntu.com/community/TrustyUpgrades/Kubuntu
[20:27] <Riddell> skaet_: apachelogger: I put the newer simpler header on https://wiki.kubuntu.org/TrustyTahr/Alpha1/Kubuntu
[21:36] <ahoneybun> Riddell valorie lordievader https://files.one.ubuntu.com/Zgy1cSgqRs62iZIGJE7pAg/
[21:38] <Riddell> "Could not locate object"
[22:20] <Riddell> whee, 4.12 going into trusty
[22:37] <soee__> wasnt it there already ?
[22:48] <Riddell> nope
[22:54] <soee> Trusty isoes were tested ?
[22:56] <kubotu> ::workspace-bugs:: [1262700] KWin major memory leak @ https://bugs.launchpad.net/bugs/1262700 (by Falk Ahlendorf)
[22:57] <Quintasan> soee: We are testing them
[22:58] <soee> Quintasan: iso link please ?
[22:59] <Quintasan> soee: http://cdimage.ubuntu.com/kubuntu/releases/trusty/alpha-1/
[22:59] <soee> Quintasan: thank you
[23:00] <soee> crap using wifi it will take 2h to download :<
[23:52]  * Riddell publishes kubuntu.org/news/kubuntu-1404-alpha-1