[00:01] <SpamapS> psusi: alright, hopefully having it there doesn't trigger some other weirdness ;)
[00:03] <SpamapS> psusi: so will we need mdmon in the installer then too?
[00:08] <SpamapS> according to mdmon's man page.. we'd need to also add jobs to start mdmon after initramfs startup to truly support it properly
[00:08] <SpamapS> but I suppose at least having the binary will allow users to handle their own business
[01:01] <psusi> SpamapS, Neil Brown seemed to indicate that mdadm starts it automatically
[01:11] <ogra_> slangasek, infinity, if one of you could take a look at compiz in the queue, that would be nice, i will do any fixes and the according compiz-plugins-main upload (it build deps on the compiz one) tomorrow ...
[01:12] <infinity> ogra_: I'll have a look.
[01:16] <infinity> yofel_: ...
[01:17] <infinity> yofel_: Those KDE 4.8.2a uploads are literally identical to the previous ones, except for the version in the changelog... (the upstream source didn't even change)
[01:23] <infinity> ogra_: || true is never a sane thing in a Makefile.
[01:24] <infinity> ogra_: That cmake copying stuff should be wrapped in ifeq/ifneq gles2_arches stuff, so it will still hard-fail if something goes wrong.
[01:25] <infinity> ogra_: Other than that (and the massive patch from Linaro that I won't even pretend to audit), it looks fine.
[01:26] <infinity> jelmer: You probably don't need to sync the same package three times. ;)
[01:26] <infinity> yofel_: Was 4.8.2a being identical to 4.8.2 intentional, or did you get the wrong orig tarballs?
[01:46] <slangasek> right, syncing three times is for hard disks
[01:48] <infinity> slangasek: Oh dang, if I'd thought about the fact that you were working on an apt upload, I would have tossed my own 1-line bugfix in too.
[01:48] <slangasek> we can reject that one and take a mulligan?
[01:49] <infinity> Or just build twice. :P
[01:50] <infinity> I'm preoccupied right now anyway, I'll upload my 1-liner on the weekend.
[01:50] <slangasek> ok
[01:50] <infinity> Well, I guess my "weekend" is now.
[01:50] <infinity> But.  Later on the weekend.
[01:51] <infinity> 700k diff?  I guess that's translation fallout?
[01:51]  * infinity looks.
[01:51] <slangasek> yeah
[02:11] <infinity> yofel_: ScottK explained the PPA version oops to me, un-rejecting the upload of yours that I bounced.
[02:23]  * infinity wonders idly what would happen if he let his dom0 use half its ram for zram and then let his domUs overcommit...
[02:25] <ScottK> yofel_: It would have been nice to have an actual debian/changelog entry that explained what you were doing and why to the poor release team reviewer.
[02:25] <infinity> I accept payment in tiny violins.
[08:05] <raffa50> hello i've done mime type!
[08:05] <raffa50> i only have a problem... i can't see file icon
[09:49] <raffa50> hello
[09:49] <raffa50> i added my mime type
[09:49] <raffa50> when i double click on the file my apps open ups
[09:49] <raffa50> i only can't see the file icon
[09:49] <raffa50> how can i do?
[11:18] <geser> the Ubuntu Mobile Edition is dead and we can drop those changes from packages again, right? (like building with libhildon)
[11:32] <raffa50> hello
[11:32] <raffa50> i've added my mime type and mi apps open ups and load the file
[11:32] <raffa50> but i can't see the file icon
[11:32] <raffa50> how can i do?
[13:20] <ogasawara> @pilot in
[15:05] <Amoz> ogasawara, hi, since you're on duty I can ask you to take a look at patches, right?
[15:07] <ogasawara> Amoz: I can, but I'm afraid I can really only be of service if it's against the kernel.
[15:08] <Amoz> ogasawara, oh, I see. Even if it's just a simple upstream bug release?
[15:09] <Amoz> it's a bugfix release for pidgin
[15:10] <ogasawara> Amoz: I've only got upload rights for the kernel, but am happy to review and try and get you in touch with the right person to help get the fix applied and uploaded
[15:11] <Amoz> ogasawara, I've already subscribed ubuntu-sponsors to the bug, maybe I should just wait for them to review it?
[15:11] <Amoz> or is there anything else I can do to make it easier for them?
[15:14] <Amoz> the bug is #964210
[15:14] <ogasawara> bug 964210
[15:19] <ogasawara> Amoz: I think you've done everything needed on your part
[15:19] <Amoz> thanks ogasawara
[15:20] <ogasawara> kenvandine: ^^ is 964210 you might be able to assist with?  Looks like Amoz already has a patch there and tested
[15:22] <kenvandine> ogasawara, Amoz: i'll look at it
[15:24] <Amoz> ogasawara, while you're here, is there any beginner kernel stuff one might be able to work with?
[15:24] <ogasawara> Amoz: definitely!  what are you interested in?
[15:25] <Amoz> well, everything?
[15:25] <ogasawara> Amoz: I usually suggest to being with some simple triage work to get a feel for the workflow, then proceed from there with patches etc.
[15:25] <ogasawara> s/being/begin/
[15:26] <ogasawara> Amoz: come jump in #ubuntu-kernel and I can get you in touch with jsalisbury to get you going on triage if you're interested
[15:27] <jsalisbury> Amoz, o/
[15:27] <ogasawara> jsalisbury: oi, you're here :) and there :)
[15:43] <roaksoax> mgw:/win 13
[15:43] <roaksoax> arghh
[15:43] <roaksoax> :)
[15:53] <kenvandine> ogasawara, Amoz: pidgin sponsored
[15:55] <Amoz> kenvandine, awesome, thanks
[15:55] <Amoz> everything looked good?
[15:56] <kenvandine> Amoz, yes
[15:56] <Amoz> \o/
[16:19] <raffa50> hello
[16:20] <raffa50> i've added my mime type, but i can't see the file icon for my extension how can i do?
[17:46] <Amoz> kenvandine, about the pidgin patch, is it supposed to appear somewhere? and should the bug be set to "fix commited" or something?
[18:05] <EtienneG> guys, is it too late to request a sync for a package in universe?
[18:08] <Laney> not if it's bug fix
[18:10] <EtienneG> actually, someting is seriously fishy with package nsscache
[18:10] <EtienneG> that's the one I want a sync for, but the version currently in precise is older than the one in lucid
[18:10] <EtienneG> weird
[18:12] <EtienneG> or not, actually.  turns out it was not in lucid
[18:12] <EtienneG> but the Debian changelog has a lucid entry
[18:14] <ScottK> Probably from a third party repo.
[18:23] <yofel> infinity: sorry for the uploads, I'll make the changelog more informative next time.
[18:43] <kenvandine> Amoz, it is in the unapproved queue right now, when the release team approves it the bug will get marked fix released
[18:50] <Amoz> kenvandine, I see, thank you
[18:51] <kenvandine> Amoz, np
[20:01] <janimo> ogra_, the compiz GL or GLES backend is selectable at compile time only right?
[20:02] <ogra_> janimo, i think so
[20:03] <ogra_> janimo, though i think i saw a mail from alf that he has a patch that makes both (GL/GLES) alongside on an intel box
[20:03] <ogra_> that should make it runtime selectable
[20:04] <janimo> ogra_, yes, that would be useful, as some Intel boxes may have PVR based  GLES-only GPUs
[20:05] <ogra_> right
[21:08] <ogasawara> @pilot out
[21:29] <mvdk> I've gotten source package jbigkit accepted by Debian - per https://bugs.launchpad.net/ubuntu/+source/splix/+bug/918435 , I figure it's best to have a shared version of it instead of packages deciding that they'll import the source themselves.  Is there any way to get it accepted into precise?
[21:32] <maxb> My guess is that it is a bit late in the cycle to start removing statically linked versions of things that are working fine
[21:33] <jibel_> slangasek, there is a problem with latest flashplugin. bug 975426
[21:33] <slangasek> jibel_: thanks, looking
[21:35] <slangasek> jibel_: got it, I think; gonna reproduce in a chroot first, but I should have the fix uploaded shortly
[21:36] <jibel_> slangasek, thanks
[21:43] <slangasek> jibel_: confirmed, and fix uploaded.  Sorry about that; the irony is that I made these changes to make the install more robust, but I only ever tested upgrades, so didn't notice the bug in the existing code :/
[21:48] <mvdk> Is there anyone here who might be able to take jbigkit from Debian into Ubuntu?  It adds support for printers for SPLiX, and it was only recently accepted because the patents have finally expired (on Wednesday).
[21:53] <slangasek> mvdk: maxb's comments above were directed at you
[21:54] <mvdk> I don't see maxb's comments
[21:54] <slangasek> i.e., it's probably not worth taking that package for precise, because if we *do* take it, we probably *won't* take the changes to split out any statically-linked versions from other packages at this stage
[21:54] <slangasek> mvdk: ah, it was shortly before you disconnected :) 14:32 < maxb> My guess is that it is a bit late in the cycle to start removing statically linked versions of things that are working fine
[21:56] <mvdk> Is that really true? It seems to me that it's a somewhat serious breach of policy, to include statically linked dependencies in a package...
[21:57] <slangasek> it's certainly not preferred
[21:57] <slangasek> but any instances of this particular linkage have been there for a while
[21:57] <mvdk> Not without a bug being raised against it for a while
[21:57] <slangasek> it's mainly against policy because it's a pain for security updates... but I don't think any of the affected packages are likely to get security attention anyway
[21:57] <mvdk> This is probably true
[21:58] <maxb> In essence... is there any motivation to need to rush this into precise rather than doing the work for q-series?
[21:58] <mvdk> Well, jbig is also a minor support thing for libtiff as well, and adds support for JBIG faxes to hylafax
[21:59]  * maxb dons devil's advocate hat and quietly chants "feature freeze" :-)
[21:59] <slangasek> we're certainly not going to enable it in libtiff at this stage of the cycle
[22:00] <mvdk> Those things are probably minor motivations; I rather figured that in effect, libjbig is already in Precise, and not much pain is exacted by splitting it out
[22:01] <maxb> Whilst that's probably true, it seems there's also not much benefit to be realized by squeezing it into precise?