[05:52] <pitti> Good morning
[07:29] <bkerensa> cyphermox: So any new info you need for Bug #972063
[08:30] <soren> No dholbach today?
[08:38] <seb128> soren, he's on holidays still I think, let me check
[08:39] <soren> Ok.
[08:39] <didrocks> seb128: soren: he is
[08:39] <soren> seb128, didrocks: Alrighty. Thanks, guyes.
[08:39] <soren> guys, even.
[08:42] <seb128> soren, he's not noted in the holidays calendar but I would say he's still away for a week
[08:44] <didrocks> seb128: I got yesterday the confirmation he is :)
[08:44] <didrocks> hence my answer
[08:50] <seb128> didrocks, ok, sorry I didn't read the channel was I was looking and didn't see your answer before adding my extra comment ;-)
[08:50] <didrocks> no worry ;)
[08:52] <ppisati> guys, why do we make life of Skype users so hard?
[08:53] <ppisati> if you tick the "start minimised in tray", close and restart Skype it looks like it's gone
[08:53] <ppisati> but it's running, just it doesn't show up in tray
[10:11] <seb128> tkamppeter,
[10:11] <seb128> hey
[10:11] <seb128> re your ghostscript upload:
[10:11] <seb128> "  * debian/control: Re-added build dependency on libicc-dev, it seems that
[10:11] <seb128>     it got lost by some Debian/Ubuntu merge."
[10:11] <seb128> tkamppeter, it was not lost, argyll is in universe, you need a MIR for it
[10:23] <wookey> can someone merge libslang2 from debian to fix lp:1028451, becausenot being able to edit anything in quantal is _really_ annoying (much as it was in debian before it got fixed there :-)
[10:24] <wookey> I guess thre is an official merge-request button I should push somewhere
[10:24] <seb128> wookey, hey, I will have a look
[10:24] <wookey> cheers
[10:58] <didrocks> doko_: hey, around?
[11:34] <wooy> hi
[11:34] <wooy> why would someone start patch file like this:
[11:35] <wooy> --- /dev/null
[11:35] <wooy> +++ real/path/here
[11:46] <wooy> got it
[11:46] <wooy> `diff /dev/null new.config > some.patch`
[11:54] <Chipzz> wooy: noone does. I think it's the result of a diff -r where the file doesn't exist in the 1st dir
[11:56] <wooy> yep, thats directory wide equivalent to the cmd above i think
[12:09] <wooy> also, as it seems, using --- path and +++ path is bit fuzzy, replacing one of them with /dev/null makes the other one the only candidate, making it bit more predicable (at least to me)
[13:35] <infinity> Sweetshark: Have a libreoffice upload pending?  It needs a rebuild ASAP for the libexttextcat SOVER transition.
[14:01] <stgraber> arges, seb128: meeting in #ubuntu-meeting
[14:02] <Sweetshark> infinity: soonish.
[14:02] <infinity> Sweetshark: "ish"?
[14:02] <seb128> stgraber, thanks
[14:02] <infinity> Sweetshark: I'm going to upload a rebuild right now, then, if "ish" isn't "pretty close to right now".
[14:02] <infinity> Sweetshark: Cause the world is uninstallable. :/
[14:03] <Sweetshark> infinity: ok, pushing package to chinstrap
[14:04] <infinity> Oh, a new RC.  Fun.
[14:04] <infinity> Sweetshark: No changes except for the new upstream source?  (ie: no changes in debian/* ?)
[14:06] <Sweetshark> infinity: minimal changes in debian IIRC
[14:07]  * Sweetshark checks
[14:08] <Sweetshark> infinity: so, I reenabled binfilter (otherwise libreoffice-dbg is uninstallable)
[14:09] <infinity> Sweetshark: Making it not depend on it would have worked too. :P
[14:09] <Sweetshark> infinity: also that package completed at https://launchpad.net/~libreoffice/+archive/libreoffice-prereleases/+sourcepub/2590864/+listing-archive-extra for i386 and is far in the build for amd64. so should be reasonably safe to upload.
[14:10] <apw> i assume its casper which displays the "Is connected to power" "Is connected to the internet" screen during installation
[14:10] <Sweetshark> infinity: /me has a secret plan to kill stupid binfilter upstream and for good.
[14:13] <Sweetshark> infinity: see https://wiki.documentfoundation.org/Development/LibreOffice4#General_changes
[14:14] <infinity> Sweetshark: So, shouldn't libreoffice-dbg use the magic ${ooo-binfilter-dep}, so it ends up installable on ARM too?
[14:20] <infinity> Sweetshark: Although, I guess it uses a bit |ed list anyway.  So, I'm not sure why that was ever uninstallable?
[14:23] <infinity> Sweetshark: Meh.  Nevermind the binfilter annoyance.  A more verbose changelog would be nice, though, since it doesn't actually say what you changed.
[14:23] <infinity> Sweetshark: http://paste.ubuntu.com/1125276/ <-- All of those changes would be nice to have mentioned.
[14:24] <arges> infinity, hey any updates on http://launchpad.net/bugs/979003 AVX/FM4? Today is the last day if its going to make it in the 12.04.1 point release, if it ain't going to happen, i'll bump it to target 12.04.2 thanks
[14:24] <infinity> arges: Oh, it's gonna make it, if I have to bribe stgraber with cookies.  Or if I have to hurt myself to get it done today.  Or both.
[14:24] <Sweetshark> infinity: next time, when I am not finalizing the package ad-hoc on your request during an engineering steering committee call discussing if rc4 is final ....
[14:25] <arges> infinity, ok well before resorting to hurting youself, ping me and i'll try to help out where i can
[14:25] <stgraber> infinity: when can you get it uploaded (without hurint yourself too much ;))?
[14:26] <infinity> stgraber: Tonight or tomorrow, testing pending.  Handwavy and such.  If testing hates me, weekend at the latest, cause I refuse to let it drag into next week. :P
[14:28] <stgraber> infinity: ok, I'll add the two bug numbers to the exception list then so I don't re-milestone these to .2 and know that they'll get fixed post-freeze time
[14:28] <infinity> stgraber: I think there might be more than two.  But I'll poke you when it's all finalised.
[14:28] <infinity> (It'll be obvious from the changelog anyway)
[14:29] <stgraber> infinity: looks like bug 979003 is the only milestoned one (unless I missed something quickly reading through the bug list)
[14:29] <infinity> stgraber: Oh, I have others with precise tasks that probably failed to get milestoned, but I don't see much point doing them separately, since the AVX/FMA4 bits are the hardest part, the rest is fluff.
[14:30] <infinity> stgraber: I'll dig it all up for you later today as I get it happier.
[14:31] <stgraber> ok, thanks
[14:33] <infinity> Sweetshark: Uploaded.
[14:36] <Sweetshark> infinity: awesome, thanks!
[14:46] <jibel> Sweetshark, infinity FYI 1:3.6.0~rc4-0ubuntu1~ppa1 is building in the lab. i386 built fine and and it building the packages, amd64 is still running
[15:16] <infinity> jibel: Well, we'll find out soon enough if the one I uploaded to the archive builds.  It can't be any worse than the current situation. :P
[15:34] <dobey> is there a branch import queue status page somewhere?
[15:35] <jelmer> dobey: http://code.launchpad.net/+code-imports/+machines
[15:47] <dobey> jelmer: i meant for the UDD branches. merging from the debian source packages into the lp:ubuntu/foo branches
[15:48] <dobey> jelmer: sorry if that wasn't clear. :)
[15:48] <jelmer> dobey: ah - see http://package-import.ubuntu.com/status/
[15:49] <dobey> ah, thanks
[15:50] <dobey> jelmer: hrmm, i don't see ubuntuone-control-panel mentioned anywhere on that page, but the lp:ubuntu/ubuntuone-control-panel branch is out of date…
[15:53] <dobey> wonder where it went :(
[15:56] <jelmer> dobey: it might just be in the list of failures
[15:57] <jelmer> hmm, I don't see it there either
[16:00] <dobey> jelmer: right, i searched the whole page with firefox search-in-place and got nothing :)
[16:05] <tkamppeter> seb128, can I MIR only libicc?
[16:11] <seb128> tkamppeter, no, you can't MIR a library, libicc is shipped by argyll
[16:14] <tkamppeter> seb128, I remember that I once tried to MIR argyll, but due to argyll's strange build system, which is not maintained any more and therefore cannot be MIRed into Main, too, I stopped trying to complete the MIR for argyll.
[16:15] <seb128> tkamppeter, that's probably why ghostscript was not build-depends on libicc then
[16:15] <seb128> tkamppeter, you might want to drop that build-depends again
[16:17] <tkamppeter> seb128, for me it seems that I will return to Ghostscript's internal libicc then, having this the only internal lib of GS due to distro-unfriendlyness of Argyll.
[16:26] <infinity> tkamppeter: Hrm?  If argyll wasn't pulling an old version of libtiff back into main, I fail to see what other grounds it would fail an MIR on.
[16:26] <infinity> tkamppeter: Build system is a silly one, we have tons of weird build systems in main.
[16:31] <infinity> tkamppeter: Ahh, I see there was some libusb issues.  That might be fixed with more recent upstream libusb in quantal?
[16:31] <infinity> tkamppeter: Also, you could just keep the argyll/libicc split?
[16:39] <tkamppeter> infinity, the problem of the build system is that as build dependency it also needs to get MIRed into main and the build system is not maintained upstream any more.
[16:41] <tkamppeter> infinity, I am now making a new Ghostscript package using its own libicc.
[16:42] <infinity> tkamppeter: Why not just keep the source split, like it was before?
[16:44] <tkamppeter> infinity, if the source split is still in place I could simply MIR libicc and seb128 made the impression for me that libicc is part of the argyll source package. If it is still split off, we simply MIR libicc.
[16:45] <infinity> tkamppeter: It's not split right now, but you did it once before...
[16:45] <infinity> Or, so I was led to believe by bug logs. :P
[16:46] <tkamppeter> infinity, was there ever reported a MIR for argyll or libicc? If yes, can you post the bug numbers here?
[16:47] <Sweetshark> infinity: oh great, gcc 4.7 crapped out on i386. the same build finished here locally (though on amd64) and in the ppa at https://launchpad.net/~libreoffice/+archive/libreoffice-prereleases/+build/3695349 so I would suggest to retry the build.
[16:47] <infinity> https://bugs.launchpad.net/ubuntu/+source/argyll/+bug/821883
[16:47] <infinity> https://bugs.launchpad.net/ubuntu/+source/libicc/+bug/824032
[16:47] <infinity> Sweetshark: You had the sources split before, and libicc had a valid MIR.
[16:48] <infinity> Sweetshark: Athough, libicc went back to universe after that MIR, perhaps because you never actually ended up linking to it?
[16:50] <seb128> tkamppeter, ^ those lines are for you I think
[16:50] <Sweetshark> huh, what? icc?
[16:50] <infinity> Err..
[16:50] <infinity> Sweetshark: My brain exploded.
[16:50] <infinity> tkamppeter: See above. :P
[16:50]  * Sweetshark gives infinity a hug and a cookie.
[16:51] <infinity> Sweetshark: The build failures were intentional, don't worry about it.
[16:51] <Sweetshark> infinity: ^^
[16:51] <tkamppeter> infinity, so we would need to re-split libicc and then link it from Ghostscript to complete the already existing MIR?
[16:51] <infinity> Sweetshark: I noticed that you'd targetted -proposed, and decided that was suboptimal. :P
[16:51] <infinity> tkamppeter: Something like that, yes.
[16:52] <tkamppeter> infinity, how is argyll and libiccc handled in Debian? Are they together or split?
[16:52] <Sweetshark> infinity: yes, I heard whispers about it being discussed on -release. anyway, yeah, it was what was there, sorry ;)
[16:53] <infinity> Sweetshark: My fault for not looking at the target.
[16:53] <tkamppeter> infinity, I do not want to have it jumping forth and back because of different parties in the two distros liking one or the other version more or loosing track on certain conditions like Ghostscript.
[16:53] <infinity> tkamppeter: I'm assuming together, since the current state in quantal looks like a straight sync.
[16:54] <infinity> tkamppeter: In oneiric and precise, we had your split version, then someone synced overit.
[16:55] <infinity> tkamppeter: You can blame RAOF, according to quantal-changes. :P
[16:55] <tkamppeter> infinity, currently, I like much more the version of the two being together as they come from the same source.
[16:56] <tkamppeter> infinity, I also do not want to have to work on the horrible build system of argyll.
[16:56] <infinity> tkamppeter: Well, I'm still curious about this "build system MIR" thing you mention?
[16:56] <infinity> tkamppeter: The only extra package argyll is trying to pull in is tiff3.
[16:56] <infinity> tkamppeter: Which you should certainly fix.
[16:56] <infinity> tkamppeter: But other than that, I'm not seeing the problem.
[16:56] <tkamppeter> infinity, and I also do not want to maintain a distro patch replacing the build system of argyll.
[16:57] <infinity> tkamppeter: Again, why do you think we need to do anything to/with the build system?
[16:57] <stgraber> infinity: at least on precise, it seems to be using jam which isn't in main
[16:58] <infinity> stgraber: Not in quantal.
[16:58] <infinity> The only issue I see in quantal is that it needs libtiff transitioning.
[16:58] <tkamppeter> infinity, main consumer of argyll is RAOF, as he maintains the bits for calibrating monitors.
[16:59] <infinity> tkamppeter: Well, let's reopen the old MIR, shall we?
[16:59] <infinity> I see that it now build-deps on libusb-dev
[16:59] <infinity> So, the bundled libusb thing seems to be fixed.
[16:59] <infinity> And it no longer uses jam.
[16:59] <infinity> Or no longer build-deps on it.
[16:59] <infinity> So, transition it for the new libtiff, and it's probably fine.
[17:02] <tkamppeter> infinity, it need also to get transitioned for the new libusb 1.0.x as libusb 0.1.x we are fading out as it is not maintained upstream any more.
[17:02] <tkamppeter> infinity, best is if RAOF does that. Can you add a comment to the reactivated bug and contact/CC/assign RAOF? Thanks.
[17:03] <infinity> tkamppeter: Well, libusb-dev is in main...
[17:03] <infinity> tkamppeter: Unless the whole world has transitioned, I don't see forcing others to.
[17:03] <infinity> OH DEAR GOD, I PASSED -v1.2.3 WITHOUT AN EPOCH AND DIDN'T NOTICE.
[17:03] <tkamppeter> infinity, so the libusb transition is not so urgent.
[17:04] <infinity> adconrad@chinstrap:~/libre $ wc -l libreoffice_3.6.0~rc4-0ubuntu2_source.changes
[17:04] <infinity> 4863 libreoffice_3.6.0~rc4-0ubuntu2_source.changes
[17:04]  * infinity weeps.
[17:05] <stgraber> infinity: well, at least we aren't missing any changelog entry ;)
[17:05] <infinity> I apologise in advance to everyone who reads -changes.
[17:06] <infinity> A 226k .changes is impressive, I'll give it that.
[17:08] <infinity> That's probably a sign that it's time for a keyboard break and some breakfast.
[17:12] <tkamppeter> infinity, can you update bug 821883? Thanks.
[17:12] <infinity> tkamppeter: I already reopened it.  Can give the current sources a once-over a bit later.
[17:13] <infinity> tkamppeter: But without even looking, the tiff transition needs to happen, so you might want to test-build that and make sure it doesn't need patching (or fix it if it does), while I look to make sure the rest is in order.
[17:33] <tkamppeter> infinity, are you core dev?
[17:33] <infinity> tkamppeter: Last time I checked.
[17:34] <barry> infinity: i guess you don't know about the automatic de-core-deving feature triggered on .changes > 200k?
[17:34] <tkamppeter> infinity, then you could sync qpdf from Debian (to 3.0.0 final), so that we can complete the qpdf MIR.
[17:34] <infinity> barry: *cough*
[17:35] <infinity> tkamppeter: In experimental?
[17:35] <infinity> Ahh, indeed.
[17:36] <infinity> tkamppeter: Done.
[17:36] <mdeslaur> barry: I think working 20 hours a day exempts infinity from that restriction :P
[17:37] <barry> mdeslaur: oh, right, i forgot about the multiplier.  don't tell infinity that he gets an extra 20*60*60 k headroom.
[17:38] <mdeslaur> hehe
[17:41] <tkamppeter> infinity, thanks.
[17:56] <tkamppeter> infinity, sorry, for having made you so much work, but the icclib dependency in ghostscript turned out to be a ghost.
[17:57] <infinity> tkamppeter: ?
[18:00] <tkamppeter> I did ldd on libgs.so and wondered why there is no libicc in the output. Then I asked the ghostscript upstream developers about how Ghostscript uses libicc and they told that it does not use it any more. I checked all the .c and .h files in Ghostscript's source code and none #includes the .h files of libicc. So the icclib directory in Ghostscript's original source code is a dead body.
[18:04] <tkamppeter> infinity, so I will upload a Ghostscript which simply drops the libicc-dev dependency.
[18:07] <tkamppeter> infinity, the Argyll MIR should be followed anyway as Argyll got more distro-friendly with the time. This should be done by RAOF as he is the main consumer of Argyll.
[18:07] <toabctl> pitti, is there any progress on porting d-feet to pygi?
[18:16] <infinity> tkamppeter: Well, if nothing in main needs it, there's no need for the MIR.  *shrug*
[18:16] <infinity> tkamppeter: But feel free to talk to RAOF and see if he wants to follow through for other reasons.
[18:21] <tkamppeter> infinity, new ghostscript uploaded.
[18:25] <tkamppeter> infinity, I have added a comment to bug 821883 now.
[18:49] <seb128> licensing questions
[18:49] <seb128> if a source as it's sources under GPL2+
[18:49] <seb128> with COPYING being GPL3
[18:50] <seb128> what should the debian/copyright contains?
[18:50] <seb128> src/*: GPL2+
[18:50] <seb128> or GPL3?
[18:53] <slangasek> I would say GPL2+
[18:54] <slangasek> an explicit copyright statement in the source is more authoritative than whatever license happens to be included
[18:56] <seb128> slangasek, thanks, I though that the COPYING was "dictating" the tarball license
[18:56] <seb128> so sources being 2+ and COPYING 3 the lot would be 3
[18:57] <slangasek> well, if in doubt I think it's best to get clarification from upstream
[18:57] <seb128> ok
[18:57] <slangasek> but there are plenty of cases where COPYING files are included that are just a copy of the GPL, and not everything in the tarball is GPL-licensed (or GPL-compatible)
[18:58] <slangasek> or cases where COPYING + COPYING.LIB are both present and nothing is LGPL licensed
[18:58] <seb128> right
[18:59] <seb128> well I'm not too concerned about that one, it's one of the tarballs of the ubuntu-online-account team, I was just wondering if debian/copyright should state GPL3 if that's what COPYING contains
[19:00] <seb128> kenvandine said he will get them to clarify that for the next update
[19:00] <slangasek> er... is Canonical upstream for this?
[19:00] <slangasek> because in *that* case, the correct license is probably GPLv3 :)
[19:01] <slangasek> (the default licensing policy for Canonical works)
[19:02] <seb128> slangasek, yeah, that's what he will get sorted for the next upload, I was just wondering if I should block the NEWing on it
[19:02] <slangasek> I wouldn't block
[19:03] <seb128> great, I was going to block, thanks for the replies ;-)
[19:03] <robbiew> slangasek: hey...did something weird just get uploaded in precise-proposed....I'm having issues with joining the canonical irc and my mail client started acting funny
[19:03] <seb128> doh
[19:03] <robbiew> I applied updates just now
[19:03] <seb128> was->wasn't
[19:03] <slangasek> robbiew: um... hmm
[19:03] <robbiew> I know my description of the issue sucks
[19:04] <slangasek> not sure we have a sane way to check for recent precise-proposed changes
[19:04] <robbiew> I think it's related to secure connections or something....
[19:04]  * robbiew digs
[19:04] <seb128> krb5 and openssl got accepted recently
[19:04] <seb128> looking at -changes
[19:04] <slangasek> krb5 was a server CVE; openssl is a more likely culprit
[19:04] <slangasek> right, https://lists.ubuntu.com/archives/precise-changes/2012-August/thread.html shows the recent changes
[19:05] <seb128> openssl (1.0.1-4ubuntu5.4) precise-proposed; urgency=low
[19:05] <seb128>   * debian/patches/lp973741.patch: Avoid segfault on legacy Intel CPUs
[19:05] <seb128>     by using correct cypher. (LP: #973741)
[19:05] <seb128>  
[19:05] <seb128> that was yesterday
[19:05] <seb128> robbiew, try downgrading that and see if that fixes it?
[19:05] <robbiew> seb128: ack
[19:06] <slangasek> robbiew: otherwise, /var/log/apt/history.log is the place to look to check which updates were applied on your system between "Working" and "Broken"
[19:06] <robbiew> cool
[19:06] <slangasek> but yeah, openssl seems likely
[19:06] <robbiew> thx
[19:23] <infinity> seb128 / slangasek: I'm going to drop that openssl SRU out of -proposed anyway, it's broken on !x86.
[19:23] <slangasek> okely dokely
[19:27] <seb128> should .pc Libs.private requirement be listed as depends of -dev binaries?
[19:27]  * micahg would think not
[19:27] <slangasek> IMHO no
[19:28] <seb128> ok, what I though but I was unsure, thanks
[19:28]  * micahg wonders what the point of listing it in the first place is (isn't the .pc file for other software to consume?)
[19:29] <kenvandine> micahg, yeah, i can't see why it is there at all
[19:29] <micahg> kenvandine: ah, Libs.private:  This line should list any private libraries in use. Private libraries are libraries which are not exposed through your library, but are needed in the case of static linking.
[19:30] <micahg> since we don't do static linking, it's not an issue
[19:30] <kenvandine> good point
[19:30] <kenvandine> perhaps
[19:33] <infinity> adam_g: Updated bug #973741 ... You might want to test with that slightly larger patchset (1.2->1.5) that I linked.
[19:33] <infinity> adam_g: And if you have access to ARM or PPC hardware, I recommend a quick spin there too.
[19:35] <slangasek> infinity, adam_g: which you should have access to via the porter machines if nothing else
[19:36] <adam_g> infinity: thanks, ill try that a try on non-x86 soon
[19:43] <infinity> Okay, really lunching now.
[19:59] <shadeslayer> hi, I'm trying to build my own kernel using make-kpkg, but I keep hitting this issue :
[19:59] <shadeslayer> dpkg-gencontrol: error: illegal package name 'linux-image-3.5.0-powersave-ARCH': character 'A' not allowed
[20:00] <shadeslayer> I believe ARCH is supposed to be replaced by my architechture .. but something seems to be going wrong
[20:01] <ScottK> shadeslayer: Maybe #ubuntu-kernel.
[20:01] <shadeslayer> alrighty
[20:14] <ogra_> hggdh, http://paste.ubuntu.com/1125837/
[20:24] <slangasek> is anyone else noticing severe problems with the bandwidth to bazaar.launchpad.net  && upload.ubuntu.com today?
[20:25] <lifeless> see #launchpad
[20:25] <lifeless> there was a PMTUd issue, not entirely debugged, but workarounds in place now.
[20:26] <slangasek> ok
[20:26] <slangasek> lifeless: as of when is the workaround in place?  Because upload.ubuntu.com just failed to take a 9k upload, 4 minutes ago
[20:27] <slangasek> (hung at 8k)
[20:27] <elmo> slangasek: as of about 2m ago
[20:27] <slangasek> ok :)
[20:38] <dobey> is there a way to force a re-import of a UDD branch from the source package in the archive?
[21:11] <adam_g> infinity: about to send a debdiff for a new openssl with that patch. do i use the same version of the package that was removed from -proposed (4ubuntu5.4), or bump that to 4ubuntu5.5?
[21:12] <slangasek> adam_g: bump
[21:12] <slangasek> once the package has been accepted, the version number can never be reused
[21:13] <slangasek> robbiew: did downgrading libssl fix your bug?
[21:13] <robbiew> slangasek: well...I think so...I also downgraded libssl1
[21:13] <slangasek> yeah, that's the one I mean :)
[21:14] <robbiew> oh..well then yes, I believe so
[21:14] <slangasek> ok
[21:15] <ScottK> adam_g: Was the previous accepted into -proposed or was it just in the queue.
[21:15] <slangasek> ScottK: it had been accepted
[21:16] <ScottK> adam_g: .5.
[21:16] <ScottK> slangasek: Thanks.
[21:16] <ScottK> And I guess I should have read further down in the backscroll ...
[21:16] <adam_g> thanks
[21:19] <ogra_> hggdh, http://paste.ubuntu.com/1125948/
[21:19] <adam_g> slangasek: in that case, the debdiff should compare 5.5 and 5.3 (released), or 5.5 and 5.4 (removed)?
[21:20] <slangasek> adam_g: 5.5 and 5.3
[21:28] <robbiew> slangasek: fwiw...I'm not sure if it was on my end or the pMTUd issues...i guess I could re-apply the new stuff and check
[21:29] <slangasek> if you still have the new stuff handy, yeah... it's gone from -proposed already :)
[21:29] <shadeslayer> hmm
[21:31] <shadeslayer> infinity: I'm not entirely sure, but seems like linux-headers-3.5.0-7 has a broken task as well, doesn't list kubuntu-desktop
[21:31] <shadeslayer> then again, I might be wrong
[22:47] <scientes> whats the reason to use deadline scheduler by default?