[00:06] <nixternal> anyone ever just do a dist-upgrade from an EOL release to something recent?
[00:07] <nixternal> i got a new client today that is using Kubuntu for a server :/  don't ask, it seems his old IT guy used it because he liked it, but it is edgy 6.10. All I can do, other than spending hours do a fresh install, which I just might end up doing, it try a dist-upgrade, but I am kind of scared of potential issues I will have to deal with
[00:48] <ScottK> debfx: What would you think about switching the quassel core apparmor profile to enforcing?
[11:08] <debfx> ScottK: sounds good but I haven't tested it with quassel 0.8
[12:41] <Riddell> apol: ubuntu-sso-client-qt is in the archives
[12:41] <apol> Riddell: what does that exactly mean? it's already in kubuntu?
[12:42] <yofel> !info ubuntu-sso-client-qt precise | apol
[12:42] <Riddell> apol: no it's in the archives and available to install, I yet know if it works
[12:42] <yofel> which reminds me I never finished ksecrets
[12:42]  * yofel takes another look at that
[12:43] <apol> Riddell: ok, since it's not going to happen until 12.10 we'll have the time to figure something out
[12:44] <Riddell> apol: it is going to happen to ubuntu desktop
[12:44] <Riddell> kubuntu is a complete unknown
[12:44] <apol> :)
[12:45] <apol> Riddell: well I guess that if I make muon to use it, we can pull it, no? at least optionally
[12:45] <Riddell> apol: yes
[12:45] <yofel> apol: it's in main, so feel free to use it
[12:45] <Riddell> for kubuntu beware of disk size on kubuntu for 12.04, for 12.10 it won't matter
[12:45] <apol> :)
[12:45] <Riddell> and I haven't got it to work yet so beware of it needing unknown gtk bits to actually work
[12:48] <apol> Riddell: well, I discussed about it with #ubuntuone people (they turned out to be good people in the end, as always :D)
[12:48] <apol> Riddell: apparently it won't pull ugly gnome stuff in the future
[12:49] <apol> like keyring (they use secret service api)
[12:49] <apol> it's still using python a lot, but I think kubuntu already uses that, right
[12:49] <yofel> right
[12:52] <Riddell> we do like our python (well I do)
[12:52] <Riddell> and we do need to package ksecretservice
[12:54] <yofel> I'm just trying to rebuild kdelibs again, for some reason amd64 always had dep-issues in my other ppa https://launchpad.net/~yofel/+archive/staging/+packages
[13:13] <BluesKaj> "morning
[13:34]  * bulldog98 just noticed, that we need activeAir theme for ksplash, if we want to use startactive
[13:35] <Riddell> bulldog98: put it in the seeds then?
[13:35] <bulldog98> Riddell: do we have that somewere?
[13:36] <ScottK> debfx: I don't think 0.8 changed anything relevant to apparmor profiles.
[13:38] <ScottK> Riddell: It's not clear what's going on with Ubuntu and ubuntuone.  The initial proposal for splitting PyQt4 wasn't adequate and I don't know if dobey will have time to work on it some more.
[13:40] <rbelem> bulldog98, it is in kde-artwork-active
[13:41] <bulldog98> rbelem: kool I’ll add that to the seed
[13:59] <bulldog98> following error ocurs: http://paste.kde.org/426890
[14:00] <Riddell> ScottK: what was wrong with the PyQt4 split proposal?
[14:00] <Riddell> if dobey doesn't have time to work on it then everything else on the client side of ubuntu one for this cycle will go to waste, bad planning somewhere
[14:01] <ScottK> It would have broken packages that depend on python-qt4 and use some of the modules he split out into seperate packages.
[14:01] <ScottK> Even with the split it's not clear they have room.
[14:01] <bulldog98> Riddell: ^
[14:01] <ScottK> They may ship just an Ubuntu One installers.
[14:13] <bulldog98> rbelem: can you tell me what’s happening here? http://paste.kde.org/426890
[15:13] <markey> hey all
[15:13] <markey> on dist-upgrade from 10.04 to 10.10 I'm stuck with this error:
[15:13] <markey> E: Internal Error, Could not early remove libcups2
[15:14] <markey> any ideas how to get out of this?
[15:16] <Riddell> dist-upgrade isn't a supported way to do release updates, only the upgrade tool is
[15:16] <markey> doh
[15:16] <Riddell> which is another way of saying, sorry I don't know
[15:16] <markey> now I'm stuck with a half upgraded system
[15:17] <BluesKaj> markey,  upgrading to the next release is now done with  sudo do-release-upgrade
[15:17] <Quintasan> markey: Theoretically you could force remove it via dpkg, try upgrading and then installing it and pray nothing breaks meantime
[15:17] <markey> Quintasan: thanks I think I'll try that
[15:18] <Quintasan> markey: I'm not held responsible for any dead kittens
[15:18] <markey> yeah I guess it can't get much worse though
[15:26] <markey> Quintasan: do you know the syntax for this force remove?
[15:26] <markey> the man page is kinda confusing
[15:27] <yofel> markey: dpkg -r<package>
[15:27] <yofel> add --force-depends if it doesn't want  to remove it due to dependencies
[15:27] <yofel> *-r <package>
[15:28] <Quintasan> thanks yofel
[15:28] <markey> thanks
[15:30] <markey> yiikes, now the same thing happens with libaudio2
[15:30] <markey> I'm getting the feeling this system is hosed
[15:31] <markey> oh wow, now it's continuing
[15:31] <markey> maybe, just maybe, I'm lucky
[15:31] <Quintasan> repeat until $(works)
[15:31] <markey> yep
[15:33] <markey> why I didn't upgrade with KPackageKikt: It didn't offer to upgrade. I've ignored the upgrade notification for ages. today I finally wanted to upgrade, but it wasn't offered
[15:39] <bulldog98> Riddell: why have I no commit rights to kubuntu-dev?
[15:39] <yofel> bulldog98: because you are no kubuntu-dev?
[15:39] <yofel> (yet)
[15:40] <Riddell> it has a process similar to kubuntu-members
[15:40] <yofel> kubuntu-members have commit rights to ~kubuntu-packagers only
[15:40] <Riddell> but don't let that put you off
[15:40] <bulldog98> ok
[15:40] <bulldog98> so I need to work a bit
[15:40] <bulldog98> no problem
[15:40] <yofel> file a merge request and poke one of us
[15:40] <Riddell> you neeed to organise a meeting with the rest of the ~kubuntu-dev members and convince us you're competant (which won't be hard)
[15:41] <bulldog98> yofel: ok
[15:41] <yofel> or apply for kubuntu-dev ;)
[15:41] <schnelle_> yofel: what is the status of new version of kmess? is it packaged for precise? 
[15:42] <yofel> schnelle_: not yet, did they publish it?
[15:42] <schnelle_> not yet on their official site
[15:42] <schnelle_> tagging in git is not enough?
[15:43] <yofel> It's better to have the official tarball
[15:44] <schnelle_> well one of devs said: 
 I don't have the full access to the sourceforge account
 so can't upload the tarbal myself
[15:44] <schnelle_> so they are probably waiting so dev eith upload rights
[15:44] <schnelle_> to upload it...
[15:44] <schnelle_> I will poke them again :)
[15:55] <bulldog98> yofel: https://code.launchpad.net/~bulldog98/ubuntu-seeds/kubuntu-active.precise/+merge/94205
[16:01] <Riddell> bulldog98: I'll do it
[16:03] <Riddell> done
[16:03] <Riddell> thanks
[16:18] <markey> yofel: Quintasan: it seems I was lucky after all, the upgrade worked. but now I'm still missing libcups2 and libaudio2, which I had force-removed earlier. apt-get install says "can't find file". how could I get them back?
[16:18] <markey> (I don't have any sound now)
[16:19] <yofel> hm, that can't find file sounds familiar....
[16:19] <Quintasan> markey: look in /etc/apt/sources.list for oneiric entries and change them to precise
[16:19] <Quintasan> apt-get update
[16:19] <markey> apt-get install claims it's already installed. but --reinstall gives this error
[16:19] <Quintasan> then try cleaning the /var/cache/apt/
[16:20] <markey> "precise"?
[16:20] <Quintasan> i.e remove all debs from that directory
[16:20] <yofel> Quintasan: wrong release
[16:20] <Quintasan> yofel: Oh
[16:20] <yofel> markey: maverick
[16:20] <Quintasan> s/maveric/oneiric
[16:20] <Quintasan> y?
[16:20] <yofel> hm, he said 10.10
[16:20] <markey> erm, 11.10
[16:20] <markey> typo
[16:20] <yofel> ah, oneiric then
[16:20] <markey> it's oneiric now
[16:21]  * Quintasan wonder why amarok crashes on windows for him
[16:21] <markey> should I simply rm -f /var/cache/apt?
[16:21] <Quintasan> it worked
[16:21] <Quintasan> nah
[16:22] <Quintasan> markey: rm -r *.deb /var/cache/apt
[16:22] <markey> ok
[16:22] <Quintasan> bleh
[16:22] <Quintasan> bleh bleh
[16:22] <Quintasan> don't issue that
[16:22] <markey> ok
[16:22] <Quintasan>  rm -r *.deb /var/cache/apt/*.deb
[16:22] <Quintasan> more like that
[16:22] <markey> alright
[16:24] <markey> no that doesn't work
[16:24] <yofel> wrong again, rm /var/cache/apt/archives/*
[16:24] <markey> :)
[16:24] <markey> thanks
[16:24] <yofel> and rm /var/cache/apt/archives/partial/*
[16:26] <markey> no dice, same error
[16:26] <markey> 0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
[16:26] <markey> Need to get 0 B/173 kB of archives.
[16:26] <markey> After this operation, 0 B of additional disk space will be used.
[16:26] <markey> E: Internal Error, No file name for libcups2
[16:28] <bulldog98> markey: have you tried passing -f ?
[16:28] <markey> yeah, doesn't change anything
[16:29] <tsimpson> markey: have you tried issuing "sudo apt-get clean"?
[16:29] <markey> nope
[16:29] <markey> let's see
[16:30] <markey> no dice
[16:30] <Quintasan> markey: try aptitude
[16:32] <markey> doh, same thing
[16:33] <markey> I guess there must be a solution
[16:35] <yofel> markey: can you try: rm /var/lib/apt/lists/*
[16:35] <yofel> run apt-get update and try again?
[16:36] <markey> nothing is in /lists
[16:36] <markey> only an empty /partial folder
[16:36] <yofel> o.O
[16:37] <yofel> running 'apt-get update' doesn't put anything there?
[16:38] <markey> ah yes, now there is a lot in thre
[16:41] <markey> hah, figured it out after googling
[16:41] <markey> "sudo apt-get install --reinstall libcups2:amd64 libcups2:i386"
[16:41] <markey> this does the trick
[16:42] <yofel> multiarch
[16:42] <yofel> just great -.-
[16:42] <markey> yep.... I would never have guessed the solution
[16:42] <yofel> mind filing a bug about apt giving nonsense error messages?
[16:43] <yofel> or incomplete ones at least
[16:43] <ScottK> I think it's known.
[16:43] <yofel> hm
[16:43] <yofel> k then
[16:45] <markey> one more reboot, maybe then the sound will work again
[16:53] <markey> hmm nope, no sound
[16:57] <markey> got it working. just some phonon settings misconfigured
[16:57] <markey> yay
[16:57] <markey> thanks all for the help :)
[17:21] <ronnoc> Darkwing: Ping
[17:53] <markey> back at home
[17:54] <markey> this multiarch thing was really a bitch
[17:54] <markey> are all packages like this now?
[18:01] <shadeslayer> markey: most, yes
[18:01] <shadeslayer> markey: they got rid of ia32-libs iirc
[18:01] <shadeslayer> it's a better solution than those libs I believe
[18:01] <shadeslayer> or so I'm told
[18:02] <shadeslayer> *sigh*
[18:02] <markey> would be nice if --reinstall could detect this, and use the correct syntax for multiarch
[18:02] <yofel> well, it's the right way to do it, just the implementation in dpkg and apt is buggy
[18:02] <shadeslayer> Prime got a boot unlocker tool
[18:04] <markey> I mean, you need deep insider knowledge for coming up with this (unless you are lucky with google, like I was)
[18:07] <shadeslayer> markey: then again, you were doing it wrong :P
[18:08] <markey> that's what I wanted to add: despite me screwing up badly, everything went fine in the end. shows how good the packaging system is
[18:09] <shadeslayer> yeah, dpkg is quite robust
[18:09] <markey> yep
[18:09] <markey> I was using Arch for a while. the packaging just does not compare
[18:09] <shadeslayer> I had some issues with libc6 itslef, still let me fix up my system
[18:09] <markey> feels like the packages hold together with glue and saliva
[18:10] <shadeslayer> haha ^^
[18:10]  * shadeslayer drinks some more cough syrum
[18:10] <markey> it's far easier to create Arch packages I hear, but it comes at a price :)
[18:10] <shadeslayer> s/syrum/syrup/
[18:10] <kubotu> shadeslayer meant: "drinks some more cough syrup"
[18:11] <shadeslayer> I tried arch once
[18:11] <shadeslayer> nearly destroyed everything on my HD trying to install it
[18:11] <shadeslayer> then again, I was naive ...
[18:12] <markey> my experience was fairly positive in the beginning, until I wanted to install some lesser popular packages
[18:12] <shadeslayer> :D
[18:13] <markey> back then they also didn't have any dbg packages, that sucked a lot
[18:13] <shadeslayer> they also don't have -dev packages
[18:14] <markey> I think -dev is always included like in Gentoo?
[18:14] <yofel> IIRC it was gentoo based, so I would assume they are
[18:14] <markey> hm yes
[18:14]  * yofel only used gentoo for a bit, never arch
[18:14] <shadeslayer> idk I was told they had no -dev packages, lemme recheck
[18:15] <markey> hey, honest question: what do you guys think of RPM these days (with zypper and all that jazz)
[18:15] <markey> is it on par with dpkg/apt?
[18:15] <shadeslayer> ah
[18:16] <ScottK> My last experience with it was in 2006 with opensuse 10.1.  It was enough of a disaster for me to say never again.
[18:16] <shadeslayer> yes, seems like the guy who I was talking to made a typo and my brain just registered -dev ... :P
[18:16] <markey> ScottK: same here. but it has improved tons to be fair. I just don't know if it's as good as dpkg now
[18:16] <shadeslayer> I became too comfy with apt/dpkg and everything else just seems pointless now
[18:17] <markey> we use SUSE for some special cases at work (but Kubuntu on our devel machines)
[18:17] <ScottK> I don't actually know, but when I look in rpm spec files they seem to be missing a lot of stuff we can do in /debian.
[18:17] <maco> markey: zypper is a big improvement over yast omg
[18:17] <markey> omg yast
[18:17] <BluesKaj> dpkg does all the work , apt just relays the message
[18:17]  * yofel has opensuse and fedora VM's, but never looked closely at rpm
[18:17] <markey> the stuff of my nightmares
[18:17] <shadeslayer> hehe
[18:17] <maco> markey: though i dont know.... is it possible to batch import a bunch of repos in suse AND THEN refresh the available package list yet?
[18:18] <shadeslayer> I tried out opensuse once, worked good for 10 minutes before slowing down and asking me accept a bunch of licenses
[18:18] <markey> maco: I wouldn't know...
[18:18] <maco> when i tried to use yast in 2007, you added a repo...then it refreshed..then you added a repo...then it refreshed...
[18:18] <markey> I've written a couple of .spec files, the format is fairly sane
[18:18] <maco> it took like a half hour to get repos set up so i could fix the broken graphics drivers
[18:18] <yofel> from what I see it's rather easy to add patches to a package in opensuse
[18:18] <maco> spec files make sense, they're just annoying in their monolithicness
[18:18] <yofel> with quilt it's not too hard for us too
[18:19] <shadeslayer> ^
[18:19] <yofel> now it would be cool if you could do that from the launchpad UI
[18:19] <ScottK> Ironically Libzypp is the disaster that caused me to leave opensuse.
[18:19] <markey> maco: how do you mean monolithic? as opposed to what?
[18:19] <shadeslayer> yofel: right after they fix the timeout issues when copying entire repo's
[18:19] <ScottK> markey: One big file instead of a number of files in a directory.
[18:19] <markey> ah yes
[18:20] <maco> markey: in debian packages, you can have a file for each binary package generated, listing what goes in it. in spec files you just make a bajillion lines of text in one file
[18:20] <maco> lots of scrolling, no side-by-side compare... 
[18:20] <yofel> shadeslayer: well, that's only really doable by disabling timeouts for copying, matching the backend workload
[18:20] <markey> that's not a huge issue though, usually you separate sections with comment lines
[18:20] <markey> in practice that's ok
[18:21] <shadeslayer> *nod*
[18:21] <shadeslayer> yofel: what I would really like would be some sort of CI system that integrates with LP
[18:21] <shadeslayer> s/LP/bzr/
[18:21] <kubotu> shadeslayer meant: "yofel: what I would really like would be some sort of CI system that integrates with bzr"
[18:22] <yofel> CI?
[18:22] <shadeslayer> Continuous Integration ... or rather Continious Packaging in our case
[18:22] <yofel> ah
[18:22] <markey> next level: Continuous Delivery
[18:22] <shadeslayer> and not just for PPA's, I mean for archive
[18:23] <yofel> well, handling bzr and quilt conflicts is the more pressing issue
[18:23] <shadeslayer> hehe
[18:23] <markey> I guess that would translate to Rolling Releases for distros ;)
[18:23] <shadeslayer> well, afaik you can handle that easily as well
[18:24] <shadeslayer> as long as the patches are well documented
[18:24] <shadeslayer> the first few lines usually have the git commit hash ( of a upstream'd patch )
[18:24] <shadeslayer> so you just convert that hash to a bzr rev using the bzr-git plugin and compare it with the code branch
[18:25] <shadeslayer> \end dream
[18:25] <markey> is BZR usable when you are used to Git?
[18:25] <yofel> *drool*
[18:25] <markey> I always wondered why you don't use Git
[18:25] <shadeslayer> markey: you get used to it
[18:25] <shadeslayer> I mean, I know the basics
[18:25] <yofel> markey: it tries to behave like a mix between git and svn, so takes a bit getting used to, but it's usable
[18:25] <shadeslayer> unlike git, where I can do all sorts of stuff now
[18:25] <markey> ok
[18:26] <yofel> markey: launchpad doesn't support git <end of reason>
[18:26] <shadeslayer> ^
[18:26] <markey> hehe yeah, not your decision I guess
[18:26] <shadeslayer> yeah, unless somehow we gain access to production servers <evil laugh>
[18:28] <markey> I guess BZR is meant to be easier to use?
[18:29] <shadeslayer> yeah, that's the idea I think
[18:30] <shadeslayer> Anyone up for packaging KDevelop? I'm going to be AWOL starting tomorrow
[18:30] <yofel> I like that it behaves synchronized like svn if I want it to (and that's how I usually want it to behave)
[18:30] <shadeslayer> ^ I'm not in favor of that behavior
[18:31] <shadeslayer> git gives you *alot* more flexibility in that scenario
[18:31] <yofel> I committed something to git more than once only to forget to push and later wondering where that commit is
[18:31] <shadeslayer> made a faulty commit and/or want to add more stuff your commit? git rebase -i HEAD~1
[18:31] <yofel> I do sometimes use bzr like the DVCS that it really is, but it's nice that it can work both ways
[18:32] <shadeslayer> heh
[18:32] <shadeslayer> git gets hard to track sometimes tho
[18:32] <shadeslayer> when you have a bazillion branches ....
[18:32] <yofel> now there I prefer git over bzr
[18:32] <yofel> bzr essentially does branching the svn way....
[18:32] <yofel> (fs-layout wise)
[18:33] <yofel> only that merging is much easier
[18:37] <shadeslayer> I just mean that managing branches can be a bit tedious with git, I've never tried out branching with bzr
[18:37] <shadeslayer> or SVN for that matter
[18:38] <yofel> shadeslayer: the moment you make a diconnected checkout with bzr you have a branch. You really can't do anything else but branching there
[18:38] <yofel> svn branching was pretty much like svn tagging
[18:38] <shadeslayer> so essentially, no real branching
[18:39] <yofel> guess the rest
[18:39] <shadeslayer> I've not really had alot of experience with svn
[18:39] <shadeslayer> mostly svn co, svn commit and svn log :P
[18:39]  * shadeslayer is a child of the git generation
[18:40] <yofel> be happy about it
[18:40] <shadeslayer> lol 
[18:40]  * yofel is happy that he isn't a child of the cvs generation ^^
[18:42] <shadeslayer> Interestingly, KDE has seen all 3 ...
[18:44] <BluesKaj> do you guys remember the method to reinstall with alternate live cd , where just installing the OS without rteformatting would save the home dir data and desktop settings ?
[18:44] <yofel> I know the live disk can do that, but I've never tried that with d-i
[18:45] <BluesKaj> with just a / partition , no /home yofel
[18:45] <shadeslayer> Just don't format the disk? Shouldn't it install over the existing install and not mess with other stuff?
[18:46] <BluesKaj> shadeslayer,  yeah , I recall doing so on 10.10 ...wondered if it still works
[18:47] <shadeslayer> BluesKaj: boot a live disk -> Back up data -> Reinstall ?
[18:47] <yofel> IIRC ubiquity will remove everything except /home (and tell you that) if you tell it to install on a partition that has an ubuntu install on it
[18:48] <yofel> needs the manual partitioning way
[18:48] <yofel> I think
[18:48] <shadeslayer> ^ Yeah, I'm not entirely sure either, so take a backup
[18:48] <shadeslayer> just in case
[18:50] <BluesKaj> shadeslayer,  I recall being very surprised that the data was still there , and the desktop settings ...didnt use ubiquity ...didnt reformat either
[18:52] <BluesKaj> alternate install cd 
[19:01] <shadeslayer> oh
[19:01] <shadeslayer> yofel: where is the kopypackages script?
[19:01]  * shadeslayer doesn't remember
[19:01] <shadeslayer> kubuntu-dev-tools?
[19:01] <yofel> kubuntu-dev-tools
[19:01] <shadeslayer> cool
[19:02] <shadeslayer> I'll try and hack on it a bit tonight to see if I can get it to copy entire repos ...
[19:02] <yofel> oh right, you wanted me to add copying all releases at one
[19:02] <yofel> *once
[19:02] <shadeslayer> yes
[19:02] <shadeslayer> I'll try to do it tonight :P
[19:04] <yofel> shadeslayer: in the option settings at the bottom, every case has a match against == from_release. Feed the other part of that check to copy_package instead of to_release and find a good way to expose that to the user and you're done
[19:04] <yofel> would justify adding a variable for that
[19:07] <shadeslayer> looking
[19:07] <yofel> the release check should be a seperate method really
[19:07] <yofel> would make things easier here
[19:17] <shadeslayer> yofel: I might have a easier way
[19:17] <shadeslayer> After:    if options.all: 
[19:17] <shadeslayer> if I add, if len(args) == 2
[19:17] <shadeslayer> then it simply means that the user did not specify the release
[19:18] <shadeslayer> I can then copy all releases
[19:18] <shadeslayer> ( I need to check if the first/second arg is a PPA ofcourse ) 
[19:18] <yofel> hm yeah, that would work too
[19:20] <yofel> which makes specifying the target release easy actually
[19:21] <yofel> but needs some overally fixes in the script
[19:26] <shadeslayer> yep
[19:26] <yofel> shadeslayer: I have another idea, give me a minute
[19:26] <shadeslayer> sure
[19:26] <shadeslayer> I'm just giving it a bit of structure as of now
[19:27] <shadeslayer> It feels weird in python world
[19:27] <shadeslayer> I've gotten too used to using C/C++
[19:29] <yofel> now I need something to test this on..
[19:29] <shadeslayer> well I can do that
[19:30] <shadeslayer> I can just copy the tp packages from the official repo to my unoffical repo
[19:34] <shadeslayer> yofel: are you writing that functionality?
[19:34] <yofel> shadeslayer: well, essentially, yes ^^
[19:34] <shadeslayer> heh :P
[19:35] <shadeslayer> let me know when its open for testing then :D
[19:38] <shadeslayer> Riddell: your ec2 script seems outdated as well
[19:39] <yofel> shadeslayer: committed
[19:40] <yofel> use 'all' for the source and target release
[19:43] <shadeslayer> sec
[19:46] <shadeslayer> works :)
[19:46] <yofel> \o/
[19:48] <shadeslayer> yofel: have you read this btw : http://shop.oreilly.com/product/9780596001674.do
[19:49]  * shadeslayer is thinking of buying it
[19:49] <yofel> no
[19:49] <DasKreech> Is that a jackalope?
[19:49] <shadeslayer> DasKreech: looks like it :D
[19:50] <shadeslayer> there's this as well : http://shop.oreilly.com/product/9780596158118.do?green=0793EC36-E771-5284-A742-0DCFF5606418&cmp=af-mybuy-9780596158118.IP
[19:52] <shadeslayer> Well, atleast this confirms my data is actually encrypted with google : http://wstaw.org/m/2012/02/22/plasma-desktopuo2537.png
[19:59] <shadeslayer> Night everyone
[20:05] <DasKreech> night
[20:14] <rbelem> shadeslayer, it is a good book
[20:15] <rbelem> shadeslayer, but not essential imho
[20:16] <rbelem> bulldog98, no idea
[20:16] <bulldog98> rbelem: hm bad plasma-desktop doesn’t even start