[02:24] <ScottK> apachelogger, yofel, shadeslayer: Due to the $release -> $release-proposed mapping used for the development release now, you can do it for any release.  Just upload to $release and it'll end up in the right place.  The only time you should need to specify is if you are uploading to $release-backports.
[04:07] <ScottK> apachelogger or afiestas: Suggestions on troubleshooting this: http://kitterman.com/kubuntu/one_battery.jpeg - as you can see from the konsole window in the back, solid knows about the correct state of both batteries, but only battery two shows up in the battery monitor?  (first I had to get upower fixed to register both batteries - that's done - now on to KDE ...) 
[05:33] <ScottK> Can someone please verify the kubuntu-docs SRU?
[06:07] <soee> goo morning
[06:07] <soee> *good
[06:19] <jussi> hrrr, not liking the new style of takin away toolbars and putting random dropdown boxes in (ie. muon) :/
[07:18] <yossarianuk> Hi - the issue with the workaround for kubuntu 13.10 UEFI issue is if you dual boot ubuntu with kubuntu....
[07:19] <yossarianuk> then you get multiple UEFI entries that all load ubuntu by default
[07:19] <yossarianuk> you can select 'ubuntu 13.10' further down the list to load kubuntu....
[07:19] <yossarianuk> (in grub)
[07:38] <valorie> yossarianuk: isn't that delightful
[07:38] <valorie> maybe our geniuses here can fix the ubuntu-uefi genius work
[07:38] <valorie> sheesh
[07:43] <yossarianuk> I only installed ubuntu just to see if it did conflict - it did..
[07:43] <yossarianuk> and I like to see how unity is coming on....
[07:43] <yossarianuk> I'd say its like self harm at present.
[07:44] <yossarianuk> every time you look for an application you spam yourself.
[07:45] <yossarianuk> it really is a joke - I search for terminal in unity - dash found some italian jazz.
[07:45] <yossarianuk> or something similar.
[07:46] <yossarianuk> (not that there is anything wrong with italian jazz - I just have no interest in seeing it when seraching for a terminal emulator.
[07:47] <valorie> woah
[07:48] <lordievader> yossarianuk: Did shadeslayer's fix work?
[07:48] <valorie> I'll have to admit, i've not had enough interest to play with unity
[07:48] <yossarianuk> lordievader: I did try and it seemed to do the same...
[07:49] <lordievader> valorie: I did, it's annoying and now I get Unity/gtk errors when I login to my Kubu desktop...
[07:49] <lordievader> yossarianuk: Hmm, too bad :(
[07:49] <yossarianuk> however it is possible I did not apply the updates correctly...
[07:49] <yossarianuk> I loaded live cd
[07:49] <yossarianuk> i used - dpkg -l |grep grub
[07:49] <yossarianuk> then updated all grub packages install from the PPA
[07:50] <yossarianuk> however when you access the livecd - pre install you do not have gru2-efi*
[07:50] <yossarianuk> grub-efi-*
[07:50] <yossarianuk> you only have grub-pc.
[07:50] <yossarianuk> (until you install)
[07:50] <yossarianuk> what should I have done.
[07:50] <yossarianuk> (p.s I'm happy to re-try again tonight...)
[08:01] <yofel> yossarianuk: some talk you missed: http://irclogs.ubuntu.com/2013/10/22/%23kubuntu-devel.html#t16:28
[08:03] <yossarianuk> yofel: ah so that was never going to work...
[08:03] <yossarianuk> well I have a running system now... So I could remove all existing efi folders (and UEFI entries) and try the new packages ?
[08:04] <yossarianuk> ---> will have to wait till lunchtime (uk) as i'm (meant to be) working...
[08:04] <yossarianuk> would doing this help :
[08:05] <yossarianuk> yofel: yes I did miss that (that convo occured between me being logged in @ work and home..)
[09:09] <shadeslayer> yossarianuk: okay so 
[09:09] <shadeslayer> yossarianuk: apparently there was some miscommunication
[09:09] <shadeslayer> yossarianuk: the fix will work if you chroot into your kubuntu install and upgrade
[09:09] <shadeslayer> if that works, we can deploy it
[09:10] <yossarianuk> is it worth me trying from an existing install ?
[09:10] <yossarianuk> i.e remove all UEFI entries and EFI folders first ?
[09:11] <yossarianuk> (wouldn't that essentially be the same as chrooting?)
[09:11] <yossarianuk> (p.s there is no issue doing a reinstall this afternoon...)
[09:12] <yossarianuk> (i'm off work revising for LPIC exams...)
[09:12] <shadeslayer> yossarianuk: there are test cases on https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1242417
[09:12] <shadeslayer> you can test anyone of them
[09:14] <yossarianuk> i'll do a new install (with chroot) later..
[09:15] <yossarianuk> (will remove existing uefi entries and wipe efi partition also..)
[09:15] <yossarianuk> so - just do a normal install - then
[09:17] <yossarianuk>  # mount -t proc none /mnt/chroot/proc
[09:18] <yossarianuk> mount --rbind /sys /mnt/chroot/sys
[09:18] <yossarianuk> mount /dev/sda1 / /mnt/chroot/boot/efi
[09:18] <yossarianuk> mount --rbind /dev /mnt/chroot/dev
[09:18] <yossarianuk> then chroot
[09:18] <yossarianuk> install ppa 
[09:18] <yossarianuk> then adist-upgrade ?
[09:32] <yossarianuk> shadeslayer: was the process I outlined correct ?
[09:36] <shadeslayer> yossarianuk: sounds about right
[09:38] <yossarianuk> groovey !
[09:44] <shadeslayer> yossarianuk: ofcourse, mount commands will probably vary according to where you install stuff :)
[09:44] <shadeslayer> you also don't seem to mount /
[09:44] <yossarianuk> yes... sorry root in the example was mounted to /mnt/chroot..
[09:45] <shadeslayer> okay
[09:45] <yossarianuk> (I also have a seperate boot which I didn't mention..)
[09:45] <shadeslayer> the important bit is ofcourse /boot
[09:46] <yossarianuk> For about 2 years I used Gentoo as my main desktop so I know what i'm doing with the chroot but (just wanted to make sure I was on the right track for the test.)
[09:46] <yossarianuk> final straw for gentoo was a kde update.....
[09:46] <shadeslayer> heh
[09:47] <yossarianuk> I was also running arch (still do) it took about 15 mins to install latest KDE - on gentoo I think it took about 3 hrs (and wasn;t really any faster)
[09:48]  * shadeslayer wonders what to do
[09:49] <shadeslayer> yossarianuk: any other bugs I should look at ?
[09:51] <yossarianuk> shadeslayer: not that I know of 
[09:51] <shadeslayer> cool
[09:51]  * shadeslayer processes SRU cards
[09:51] <yossarianuk> well - perhaps the 'bug' where ubuntu+others don't have the latest nvidia driver .... But that isn;t a bug as such...
[09:52] <yossarianuk> ps - i'll msg you my email (in case you realise anything before I test later today)
[09:52] <shadeslayer> ack
[09:53] <shadeslayer> I already have it from the email yesterday
[09:53] <yossarianuk> ah yes.
[09:53] <yossarianuk> apart form the UEFI issue Kubuntu 13.10 seems pretty solid...
[09:53] <yossarianuk> liking the fact I have openGL 3.1 shaders...
[09:54] <yossarianuk> (nvidia has had opengl 4.x support for some time...)
[09:54] <yossarianuk> and it just seems that tiny bit snappier than previous releases,
[09:55] <shadeslayer> that you'd have to take up with the ubuntu-x team
[10:17] <kubotu> ::runtime-bugs:: [1243620] Languages not displayed correctly in "language control module": German and English are emp... @ https://bugs.launchpad.net/bugs/1243620 (by Daniel Hahler)
[10:32] <afiestas> ScottK: can you report a bug with all that info pls?
[10:43] <ScottK> afiestas: Will do.
[10:43] <ScottK> afiestas: What do I report it against?
[10:43] <afiestas> solid/powermanagement 
[10:57] <ScottK> afiestas: KDE bug 326491
[11:08] <shadeslayer> bah http://pastebin.kde.org/pc9lneeu2
[11:11]  * apachelogger doesn't think he'll get to do much today - feeling not so good
[11:12] <apachelogger> ScottK: thanks for clearifying the pocket mapping
[11:12]  * Riddell fluffles apachelogger 
[11:13]  * apachelogger huggles Riddell
[11:29] <Riddell> highvoltage: we've just been offered hosting for a try out of kubuntu through a browser type setup which edubuntu used to have, does it still have it and can you say if it's a useful thing to have?
[11:30] <highvoltage> Riddell: our users liked it.
[11:30] <highvoltage> Riddell: it's been offline for a bit because some code needs updating (I think stgraber was planning to do it after 13.10 release, which is now)
[11:31] <highvoltage> Riddell: since it's been down we've had lots of requests for it and offers to get it up and running again (mpostmostly for hosting as apposed to fixing code)
[11:32] <Riddell> highvoltage: yeah that's a worry, it feels like quite3 a developer drain
[11:32] <Riddell> highvoltage: what technologies did it use?
[11:32] <highvoltage> Riddell: x2go / nx
[11:33] <highvoltage> Riddell: once stgraber has it up to date again it shouldn't be much work for kubuntu to try. perhaps a proof of concept to try it out might be a good idea just to gauge how much work and effort it is and whether it's worth it.
[11:42] <kubotu> ::workspace-bugs:: [1201180] Pressing power button turns off the PC ignoring the presence of another session manager @ https://bugs.launchpad.net/bugs/1201180 (by Marco Trevisan (Treviño))
[12:00]  * Riddell blogs http://blogs.kde.org/2013/10/23/linus-comes-edinburgh
[12:10] <BluesKaj> Hiyas all
[12:25] <soee> Riddell, you are looking or some servers ?
[12:26] <shadeslayer> cyphermox: ping
[12:34] <shadeslayer> cyphermox: any reason why nm wasn't updated?
[12:34] <shadeslayer> ( to 9.0.8.4 )
[12:35] <shadeslayer> or well .. 0.9.8.4
[12:49] <ScottK> apachelogger: You can add KDE Bug 326500 to your Muon list.
[12:58] <shadeslayer> ScottK: apol said he was going to do a 2.1
[12:58] <shadeslayer> soon
[12:59] <ScottK> The updater is almost totally useless as it is.
[13:00] <shadeslayer> I can't check because my system is borked a bit ( polkit issues )
[13:02] <BluesKaj> sed'd to 14.04 , all seems well so far with several libs updates/upgrades so far 
[13:02] <shadeslayer> heh
[13:02] <shadeslayer> I wouldn't jump so soon tbh
[13:03]  * shadeslayer usually waits till various libraries and gcc are updated
[13:05] <BluesKaj> well, It's become a habit with me , but I do have a stable OS on another partition and my data , such as it is residing on an external drive
[13:06] <BluesKaj> my data is mostly media stuff , since I'm a home user 
[13:10] <shadeslayer> ScottK: want to backport the grub fix from trusty?
[13:10] <ScottK> I think apachelogger  was going to do it.
[13:11] <shadeslayer> he is not
[13:11] <shadeslayer> I have it in my PPA
[13:11] <shadeslayer> https://launchpad.net/~rohangarg/+archive/experimental/+files/grub2_2.00-19ubuntu2.1.dsc
[13:11] <shadeslayer> fails on i386 ... I do not know why
[13:12] <Quintasan> hurr
[13:12] <Quintasan> it's either me or new digikam is just about bumping the version
[13:13]  * Quintasan rebuilds and installs
[13:13] <shadeslayer> it's you
[13:13]  * shadeslayer runs
[13:14] <Quintasan> Not so fast
[13:14]  * Quintasan grabs shadeslayer's collar and throws a brick at him
[13:14]  * shadeslayer ducks
[13:14] <Quintasan> kubotu: order whisky for Quintasan 
[13:14]  * kubotu slides whisky down the bar to Quintasan
[13:14] <Quintasan> meh
[13:15] <Quintasan> apachelogger: Where be me whisky bind for kubotu /
[13:15] <Quintasan> ?
[13:16] <jussi> sigh... someone stole my alt tab effect from saucy.... grrrr (or I can figure out how to turn it on)
[13:16] <jussi> can't
[13:16] <shadeslayer> jussi: it's in systemsettings -> Window Behaviour
[13:16] <jussi> shadeslayer: but activating other ones doesnt change anything!
[13:17] <shadeslayer> WFM
[13:18] <jussi> shadeslayer: oh now it works. btw, what the heck is it doing there and not in desktop effects? 
[13:19] <shadeslayer> *shrug*
[13:19] <shadeslayer> it changed places
[13:19] <shadeslayer> like 2 releases ago or sth
[13:20] <jussi> meh
[13:20] <jussi> makes no sense to me
[13:20] <jussi> anyway, still 4 shirts left!
[13:31] <Quintasan> hurr
[13:31] <Quintasan> shadeslayer: Any ideas why pbuilder refuses to create trusty tgz? I have new deboostrap and whatnot
[13:31] <shadeslayer> no idea, I created one yesterday
[13:31] <shadeslayer> worked for me
[13:31] <Quintasan> says unknown distribution: trusty
[13:31] <Quintasan> derp
[13:32] <shadeslayer> just add a symlink
[13:32] <shadeslayer> to gutsy
[13:33] <Quintasan> dumbest thing is that debootstrap trusty ./derp works
[13:33] <Quintasan> wot
[13:33] <Quintasan> it just worked
[13:33] <Quintasan> for some reason
[13:39]  * ScottK made one on Monday.
[13:43] <apol> ScottK: hey, I was looking at https://bugs.kde.org/show_bug.cgi?id=326500
[13:43] <apol> I can't really understand it
[13:44] <apol> is it a problem that muon gets frozen?
[13:52] <shadeslayer> ScottK: fwiw grub2 i386 builds on pbuilder, so something funky with the PPA builder
[13:52] <shadeslayer> it also builds in trusty
[13:54] <apachelogger> apol: go fix the crash instead plz :P
[13:55] <apachelogger> new reviews http://techlorebyigor.blogspot.com/2013/10/kubuntu-1310-is-for-keeps.html http://mylinuxexplore.blogspot.com/2013/10/kubuntu-1310-saucy-salamander-review.html
[13:55] <apachelogger> apol: people seem to like discover btw :)
[13:56] <apachelogger> shadeslayer: seems the PPA killed whatever test was run there
[13:56] <shadeslayer> heh
[13:56] <apachelogger> maybe due to the fact that they are emulated or something
[13:57] <shadeslayer> well, anyway, someone needs to upload grub
[13:57] <shadeslayer> soon
[13:58] <smartboyhw_> shadeslayer: In here we're waiting for the fix to be uploaded to Trusty.
[13:58] <smartboyhw_> Here = Studio
[13:59] <Quintasan> YES
[13:59] <Quintasan> werks
[14:00] <ScottK> apol: No.  It's not frozen.  It does something and then goes back to everything still selected.
[14:01] <ScottK> apachelogger: Wasn't Colin going to SRU grub or was it us?
[14:01] <shadeslayer> apachelogger: fwiw releaseme doesn't work for muon
[14:02] <shadeslayer> something about not being able to fetch the source from svn
[14:02] <apachelogger> ScottK: us
[14:02] <apachelogger> shadeslayer: muon doesn't have source on svn
[14:03] <shadeslayer> really? I didn't notice ...
[14:04] <Quintasan> one does not simply use svn for new projects
[14:08] <ScottK> apachelogger: Can you do that.  If I upload it, I can't accept the SRU.
[14:14] <apachelogger> ScottK: about to leave for doctors appointment, can do in an hour or so
[14:19] <cyphermox> shadeslayer: re NM> no ack from release at the same time as ack from touch release team.... I uploaded 0.9.8.4 to trusty yesterday
[14:20] <shadeslayer> okay
[14:28] <Riddell> cyphermox: 
[14:28] <Riddell> cyphermox: do you think we could do a SRU?  I know the plasma-nm guys would be much happier to know their users are with 0.9.8.4
[14:34] <shadeslayer> aye ^^
[14:35] <Riddell> and we're the first distro to use them so their bug reports have gone up a lot since we released :)
[14:54] <yossarianuk> shadeslayer: emailed you regarding uefi / new gre pkgs
[14:54] <yossarianuk> *grub*
[14:54] <shadeslayer> roger
[14:55] <cyphermox> Riddell: there are some new features. do you think the release team / SRU team would be fine with it as SRU?
[14:55] <shadeslayer> yossarianuk: I don't see a "Upgraded grub" in there
[14:55] <cyphermox> the new feature part is really minimal anyway, it's just some connectivity checking stuff
[14:55] <shadeslayer> grub the package
[14:56] <shadeslayer> cyphermox: I bet if you don't say anything you can sneak it past them ;)]
[14:56] <yossarianuk> sorry - i left out the step
[14:56] <yossarianuk> i.e inside chroot
[14:56] <shadeslayer> yossarianuk: as in left out the step in testing?
[14:56] <shadeslayer> ah
[14:56] <yossarianuk> no - just in the email
[14:56] <yossarianuk> i.e
[14:56] <yossarianuk> in chroot I 'apt-get dist-upgrade'
[14:56] <cyphermox> shadeslayer: not a good plan. Should thinks regress, it's just going to be more painful
[14:56] <yossarianuk> (after adding a nameserver to /etc/resolv.conf)
[14:57] <shadeslayer> yossarianuk: please report your findings here https://bugs.launchpad.net/ubuntu/+source/grub2/+bug/1242417
[14:57] <yossarianuk> will do very shortly 
[14:57] <shadeslayer> thanks!
[14:57] <yossarianuk> np
[14:57] <yossarianuk> i.e I can boot the OS without manually changing theefi folder name
[14:58] <shadeslayer> ideally, just updating the package should work, and then you don't have to do anything
[14:58] <yossarianuk> however there is now a phantom 'ubuntu' entry...
[14:58] <yossarianuk> also
[14:58] <yossarianuk> i'll report to the bug..
[14:58] <shadeslayer> apachelogger: ^^
[14:58] <shadeslayer> yep, that'd be awesome
[14:58] <yossarianuk> its reallt odd - if I delete via efibootmng it comes back on reboot?
[14:59] <yossarianuk> if I delete the kubuntu one that stays deleted.
[14:59] <yossarianuk> they both load kubunut
[14:59] <yossarianuk> *kubuntu*
[14:59] <shadeslayer> no idea, I use refind so I've only rarely dealt with grub-efi
[14:59] <yossarianuk> - although I do not have ubuntu installed yet.
[14:59] <yossarianuk> cool - at least its progress.....
[15:00] <apachelogger> shadeslayer: too much backlog
[15:01] <shadeslayer> apachelogger: grub fix sort of works
[15:05] <apachelogger> sort of?
[15:06] <yossarianuk> it does work
[15:06] <yossarianuk> i.e I could boot without manually copying the /boot/efi/EFI/kubutu foler -> /boot/efi/EFI/ubutu
[15:06] <yossarianuk> (spelt correctly)
[15:07] <yossarianuk> but - it creates another UEFI entry 'ubuntu' also
[15:07] <yossarianuk> that even if I delete via efibootmng - comes back on reboot (which is odd)
[15:07] <yossarianuk> this was from  aclean disk / cleaned UEFI entries.
[15:08] <apachelogger> how did you clean the entires?
[15:08] <yossarianuk> efibootmgr 
[15:08] <yossarianuk> shows 'Boot0008* ubuntu'
[15:08] <yossarianuk> i use
[15:08] <yossarianuk> efibootmgr -b 8 -B
[15:09] <apachelogger> was that present immediately after install?
[15:09] <yossarianuk> efibootmng shows the entry is gone
[15:09] <yossarianuk> yes
[15:09] <apachelogger> may be that your firmware just tries to be smart
[15:09] <apachelogger> yossarianuk: well, I don't trust efibootmgr to be honest: P
[15:09] <yossarianuk> well after the install (after chrooting)
[15:10] <yossarianuk> its fine now  - however may cause issues after installing ubuntu
[15:10] <yossarianuk> its just odd it comes back
[15:10] <yossarianuk> the kubuntu entry doesn't
[15:10] <apachelogger> it won't cause issues
[15:10] <yossarianuk> if I remove the efi folders then remove the entry it doesn;t come back
[15:10] <apachelogger> since the kubuntu entry points to the same loader image
[15:11] <yossarianuk> (but obviously I cannot boot)
[15:11] <yossarianuk> ok thanks
[15:11] <apachelogger> same thign would happen if you installed kubuntu and then on a separate partiton install ubuntu, they'd still point to the same loader
[15:11] <yossarianuk> well at present I only have 1 os - kubuntu
[15:11] <yossarianuk> after install /boot/efi/EFI/ubuntu was also there
[15:11] <apachelogger> why does your boot manager have 9 entires then Oo
[15:11] <yossarianuk> (after install + new grub updates)
[15:12] <Riddell> cyphermox: hmm would be hard but maybe
[15:12] <cyphermox> Riddell: yeah
[15:12] <yossarianuk> DVD drive, UEFI built in shell, UEFI USB stick, etc
[15:12] <cyphermox> we can find the commits that are relevant though and just SRU that
[15:12] <Riddell> cyphermox: where did your packages end up?
[15:12] <yossarianuk> Boot0000* kubuntu
[15:12] <cyphermox> Riddell: what do you mean?
[15:13] <yossarianuk> Boot0007  Unknown Device  ?
[15:13] <Riddell> cyphermox: is there a PPA so I can look at them again?
[15:13] <cyphermox> no, it was in my people page
[15:13] <cyphermox> http://people.ubuntu.com/~mathieu-tl/network-manager/
[15:13] <Riddell> cyphermox: cool, I'll take a look tomorrow
[15:13] <yossarianuk> i'll report my findings anyway - thanks for trying to fix the issue !
[15:15] <apachelogger> yossarianuk: use the shell to drop the ubuntu entry
[15:15] <apachelogger> help bcfg
[15:15] <cyphermox> Riddell: If you can just tell me what the problem was again then I'll look for the patch
[15:15] <apachelogger> something like bcfg boot rm $ID
[15:15] <apachelogger> then `reset`
[15:15] <apachelogger> if it appears again the firmware is being smart
[15:15]  * apachelogger afk
[15:17] <Riddell> cyphermox: I think it's a few things, I'll clarify with jgrulich
[15:18] <yossarianuk> apachelogger: bcfg isn't install on ubuntu 13.10 - not in the repos  either
[15:18] <apachelogger> yossarianuk: uefi shell
[15:18] <shadeslayer> apachelogger: did you upload grub?
[15:18] <yossarianuk> ah - ok
[15:19] <yossarianuk> thanks will reboot to drop to UEFI shell now (I take it I cannot do that from running OS?)
[15:22] <shadeslayer> \o/
[15:22] <shadeslayer> first trusty upload
[15:23] <shadeslayer> https://launchpad.net/ubuntu/+source/libnm-qt/0.9.0.1-0ubuntu1
[15:24] <yossarianuk> The problem with non rolling releases is your always getting excited about the new release rather than enjoying the current one...
[15:24] <apachelogger> shadeslayer: grub links plz I am going to reboot and then upload
[15:25] <shadeslayer> apachelogger: https://launchpad.net/~rohangarg/+archive/experimental/+files/grub2_2.00-19ubuntu2.1.dsc
[15:26]  * shadeslayer looks at "Rohan Garg (rohangarg) cannot upload grub2 to Saucy/Release" sadly
[15:27] <apachelogger> shadeslayer: please note that the bug report is not  ready for SRU
[15:27] <apachelogger> still needs impact and regression defined
[15:27] <apachelogger> see description
[15:28] <shadeslayer> "Could potentially break everything for all ubuntu users"
[15:29] <apachelogger> sounds about right
[15:31] <apachelogger> why it affects kubuntu-settings I do not know btw
[15:41] <shadeslayer> I like how Howard just reverted their GRUB_DISTRIBUTOR variable xD
[15:41] <shadeslayer> https://code.launchpad.net/~smartboyhw/ubuntu/trusty/ubuntustudio-default-settings/fix-bug-1242417/+merge/192209
[15:44] <apachelogger> cj wasn't too keen on the idea of piling up manual workarounds
[15:51] <apachelogger> ScottK, shadeslayer: [ubuntu/saucy-proposed] grub2 2.00-19ubuntu2.1 (Waiting for approval) 
[15:51] <shadeslayer> cool
[15:53] <apachelogger> shadeslayer: maybe make a card for that
[15:54] <apachelogger> because we will have to update the release page, drop a mail to kubuntu-users/kubuntu-devel and (unless we get .1 put a news about the defect and how people can overcome it)
[15:55] <apachelogger> I think yossarianuk broke his boot table
[15:55] <shadeslayer> ^^
[16:17] <apachelogger> https://trello.com/c/FpNkK1Da
[16:17] <shadeslayer> Riddell: plasma-nm updated
[16:17] <apachelogger> also
[16:17] <apachelogger> shadeslayer: https://trello.com/c/XwcVaeiG
[16:18] <shadeslayer> okay mm is left
[16:18] <yossarianuk> updated bug, it looks like as long as /boot/efi/EFI/ubuntu  exists I cannot remove the UEFI entry for 'ubuntu' (which boot kubuntu)
[16:19] <yossarianuk> i have removed with bcfg and efibootmng - it comes back on reboot (unless I delete the directory /boot/efi/EFI/ubuntu ...)
[16:19] <yossarianuk> (then I cannot boot)
[16:19] <shadeslayer> apachelogger: fwiw libnm-qt has a tiny API change ( a signal has new parameters )
[16:20] <apachelogger> Riddell: what do I do with https://trello.com/c/r2YHDTII
[16:20] <apachelogger> shadeslayer: doesn't matter, signal() == signal(Foo foo)
[16:20] <yossarianuk> also if I delete '/boot/efi/EFI/kbuntu' the system still boots....
[16:20] <yossarianuk> as long as /boot/efi/EFI/ubuntu is still there
[16:21] <shadeslayer> apachelogger: ack
[16:21] <yossarianuk> I blame ubuntu for all of this.........
[16:21] <apachelogger> yossarianuk: if ubuntu comes back after a reset from bcfg removal it gets added by your firmware automatically
[16:21] <apachelogger> nothing we can do about that
[16:22] <yossarianuk> but this is a new thing....
[16:23] <yossarianuk> i.e in 13.04 it did not happen
[16:23] <yossarianuk> )its not the end of the world)
[16:24] <yossarianuk> As a test I may blank drive + all UEFI entries again - just install Ubuntu 13.10 then see if I can remove the entry 
[16:25] <yossarianuk> if that is the case then there is an issue.
[16:25] <yossarianuk> (i.e if the entry stays removed)
[16:31] <apachelogger> seems our support crew called it a day ^^
[16:32] <shadeslayer> heh, probably fed up of all the calls coming in about broken UEFI
[16:32] <apachelogger> because we also get so many bug reports, right? :P
[16:33] <yossarianuk> I know for a fact that the UEFI issue has effected at least 8 people who use the kubuntu google plus page.
[16:34] <yossarianuk> most people think the workaround is fine and have not added to bug report.
[16:34] <yossarianuk> wait until they dual boot.....
[16:34] <shadeslayer> I think we should do a 13.10.1 once we get all the fixes we want in
[16:34] <apachelogger> not our call
[16:34] <shadeslayer> well, just my 2 cents
[16:34] <apachelogger> also there can be made a case against it
[16:34] <yossarianuk> threaten to go on strike.....
[16:34] <apachelogger> in that .1 would contain everything in -updates at the time
[16:34] <shadeslayer> what would be a case against it?
[16:34] <shadeslayer> and>
[16:35] <shadeslayer> *and?
[16:35] <shadeslayer> isn't that a good thing
[16:35] <apachelogger> not really
[16:35] <shadeslayer> lots of bug fixes?
[16:35] <apachelogger> something in -updates could cause a problem with ubiquity the livecd
[16:35] <yossarianuk> but that could be tested.
[16:35] <shadeslayer> ^
[16:35] <apachelogger> given reduced testing time and scope this could slip through our hands and then we have again a broken image, except it will be broken in other ways
[16:35] <shadeslayer> yossarianuk: like we did for 13.10 :D
[16:36] <yossarianuk> the annoying thing is people were having issues - just seemed not to bother actually making a bug report.
[16:36] <shadeslayer> apachelogger: so it's basically comes down to between "Potentially broken CD" and "Broken CD"
[16:36] <apachelogger> so IMO iff ubiquity manages to update grub such taht it does not lead to a broken system it would be impractical to do .1
[16:36] <xnox> I don't think it's possible to build an image with just a single package from -updates, you take all or nothing.
[16:37] <shadeslayer> xnox: actually, that would  be a good thing, since we also want muon updated and what not
[16:37] <yossarianuk> (i'm guessing that people just assumed that it would be fixed by the final release...)
[16:37] <xnox> and we will have to be careful not to delete that source.
[16:37] <apachelogger> xnox: that's what ScottK said too, which is why I would stay away from it
[16:37] <shadeslayer> I really don't see why we can't update, test, and if it is still broken, not release it
[16:37] <apachelogger> yossarianuk: yeah, assumption is the thing that comes befure a kerneloops :P
[16:38] <apachelogger> shadeslayer: <shadeslayer> yossarianuk: like we did for 13.10 :D
[16:38] <apachelogger> I would be very very very careful with assuming that our testing will be sufficient to prevent a regression over the 13.10 iso
[16:38] <apachelogger> so as I said
[16:39] <Quintasan> I'd say "very very very" doesn't even begin to cut it.
[16:39] <shadeslayer> that is true
[16:39] <apachelogger> if it turns out that once it is in updates it will lead to a fixed system that should be a good enough solution for .10
[16:39] <shadeslayer> again, I agree with that solution
[16:39] <Quintasan> As much as I hate it - our testing is usually crappy given we have very limited resources.
[16:39] <shadeslayer> but if it does not ...
[16:40] <apachelogger> if not then we can still consider a new image and if that does not work we'll simply create some automation the user can run
[16:40] <yossarianuk> but the point is - that the present .iso is 100% broken for uefi systems. - if an update fixes the issue it would mean UEFI users would need to be online to boot
[16:40] <apachelogger> it's not exactly rocket science to find the EFI partition and cp kubuntu ubuntu :P
[16:40] <yossarianuk> apachelogger: for some people it is.......
[16:40] <yossarianuk> Kubuntu is for everybody.....
[16:40] <apachelogger> read what I wrote please
[16:41] <apachelogger> also .10 will be outdated in 8.5 months
[16:41] <apachelogger> so
[16:41] <apachelogger> ....
[16:41] <apachelogger> veryyyyyyyy tiny scope here :P
[16:41] <apachelogger> if it was an LTS it would be different
[16:42] <apachelogger> Quintasan: actually I think the testing is just badly organized
[16:42] <apachelogger> that's why I put up the 14.04 deadlines board
[16:42] <shadeslayer> who wants to file SRU bugs for {libmm,libnm}-qt and plasma-nm
[16:42]  * apachelogger hides
[16:42] <Quintasan> apachelogger: Any ideas how to prevent that? I usually just grab the isos when I get pinged and do the testcases
[16:43] <apachelogger> https://trello.com/b/sdTmhD0H/14-04-deadlines
[16:43] <apachelogger> also our iso test cases are pretty crappy IMO
[16:43] <apachelogger> there need to be more focused tests
[16:43] <apachelogger> that don't need to be done for every candiate ISO but at least one
[16:43] <apachelogger> like l10n testing
[16:45] <yossarianuk> (+ UEFI testing....)
[16:45] <Quintasan> Do we even have the hardware to do UEFI testing?
[16:45] <apachelogger> I do now
[16:45] <yossarianuk> KVM can now emulated UEFI
[16:45] <apachelogger> I can even set my own secureboot keys and shit
[16:45] <Quintasan> yossarianuk: That's not a proper way to test this IMO.
[16:45] <apachelogger> yossarianuk: barely
[16:46] <apachelogger> and what Quintasan said
[16:46] <Quintasan> I'm pretty much sure UEFI will probably differ in some dumb way depending on the manufacturer
[16:46] <yossarianuk> UEFI has been generally annoying since I started using it...
[16:46] <apachelogger> Quintasan: that is a given but those issues are outside our scope anyway
[16:46] <shadeslayer> Quintasan: so kind of pointless to test it on a specific manufacturer?
[16:46] <apachelogger> that's part of general ubuntu efi/scureboot enablement
[16:47] <Quintasan> shadeslayer: I did not say that.
[16:47] <shadeslayer> I'm saying that
[16:47] <apachelogger> shadeslayer: it's pointless to test against clean spec compliant implements found in virtualization software :P
[16:47] <Quintasan> It's better than not doing it at all but we CAN'T test it on every single hardware.
[16:48] <Quintasan> It's not possible due to time, hardware and MOST importantly human resources constraints.
[16:48] <Quintasan> Even if we had all the hardware we wouldn't have enough manpower to test this :D
[16:48] <Quintasan> Typical time/effort problem.
[16:49] <Quintasan> Or maybe effort put/results gained to be more PRECISE.
[16:49] <apachelogger> it's a usefulness problem :P
[16:51] <Quintasan> http://paste.ubuntu.com/6290053
[16:51] <Quintasan> Looks like a big list of DO NOT SHIP - COPYRIGHT MUMBO JUMBO to me
[16:52] <Quintasan> Any objections to me ignoring this?
[16:52] <shadeslayer> apachelogger: muon 2.1.0 uploaded to trusty
[16:52] <shadeslayer> apachelogger: apol sent me a tarball with the final release
[16:52] <Quintasan> shadeslayer: Does it fix the muon-installer crashing after a few seconds after starting?
[16:52] <yossarianuk> well thanks to everybody working on the UEFI and other issues 
[16:52] <shadeslayer> yep
[16:52] <Quintasan> My roommate is whining about it never working :P
[16:52] <Quintasan> Great.
[16:53] <shadeslayer> Quintasan: cool, now you can file a SRU bug
[16:53] <shadeslayer> so that your roommate can get the fix
[16:53] <apachelogger> handy
[16:53] <yossarianuk> what version of KDE is 14.04 aiming to use btw ?
[16:53] <yossarianuk> isn't 4.11 a LTS version of KDE?
[16:53] <Quintasan> Uhh 4.12 is not going to happen IIRC
[16:53] <apachelogger> nonesense
[16:54] <apachelogger> kde-workspace stays at 4.11 everything else moves on
[16:54] <shadeslayer> ^^
[16:54] <Quintasan> Okay. It's just me being wrong then
[16:54] <apachelogger> Quintasan: why's your roommate not using discover?
[16:55] <shadeslayer> yes, why is he not discovering
[16:55] <Quintasan> Because it was not in raring?
[16:55] <apachelogger> raring is crashing?
[16:55] <apachelogger> what?
[16:55] <Quintasan> And he just upgraded.
[16:55] <apachelogger> I don't get it
[16:55] <apachelogger> if he's on raring why does he have muon 2.0.65?
[16:56] <Quintasan> He's been using raring, he upgraded -> it started crashing and he is whining now
[16:56] <Quintasan> :P
[16:56] <apachelogger> ah
[16:56] <apachelogger> tell him to use discover :P
[16:56] <Quintasan> I told him to shut the hell up and report it upstream.
[16:56] <Quintasan> ^^
[16:56] <apachelogger> no clue why they insisted on keeping installer at all, from my perspective discover replaces what installer was supposed to do
[16:57] <Quintasan> apachelogger: In my uni organisation there is a nice sentence right above the exit.
[16:57] <Quintasan> "BEACAUSE FU%* YOU, THAT'S WHY"
[16:58] <Quintasan> It's not entirely apropriate for this instance but we generally answer why's with that when possible :P
[16:59] <apachelogger> actually it's very appropriate
[16:59] <apachelogger> JT is a GUI horder
[16:59] <apachelogger> when they port to qt5 surely there will be discover1 and discover2 and both can be built :P
[16:59] <Quintasan> All your GUIs are belong to me?
[17:00] <apachelogger> to him!
[17:00] <Quintasan> Anyone wants to look at digikam 3.5 before I upload something potentially strange?
[17:02] <ScottK> apol: I saw the commit message on the deselecting updates bug.  Glad you were able to figure it out.  Could you add the software properties option back to Muon updater?  Having to fire up discover just to enable saucy-proposed for testing is awkward.
[17:06] <yossarianuk> http://www.youtube.com/watch?v=jjRAKuis7T8&t=16m20s   - Linus wants the different desktop people to work together and stop making pretty login screens....
[17:06] <Quintasan> shadeslayer: dget -xu http://people.ubuntu.com/~quintasan/uploads/digikam_3.5.0-0ubuntu1.dsc
[17:06] <Quintasan> DO EEEET.
[17:08] <shadeslayer> you can't upload to trusty?
[17:08] <shadeslayer> ScottK: muon 2.1.0 uploaded to raring
[17:08] <shadeslayer> erm
[17:08] <shadeslayer> saucy I mean
[17:09] <shadeslayer> ScottK: please accept so that you can selectively mark upgrades and Quintasan's roommate can start muon
[17:09] <shadeslayer> bug 1243807
[17:09] <Quintasan> shadeslayer: Damn you, I can but I don't trust myself this much after not doing anything for quite a while
[17:09] <Quintasan> I want you to check it.
[17:10] <shadeslayer> ok
[17:10] <shadeslayer> fetching
[17:18] <shadeslayer> Quintasan: looks good
[17:18] <shadeslayer> want me to upload
[17:18] <shadeslayer> Quintasan: no missing files et all?
[17:19] <Quintasan> shadeslayer: http://paste.ubuntu.com/6290053 <--- looks like a copyright pita so I ommited them
[17:19] <shadeslayer> ah so the usual
[17:19] <shadeslayer> :)
[17:20] <shadeslayer> Quintasan: so are you uploading?
[17:24] <shadeslayer> ScottK: bug 1243822 for your approval
[17:28] <Quintasan> shadeslayer: Upload'n
[17:50] <ScottK> shadeslayer: libmm-qt_0.5.0-0ubuntu1_0.5.1 is not a bug fix only release.
[17:53] <ScottK> Nor is libnm-qt_0.9.0
[17:54] <ScottK> shadeslayer: No way am I accepting renaming the applet for an SRU.  That's likely to mess up people's panels.
[17:54] <ScottK> Rejected the lot.
[17:55] <ScottK> The features in lib* seem minor and not a big deal, but come up with a plan for plasma-nm that doesn't involved a rename.
[17:55] <ScottK> Then we'll talk.
[17:59]  * yofel reminds shadeslayer and Quintasan that digikam has a packaging branch, please update
[18:08] <shadeslayer> ScottK: oh yeah
[18:12] <shadeslayer> ScottK: re libs, those are fine right?
[18:12] <shadeslayer> and they're not features afaict ?
[18:12] <ScottK> They are, but I can live with it.
[18:12] <shadeslayer> they're still ABI compatible since signal() is same as signal(foo)
[18:12] <shadeslayer> well .. ABI wise
[18:12] <shadeslayer> okay
[18:13] <ScottK> That's why I can live with it.
[18:24] <Quintasan> mmkay
[18:35] <ScottK> apachelogger: Can you review the diff for the nm-applet?  It's way more than I can look at today.
[18:42] <jalcine> Hey guys, so I'm looking to helping SDDM (https://github.com/sddm/sddm) get into (K)ubntu as a display manager
[18:43] <jalcine> it's an alternative to Canonical's lightdm and uses QML for theming
[18:43] <jalcine> the thing is I'd have to patch a package in universe (I think) called libxcb1 to get 'libxcb-xkb' to get it compiling
[18:43] <jalcine> any tips on how to do that?
[18:43] <jalcine> Right now I'm following http://developer.ubuntu.com for the inital patching but is there anything when it comes to patching I should be aware from sages here?
[18:44] <jalcine> b 1
[18:51] <apachelogger> ScottK, shadeslayer: where be the diff plz
[18:52] <apachelogger> jalcine: as far as I am aware it requires no patch, it just needs to be passed --enabled-xkb or somesuch thing to configure
[18:52] <ScottK> apachelogger: http://launchpadlibrarian.net/154814974/plasma-nm_0.9.3.0-0ubuntu5.1_0.9.3.1-0ubuntu0.1.diff.gz
[18:53] <jalcine> apachelogger: yeah, a patch to the Debian packaging then, because it doesn't have that option
[18:54] <apachelogger> that's not a patch, that'd simply be a change to the packaging :P
[18:55] <jalcine> Awesome, so would I just report this on Launchpad as a wish to change the packaging?
[18:57] <apachelogger> jalcine: yeah
[18:59] <jalcine> okay; I'll make a diff first (everyone loves diffs, I hear)
[19:01] <apachelogger> hm
[19:01] <apachelogger> shadeslayer: did you ask upstream if it is wise to push that without the libs?
[19:05] <kubotu> ::workspace-bugs:: [1243860] KDE battery monitor shows empty battery (wrongly) when connected to power source @ https://bugs.launchpad.net/bugs/1243860 (by Peder Chr. Nørgaard)
[19:11] <apachelogger> shadeslayer, ScottK: so... a) I'd check with upstream whether it is fine to backport that without the associated qt libraries b) that needs l10n stat comparision for de,es,fr and/or l10n QA as strings were added c) that needs serious regression potential assesment as desktop files and library files changed name
[19:11] <apachelogger> also
[19:12] <apachelogger> Riddell had a crash while upgrading from .04 to .10 due to plasma-nm's different kded name, so it is more than likely that the change will again cause a kded crash in some cases
[19:13] <apachelogger> needs particular looking out for and also talking to upstream in case they get a report about that during -proposed testing phase
[20:07] <kubotu> ::workspace-bugs:: [1197261] Can't install kde-style-skulpture on KDE 4.11 Beta 2 - conflict with kde-window-manager pa... @ https://bugs.launchpad.net/bugs/1197261 (by Murz)
[20:23] <Quintasan> what
[20:23] <Quintasan> the hell
[20:24] <Quintasan> ScottK: libqtgstreamer-dev : Depends: libboost-dev (>= 1.39) but it is not going to be installed
[20:24] <Quintasan> We have 1.54 in trusty, right?
[20:24] <ScottK> Yes
[20:25] <Quintasan> Why would that fail
[20:25] <ScottK> Probably things it depends on depending on conflicting boost -dev packages (the -dev aren't co-installable)
[20:26] <Quintasan> It built and installed just fine on my trusty chroot
[20:26] <Quintasan> Damn
[20:27] <ScottK> 1.54 transition is ongoing, so maybe something is updated since you updated your chroot.
[20:36] <Quintasan> ScottK: I guess I'll just wait for the transition to be done and retry the build