[00:01] <amichair> ...and deliver what we promote
[00:01] <amichair> no silly usability bugs
[00:01] <jwisser> amichair: I cannot tell you how right you are.
[00:04] <amichair> e.g. the software-properties (repo sources dialog) bugs I've been fixing for the past couple of days... they wouldn't pass a 30-minute qa session in any commercial company
[00:05] <amichair> and the whole app is just a gui, there's no real technical problem here...
[00:05] <jwisser> amichair: You are my new best friend.
[00:05] <amichair> well I hope I can make things a tad better :-)
[00:05] <jwisser> That is exactly the kind of thing that needs to get fixed.
[00:06] <claydoh> just having these dialogs means Kubuntu is  going to be better :)
[00:06] <claydoh> you folks rock!
[00:07] <claydoh> oooh what a horse race! literally
[00:07]  * claydoh is watching the breeders  cup for some odd reason
[00:08] <jwisser> So who else do we need to convince about this? (amichair and claydoh)
[00:09] <amichair> lol... I thought I wasn't getting some 'horse race' proverb from somewhere around the world ;-)
[00:09] <jwisser> amichair: I had a moment of that, too.
[00:10] <amichair> I think it has to come up here (or in the lists) with the major kubuntu devs
[00:10] <jwisser> amichair: And that's my question; I haven't been here long enough to know who those are.
[00:11] <claydoh> probably no one to convince, I think all the 'players' are/would be on board  thats why we have Timelord - to get more peeps involved and help form what we are going to become
[00:11] <amichair> me neither :-)
[00:12] <amichair> claydoh: yes, I meant not as much 'convincing' as getting everyone's mind-share on this
[00:13] <jwisser> claydoh: It seems like some people who are determined to stick as closely as possible to the KDE upstream aren't liable to be pleased about the idea of pushing customization.
[00:13] <claydoh> apachelogger, Scott K, Rid dell, and a number of others
[00:13] <jwisser> Or at least, the idea of including an-easier-to-find customization center.
[00:13] <amichair> so maybe we can get the KDE ppl to do it :-)
[00:13] <claydoh> jwisser: customization can take many forms, but I think some small things are possible
[00:14] <jwisser> claydoh: Nice thing about this channel is that I've already spoken to two of the three you mention by name. Good deal. :-)
[00:14] <jwisser> claydoh: I'm not pushing for OOTB customization, just easier access to it for individual users.
[00:15] <jwisser> amichair: Dur. I'm still in closed-source mindset from using my Mac. I forget you can go ask people nicely.
[00:15] <claydoh> jwisser: that probably would be better for upstream as it would elp out KDE greatly
[00:15]  * jwisser goes to find the KDE dev channel.
[00:16] <claydoh> re: the horse race, the favorite came from last place and ended up  winning - and setting history as the first female horse to win the race
[00:16] <amichair> claydoh: we're making history here :-)
[00:16] <claydoh> amichair: looks like it :)
[00:17] <jwisser> Gotta say, I'm excited about the possibilities. :-)
[00:18]  * amichair wishes he could make a living of open source dev
[00:18] <jwisser> For now, I'm just gonna start reading #kde-devel. I don't want to go ask for something until the Kubuntu community as a whole is behind it.
[00:18] <amichair> jwisser: go a head and mingle :-)
[00:27] <jwisser> How bad would the reaction be to including a closed-source app on the Kubuntu desktop? Theoretically speaking?
[00:27] <claydoh> jwisser: never by default, will never happen
[00:28] <claydoh> it would go very badly i am sure
[00:28] <claydoh> jwisser: which app?
[00:28] <JontheEchidna> Ubuntu policy wouldn't allow it even if everybody wanted it :P
[00:29] <claydoh> JontheEchidna beat me to that point
[00:29] <jwisser> Unfortunate. I was just thinking it would be extraordinarily badass if we could get the Doubletwist guys to port to Linux. "Just works" synching with craptons of media players and smartphones out of the box? Yes, please.
[00:29] <jwisser> Hmmm.
[00:30] <jwisser> I wonder if we could convince them to collaborate with Kubuntu devs on a FOSS version for Linux.
[00:30] <jwisser> It occurred to me the other day that an app like that would to a long way toward distinguishing a given Linux distro.
[00:31] <jwisser> Particularly because I'm pretty sure they're working on iPhone syncing…
[00:31] <jwisser> Imagine being the first distro with full iPhone sync.
[00:33] <jwisser> Better still if we could add support for the Pre, as well.
[00:33] <jwisser> Talk about your killer app for a lot of users.
[00:35] <jwisser> But, possibly I am crazy.
[00:35] <claydoh> its gotta be FOSS tho, else we become linspire or worse :)
[00:35] <jwisser> ::shivers:: Fair enough. None of that around here.
[00:36] <amichair> jwisser: well, we won't be the first - if they port, many distros will include it as well. Not that I think that's a bad thing :-)
[00:36] <JontheEchidna> one thing I've found is that it's very hard to be unique
[00:36] <jwisser> Ehhh, we could be the first. Little creative release timing. ;-)
[00:36] <jwisser> And a late announcement.
[00:37] <JontheEchidna> we are pretty much first among the regular 6-month distros
[00:37] <jwisser> Not for long, sure, but we could be first to market and get a reputation for getting cool stuff done.
[00:39] <jwisser> And if you want new devs, that should bring a few in.
[00:49] <amichair> is it possible in bzr to update the log message for a commited revision?
[00:50]  * JontheEchidna would like to know too
[00:50] <JontheEchidna> I usually just bzr uncommit when that happens
[00:50] <JontheEchidna> which is inconvenient, to say the least
[00:55] <amichair> JontheEchidna: r u a long time kubuntu dev?
[00:56] <JontheEchidna> I've been contributing since mid-2008, so not too terribly long-time compared to some here
[00:56] <ScottK> jwisser: What's the only netbook oriented KDE distro in the world?
[00:56] <ScottK> Being first is a good thing and we can do it if we pick some right things to be first at.
[00:57] <ScottK> Marketing works in more than one direction.
[00:57] <amichair> ScottK: good point! but how would u translate that for someone that has no idea what kde is?
[00:58] <ScottK> In 6 months if several distros are pestering the netbook devs for stuff, where will their first attention go?
[00:58] <ScottK> Hopefully to us.
[00:58] <ScottK> amichair: Part of the problem is that end users are really who you market to for netbooks.
[00:59] <ScottK> The target market for netbooks is people making OEM decisions.
[00:59] <ScottK> There is money in being pre-installed.
[00:59] <ScottK> That drives a different kind of argument.
[00:59] <amichair> true
[01:00] <ScottK> It is really hard to make existing GTK+ stuff scale down to netbooks.  That's why Canonical has a huge mobile team.
[01:00] <ScottK> Qt/KDE 4, it's dead easy.
[01:00] <amichair> if these ppl hear kde, is that enough to give us a few extra points?
[01:00] <ScottK> Nokia didn't buy Trolltech for charity.
[01:01] <amichair> also, do scaling issues translate to oem problems, or ubuntu dev problems?
[01:01] <ScottK> Qt is the future in small form factor computing compared to GTK.  It's already known the Maemo 6 will be Qt.
[01:01] <ScottK> amichair: Both.
[01:01] <amichair> cool (for us :-) )
[01:02] <ScottK> The future may be Android or something else, but between GTK and Qt, I think in the next couple of years, Qt is the clear winner.
[01:02] <ScottK> amichair: Look at the size of the Canonical team working on Ubuntu Mobile desktop/launcher and look at us with 2 upstream devs and a few of us working part time.
[01:03] <ScottK> The value position for an OEM in terms of cost risk is substantially lower with a Qt/KDE solution.
[01:03] <bjoern_> Hi, I need help. I just upgraded from jaunty to karmic and couldn't reboot.
[01:03] <ScottK> KDE is shinier than Gnome too.
[01:03] <amichair> yes, shiny is why I'm here :-)
[01:04] <jwisser> ::laughs:: Shiny is what kept me away for so long.
[01:04] <ScottK> I heard someone at say that at install fests they just give Kubuntu CDs to people that ask for it or people that say Ubuntu is ugly.
[01:04] <jwisser> (Sorry, forgot to set away while making dinner.)
[01:04] <bjoern_> The upgrade terminated between installing and clean up, but I got a reboot anouncement which I followed.
[01:04] <ScottK> bjoern_: Did you try in #kubuntu?  That's the help channel.
[01:04] <amichair> is promotion/marketing necessary in that case? or is it just about finding the right half-dozen oem decision makers and sending someone to talk to them?
[01:05] <ScottK> amichair: That's promotion/marketing.
[01:05] <jwisser> amichair: Still counts as promotion and marketing. ;-)
[01:05] <amichair> ok... u know what I mean :-)
[01:05] <ScottK> One thing we need is a really shiny demo mode.
[01:05] <jwisser> That's some of the hardest marketing to do, in fact, as a lot of those people have a small staff dedicated to keeping the riffraff away.
[01:05] <ScottK> If we had that, a Kubuntu based netbook would fly off the shelves.
[01:05] <bjoern_> ScottK: Sorry, yes, but I didn't got an answer.
[01:06] <ScottK> bjoern_: What happens when you try to boot?
[01:06] <amichair> ScottK: demo mode? isn't the regular user experience the aim of shininess?
[01:06] <ScottK> amichair: It needs to look sexy on a store shelf.
[01:06] <ScottK> This is about marketing still.
[01:07] <amichair> ScottK: that's my point... it needs to look that way all the time! if someone borrows my netbook to check their mail, they shold be jelous within 30 seconds...
[01:07] <bjoern_> ScottK: menu.lst had still the old kernel which didn't boot. And for the new kernel there is no initrd.
[01:07] <ScottK> bjoern_: How about #ubuntu then.  That's common between Kubuntu and Ubuntu.
[01:07] <jwisser> amichair: That's so, but have you been in an Apple store?
[01:07]  * ScottK isn't so good with those kinds of problems.
[01:08] <ScottK> amichair: That too.
[01:08] <bjoern_> ScottK: OK, thanks I will try there.
[01:08] <jwisser> They have machines set up to cycle into sexy ad screensavers.
[01:08] <amichair> I think viral marketing is quite important for gizmos (which netbooks still are)
[01:08] <jwisser> ScottK: KNE is going to ship with Ubuntu One enabled, right?
[01:09] <ScottK> jwisser: Not decided for 10.04.  We'd need someone to write a KDE client.
[01:09] <jwisser> ScottK: Then we need someone to write a KDE client. No-hitch syncing for the average (l)user is something Linux traditionally sucks at. We have an opportunity to be awesome here.
[01:10] <ScottK> So point one in the marketing plan is a section of kubuntu.org that this theoretical OEM VP of engineering would look at and go "Wow, I need to have someone look into this."
[01:11] <jwisser> As long as point zero is actually having the features. ;-)
[01:11] <ScottK> Part of the reason to focus marketing on the OEMs is OEM service contracts come with funding so Kubuntu has more paid devs and the abilty to do more stuff.
[01:11] <ScottK> jwisser: Certainly.
[01:11] <ScottK> jwisser: Much of the value propositon for Kubuntu Netbook exists today based on the technology and what we've already done.
[01:12] <ScottK> So we can start to tell the story.
[01:12] <jwisser> ::contemplates:: Working with OEMs could also give us an opportunity on flawless operation on certain hardware.
[01:12] <jwisser> *to ensure
[01:12] <ScottK> Yes.  The existing Canonical OEM contracts are why Kubuntu Netbook works on as much hardware as it does.
[01:13] <jwisser> ScottK: I'm just thinking it would be fantastic if our hypothetical OEM could sell a netbook/desktop combo by going "Holy crow, look at the syncing! Isn't that fantastic?"
[01:13] <ScottK> Agreed.
[01:13] <ScottK> Unfortunately Ubuntu One only sync's between Linux machines, so it's of no help for someone wanting to sync between a Windows desktop and a Linux netbook.
[01:14] <jwisser> Could some enterprising Windows dev theoretically write a client?
[01:14] <ScottK> (and I have mentioned this point to them and they are waiting for a community developed Windows client)
[01:14] <ScottK> jwisser: Yes
[01:15] <jwisser> Well, I wasn't even expecting a Windows client.
[01:16] <ScottK> OK, I think for what you're looking for it's essential.
[01:16] <jwisser> I was thinking that possibly we could get some OEMs to try to sell *ubuntu netbook/desktop combos on the distinction of Ubuntu One alone.
[01:16] <ScottK> It's not worth our time to do marketing work that just cannabalizes the existing Linux netbook market.
[01:16] <ScottK> I see.
[01:16] <jwisser> ::nods:: Fair point.
[01:17] <ScottK> For syncing, and OEM would be better off, at least today, making a deal to preinstall a dropbox client.
[01:17] <ScottK> and/an
[01:18] <jwisser> Right. We need something to convince them that's not so. :-)
[01:18] <ScottK> Today it is so.
[01:18] <jwisser> Why, specifically?
[01:19] <ScottK> Dropbox is cross platform.
[01:19]  * jwisser waves aside cross-platformness.
[01:19] <jwisser> Anything else?
[01:19] <ScottK> "This will help you sell more netbooks to people that already use Linux on their desktops" is no help.
[01:19] <ScottK> Dropbox is cheaper for more space.
[01:20] <jwisser> 50GB for $10 is identical, no?
[01:20] <ScottK> jwisser: I'd encourage you to do some research on why people think Nokia bought Trolltech.  I suspect that will help you understand the engineering reasons OEMs want a Qt/KDE solution even if they don't know it.
[01:21] <ScottK> OK, they've changed it then.  Initially it was 10
[01:21]  * jwisser goes to do some research on the subject.
[01:25] <amichair> who do I need to pay around here to review and merge some bugfixes?
[01:26] <ScottK> JontheEchidna is Mr. Bugs.
[01:26] <ScottK> amichair: What do you have?
[01:27] <amichair> I'm working on software-properties
[01:28] <ScottK> OK.  It's Python, right?
[01:28] <amichair> yep
[01:29] <ScottK> OK.  I can review that.
[01:29] <amichair> I'm new to that as well, so would love to get feedback
[01:29] <ScottK> OK.  I'm a medium grade Python hacker.  We'll see.
[01:30]  * amichair is trying to figure out where is bzr branch lives...
[01:32] <amichair> oh wait, I need to push (sorry, svn user...)
[01:33] <amichair> is it just 'bzr push'?
[01:33] <maco> tell it where if you havent before
[01:34] <maco> like bzr push lp:~amichair/software-properties/doing-stuff
[01:34] <maco> doing-stuff being your branch name
[01:34] <maco> ~amichair being your launchpad account
[01:35] <maco> assuming you were going to do it by pushing somewhere and doing a merge request. i dont think all the sponsors are clear on that process yet though, so debdiffs are still popular
[01:36] <amichair> how can I tell if it's already associated with a remote location?
[01:37] <jwisser> In case anyone was wondering, this is what we need to *not* do with our marketing: http://phones.verizonwireless.com/motorola/droid/
[01:39] <maco> amichair: i'm looking...
[01:40] <maco> amichair: bzr info
[01:40] <amichair> maco: ok, I suspected so and didn't see it, so I'll just try what u recommended above
[01:42] <ScottK> amichair: You have to commit before you push.
[01:43] <dtchen> you may want to look at other branches, too, that aren't listed in 'bzr info'
[01:43] <maco> oh right...svn users arent used to that
[01:43] <amichair> ScottK: yes, I commited every fix in a separate revision - good habits from svn :-)
[01:43] <amichair> hehe
[01:43] <ScottK> OK.
[01:43] <dtchen> 'bzr info' can be misleading, since you're not confined to what's in .bzr/branch/branch.conf
[01:43] <amichair> maco: bad-habitted ppl aren't used to that :-)
[01:44] <amichair> why is it sending > 10M ? isn't it supposed to be sending only diffs?
[01:44] <maco> amichair: i meant svn people arent used to a 2-step process.  with svn you just commit and it goes remote always right? whereas here you commit locally and push to get it to the remote server
[01:45] <maco> probably because the original doesnt exist at ~amichair/ yet
[01:45] <amichair> maco: yep, exactly.
[01:45] <maco> and future pushes to the same spot will be just the diff
[01:45] <amichair> maco: oh, I figured since it's branched off an existing project, it would know that...
[01:46] <maco> i think this is also the difference between branching and...um i think cloning?
[01:46] <maco> one has the entire history. the other doesn
[01:46] <maco> t
[01:47] <amichair> I started it off with 'bzr branch'...
[01:47] <amichair> well I don't mind, as long as I'm doing what's considered right for u guys :-)
[01:47] <amichair> ok, done
[01:48] <amichair> now where do I find it? what url do I give ScottK to review?
[01:48] <maco> ah ok...so there's branch and  checkout...
[01:49] <maco> go to your launchpad page and hit the code button
[01:49] <maco> and it should be listed as one of your branches
[01:49] <amichair> oh I see - it's 'Branches'. my very first branch!
[01:50] <amichair> yes and it seems to have all previous history too
[01:51] <amichair> hmm... no indication of where it actually branched off from the main project
[01:51] <maco> yeah...i think "init" followed by "checkout" wouldnt have previous history
[01:51] <dtchen> it won't unless you're using using stacking
[01:51] <maco> dtchen: wont what?
[01:52] <dtchen> it won't give any indication
[01:52] <maco> ohok
[01:52] <dtchen> that's more of a loggerhead issue, however
[01:52] <amichair> maco: I read that co just takes the main code and tries to push it back there, which I can't. branch lets me work in my own area.
[01:53] <amichair> so, does this look the way u'd like it to? https://code.launchpad.net/~amichai2/software-properties/fixes
[01:54] <amichair> (wish I could change that 2 to an r... really confusing)
[01:54] <dtchen> almost
[01:54] <dtchen> remember to use the correct changelog-closing syntax, which is LP: #foo
[01:54] <dtchen> if you forget the colon or the hash, it's omitted.
[01:54] <amichair> ok, good to know
[01:55] <amichair> dtchen: any way to update the log message retroactively?
[01:55] <dtchen> also, debcommit(1) is a good thing
[01:55] <dtchen> amichair: the log message isn't that important; the changelog entries are more so
[01:55] <amichair> dtchen: what's that?
[01:56] <dtchen> amichair: a highly recommended tool
[01:56] <dtchen> if you have devscripts installed (and you should), check the man page for it
[01:57] <adiroiban1> hi. Kubuntu install UI app is using the same strings (text) as Ubuntu Ubiquity ?
[01:57] <amichair> I don't, and I will :-)
[01:57] <adiroiban1> or it is a different package ?
[01:57] <dtchen> in a nutshell, you generate commit messages based on entries in debian/changelog. The correct bzr/LP syntax for --fixes is done automatically.
[01:58] <amichair> woah... quite a few dev scripts there :-p
[01:59] <ScottK> adiroiban1: I'm pretty sure it's different.
[01:59] <ScottK> shtylman: ^^^ ?
[02:00] <adiroiban1> ScottK: can you please point me to the source package / project of the kubuntu-installer
[02:00] <adiroiban1> thanks!
[02:00] <ScottK> adiroiban1: It's in the same source package (ubiquity)
[02:00] <ScottK> It's just a different front end
[02:00] <ScottK> shtylman will know for sure.
[02:01] <adiroiban1> ok. looking at the ubiquity source, it looks like 99% of the strings  are reused
[02:01] <adiroiban1> reused / shared
[02:03] <amichair> dtchen: so I manually edit changelog, then use debcommit [files] instead of bzr commit -m?
[02:03] <dtchen> amichair: just debcommit -n
[02:03] <dtchen> amichair: and if that's satisfactory, do the real commit without -n
[02:04] <dtchen> amichair: debcommit takes care of bzr commit -m, as you'll note
[02:04] <amichair> dtchen: oki, and what's the standard for changelog entries?
[02:04] <dtchen> amichair: I'm only referring to the changelog syntax for closing bugs
[02:04] <dtchen> LP: #foo
[02:05] <dtchen> there's some LP-fu on the backend that will link your bzr branch(es) to the bugs, too
[02:05] <amichair> dtchen: bug in general, I see there's urgency, indentation, etc...
[02:05] <dtchen> ah, yes, follow the indentation
[02:05] <amichair> dtchen: or if I want to give a better explanation than the bug description, etc.
[02:05] <dtchen> urgency doesn't really matter as much for Ubuntu source packages
[02:05] <maco> dont change the urgency
[02:05] <maco> as a general rule
[02:06] <maco> most ubuntu devs dont, some dont even realize that it has an effect and just assume its a debian-only thing. it doesnt have a huge effect really anyway...
[02:06] <amichair> and email address, and datetime... is there a tool that generates all this as well?
[02:06] <maco> yes
[02:06] <ScottK> dch -i
[02:06] <dtchen> it does affect build priority, but not in an obvious manner [and not for the typical source upload]
[02:06] <maco> in .bashrc
[02:06] <maco> export DEBEMAIL='maco.m@ubuntu.com'
[02:06] <maco> export DEBFULLNAME='Mackenzie Morgan'
[02:06] <maco> thats in mine
[02:06] <maco> set to what yours should be
[02:07] <maco> and then dch will know what data to fill in
[02:08] <maco> wow looking at .bashrc may have just told me why i cant get ibus working. i left the s off...
[02:09] <maco> no seele? aww
[02:10] <amichair> ok, now is there any way to change it retroactively in all them commits? or I'll just do better next time?
[02:11] <dtchen> amichair: don't worry about the previous commit messages
[02:11] <amichair> dtchen: and the "LP: #num" is just in the dch freetext?
[02:11] <dtchen> amichair: it's in debian/changelog
[02:11] <dtchen> I think that's what you're calling "dch freetext"
[02:12] <amichair> dtchen: I mean the text argument to "dch -i" which scott just mentioned
[02:13] <dtchen> amichair: yes
[02:13] <amichair> just want to clarify, from now on all I do when a rev is ready is "dch -i bla bla [(LP: #num)]" followed by "debcommit [files]"? and that's it?
[02:14] <dtchen> well, I tend to edit stuff in $EDITOR
[02:14] <dtchen> a typical workflow for me would be: dch -i -> $EDITOR -> debcommit -n -> debcommit
[02:14] <amichair> that's "dch -ie" instead?
[02:15] <ScottK> amichair: Just dch -i will open debian/changelog formated for a new revision ready for you to edit.
[02:15] <maco> should open in nano i think as the default
[02:16] <ScottK> Shudder.
[02:16] <maco> (i have EDITOR=/usr/bin/vim in my .bashrc though, so vim opens for me)
[02:16] <amichair> so "dch -i" -> edit (e.g. "bla bla [(LP: #num)]" or multiline with asterisks) -> debcommit on -> debcommit ?
[02:17] <amichair> oops, /on/-n/
[02:18] <maco> looks reasonable
[02:18] <amichair> (I just set vi as well...)
[02:19] <amichair> okily-dokily!
[02:19] <amichair> thanks guys, you've been very helpful :-)
[02:19] <amichair> ScottK: the branch is at https://code.launchpad.net/~amichai2/software-properties/fixes
[02:19] <ScottK> OK
[02:19] <amichair> ScottK: I promise to do the changlog stuff better next time :-)
[02:20] <amichair> ScottK: and I would love any feedback at any level... whatever I can learn from :-)
[02:20] <ScottK> Personally, I prefer a debdiff in a bug, but I'm old fashioned.  Let me see if I can manage this.
[02:21] <amichair> but I gotta get going now, will check in tomorrow, it can wait till then
[02:21] <shtylman> adiroiban1: the strings are the same as ubiquity
[02:22] <adiroiban1> shtylman: thanks! I just wanted to be sure
[02:22] <amichair> thanks everyone!
[02:22] <adiroiban1> the kubuntu frontend looks great :)
[02:22] <shtylman> thanks :)
[02:23] <JontheEchidna> amichair: whoa, you rock
[02:23] <JontheEchidna> that's a lotta fixes
[02:24] <amichair> JontheEchidna: a lot? that's just one day! including learning python :-)
[02:24] <JontheEchidna> :o
[02:24] <amichair> JontheEchidna: there's actually a tough one I couldn't close, a crash that looks like a messed up stack frame or something, very strange.
[02:25] <adiroiban1> shtylman: kudos for the great UI. I will come back with some i18n bugs :)
[02:25] <amichair> I could use some help there, maybe tomorrow :-)
[02:25] <amichair> cya!
[02:25] <maco> wow
[02:25] <JontheEchidna> amichair: the one where clicking the checkbox crashes? Yeah, very strange
[02:25] <JontheEchidna> it's also been around forever :(
[02:26] <amichair> JontheEchidna: yep. happens also with keyboard. I got to one method call that if commented out crashes, if inlined doesn't crash, and if the first line in the nested call is changed to 'return', still crashes. hence it seems like a corrupt stack at the C level or something... really dunno
[02:27] <shtylman> adiroiban1: sounds good
[02:27] <JontheEchidna> could be a PyQt issue
[02:27] <JontheEchidna> if regular Qt apps had such bugs we would seem them a lot more often, I'd think
[02:27] <amichair> but I really don't know enough about it, that's just a very wild guess :-)
[02:28] <amichair> JontheEchidna: well maybe I'll look deeper into it when I have the time. but I figured I'd start with quantity over quality :-p
[02:29] <JontheEchidna> hehe
[02:30] <amichair> anyway, it's past my bedtime. cya guys around!
[02:38] <maco> hmm pyqt is implemented in C still right? not C++?
[02:39] <ScottK> What makes you say that?
[02:40] <DarkwingDuck> Hey ScottK, I'm sorta back.
[02:41] <ScottK> DarkwingDuck: Welcome.
[02:41] <DarkwingDuck> :) Push though a bit of pain but, I'm starting to try and get back into it.
[02:41] <Lex79> JontheEchidna: are you merging with debian testing?
[02:42] <JontheEchidna> Lex79: yeah, for the LTS we're merging with squeeze (testing)
[02:42] <JontheEchidna> but really it's not that big of a difference for the KDE packages
[02:42] <JontheEchidna> since it just means that the latest n' greatest shows up 10 or so days later
[02:43] <ScottK> Or 40
[02:43] <ScottK> Since KDE tends to get caught up with other stuff in transitions.
[02:43] <Lex79> ok
[03:00] <JontheEchidna> could I get a sponsor for bug 477910?
[03:04]  * akonadi .
[03:05] <JontheEchidna> Lex79: libs-experimental is going away in 4.4, probably not worth it to merge
[03:05] <Lex79> uhm :(
[03:05] <Lex79> ok thank you
[03:06] <JontheEchidna> no prob.
[03:30] <ScottK> JontheEchidna: Looking
[03:32] <ScottK> JontheEchidna: Have a look at rmadison libboost1.40-dev and then tell me why I don't want to upload your diff?
[03:33] <JontheEchidna> universe, careless of me
[03:33] <ScottK> 1.40 for Boost is probably what we want, but we didn't decide yet.
[03:34] <ScottK> It's not a big deal.
[03:35] <JontheEchidna> should I update the diff or?
[03:36] <ScottK> I don't think there's a rush.  We'll decide at UDS week after next, so I'd just let it wait.
[03:36] <JontheEchidna> ok
[03:38] <ScottK> So apparently Flash sucks no matter what OS you use: http://twitter.com/BritishRT/statuses/5488077051
[03:57] <Lex79> I'm wondering if fix_phonon_include patches could be removed for lucid...
[03:57] <Lex79> someone knows?
[04:24] <maco> Nightrose: Script: http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js:22
[04:24] <maco> Nightrose: buzz.kde.org still makes firefox not-happy for me
[04:24] <maco> it says that script is either busy or not responding
[07:12] <markey> haha
[07:12] <markey> anyone know a certain "Herald Strait"?
[07:13] <markey> the face rings a bell...
[07:13] <markey> I could swear it's... straitlogger or something
[07:15] <markey> http://boycottnovell.com/2009/11/07/ubuntu-9-10-works-well/
[08:17] <Peace-> Hi
[08:42] <amichair> what exactly does 'Triaged' mean as a bug status?
[08:45] <tsimpson> Triaged: the bug supervisor considers that the bug report contains all information a developer needs to start work on a fix.
[08:45] <tsimpson> from https://help.launchpad.net/Bugs/Statuses
[08:46] <Peace-> 2. (Government, Politics & Diplomacy) the principle or practice of allocating limited resources, as of food or foreign aid, on a basis of expediency rather than according to moral principles or the needs of the recipients
[10:13] <MelisU> Why are KDE, Kubuntu and you folks so awesome?
[10:14] <Peace-> xD
[10:14] <Peace-> thanks
[10:14] <acey> Hi all
[10:14] <MelisU> yw, but I demand an answer
[10:15] <Peace-> i have not read i am doing support on kubuntu right now
[10:15] <Peace-> so
[10:15] <Peace-> xD
[10:19] <acey> :)
[10:56] <Quintasan> MelisU: Because we have Ninjas
[10:56] <Quintasan> ~ninjas
[10:56] <Quintasan> oh, bot's dead
[10:57] <Quintasan> and apachelogger ain't here
[10:58] <amichair> maco, dtchen, ScottK: I followed your changlog advice of yesterday, but I see it increases the changlog version to 0.75.5ubuntu1 instead of 0.75.6... is this normal?
[10:59] <Quintasan> Riddell: have you reviewed my debdiff? Can I push changes to bzr or it needs more love?
[10:59] <Nightrose> maco: yea i know :( that's why i asked for coding help
[11:00] <amichair> is the correct next version 0.75.6 or 0.75.5ubuntu1?
[11:02] <amichair> Quintasan: apachelogger stormed out yesterday, said he needs a week to cool off :-(
[11:02] <Quintasan> amichair: what's the package?
[11:03] <amichair> Quintasan: software-properties
[11:03] <Quintasan> amichair: and what are you trying to do exacly?
[11:04] <Hatl> hi! i updated my kubuntu to 9.10. now it takes over two minutes until the startup is finished. i created a bootchart: http://h.imagehost.org/view/0687/gerhard-nb-karmic-20091108-1
[11:04] <Hatl> can anybody tell me whats wrong?
[11:04] <amichair> Quintasan: I made a bunch of bugfixes, and the fellas taught me how to make proper changlogs with dch and debcommit, but I see the auto-version-increment is inconsistent...
[11:04] <Quintasan> sure it is
[11:04] <amichair> Quintasan: so I'm supposed to change it manually? or is this configured somewhere?
[11:04] <Quintasan> amichair: version format in ubuntu goes like this -> package.version-<debian_revision>-ubuntu<ubuntu-revision>
[11:05] <Quintasan> amichair: What's the previous version?
[11:05] <amichair> Quintasan: I'm looking down the changelog and see no 'ubuntu' in version numbers, just 0.75.1, 0.75.2,...,0.75.5
[11:06] <Quintasan> hmm
[11:06] <Quintasan> looks like this is a ubuntu specific package
[11:06] <amichair> Quintasan: it's an ubuntu-only package I guess, so is the numbering different?
[11:07] <Quintasan> amichair: change it manually to 0.75.6
[11:07] <amichair> Quintasan: am I supposed to fix it manually, or is there something to configure or a param to dch or something like that?
[11:07] <Quintasan> amichair: dunno about parameter, I usually fix it by hand when version's wrong
[11:08] <amichair> Quintasan: ooh, and I just noticed it says 'kramic' instead of 'unreleased' too
[11:08] <amichair> Quintasan: which I'm assuming from the previous entry is the way to go...
[11:08] <Quintasan> amichair: I guess they won't kill you for wrong version
[11:08] <amichair> Quintasan: :-)
[11:08] <Quintasan> amichair: I would replace karmic with lucid if it's an update
[11:09] <amichair> Quintasan: too bad the tools don't make this less error-prone, as is the point of having tools :-)
[11:09] <Quintasan> amichair: I haven't seen you around here, are you new here or you had a break?
[11:09] <Quintasan> amichair: oh
[11:09] <amichair> Quintasan: new here
[11:09] <Quintasan> amichair: dch automatically changes to lucid but I suppose we don't have updated it yet
[11:10] <Quintasan> didn't update*
[11:10] <amichair> Quintasan: it's my first kubuntu dev work, so I'm learning the basics (thanks!)
[11:10] <Quintasan> amichair: everyone has to start somewhere :P
[11:11]  * Quintasan is JontheEchidnas minion
[11:11] <Quintasan> :P
[11:11] <amichair> Quintasan: and when they merge stuff, they renumber the versions to be consistent with merge order?
[11:12] <Quintasan> uhh, it's kinda confusing, you look for latest merge entry in ubuntu changelog and copy newer ones from debian
[11:13] <Quintasan> amichair: look on https://wiki.ubuntu.com/Kubuntu/LucidKDEMerges for procedure, it's giving me and headache and JontheEchidna has done already 6 merges :P
[11:16] <amichair> ScottK: I added another one to the bunch, hope the changelog is ok now :-)
[11:16] <Quintasan> urgh, wtf is with kubuntuforums.net? TBH I find it ugly
[11:20] <amichair> Quintasan: are you one of the ancient ones?
[11:21] <Quintasan> amichair: not really
[11:23] <amichair> Quintasan: who decides whether bugs of importance 'wishlist' should be implemented?
[11:24] <Quintasan> amichair: I think it's just a matter if someone you want to do it shows up
[11:24] <Quintasan> amichair: most bugs in wishlist are [needs-packaging] bugs
[11:25] <amichair> Quintasan: isn't that a problem? shouldn't there be some kind of overview of what's appropriate and what's feature creep or bloat or unmaintainable?
[11:28] <yadudoc>  Hi , I removed amarok nightly and installed amarok from the ubuntu repos... but now I'm getting these errors.. http://codepad.org/4U0v0i8A . Could someone please help me with this ?
[11:31] <amichair> Quintasan: there's something fun about finding a duplicate bug report *after* you've already fixed it :-)
[11:33] <yadudoc> amichair, :( i tries cleaning my apt-cache thinking the packages were corrupt and ended up downloading the whole thing .... and downloads burn a hole in the pockets here
[11:33] <yadudoc> *tried
[11:34] <amichair> yadudoc: did u try asking in #kubuntu ? that is the support channel
[11:35] <yadudoc> amichair, I asked at #amarok and they forwarded me here. Should I ask at #kubuntu ?
[11:36] <yadudoc> amichair, asking ... :)
[11:36] <amichair> yadudoc: yes, try there. #kubuntu is the support channel, whereas #kubuntu-devel is the developer channel
[11:49] <Quintasan> amichair: that's why I always look for duplicates, mark them as a duplicate the close the main one :P
[12:01]  * markey fetches KDE 4.4.3
[12:01] <markey> yay
[12:01] <markey> you rock :)
[12:01] <markey> well, that is, if it works
[12:01] <markey> we shall see :p
[12:01] <markey> err
[12:01] <markey> 4.3.3 even
[12:01] <markey> not from the future
[12:07] <apachelogger> amichair: ping
[12:07] <amichair> apachelogger: welcome back :-)
[12:07] <apachelogger> amichair: did you get your changes merged yet? :)
[12:08] <amichair> apachelogger: waiting for ScottK to review... wanna have a look?
[12:08] <Quintasan> apachelogger: hiho
[12:08] <apachelogger> sure
[12:08] <apachelogger> yo Quintasan
[12:08]  * apachelogger notes that Quintasan is not very timelordish
[12:09] <amichair> but I'm gonna need lots of feedback! I want to learn! no 'tl;dr: I guess it's ok let's merge' :-)
[12:09] <amichair> it's at https://code.launchpad.net/~amichai2/software-properties/fixes
[12:09]  * apachelogger is a furious reviewer anyway :P
[12:10] <Quintasan> apachelogger: well, dunno what I'm supposed to do, there is so much work that I'm lost :PP
[12:10] <apachelogger> first fix is already why I find python so superior to C++
[12:10] <apachelogger> Quintasan: what do you want to do anyway :P
[12:11] <Quintasan> lol dunno, I was about to merge something :P
[12:11] <apachelogger> merging sounds good
[12:11] <apachelogger> though
[12:11] <apachelogger> I'd really appreicate some solution to how-can-apachelogger-track-todo-items-for-the-whole-time-to-get-timelord-more-organized
[12:12] <Quintasan> Wave?
[12:12] <Quintasan> :D
[12:13] <amichair> anyone here know the insides of pyqt?
[12:13] <apachelogger> amichair: r586 is no good
[12:13] <apachelogger> see my commit msg why
[12:13] <apachelogger> what is not in the application/pgp-keys mimetype should not be supported
[12:13] <Quintasan> apachelogger: got few seconds? seems like Riddell is busy and my kdetoys merge aint complicated
[12:13] <apachelogger> not at all, not even virtually
[12:13] <amichair> apachelogger: where do I see that
[12:14] <apachelogger> amichair: https://code.edge.launchpad.net/~amichai2/software-properties/fixes
[12:14] <amichair> apachelogger: I thought so too, asked about it here
[12:14] <apachelogger> or if you do in your branch ... bzr log 584
[12:14] <apachelogger> or you install qbzr and run bzr qlog
[12:14] <apachelogger> latter I can recommend
[12:14] <amichair> apachelogger: is that upstream? couldn't find where the mime types are set
[12:14] <apachelogger> anywhere really :P
[12:14] <apachelogger> amichair: you can google for freedesktop.org mimetype spec
[12:15] <apachelogger> that should turn up the underlying spec ... it basically defines that some regular mimetypes come form a shared spec package directly from freedesktop.org
[12:15] <apachelogger> on top of that desktops can stack new ones
[12:15] <apachelogger> or applications for that matter
[12:15] <apachelogger> thus really anyone can provide a mimetype
[12:15] <amichair> I'm looking at the web link, don't see merge comment
[12:15] <apachelogger> the default ones are in /usr/share/mime/ if I am not mistaken
[12:16] <apachelogger> amichair: 584. By Harald Sitter on 2009-09-07
[12:16] <apachelogger> KDE frontend: replace old manual listing of file endings for key import
[12:16] <apachelogger> with mimetype based model (no need to support old stuff since it is so
[12:16] <apachelogger> incredibly wrong... ending-wise that is)
[12:16] <amichair> apachelogger: oh ok, I read that :-)
[12:16] <apachelogger> also: that particular implementation makes the defined name untranslatable
[12:17] <apachelogger> i.e. the dialog would show "PGP keys" in the filter bar no matter what
[12:17] <amichair> apachelogger: I figured what was really terribly wrong was that the previously set suffixes contained truly wrong suffixes which are incompatible
[12:18] <amichair> apachelogger: but I totally agree, just didn't know where the mimetypes are set
[12:18] <amichair> apachelogger: so, where's the bestest place to add it?
[12:18] <apachelogger> we should not support them fileendings
[12:18] <amichair> apachelogger: which?
[12:19] <apachelogger> that is my point here, they are wrong, they dont get more right if we manually add it to the mimetype
[12:19] <apachelogger> amichair: the old ones
[12:19] <amichair> apachelogger: of course. but gpg *is* supported, and was missing after 584 rev., even though all keys I've seen used are gpg...
[12:20] <amichair> amichair: so where is the bestest place to add gpg to the pgp mime type suffix list?
[12:22] <apachelogger> amichair: where is gpg supported?
[12:22] <apachelogger> .gpg is an encrypted file
[12:22] <apachelogger> not a key
[12:22] <amichair> apachelogger: importing gpg keys works, it's all I ever used
[12:22] <apachelogger> same goes for pgp
[12:23] <apachelogger> amichair: gpg keys end with asc, pkr or skr
[12:23] <apachelogger> any key ending with something else is also just wrong
[12:23] <apachelogger> check with kgpg
[12:23] <apachelogger> it will spit out asc
[12:23] <apachelogger> so will the gpg cli tool
[12:23] <amichair> oh in that case my rev. should be destroyed immediately!
[12:23] <apachelogger> gpg and pgp are not valid file endings for keys
[12:24] <amichair> amichair: I guess my test files were bad
[12:24] <apachelogger> well, where did you get the files from?
[12:24] <apachelogger> or did you have them lying around?
[12:24] <amichair> amichair: that's what I'm trying to figure out :-)
[12:27] <apachelogger> anyhow
[12:27] <apachelogger> moving on
[12:27] <apachelogger> amichair: copright and author in DialogAdd.py are wrong :P
[12:27] <apachelogger> amichair: DialogAdd should implement a KDialog, not a QDialog
[12:28] <apachelogger> http://api.kde.org/4.x-api/kdelibs-apidocs/kdeui/html/classKDialog.html
[12:28] <amichair> apachelogger: not entirely... it was mostly copied :-)
[12:28] <apachelogger> amichair: yeah, thus the wrongness :P
[12:28] <apachelogger> amichair: did you stick to the code used in Gtk's DialogAdd?
[12:29] <amichair> apachelogger: I thought copied copyrighted works remain under the original authors copyright
[12:29] <apachelogger> because the check+line seems a bit different :)
[12:29] <apachelogger> amichair: where did you copy from?
[12:29] <amichair> apachelogger: well it was a mix of kde DialogEdit and gtk DialogAdd
[12:29] <amichair> apachelogger: one for gui, the other for functionality
[12:29] <apachelogger> amichair: gtk > kde in this case, since gtk forms a reference implementation
[12:30] <apachelogger> amichair: check_line misses a ppa check at the very least
[12:30] <apachelogger> amichair: and yes, copied work remains under original copyright :)
[12:30]  * apachelogger assumed you mastered that up on your own
[12:31] <amichair> apachelogger: yep, DialogEdit inherits QDialog not KDialog, I copied from there
[12:31] <apachelogger> still should implement a KDialog, so should DialogEdit I suppose
[12:31] <amichair> apachelogger: as for the ppa check.. well there are 4 different versions of this method in the package, not all consistent
[12:31] <apachelogger> amichair: maybe check the bzr log, if Riddell mentioned a reason for using QDialog over KDialog, then maybe add a comment to DialogAdd and DialogEdit stating why to use QDialog and not KDialog
[12:31] <apachelogger> if not, then try porting to KDialog
[12:32] <apachelogger> amichair: yeah, software-properties is a collection of duplicated rap
[12:32] <apachelogger> crap
[12:32] <apachelogger> thus my frustration yesterday
[12:32] <apachelogger> other than the stuff mentioned DialogAdd should be good
[12:36] <Quintasan> apachelogger: http://hs.quintasan.pl/kdetoys.tar.gz -> mind looking if it's good enough?
[12:36] <apachelogger> I always thought the policy suggests reporting bugs about merge reviews? :P
[12:37] <apachelogger> amichair: code looks good otherwise, get the remaining issues fixed and I'll take it for a test drive
[12:37] <Quintasan> apachelogger: I'm too lazy to report a bug, I propably will upload diffs over 9000 times so I'd rather ask someone to look at it first :P
[12:37] <apachelogger> amichair: oh, btw, you really really want to make the changelog reflect all larger/important changes
[12:37] <Quintasan> also, lol @ konq, shows only top of the page
[12:38] <apachelogger> amichair: also as long as there is an entry saying UNRELEASED you should add your stuff just to that entri
[12:38] <apachelogger> dch -a will take care of that
[12:38] <apachelogger> Quintasan: +kdetoys (4:4.3.3-0ubuntu1~ppa1) karmic; urgency=low
[12:38] <apachelogger> ppa?
[12:39] <amichair> apachelogger: yes, I had a little tutoring session about debcommit and all yesterday (after all but the last commit)
[12:40] <amichair> apachelogger: ok, I was told to use dch -i but I'll read up on it :-)
[12:41] <apachelogger> Quintasan: in DebianVsNew uploaders differs even though it should not
[12:41] <apachelogger> Quintasan: is there any point in having the build-deps bumped?
[12:41] <apachelogger> if not, please refrain from that
[12:41] <apachelogger> amichair: dch -i will increment
[12:41] <apachelogger> dch -a will add a new change
[12:41] <amichair> apachelogger: and when should either be used?
[12:42] <apachelogger> dch -a as long as the series field says UNRELEASED
[12:42] <apachelogger> it means the version at hand was not uploaded to the archives
[12:42] <apachelogger> so you can just add your changes to that entry
[12:42] <amichair> and then the date/author is lost? or appended somehow as well?
[12:43] <apachelogger> just try it out :P
[12:43] <amichair> oki :-)
[12:43] <apachelogger> remove your entry from debian/changelog, so mine is the latest
[12:43] <apachelogger> then run dch -a and see what happens
[12:44] <apachelogger> Quintasan: +Section: kde in kteatime
[12:44] <amichair> ok, well I'll try it out for next commit, since I have 6 missing changelogs anyway :-)
[12:45] <apachelogger> Quintasan: drop that, it is redundant with the source section ... section gets inherited from the source section, if it is added to the binary section it will just override that
[12:45] <apachelogger> Quintasan: +Section: games ... in kweather <- looks ultimately wrong?
[12:45] <apachelogger> Quintasan: you lost the README.source file
[12:45] <amichair> apachelogger: btw the ppa format is not documented there (or supported by SourceEntry, it seems) - what's the format?
[12:46] <apachelogger> Quintasan: it would be really nice if youd review your diffs before proposing them :S
[12:46] <amichair> apachelogger: perhaps it should be added to SourceEntry, so all users get it for free?
[12:46] <apachelogger> merging is not russion roulette but a perfect oportunity to clean up our crap
[12:47] <apachelogger> amichair: I dunno, take a look at the gtk stuff
[12:47] <apachelogger> whatever it does... just duplicate it :P
[12:47] <amichair> apachelogger: there's no mention of it other than that missing check
[12:47] <apachelogger> just do what the gtk version does :P :P :P
[12:47] <apachelogger> dont think about it ... there is no logic in our pythonware
[12:48] <apachelogger> we duplicate that utf8(str) stuff in almost all apps instead of creating a convenience function
[12:48] <amichair> apachelogger: should I copy over all the gtk-specific bugs from launchpad too? :-P
[12:48] <apachelogger> translation is handled 100% different in each app
[12:48] <apachelogger> there is no logic
[12:48] <apachelogger> amichair: if they dont care, why should we :P
[12:48] <amichair> apachelogger: because we want to be bug free!
[12:48] <apachelogger> it's just a suggestion, but usually when you start digging too deep you will end up with an urge to rewrite the app :P
[12:49] <amichair> free as in speach, free as in beer, free as in bugs
[12:49] <apachelogger> amichair: give it a shot :)
[12:49] <amichair> apachelogger: yes, I already got that urge... so much duplicate code!
[12:49] <apachelogger> see
[12:49] <amichair> apachelogger: and sometimes python code is soooo verbose... got to get used to it
[12:50] <apachelogger> python is ugly and stupid(tm)
[12:50] <apachelogger> anyhow
[12:50] <apachelogger> amichair: if you rewrite it ... please take a look at who UI construction is handled in jockey and apturl
[12:50] <amichair> apachelogger: like yesterday I asked: http://paste.ubuntu.com/311619/
[12:50] <apachelogger> theu use a centralized UI abstraction class where strings get passed through ... especially jockey uses a wonderful approach to that
[12:51] <apachelogger> software-properties is supposed to use such a design from what the implementation looks like
[12:52] <apachelogger> amichair: first is no go
[12:52] <amichair> well I'm not gonna rewrite it today... I feel too much of a noob to make huge changes. once all bug are gone, maybe I'll start with refactoring.
[12:52] <amichair> apachelogger: yes, that's what I've been told
[12:52] <apachelogger> amichair: I'd jump into refactoring first ... some bugs might autoresolve by that
[12:53] <apachelogger> amichair: that looks in python worse than it would look in c++ :P
[12:53] <amichair> amichair: and in python it does look a bit ugly, in other languages more natural. but the advantages are many...
[12:53] <apachelogger> what would the advantage be?
[12:53] <apachelogger> other than making it difficult to read in almost every language
[12:53] <amichair> I beg to differ:
[12:54] <amichair> if going over a method that does lots of things, with the first format, I need only parse 2 words to know that all the code does is enable/disable a button.
[12:54] <amichair> with the second, I need to parse all 8 lines to reach the same conclusion
[12:54] <amichair> it's much more work to maintain and read
[12:55] <amichair> and makes everything... 8 times longer
[12:55] <amichair> the difference between maintaining a 100 line or 800 line class is huge!
[12:55] <amichair> I'm not talking about mangling everything onto one line
[12:55] <amichair> u can keep things simple and readable, and still save a lot of space, bugs, and time
[12:55] <apachelogger> amichair: you only need to look at 2 words because you know what you are looking for
[12:56] <apachelogger> that might be different when you hacked 3 months in cpp
[12:56] <apachelogger> also, inthe second you read three words
[12:56] <amichair> nope. I see it's a single method call on a single object.
[12:57] <amichair> in the second case, there might be variable assignments in there, or other things that are easy to miss, or it might be referencing two different objects with similar names...
[12:57] <apachelogger> that is unnecessary information
[12:57] <amichair> apachelogger: and who's to guarantee the last line does enable button_edit_ok2?
[12:57] <apachelogger> amichair: that is also unnecessary information
[12:57] <amichair> u have to read and process the whole thing, every time u look around that code
[12:58] <apachelogger> no, you look at the if and the setenabled
[12:58] <apachelogger> the true is just so you know that the call goes to an object and not about an object
[12:58] <amichair> yes, but there are 2 ifs, one else, and 3 setenabled, and u have to find them horizontally and vertically before u can be sure
[12:58] <apachelogger> other than that no parsing is done
[12:59] <apachelogger> amichair: python enforces indention
[12:59] <apachelogger> in other languages I might agree on the finding part, in python I dont
[12:59] <amichair> apachelogger: indentation doesn't help in this case
[12:59] <apachelogger> ah well
[12:59] <apachelogger> pointless discussion
[12:59] <amichair> apachelogger: I still can't tell the second if doesn't have within the indented block and extra variable assignment...
[12:59] <apachelogger> here is the ultimate reason not to use the first
[12:59] <apachelogger> you are not alone
[13:00] <apachelogger> anyone who is not experienced enough to prase the former will have to spend a great deal of time thinking about it
[13:00] <amichair> apachelogger: that's the same reason I'd prefer the first. less work for everyone else :-)
[13:00] <apachelogger> and if you have loads of such calls then the unexperienced person is boned
[13:00] <apachelogger> eventually driving him away
[13:00] <apachelogger> amichair: yeah, because they leave
[13:01] <apachelogger> you always have to consider that however looks at the code after you created it might not know programming all to well, or python for that matter
[13:01] <amichair> from my experience, code quality degrades with proportion to both time and verboseness
[13:01] <apachelogger> because he wantes to get started and stuff, so he tries to hunt down some minor issue
[13:01] <apachelogger> hits that line
[13:01] <apachelogger> and gives up
[13:02] <apachelogger> trust me, I had a lotta discussion about this kind of stuff the past few weeks ... it always comes down to using technically less advanaced solutions for the sake of success
[13:03] <amichair> apachelogger: having someone who doesn't know how to code (in any language) work on code is problematic in many ways... but I see your point.
[13:03] <amichair> in any case, I see this is the standard here, and I respect it
[13:03] <amichair> which is why, variations of these 8 line appear in 4 different places, rather than 1 line each :-)
[13:03] <apachelogger> in austria ~50 % of all software projects fail completely because too much engineering gets put into generally simple things
[13:04] <amichair> apachelogger: that would be a point in favor of the more concise writing, from my pov
[13:04] <amichair> it's much easier to create/hide/miss bugs in a 40 line method than a 5 line method
[13:04] <apachelogger> amichair: what you propose is too much engineering
[13:04] <Quintasan> apachelogger: we will be building 4.3.3 against 4.3.2 libs?
[13:05] <amichair> apachelogger: it's syntax, not engineering. they are semantically equivalent 100%
[13:05] <apachelogger> amichair: that builds on the assumption of single-person maintenance
[13:05] <apachelogger> amichair: the combo makes it bad
[13:05] <amichair> overengineering would be making 3 classes to handle just that snippet :-)
[13:05] <apachelogger> combine unreadable syntax with high glevel engineering and I can tell you that the project will fail in 99% of all possible cases
[13:06] <apachelogger> amichair: not overengineering
[13:06] <apachelogger> in fact, overengineering just increases the effort of getting used to the code base
[13:06] <apachelogger> I am talking readability at large here
[13:06] <amichair> apachelogger: again, 'unreadable syntax' is what u call the second, and I call the first :-)
[13:07] <amichair> apachelogger: some of our arguments are identical, just different pov
[13:07] <apachelogger> amichair: the former is unreadable syntax, google for unreadable C and you will stuff like that, just written in C
[13:07] <apachelogger> any good coding standard will explicitely mention to not use the first version
[13:07] <apachelogger> it is more efficient in about all aspects, but not the most important one, which is making the code accessible to a team of different people
[13:08] <amichair> let me give u a simpler example, making my point: http://paste.ubuntu.com/313265/
[13:08] <apachelogger> Quintasan: no, but technically 4.3.3 depends 4.3.0
[13:08] <apachelogger> not 4.3.1 not 4.3.2 not 4.3.3
[13:09] <apachelogger> abi is all fixed within a series
[13:10] <Quintasan> apachelogger: damn, I'd be better with copying Debians work and applying our changes there
[13:10] <apachelogger> amichair: those are not equal statements
[13:10] <apachelogger> Quintasan: quite possibly :P
[13:10] <Quintasan> also, wiki should link to SID not experimental, can I change this?
[13:10] <apachelogger> Quintasan: or you could create an app that does automerge :P
[13:11] <Quintasan> lol
[13:11] <apachelogger> Quintasan: I seem to remember that there was some mail about merging from experimental
[13:11] <Quintasan> that would be another thing that Timelord would have to fix :P
[13:11] <apachelogger> better check ubuntu-devel or ubuntu-devel-discuss or something first
[13:11] <amichair> apachelogger: (assuming the method return a boolean, of course)
[13:11] <Quintasan> apachelogger: packages.debian.org/source/experimental/kdetoys shows there is no such package
[13:12] <apachelogger> amichair: those are two different things
[13:12] <Quintasan> while sid works
[13:12] <amichair> or maybe just replace it with something_or_other == good_thing
[13:12] <apachelogger> amichair: this is a bad example since it largely depends on what should be returned
[13:12] <apachelogger> obviously you will not condition a bool to return a bool
[13:13] <amichair> apachelogger: that's exactly that 'obviously not in this case' I was aiming for...
[13:13] <apachelogger> esp not if the coding standard suggests var names to include data types
[13:13] <Quintasan> apachelogger: also, we are just comparing debian dirs, so why download to whole source rather than bzr branch?
[13:13] <Quintasan> dir
[13:13] <Quintasan> grr
[13:13] <amichair> apachelogger: all I'm saying is that in many other cases, as before, I read it the same as in this case. it's just much more words and work to do the same thing, and just as readable
[13:14] <apachelogger> no
[13:14] <amichair> corrected here: http://paste.ubuntu.com/313272/
[13:14] <apachelogger> they are different things :P
[13:14] <apachelogger> in one you try to close the door to see that the door was open hence open the door so it is open again, of which you are sure now, since you closed it
[13:15] <apachelogger> in any other you enter the room, check if the window is open and if so, turn off the radiator, and close the door unless the window is closed in which case you turn on the radiator and leave the door open
[13:16] <amichair> I think my mind just had a buffer overrun :-)
[13:17]  * apachelogger can trigger that
[13:18] <apachelogger> amichair: the examples are to suggest the difference between making simple things complicate while making complicated things simple
[13:19] <amichair> apachelogger: again, that argument is problematic, because from my pov the option I prefer *is* the one that makes things simpler
[13:19] <amichair> amichair: that's why I prefer it!
[13:19] <apachelogger> you can also turn off the radiator after entering the room, but that depends on the assumption/knoweldge that the room was not left while the window was open and the radiator off, since the door was closed
[13:19] <amichair> see that? I'm writing to myself now, that buffer overrun is about to cause a segfault
[13:20] <apachelogger> amichair: those are not options
[13:20] <apachelogger> those are different cases
[13:20] <apachelogger> either you enter the room and check if stuff is in order and then set action, or you enter the room and set action, knowing that stuff must be in order because otherwise you would not have left the room previously
[13:21] <apachelogger> so for someone who does not yet know that the room wont be left unless the windows i closed and the radiator turned on it will be difficult to understand why you can just enter the room and turn the radioator off without running into the problem that the radioator might already be off
[13:22] <Quintasan> zomfg, the uploader issue is s/trigger/armin
[13:22] <Quintasan> apachelogger: I should keep what debian has in Uploaders?
[13:22] <apachelogger> sure
[13:22] <apachelogger> the field only matters to them anyway :P
[13:22] <apachelogger> the less diff, the better
[13:22] <Quintasan> and drop Sections?
[13:22] <apachelogger> Quintasan: yes
[13:23] <Quintasan> apachelogger: I'm copying the vcs-bzr fields too, is that okay?
[13:24] <apachelogger> copying from where?
[13:24] <amichair> apachelogger: so, would u still want me refactoring the package? :-P
[13:24] <Quintasan> apachelogger: form our control to debian's
[13:25] <Quintasan> apachelogger: will lucid still have -kde4 packages?
[13:26] <Quintasan> we could drop Conflicts and Replaces lines if we drop -kde4 packages
[13:26] <apachelogger> amichair: as long as you keep the code comply with the particse applied until know
[13:27] <apachelogger> Quintasan: -kde4 needs to stay at least as long as we support releases that had the -kde4 packages
[13:27] <Quintasan> kay, copying over
[13:27] <apachelogger> so at least until 8.04 reaches EOL which might be the case
[13:27] <apachelogger> Quintasan: the vcs tags need to be in the new control
[13:28] <Quintasan> yup, so I removed what debian supplies and placed our links to bzr there
[13:30] <amichair> is there a preferred way to fix/update a previous commit? so that they can be applied without interference form other commits in between?
[13:33] <apachelogger> bzr revert I suppose
[13:33] <Quintasan> apachelogger: we don't have README.source, I guess I will copy it, right?
[13:34] <amichair> revert destroys the local changes, no?
[13:34] <ryanakca> amichair: I believe so
[13:35] <ryanakca> amichair: If you're using git, you could go 'git rebase -i'... but I guess you're using bzr
[13:35] <amichair> ryanakca: yep, bzr
[13:36] <amichair> I saw there's an uncommit, wonder if it can be used this way. uncommit a particular revision, append to the modifications, and commit
[13:36] <ryanakca> amichair: Try the bzr-rebase package.
[13:36] <ryanakca> amichair: But that would squish the current revision with the previous one and the changes you wanted to make to the previous one, no?
[13:39] <ryanakca> apachelogger: Why would we need to keep -kde4 until then? People wouldn't be doing a direct upgrade, and on the way up the versions, wouldn't the replaces lines do their magic and give people the packages without -kde4? (I'm guessing here)
[13:41] <amichair> ryanakca: it seems uncommit can only work on last revision, or everything from last to X. no good for me.
[13:42] <ryanakca> amichair: *nod*... bzr-rebase might do the trick then.
[13:42] <Quintasan> ryanakca: because we support 8.04 for err, few years and our policy is to provide smooth transition from any supported version :P
[13:43] <ryanakca> Quintasan: Despite jumping versions being (or having been?) unsupported. Ok, thanks :)
[13:47] <Quintasan> apachelogger: I'm doing a debdiff between debian's kde and our 4.3.3 from ppa, is that alright? looks like you complained about ~ppa1 in name :P
[13:48] <Quintasan> merging is even moar time consuming than compiling a new release :P
[13:53] <amichair> apachelogger: so how would u like it? I put the old 'informative' changelog message on the new revision which actually fixes the previous one?
[13:55] <amichair> apachelogger: or make a separate message in changelog and commit message, one for releas and the other describing the actual changes in rev.?
[13:57] <Quintasan> apachelogger: http://hs.quintasan.pl/kdetoys-ver666.tar.gz <-- this must be good, I swear upon gods
[13:57] <Quintasan> I diffed, then diffed and diffed and everything seemed right
[13:58] <Quintasan> or maybe my brain is that tired and it want's me to stop
[14:03] <amichair> apachelogger: when changing all dialogs from QDialog to KDialog, is there anything in particular I should take notice of? or is it fully backwards compatible?
[14:23] <apachelogger> ryanakca: I would prefer being save, for the love of our users
[14:24] <apachelogger> amichair: dunno, might need changes kdialog is more magical than qdialog
[14:24] <apachelogger> amichair: I really dont care how you unsort the commit mess :P
[14:46] <JontheEchidna> review on Planet KDE: http://ciesbreijs.blogspot.com/2009/11/freedom-desktops-closing-in-on-me.html
[14:54] <amichair> apachelogger: how about the other fixes?
[14:57] <ghostcube> hmm the kernel update from today fixes my uvc driver bug
[15:03] <ryanakca> Is merging a package that Debian has in a VCS any different than otherwise (cmake packaging is stored in Git in Debian)?
[15:21] <ryanakca> Also, why do we add the build-dep on libxmlprc-core-c3-dev if Debian doesn't?
[15:22] <ryanakca> (for cmake that is)
[15:30] <claydoh> apachelogger: https://wiki.kubuntu.org/Kubuntu/GettingInvolved/Support
[16:42] <ryanakca> Can someone review my cmake merge on REVU ( REVU hasn't updated yet, should appear shortly: http://revu.tauware.de/p/cmake )
[16:44] <ryanakca> ... errr... merge-genchanges didn't include the source tarball in the upload, but it's the same as what's currently in the archive
[17:52] <ghostcube> hmm does anyone in here kow an grafical sensors tool that can handle atk0110-acpi
[17:52] <ghostcube> from lmsensors
[17:58] <Lure> ScottK: shouldn't you put KubuntuUpdatePolicy to TB agenda?
[18:23] <adiroiban> hi. do you know why the required translations are not provided in the kover package?
[18:23] <adiroiban> https://edge.launchpad.net/ubuntu/karmic/+source/kover
[18:24] <adiroiban> I have checked the upstream release and it contains the translations http://lisas.de/kover/download.php3
[18:25] <adiroiban> kover is part of Universe so the translations are not handled by Rosetta and langauge pack
[18:25] <ghostcube> are the restricted modules now called backport modules `
[18:26] <dtchen> no
[18:26] <dtchen> there are no restricted modules as of 9.10
[18:27] <dtchen> everything has been offloaded into separate source packages that are built using DKMS
[18:27] <dtchen> linux-backports-modules-2.6.31 is a very specific set of Free drivers that are simply newer snapshots of what's in linux
[18:27] <ghostcube> ah ok thx
[18:44] <Tonio__> ScottK: for KNE : http://kde-apps.org/content/show.php/Bangarang?content=113305&PHPSESSID=57332e226cbd1ad28abf1b4f1a40f4d9
[18:44] <Tonio__> ScottK: potential replacement for amarok
[19:23] <ryanakca> Tonio__: I could package that sometime this week or next weekend....
[19:24] <Tonio__> ryanakca: would be nice :)
[19:24] <ryanakca> Tonio__: OK
[19:49] <rgreening> sebas: ping
[19:49] <rgreening> sebas: got a question about google + akonadi + contacts sync weirdness...
[19:50] <rgreening> and if there's a correct way to do it?
[20:01] <ryanakca> rgreening: Are you in a merge reviewing mood?
[20:06] <rgreening> just about to head out for the evening... sorry ryanakca
[20:29] <ryanakca> rgreening: No worries
[21:40]  * ryanakca scratches his head and wonders why 'dir ~' works, but 'ls ~' creates an ls process in 'uninterruptible sleep' ('D' process state in ps)
[22:14] <apachelogger> adiroiban: the po stuff is not ported to KDE 4's build system
[22:14] <apachelogger> god knows why
[22:15] <adiroiban> apachelogger: thanks. I have implemented the required changes
[22:15] <apachelogger> k
[22:15] <apachelogger> though
[22:15] <apachelogger> adiroiban: please consult with upstream first
[22:15] <apachelogger> there might be a reason for that after all
[22:15] <adiroiban> yep. I have send an email
[22:16] <adiroiban> it's bug #478507
[22:16] <apachelogger> k