[00:17] <phoenix_firebrd> yofel: are you there?
[00:17] <Riddell> phoenix_firebrd: what do you need to know?
[00:17] <phoenix_firebrd> Riddell: good morning
[00:18] <phoenix_firebrd> Riddell: I am building libkolabxm and i am getting error i will paste it now
[00:19] <phoenix_firebrd> Riddell: http://paste.kde.org/655154/
[00:20] <Riddell> your patch doesnae apply
[00:21] <phoenix_firebrd> Riddell: ya i can see that
[00:21] <Riddell> open the patch and src/uriencode.cpp in an editor and decide if it still needs to apply
[00:21] <Riddell> if not delete the patch and entry from debian/patches/series
[00:21] <phoenix_firebrd> Riddell: Its not my patch
[00:22] <Riddell> I know, it's mine :)
[00:23] <phoenix_firebrd> Riddell: so i have to remove the patches?
[00:23] <Riddell> you have to decide if it still needs to apply
[00:23] <Riddell> or if whatever the patch was for has been fixed
[00:24] <phoenix_firebrd> Riddell: the packagers decide on that?
[00:24] <Riddell> there's nobody here but us chickens
[00:25] <Riddell> oh I'm taking wrongful credit, it's apachelogger's patch
[00:25] <Riddell> phoenix_firebrd: so looks like a patch to fix a mistake in the code, look at the code and see if that mistake has been fixed
[00:26] <phoenix_firebrd> Riddell: ok
[00:27] <phoenix_firebrd> Riddell: manual patching allowed?
[00:29] <Riddell> phoenix_firebrd: how do you mean?
[00:29] <phoenix_firebrd> Riddell: If the patch are ok and it was not applied previously? can we patch the source manually?
[00:30] <Riddell> phoenix_firebrd: are you still talking about kubuntu_fix_curl_constness.patch ?
[00:31] <phoenix_firebrd> Riddell: ya and it seems the patch was already applied
[00:32] <phoenix_firebrd> Riddell: so, now i have to just delete the corresponding .patch file from debian/patch/ ?
[00:34] <Riddell> yep
[00:34] <phoenix_firebrd> Riddell: both the patches are already applied
[00:34] <Riddell> and the name from debian/patches/series
[00:35] <phoenix_firebrd> Riddell: does the patch dir have to remain?
[00:35] <Riddell> our patches go upstream, we rock
[00:35] <Riddell> phoenix_firebrd: doesn't matter either way
[00:35] <phoenix_firebrd> nice
[00:35] <phoenix_firebrd> i have removed the patch dir
[00:36] <Riddell> debuild it baby!
[00:37] <phoenix_firebrd> Riddell: ya doing that
[00:39] <phoenix_firebrd> Riddell: debuild seems changes in cmakelists.txt which i didn't change and wants to commit using this command dpkg-source --commit and it needs a commit name
[00:39] <phoenix_firebrd> Riddell: http://paste.kde.org/655160/
[00:41] <phoenix_firebrd> Riddell: can i commit with message "removed previously applied patches" ?
[00:41] <Riddell> what's in /tmp/libkolabxml_0.8.2-0ubuntu1~ubuntu13.04~ppa1.diff.6Gm6oh phoenix_firebrd ?
[00:42] <phoenix_firebrd> Riddell: checking
[00:43] <phoenix_firebrd> Riddell: http://paste.kde.org/655166/
[00:43] <Riddell> phoenix_firebrd: that's the kubuntu_01_include_dir.diff patch
[00:43] <Riddell> so it must have been applied somehow
[00:43] <Riddell> start again
[00:44] <phoenix_firebrd> ok
[00:44] <Riddell> remove the libkolabxml-0.8.2 sources
[00:44] <Riddell> extract the tar
[00:44] <Riddell> copy the debian dir in
[00:44] <Riddell> remove the kubuntu_fix_curl_constness.patch patch but not the other one
[00:44] <Riddell> add changelog and debuild
[00:46] <phoenix_firebrd> Riddell: ok
[00:51] <phoenix_firebrd> Riddell: running pbuilder
[00:51] <Riddell> I only use pbuilder for a final check, I just compile things locally first
[00:51] <Riddell> pbuilder takes ages to run
[00:52] <phoenix_firebrd> Riddell: I am running 12.10
[00:52] <Riddell> probably still fine for most things
[00:53] <phoenix_firebrd> Riddell: only the internet come in the way
[00:53] <phoenix_firebrd> Riddell: If i install all the deps and it will show in the updates
[00:53] <Riddell> ec2 machines available on request too
[00:53] <phoenix_firebrd> Riddell: mine is 2mbps and with a fup of 80gb after that 256 kbps
[00:54] <phoenix_firebrd> Riddell: Give me that when you feel i am ready 
[00:57] <Riddell> phoenix_firebrd: ubuntu@ec2-54-242-247-61.compute-1.amazonaws.com
[00:57] <Riddell> run poweroff when you're done to kill the machine
[00:58] <phoenix_firebrd> Riddell: ok
[01:01]  * Riddell snoozes
[03:13] <ScottK> cyphermox: Hi
[04:03] <jackyalcine> Hey, any uses for graphics tablet in KDE/Kubuntu? 
[04:03] <jackyalcine> As per http://blog.dev001.net/post/40681591705/x-org-use-your-android-tablet-as-a-graphics-tablet, looks like it might become more commonplace
[06:56] <soee> good morning
[09:29] <apachelogger> "I know firefox needs to be patched, and if official firefox maintainer does not want to patch firefox, we could make a fork of Firefox called "firefox-kde" or something."
[09:29] <apachelogger> he wrote 'we', but he meant 'you'
[09:46] <apachelogger> shadeslayer: jreen is not in raring yet?
[09:49] <apachelogger> shadeslayer: FWIW not knowing that dbus-launch and kded4 fork, the code does not make sense :P
[09:50] <apachelogger> yofel: regarding the failure notification ... new team with new ml :P
[09:51] <apachelogger> for all I care we can also make an irc bot for it 
[09:51] <apachelogger> but who's going to run it and who's going to maintain it etc. :S
[09:52] <yofel> true, but if we really make one then please for all branches we remotely care about and put it in #kubuntu-commits
[09:56] <apachelogger> yofel: i.e. all repostiories kubuntu-members or kubuntu-dev can upload to
[09:56] <apachelogger> yes
[09:56] <yofel> phoenix_firebrd: something else for pbuilder before I forget it: You probably really want this in your pbuilderrc:
[09:56] <yofel> EXTRAPACKAGES="eatmydata"
[09:56] <yofel> export LD_PRELOAD=/usr/lib/libeatmydata/libeatmydata.so
[09:56] <phoenix_firebrd> yofel: good morning 
[09:57] <yofel> good morning :)
[09:57] <phoenix_firebrd> did you sleep or yet to sleep?
[09:57] <yofel> apachelogger: yeah, and IMO maybe even commits to stable kde branches 
[09:57] <yofel> I did sleep, it's 11AM here
[09:57] <phoenix_firebrd> yofel: good
[09:58] <apachelogger> yofel: well for that we can simply get the kde bots in
[09:58] <yofel> apachelogger: but that's for later anyway
[09:58] <phoenix_firebrd> yofel: i will add those lines to the pbuildrc
[09:58] <yofel> true
[09:58] <phoenix_firebrd> yofel: If a patch need needs fuzz option during build what should i do?
[09:59] <apachelogger> yofel: the problem I have with lunchpad and IRC bots have is: short of getting a server-side hook deployed (which is terribly unlikely), we have to rely on randomly formatted mails
[09:59] <yofel> quilt push it by hand and refresh it.
[09:59] <yofel> quilt will patch it fine, but dpkg-source doesn't allow fuzz
[09:59] <apachelogger> which in turn requires a vastly more complicate server-bot setup
[09:59] <apachelogger> as the bot then needs to get ahold of the mails
[09:59] <yofel> apachelogger: I know :(
[10:00] <apachelogger> doing stuff based on mails is really spooky anyway ^^
[10:00] <phoenix_firebrd> apachelogger: morning
[10:00] <apachelogger> hey phoenix_firebrd
[10:00] <apachelogger> Riddell: it appears you are overly dismissive of the ideas on the ML :P
[10:01] <apachelogger> more importantly tho, go fix your mail client
[10:02] <phoenix_firebrd> yofel: what does those two lines for pbuilderrc does?
[10:02] <apachelogger> I really do not get why everyone is so hung up on the browser question though
[10:02] <phoenix_firebrd> apachelogger: debault browser?
[10:02] <apachelogger> yes
[10:03] <yofel> phoenix_firebrd: it replaces sync() and fsync() system calls with a NOOP, which makes package installation a LOT faster
[10:03] <phoenix_firebrd> apachelogger: rekonq +1
[10:03] <yofel> rekonq +0
[10:03] <apachelogger> curl ftw
[10:03] <phoenix_firebrd> yofel: what do you prefer?
[10:03] <Tm_T> KDE browser +1 (Konqueror +2)
[10:03] <yofel> rekonq 2.0 is ok, but it took it 3 minutes(!) stuck with 100%CPU to open a simply gzipped buildlog from launchpad yesterday
[10:04] <yofel> I'm presonally a firefox person, but I use firefox, chromium and rekonq at the same time sometimes
[10:04] <phoenix_firebrd> yofel: but what about the gtk dep
[10:04] <apachelogger> so
[10:04] <Tm_T> I use lynx quite often /:
[10:04] <apachelogger> webkit > gecko
[10:05] <apachelogger> because webkit > khtml > gecko
[10:05] <yofel> phoenix_firebrd: I said what I use, please don't use what I use as the default
[10:05] <Tm_T> apachelogger: you mean kthml > all ?
[10:05] <Tm_T> khtml too
[10:05] <apachelogger> did you look at the code? :P
[10:05] <apachelogger> like ... brrrrr
[10:05] <Tm_T> apachelogger: oh yes I have done that
[10:05] <apachelogger> hence why webkit is superior
[10:05] <apachelogger> tho its code is also brrrr
[10:06] <apachelogger> yet it is less of a lolwut kind of brrrr
[10:06]  * apachelogger will one of these days get a discussion about who the actual target audience of kubuntu is
[10:06] <yofel> but I'm together with apachelogger that I don't understand why people make such a fuss about the default browser
[10:07] <yofel> rekonq works for most things, if you need something else freakin' install it
[10:07] <Tm_T> apachelogger: us ofcourse (;
[10:07] <yofel> rekonq 2.1 will even have a usable history tab
[10:08] <apachelogger> >>I use a lot the button to "keep Above Others", and I'm quite sure most of the new user not even knows it can be done, instead once is there it's really easy to understand how and when to use it.<<
[10:08] <Tm_T> I still miss the bookmark bar from Konqueror when I use other browsers /:
[10:08] <apachelogger> so, if I were not so lazy I'd search for a study on why in fact that is not and easy to understand feature
[10:08] <yofel> apachelogger: that would be something I curse windows for not having, but that's probably jsut me
[10:08] <apachelogger> as useful as it is, it entirely requires thinking outside the box
[10:09] <yofel> wasn't it enabled in kde3 times though?
[10:09] <apachelogger> alas, I fail to think of one real world example where you can keep something above everything else without having to reorder
[10:10] <apachelogger> oh, well, dirt on ones glasses work that way
[10:10] <apachelogger> yofel: I believe so, yes
[10:11] <apachelogger> it's not that the button being there does any harm
[10:11] <apachelogger> kinda messes with visual balance though
[10:11] <apachelogger> and since normal people will have a hard time grasping the concept it is not worthwhile
[10:12] <yofel> i have: 'on all desktops' 'keep above' 'shade' <title> 'min' 'max' 'close'
[10:12] <yofel> perfectly balanced
[10:12] <apachelogger> or the supreme reasoning of why not to have it: nuno wanted it gone
[10:12] <yofel> ah ok
[10:12] <apachelogger> yofel: actually that sounds more like your window will eventually fall over to the right :P
[10:12] <apachelogger> that's what I mean with visual balance
[10:12] <yofel> note that title is in the middle
[10:13] <apachelogger> yeah
[10:13] <apachelogger> so it goes
[10:13] <yofel> ok, so it's 4:3 including the icon, but still
[10:13] <apachelogger> [o]                    super app     [a] [i] [p] [y] [x]
[10:14] <apachelogger> if you had the title left it'd be better
[10:14] <Tm_T> [menu]    konsole    [maximize]
[10:14] <apachelogger> but then the title suddenly becomes an element of visual balance
[10:14] <apachelogger> so that's bad
[10:14] <apachelogger> like really bad
[10:15] <apachelogger> as a short title will again endanger the window of falling over to the right, and a long one may make it fall ot the left
[10:15] <yofel> [o] [a] [i] [j]        foo       [v] [^] [X]
[10:15] <apachelogger> yofel: yeah, that works
[10:15] <apachelogger> crowded though etc.
[10:15] <apachelogger> Tm_T: with you on that
[10:15] <yofel> well, I think I'll drop "shade" - I never use that...
[10:16] <apachelogger> yofel: truth be told, I use a lot of that crap, but I do not use it as often as I use max or close for example
[10:16] <apachelogger> in fact it may be 10:1
[10:16] <Tm_T> apachelogger: I less is better with those buttons I'd say
[10:16] <apachelogger> so I personally find it perfectly acceptable to right click on the window and activate the magic from the menu
[10:16] <yofel> yeah
[10:17] <Tm_T> triple click on menu does close the window, so close button is not needed
[10:17] <apachelogger> Tm_T: absolutely agreed, though your 2 button lineup can only be pulled of by keyboard users ^^
[10:17] <Tm_T> and double click on titlebar minimizes so no need for a button with that (;
[10:18] <Tm_T> apachelogger: yeah, my config isn't for others anyway
[10:18] <Tm_T> but there's a balance what is really needed by default
[10:18] <apachelogger> it's a config made to enjoy .prn I think
[10:18] <yofel> lol
[10:18] <Tm_T> huh?
[10:18] <apachelogger> less chrome = more prn
[10:19] <Tm_T> naah, more like this: http://www.tm-travolta.net/shots/wut.png
[10:20] <apachelogger> JontheEchidna: didn't we remove quickaccess for lack of maintainership?
[10:20] <apachelogger> Tm_T: ascii prn then
[10:20] <apachelogger> all the same to me
[10:21] <Tm_T> apachelogger: yeah, all those log files are pure prn (;
[10:21] <apachelogger> "I guess a second panel on the top of the screen can do most of the job "
[10:21] <apachelogger> I seem to have seen something like this before
[10:21] <apachelogger> hm, where was it
[10:22] <yofel> please... no. I have 2 panels, but they're left and right where it hurts the least
[10:22] <apachelogger> ^^
[10:23] <apachelogger> being a buddhist and all, I have to say the following about 2 panels
[10:23] <yofel> if anything go the ubuntu way for 2 panels. We would at least have an excuse for that
[10:23] <apachelogger> if you have so much crap that you cannot fit it all in one panel, the solution is not to add more panels but remove crap
[10:24] <mikhas> would you like a third panel?
[10:24] <Tm_T> are we talking about plasma panels now?
[10:24] <apachelogger> yofel: top-bottom panels do not work well unless they are relatively small in height OR the screen is of appropriately size
[10:24] <yofel> ack
[10:25] <apachelogger> language fail right there
[10:25] <apachelogger> anywho
[10:25] <apachelogger> that is why in gnome2 the panels where rather tiny
[10:25] <Tm_T> one panel has to be enough for default
[10:25] <apachelogger> otherwise on a small screen you get the feeling that they are crushing your windows or something
[10:25] <yofel> gnome2 worked really well on 4:3 screens
[10:25] <apachelogger> yofel: yeah
[10:26] <apachelogger> now take kde with the super huge panels and try that on a small 4:3 screen
[10:26] <apachelogger> to pull that off almost all plasmoids would have to be redone to not waste space the way they do
[10:26] <apachelogger> (though perhaps that should be done anyway ^^)
[10:27] <apachelogger> mikhas: we have 4 edges, if anything we should have 4 panels :P
[10:27] <mikhas> triangular-shaped screens are the future, I'm telling you …
[10:28] <apachelogger> actually someone told me spherical
[10:28] <apachelogger> though I cannot remember why
[10:28] <apachelogger> to close a window you shake the sphere
[10:28] <apachelogger> \o/
[10:28] <apachelogger> oh one more though on the panel thing ... the more plasmoids you add to plasma the higher the risk it will crash
[10:28] <apachelogger> ...
[10:30] <Riddell> ug, you want precious screen space to be taken up by toys?
[10:31] <tsimpson> you could use a "showcase" activity, have the default activity nice and clean and have another full of crud.. er toys
[10:32] <tsimpson> though that assumes people know how to get from one activity to the other, or even know what they are
[10:34] <yofel> "-add more monochromatic icons for all notification-helpers. Please use existing or talk to Nuno Pinheiro. "
[10:34] <yofel> WHY? Why does everyone to have anything in mono? Sure, it *looks* good, but usability--
[10:34] <yofel> add want in there
[10:37] <apachelogger> ah
[10:37] <apachelogger> again I disagree about the problem statement :P
[10:38] <apachelogger> the icons should not be mono, there should be less notification helper icons
[10:38] <yofel> huh? how much are there? I only see the additional-stuff and reboot ones usually
[10:38] <apachelogger> ultimately only reboot and hooks notification
[10:38] <apachelogger> both of which ought to be drawing attention as they are kinda important usually
[10:38] <apachelogger> yofel: the additional stuff ones should not be there
[10:39] <yofel> where then? a non-expiring notification?
[10:39] <apachelogger> no notification
[10:39] <yofel> now I'm confused
[10:39] <apachelogger> it should be inside the app
[10:39] <apachelogger> like the additional wallpaper thingy
[10:40] <yofel> where in rekonq would you add the flash installer then?
[10:40] <apachelogger> the notifications were a quick solution with minimally invasive patching
[10:40] <apachelogger> yofel: detect flash plugins and replace the plugin component with a thingy that installs
[10:40] <apachelogger> or if it must be a notification *inside* the app
[10:41] <yofel> ok, and now something that we have the manpower to do?
[10:41] <yofel> (other than patches welcome)
[10:42] <apachelogger> yofel: you sure that excuse qualifies as reason not to target that problem resolution?
[10:43] <yofel> not really
[10:47] <phoenix_firebrd> yofel: from which directory i have to run quilt for patching?
[10:47] <apachelogger> Riddell: there is a legit question at the heart of this ... how do we educate/show users what they can or may want to do with plasma
[10:47] <apachelogger> and perhaps at least as important ... do we even want that
[10:47] <yofel> phoenix_firebrd: source base dir
[10:47] <phoenix_firebrd> apachelogger: like force feed the?
[10:47] <phoenix_firebrd> apachelogger: like force feed them?
[10:47] <yofel> phoenix_firebrd: oh, wait
[10:48] <apachelogger> phoenix_firebrd: yes
[10:48] <apachelogger> though it is a terrible unsuitable phrase to use
[10:48] <phoenix_firebrd> yofel: one file is in the sorce dir and the other is in sorce.orig dir
[10:48] <yofel> phoenix_firebrd: put this in your .quiltrc http://paste.kde.org/655298
[10:48] <apachelogger> you cannot be force fed software unless you cannot remove it :P
[10:48] <yofel> ~/.quiltrc
[10:49] <yofel> well, upstream does have a few "showcase" activities
[10:49] <yofel> so that's not wrong pre se
[10:50] <Riddell> apachelogger: I recon that users who like wee widgets will be the sort of user to play with settings enough to find them, it's not hard there's a cashew thing to click on right there
[10:50] <apachelogger> such that you always end up with either an opt-in or opt-out approach, e.g. our default distro comes with very few plunder so you need to install more plunder yourself, out of the box windows computers come with all sorts of plunder from the oem so you need to manually remove stuff you do not want
[10:51] <apachelogger> I personally favor our approach but it has the problem that a user may not know how one can make advanced use of $software and how that may improve ones productiveness or computing experience
[10:52] <apachelogger> Riddell: what about activities
[10:53] <Riddell> write good docs? make an interactive intro to plasma widget?
[10:53] <apachelogger> possible solutions indeed
[10:53] <apachelogger> so someone should write that as a reply :P
[10:53] <Riddell> yeah I think we should replace default virtual desktops with default activities
[10:54] <Riddell> but I do think the way of interactive with activities is not intuitive at all
[10:54] <apachelogger> Riddell: that's why I thought you were dismissive btw, a first start introduction is not a bad idea as such, it getting in the way of using is
[10:54] <yofel> I have one use for them: have a completely empty desktop for presentations at work. End of use case
[10:54] <apachelogger> an issue nicely worked around by making any such intro either an app that does not start by default or is a plasma widget
[10:55] <apachelogger> yofel: lol
[10:55] <apachelogger> so
[10:55] <apachelogger> I always end up loosing windows in some activity
[10:56] <yofel> ... or end up having stuff consuming memory that you forgot about
[10:57] <apachelogger> *nod*
[10:57] <apachelogger> not my kind of concept
[10:57] <apachelogger> then again I never used vdesktops either
[10:58] <yofel> I do, but that's a matter of taste. If there was a pager-like widget for activities I would probably use them
[11:03] <phoenix_firebrd> yofel: this is the patch http://paste.kde.org/655316/ take a look at the file locations, now from which dir i should run quilt
[11:04] <yofel> after you created the .quiltrc that I posted, go into libkolabxml-0.8.2 and run 'quilt push' in there
[11:04] <phoenix_firebrd> yofel: its cutmp3
[11:04] <yofel> ah, same procedure though
[11:05] <phoenix_firebrd> yofel: did you see this https://launchpad.net/~murthy/+archive/test/+packages
[11:05] <yofel> not yet, I can review kolabxml later
[11:05] <phoenix_firebrd> yofel: ok
[11:05] <yofel> kolab would be waiting for shadeslayer I guess - if he can figure it out
[11:05] <phoenix_firebrd> yofel: ya
[11:06] <phoenix_firebrd> yofel: when i run quilt from inside the source dir it fails 
[11:06] <phoenix_firebrd> yofel: the source.orig dir is outside
[11:06] <phoenix_firebrd> also i updated the quiltrc with the code that you gave 
[11:07] <yofel> it fails with what error message?
[11:07] <phoenix_firebrd> the .quiltrc file is in home dir
[11:08] <phoenix_firebrd> yofel: http://paste.kde.org/655322/
[11:09] <yofel> can you please pastebin that Makefile
[11:10] <phoenix_firebrd> yofel: ok i will paste, i can see it is modified
[11:11] <phoenix_firebrd> yofel: http://pastebin.com/pMNYFcKS
[11:12] <yofel> that version number change breaks it I think
[11:12] <yofel> anyway
[11:12] <yofel> $me -> lunch
[11:12] <yofel> bbiab
[11:12] <phoenix_firebrd> yofel: see you later enjoy 
[11:24] <Riddell> phoenix_firebrd: can I shut down the ec2?
[11:28] <phoenix_firebrd> Riddell: sure
[11:46] <yofel> phoenix_firebrd: please put all the changes you do in the changelog and mention why you drop a patch. I fixed 2 other things too but generally the package is fine. full diff: http://paste.kde.org/655346 
[11:46] <yofel> phoenix_firebrd: uploaded https://launchpad.net/ubuntu/+source/libkolabxml/0.8.2-0ubuntu1
[11:48] <phoenix_firebrd> yofel: wow thats very detailed, i didn't know that
[11:48] <phoenix_firebrd> yofel: nice
[11:49] <phoenix_firebrd> yofel: so apart from the changelog , am i ok?
[11:50] <yofel> phoenix_firebrd: yeah, as for my changes - you probably didn't look at the cmake output close enough
[11:51] <yofel> there was a message about swig not being found and a warning about Qt not being there
[11:51] <yofel> they're both optional, so it built. But do try to get everything working as long as it's there
[11:51] <phoenix_firebrd> yofel: yesterday i added swig
[11:51] <yofel> (or as long as we don't have a reason for not using it)
[11:52] <yofel> that was in kolab I think - kolabxml already had swig2.0, but it uses swig, not swig2.0
[11:52] <phoenix_firebrd> yofel: ok
[11:53] <phoenix_firebrd> yofel: whats the time?
[11:53] <yofel> time?
[11:53] <phoenix_firebrd> yofel: where do you live?
[11:53] <yofel> Stuttgart/Germany
[11:53] <yofel> so almost 1pm now here
[11:54] <phoenix_firebrd> yofel: 12 54 pm?
[11:54] <Riddell> hi vassie 
[11:54] <yofel> yep
[11:54] <phoenix_firebrd> yofel: can you build cutmp3
[11:54] <vassie> Riddell: hello :)
[11:56] <yofel> phoenix_firebrd: as I don't have upload permissions for cutmp3 a MOTU or core-dev should do that
[11:56] <phoenix_firebrd> yofel: no just build
[11:56] <yofel> well ok, that I can do
[11:56] <phoenix_firebrd> yofel: i have doubts in the patching
[11:58] <phoenix_firebrd> yofel: tell me when the patching fails
[11:59] <yofel> patch works when you change the VERSION from 2.0.2 to 2.1 - the patch initially fails because the patch context changed
[11:59] <vassie> Riddell: i have some time now if you are free>
[12:00] <Riddell> vassie: awooga
[12:00] <phoenix_firebrd> yofel: so you mofify the patch?
[12:00] <phoenix_firebrd> *modify
[12:01] <phoenix_firebrd> yofel: tell me what you did
[12:01] <yofel> yep, in this case it's easy. Worst case you would have to force apply the patch, manually integrate all rejected hunks and refresh the patch
[12:02] <yofel> in the patch, replace  VERSION=2.0.2 with  VERSION=2.1 - which is what the Makefile has now
[12:02] <phoenix_firebrd> yofel: ok, now debuild?
[12:04] <yofel> run 'quilt push' to verify that the patch applies fine, then debuild
[12:05] <phoenix_firebrd> yofel: works
[12:05] <phoenix_firebrd> yofel: i never thought we had permission to mmodify the patch
[12:07] <yofel> phoenix_firebrd: patches are modifications to the application added by the packagers - i.e. by *you*
[12:07] <yofel> and usually we don't modify the patches, but if the don't apply, we have to fix them
[12:08] <yofel> or decide what else we're supposed to do with them
[12:08] <phoenix_firebrd> yofel: I thought its a patch for the devs
[12:09] <yofel> define "dev" - a packager counts as distribution developer. Upstream developers rarley provide patches. But if they do, then it's our job to add them - or not
[12:10] <phoenix_firebrd> yofel: can the following message be removed from the log 
[12:10] <phoenix_firebrd> yofel: "ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded: ignored."
[12:10] <yofel> phoenix_firebrd: run pbuilder update once. The eatmydata package isn't yet installed
[12:10] <yofel> it needs to be installed in the chroot to work
[12:11] <yofel> that's what EXTRAPACKAGES does, but not during 'build'
[12:12] <phoenix_firebrd> yofel: no need to set the distribution for updating pbuilder ?
[12:12] <yofel> what do you mean? just call pbuilder as you usually do, just with update instad of build
[12:12] <phoenix_firebrd> yofel: updating
[12:13] <phoenix_firebrd> yofel: i thought a patch is created by the application dev and to patch the source only by them
[12:14] <phoenix_firebrd> yofel: I can remember you added my kmix patch once
[12:14] <yofel> no, the patches in debian/patches/ are distribution patches. The packagers decide what goes in there and what not
[12:14] <phoenix_firebrd> yofel: ya, learned that today
[12:14] <yofel> sure, we do have upstream patches, or cherry-picked upstream commits in there sometimes. But we have plenty of kubuntu-only stuff too
[12:15] <yofel> kubuntu-only should be prevented if anyhow possible, but sometimes it's simply a distro-specific change
[12:16] <yofel> like that makefile patch which is simply needed to get the application to build a proper archive package
[12:16] <phoenix_firebrd> yofel: so in the case of cutmp3 we have modified the patch, so what should we say in the change log?
[12:17] <phoenix_firebrd> yofel: "corrected version number in the patch?"
[12:17] <yofel> uh... "Refresh <patchname> for the new release" or so
[12:18] <yofel> changelog entries use present tense btw.
[12:18] <phoenix_firebrd> yofel: ok
[12:19] <phoenix_firebrd> yofel: even after updating the pbuilder i am getting the error message
[12:19] <yofel> do mention the patch name in the changelog though when you change it. Makes it easier to find all changes to it when you search through the changelog later
[12:19] <yofel> hm, weird
[12:19] <phoenix_firebrd> yofel: ok
[12:19] <yofel> phoenix_firebrd: try update --override-config
[12:20] <phoenix_firebrd> yofel: omg its updating to precise
[12:20] <yofel> huh?
[12:21] <phoenix_firebrd> yofel: by default when creating its getting precise
[12:21] <yofel> ouch
[12:21] <phoenix_firebrd> yofel: when we create does the cache get destroyed?
[12:21] <yofel> sorry then, I manage my tars by release, so that doesn't happen here
[12:22] <yofel> I don't think so, only the base.tgz should be re-created
[12:23] <phoenix_firebrd> yofel: i will try to update with --distribution raring
[12:23] <yofel> ok
[12:23] <phoenix_firebrd> works
[12:23] <phoenix_firebrd> updating to raring
[12:24] <yofel> here's my pbuilderrc if you find anything useful: http://paste.kde.org/655358/
[12:26] <phoenix_firebrd> yofel: i have saved your pbuilderrc as a file, i will go throught it
[12:27] <yofel> we need to put a set of defaults somewhere...
[12:28] <phoenix_firebrd> yofel: the error messages still show up
[12:28] <phoenix_firebrd> yofel: what defaults?
[12:28] <yofel> phoenix_firebrd: odd, can you pastebin your pbuilderrc?
[12:28] <yofel> some pbuilder settings that make sense by default for us
[12:28] <yofel> there is one on https://wiki.kubuntu.org/Kubuntu/Ninjas/BuildEnvironment but it's a bit outdated
[12:28] <phoenix_firebrd> yofel: ok
[12:28] <yofel> (actually the whole page is)
[12:29] <phoenix_firebrd> yofel: http://paste.kde.org/655364/
[12:30] <yofel> wth, that looks right.
[12:30] <yofel> can you login to your pbuilder and check if eatmydata is installed?
[12:30] <phoenix_firebrd> yofel: ok
[12:31] <phoenix_firebrd> yofel: i have logged in, how can i check if it is installed?
[12:31] <yofel> apt-cache policy eatmydata
[12:32] <phoenix_firebrd> Installed: 26-2
[12:33] <yofel> and you got no ld.so error while looking that up?
[12:34] <phoenix_firebrd> ERROR: ld.so: object '/usr/lib/libeatmydata/libeatmydata.so' from LD_PRELOAD cannot be preloaded: ignored.
[12:34] <phoenix_firebrd> yofel: does this channel have a bot?
[12:34] <yofel> 2, ubottu and kubotu - depends on what you need
[12:34] <yofel> actually 3 counting the logbot
[12:35] <phoenix_firebrd> yofel: the one that alerts when you paste huge data
[12:35] <yofel> ah floodbot, no, intentionally not
[12:35] <phoenix_firebrd> ya right
[12:35] <phoenix_firebrd> nice
[12:36] <phoenix_firebrd> yofel: I wont flood :)
[12:36] <yofel> weird though that eatmydata is installed and it complains about it not being there
[12:36] <yofel>  /usr/lib/libeatmydata/libeatmydata.so exists in the chroot, right?
[12:36] <phoenix_firebrd> yofel: i will check
[12:37] <phoenix_firebrd> yofel: yes
[12:37] <yofel> o.O
[12:37] <phoenix_firebrd> yofel: even looks fine with ldd
[12:38] <yofel> I guess disable it for now as I'm out of ideas
[12:38] <yofel> without that pbuilder is a bit of a pain though :(
[12:39] <yofel> (unless you have a SSD)
[12:39] <phoenix_firebrd> yofel:  I build with root permission , does that affect?
[12:39] <yofel> or enough memory to build in a tmpfs (i.e. 16GiB or so)
[12:40] <phoenix_firebrd> yofel: i have 999mb left in root
[12:40] <yofel> well, I do too, but I use sudo -E to keep the env settings. But if it would loos those then LD_PRELOAD wouldn't be set in the first place
[12:40] <yofel> oops, that might be a bit small for some packages
[12:40] <phoenix_firebrd> yofel: ya
[12:40] <yofel> (digikam for example easily takes 5G)
[12:41] <phoenix_firebrd> yofel: ya
[12:50]  * yofel wonders what else you could update - library packages aren't exactly the easiest thing to start with
[12:56] <phoenix_firebrd> yofel: I added this to the changelog for cutmp3 "-Refresh 01-makefile.patch for the new release" \
[12:57] <phoenix_firebrd> I didn't modify anything else
[12:57] <yofel> yeah, that's ok
[12:57] <phoenix_firebrd> yofel: If its ok with you, i am enjoying building the libs
[12:58] <phoenix_firebrd> yofel: I am just learning the basic by unconventional method :)
[13:01] <yofel> kile has an update
[13:01]  * yofel was looking for something we keep in bzr though
[13:01] <yofel> but I guess we can throw kile in bzr
[13:03] <phoenix_firebrd> yofel: I have no idea what you are talking about
[13:03] <yofel> I'll try to clear that up
[13:03] <yofel> do you know what bzr is?
[13:03] <yofel> or git or svn for that matter?
[13:04] <phoenix_firebrd> yofel: ya i am using git and bazaar
[13:05] <Riddell> phoenix_firebrd: libkolab all done?
[13:06] <yofel> Riddell: that was waiting on shadeslayer who tried to get the tests to build
[13:06] <turgay> hi 
[13:06] <phoenix_firebrd> Riddell: libkolab built , but tests fail
[13:06] <turgay> I can not get sound
[13:06] <yofel> phoenix_firebrd: so, for many packages we keep the packaging (the debian folder) in a bazaar branch https://code.launchpad.net/~kubuntu-packagers/kubuntu-packaging/
[13:06] <turgay> turgay@turgay-S:~$ aplay -l
[13:06] <turgay> aplay: device_list:252: ses kartı bulunamadı...
[13:07] <phoenix_firebrd> Riddell: i am building packages listed here http://qa.ubuntuwire.com/uehs/no_updated.html
[13:07] <Riddell> I'm still not convinced that is complete
[13:07] <Riddell> somewhere on my todo list is to make something similar for kde packages
[13:07] <turgay> http://ompldr.org/vaDdjYg  lspci 
[13:08] <phoenix_firebrd> Riddell: https://launchpad.net/~murthy/+archive/test/+packages
[13:08] <phoenix_firebrd> Riddell: that would be nice
[13:11] <yofel> phoenix_firebrd: so, if you want I can give you a short intro to our bzr workflow taking kile as example. Without direct commit access it takes a bit longer but you'll learn something new about launchpad too
[13:11] <phoenix_firebrd> yofel: that would be awesome
[13:12] <phoenix_firebrd> yofel: kile is in official ubuntu repos?
[13:12] <yofel> ok, do you have the kubuntu-dev-tools installed? That has a small script named kbzr
[13:12] <phoenix_firebrd> yofel: checking
[13:12] <yofel> which helps with not having to type lp:~kubuntu-packagers/kubuntu-packaging/... all the time
[13:12] <phoenix_firebrd> yofel: no
[13:13] <phoenix_firebrd> yofel: installing
[13:13] <phoenix_firebrd> yofel: shall i install kubuntu-dev-tools or just kbzr just for now?
[13:13] <yofel> kubuntu-dev-tools, kbzr is part of that
[13:14] <Riddell> turgay: user support in #ubuntu and #kubuntu thanks
[13:15] <phoenix_firebrd> yofel: E: Package 'kubuntu-dev-tools' has no installation candidate
[13:16] <yofel> add ppa:bulldog98/kubuntu-dev-tools to your sources
[13:16] <yofel> that has snapshots of lp:kubuntu-dev-tools 
[13:18] <phoenix_firebrd> yofel: muon has a bug, its not refreshing the list after modifying the sources , it updates after second time 
[13:18] <phoenix_firebrd> yofel: installing kubuntu-dev-tools
[13:18] <yofel> file a bug, but I think that's some mismatch between muon and software-properties-kde
[13:19] <phoenix_firebrd> yofel: ok
[13:19] <turgay> Riddell: I installed kubuntu  13:04 :)
[13:19] <yofel> file a bug anyway so it's not forgotten
[13:19] <yofel> turgay: user support for 13.04 is in #ubuntu+1
[13:19] <turgay> ok
[13:19] <Riddell> turgay: #ubuntu+1 then (alas we're not sound specialists here)
[13:20] <phoenix_firebrd> yofel: the dev tools installed
[13:20] <phoenix_firebrd> yofel: open kbzr?
[13:20] <yofel> ok, now go to your workplace and run: kbzr branch kile
[13:20] <turgay> thnx   pai.
[13:21] <phoenix_firebrd> yofel: i have the source
[13:22] <phoenix_firebrd> yofel: only with debian folder
[13:22] <phoenix_firebrd> yofel: oops
[13:22] <yofel> right, that's all we keep in bzr
[13:22] <phoenix_firebrd> yofel: next?
[13:23] <yofel> now you need to download 2.1.3 from the website as the watch file doesn't work
[13:23] <yofel> see http://kile.sourceforge.net/download.php
[13:24] <yofel> so just download the file and rename it to kile_2.1.3.orig.tar.bz2 outside the kile folder like uscan did for the other packages
[13:24] <phoenix_firebrd> yofel: ok
[13:24] <phoenix_firebrd> yofel: 2 min to download finish
[13:26] <phoenix_firebrd> yofel: for some reason the file is getting downloaded at 26 KB/s
[13:27] <yofel> blame the mirror I guess
[13:29] <phoenix_firebrd> yofel: i should put the downloaded file inide kile dir or outside?
[13:29] <yofel> outside, and it has to be named <pkg>_<version>.orig.tar.<compression>
[13:30] <phoenix_firebrd> yofel: done
[13:30] <yofel> the source folder would usually be kile-2.1.3, but here kile is enough as we don't need it unpacked
[13:31] <phoenix_firebrd> yofel: ok
[13:31] <yofel> ok, now go inside the kile folder again and run 'dch -i' which'll add a new changelog entry
[13:31] <yofel> put 'New upstream release' there for now as usual, and change the version at the top to 2.1.3 and ubuntu1
[13:32] <yofel> leave it UNRELEASED
[13:32] <yofel> now you would usually run debuild, but with bzr you need to run 'bzr builddeb -S'
[13:33] <yofel> which will fail for now as I just saw
[13:33] <phoenix_firebrd> i have done that
[13:33] <yofel> as a patch doesn't apply 
[13:36] <yofel> phoenix_firebrd: ok, as we don't have the source unpacked here we can't directly work on the patch
[13:36] <yofel> bzr runs debuild in a temporary location so lets go there
[13:36] <yofel> that's ../build-area/kile-2.1.3/
[13:37] <phoenix_firebrd> yofel: ya, i can see the build fails, so what do we do?
[13:37] <phoenix_firebrd> ok
[13:37] <yofel> there we can work on the package as if we wouldn't be using bzr
[13:37] <yofel> now let me read the patch closely, as this doesn't look reverse-applied to me...
[13:38] <phoenix_firebrd> yofel: I am inside the said folder
[13:38] <phoenix_firebrd> yofel: ok
[13:40] <yofel> ok, what upstream did between 2.1.2 and 2.1.3 in that file is this: http://paste.kde.org/655514 causing the patch to fail
[13:40] <yofel> (I found that out by pulling the 2.1.2 source from launchpad and running diff -ruN kile-2.1.{2,3}/src/data/kilestdtools.rc
[13:40] <yofel> )
[13:41] <yofel> after unpatching 2.1.2
[13:41] <phoenix_firebrd> ok
[13:41] <yofel> ok. so we need to fix the patch again, which you should now know how to do
[13:42] <phoenix_firebrd> yofel: we need to create a new patch
[13:42] <yofel> not really, we can fix the existing one. Creating the patch fresh might be a good lesson too though
[13:43] <phoenix_firebrd> yofel: I sec
[13:44] <phoenix_firebrd> yofel: i want to take a look at the log
[13:44] <phoenix_firebrd> yofel: so whats the next step?
[13:44] <yofel> actually wait, I need to look something up
[13:45] <phoenix_firebrd> yofel: shall i do what you did ?
[13:45] <phoenix_firebrd> yofel: ok
[13:45] <yofel> we might actually want to drop that patch
[13:45] <phoenix_firebrd> yofel: not needed?
[13:46] <yofel> that patch was added 2010 by fabo because kbibtex wasn't avaliable for KDE4
[13:46] <yofel> from what I see we have kbibtex 0.4 in the archive which is kde4 based
[13:47] <phoenix_firebrd> yofel: so we have to remove the patch and test with pbuilder
[13:49] <yofel> let's disable it for now
[13:49] <yofel> I just tried kbibtex, and while the UI is horrible, it seems usable
[13:49] <phoenix_firebrd> yofel: you mean delete the patch file?
[13:49] <yofel> phoenix_firebrd: ok, so let's go back to our bzr kile folder
[13:49] <yofel> no
[13:49] <phoenix_firebrd> yofel: ok
[13:50] <phoenix_firebrd> yofel:  iam inside the bzr kile/debian
[13:50] <yofel> there edit debian/patches/series and comment it out (#)
[13:50] <phoenix_firebrd> yofel: ah right
[13:50] <yofel> fabo: can we just drop that?
[13:50] <phoenix_firebrd> yofel: done
[13:51] <yofel> phoenix_firebrd: next add a line in the changelog that the patch is diabled as kbibtex is now usable with kde4
[13:51] <phoenix_firebrd> yofel: ok
[13:52] <fabo> yofel: yes
[13:52] <yofel> good
[13:53] <yofel> phoenix_firebrd: ok, remove the patch name from the series file completely and bzr rm the patch
[13:53] <phoenix_firebrd> yofel: ok
[13:54] <phoenix_firebrd> yofel: done
[13:55] <yofel> phoenix_firebrd: ok, now edit the control file and add kbibtex Suggests of kile (and mention that in the changelog)
[13:55] <yofel> *to the Suggests of kile
[13:56] <yofel> after that, bzr builddeb will finish fine and we can go to pbuilder
[13:57] <yofel> kile isn't exactly small so it'll take a while
[13:59] <phoenix_firebrd> lust4ever
[13:59] <phoenix_firebrd> oops
[14:00] <phoenix_firebrd> thats shouldn't have happended
[14:00] <phoenix_firebrd> builddeb finished successfully
[14:00] <phoenix_firebrd> yofel: ^
[14:03] <yofel> now would be the time for pbuilder, but we could skip that as it built fine here. http://paste.kde.org/655532
[14:05] <phoenix_firebrd> yofel: what should i do next?
[14:05] <yofel> ok, now
[14:05] <yofel> as we didn't add any new files, just run bzr commit. Debcommit should fill in the commit message with the changelog contents which is fine
[14:06] <yofel> so just use that
[14:06] <phoenix_firebrd> yofel: what will be the commit message?
[14:07] <phoenix_firebrd> yofel: oops
[14:07] <phoenix_firebrd> yofel: sorry
[14:07] <yofel> if you messed up run bzr uncommit and try again
[14:07] <yofel> next you need to get your changes to launchpad, so run 'bzr push lp:~murthy/kubuntu-packaging/kile-2.1.3' the last part is the branch name and I just arbitrarily choose kile-2.1.3 for now
[14:08] <yofel> the lp: syntax is lp:<owner>/<project>/<branch<
[14:08] <yofel> if you don't have a project '+junk' can be used
[14:10] <phoenix_firebrd> yofel: bzr creates a ppa ?
[14:10] <yofel> no
[14:10] <phoenix_firebrd> yofel: in that case i should create one or i should push to ppa:murthy/test ?
[14:11] <yofel> no, we don't need a package for now
[14:11] <yofel> we need the bzr contents on launchpad
[14:11] <yofel> that's what bzr push lp:~murthy/kubuntu-packaging/kile-2.1.3 will do
[14:12] <phoenix_firebrd> yofel: i have to see the output to understand
[14:13] <phoenix_firebrd> yofel: you are pushing the change to this ppa "push lp:~murthy/kubuntu-packaging/kile-2.1.3" using bzr right?
[14:13] <yofel> this is what I did: http://paste.kde.org/655544
[14:13] <yofel> that is *NOT* a PPA
[14:14] <phoenix_firebrd> "lp:~murthy/kubuntu-packaging/kile-2.1.3"
[14:14] <phoenix_firebrd> ok
[14:14] <yofel> the result of my push is this: https://code.launchpad.net/~yofel/kubuntu-packaging/kile-2.1.3
[14:14] <yofel> now you need to do it
[14:15] <yofel> that's just a bzr repository branch on launchpad, like on github and co.
[14:15] <phoenix_firebrd> yofel: ok, i did that and i am getting errors
[14:15] <yofel> uhm, ok, what kind of?
[14:16] <phoenix_firebrd> yofel: http://paste.kde.org/655550/
[14:16] <yofel> hm, then I guess you either didn't run bzr launchpad-login yet or bzr doesn't know your ssh key
[14:16] <yofel> the first I guess
[14:17] <phoenix_firebrd> yofel: ya
[14:18] <yofel> poke me when it worked
[14:19] <phoenix_firebrd> yofel: ok
[14:23] <phoenix_firebrd> yofel: finished https://code.launchpad.net/~murthy/
[14:23] <yofel> \o/
[14:23] <phoenix_firebrd> yofel: thats it?
[14:23] <yofel> nope
[14:24] <phoenix_firebrd> :)
[14:24] <yofel> but we're close
[14:24] <phoenix_firebrd> yofel: are you running out of patience?
[14:24] <yofel> no, just doing something else in parallel so it can't answer immediately
[14:25] <yofel> ok
[14:25] <phoenix_firebrd> yofel: no its not that, you have a lot of patience to teach me step by step
[14:25] <yofel> phoenix_firebrd: can you please add "* New upstream release" at the top of the changelog? It's a bit of a redundant information but it's convetion to have it in there for a new version
[14:26] <phoenix_firebrd> yofel: I never thought that someone could do that for me
[14:26] <yofel> phoenix_firebrd: I don't mind doing that if the other person listens to me ;)
[14:26] <phoenix_firebrd> yofel: ok, i will add
[14:26] <yofel> then commit and push again
[14:26] <phoenix_firebrd> yofel: i am all ears
[14:27] <BluesKaj> Hiyas all
[14:27] <yofel> after that we'll need to get your changes into the official packaging branch
[14:28] <yofel> for that, after you've commited and pushed the last change, press on "Propose for merging" on the branch page
[14:28] <phoenix_firebrd> BluesKaj: hi
[14:29] <phoenix_firebrd> yofel: thats like submitting for review? 
[14:29] <yofel> yep
[14:29] <yofel> there you'll have to set the target branch, which is lp:~kubuntu-packagers/kubuntu-packaging/kile
[14:29] <BluesKaj> hi phoenix_firebrd
[14:31] <yofel> put some useful comment in there (optional), and leave the rest open for now and press Propose Merge
[14:31] <yofel> then give me the link to the merge
[14:32] <phoenix_firebrd> yofel: i have updated the changelog, done builddeb, commited the changes and pushed it again
[14:32] <phoenix_firebrd> yofel: 1 min
[14:37] <phoenix_firebrd> yofel: https://code.launchpad.net/~murthy/kubuntu-packaging/kile-2.1.3/+merge/144714
[14:38] <yofel> good, that's the review page and launchpad will show a nice diff at the bottom once it's done loading
[14:39] <phoenix_firebrd> yofel: ok
[14:41] <phoenix_firebrd> yofel: i can see the diff now
[14:41] <yofel> phoenix_firebrd: ok, I'll change Adding to Add in the changelog, otherwise fine
[14:42] <phoenix_firebrd> yofel: you can edit that online?
[14:42] <yofel> no, but bzr merge will just import your changes which I can then edit before pushing them to the real branch
[14:43] <shadeslayer> yofel: I think you should upload kolab
[14:43] <shadeslayer> because tests will take time
[14:43] <yofel> shadeslayer: from where?
[14:43] <yofel> ah, without tests
[14:43] <yofel> can do
[14:43] <phoenix_firebrd> yofel: ok
[14:44] <yofel> phoenix_firebrd: done https://code.launchpad.net/~kubuntu-packagers/kubuntu-packaging/kile
[14:44] <yofel> now
[14:45] <yofel> filing a merge request isn't *required*, as you can just poke me with your branch on launchpad, but I wanted you to see the full process once. Sometimes it's easier that way
[14:45] <phoenix_firebrd> yofel: nice, thanks a lot
[14:47] <phoenix_firebrd> yofel: I will do the build process with bazaar and push it here and will poke you to merge
[14:47] <yofel> yeah, or someone else can do it. It's only for the packages that we have in bzr, which is the KDE SC mostly
[14:47] <yofel> you'll get to touch that once you're at ninja level ;)
[14:48] <phoenix_firebrd> yofel:  soon :)
[14:49] <phoenix_firebrd> yofel: I have to summarize and take notes of what i learned today
[14:49] <phoenix_firebrd> yofel: that would help be if i forget something
[14:50] <yofel> sure, if you have a question just ask around
[14:50] <yofel> I added one more change, just for reference: http://paste.kde.org/655586
[14:50] <yofel> I should've fixed those right at the beginning
[14:51] <phoenix_firebrd> yofel: should i build and put these packages http://qa.ubuntuwire.com/uehs/no_updated.html to bazaar branch ?
[14:52] <yofel> nah, only if they have a branch linked to in the control file
[14:52] <yofel> otherwise use the classic packaging way and put it in a PPA for review
[14:52] <phoenix_firebrd> yofel: ok
[14:52] <yofel> for the general universe packages a MOTU will have to look at them, you can file a sponshorhip request for those (a bug)
[14:53] <phoenix_firebrd> MOTU?
[14:53] <yofel> Masters of the Universe ;P
[14:53] <phoenix_firebrd> yofel: thats apachelogger right?
[14:54] <yofel> well, he's a core-dev (which implies MOTU)
[14:54] <yofel> more info on https://wiki.ubuntu.com/MOTU/Contributing and they're usually at home in #ubuntu-motu
[14:55] <phoenix_firebrd> yofel: ok
[14:55] <shadeslayer> it's funny how MOTU sounds so similar to a hindi word which stands for being fat
[14:55] <yofel> lol
[14:55] <phoenix_firebrd> ha ha ha
[14:56] <yofel> phoenix_firebrd: reason why I say that: package upload permissions are managed by package sets here, and I as kubuntu-dev can upload: http://paste.kde.org/655586
[14:56] <yofel> for the rest you need to find the appropriate person/team
[14:56] <phoenix_firebrd> yofel: i saw that when i tried to select you as a reviewer
[14:56] <yofel> I don't mind doing a review every now and then though. (rarely)
[14:58] <phoenix_firebrd> yofel: I am feeling very sleepy
[14:58] <Riddell> looks like you're getting quite into this phoenix_firebrd, well done
[14:59] <phoenix_firebrd> Riddell: thanks a lot
[14:59] <Riddell> I've also been training up vassie today, lovely to have some new talent around
[14:59] <BluesKaj> this may not be the right place to ask , but i'm having some freeze issues with firefox on 13.04 , can someone direct me to correct log to find the errors
[14:59] <Riddell> vassie's first effort appearing in https://launchpad.net/~vassie/+archive/ppa
[14:59] <vassie> glad i can help
[14:59] <yofel> BluesKaj: #ubuntu-mozillateam might know more
[15:00] <phoenix_firebrd> vassie: congrats 
[15:00] <BluesKaj> ok thanks yofel
[15:00] <vassie> phoenix_firebrd: thank you
[15:01] <phoenix_firebrd> yofel: i am getting up at 3 am 
[15:03] <yofel> wow, I can't manage that ^^
[15:03] <phoenix_firebrd> yofel: that mean your time will be around 11 pm
[15:03] <phoenix_firebrd> yofel: do you hang around at that time?
[15:03] <yofel> usually yes
[15:04] <Riddell> phoenix_firebrd: if not you can try me or anyone else
[15:05] <phoenix_firebrd> Riddell: sure
[15:05] <phoenix_firebrd> Riddell: you were awake very late yesterday
[15:06] <Riddell> late to you is not so late to me, the americans are later still :)
[15:06] <phoenix_firebrd> Riddell:  :)
[15:06]  * Riddell out for an hour
[15:07] <phoenix_firebrd> shall i got go to bed?
[15:07] <phoenix_firebrd> shall i  go to bed?
[15:07] <yofel> ok, kile up
[15:07]  * yofel looks at kolab
[15:07] <shadeslayer> yofel: I ran dh_auto_test through xvfb-run for about 16 hours
[15:08] <yofel> bah
[15:08] <shadeslayer> but it was still stuck on the first test
[15:08] <yofel> yeah, it opens kompare and waits for someone to close the window
[15:08] <shadeslayer> so we should ask the kolab people if it's possible to keep running the tests even if the kompare window is open
[15:08] <shadeslayer> and not fail if the kompare window is not closed
[15:09] <yofel> yeah, or if they could make it not use kompare
[15:09] <shadeslayer> I read the code a bit
[15:09] <shadeslayer> I couldn't figure out why it would open kompare
[15:09] <shadeslayer> because it's a macro
[15:09] <shadeslayer> which doesn't have a kompare call
[15:10] <shadeslayer> so will talk to the kolab people
[15:10] <yofel> ...
[15:10] <yofel> phoenix_firebrd: feel free to, good night
[15:11] <shadeslayer> it's only 9 PM
[15:11] <shadeslayer> yofel: I probably missed something :P
[15:13] <phoenix_firebrd> sorry i was on the phone
[15:13] <phoenix_firebrd> shadeslayer: i wakeup at 3 am daily
[15:13] <phoenix_firebrd> shadeslayer: i have to eat and do some work and i am already feeling sleepy
[15:14] <yofel> phoenix_firebrd: reading assignment for home: http://www.debian.org/doc/debian-policy/ - take your time to read it
[15:14] <yofel> as in a month or two
[15:14] <phoenix_firebrd> yofel: sure 
[15:14] <phoenix_firebrd> yofel: it will be done
[15:14] <yofel> those are the general rules we have to follow in the packages, so you should know them
[15:14] <apachelogger> like shadeslayer read the make manual
[15:14] <apachelogger> oh wait
[15:14] <apachelogger> he didn't
[15:14] <apachelogger> trololo
[15:14] <shadeslayer> I did
[15:14] <yofel> or at least remember where to look them up
[15:15]  * apachelogger leaves for lunch
[15:15] <shadeslayer> apachelogger: some of it
[15:15] <shadeslayer> but I did
[15:15] <phoenix_firebrd> ha ha ha
[15:15] <yofel> he also read the make manual (probably...)
[15:15] <shadeslayer> right :P
[15:15] <phoenix_firebrd> yofel: sure
[15:15] <yofel> phoenix_firebrd: as 'rules' is a Makefile, knowing gnu make syntax is useful
[15:16] <yofel> phoenix_firebrd: but nobody of us I think really managed to read the whole manual :P
[15:16] <yofel> except apachelogger maybe
[15:16] <apachelogger> or you'll end up like shadeslayer writing test targets as if they were bash
[15:16] <shadeslayer> like for eg. I was trying to figure out how to loop in make yesterday
[15:16] <shadeslayer> xD
[15:16] <apachelogger> ultimately being at the discretion of other binaries to work in a way that will make it work
[15:16] <yofel> hey! it was beatiful... erm, bash
[15:16] <apachelogger> yofel: you better be glad that I did not write the l10n stuff in make
[15:16] <yofel> apachelogger++
[15:17] <apachelogger> cuz I originallys tarted it in make and then ported to bash because I feared people would not be able to haxx0r it :P
[15:17] <yofel> oh
[15:17] <yofel> phoenix_firebrd++
[15:17] <yofel> ~karma phoenix_firebrd
[15:17] <kubotu> karma for phoenix_firebrd: 1
[15:17] <yofel> ;)
[15:18] <phoenix_firebrd> yofel: nice
[15:18] <phoenix_firebrd> yofel: you checked my karma?
[15:18] <shadeslayer> ~karma shadeslayer
[15:19] <kubotu> karma for shadeslayer: 16
[15:19] <shadeslayer> wohoo
[15:19] <yofel> phoenix_firebrd: it's just a play thing really ;)
[15:19] <yofel> ~karma yofel
[15:19] <kubotu> karma for yofel: 19
[15:19] <yofel> haha
[15:19] <shadeslayer> drat
[15:20] <yofel> ~karma bzr
[15:20] <kubotu> karma for bzr: -5
[15:20]  * apachelogger scratches nose
[15:20] <yofel> hehe
[15:20] <apachelogger> what shall I get for lunch? :S
[15:20] <shadeslayer> akonadi bugs
[15:20] <yofel> lol
[15:20] <apachelogger> shadeslayer: also to loop you'd use bash
[15:20] <phoenix_firebrd> ha ha ha
[15:21] <shadeslayer> apachelogger: so I was right? hooray
[15:22] <apachelogger> shadeslayer: well depends on the loop
[15:22] <apachelogger> e.g. you can dynamically build targets
[15:23] <apachelogger> FILES = foo bar foobar
[15:23] <yofel> apachelogger: I know that make does multi-pass parsing on the makefile, but I never  understood how that works
[15:23] <apachelogger> $(FILES):
[15:24] <apachelogger> \tcat $(@)
[15:24] <apachelogger> all: $(FILES)
[15:24] <apachelogger> will cat all 3 files
[15:25] <apachelogger> yofel: not sure how to explain it actually :P
[15:25] <apachelogger> well, I don't see what needs explaining anyway ^^
[15:26] <apachelogger> imagine you have the variables FILES and DIRS from which targets are built
[15:27] <apachelogger> so what happens is that make creates a target with the unique name of each file by copying the generic target, and otherwise subs FILES for the actual names
[15:28] <apachelogger> in the next pass it would use the FILE sub'd output and sub DIRS
[15:28] <apachelogger> until everything is resolved
[15:39] <shadeslayer> who has precise here?
[15:48] <allee> shadeslayer: precise on real hw or vm?  what needs verification?
[15:49] <shadeslayer> bug 1093220
[15:49] <shadeslayer> either is fime
[15:49] <shadeslayer> *fine
[15:54] <allee> shadeslayer: mhm, sounds like p2p software.   Better not at work :-(
[15:54] <shadeslayer> yes it is :)
[15:55] <shadeslayer> allee: that's fine, you can test at home :)
[15:55] <allee> :-)
[16:06] <phoenix_firebrd> good night yofel, Riddell, shadeslayer, apachelogger
[16:07] <shadeslayer> bye
[16:07] <yofel> nini
[16:07] <shadeslayer> I'll go and play some GoW myself
[16:07] <shadeslayer> ciao
[16:11] <mikhas> allee, not all torrents point to copyright violations …
[16:12] <mikhas> distros still offer torrents, too
[16:17] <Guest23195> what reason gave firefox upstream to not include KDE integration patches?
[16:29] <Guest23195> does it breaks firefox-gnome-support?
[16:31] <allee> mikhas: of course!  That's right no doubt!
[16:51] <Riddell> Guest23195: I think they just don't want to maintain it
[16:52] <Guest23195> they want to maintain gnome integration but don't want to maintain kde integration? mmmm suspicious :p
[16:54] <Riddell> closed minded indeed
[17:58] <Riddell> shadeslayer: what's needed from kde4libs and kde-workspace for active?
[17:58] <shadeslayer> there are some patches
[17:58] <shadeslayer> but I haven't tested them
[18:01] <shadeslayer> we need ftp://ftp.kde.org/pub/kde/stable/active/3.0/src/patches/kdelibs-plasma-active-patches.diff
[18:01] <Riddell> no small patch
[18:01] <shadeslayer> band this ftp://ftp.kde.org/pub/kde/stable/active/3.0/src/patches/kde-workspace-kwin-touch-mouseevents-translation.diff
[18:01] <shadeslayer> yes
[18:02] <Riddell> shadeslayer: in kde-workspace changelog you say
[18:02] <Riddell>   * Build with KDE_PLATFORM_PROFILE=Desktop
[18:02] <Riddell> but nothing in debian/rules
[18:02] <shadeslayer> yeah, ignore that
[18:03] <shadeslayer> that's whats built by default
[18:03] <shadeslayer> I probably just forgot to remove it from the changelog
[18:32] <kubotu> ::workspace-bugs:: [1066237] log out button freezes kde @ https://bugs.launchpad.net/bugs/1066237 (by J. Sundermeyer)
[20:58] <Riddell> shadeslayer: whee active is active (on my laptop)
[21:01] <shadeslayer> Riddell: lol
[21:02] <Riddell> I'm kindae suspicious how the patches aren't upstream
[21:04] <EagleScreen> /usr/sbin/guest-account script seems to copy files from /etc/guest-session/skel, but there isn't /etc/guest-session directory in my Kubuntu 12.10 system with lightdm ???
[21:06] <Riddell> EagleScreen: is there something in ubuntu desktop?
[21:08] <EagleScreen> Riddell: sorry your question is ambiguous to me
[21:10] <Riddell> EagleScreen: does an ubuntu desktop install have files there?
[21:10] <Riddell> shadeslayer: did you apckage declarative-plasmoids?
[21:10] <Riddell> shadeslayer: this is a bit incomplete Description: <insert up to 60 chars description>
[21:12] <EagleScreen> Riddell: you mean Ubuntu Desktop with Unity? I don't know, but then where Kubuntu copy guest home data from?
[21:17] <jussi> raring here we come  :D
[21:43] <Riddell> jussi: how did it go?
[21:44] <jussi> Riddell: still happening...
[22:41] <BarkingFish> evening guys :)  anyone know what is wrong with do-release-upgrade and why it's causing a traceback?
[22:46] <BarkingFish> if its something simple I can fix, i'll fix and try to use it - if not, I'll bugzilla it and leave it for whoever maintains whatever provides it :)
[22:47] <yofel> BarkingFish: seeing the traceback would help ;)
[22:48] <BarkingFish> ok, one sec and I'll pastebin it
[22:50] <BarkingFish> yofel, http://paste.ubuntu.com/1567461/
[23:12] <yofel> BarkingFish: uh, if I read EOF as End Of File this doesn't look good
[23:13] <yofel> a broken file on your system maybe?
[23:13] <BarkingFish> that's what it is
[23:13] <BarkingFish> I don't know what's caused it - but apparently, the file comes from (according to dpkg -S) "ubuntu-upgrader-release-core"
[23:14] <yofel> hm, I think it's the distutils
[23:14] <BarkingFish> i'm not aware of any broken files on my system, yofel - it's been working fine.
[23:14] <yofel> dpkg -S DistUpgrade says what?
[23:14] <BarkingFish> one sec
[23:14] <yofel> python-distupgrade or python3-distupgrade I guess
[23:14] <yofel> try reinstalling what you get
[23:15] <BarkingFish> http://paste.ubuntu.com/1567514/
[23:16] <BarkingFish> hold on, wrong package :)
[23:16] <yofel> nah, try reinstalling python3-distupgrade
[23:16] <yofel> dpkg -S is case sensitive though ;)
[23:17] <BarkingFish> http://paste.ubuntu.com/1567515/
[23:17] <BarkingFish> That's what your command gave me :)
[23:17] <yofel> ok
[23:17] <yofel> what are the contents of /usr/lib/python3/dist-packages/DistUpgrade/DistUpgradeVersion.py ?
[23:18] <BarkingFish> fixed
[23:18] <BarkingFish> reinstalled python3-distupgrade and it's running now
[23:18] <BarkingFish> upgrading me to raring's tar.gz :)
[23:18] <yofel> so broken file after all.
[23:19] <BarkingFish> yeah - I had no idea it was busted - i wouldn't have had a clue how to find out anyway!
[23:20] <BarkingFish> right, I'm gonna drop out - upgrade on the way, and if I sit here, my net will slow down too much. The joy of wifi :(
[23:20] <BarkingFish> I'll see you later :D
[23:20] <BarkingFish> thanks yofel!
[23:28] <Riddell> jussi: any luck?