[00:04] <mohbana> ok i;ve got to go
[01:03] <slangasek> Caesar: aha
[01:45] <calc> hmm it didn't find any errors, i guess i will reinstall and see what it does
[01:55] <calc> if my drive keeps getting weird errors after that i will ebay it since it likely is a miscommunication between the drive and the laptop (it has a drop sensor in the drive itself, plus the one in the laptop)
[01:55] <calc> then i will just need to get a drive without the sensor
[02:24]  * bluefoxicy waits 10 minutes for evolution to start
[02:25] <TheMuso> c
[02:29] <nixternal> bluefoxicy: 5 minutes to go
[02:29] <nixternal> use Mutt, it is instant :)
[02:30] <bluefoxicy> nixternal:  I started it 10 minutes ago, still waiting.
[02:45] <bluefoxicy> is this ever gonna finish
[02:55] <bluefoxicy> finally
[02:58] <Caesar> slangasek: the patch to fix it is hilarious
[02:58] <Caesar> I should update the bug with it
[03:02] <lifeless> bluefoxicy: you're running karmic?
[03:08] <bluefoxicy> lifeless:  no
[03:09] <lifeless> bluefoxicy: jaunty?
[03:09] <bluefoxicy> yep
[03:09] <lifeless> hmm
[03:10] <lifeless> well, file a bug upstream, keyword 'perf', and be sure to grab a strace or other analysis to be able to say broadly whats wrong
[11:40] <slangasek> calc: OOo in karmic seems to have silently switched to using the system librdf0 again, pulling 500K of libs onto the CD - is this offset by a size decrease in the OOo packages themselves?
[12:06] <slangasek> boo, what happened to the "how to version security updates" description from https://wiki.ubuntu.com/SecurityUpdateProcedures?
[12:06] <slangasek> ah, https://wiki.ubuntu.com/SecurityTeam/UpdatePreparation now
[12:35] <MacSlow> kenvandine, hey there
[12:36] <MacSlow> kenvandine, were you able to get any of the laptops running with the projectors at the last plenary session at UDS on friday?
[13:09] <bryce> pitti: I seem to have not escaped UDS without bringing ubuflu home with me.  I'm taking today off sick
[13:10] <slangasek> eep
[13:11] <slangasek> if bryce is sick with the ubuflu, I guess it's only a matter of time before I'm incapacitated
[13:11] <bryce> slangasek: yeah you're the last pdx mafia left standing
[13:12] <slangasek> maybe I acquired immunity by also being the only pdx mafia member to do karaoke
[13:12] <bryce> ahh
[13:14] <bryce> heya rickspencer3
[13:14] <rickspencer3> hi bryce
[13:15] <MacSlow> bryce, just everybody got it :/
[13:15] <slangasek> bryce: so I guess I can't pester you about this sudden X behavior change where xrandr calls are crashing the server even though there've been no changes to the server packages in jaunty lately :)
[13:16] <bryce> MacSlow: UDS=PetriDish
[13:16] <slangasek> (that's ok, I seem to have a useful error message in gdm log, so I'll file a bug :)
[13:17] <MacSlow> bryce, *g*
[13:17] <rickspencer3> bryce: if you're sick, take a day off
[13:17] <rickspencer3> ;)
[13:17] <bryce> rickspencer3: yeah I think so
[13:17] <rickspencer3> you don't want to get everyone in #ubuntu-devel sick, right
[13:17] <bryce> hehe
[13:18] <bryce> *cough* *cough*
[13:18] <MacSlow> For everybody not seen yet, a quick screencast of the "cairo on the GPU"-proof-of-concept -> http://macslow.net/clips/gl-fragment-curves-1.ogg (still uploading though)
[13:19]  * persia hands bryce a handy mask
[13:19]  * rickspencer3 disinfects monitor
[13:19] <MacSlow> agateau, salut
[13:20] <agateau> MacSlow: guten tag!
[13:22] <kenvandine> MacSlow: no, we didn't
[13:22] <kenvandine> rickspencer3: your up early
[13:22] <rickspencer3> kenvandine: yeah, couldn't sleep
[13:23] <kenvandine> i am filling out my swap day form :)
[13:23] <rickspencer3> (I'm not really here, I'm taking vacation until Thur ;) )
[13:23] <bryce> mm jet lag
[13:23] <rickspencer3> hehe
[13:23] <bryce> yeah got that too
[13:23] <rickspencer3> bryce: kenvandine: I actually like the Europe to Seattle Jet lag starting on day 2 (day 1 I am just whipped)
[13:24] <kenvandine> i was too
[13:24] <kenvandine> i felt exhausted by 3pm
[13:37] <slangasek> oh wow, this is the worst rendering of 'ff' by firefox that I've ever seen
[13:38] <mterry> slangasek: Oh, I realized over the weekend why the 'Copyright' field in the proposed debian/copyright spec is optional: for public domain items
[13:39] <slangasek> mterry: right, I disagree with this interpretation - the 'Copyright' field is the right place to declare that a work *is* public domain :)
[13:39] <mterry> slangasek: Ah, the examples use the license field.  OK, as long as you were aware of the use case
[13:50] <ogra> hmm, shouldnt PCIID '8086:2a02' be unblacklisted in karmic ?
[13:50]  * ogra was hoping for composite after the upgrade
[13:50] <Tm_T> that is what exactly? (I'm curious)
[13:50] <ogra> intel
[13:51] <Tm_T> ah, roger roger
[13:51] <ogra> i965
[13:52] <Tm_T> ah, that beastie
[13:54] <ogra> bryce, shouldnt 8086:2a02 be un-blacklisted in the karmic intel driver ?
[13:55] <bryce> ogra: yes
[13:56] <ogra> weird
[13:56] <ogra> Blacklisted PCIID '8086:2a02' found
[13:56] <ogra> aborting and using fallback: /usr/bin/metacity
[13:56] <ogra> thats what i get in ~/.xsession-errors trying to switch to compiz
[13:56] <bryce> the blacklisting is in compiz, not in the intel driver
[13:57] <ogra> ah
[13:57]  * ogra edits
[13:58] <ogra> wow, decent alt-tab behavior is back ...
[14:26] <maxb> Is it intentional that syncs from debian don't cause email to karmic-changes@ ?
[14:39] <james_w> maxb: auto-syncs yes, manually requested syncs should
[14:40]  * maxb was a bit surprised when a bunch of things showed up in update manager but not in changes email
[14:42] <maxb> If that was an autosync, would that normally sync every eligible package? I was expecting a linphone update on the next autosync but it doesn't seem to have happened
[14:42] <Tm_T> maxb: nice that you mentioned linphone... (:)
[14:45] <james_w> maxb: it would do normally
[14:46] <Tm_T> maxb: dunno if you need to know, but I mention, https://lists.ubuntu.com/archives/kubuntu-devel/2009-June/002901.html
[14:47] <slangasek> it may not have been built yet?
[14:47] <maxb> It's not build on ia64 or mipsel yet - that matters?
[14:47] <slangasek> no, that doesn't matter
[14:47] <slangasek> I mean that the source may be synced to Ubuntu and the binaries may not be built yet
[14:48] <maxb> rmadison says no, but that could be out of date
[14:48] <slangasek> it is
[14:48] <slangasek> fwiw :)
[14:48] <maxb> oh
[14:49] <maxb> right, nothing to worry about then
[15:18] <calc> slangasek: i think so, it should be anyway since when not using the system rdf it ships rdf in its own packaging
[15:36] <calc> grr i somehow didn't manage to reinstall grub correctly when i restored my laptop, i can't get it to boot :(
[15:38] <slangasek> calc: well, it also pulls in things like redland-utils as recommends, which I think might've been the reason we went this way for jaunty?
[15:41] <calc> iirc one of the reasons i disabled it at least was due to thinking the internal copy worked better but i talked to rene and he said the system one worked as well (which he was already using at the time), i suppose we could demote its recommends(?)
[15:48] <calc> did vol_id go away in karmic?
[15:49] <ogra> calc, yes
[15:49] <Kano> calc: how did you try
[15:49] <calc> it claims i don't have it and that if i install udev it would be there... which udev is already installed
[15:50] <ogra> use blkid
[15:50] <calc> i'm trying to make sure my uuid's are correct
[15:50] <calc> ogra: ok
[15:51] <calc> doh i am using the wrong uuid in grub somehow
[15:51]  * calc updates it and hopes it works
[15:55] <calc> it worked, no idea where i got the previous uuid from, that was strange
[15:55] <slangasek> what's the status of pulseaudio in karmic?
[15:55]  * slangasek just dist-upgraded, and pulseaudio isn't working
[15:55] <calc> slangasek: not sure i think TheMuso and crimsun were intending to fix it up soon after UDS
[15:56] <slangasek> calc: what is it that needs fixing up? :)
[15:56] <slangasek> I don't see any matching bug reports, and the error message is opaque as usual
[15:56] <calc> slangasek: i don't remember the details, sorry
[15:56] <calc> but i don't think it related to it not working at all, just to make it work better in some cases
[15:56] <slangasek> TheMuso, dtchen: ping
[15:58] <slangasek> Jun  1 07:42:24 dario pulseaudio[4693]: module.c: Failed to load  module "module-alsa-card" (argument: "device_id=0 name=pci_8086_27d8_sound_card_0 card_name=alsa_card.pci_8086_27d8_sound_card_0 tsched=0"): initialization failed.
[15:58] <slangasek> 'swhat I get
[15:58] <persia> slangasek, Does direct access through ALSA work?
[15:59] <slangasek> persia: how can I trick GNOME into doing that, given the pulseaudio autospawn nonsense?
[15:59] <persia> slangasek, aplay?
[15:59] <calc> persia: we aren't routing alsa through pulse yet are we?
[16:00] <persia> But more importantly, when you get that error, pulseaudio is failing to load the alsa module, so it's not grabbing the card.
[16:01] <persia> calc, Hrm.  I don't think so, but I could be wrong (I'm still cleaning up some infrastructural issues before upgrading to karmic)
[16:01] <slangasek> persia: well, yes, that much is clear; I don't find that this makes it particularly diagnosable, though
[16:03] <slangasek> aplay doesn't throw errors; it also doesn't give me sound
[16:03] <persia> slangasek, Hrm.  That's probably true.  Did I actually understand the deep stack, I'd probably be asking you questions about your kernel conf and comparing to that output line, but I'm not prepared to interpret the results if you gave them to me.
[16:03] <persia> If aplay doesn't give you sound, you've very likely an issue loading your audio card driver.
[16:03] <slangasek> the driver is loaded
[16:04] <slangasek> and if I switch to OSS, I get sound
[16:04] <loic-m> ogra: ping
[16:05] <persia> I think I had that bug once.  I ended up disabling OSS.  Something about the device being captured by the OSS compatibility layer, I think, but I don't really understand it.
[16:05] <persia> But I am sure that it's not pulse if aplay also doesn't work.  Doesn't really help explain the issue though.
[16:06] <slangasek> eh, except my understanding is that alsa now autospawns pulse by default, so just running 'aplay' *is* pulse
[16:06] <slangasek> if I try to point aplay at the sound card explicitly, I get a 'Sample format non available' error instead
[16:07] <persia> That's more useful.  You can fiddle with -f, but it would depend on you having the right file.
[16:09] <slangasek> "the right file"?
[16:10] <persia> slangasek, A file in the format you specified.
[16:10] <persia> (which you may be able to create with arecord, but not if it isn't working)
[16:11] <slangasek> except I didn't specify a format
[16:11] <slangasek> it's a .wav file, and it knows what format it's in and it refuses to play it.
[16:14] <persia> Ah.  That usually indicates either that your sound card doesn't support the format or that there is a negotiation issue.
[16:14] <persia> (one of the things pulse does is resample everything before submitting to the card to reduce these issues)
[16:15] <slangasek> gives me no feedback about what format it wants, though
[16:18] <persia> Unfortunately, I forget how to get that information :(  Maybe dtchen will come around at some point.
[16:19] <slangasek> bug #382440 opened, in the meantime
[16:27] <slangasek> persia: nah - if I manually neuter alsa to not autospawn pulse, then alsa playback works fine
[16:27] <persia> It's not supposed to do that.  Now I'm confused, and have all the more incentive to upgrade soon.
[16:27] <persia> I wonder if pulse is trying to attach to the pulse pcm in a loop or something.
[16:28] <slangasek> oh, that's interesting; now I've reset everything to permit autospawn again, and it still works
[16:28] <slangasek> and pulse is running, and attaching successfully
[16:28] <persia> Right.  Quick, before you lose it, save the entire history of what you've done.  You may need it again.
[16:29] <slangasek> heh
[16:57] <slangasek> TheMuso: bug #379092> hmm, from what I remember being discussed in February, that sounds like a regression to me, as adjtime shouldn't be used even if it does exist
[17:35] <wip> hi sorry for the noise, but we need a new rt-kernel release. too many bugs in the actual release
[19:23] <alex-weej> MacSlow: are you trying to make a Cairo backend like Glitz?
[19:23] <alex-weej> i'm still a bit confuses as to what you are making
[19:35] <mweichert> hello, I'm trying to learn how to create pam-auth-update packages. However, I see common examples of modules using key,value pair control-flags for modules, such as that appear here: https://wiki.ubuntu.com/PAMConfigFrameworkSpec
[19:36] <mweichert> I'm used to the following module control-flags: required, sufficient, optional
[19:36] <mweichert> I've never come across something like this before, till now: [success=2 default=ignore]
[19:36] <mweichert> where can I read about this format?
[19:39] <mweichert> I've found a little info here: http://www.kernel.org/pub/linux/libs/pam/Linux-PAM-html/sag-configuration-file.html
[19:40] <holoway> mweichert: that's where I remember learning about that syntax
[19:40] <holoway> and the other extensions, like skip
[19:41] <holoway> (which is good for ldap)
[19:47] <mweichert> holoway: can I ask you to look at this brief example if you don't mind: http://www.pastie.org/496843
[19:47] <holoway> mweichert: sure
[19:48] <mweichert> is line 6, saying if this module succeeds, to go line 11
[19:48] <mweichert> success=2, meaing skip the next two modules ?
[19:48] <holoway> mweichert: exactly
[19:48] <mweichert> holoway: ok, perfect - thanks
[19:48] <holoway> it's a sneaky bit of pam magic
[19:49] <holoway> but it's a very good idea, and that's a nice pam configuration, actually
[19:50] <holoway> in the past, I've used that syntax to handle things like skipping the LDAP checks for local users, etc
[19:50] <mweichert> holoway, yeah, I can see it's usefulness. I actually find it easier to read than using the other control-flags (now that I understand the syntax)
[19:50] <holoway> oh yeah - it's the way to go if you are building a complicated pam structure
[19:51] <holoway> once I started thinking about it like a kind of funky firewall syntax it made more sense - default policy is denial, success usually jumps you out of the control flow, etc.
[19:52] <mweichert> holoway, I'm liking it. :)
[19:54] <mweichert> holoway, is success=end the equivalent of success=ok or success=done ?
[19:55] <holoway> mweichert: I think so, but it's been a while since I've dug around inside of pam
[19:56] <holoway> mweichert: I believe the difference is that success=ok means you move on, and you are just contributing to success
[19:56] <holoway> mweichert: wheras 'end' means 'I am the canonical answer - success has happened, stop processing the rest of this phase'
[19:56] <holoway> and die is the same, only for failure ('I am the ultimate failure, don't ask any other modules in the stack')
[19:59] <mweichert> holoway, ok - thanks.
[20:23] <MacSlow> alex-weej, if I'll add my stuff to glitz or do it separately in the end I cannot tell yet
[20:23] <MacSlow> alex-weej, it's too early
[20:51] <mterry> It seems to be the case that --install-layout=deb isn't needed anymore for python2.6?  Without it, on a karmic-built package, the modules correctly get put in /usr/lib/python2.6/dist-packages.  Was that just a temporary necessity?
[20:54] <aliciapg> was kdenlive removed from kde recently?
[20:54] <Tm_T> removed from where exactly?
[20:55] <aliciapg> i tried to submit a bug report for kdenlive upstream but it was no longer listed as one of their projects anymore in bugzilla
[20:56] <Tm_T> aliciapg: ah, you might like to ask #kde and/or #kdenlive then?
[20:56] <aliciapg> thanks i'll try that
[20:57]  * Tm_T wonders why ask in here in first place anyway
[20:57] <mterry> Tm_T: Because this room has such helpful people!  :)
[20:58] <Tm_T> where?
[21:00] <aliciapg> because kde was non responsive
[21:01] <Tm_T> interesting
[21:41] <mweichert> can someone help explain the differences to me between Primary, Additional, Initial types used in pam-auth-update packages please?
[21:42] <mweichert> Primary vs Additional - I take it that the primary type is used if there is no other packages enabled?
[22:10] <dtchen> slangasek: seems a lot like the dbus races that were floated about last cycle, will look in a bit
[22:12] <dtchen> slangasek: in the meantime, disabling PA's autospawn is accomplished by echoing "autospawn = no" into ~/.pulse/client.conf and killing pulseaudio
[22:32] <maxb> mweichert: I'm trying and failing to find actual documentation, but it looks to me that Primary ones provide an actual method of authenticating users, etc., whilst Additional ones are merely ones which hook into pam to provide additional functionality
[22:32] <maxb> i.e. without a Primary one, PAM would be useless/crippled
[22:59] <TheMuso> slangasek: but since adjtime won't exist, nothign will be done.
[22:59] <TheMuso> slangasek: and pong re whatever youw atned to talk to me and dtchen about.
[23:20] <slangasek> mweichert: https://wiki.ubuntu.com/PAMConfigFrameworkSpec
[23:20] <slangasek> TheMuso: right, point is whether it's wrong even *if* /etc/adjtime exists
[23:21] <slangasek> TheMuso: the ping became bug #382440.
[23:21] <TheMuso> slangasek: ok thanks