[03:48] <manchicken> apachelogger: ping
[04:45] <shadeslayer_> mmm
[04:45] <shadeslayer_> yofel: kde-sc-dev-latest still seems a bit broken
[04:46] <shadeslayer_> http://paste.kde.org/pa2dc615a/
[04:48] <shadeslayer_> hm rather
[04:48] <shadeslayer_> libical-dev is old
[04:48] <shadeslayer_> :(
[04:55] <shadeslayer_> yofel: I don't think they backport libglu
[04:55] <shadeslayer_> atleast the wiki page doesn't say anything
[05:56] <markey> what does the "pi" mean? "pi  nepomuk-core - Nepomuk Semantik Desktop core libraries - transitional package"
[06:11] <soee> good morning
[06:31] <debfx> which boost version are the precise backports meant to build against?
[06:32] <debfx> currently akonadi has 1.48 while pimlibs build-depends on unversioned (= 1.46) boost
[07:30] <agateau> Riddell: hey, regarding kde-wireless vs kde-wireless2: kde-wireless was my first attempt but I didn't like it. It should be ignored. I am going to trash it
[07:30] <agateau> Riddell: regarding the Spinner: it's a new file which I introduced in r5979 http://bazaar.launchpad.net/~agateau/ubiquity/kde-wireless2/revision/5979 maybe you haven't copied it there?
[07:44] <shadeslayer_> markey: pi? I don't see a pi
[07:45] <markey> Mamarok: can you explain that?
[07:45] <shadeslayer_> and Semantik seems to be spelled incorrectly?
[07:45] <Mamarok> shadeslayer_: that's the listing inf you run aptitude search
[07:46] <shadeslayer_> I don't have aptitude here :S
[07:46] <Mamarok> markey: already explained it to you: nepomuk-core is a transitional package, should not be a hard dependency
[07:46] <markey> not to me
[07:46] <Mamarok> nepomuk-core-runtime is the one I presume
[07:46] <markey> to shadeslayer_ 
[07:46] <shadeslayer_> ah I think those letters are some sort of status or sth
[07:47] <Mamarok> that's how transitional packages appear in aptitude search, those are marked pi
[07:48] <shadeslayer_> i is probably 'installed'
[07:48] <shadeslayer_> v is probably virtual
[07:49] <Mamarok> shadeslayer_: man aptitude explains those
[07:49] <Mamarok> but that is not the problem, markey
[07:49] <shadeslayer_> righto
[07:49] <Mamarok> the problem is that our cmake is looking for a package marked as transitional
[07:50] <Mamarok> which might not be installed, as it is not needed technically
[07:50] <shadeslayer_> hm? The package name doesn't dictate CMake files AFAIK
[07:51] <shadeslayer_> though difficult to say without actually knowing the real problem :)
[07:52] <Mamarok> shadeslayer_: I talk about Amarok's cmake
[07:53] <shadeslayer_> tbh I'm not even sure why I'm on IRC right now o_o
[07:54] <shadeslayer_> Mamarok: and you're just trying to build amarok on kubuntu?
[07:54] <shadeslayer_> or well, markey is ?
[07:55] <Mamarok> shadeslayer_: this was a warning error triggered when markey compiled this morning
[07:55] <shadeslayer_> I see
[07:57] <markey> yep
[08:20] <Quintasan> \o
[08:21] <shadeslayer_> hi Quintasan]
[08:26] <shadeslayer_> that should fix kdepimlibs
[08:53] <yofel__> Mamarok, markey: please note that our packages cannot know how you name a dependency in cmake (nor do they match the names of cmake config files if there are any).
[08:53] <yofel__> so if nepomuk-core is missing, you probably want to install nepomuk-core-dev, for nepomuk-widgets you would want libnepomukwidgets-dev, etc.
[08:53] <markey> nevermind, it was all a big misunderstanding
[08:54] <markey> source of the confusion was, I used to have this package installed, and after some upgrades it wasn't installed anymore
[08:54] <Mamarok> for some very obscure reason
[08:54] <Mamarok> it wasn't installed here anymore either
[08:54] <Mamarok> markey uses KDE 4.10.5, I use 4.10.95
[08:55] <Mamarok> both Raring
[08:55] <markey> that's not true
[08:55] <xnox> ubiquity/frontend/kde_ui.py:569: undefined name 'QWidget'
[08:55] <yofel__> oh right: We named the package nepomuk-core, debian named it nepomu-core-runtime so it was removed in the last merge and uninstalled. I then later added a transitional package to make it less confusing
[08:55] <Mamarok> markey: no?
[08:55] <markey> no#
[08:55] <markey> told you before
[08:55]  * Mamarok is confused
[08:56] <Mamarok> markey: you didn't have nepomuk-core-dev installed anymore, didn't you?
[08:56] <markey> no
[08:56] <Mamarok> neither did I
[08:56] <markey> well yofel just explained it
[09:01] <yofel__> shadeslayer_: yeah, libglu was a mistake on my side. (I thought that I fixed all the wrong packages :/ )
[09:17] <Riddell> agateau: I copied spinner to /usr/lib/ubiquity/ubiquity/frontend/kde_components/
[09:17] <Riddell> agateau: it still needed the import changed
[09:53] <agateau> Riddell: oh ok, it is quite possible I only tested it with the test program :/
[09:53] <agateau> Riddell: how did you change it?
[09:53] <agateau> rather, what did you change the import into?
[11:02] <apachelogger> Riddell: how does one branch from bzr using an existing local history?
[11:13] <agateau> apachelogger: you mean creating a branch from another local branch?
[11:18] <apachelogger> agateau: no, branching a remote branch that is derived from another remote branch from which I already have a local branch
[11:18] <apachelogger> like git remote add
[11:18] <apachelogger> so it will not download the entire history even though I have like 99% of it already locally
[11:20] <agateau> apachelogger: oh. my bzr foo is not strong enough for that
[11:23] <kubotu> ::workspace-bugs:: [1206199] /etc/localtime incorrect link created by dateandtime kcm @ https://bugs.launchpad.net/bugs/1206199 (by Leszek Lesner)
[11:43] <apachelogger> agateau: I actually fear one cannot do that :/
[11:44] <agateau> apachelogger: you mean mighty bzr is not as powerful as you thought?! ,)
[12:04] <apachelogger> agateau: ... :P
[12:22] <apachelogger> yofel__: fixed startneon5 a bit toget a more sensible session out of it
[12:23] <yofel__> oh? what does it run now?
[12:34] <Riddell> apachelogger: sorry, changed the import to    from ubiquity.frontend.kde_components.Spinner import Spinner
[12:34] <Riddell> agateau: sorry, changed the import to    from ubiquity.frontend.kde_components.Spinner import Spinner
[12:34] <Riddell> agateau: how do I run the test programme again?
[12:35] <agateau> Riddell: as root, go into your ubiquity source dir, then run PYTHONPATH=$PWD python3 ubiquity/frontend/kde_components/nmwidgets.py
[12:35] <agateau> vi !$
[12:36] <apachelogger> yofel__, shadeslayer_: did someone retry qtwebkit? Oo
[12:37] <agateau> oups, wrong window :/
[12:38] <agateau> Riddell: just pushed your fix in
[12:39] <yofel__> apachelogger: I retried the one that failed
[12:40] <apachelogger> yofel__: please don't
[12:40] <apachelogger> it's completely kaput
[12:41] <apachelogger> will get stuck forever or fail right away
[12:41] <apachelogger> I also deactivated the daily build consequently
[12:41] <apachelogger> no clue why it fails though... well, I do, I just don't  know what to do about it :P
[12:41] <apachelogger> qmake is being recursively invoked when checking for dependencies... recu;rsively as in checking for fontconfig will invoke the check for fontconfig...
[12:42] <yofel__> urgh
[12:42] <apachelogger> new qt builds incoming though
[12:43] <apachelogger> yofel__: qtwebkit isn't required for anything important right now anyway, so not that important for now
[12:43] <apachelogger> FWIW, it's exactly the issue I had when building qtwebkit inside the qt5 meta
[13:00] <Riddell> apachelogger: this neon5 session isn't running for me
[13:00] <Riddell> apachelogger: http://paste.kde.org/p58785a9b/
[13:00] <Riddell> apachelogger: line 16 looks important
[13:00] <apachelogger> ah
[13:00] <apachelogger> not published yet
[13:00] <Riddell> apachelogger: what's not?
[13:00] <apachelogger> project-neon5-session
[13:01] <apachelogger> the previous startneon5 didn't fire up kdeinit5 making it rather not doing anything ^^
[13:02] <apachelogger> hm, actually should be published already
[13:02] <apachelogger> Riddell: make sure you have session 282~saucy1
[13:02] <Riddell> apachelogger: I have 281~saucy1 installed
[13:02] <apachelogger> right, needs upgrade
[13:02] <Riddell> no 282~saucy1 available
[13:02] <Riddell> ooh there it is
[13:03] <Riddell> just appeared
[13:03] <Riddell> ok.. wish me luck
[13:04] <Riddell> well something works :)
[13:04] <apachelogger> weeh
[13:06] <Riddell> sweet http://starsky.19inch.net/~jr/tmp/plasma2.png
[13:06] <Riddell> presumably it's known that it's not full screen?
[13:07] <Riddell> apachelogger: can I blog about this?
[13:08] <Riddell> cos it's pure blogworthy
[13:08] <apachelogger> I'd do it when/if workspace starts building on raring
[13:08] <apachelogger> triggered a build on possible fix
[13:19] <Riddell> agateau: I think "wi-fi" should be "Wi-Fi" in the text
[13:20] <agateau> Riddell: I am using the generic Ubiquity strings there
[13:20] <agateau> Riddell: so it's not really in my control
[13:20] <Riddell> agateau: oh fair enough then
[13:21] <agateau> Riddell: but I agree with you :)
[13:21] <apachelogger> yofel__, shadeslayer_: kdeexamples test build on saucy triggered
[13:21] <apachelogger> daily builds off for now
[13:21] <apachelogger> (didn't test locally :P)
[13:22] <Riddell> I'll reboot again into a live system see if I can turn on debugging or anything to get it working
[13:34] <Riddell> agateau: whole new backtrace now http://paste.kde.org/p482c1fe5/
[13:34] <agateau> damn
[13:35] <agateau> should really have tested it with the real Ubiquity
[13:35] <Riddell> ach who needs testing :)
[13:35] <agateau> Riddell: this is because it fails to load the "process-working" icon
[13:35] <agateau> which is provided by the Oxygen icon theme
[13:35] <Riddell> mm, that should have been fixed by your previous fix
[13:36] <Riddell> I hand copied the files needed by this branch into my live system, wonder if I missed something for that
[13:36] <agateau> I agree it should have worked
[13:36] <Riddell> there's your whole widget relayout branch as well that might be causing confusion
[13:37] <agateau> I haven't been using that branch for this work
[13:37] <BluesKaj> Hi folks
[13:43] <Riddell> agateau: ok fixed by your icon theme fix from before, that hasn't made it into this branch http://bazaar.launchpad.net/~ubuntu-installer/ubiquity/trunk/revision/5955#ubiquity/frontend/kde_ui.py
[13:43] <agateau> Riddell: oh right, good catch!
[13:43] <agateau> Riddell: going to merge it in
[13:45] <Riddell> agateau: so now I get same as yesterday, it has a gap in the steps list on the left but it skips over it and goes straight to partitioning
[13:46] <Riddell> agateau: nothing in syslog or installer/debug about wireless
[13:46] <Riddell> setting export UBIQUITY_DEBUG=1 doesn't help
[13:46] <agateau> Riddell: ok so. The gap is because we are missing a translation: I added the text to debian/ubiquity.templates but I am not sure how to get that compiled/installed
[13:47] <agateau> Riddell: the wireless step is skipped if you have network at install time (for example if you are in a vbox or if you have a wired connection)
[13:47] <agateau> Riddell: Ubuntu installer behaves the same
[13:48] <agateau> so you need to have a not-connected wireless card and no wired connection
[13:48] <agateau> you can somehow force the step to show using by passing "--wireless" to ubiquity, but it will behave strangely when the connection has already been established
[13:49] <agateau> Riddell: what are you testing it on?
[13:49] <Riddell> agateau: my laptop,live system, alpha 2
[13:50] <agateau> Riddell: and do you have a wired connection?
[13:50] <Riddell> no wireless
[13:50] <Riddell> do I need to disconnect that?
[13:50] <agateau> "no wireless" ?
[13:51] <agateau> you need 1) a wireless card, but not already connected to an access point
[13:51] <agateau> 2) no established wired connection
[13:51] <agateau> Riddell: @
[13:51] <agateau> Riddell: ^
[13:52] <Riddell> sweet,it works!
[13:52] <agateau> \o/
[13:54] <Riddell> agateau: so most important thing, do you want to blog this or shall I?
[13:54] <agateau> Riddell: shouldn't we wait until it's in saucy to blog about it?
[13:55] <Riddell> bah, waiting, who's got the patience for that?
[13:55] <Riddell> xnox: do you trust me to review the nm.py code split?
[13:55] <agateau> Riddell: feel free to blog about it then, just mention it's young code :)
[13:56] <xnox> Riddell: as long as it merges without conflicts, is pyflakes/pep8 clean, and does crash the installer, that's fine. Added bonus if you did test that gtk-wifi page comes up. Otherwise, I would have tested that with next daily.
[13:56] <xnox> s/does/doesn't/
[13:56] <kubotu> xnox meant: "Riddell: as long as it merges without conflicts, is pyflakes/pep8 clean, and doesn't crash the installer, that's fine. Added bonus if you did test that gtk-wifi page comes up. Otherwise, I would have tested that with next daily."
[13:57] <agateau> damn, crashing the installer is much easier than not crashing it!
[13:57] <agateau> Riddell: just merged trunk in kde-wireless2 to fix the missing icon
[13:58] <Riddell> gtk stide 
[13:59] <Riddell> ahem
[13:59] <Riddell> agateau: and the widget refactoring? isn't there a clash in style.qss?
[13:59] <Riddell> gtk wifi page still working fine
[14:00] <agateau> Riddell: I fixed the merge conflict before pushing
[14:00] <agateau> Riddell: I am not that clumsy :)
[14:41] <Riddell> hmm ubiquity seems to need me to run kdesudo manually now, it didn't a few versions ago
[14:46] <Riddell> xnox: is that your autopilot changes?
[14:47] <xnox> Riddell: there is no kdesudo anymore.
[14:47] <xnox> Riddell: pkexec is used on all flavours now.
[14:48] <Riddell> cos, policykit fancyness
[14:48] <Riddell> ooh policykit fancyness
[14:49]  * apachelogger notes that this can have unwanted sideeffects as the envrionment is not carried over
[14:53] <apachelogger> eek
[14:53] <apachelogger> workspace continues to fail
[14:54] <Riddell> naughty workspace
[14:58] <yofel__> probably because they can't make up their mind on the branchname 
[14:59] <apachelogger> lol?
[15:00] <apachelogger> oh there was a fix for dbusmenuqt
[15:03] <apachelogger> yofel__, shadeslayer_: triggered another workspace build, saucy only in case it fails again
[15:03] <apachelogger> off for dinner now
[15:05] <mgraesslin> apachelogger: I'll just answer here
[15:05] <mgraesslin> xrandr and xrender can probably be dropped
[15:05] <apachelogger> mgraesslin: so that's just transitional?
[15:06] <mgraesslin> I guess so, it's probably still linked
[15:06] <mgraesslin> but shouldn't be used
[15:06] <mgraesslin> at least we ported away from xrender
[15:06] <mgraesslin> and the only xrandr code got ifdefed
[15:06] <mgraesslin> xcursor is needed and I don'
[15:06] <mgraesslin> t
[15:06] <mgraesslin> understand why it's missing
[15:06] <apachelogger> no cmake checks or somesuch?
[15:07] <mgraesslin> it doesn't complain on my system
[15:07] <apachelogger> yofel__, shadeslayer_: ^ I reckon the build will fail on xcursor missing
[15:07] <yofel__> oh well
[15:08] <mgraesslin> I will look into that tomorrow morning
[15:08] <mgraesslin> and fix it
[15:08] <yofel__> mgraesslin: any news on that kwin build patch btw.?
[15:08] <apachelogger> mgraesslin: perhaps you are find_packaging it but don't reflect it via macro_log_feature or what it's called?
[15:08] <mgraesslin> yofel__: I can give you the link for the 4.10 version, but I did not yet rebase to 4.11
[15:08] <apachelogger> mgraesslin: would at least explain why there is no indication of it up to the warning that it is set to notfound
[15:08] <mgraesslin> oh that could be - macro_log_feature got dropped
[15:09] <apachelogger> well, something replaced it judging from the output of cmake, I just do not know what ^^
[15:09] <apachelogger> (reminds me that I need to redo the entire cmake for phonon5 :@)
[15:09] <yofel__> mgraesslin: would that be a lot of work? If not I could give it a try
[15:09] <apachelogger> mgraesslin: anyway, we'll see where the build gets today and if it fails we can prod it into building tomorrow
[15:10] <mgraesslin> I'm not sure, I think the cmake stuff in base directory changed, so it won't work
[15:10] <apachelogger> -> dinner
[15:10] <yofel__> ah
[15:10] <mgraesslin> yofel__: the patch for 4.10 is http://quickgit.kde.org/?p=clones%2Fkde-workspace%2Fgraesslin%2Fkde-workspace.git&a=commit&h=2f23192fe2658b9ecde005db40b2ec366b3e18d4
[15:11] <yofel__> thanks!
[15:11] <mgraesslin> looking at the patch I doubt it will compile on 4.11
[15:18] <Riddell> agateau: gosh you have code to draw icons with qpainter in here, isn't it simpler just to edit the oxygen icons?
[15:19] <agateau> Riddell: wanted to avoid the mess of having to get new images to install correctly, but you are probably right
[15:19] <agateau> Riddell: I can install real images if you prefer
[15:21] <Riddell> agateau: oh it's fine, just surprising
[15:27] <Riddell> agateau: yep looks good, I think I'll commit it
[15:27] <agateau> Riddell: have you already merged the nm-split branch in?
[15:30] <Riddell> agateau: that's part of the kde-wireless2 branch surely?
[15:31] <agateau> Riddell: it is, indeed
[15:31] <agateau> Riddell: will LP notice?
[15:31] <Riddell> moving bits from one file nm.py to a gtk component file makes good sense, gui bits belong better there anyway
[15:47] <Riddell> agateau: hmm a couple of possible errors?
[15:47] <Riddell> ubiquity/plugins/ubi-wireless.py:21: 'syslog' imported but unused
[15:47] <Riddell> ubiquity/plugins/ubi-wireless.py:65: 'nmwidgets' imported but unused
[15:48] <agateau> mmm
[15:48] <agateau> I need to update to Saucy (no pyflakes3 here)
[15:48] <agateau> syslog => can probably be removed
[15:48] <agateau> nmwidgets => looking into it
[15:48] <Riddell> ah but you have a comment about needing toimport it
[15:48] <Riddell>         # NOTE: Import 'nmwidgets' even though it's not used in this function                                                 
[15:48] <Riddell>         # as importing it as the side effect of registering                                                                   
[15:48] <Riddell>         # NetworkManagerWidget which we DO use in the Wireless step UI.                                                       
[15:49] <agateau> that is in the gtk code, right?
[15:49] <Riddell> yeah
[15:50] <agateau> Riddell: this import was there before but was importing something else
[15:50] <Riddell> it makes the ./tests/run-pyflakes test fail
[15:51] <Riddell> oh before it was 
[15:51] <Riddell> -        # NOTE: Import 'nm' even though it's not used in this function as
[15:51] <agateau> yes
[15:51] <agateau> I wonder how this got through pyflakes
[15:52] <agateau> maybe that's because it imports "misc" on the same line? or was it whitelisted in the test?
[15:52] <Riddell> nm is used elsewhere in the file
[15:52] <Riddell> I don't see a whitelist
[15:53] <agateau> ah that's why pyflakes does not complain
[15:53] <agateau> it's not smart enough
[15:54] <agateau> a simple and clean fix would be to *not* register things at import time (which is bad practice anyway) and add an explicit register() function, which would be called from the code importing nmwidgets
[15:54] <xnox> Riddell: we had a guard / whitelist for run-pyflakes, might need adjustment.
[15:55] <xnox> Riddell: agateau: adjust ./tests/pyflakes.exclude
[15:55] <Riddell> xnox: ah that's the one
[15:56] <agateau> xnox: right, thanks
[15:56] <agateau> pushing the change in 10 secs
[15:57] <agateau> Riddell: pushed
[15:59] <Riddell> agateau: this however is just unexcusable...
[15:59] <Riddell> ubiquity/frontend/gtk_components/nmwidgets.py:12:1: E302 expected 2 blank lines, found 1
[16:00] <agateau> damn
[16:00] <agateau> Riddell: mmm, I have no blank lines there
[16:01] <Riddell> agateau: no me neither and now I run it again the issue disappears
[16:01] <agateau> and run-pep8 is happy there
[16:01] <agateau> Riddell: reliable tooling :)
[16:01] <Riddell> maybe it was me who made the unexcusable error in my testing and it get tidied up when I merged with yours
[16:02]  * Riddell hangs head in shame
[16:08] <agateau> thou shall not mess with pep8!
[16:12] <Riddell> agateau: this looks more problematic http://paste.kde.org/pf5322790/
[16:13] <agateau> oww
[16:13] <agateau> Riddell: did not notice there was unittests for these classes
[16:15] <Riddell> agateau: able to tidy those up?
[16:16] <agateau> Riddell: looking into it
[16:16] <agateau> Riddell: if I don't get it done today, I'll be working on it tomorrow
[16:16] <Riddell> groovy
[16:26] <xnox> Riddell: agateau: why do i have email "2 revisions removed from brunch lp:ubiquity" ?
[16:26] <xnox> is it ok, or did you push override my upload =)
[16:26] <agateau> xnox: I have no idea
[16:27] <xnox> ok.
[16:27] <Riddell> xnox: I uncommitted
[16:27] <Riddell> because of the test failures
[16:27] <xnox> Riddell: ack.
[16:43] <shadeslayer_> yofel: since you know about the issue, can you have a look at what's causing the weirdness wrt nepomuk and db?
[16:46] <shadeslayer_> uhhh
[16:46] <shadeslayer_> this build log looks weird
[16:57] <yofel> shadeslayer_: where?
[16:58] <shadeslayer_> trello
[16:58] <shadeslayer_> that thing where nepomuk doesn't start
[16:58] <shadeslayer_> because it can't start the db, or connect to it or sth
[17:02] <yofel> shadeslayer_: there's 2 issues I can think of: 
[17:02] <yofel> 1) people using 3rd party virtuoso (or something coming from debian experimental) leading to a lib lookup issue like we had in neon
[17:02] <yofel> 2) system crashes or something like that corrupting soprano-virtuoso.trx which requires a manual recovery
[17:03] <shadeslayer_> yofel: regarding 1, who even uses a 3rd part virtuoso o_o
[17:03] <yofel> vHanda wanted to look at 2) at some point because it happened to me during akademy, not sure what came out of it
[17:03] <shadeslayer_> ack
[17:03] <yofel> shadeslayer_: no idea, that's why I'm not too worried about that (but maybe extending the RPATH with the multiarch dir might be a good idea)
[17:29] <yofel> kde status cleanup
[17:49] <Peace-> Riddell: :) http://cli-apps.org/CONTENT/content-pre1/159751-1.jpeg
[17:49] <shadeslayer_> apachelogger: qtwebkit still OOM'ing?
[17:49] <shadeslayer_> stupid thing still hangs on fontconfig
[17:54] <apachelogger> yes
[17:54] <apachelogger> well, it doesn't oom
[17:54] <apachelogger> it forkbombs
[17:55]  * yofel tries a build
[17:57] <yofel> apachelogger: why does it need that syncqt.pl call?
[18:01] <apachelogger> header creation
[18:06] <shadeslayer_> the question is, is that the recommended way of building it
[18:06] <shadeslayer_> since there seem to be atleast 3 build systems
[18:06] <shadeslayer_> -.-
[18:06] <yofel> the archive package uses qmkae
[18:06] <shadeslayer_> and the README is empty
[18:06] <yofel> and the other 2 systems don't work for me
[18:06] <shadeslayer_> !find synqt.pl
[18:06] <shadeslayer_> !find synqt.pl saucy
[18:07] <shadeslayer_> where be that file
[18:07] <yofel> project-neon-qt5
[18:07] <shadeslayer_> I see
[18:07] <yofel> project-neon5-qt5 actually
[18:09] <yofel> wtf, 'qmake' forkbombs. 'mkdir build; cd build; qmake ..' doesn't
[18:10] <shadeslayer_> 0.o
[18:27] <shadeslayer_> yofel: stops at Checking for fontconfig for me
[18:28] <yofel> it did finish after a while here
[18:28] <shadeslayer_> ah yes
[18:29] <shadeslayer_> yofel: so, IIRC there's an option to specify the build dir right?
[18:29] <shadeslayer_> -B I think
[18:30] <shadeslayer_> let's try using that :P
[18:33] <yofel> why does this not happen to the archive package...
[18:33] <shadeslayer_> because, magic
[18:41] <yofel> uh... and why does this not happen in git?!?
[18:45] <shadeslayer_> :O
[18:45] <shadeslayer_> indeed
[19:13] <shadeslayer_> yofel: maybe something the mk files do?
[19:14] <yofel> well... 
[19:14] <yofel> this doesn't happen if I create the package from git
[19:14] <yofel> this doesn't happen if I create the package from bzr
[19:14] <yofel> now I'm trying to run dailydeb by hand to see what happens
[19:14] <shadeslayer_> oh
[19:41] <yofel> lolwhat
[19:42] <yofel> when building qtwebkit built by bzr dailydeb it forkbombs @_@
[20:50] <shadeslayer_> yofel: o_o
[20:50] <shadeslayer_> what about using apachelogger's custom build scripts
[20:51] <yofel> well, I'm wondering if the foldername with the complex package version is the issue
[20:51] <yofel> need to try that 
[20:53] <shadeslayer_> why would that be a factor 0.o
[20:53] <shadeslayer_> unless qmake trips on the path and goes bezer
[20:53] <shadeslayer_> *bezerk
[20:53] <shadeslayer_> ( like it did with the space in my folder name in the Sailfish SDK )
[21:01] <Noskcaj> Are we able to go without a debian import for terminus? I've made a .deb for the latest version, which allows it to be run on kubuntu again
[21:02] <Riddell> Noskcaj: what's terminus?
[21:02] <Noskcaj> Riddell, a font, that breaks bits of kubuntu. bug 812134
[21:02] <Riddell> mm, why would we want it then?
[21:04] <yofel> shadeslayer: yeah, seesm to be the folder name O.O
[21:04] <Noskcaj> Riddell, because i just fixed it, and it's a very popular font.
[21:04] <yofel> try to rename the git clone to project-neon5-qtwebkit-0.0+git20130726+r164~84d199a+neon6~test1, then run qmake in there
[21:05] <shadeslayer> O_O
[21:05] <shadeslayer> yofel: okay yeah, that's just freaking broken
[21:05] <shadeslayer> are you saying it trips on saucy1?
[21:06] <yofel> it trips on *something*, I'm renaming now
[21:06] <shadeslayer> yofel: btw http://bcache.evilpiepirate.org/
[21:06] <Riddell> Noskcaj: aah
[21:06] <shadeslayer> might be beneficial for you :)
[21:06] <Riddell> Noskcaj: such we can get that in, is it on the bug?
[21:06] <yofel> seen the initial post when it was merged, not sure what to do with it
[21:07] <yofel> could be useful or virtualbox I guess
[21:07] <Noskcaj> Riddell, I'll make the .dsc now
[21:07] <yofel> *for
[21:10] <yofel> shadeslayer: seems like '+' is the fuse
[21:10] <yofel> project-neon5-qtwebkit-0.0+ BOOM, project-neon5-qtwebkit-0.0 WORKS
[21:10] <yofel> (WTF)
[21:11] <yofel> apachelogger: ^
[21:11] <shadeslayer> what the flying fuck
[21:15] <yofel> I changed the version string to 0.0.git{date}.r{revno}~{git-commit}.neon{revno:packaging} (unless someone has a better idea)
[21:16] <shadeslayer> fine with me
[21:16] <shadeslayer> actually
[21:16] <shadeslayer> yofel: you could change the build for Qt
[21:16]  * shadeslayer does that himself
[21:16] <yofel> what do you mean?
[21:16] <shadeslayer> well
[21:16] <shadeslayer> currently the qt build disables mm and webkit
[21:17] <shadeslayer> we could change the version on qt and try building with mm and webkit]
[21:17] <yofel> I would rather have qtwebkit seperate...
[21:17] <shadeslayer> why? :D
[21:17] <yofel> takes too long to build would be one reason
[21:17] <shadeslayer> okay
[21:18] <shadeslayer> lemme try mm then
[21:26] <Noskcaj> Riddell, I've added the files from the new debian version. The debian maintainer hasn't gotten to it yet, and it would be nice to fix this by 13.10
[22:14] <shadeslayer> yofel: yep, mm compiles 
[22:14] <shadeslayer> when you set the version without the + signs
[22:56] <apachelogger> Oo
[22:56] <apachelogger> yofel: nice catch
[23:09] <shadeslayer> ^^
[23:15] <shadeslayer> apachelogger: we can enable mm now btw if we fix the versioning in the Qt package