[00:00] <slangasek> stgraber: do you think this is important enough to have udev Breaks: the versions of the packages without 'or container'?  Since each of these are unlikely to usefully run in a container, I'm not convinced it's worth it
[00:00] <slangasek> (and it's higher risk wrt upgrades)
[00:01] <stgraber> slangasek: no, it's only really a problem when the container starts/restarts not a runtime problem, so just pushing them all at the same time so that they all are updated roughly at the same time should be enough
[01:15] <slangasek> apw: have confirmed this grub patch DTRT; though on my radeon test machine, I still get garbled fb after handoff
[01:27] <infinity> No command 'vim' found, did you mean:
[01:27] <infinity>  Command 'vmm' from package 'vmware-manager' (multiverse)
[01:27] <infinity>  Command 'zim' from package 'zim' (universe)
[01:27] <infinity> ...
[01:28] <infinity> You'd think it would suggest, I dunno, 'vim' from package 'vim'?
[01:28] <infinity> Oh, but it's an alternative. :/
[01:28] <infinity> Annoying.
[01:34] <nigelb> heh
[01:35] <sladen> infinity: launchpad.net/ubuntu/+source/command-not-found/+filebug?field.title=command-not-found+does+not+suggest+vim+because+it+is+an+alternative
[01:39] <nigelb> so much troll on the fedora for arm lwn article.
[01:39] <nigelb> well, I was reading the comments. so I am to be blamed :)
[01:41] <ajmitch> nigelb: I hope you're not trolling there as well
[01:41] <nigelb> ajmitch: er, no. I only made the mistake of reading the comments
[01:41] <ajmitch> sure...
[05:14] <ScottK> jelmer: Are you planning on an FFe for dulwich 0.8.5 so bzr-git can build?
[05:52] <smoser> kenvandine, http://paste.ubuntu.com/915581/
[05:52] <smoser> it seems you inadvertantly regressed the fix i put in for bug 762167
[06:39] <Adri2000> hmm, has the archive gpg key really not changed since 2004?
[06:42] <Adri2000> debian renews its key regularly and now has a 4096R one, while we still have a 1024D it seems. is that something that has already been discussed somewhere?
[06:48] <infinity> Adri2000: It's been discussed, yeah.
[06:50] <Adri2000> infinity: and? :)
[07:02] <dholbach> good morning
[07:03] <infinity> Adri2000: We know we need to rev to a new key at some point and test that our migration is sane, etc.  We don't have a specific timetable for when.
[07:07] <smb> @crashpilot in
[07:08] <udevbot> Error: "crashpilot" is not a valid command.
[07:08] <smb> Sadly the truth does not work... :-P
[07:08] <smb> @pilot in
[07:08] <Adri2000> infinity: ok
[07:23] <apw> slangasek, see your branch.  not sure this does quite the same thing.  as if i am at the boot prompt and i edit the gru
[07:24] <apw> slangasek, grub entry and switch the gfxpayload value i won't influence the value of vt_handoff -- of course thats no worse than now where one has to drop it from both places to be sure anyhow
[07:59] <tumbleweed> bdrung: done
[08:43] <cjwatson> slangasek: the debian-cd bit is public; https://code.launchpad.net/~ubuntu-cdimage/debian-cd/ubuntu
[08:44] <cjwatson> slangasek: not that you'd want to use it for self-builds - easier to use lb config --binary-images iso-hybrid or similar
[08:46] <cjwatson> apw: I don't think it's necessary to solve the case of editing it by hand at the boot prompt
[08:47] <apw> cjwatson, indeed, though inspired by his patch i think i have a nice clean fix which does
[08:48] <cjwatson> I'll have a look when y'all settle down :)
[08:48] <apw> cjwatson, should have a branch shortly for perusal :)  i hate hate hate quilt
[08:51] <cjwatson> oh believe me it's better than what we were using beforehand
[08:52] <cjwatson> I switched grub2 to quilt because it made it about three times faster to refresh patches against new upstream versions
[08:52] <apw> cjwatson, i don't doubt it :)  i still _always_ use it wrong and eat my tree
[08:52] <cjwatson> but honestly if you're going to be spending time fighting with it, I'd rather you just attached a bare patch and let me worry about integrating it
[08:52] <cjwatson> better use of time all round
[08:53] <apw> cjwatson, well its also good practice :)  if i fail in half an hour i'll send it to you :)
[08:59] <nailora> bug #955848 -- can one of you make it public if possible? thanks!
[09:00] <cjwatson> nailora: is this a bug you're subscribed to, or that you reported?
[09:00] <cjwatson> nailora: if not, please give reasons
[09:00] <cjwatson> nailora: if so, you can just make it public yourself
[09:06] <nailora> i am sorting simple-scan bugs at a the moment. mostly those of the upstream launchpad project, but as most bugs are reported via ubuntu, i look through those as well. however some of them are private. i get to know about them if another public bug is marked as duplicate of the private bug. i suspect there are quite some more bugs i do not even know about.
[09:07] <nailora> i do not have any special rights with respect to the ubuntu project in launchpad.
[09:08] <cjwatson> nailora: I'm not sure I'm prepared to unprivate a simple-scan bug you didn't report, because I have no way to know whether e.g. it might be reverse-engineerable into bits of a private document somebody was scanning
[09:08] <cjwatson> that's the kind of reason why crash reports are private, because it's easy for bits of a dead process to contain confidential information
[09:08] <cjwatson> somebody who's a specialist in simple-scan can probably sort it out, but I don't think random developers can
[09:10] <cjwatson> nailora: if you join ubuntu-bugcontrol (https://wiki.ubuntu.com/UbuntuBugControl) then you can see crash bugs
[09:12] <nailora> i understand that. but in the past (public) reports against simple-scan in ubuntu have been left without reponse for years (!), and i suspect this is even more true for private bug reports.
[09:13] <cjwatson> ok, you're certainly welcome to sign up for ubuntu-bugcontrol and DIY, I just don't feel comfortable doing it for you in this case
[09:13] <apw> cjwatson, ok in http://people.canonical.com/~apw/lp942846-grub2-precise/ are two files, 10_linux which is the 'finished' applied version, and a debdiff which in theory at least applies to make the same
[09:15] <apw> cjwatson, and if i picked the right base, this is it applied: lp:~apw/ubuntu/precise/grub2/lp942846
[09:17] <cjwatson> the change to ubuntu_recovery_nomodeset.patch looks wrong, but I can clean that up
[09:17] <apw> cjwatson, oh what did i do wrong there ...
[09:18] <cjwatson> looks like you did quilt refresh after a previous version of the change, and then went back and cleaned up but didn't quilt refresh your way up the stack
[09:18] <cjwatson> lp:~apw/ubuntu/precise/grub2/lp942846 looks like something entirely different
[09:18] <cjwatson> the top change is "grep refuses to process files which are also its stdout channel
[09:18] <cjwatson> which prevents the password check from working and emits an ugly error.
[09:18] <cjwatson> (LP: #911225)"
[09:18] <cjwatson> pushed the wrong branch?
[09:19] <apw> cjwatson, that is the previous commit, and i did push, then commit and push again, so i think that is LP lag ... grrr
[09:19] <lag> apw always blames lag :(
[09:20] <cjwatson> normally if it's LP lag there's a message saying that new versions will be available shortly
[09:20] <cjwatson> in any case why would the base be that revision of yours?  that was ages ago
[09:20]  * lag changes his name to lp_is_working_perfectly
[09:21] <apw> cjwatson, i have lost the plot entirely somewhere ... bzr is doing something i cannot fathom
[09:21] <cjwatson> oh, there we go, there's a message now
[09:21] <bdrung> tumbleweed: thanks. can you upload it as 0.8.2 or should i do that?
[09:21] <apw> cjwatson, i rm -rf'd a grub2/precise directory then branched a new one, and pushed to that name above, when i push it pushes to some other saved place, where it gets that i have no idea
[09:21] <cjwatson> apw: nope, base for this is completely wrong
[09:22] <cjwatson> not that that means I couldn't merge, but I think it'd be easier to go off the debdiff perhaps
[09:22] <apw> bah i am a lost cause
[09:22] <cjwatson> you can see in https://code.launchpad.net/~apw/ubuntu/precise/grub2/lp942846
[09:22] <cjwatson> or by 'bzr log' locally
[09:22] <apw> bzr branch lp:ubuntu/precise/grub2 was in theory waht i used to get it
[09:23] <cjwatson> ah, er, yeah, don't do that
[09:23] <cjwatson> see Vcs-Bzr in 'apt-cache showsrc grub2' for the real branch
[09:23] <cjwatson> lp:~ubuntu-core-dev/ubuntu/precise/grub2/precise
[09:23] <cjwatson> I think I was having trouble with the importer
[09:24] <cjwatson> then again, this branch is not based on lp:ubuntu/precise/grub2 either, just based on what the log says
[09:25] <cjwatson> no idea what you did :)
[09:25]  * apw cries
[09:25] <infinity> Poor apw.
[09:25] <cjwatson> I'm happy to just work off the debdiff if you want
[09:25] <infinity> Need me to import grub into git for you, so you can figure it out? ;)
[09:25] <cjwatson> nooooo
[09:25] <apw> cjwatson, that might be easier :)
[09:26] <nailora> i will consider joining ubuntu-bugcontrol. i am unhappy with the situation because 99% percent of private bugs with simple-scan are mere cries for help from clueless users switching from windows suffering from crappy drivers. no bug reports should be created and certainly no private ones... nobody will look at the trace and the best thing for everyone is a timely "let me google that for you" or "sorry, we cant change
[09:26] <cjwatson> apw: ok, let's see
[09:27] <nailora> i understand that the situation is different for bugs where some engineering is to be done. but this is more first level support where apport made it to easy to file a bug report.
[09:32] <tumbleweed> bdrung: sure, will upload
[09:33] <raffa50> hello
[09:33] <raffa50> i'm triying to add my mime type to ubuntu
[09:34] <raffa50> i'm pacaging the .deb for my app
[09:34] <raffa50> where i shoud insert xdg-mime i/src/sly.xml ?
[09:34] <raffa50> in rules ? where?
[09:34] <cjwatson> nailora: the crash reporting system is being reengineered to make these kinds of things reports in a separate crash reporting system that can be looked at statistically, rather than bug reports
[09:35] <directhex> raffa50, man dh_installmime
[09:35] <cjwatson> we don't have the resources to look at every crash bug individually, and aren't going to have, so it does need a different presentation
[09:36] <cjwatson> the business of reporting crashes as bugs straight off was only ever intended to be temporary
[09:36] <cjwatson> https://blueprints.launchpad.net/ubuntu/+spec/foundations-p-crash-database
[09:39] <smb> @pilot out
[09:40] <nailora> cjwatson: that might improve the situation
[09:40] <raffa50> man dh_installmime ????????? where is?
[09:41] <cjwatson> raffa50: the debhelper package; and please only use one question mark at a time, we don't need nine in a row :-)
[09:43] <raffa50> can't understand
[09:43] <apw> cjwatson, i had better re-test this applied version after all these fubars ...  if you push up your applied version i can make sure its right
[09:43] <raffa50> i extracted .dev
[09:43] <raffa50> deb
[09:43] <raffa50> and i opened ruler file
[09:43] <raffa50> rules
[09:43] <raffa50> in debian foder
[09:44] <cjwatson> apw: oh, my comment about ubuntu_recovery_modeset.patch was wrong, sorry, I misread the two levels of patch
[09:44] <raffa50> now where i must place xdg-mime /src/sly.xml for istalliong
[09:44] <raffa50> my mine
[09:45] <directhex> raffa50, "man" is the command to view a manual page. dh_installmime is the command to set up mime types in packages. so <directhex> raffa50, man dh_installmime
[09:45] <directhex> i.e. if you're manually writing xdg-mime anywhere you're doing things terribly terribly wrong
[09:45] <cjwatson> mm, xdg-mime uses a different file format from dh_installmime
[09:46] <cjwatson> no package on my system appears to use xdg-mime at all
[09:46] <directhex> cjwatson, glorious
[09:46] <raffa50> i asked aroud
[09:46] <raffa50> they sayd to add mime in that way
[09:46] <apw> cjwatson, heh well thats something
[09:46] <directhex> sigh
[09:47] <directhex> raffa50, have you read that manual page yet?
[09:47] <raffa50> yes
[09:47] <raffa50> but now i'm confused
[09:47] <raffa50> i wrote an xml
[09:48] <raffa50> and now what i must do? (sorry i'm italian and only 18)
[09:49] <directhex> http://wiki.debian.org/MimeTypesSupport
[09:49] <directhex> i don't have time for the clearly required level of hand holding. you may have better luck in #ubuntu-motu
[09:50] <cjwatson> directhex: oh, I see, these XML files live in .sharedmimeinfo
[09:51] <cjwatson> that makes a degree of sense, at least
[09:51] <cjwatson> raffa50: so put your XML file in debian/YOURPACKAGENAME.sharedmimeinfo, replacing YOURPACKAGENAME with ... your package name
[09:51] <raffa50> ah
[09:51] <raffa50> and then?
[09:52] <cjwatson> raffa50: if you're using sensible modern packaging with dh, then that's all you need
[09:52] <raffa50> ?
[09:52] <cjwatson> raffa50: otherwise, you need to call dh_installmime in your binary-arch or binary-indep target in debian/rules as appropriate (there are probably a bunch of other dh_installblah things there already)
[09:53] <raffa50> i did as you sayd
[09:53] <raffa50> i placed
[09:53] <raffa50> my xml
[09:53] <raffa50> in debian
[09:53] <raffa50> now it's name is sly.sharedmimeinfo
[09:54] <raffa50> i need to do other things?
[09:54] <cjwatson> post debian/rules to http://paste.ubuntu.com/
[09:55] <raffa50> http://paste.ubuntu.com/915787/
[09:57] <cjwatson> raffa50: add 'dh_installmime -i' after the line that says 'dh_installmenu'.  The line with 'dh_installmime -i' on it *must* start with a real tab character, just like the other lines around it.
[10:02] <raffa50> ok
[10:02] <raffa50> ki try
[10:04] <raffa50> dpkg-buildpackage -S -sa -kE05C9204 is the command to build right??
[10:05] <raffa50> istalled
[10:05] <raffa50> don't work
[10:07] <raffa50> http://paste.ubuntu.com/915799/
[10:07] <raffa50> first row is <?xml version="1.0" encoding="utf-8"?>
[10:08] <cjwatson> raffa50: that builds a source package, not a binary package ...
[10:08] <cjwatson> 'debuild -uc -us' builds binary packages
[10:08] <raffa50> ok
[10:09] <raffa50> i'm noob, but my project is big: Sly IDE for beginners
[10:11] <raffa50> now it builded .deb'
[10:11] <raffa50> ? i try again
[10:13] <raffa50> nothing again
[10:13] <raffa50> is my xml correct? http://paste.ubuntu.com/915799/
[10:16] <raffa50> in the first row i missed ? because pastebin doesn't allow it
[10:20] <raffa50> there is anyone??? yhuuhuuuuu?
[10:25] <apw> cjwatson, ahh thanks, will re-test it after all that dammage
[10:26] <directhex> raffa50, run "dpkg -I yourpackage.deb postinst"
[10:26] <directhex> and pastebin the result
[10:27] <cjwatson> apw: looks like it should be fine; I have one or two other things I want to sort out, so either feel free to test from the branch, or I'll go through it once I'm ready
[10:28] <apw> cjwatson, i will test this bit from the branch indeed
[10:28] <cjwatson> apw: or I can build binaries for you if you're still having trouble getting the right branch
[10:28] <apw> cjwatson, nope incompentance over, i see your clean tip with the extra change
[10:28] <cjwatson> 'k, cool
[10:29] <apw> cjwatson, glad at least the debdiff was right even if i was based in space
[10:42] <bdrung> tumbleweed: fyi: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667614
[10:43] <tumbleweed> bdrung: yeah, I saw some of the IRC discussion on that
[10:45] <bdrung> tumbleweed: you may come up with a patch (you are a better perl hacker than me)
[10:46] <tumbleweed> heh
[11:08] <raffa50> http://paste.ubuntu.com/915850/
[11:19] <apw> cjwatson, ok in my testing that seems to behave as i would expect, this should give those psb people something to switch which will work
[11:26] <cjwatson> apw: great - I'll upload that later today.  I'll also look at making this automatic in the encrypted-/usr case
[11:26] <apw> cjwatson, what was it thats on / that breaks graphics?  given all of /boot is not encrypted ?
[11:27] <apw> cjwatson, as slangasek was saying it worked fine for him which was confusing
[11:27] <cjwatson> apw: /usr/share/grub/unicode.pf2 is big and isn't copied to /boot/
[11:28] <cjwatson> see 'if loadfont /usr/share/grub/unicode.pf2' in grub.cfg
[11:28] <apw> yep ... makes sense.  so yes in that case off sounds good by default
[11:28] <apw> cjwatson, and i need to get whoever has the psb stuff to get their ids added to the blacklist
[11:29] <cjwatson> it is possible to manually copy unicode.pf2 to /boot/grub/, and maybe slangasek had done that
[11:38] <raffa50> help please
[11:38] <raffa50> http://paste.ubuntu.com/915850/
[11:45] <raffa50> no way
[11:54] <raffa50> help me please
[11:55] <raffa50> there isn't an example?
[12:02]  * ogra_ wonders if anyone knows a more elegant way to apply arch specific quilt patches to a package than what i do in http://paste.ubuntu.com/915905/
[12:09] <cjwatson> ogra_: why can't it be ifdeffed and thus just applied for all architectures?
[12:09] <ogra_> cjwatson, because it changes stuff that cant easily be ifdeffed ... (long story) ... the patch bneeds to be arch specific in this caswe
[12:09] <ogra_> *case
[12:10] <ogra_> (it changes the API of some core functions afaik, i'm only the patch delivery guy here)
[12:11] <ogra_> cjwatson, do you know a more elegant way than mangling the series file ?
[12:14] <cjwatson> ogra_: I don't
[12:14] <ogra_> k
[12:15] <ogra_> i was hoping for some quilt magic i dont know about :(
[12:16] <cjwatson> although the approach in that pastebin is bad, because it will repeatedly append the arch-specific entries on repeated builds
[12:16] <ogra_> right
[12:16] <cjwatson> ogra_: a slightly neater approach might be to have a separate directory for the arch-specific patches, and call quilt twice setting QUILT_PATCHES the second time
[12:17] <cjwatson> ogra_: or, actually, you don't need a separate directory; you could set QUILT_SERIES=series.$(ARCH)
[12:18] <cjwatson> you ought to override dh_quilt_unpatch as well
[12:18] <raffa50> cjwatson: help me don't work
[12:18] <cjwatson> raffa50: sorry, I can't
[12:18] <raffa50> :(
[12:18] <cjwatson> raffa50: I have too many other things to do and you aren't providing any useful information about how it doesn't work
[12:18] <raffa50> no .deb examples
[12:18] <ogra_> cjwatson, yeah, thats just for testing the functionality yet
[12:18] <raffa50> ?
[12:18] <ogra_> indeed upatch will get aqn override too
[12:18] <ogra_> *an
[12:18] <ogra_> *unpatch *sigh*
[12:19]  * ogra_ goes to look at QUILT_SERIES ... didnt notice that one yet
[12:20] <raffa50> what shoud i do now?
[12:21] <cjwatson> perhaps you should write up your question in detail and post it somewhere else, such as askubuntu.com or some appropriate mailing list
[12:21] <cjwatson> somewhere that's more focused on application developers
[12:21] <raffa50> i asked on italian forum
[12:36] <cjwatson> apw: actually, I'm going to skip any changes to the 'if loadfont' path - experimentation suggests that this may be hardware-specific, i.e. it will at least sometimes manage to enable gfxterm anyway even if gfxmode hasn't been explicitly set beforehand
[12:36] <raffa50> oki
[12:36] <raffa50> i asked
[12:36] <cjwatson> apw: I think the only sensible approach long-term is to write a new command that exits zero iff a video mode is active, but I don't want to attempt that for precise really
[12:37] <apw> cjwatson, yeah that would be nice if we could do it, but as you say that is a Q job
[12:37] <apw> cjwatson, could you gate it on the existance of that font file for the time being?
[12:37] <cjwatson> no, because that's actually not correct
[12:37] <cjwatson> I did some tests here and got a video mode even without loading a font or setting gfxmode
[12:38] <apw> gurgle
[12:38] <cjwatson> just with a rescue CD image produced using grub-mkrescue, in kvm
[12:38] <cjwatson> so something else is going on, and I don't want to make a random change without understanding what :)
[12:39]  * cjwatson uploads what he has so far
[12:39] <apw> cjwatson, fair indeed.  well i guess for now we can just leave things as they are perhaps?  and where its known to explode with a specific card we just get those in the blacklist, and if its else they have to do it by hand
[12:40] <apw> at least now they can use the /etc/default/grub variables to turn it off properly
[12:40] <raffa50> where can i find a .deb example that adds mime?
[12:42] <cjwatson> raffa50: the following packages on my system appear to register MIME entries using the system we recommended: apport brasero-common capplets-data fontforge gnome-keyring gramps libreoffice-common nautilus-data shared-mime-info software-properties-gtk tomboy vinagre
[12:42] <cjwatson> raffa50: so you can 'apt-get source' any of those and inspect them
[12:43] <cjwatson> apw: provisionally that seems reasonable; I guess we'll see
[12:49] <raffa50> thanks
[12:50] <raffa50> when i done
[12:50] <raffa50> apt-get source
[12:50] <raffa50> tomboy
[12:51] <raffa50> what foder i should open?
[12:51] <raffa50> ls
[12:51] <raffa50> found
[12:55] <ogra_> hmpf, so it seems compiz does completely ignore the patch target during build, it inly applies them on unpack :/
[12:55] <ogra_> *only
[13:00] <ogra_> (which means that debian/rules doesnt apply indeed ... sigh)
[13:04] <kenvandine> smoser, sorry i should have noticed that
[13:04] <kenvandine> smoser, i'll fix it and merge it into the packaging branch
[13:16] <raffa50> i made some thing
[13:16] <raffa50> now it says
[13:16] <raffa50> Tipo application/x-sly
[13:17] <raffa50> impossible to find application for opening type application/x-sly
[13:24] <mhall119> dholbach: ping
[13:24] <dholbach> mhall119, pong
[13:25] <mhall119> dholbach: https://bugs.launchpad.net/ubuntu/+source/thunderbird/+bug/973394 contains a patch to add Keywords to thunderbird.desktop
[13:25] <mhall119> specifically so that a Dash search for "Email" will contain Thunderbird
[13:25] <mhall119> it's recently been highlighted as something needed for 12.04 in http://www.linuxuser.co.uk/opinion/5-problems-with-ubuntu-12-04-part-1-unity-dash-usability-issues/
[13:25] <dholbach> nice
[13:26] <dholbach> chrisccoulson, ^ did you see this one?
[13:26] <dholbach> mhall119, it seems to be milestoned for precise
[13:26] <chrisccoulson> dholbach, yeah, it's already fixed in the nightly builds
[13:26] <mhall119> chrisccoulson: awesome, thanks!
[14:02] <ogra_> sigh, i wonder if its not easier to just ignore quilt and just use patch conditionally
[14:07] <hallyn> tjaalton: ok i can't personally list any improvements with the new qxl driver so I can't recommend pushing it (if you haven't already) unless Munzir chimes in
[14:07] <hallyn> tjaalton: apparently spice updates in debian are slow in coming because of fights over what to do with celt
[14:08] <hallyn> might have to do something in 12.10 (like do our own updates)
[14:13] <ogra_> seems if i use quilt here, it still uses the .pc directory which messes up all my overrides
[14:15] <Laney> you probably can't do stuff like that with 3.0 (quilt), at least not nicely
[14:15] <ogra_> yeah, just finding that out
[14:16] <ogra_> i guess i'll just go with a simple "patch -p0 <debian/patches/my_extra_patch.patch" in debian/rules or some such
[14:16] <Laney> make sure to reverse it in clean too
[14:17] <ogra_> indeed
[14:18] <ogra_> intrestingly not even the suggestion from cjwatson above to just set the QUILT_ vars differently seem to help ... seems the .pc metadata is set in stone at this point
[14:22] <jml> :(
[14:23] <jml> the phsical 't' ke on m keboard (letter between 'x' and 'z' in dvorak) is being mapped to the Hiragana-Katanana ke
[14:23] <Laney> there might be $QUILT_PC
[14:25] <ogra_> oh, wait ! it might help if the package actually used dh --with quilt $@ instead of just dh $@
[14:25]  * ogra_ slaps forehead
[14:29] <tjaalton> hallyn: that's ok, let's keep what we have now :)
[14:29] <tjaalton> it's very simple to backport if someone needs it
[14:29] <hallyn> ack that :)
[14:35] <smoser> slangasek, SpamapS bug 974284 raised in openstack-dev
[14:55] <SpamapS> smoser: interesting
[14:55] <smoser> the power fail scenario does seem valid.
[15:07] <Adri2000> in a default amd64 precise install, can I disable dpkg's "foreign-archicture i386" without any problem? or is it going to break things (I'm thinking of stuff like flash)?
[15:07] <Adri2000> or do I need to add i386 to my local mirror? :s
[15:08] <cjwatson> it'd break flash, yes; but you can use "deb [arch=amd64] http://mirror/ubuntu precise main" or similar if you need to have sources.list lines with non-default architecture sets
[15:15] <Adri2000> cjwatson: after testing looks like flash is ok, but stuff like acroread, needing ia32-libs-multiarch and nspluginviewer aren't...
[15:16] <Adri2000> well I guess I'll have to choose: proprietary stuff, or more hard disk for my mirror :)
[15:16] <cjwatson> I gave you an option that didn't involve changing your mirror
[15:16] <cjwatson> assuming you don't mind downloading a small amount of stuff directly from the primary archive
[15:16] <Adri2000> I tried, but it has the same effect as changing dpkg conf: ia32-libs-multiarch and nspluginviewer are still unavailable
[15:17] <Adri2000> yeah, I'd have to keep archive.ubuntu.com in sources.list
[15:17] <cjwatson> yes, you would
[15:18] <Adri2000> I see. that won't work for my specific case (should not go directly to outside repositories), but good to know anyway
[15:20] <slangasek> cjwatson: oh hah, did I manually copy unicode.pf2?  That's possible, I remember something along those lines :/  but I thought grub itself had code to do that copy when needed
[15:21] <cjwatson> maybe we did once and took it out 'cos it was giant
[15:21] <cjwatson> I forget :)
[15:22] <slangasek> apw: so keying off of gfxpayload directly, then?  That makes sense to me
[15:22] <cjwatson> anyway, I think we've since established that there are other ways you might get a graphical mode
[15:22] <slangasek> ok
[15:30] <apw> slangasek, yeah that the hope.  and if you change gfxmode $foo to gfxmode text everything naturally follows
[15:32] <ogra_> slangasek, wrt the compiz patches, the prob with them is that all i can get is a diff between two bzr branches ... sadly the package has additional quilt patches in debia/patches that touch the same files in some areas so its not just apply and go, i'm trying to work out a better plan with linaro to go forward with that atm
[16:28] <mpt> ev, reported bug 974428
[16:29] <ev> cheers
[16:42] <smoser> slangasek, i'd really appreciate your brain power on https://bugs.launchpad.net/ubuntu/+source/ifupdown/+bug/974284
[16:48] <slangasek> smoser: hmm, had seen your follow-up to bug #838968 this morning in connection with this, and am at the moment still confused
[16:49] <slangasek> in part because I thought we'd put that issue to bed :)
[16:49] <smoser> well, we did a good job on boot.
[16:49] <smoser> (i think)
[16:49] <smoser> but apparently negatively affected reliability
[16:50] <smoser> and the most recent comment there is most damaging.
[16:50] <slangasek> ah, I see there
[16:50] <slangasek> I think I would argue that dhclient needs to be modified to give us the behavior we want
[16:50] <slangasek> stgraber: ^^ what do you think?
[16:53] <stgraber> yeah, I saw smoser's bug but am not too sure what to do here... assuming the interface is configured when dhclient returns is wrong unless we have -1 but if we call with -1 then it's possible you don't get your IP if the DHCP server was unavailable
[16:53] <stgraber> our current behaviour is identical to d-i and network-manager's behaviour, if you don't get an IP from DHCP within $TIMEOUT, it fails
[16:54] <smoser> the one thought i had....
[16:54] <smoser> most of the time the original 60 second timeout was enough
[16:54] <smoser> we bumpted that to 5 minutes
[16:54] <slangasek> stgraber: have posted a couple thoughts on the bug
[16:55] <slangasek> (and assigned to you)
[16:55] <smoser> i *think* that dhclient didn't background until that 5 minutes was up.
[16:55] <smoser> err. that timeout.
[16:55] <slangasek> smoser: I believe that's correct
[16:55] <smoser> if thats the case, then we're in a much better position if we revert the '-1' flag.
[16:55] <slangasek> er, oh
[16:56] <slangasek> sorry, no, it should background as soon as it gets a lease
[16:56] <slangasek> I misread
[16:56] <smoser> ie, ifup will much more often exit with the correct exit value (0 on success).
[16:56] <smoser> slangasek, oh. well thats good enough.
[16:56] <slangasek> if it hits the timeout without getting a lease, it exits non-zero, and the interface is marked as down
[16:56] <smoser> wel... anywah.
[16:56] <smoser> i'll lave you to think about it.
[16:56] <slangasek> if it gets a lease, it backgrounds immediately and the parent process exits 0
[16:56] <smoser> right, which really is "success"
[16:57] <smoser> so thats fine.
[16:57] <smoser> i lagely agree with the comment in the bug slangasek
[16:58] <smoser> but i think ideally we'd also still background on timeout failure
[16:58] <smoser> initial timeout.
[16:58] <smoser> ie, to safeguard for the power failure case, where 5 minutes wasn't enough, but 5 minutes and 3 seconds would have been.
[16:59] <stgraber> so we want dhclient to try for $TIMEOUT, if it gets a lease during that time, background itself and get into a renewal/retry loop, if it doesn't, then ???
[16:59] <stgraber> for ??? I tend to prefer failing as I really don't want to run the ifupdown hooks unless we have a working connection
[17:00] <stgraber> but you clearly prefer continuing regardless that'll make all the upstart jobs trigger as well as all upstart hooks (even though you don't have network access)
[17:02] <doko> bryceh, ping
[17:08] <stgraber> slangasek: commented in the bug. I scanned through all the existing options and no combination of these that are documented will do what we want, so we need to implement a new option
[17:09] <slangasek> stgraber: is it wrong to change the behavior of -1?
[17:10] <slangasek> the fact that dhclient -1 backgrounds and sticks around after getting a lease is already contrary to the obvious meaning of the option
[17:10] <slangasek> so extending it to also retry on failure once backgrounded would also seem ok to me?
[17:10] <slangasek> (NM doesn't appear to use -1, so no issues there)
[17:11] <stgraber> slangasek: I think it might be a problem if something like Network Manager (bad example, it doesn't use it, just checked) expects "dhclient -1" to exit on failure to renew as a way of monitoring it
[17:11] <slangasek> :)
[17:11] <slangasek> so, what else besides NM would we need to worry about here?
[17:11] <slangasek> d-i doesn't monitor either
[17:11] <stgraber> netcfg
[17:12] <stgraber> ah, I thought it was calling with -1
[17:12] <slangasek> it does, but it also doesn't monitor
[17:12] <slangasek> I think in general anything that's going to monitor for lease renewal failures is going to *not* use -1
[17:12] <slangasek> because if it's smart enough to monitor, it doesn't need the -1, does it?
[17:13] <slangasek> oh, maybe -1 is the only way dhclient does any error reporting at all :P
[17:13] <stgraber> indeed, you shouldn't need -1 if you monitor (using -sf)
[17:22] <smoser> ok. i have a stupid question. (not uncommon)
[17:22] <smoser> wget http://us.archive.ubuntu.com/ubuntu/dists/precise/main/installer-i386/current/images/MD5SUMS.gpg
[17:22] <smoser> wget http://us.archive.ubuntu.com/ubuntu/dists/precise/main/installer-i386/current/images/MD5SUMS
[17:22] <smoser> gpg  --keyring=/usr/share/keyrings/ubuntu-archive-keyring.gpg --verify MD5SUMS.gpg  MD5SUMS
[17:22] <smoser> 2 questions
[17:22] <smoser> a.) is there a better way to know the keyring to use there?
[17:22] <smoser> b.) when you do that it says: WARNING: This key is not certified with a trusted signature!
[17:29] <mdeslaur> smoser: why don't you just use the keyring that's in ubuntu-keyring?
[17:29] <smoser> is that not what i'm doing ?
[17:29] <mdeslaur> oh wait, I'm misreading :)
[17:29] <mdeslaur> duh, sorry
[17:30] <slangasek> smoser: a) no, b) the warning should be ignored
[17:30] <smoser> slangasek, gracias.
[17:32] <slangasek> smoser: to expand: the reason you can trust the key is because you have it installed via the ubuntu-keyring package, which uses its own trust path through the Ubuntu archive; so this makes the warning ignorable, but also means it's the only trust path most people have to the key, so you can't just fetch the key from a keyserver for verification
[17:32] <smoser> right.
[17:52] <SpamapS> slangasek: so, what do we do about myodbc?
[17:52] <SpamapS> slangasek: its the last rdep on libmysqlclient16
[17:58] <slangasek> SpamapS: hmm, in Ubuntu or Debian?  The version of myodbc in experimental should be syncable and work in precise, provided there's an adequate version of mysql-5.5 there
[17:59] <arges_> Who is the patch pilot today?
[18:01] <slangasek> I would look it up, but I can never remember the name of the wiki page
[18:01] <SpamapS> slangasek: ah so perhaps just a sync then? I'll try a test build.
[18:01] <slangasek> because it doesn't contain the words "patch" or "pilot"
[18:01] <slangasek> SpamapS: yeah, I would say a sync is best
[18:02] <slangasek> ah, CodeReview*s*
[18:02] <slangasek> (and there's now a PatchPilot redirect, goody :)
[18:02] <slangasek> cnd: are you patch piloting today?
[18:33] <psusi> why is there no bzr branch for mdadm?
[18:37] <slangasek> psusi: see http://package-import.ubuntu.com/status/ for the failure
[18:38] <ogra_> hmm, did debootstrap recently start to set the default locale to en_US.UTF-8 ?
[18:39]  * ogra_ gets locale warnings inside a fresh chroot where i'm chrooted with LANG=C ... 
[18:40] <slangasek> ogra_: not that I'm aware of
[18:40] <ogra_> weird
[18:49] <psusi> slangasek: so it's a bug in bzr?
[18:49] <slangasek> it's a bug in the package importer
[18:49] <slangasek> I don't know if it's a bug in bzr per se
[18:50] <psusi> slangasek: so I should file a bug against udd?
[18:50] <SpamapS> slangasek: test rebuild worked, smoke test worked.. myodbc synced
[18:50] <slangasek> psusi: you can, though I would note that this is unlikely to get actioned very quickly... if you care about seeing this fixed any time soon, you probably have to roll up your sleeves
[18:53] <slangasek> SpamapS: woohoo
[18:55] <SpamapS> I *think* thats the last actual mysql 5.1 deps now
[18:55] <SpamapS> everything left is just suggests
[18:56] <slangasek> cjwatson, apw: for reference, I do see a comment in the changelog, from 2009, about copying unicode.pf2 to /boot; so I presume that's how I have it :)
[18:56] <SpamapS> crap.. akonadi-backend-mysql
[18:57] <slangasek> heh
[18:57] <SpamapS> no
[18:57] <SpamapS> strike that
[18:57] <SpamapS> local version
[18:57]  * SpamapS needs to run these rdepends in a chroot
[18:57] <SpamapS> argh
[18:58] <stgraber> smoser: hmm, can you confirm that when running dhcp without -1 that when the lease expires and dhclient can't renew it doesn't exit and instead retries indefinitely?
[18:59] <smoser> stgraber, i honestly do not know.
[18:59] <stgraber> smoser: because I can't find any code doing that in isc-dhcp, the code path with or without -1 seems identical when it comes to renewal
[18:59] <smoser> so you think it would have failed all the same for the bug opener
[18:59] <smoser> regardless of the -1
[18:59] <stgraber> looking at the code, it should, yeah
[18:59] <stgraber> »···if (interval > client -> config -> timeout) {
[18:59] <stgraber> »···»···state_panic (client);
[18:59] <stgraber> »···»···return;
[18:59] <stgraber> »···}
[19:00] <smoser> i cannot ocnfirm that.
[19:00] <smoser> or deny
[19:01] <stgraber> that code is all the code paths I could find, so when dhclient can't renew, it tries again for $TIMEOUT (5 minutes in our case), then that if matches and dhclient exits with an error message in syslog
[19:01] <stgraber> smoser: I'll run another test here to confirm that I get the same behaviour without -1
[19:01] <smoser> stgraber, and it takes down the iP ?
[19:01] <stgraber> yes
[19:02] <stgraber> correct behaviour considering it's expired and can get allocated to another client by the server
[19:02] <stgraber> (when it gets back to life)
[19:34] <SpamapS> jdstrand: https://bugs.launchpad.net/ubuntu/+source/lemonpos/+bug/894377 .. mysql-5.1 is safe to remove now :)
[19:35] <jdstrand> SpamapS: ack, thanks
[19:41] <jjohansen> stgraber: so I have hardware to help debug the web cam bug in Bug #966294
[19:47] <stgraber> jjohansen: cool, I currently have ssh access to gema's netbook for testing
[19:47] <stgraber> jjohansen: can you confirm that "gst-launch-0.10 v4l2src ! video/x-raw-rgb,width=640,height=480 ! ffmpegcolorspace ! xvimagesink" works on that machine?
[19:48] <stgraber> it's a bit dark at gema's place at the moment ;) so hard to tell if I'm getting a black/broken input or if it's actually working :)
[19:53] <jjohansen> stgraber: yes it works
[19:55] <jdstrand> SpamapS: mythtv has build deps on libmysqlclient16-dev | libmysqlclient15-dev
[19:57] <jdstrand> SpamapS: I added a task to the bug
[19:57] <micahg> superm1: ^^
[19:57] <jdstrand> superm1: fyi 894377
[19:58] <jdstrand> superm1: also fyi, libmysqlclient16-dev is listed twice as a build dep
[19:58] <stgraber> jjohansen: ok, I'm starting to downgrade packages to pinpoint when it broke, I might poke you again for more tests soon
[19:58] <jjohansen> stgraber: sure
[20:00] <stgraber> jjohansen: do you remember seeing that screen when installing Oneiric?
[20:00] <jjohansen> stgraber: yep, it worked did it this morning
[20:01] <stgraber> cool, thanks, that's useful to confirm ;)
[20:13] <superm1> jdstrand: mythtv has build depends on either so that the same source can be built on lucid->precise
[20:13] <superm1> we build on the daily PPA using the same source package
[20:13] <jdstrand> superm1: that is fine-- I'm saying that libmysqlclient16-dev is listed on its own and as part of libmysqlclient16-dev | libmysqlclient15-dev (check the control file)
[20:14] <superm1> jdstrand: ohh i see
[20:14] <jdstrand> superm1: problem is, libmysqlclient16-dev is going away in precise. see bug #894377
[20:14] <superm1> will fix it for next upload
[20:14] <jdstrand> superm1: can you adjust it to also have libmysqlclient-dev in there?
[20:15] <superm1> jdstrand: sure
[20:15] <jdstrand> superm1: awesome-- that should fix the bug
[20:15] <jdstrand> superm1: thanks!
[20:15] <superm1> planning next upload to be start of next weekish (right before FF), is that ok, or do you need it fixed sooner so the archive can adjust?
[20:16] <jdstrand> I'll let SpamapS comment ^
[20:16] <jdstrand> this is all universe stuff, so it shouldn't really matter
[20:22] <chrisccoulson> is there an archive admin who can process bug 971525 for me, please :-)
[20:23] <micahg> chrisccoulson: that one wasn't from Debian, Q-FUNK uploaded it
[20:23] <chrisccoulson> really?
[20:24] <chrisccoulson> that sucks
[20:24] <micahg> yeah, I complained at the time
[20:24] <chrisccoulson> it still needs to go
[20:24] <micahg> and I thought you said it was fine :)
[20:24] <chrisccoulson> i was never asked about this
[20:26] <stgraber> jjohansen: did you try with i386 or amd64?
[20:26] <chrisccoulson> urgh, no, this isn't. i've never looked at this in my life
[20:26] <chrisccoulson> i looked at some spice plugin
[20:26] <chrisccoulson> but not this
[20:26] <jjohansen> stgraber: amd64
[20:26] <chrisccoulson> nobody has ever asked me about this extension
[20:26] <micahg> I will scream louder next time ;(
[20:26] <jjohansen> do you want me to reinstall and try i386?
[20:26] <jjohansen> stgraber: ^
[20:28] <stgraber> jjohansen: I currently don't have any reason to suspect the architecture to impact it but I see that only one of the duplicates was on i386, everything else was amd64
[20:29] <stgraber> jjohansen: btw, apparently downgrading libgstreamer0.10-0 to oneiric's version, does the trick on that system, now triple-checking this and I'll try to pinpoint a specific part of the library as the changelog is unfortunately huge
[20:29] <stgraber> jjohansen: so yeah, if you don't care about that system and have a few minutes, testing i386 would be interesting, if only just to confirm that it's not architecture specific
[20:30] <jjohansen> stgraber: okay, will do
[20:38] <Q-FUNK> seb128: deleting a package from the archive just like that is not appreciated at all.
[20:39] <Q-FUNK> chrisccoulson: and if there's a problem with a particulat plug-in, file a bug, rather than acting like you did.
[20:39] <micahg> Q-FUNK: it never should've been uploaded in the first place
[20:39] <chrisccoulson> Q-FUNK, it shouldn't have been accepted
[20:39] <chrisccoulson> we got rid of pretty much all firefox extensions from the archive for a good reason
[20:40] <Q-FUNK> chrisccoulson: then it should have been said back then.
[20:40] <bdrung> kenvandine: nice ubuntu-wallpaper upload. finally the old wallpapers can still be used.
[20:40] <chrisccoulson> of course. but nobody asked me
[20:41] <Q-FUNK> chrisccoulson: could it have been a good idea to get yourself know to the uploader then?
[20:41] <seb128> Q-FUNK, breaking firefox is not appreciated at all
[20:41] <Q-FUNK> chrisccoulson: right now, you're forcing the removal of a package that's needed to access public services and whose upload into the archive took ages to happen.
[20:41] <Q-FUNK> seb128: do you even have proof that it's what did it?
[20:41] <seb128> Q-FUNK, the removal has been asked by the firefox maintainer and I trust him to know what he's asking for
[20:42] <seb128> Q-FUNK, it's not like it's hard to add it back when it's resolved
[20:42] <seb128> Q-FUNK, it's just the safe way
[20:42] <seb128> Q-FUNK, if it turns out to be an error I'm happy to NEW it back
[20:42] <Q-FUNK> seb128: it's not like I can know IF and WHAT is broken after it's been removed without anyone backing up their claims.
[20:43] <seb128> Q-FUNK, well it's "first let's stop breaking user, then we can discuss"
[20:43] <chrisccoulson> Q-FUNK - we update firefox every 6 weeks. in adding a new extension to the archive, you're effectively committing me to spend extra time every 6 weeks for the next 5 years unbreaking, updating and testing it to keep it working with new versions of firefox
[20:43] <kenvandine> bdrung, jbicha did the hard work :)
[20:43] <chrisccoulson> not cool
[20:43] <micahg> chrisccoulson: I assume this is not an NPAPI plugin, right?
[20:44] <bdrung> kenvandine, jbicha: thanks for that. the default wallpaper are missing: bug #974628.
[20:44] <Q-FUNK> micahg: you're also making assumptions that are unverified.
[20:44] <chrisccoulson> micahg, it has a binary part that might be, but it also has a firefox extension
[20:44] <chrisccoulson> Q-FUNK, what assumptions?
[20:44] <chrisccoulson> i can assure you that extension is what broke your firefox localization
[20:44] <chrisccoulson> by installing itself in to a location that is meant to be a symlink
[20:45] <Q-FUNK> chrisccoulson: ok, so why didn't you just file a bug, rather than get seb128 to remove the package?
[20:45] <micahg> Q-FUNK: we can't have random extensions in the archive as we can't be updating them every 6 weeks, if something is a pure NPAPI plugin, then it shouldn't break anything and should be fine, but even in those cases we have had some issues
[20:46] <Q-FUNK> micahg: the source package contains both a XUL extension and a NPAPI plug-in, packaged separately.
[20:46] <chrisccoulson> what functionality does the extension provide?
[20:46] <micahg> Q-FUNK: right, so one piece is ok and the other isn't :) (assuming the plugin is installed properly)
[20:48] <Q-FUNK> the XUL extension interfaces with opensc's one-pin module for website logon using PIN1.
[20:48] <Q-FUNK> the NPAPI plug-in inerfaces with libdigidocpp to enable legally-binding digital signature of online documents using PIN2.
[20:48]  * micahg will leave the rest here to chrisccoulson
[20:48] <jbicha> bdrung: I'm not so sure we should include old copies of *the* default wallpaper itself
[20:49] <chrisccoulson> note, i've just had a quick glance at the extension, and it would have even failed the basic preliminary review on addons.mozilla.org
[20:49] <Q-FUNK> micahg: it could indeed be that the plug-in is at the correct location, while he extension isn't. if that's the case, please just put the info in the bug and I'll upload a fix.
[20:49] <chrisccoulson> for polluting the main window global JS scope
[20:49] <chrisccoulson> quite a lot, too
[20:49] <Q-FUNK> chrisccoulson: could be.  it needs to do a lot of backflips to interface with the card.
[20:50] <chrisccoulson> it needs to do that without polluting the main browser window scope though
[20:50] <bdrung> jbicha: it would be nice to be able to install the old default wallpaper. my favourite ubuntu default wallpaper is the one from hardy.
[20:50] <chrisccoulson> mozilla provide guidelines for avoiding that
[20:50] <chrisccoulson> but that can break firefox and other addons in extremely strange, unpredictable and hard-to-trace ways
[20:51] <bdrung> jbicha: they could either put to the ubuntu-wallpaper-* packages or into a separate package.
[20:51] <Q-FUNK> chrisccoulson: upstream is quite active, as he is legally-bound to provide support by a public sector contract. if there's any such issue, I'm sure he'd love to hear about it.
[20:51] <SpamapS> jdstrand: hrm, I wonder why it build-deps but does not have a real dep .. argh!
[20:52] <Q-FUNK> chrisccoulson: upstream happens to be online now on #esteid if you'd like to explain what you just told me.
[20:53] <chrisccoulson> Q-FUNK - 1 second. i'm just going to install it to make sure that's correct :)
[20:53] <jbicha> bdrung: I was thinking of a ubuntu-wallpapers-classic with the pre-karmic wallpapers, but for the lucid-precise series the wallpaper isn't changing much
[20:53] <jbicha> and I think the intended design is that the new tweaks replace the older version of the orangey-aubergine light thing
[20:54] <Q-FUNK> chrisccoulson: basically, I'm committed to maintaining the ubuntu package, while upstream is legally-bound to support his code. whatever's wrong, please let us know.
[20:54] <bdrung> jbicha: a ubuntu-wallpapers-classic package with the pre-karmic wallpapers sounds good.
[20:56] <jbicha> bdrung: I don't think I'll do the slideshow for them though, just the standalone images
[20:57] <bdrung> jbicha: creating a slideshow isn't that big deal
[20:57] <bdmurray> SpamapS: do you plan on working on bug 957494?
[21:06] <stgraber> smoser, slangasek: hmm, apparently I was wrong, something makes dhclient stick around when it's not called with -1, will have to dig some more to figure out where that's
[21:06] <bkerensa> cyphermox: you have a minute?
[21:06] <cyphermox> yeah
[21:06] <smoser> stgraber, thank you for looking at this.
[21:06] <slangasek> stgraber: ok
[21:06] <cyphermox> bkerensa: shoot :)
[21:06] <bkerensa> cyphermox: I hear you are the bt expert?
[21:06] <bkerensa> :D
[21:07] <cyphermox> I'd never call myself an expert at anything ;)
[21:07] <cyphermox> bkerensa: what do you want to know ?
[21:08] <bkerensa> cyphermox: well I have a bug basically I have a brand new Jabra Halo v2 that pairs fine in Ubuntu but does not function as a headset and wont show up in -> Sound Settings
[21:08] <bkerensa> and I am wondering who would be responsible for this kind of bug or at least works on these
[21:10] <bkerensa> cyphermox: https://bugs.launchpad.net/ubuntu/+source/pulseaudio/+bug/972063
[21:11] <cyphermox> depends what bluez does with the headset; it might be bluez or pulseaudio. I'll update the bug accordingly
[21:12] <SpamapS> bdmurray: I hadn't looked closely at it since the initial comment. I do want to fix it.
[21:21] <bkerensa> cyphermox: the only thing that happens is if I press the button on the side of the headset it will mute my system sound and unmute but other than that no audio comes through and no sound settings profile is created
[21:22] <bkerensa> cyphermox: slangasek did some basic troubleshooting with me but I am more than willing to do more debug if need be to get it sorted
[21:22] <slangasek> the button working is irrelevant
[21:23] <slangasek> rather, it's irrelevant to audio, which is a pulseaudio+bluez problem
[21:23] <slangasek> the button works as a kernel input device
[21:23] <cyphermox> oh, that changes things
[21:23] <cyphermox> otoh, it means the device is properly paired and it's likely more of a pulseaudio issue than something with bluez
[21:23] <slangasek> yes
[21:25] <bkerensa> cyphermox: so basically I would love to work to try and debug this so whomever works on pulseaudio can perhaps make a crack at fixing it sometime in the future
[21:25] <bkerensa> :D
[21:44] <jjohansen> stgraber: so I can confirm i386 exhibits the same issue
[21:45] <stgraber> jjohansen: cool, thanks
[21:53] <skaet> We're now a week out from final freeze,  and are going to be freezing the archive, so that we can start to be selective about the fixes getting added.
[21:54] <cjwatson> slangasek: unicode.pf2> oh, what do you know, we still do that; but for some reason /boot/grub isn't preferred over /usr/share/grub for loading it
[21:55] <cjwatson> that's a bug I think
[21:55] <slangasek> ah :)
[21:55] <slangasek> does that mean we still don't know what's going on with reports of brokenness w/ crypted root?
[21:56] <slangasek> oh, of course - my / is encrypted and my /usr isn't
[21:56] <slangasek> so my experience is not going to be typical anyway here :P
[21:58] <cjwatson> well, I think loading that from /boot/grub would serve to render at least encrypted /usr closer to the standard case
[21:59] <slangasek> right
[22:14] <skaet> Please continue to upload fixes,  and allert the release team members in #ubuntu-release for seeded image package fix issues,  and #ubuntu-motu channel for unseeded universe package issues.
[22:54] <apw> q2
[23:18] <cnd> slangasek, I'm down with a fever :(
[23:18]  * kees hugs cnd
[23:19] <cnd> kees is now infected too
[23:20] <kees> only virtually
[23:33] <SpamapS> kees: Hey, you know about md and udev.. any ideas on what adding this rule into the mdadm package might do to peoples' raid arrays? http://paste.ubuntu.com/916749/ ?
[23:43] <kees> SpamapS: one sec, reading...
[23:43] <kees> SpamapS: er, is this an entirely new file?
[23:45] <SpamapS> kees: it would be /lib/udev/rules.d/64-md-raid.rules
[23:45] <SpamapS> kees: we haven't been installing it since jaunty
[23:46]  * kees studies
[23:46] <SpamapS> kees: I think its just missing due to an oversight
[23:46] <SpamapS> my udev knowledge is very weak.. :-P
[23:52] <psusi> SpamapS, we seem to be shipping 65-mdadm-blkid.rules instead
[23:52] <kees> SpamapS: so, the first section is handled (more correctly) by 85-mdadm.rules
[23:52] <psusi> and that one
[23:53] <kees> SpamapS: and the rest, as psusi says, is in 65-mdadm-blkid.rules
[23:53] <SpamapS> interesting
[23:53] <SpamapS> ok, this is an upstream file
[23:53] <SpamapS> so it looks like we split it up already
[23:53] <kees> (which is also more correct)
[23:53] <psusi> yea.. also it looks like the upstream one is trying to use mdadm to activate intel fakeraid and ddf, which we still have handled by dmraid
[23:54] <SpamapS> I think I'll keep the upstream one out of the package then
[23:54] <SpamapS> psusi: this came up when I was solving the mdmon missing problem
[23:54] <psusi> though someone yesterday had some trouble with intel fakeraid and it looked like mdadm had tried to activate it in the installer
[23:54] <SpamapS> mdadm is still quite a mess IMO..
[23:55] <SpamapS> Certainly better, as we're at least up to date with upstream
[23:55] <psusi> upstream still hasn't sorted out how to deal with the problems introducing support for ddf and intel fakeraid causes... namely mdadm now conflicts with dmraid since both can handle those arrays
[23:57] <SpamapS> alright, well for this particular fix, I'm just going to keep this file out of rules, but include mdmon and its corresponding manpage. Is mdmon at all part of the ddf/fakeraid case?
[23:58] <psusi> yes... apparently its a daemon that updates the on disk metadata on behalf of the kernel
[23:58] <psusi> for the new external metadata types
[23:59] <psusi> it's required to get the array mounted read/write... and it seems there's a kernel BUG_ON that gets triggered without it... sounds like they assumed it would be there and didn't deal with it when it isn't...