[00:04] <directhex> gwaaaaan, dare you. double dare you!
[00:06] <Hobbsee> calc: will that be in the final?
[00:08] <RAOF> Man "glitch-free" pulseaudio is a barefaced lie :)
[00:09] <directhex> so, i wonder if Hobbsee here feels like being a hero & uploading that ickle security-driven mono merge
[00:10] <RAOF> TheMuso: If you're interested in pulseaudio 0.9.13 feedback, it suffers from _more_ underruns than 0.9.12
[00:10] <TheMuso> RAOF: Oh wonderful. :S
[00:10] <directhex> RAOF, thank god for my soundblaster!
[00:11] <TheMuso> The more I deal with hda hardware, the less I like it.
[00:11] <RAOF> I belive crimsun came to the same conclusion!
[00:11] <Hobbsee> directhex: mono?  No.
[00:11] <directhex> aw, poopies.
[00:11] <Hobbsee> RAOF: it's glitch free for me.  *shrug*
[00:11] <NCommander> WHen does jaunty open specifically?
[00:11] <NCommander> Start of november, right?
[00:12] <Hobbsee> NCommander: fail.
[00:12]  * NCommander never claimed to succeed ;-)
[00:12] <Hobbsee> NCommander: you've just managed to make this the worse release we've had that question :P
[00:12] <NCommander> o_o?
[00:12] <NCommander> My English parser failed
[00:12] <Hobbsee> people are watching for when that question first gets asked.  usually, the previous one manages to release first before anyone asks when the next one will open!
[00:13] <TheMuso> RAOF: What would be interesting is someone else who had the same codec on different system hardware, and whether they got the same underruns.
[00:13] <Hobbsee> yeah, i think my english writer failed in the first sentence, too
[00:13] <james_w> start of November?
[00:13] <NCommander> Hobbsee, I only ask because we have a serious bug that happens to a backport
[00:13] <Hobbsee> NCommander: now you've gone beyond that record (asking a couple of days after release).
[00:13] <TheMuso> RAOF: Did you post your alsa-info output anywhere?
[00:13] <NCommander> er wait
[00:13] <Hobbsee> NCommander: ahhh.  I thought you were just desperate to start merging, or something.
[00:13] <NCommander> intrepid was released and I missed it?
[00:13] <Hobbsee> no.
[00:13] <NCommander> Hobbsee, no, this is just backport related
[00:14] <NCommander> We normally only backport from the latest release
[00:14] <Hobbsee> right, yes.
[00:14] <NCommander> We need a new upstream to fix the bug
[00:14] <NCommander> The new upstream is in sid
[00:14] <NCommander> you can see where this is going
[00:14] <Hobbsee> if the next release is impossible to put things in, then just backport it regardless, and push it to intrepid when you can.
[00:14] <Hobbsee> IIRC, that was the policy previously
[00:14] <RAOF> TheMuso: I did at one point.  I can do so again this evening.  It's probably attached to one or more of my PPA regression bugs, though.
[00:14] <Hobbsee> er, no, not intrepid.  jaunty.  whatever the release after this one is.
[00:14] <NCommander> We have bent the "Must be a packaged version" to do a backport rule before
[00:15] <NCommander> I'd like to avoid doing that if possible however
[00:15] <Hobbsee> NCommander: well, even after we release, it'll take a while for the toolchain stuff to be done, and the general archive to open.
[00:16] <NCommander> Hobbsee, ok, I'll talk to ScottK/jdong and see if we're willing to bend the rule in this case
[00:16] <TheMuso> RAOF: I'll have a dig first.
[00:16] <NCommander> I'm going to guess the general archive opening won't be for more like a month, right?
[00:16] <TheMuso> But later...
[00:17] <NCommander> (like second week of November)
[00:17] <Hobbsee> NCommander: they usually are.
[00:17] <Hobbsee> NCommander: and yeah, that's probably a reasonable estimate.
[00:17] <calc> Hobbsee: no 2.4.1 will be in intrepid final
[00:17] <NCommander> Ok
[00:17] <calc> Hobbsee: final is for most intents this thursday
[00:17] <Hobbsee> calc: ahhh
[00:17] <NCommander> I'll have to ask ScottK on bending the rule
[00:17] <Hobbsee> calc: i thought we delivered an rc of it now
[00:17] <calc> Hobbsee: and 3 days of shake out for 3.0 wouldn't be nearly enough
[00:18] <calc> Hobbsee: just in the ppa
[00:18] <Hobbsee> ah.
[00:18] <calc> Hobbsee: even with 2.4 in hardy it had major issues until a few months later
[00:18] <calc> Hobbsee: so i updated it with 2.4.1 later but that was a lot of work
[00:18] <Hobbsee> calc: fair enough.  I've just seen lots of people asking.
[00:19] <TheMuso> crimsun: any ideas as to how we can better solve 274124?
[00:19]  * calc is considering trying to get 2.4.2 in later with more fixes but that might not even fly
[00:19] <calc> Hobbsee: yep, been responding to the comments on the forum
[00:20]  * directhex empathises with calc, given past history with mono. except diff.gz is rather terrifyingly enormous for OOo
[00:20] <Hobbsee> calc: fun.  have you gone mad yet?
[00:20] <calc> Hobbsee: some of them are a bit crazy it seems
[00:20] <NCommander> Stupid question
[00:20] <NCommander> If we do a new upstream in an SRU or security, what is the versioning?
[00:21] <calc> Hobbsee: insisting that Debian has 3.0 in their main repo (its not it is in experimental)
[00:21]  * NCommander is trying to figure out how the versioning for this backport should be done
[00:21]  * directhex has been responding to mono 2.0 posts on the forum
[00:21] <NCommander> directhex, do you need any mono help?
[00:22] <directhex> NCommander, i need a merge, which should be the absolute final version for intrepid
[00:22] <NCommander> a merge from Debian?
[00:22] <directhex> NCommander, yeah. latest upload, 1.9.1+dfsg-4, includes a bunch of bug fixes including two security holes
[00:23] <directhex> NCommander, note the name in the 1.9.1+dfsg-4 changelog \o/
[00:23] <NCommander> Sounds like *fun*
[00:23] <NCommander> wait
[00:23] <NCommander> O_o?
[00:23] <Hobbsee> calc: hah.
[00:23] <NCommander> Why does that sound like its going to burn?
[00:24] <directhex> NCommander, http://svn.debian.org/viewsvn/pkg-mono/mono/trunk/debian/changelog?rev=3727&view=auto
[00:26]  * calc hopes the mono update doesn't blow up OOo ;-)
[00:27] <NCommander> directhex, that looks like loads of fun
[00:27] <calc> seeing as debian has been in freeze for a while i think it should be safe :)
[00:27] <directhex> calc, i can't think of any changes that would be harmful for libuno-cil
[00:27] <calc> ok
[00:27]  * ogra hopes the OOo upload doesnt blow up his lpia-linux build :P
[00:28] <calc> i remember before the packaging split surprised me :)
[00:28] <calc> ogra: >:-)
[00:28] <ogra> :)
[00:28] <directhex> calc, okay, advance warning then: jaunty will have a new mono package split
[00:28] <calc> directhex: ok that should be fine
[00:29] <calc> directhex: as long as it doesn't happen right before final freeze ;-)
[00:30] <directhex> calc, i don't have time to read the OOo build deps before bed, but i don't see any binary deps which will change after the new split
[00:31] <directhex> calc, you could sponsor my mono merge, y'know. it'd be neat!
[00:32] <lool> Hmm there is no daily-live for ppc
[00:34] <Riddell> cjwatson: needed a couple other fixes :-/ but seems to all work now running in multiple locales
[00:35] <directhex> see this tiny diffstat? it's a teeny tiny diffstat! http://launchpadlibrarian.net/18515040/mono_1.9.1%2Bdfsg-4ubuntu1.diffstat
[00:43] <calc> directhex: i have a fairly large merge to finish by tomorrow, sorry :(
[00:45] <Riddell> cjwatson: I'm assuming you've gone to bed so I've uploaded language-selector (and shall go to bed also)
[00:45] <directhex> calc, poo, never mind. i was hoping to avoid bugging pitti, but i really wanna make sure -4 gets in
[00:45] <RAOF> TheMuso: http://www.alsa-project.org/db/?f=dad977e638055d5d42e035221185e6c519cd3990 if you haven't already found it.
[00:45] <TheMuso> RAOF: thanks
[00:45] <asac> calc: will you do another upload for intrepid?
[00:46] <ogra> asac, he's only doing PPA uploads atm
[00:46] <directhex> calc, oh, one other thing. we have, as a packaging goal, complete elimination of mono merges for jaunty. syncing fo' life, y'all.
[00:46] <asac> calc: could you please fix the milestoned bug #272772 :)
[00:47] <asac> ogra: PPA only until jaunty?
[00:47] <calc> asac: yes
[00:47] <asac> calc: did you miss that bug above?
[00:47] <ogra> heh
[00:48] <calc> asac: er no i am doing another upload for intrepid tonight (hopefully unless i pass out)
[00:48] <calc> asac: i will include the abrowser fix in the upload tonight
[00:48] <asac> calc: ok. please remember to fix that bug. shouldnt be that hard ;)
[00:48] <asac> cool
[00:48] <asac> thanks a bunch
[01:07] <NCommander> jdong, ping
[01:14] <kirkland> slangasek: hey, i might need a hand with a PAM issue
[01:14]  * slangasek ducks and covers
[01:15]  * directhex shoves his mono merge bug under slangasek's cover
[01:15] <kirkland> slangasek: i'm trying to figure out if pam_ecryptfs is the culprit
[01:16] <kirkland> slangasek: hmm, okay, not an ecryptfs problem
[01:16] <slangasek> ummm ok :)
[01:17] <kirkland> slangasek: well, it occurs on a system without ecryptfs ;-)
[01:17] <kirkland> slangasek: intrepid system, non-root user, run "passwd"
[01:17] <kirkland> slangasek: enter an "incorrect" current password
[01:18] <kirkland> slangasek: passwd exits with "password updated successfully" even though it isn't (thankfully)
[01:18] <kirkland> slangasek: same thing if you enter two non-matching new passwords
[01:19] <slangasek> kirkland: bug #272232
[01:19] <kirkland> slangasek: excellent, thanks.
[01:19] <kirkland> slangasek: i think this is leading to some confusion on the pam_ecryptfs front
[01:19] <kirkland> slangasek: i'll point at that bug
[01:19] <slangasek> on my personal hit list for intrepid wrt the pam-auth-update stuff, I need to triage the bug state properly so it's on others' radar too
[01:20] <fbond> Hiya, pardon the attention getting, but I think it is deserved in this case.  I've just nominated it for Intrepid:
[01:20] <fbond> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/264019
[01:21] <fbond> Seems to be some bug in TCP that gets triggered somehow when using Verizon DSL.
[01:22] <kirkland> slangasek: okay, thankfully, pam_ecryptfs isn't re-wrapping the passphrase
[01:22] <kirkland> slangasek: my heart stopped for a few minutes back there ;-)
[01:23] <slangasek> kirkland: yes, I got /that/ part of the framework right, it's really just the error messages that we got wrong :)
[01:23] <kirkland> slangasek: :-D  thanks for that, at least
[01:36] <slangasek> fbond: could you please provide wireshark captures in pcap format, instead of text dumps?
[01:36] <TheMuso> RAOF: and its Realtek ALC660 is that correct?
[01:39] <RAOF> TheMuso: Yes.  The other one would be the USB speaker.
[01:40] <TheMuso> RAOF: yeah. Well the hda code supports your notebook with no problems so what causes the underruns I don't know yet.
[01:40] <slangasek> fbond: and I guess you're doing a manual test here, since this is an HTTP/1.0 request instead of HTTP/1.1...?
[01:41] <RAOF> TheMuso: Another data point might be that "pulseaudio -vvv" does not report the underruns unless there's a pavucontrol client connected.  The underruns happen regardless of the existance of pavucontrol.
[01:42] <fbond> slangasek: I can provide pcap files, sure.
[01:42] <fbond> I saved them.
[01:42] <TheMuso> RAOF: Right.
[01:42] <fbond> slangasek: Um, maybe wget uses HTTP/1.0?
[01:42] <fbond> slangasek: I did some manual tests, too, but I think those were with wget.
[01:42] <slangasek> wget might use HTTP/1.0 by default, I guess
[01:43] <fbond> Should I upload pcap files?
[01:43] <slangasek> well, no, I don't see any options to wget to specify the protocol, so that doesn't seem possible
[01:43] <slangasek> fbond: yes, please
[01:43] <fbond> slangasek: Okay, brb.
[01:44] <fbond> (Hoping my pr0n d/l cron job wasn't running then ;)
[01:48] <fbond> Ah, crap, one of them is 2MB.  Forgot to compress, sorry.  The last may be the most interesting, anyway...
[01:48] <fbond> slangasek: uploaded
[01:49] <fbond> Hm.  Wget appears to use HTTP/1.0.
[01:51] <slangasek> fbond: hmm, I didn't remember HTTP/1.0 supporting Host: headers at all... ohwell
[01:51] <slangasek> fbond: do you have a firewall configured on your Intrepid system?
[01:51] <slangasek> (i.e., does iptables -L -n return anything?)
[01:52] <fbond> slangasek: Just default policy accept on everything.
[01:52] <fbond> Default configuration.
[01:53] <fbond> I did try installing firestarter in an effort to correct the issue (didn't make any sense, but some users said it fixes things for them.  Didn't fix anything for me.  I wasn't sure if it did some iptables magic that might've been affecting things for them...)
[01:58] <slangasek> fbond: ok; what I see here when tracing a comparable test is fragmented packets being sent by the remote server (www.youtube.com)
[01:59] <nixternal> problems with drive encryption on install by chance? I am having issues
[01:59] <slangasek> fbond: and given that you don't see the same thing, it's likely that your router isn't passing them through
[02:09] <slangasek> fbond: ok, I've taken that bug as far as I can, I think; it's up to the kernel team to take it from there
[02:46] <fbond> slangasek: Thanks.  The issue at hand is that the problem only exists with 2.6.27.
[02:46] <fbond> I'm on 2.6.24 now and it does not exist at all.
[02:47] <fbond> (2.6.24 with intrepid userland)
[02:47] <fbond> You think it might be a library?
[02:47] <slangasek> no
[02:49] <fbond> slangasek: Okay, thanks for looking into this.  I think it may be a serious issue.  I've added one more comment.  I hope the kernel team is able to find the problem.
[03:05] <TheMuso> slangasek: re 274124 I am not sure what more can be done at this point. The only thing I could do is wrap pulseaudio in a script to either prevent it from loading if something is using a sound device, or make it wait and load when the device is free. Other ideas are welcome.
[03:06] <slangasek> TheMuso: I think the latter is Obviously Correct, but maybe there's some reason you don't?
[03:07] <TheMuso> slangasek: The problem here is that pulseaudio detects sound devices on load, and a user may have more than one, so the script would have to check all devices. Even then since it seems pulse behaves weirdly when it tries aaaato connect to a device and fails, I am not sure if that script will help.
[03:24] <crimsun> TheMuso: (sorry, just returned from class.)  What was the rationale for --disable-pulse --enable-alsa being used as libcanberra-0.6's extra configure flags?
[03:24] <TheMuso> crimsun: pulse 0.9.11 or greater is needed for canberra.
[03:37] <crimsun> TheMuso: ah, right.  Yeah, busy-waiting isn't the approach I'd recommend, either, so I'll have to give your proposed steps a try here in a bit.
[03:38] <TheMuso> crimsun: Ok. The pulse-session wrapper is needed due to the way thigns are started in /etc/X11/Xsession.d, and I wanted pulse to be run after the dbus session is started.
[03:38] <lifeless> does lennart use pulse yet ?
[03:38] <TheMuso> lifeless: I believe so.
[03:38] <lifeless> it should improve soon then :P
[03:39] <slangasek> TheMuso: ok, I've tried putting pulseaudio into the X11 session here as you suggested in the bug, and it worked
[03:40] <slangasek> TheMuso: but I still have concerns that we're only reducing a race, not solving it
[03:41] <TheMuso> slangasek: I understand, however due to the way GNOME starts up, there is the potential for a lot of race conditions in general, and afaik there is no reliable way to get a signal from pulseaudio to say "I'm started, go ahead". If there was, I'd get the login sound playback to wait for that signal before it does anything.
[03:42] <slangasek> TheMuso: no, the point is that each component should be /resilient/ in the face of races
[03:42] <TheMuso> Since gnome now uses desktop files in a couple of locations to start things, there doesn't really appear to be a reliable way to have one startup item be a dependency for another.
[03:42] <slangasek> unless there's specifically a reason that it's also wrong for these other bits to start before pulse is running
[03:47] <TheMuso> slangasek: Point taken, but as far as I understand things re the GNOME startup process, short of not using pulseaudio at all, there is no way the libcanberra login sound startup item can know that pulse is ready. Things however will be much better for jaunty, as we can build libcanberra with pulseaudio support only, which will require it to wait for pulseaudio.
[03:47] <TheMuso> Unless crimsun has any other ideas to make things more resilliant.
[03:48] <crimsun> TheMuso: not really any more (hence my first question regarding libcanberra0.6)
[03:48] <slangasek> why does libcanberra need to know pulse is ready?  I don't see why pulse isn't doing a better job of recovering if the device is in use when it starts up
[03:51] <TheMuso> Newer version of pulse may recover better than 0.9.10 does. I'll dig through upstrea git, but I don't remember seeing anything in the logs about improving such behavior.
[04:00] <TheMuso> slangasek: Because the race here is caused by libcanberra playing a sound, and pulseaudio is either not fully loaded enough to receive the audi ofrom the alsa pulse plugin and play it, or its not loaded at all. What makes this extra difficult is that on all my machines, the race condition never seems to eventuate to where pulse cannot load properly.
[04:01] <TheMuso> so fixing pulse is whats needed, I'll see what I can find.
[04:01] <slangasek> so I think you should be able to reproduce this by: 1) kill pulseaudio, 2) play a long sound with aplay, 3) start pulseaudio again
[04:02] <slangasek> I haven't tested this, but that seems to be the race in question, and I think pulseaudio should be made robust in the face of it
[04:04] <sbeattie> slangasek: dumb question time: what's the procedure for getting uninstallable packages out of the archive? e.g. xserver-xorg-video-unichrome wlassistant
[04:04] <slangasek> sbeattie: file a bug on the package requesting removal, subscribe the sponsors team for the corresponding archive component if needed, subscribe ubuntu-archive if not
[04:05] <sbeattie> slangasek: okay, thanks, will do.
[04:05] <TheMuso> slangasek: thats what I'm doing now.
[04:06] <crimsun> right, my test case has been running aplay -Dplug:hw:0 foo.wav in a loop on tty1 and logging in to GNOME
[04:07] <crimsun> in that case, pulseaudio --fail does not fail catastrophically, which is also a problem
[04:10] <TheMuso> crimsun: Right. Just checking a log I made here, pulse doesn't try again to connect to an audio sink if it didn't succed in finding one on the first go.
[04:10]  * slangasek nods
[04:12] <TheMuso> The fun bit is finding where in pulse we need to tell it to try again.
[04:12] <slangasek> TheMuso: I would propose that you tell it to try again when it receives a new client request
[04:13] <TheMuso> slangasek: My thoughts as well.
[04:52] <TheMuso> Well, the same bug exists in 0.9.13, but instead of doing nothing, 0.9.13 has a null sink that gets used if other sinks are not available.
[05:02] <NCommander> Hey TheMuso
[05:37]  * calc remembered to write the mimetype identification for Microsoft files :)
[05:59] <sbeattie> hrm, anyone know why libfile-temp-perl got removed? libmime-tools-perl depends on it, and a few things depend on that, etc.
[06:02] <slangasek> because it's obsolete and people were trying to fix the libmime-tools-perl dep but there was a build failure if I've distilled IRC correctly
[06:05] <sbeattie> ah, okay, as long as its already known. thanks.
[06:07]  * StevenK tries to find run-init
[06:08] <StevenK> Since this device booting jumps out of the initramfs and seems to hang.
[06:09] <ScottK> Hobbsee fixed it.
[06:09] <ScottK> Err Hobbsee changed it to avoid a brain dead area of Soyuz.
[06:15] <calc> one last bit to fixup then final OOo 2.4.1 test build :)
[06:21] <calc> is there a /usr/lib/abrowser/plugins dir?
[06:34] <dholbach> good morning
[06:36] <evand> good morning dholbach
[06:36] <dholbach> hi evand
[06:40] <NCommander> ScottK, so now what? (w.r.t to the backport)
[06:41] <ScottK> NCommander: I'm gonna upload it.
[06:41] <NCommander> Cool :-)
[06:41] <NCommander> Its in the PPA to save you some work
[06:42] <ScottK> It's just a debian/changelog entry, so I just grabbed it from Debian.
[06:43] <NCommander> Oh ;-)
[06:44] <ScottK> Uploaded.
[06:44] <calc> uploading openoffice.org 1:2.4.1-11ubuntu1 now
[06:44] <NCommander> \o\ /o/ :-)
[06:44]  * calc prays it builds properly on all working archs
[06:44]  * NCommander watches it FTBFS on hppa just to spite you
[06:45] <calc> NCommander: it definitely will on hppa
[06:45] <calc> NCommander: it doesn't support hppa at all, configure fails
[06:45] <NCommander> O_o;
[06:45] <NCommander> OpenOffice supports m68k o_o;;;
[06:45]  * calc is hoping this build will pass on ppc though
[06:45] <calc> NCommander: yea, i'm not exactly sure why it hates hppa, haven't taken the time to look into why
[06:46] <NCommander> We even managed to build it on m68k
[06:46] <calc> probably it works on m68k because someone bothered to fix it ;-)
[06:47] <calc> now i get to work on taxes :\
[06:49]  * calc wants to sleep instead of doing taxes :\
[06:49]  * ScottK high fives calc.
[06:49] <ScottK> calc: I'm mailing mine tomorrow too.
[06:50] <calc> i have until jan but i don't know if they extended the stimulus checks for texas also
[06:50] <calc> so i am filing tomorrow to be safe
[06:54] <ScottK> Ah.  Well I had until tomorrow.
[07:05] <ScottK> slangasek: If you're still around, it's be nice if you would accept kdesvn in hardy-backports.
[07:26] <sten_> hi.  I'm trying to semi-automate adding debian/changelog info.  Any pointers?
[07:26] <sten_> (cat leaves EOF markers which break dpkg-buildpackage)
[07:27] <evand> dch?
[07:28] <StevenK> Yeah, dch will can do it semi-automatically
[07:28] <StevenK> s/will //
[07:28] <RAOF> s/semi-//
[07:28]  * RAOF uses dch from a script for nouveau.
[07:28] <slangasek> calc: didn't build with -v1:2.4.1-9ubuntu2?
[07:28] <sten_> ahh.  I figured someone would have already written something!  Thanks!  (in ignorance, some of us end up trying to re-invent the wheel)
[07:30] <slangasek> ScottK: done
[07:32] <liw> sten_, what are "EOF markers"?
[07:38] <NCommander> Is anyone here a Linux kernel guru?
[07:38] <dholbach> NCommander: #ubuntu-kernel
[07:39] <NCommander> ooh
[07:39] <NCommander> handy
[07:41] <sten_> liw: End Of File.  I was using a combination of cat, cut, and sed (and maybe awk...but I don't remember, since I haven't looked at the code in months, and I just deleted it)
[07:41] <sten_> liw: anyways, this produces and EOF in the middle of a file, apparently:
[07:42] <sten_> liw: echo "This is normal text" > orig.txt ; echo >> orig.txt ; echo "This is line 3 of normal text" >> orig.txt
[07:42] <sten_> liw: then,
[07:43] <sten_> liw: echo "This is going to be pre-pended text" > additions.txt
[07:43] <pitti> Good morning
[07:43] <sten_> liw: and finally, cat additions.txt orig.txt > newfile.txt
[07:44] <sten_> liw: dpkg-buildpackage fails, due to the EOF at the end of additions.txt, which gets place in the middle of the newfile.txt, between additions.txt's text and orig.txt's text (there should only be one EOF, and it should actually be at the end of the file!)
[07:45] <liw> sten_, er, I don't think things work the way you think they do. unix does not have an "end of file marker", it keeps track of the length of a file and does not use a marker of any kind
[07:45] <slangasek> sten_: I'm afraid you're mistaken, that command will not produce an EOF where you suggest it does
[07:45] <sten_> liw: (of course, I was mucking with the changelog.  It's really nice to know about "dch" :-)
[07:46] <sten_> slangasek, liw: then why does dpkg-buildpackage fail with this output?
[07:46] <liw> sten_, http://paste.ubuntu.com/57761/
[07:46] <slangasek> I don't know, your example text isn't exactly a valid changelog entry
[07:46] <liw> sten_, I think you did something else that went wrong
[07:47] <liw> sten_, anyway, I'm glad you find out about dch
[07:47] <slangasek> indeed, dch is Happy
[07:50] <sten_> yup, :-)  I'm not even going to bother with the strange, illogical debugging process I've been taking a look at every few weeks or so (seriously, it didn't make sense.  I also didn't think that unix had EOF markers for normal files -- mind you, I'm quite familiar with them when using tape...)
[07:51] <StevenK> pitti: I note you marked bug 281144 as a dupe, removed source and binaries for bluez-libs, but didn't remove source for bluez-utils
[07:52] <pitti> StevenK: argh, that would be me not being able to read
[07:52]  * StevenK removes it
[07:52] <pitti> StevenK: thanks
[07:54] <sten_> I know it's not a bug, because modifying /etc/modprobe.d/aliases causes it, but I've noticed that gnome no longers starts unless the ipv6 module is allowed to autoload.  Does anyone know why this might be?
[07:58] <sten_> (steps to replicate: change ipv6 on L11 to off, reboot, attempt to start a gnome session)
[07:59] <StevenK> pitti: Looks like libflashsupport and kio-sword still want libgnutls13. kio-sword just needs to be pulled out from ichthux-desktop and it can get killed.
[08:00] <StevenK> pitti: I'm not sure what to do about libflashsupport -- some people say kill it, and others say it is useful.
[08:01] <slangasek> wasn't there discussion about libflashsupport being the cause of all flash crashes everywhere?
[08:01] <slangasek> and/or conflicting with pulseaudio?
[08:03] <pitti> slangasek: can you please commit your hal change to bzr?
[08:03] <slangasek> oops
[08:04] <slangasek> yes, sorry
[08:04] <StevenK> slangasek: That's what I've heard. But I've heard others say it makes Flash work with Pulse ...
[08:04] <StevenK> So, I'm fairly confused about it.
[08:06] <pitti> StevenK: I don't know about libflashsupport, I'm afraid; I think we shuold ask ogra
[08:07] <StevenK> pitti: Sounds good to me, I need to ask him about the lpia kernel, too
[08:10] <slangasek> pitti: done
[08:11] <pitti> slangasek: thanks
[08:19] <slangasek> hrm; how did pwlib build prior to the latest upload, given that it depends on libdc1394-13-dev in universe?
[08:23] <StevenK> slangasek: libdc1394 was demoted on the 26/07/2008
[08:23] <slangasek> StevenK: ah, where do you see that?
[08:23] <StevenK> slangasek: https://edge.launchpad.net/ubuntu/+source/libdc1394/1.1.0-5ubuntu1
[08:24] <StevenK> slangasek: Specifically, the Superseded section with "Removal requested  on 2008-07-27. "
[08:24] <StevenK> Er, rather "Superseded  on 2008-07-26  by libdc1394 - 1.1.0-5ubuntu1"
[08:24]  * StevenK glares at his mouse
[08:24] <slangasek> ah, yes
[08:25] <StevenK> Pity it doesn't tell who changed the overrides. :-)
[08:25] <slangasek> yeah :/
[08:25] <slangasek> not that any of us are likely to remember now the reason :)
[08:25] <slangasek> well, the build-dep is probably expendable anyway, from what I see
[08:25] <pitti> maybe it just appeared in component-mismatches and we demoted it en masse?
[08:26] <pitti> if it previously was in main, there shouldn't be a problem just promoting it back
[08:26] <StevenK> pitti: Speaking of component-mismatches, how does one go about fixing some of that stuff?
[08:26] <pitti> StevenK: main -> universe can "just be done"
[08:26] <slangasek> pitti: AFAICS it should never have appeared in component-mismatches since pwlib build-depended on it continuously
[08:26] <slangasek> but I think that b-d can be scrapped, checking
[08:27] <pitti> StevenK: universe -> main is a mixed thing; watching for MIRs, fixing packages to not need them, or dropping main packages which pull in a lot of stuff
[08:27] <slangasek> ah, it is needed, the plugin package it builds just winds up in universe
[08:27] <slangasek> so yes, I'll re-promote it to main
[08:30] <slangasek> ogra: I don't remember now what needed to be done for rasmol, but it's still dep-wait in intrepid...
[08:30] <StevenK> pitti: Some the main -> universe looks due to no reason for staying in main. I'm a little retiscent to demote stuff that I know either I or someone else worked hard to get into main in the first place. :-)
[08:31] <slangasek> if it's supposed to be in main, it should've been seeded by now
[08:31] <StevenK> usb-creator is in main, and is "supposed" to be.
[08:32] <StevenK> bluez-utils erroneously appears, but that has to wait for a britney run
[08:33] <StevenK> Reverse-Depends: Rescued from sendmail]
[08:33] <StevenK> The hell? Like sendmail is in main anyway
[08:34] <slangasek> the source is (libmilter)
[08:34] <StevenK> Oh, eeek.
[08:36] <StevenK> Actually, britney is a little confused. a52dec is listed for main due to gstreamer-plugins-ugly, which source and binaries are in universe
[08:37] <pitti> StevenK: also, please NB that some of the main->universe are not justified, because they are in the mobile seed
[08:37] <pitti> StevenK: like midbrowser
[08:37] <StevenK> The mobile seed is in universe
[08:38] <slangasek> StevenK: it's transitive, and something else wants gst-plugins-ugly0.10 (elisa)
[08:38] <pitti> StevenK: oh, I thought you wanted those packages in main for langpacks, or so?
[08:38] <StevenK> pitti: It's a long story
[08:38] <pitti> StevenK: is the result "they are fine in universe"?
[08:38] <slangasek> StevenK: and I'm pretty sure that's not britney...
[08:39] <StevenK> pitti: The result is "They can stay where they are for the moment"
[08:39] <StevenK> slangasek: I was wondering if it was britney or annastacia
[08:39] <pitti> StevenK: hm, then we need to teach britney about the mobile seed
[08:39] <slangasek> StevenK: britney doesn't know anything about germinate
[08:39] <pitti> StevenK: otherwise it's just too easy to accidentally demote either those or (less obvious) one of their dependencies
[08:41] <StevenK> Hmmmm. I see that. elisa is the cause of a lot of c-m stuff
[08:41]  * slangasek drops off for a bit of sleep
[08:51] <bigUSA> Ïðèâåò âñåì.
[08:52] <bigUSA> Ñêàæèòå, ó êîãî ïîëó÷èëîñü ñäåëàòü êóá è 4 îòäåëüíûõ ðàáî÷èõ ñòîëà?
[08:56] <pitti> mvo: hi
[08:56] <pitti> mvo: did I see the "u-m must revert fglrx migration" bug I threw at you last night?
[08:57] <mvo> pitti: yes, I talked with bryce_ about it, I upload the revert soon
[08:57]  * pitti hugs mvo, thanks
[08:57] <mvo> cheers
[08:57] <bryce_> mvo, thanks :-)
[08:59] <jibel> pitti: Hi
[09:00] <jibel> pitti: I don't think 256131 is fixed. There's still an issue because of the order in which scrollkeeper / xml-core are uninstalled/installed
[09:00] <jibel> bug 256131
[09:00] <pitti> jibel: I know
[09:01] <pitti> jibel: that's why the rarian task is still open; I need some feedback on ubuntu-devel@ on it
[09:02] <jibel> oh, ok.
[09:17] <davmor2> mvo: there are lots of dupes of the screensaver bug coming in :(
[09:19] <mvo> davmor2, meh, ok
[09:20] <mvo> davmor2, when you do the next install test, would you watch out for the control-center issue again? I uploaded a new plugins-extra package that should fix it
[09:23] <Koon> mvo: it's juste the merge of the other bug you were assigned to. I merged them into the one that has been nominated for intrepid release
[09:23] <davmor2> mvo: this morning after I drop my wife off at a meeting so np's there
[09:26] <mvo> Koon, thanks, did you do some bug triage on the screensaver bugs? or did you ran accross it yourself?
[09:26] <Koon> mvo: I ran accross it myslef, found the two bugs and merged them
[09:27] <Koon> mvo: do you already have an idea how to fix it or are you still searching ?
[09:29] <mvo> Koon, no idea, ogra  did some tests and thinks dpms is probably mixed in, but I haven't found time to look into it properly
[09:29] <mvo> Koon, what video card/driver do you use?
[09:29] <mvo> for me it went away after upgrading to compiz 0.7.8
[09:30] <Koon> upgrading to 0.7.8 doesn't fix it for me, as well as xset -dpms. I have to uncheck "unredirect fullscreen windows" in compiz config
[09:31] <Koon> I have it both on my laptop (Intel X3100) and my workstation (nvidia 8xxx)
[09:32] <mvo> Koon, ok, thanks
[09:33] <Koon> mvo: if you can't reproduce it, don't hesitate to ping me for any test you may require
[09:34] <mvo> Koon, thanks, will do
[09:36] <Hobbsee> ScottK: well, I *tried* to fix it.  Then managed to somehow get an interesting dpkg error.
[09:39] <sbeattie> mvo: I commented on bug 282830; update-manager is still failing for me in that VM despite apt-get dist-upgrade -y working.
[09:40] <mvo> sbeattie, ok, good (or bad) - that narrow the problem down a bit, I check it out and sent you debug patches
[09:41] <sbeattie> mvo: cool. it will probably have to wait a few hours, I need to sleep soon.
[09:41] <tseliot> mvo: did you have a look at this (and at Aaron Plattner's solution)? https://bugs.launchpad.net/ubuntu/+source/compiz/+bug/269904
[09:41] <mvo> sbeattie, sure, it must be really late in your TZ
[09:43] <mvo> tseliot, no thanks for pointing it out
[09:43] <tseliot> mvo: I think it's something worth having ;)
[09:44] <mvo> tseliot, yeah, I need to check how complete it is before adding it
[09:44] <tseliot> ok
[10:00] <liw> hmm. I get a notification that my quit button can be replaced by the new thing. but I don't have a quit button. shouldn't the updater check for that?
[10:01] <seb128> liw: it'll tell you that you don't have the applet and that you need to update the configuration
[10:02] <liw> seb128, what configuration is that? (I already told it not to bother)
[10:02] <seb128> those are question for mvo ;-)
[10:03] <seb128> but right the migration tool is not really smart right now
[10:03] <seb128> I think it doesn't verify if the switch user applet is installed either before adding it
[10:03] <liw> I admit that I'm probably an unusual case for removing the quit button in the first place
[10:03] <mvo> liw, its pretty difficult to do that (check for it before showing the notification) because the notification is created with a postinst thing that can't easily look into the users gconf
[10:04] <mvo> liw, so while we could do it with some extra work so far I stayed away from it assuming it would be somewhat unusual
[10:04] <liw> mvo, what change does it do if one presses the update button?
[10:05]  * mvo thinks we could have made all of this better and more clever if it came up a little bit earlier in the release process
[10:05] <mvo> liw, it moves the fast-user-switch applet to the top right corner and removes the quit button object
[10:07] <liw> mvo, how does it do that? that still requires talking to the users gconf, doesn't it?
[10:09] <mvo> liw, yeah, its a two stage process. the notification is generate during the postinst of the gnome-panel (on upgrade) and copied into /var/lib/update-notifier/user.d - that is a directory where update-notifier checks for user notification that are releated to package upgrades. they are shown for each user and can have scripts attaached to them
[10:10] <mvo> liw, htere is a InteractiveUpgradeHooks wiki page with more information
[10:10] <mvo> liw, its a somewhat underutilized feature, but quite useful for cases like this
[10:11] <TomaszD> pitti, hey. People from #launchpad forwarded me to you, could you check what is wrong with cheese's translation template? no pending updates, last ones failed months ago.
[10:12] <pitti> TomaszD: you mean the package doesn't build one/
[10:12] <pitti> ?
[10:12] <TomaszD> pitti, https://translations.launchpad.net/ubuntu/intrepid/+source/cheese/+imports
[10:12] <pitti> Building cheese.pot...
[10:12] <pitti> the package seems to be fine
[10:12] <seb128> "Wrote cheese.pot"
[10:13] <seb128> right, the build log suggests it builds it correctly
[10:13] <pitti> TomaszD: right, that seems to indicate that the help templates are not imported (since they aren't shipped in langapcks); that seems to be correct?
[10:14] <TomaszD> hmm, seems to be working fine indeed
[10:14] <TomaszD> sorry for the false alarm
[10:14] <TomaszD> I've got just one more package to check
[10:15] <TomaszD> bluez-gnome
[10:15] <TomaszD> there is this new version out, templates approved 8 days ago
[10:15] <TomaszD> but still not uploaded
[10:15] <TomaszD> is this something of concern
[10:15] <TomaszD> or just patience?
[10:19] <TomaszD> pitti, ?
[10:20] <seb128> TomaszD: that would be a rosetta question
[10:20] <pitti> TomaszD: latest intrepid packages are from a 20081011 export, so it might just have missed it
[10:20] <seb128> TomaszD: if the build update the template the ubuntu job is done basically
[10:22] <TomaszD> oh, but did the build update the template? how can I be sure?
[10:25] <seb128> TomaszD: look to the build log?
[10:25] <seb128> TomaszD: http://launchpadlibrarian.net/18301573/buildlog_ubuntu-intrepid-i386.bluez-gnome_1.8-0ubuntu1_FULLYBUILT.txt.gz
[10:26] <TomaszD> well it did update the template
[10:26] <TomaszD> lp can be really terrible to navigate
[10:28] <tseliot> liw: see if you can test what I suggested here (I talked to mvo about this): https://bugs.launchpad.net/ubuntu/+source/linux-restricted-modules-2.6.24/+bug/278963
[10:28] <lool> tjaalton: Hey, I see we have xserver-xorg-video-openchrome 1:0.2.903-0ubuntu2, but I don't see any ubuntu branch in git.debian.org:/git/pkg-xorg/driver/xserver-xorg-video-openchrome.git
[10:28] <lool> tjaalton: perhaps you need to push the new branch explicitely?
[10:29] <liw> tseliot, yeah, I will. I'll start the upgrade once I don't need the desktop machine anymore today (tonight at the latest)
[10:29] <jcristau> lool: not all the ubuntu xorg stuff is in git. i think openchrome isn't
[10:29] <tseliot> liw: thanks a lot :-)
[10:29] <lool> ok, it has a vcs-git though
[10:31] <liw> tseliot, argh, no, I forgot: I had some hardware trouble (a case's power button broke), so I had to swap hard disks to another computer; I'll fix the original computer and then re-try the test (still hopefully tonight, but might only happen tomorrow)
[10:31] <lool> ah, I kept xserver-xorg-video-via on upgrades but it's not built in intrepid anymore
[10:33] <liw> (hardware is the nemesis of progress)
[10:33] <tseliot> liw: ok, thanks
[10:47] <NCommander> morning seb128
[10:47] <seb128> hello NCommander
[10:47] <NCommander> seb128, how goes it?
[10:47] <seb128> NCommander: got a cold but other good, you?
[10:47] <NCommander> seb128, celebrating my 50th upload to the archive :-)
[10:47] <seb128> good ;-)
[10:47] <seb128> time for motuing? ;-)
[10:48] <Koon> mvo: about the screensaver issue, reenabling something equivalent to your sledgehammer.diff from bug 145123 fixes it here.
[10:48] <NCommander> I've been told to wait for DIF Jaunty
[10:48]  * NCommander will be at UDS it seems
[10:48] <seb128> NCommander: oh, I though you couldn't go to this one?
[10:48] <NCommander> I managed to clear my schedule
[10:48] <mvo> Koon, possible, if I can not come up with a better solution, its time for the sledgehammer again :)
[10:48] <Koon> mvo: will post fix and PPA it for more testing if you want
[10:48] <NCommander> After someone (and I have no idea who) put me down on the list for sponsorship
[10:49]  * NCommander managed to call in a last minute favor
[10:49] <mvo> Koon, could you show me the diff please?
[10:50] <NCommander> seb128, so yes, I'll be at UDS :-). I look forward to meeting you and the rest of ubuntu-*
[10:50] <NCommander> and kubuntu-* and xubuntu-*
[10:50] <seb128> NCommander: good ;-)
[10:50] <ogra> mvo, Koon, either xset -dpms, reoving gpm or switching off the mentioned compiz setting fixes the issue
[10:50] <Riddell> NCommander: great
[10:50] <Koon> ogra: xset -dpms doesn't fix it here
[10:51] <Koon> (or I missed something)
[10:51] <pitti> tkamppeter: sorry, I forgot the status about that: does openprinting.org have any packaged PPD files?
[10:51] <ogra> Koon, bug 278112, right ?
[10:51] <directhex> dholbach, can you check the integrity of your /tmp? i've run amd64 intrepid builds of mono on multiple systems without seeing the error you mention
[10:51] <Koon> ogra: yes
[10:52] <asac_> calc: thanks for the abrowser fix
[10:52] <ogra> Koon, intel graphics ?
[10:52] <dholbach> directhex: what do you want me to test?
[10:52] <Koon> ogra: or nvidia.
[10:52] <dholbach> directhex: /tmp seems to be working nicely
[10:54] <directhex> dholbach, what's the md5sum of the mono-1.9.1+dfsg/mcs/mcs/cs-parser.jay being used for that build? i really can't reproduce a build failure
[10:54] <Koon> mvo: for the diff, just a sec
[10:54] <dholbach> directhex: let me try it again, will let you know in a sec
[10:55] <Koon> mvo: http://pastebin.ubuntu.com/57826/
[10:55] <mvo> Koon, heh :) ok- thanks
[10:56] <Koon> it's just a refresh of your old sledgehammer :)
[10:56] <mvo> yeah
[10:56] <mvo> I remember that one
[10:56] <Koon> will post it as proper debdiff on the bug + PPA it so that people on the bug can test it
[10:56] <mvo> the original bug (in X) that made it required in the first place got fixed
[10:56] <mvo> Koon, excellent, thanks
[10:57] <tjaalton> lool: it's not in git at all
[10:58] <tjaalton> lool: our changes to openchrome I mean
[11:02] <tkamppeter> pitti, packaged PPD files will come soon, at least one manually created package. Have you any preference of printer brand?
[11:03] <ogra> Koon, mvo, for me the prob happens with gnome-screensaver uninstalled as well
[11:03] <mvo> ogra, intel?
[11:03] <ogra> yep
[11:04] <ogra> unchecking the option in gnocf helps though
[11:04] <ogra> *gconf
[11:04] <ogra> as well as xset -dpms (which doesnt seem to help Koon though)
[11:08] <doko> bryce_, tjaalton, infinity: any idea why xfb-run fails on the buildds on sparc and powerpc? see the recent openjdk-6 build log
[11:10] <tjaalton> doko: I understand the new xorg-server that lool uploaded should fix that
[11:13] <jcristau> tjaalton: don't think so. it just makes error output work.
[11:14] <tjaalton> jcristau: ok
[11:17] <davmor2> mvo: \o/ Yay works Dude :)
[11:18] <mvo> davmor2, excellent!
[11:23] <lool> tjaalton: ok thanks
[11:25] <lool> tjaalton, bryce_: I moved the ppa-only xserver-xorg-video-psb to xsfbs; it now has correct provides, so wont need new special conflicts in the future; only the one I added is needed
[11:27] <dholbach> directhex: builds nicely now
[11:28] <directhex> dholbach, gremlins, then?
[11:29] <dholbach> directhex: no idea :)
[11:29] <mvo> davmor2, when you get tomorrows daily alternate CD, could you do a cdrom release upgrade with it please?
[11:55] <ogra> oh, pitti that gdm fix could also have pointed to gdm-cdd.conf as well :)
[12:00] <lool> ogra: hmm openchrome will need a Pas tweak unfortunately
[12:01] <lool> ah ECHAN
[12:01] <lool> tjaalton, bryce_: I synced the latest vars.i386 cleanup into vars.lpia, hence the new xorg upload
[12:02] <lool> (and I should be mostly done fiddling with xorg now  O:-)
[12:02] <lool> I might chase that xvfb issue on big endian arches now if qemu supports one, such as ppc
[12:06] <pitti> ogra: argh, too many files...
[12:06] <ogra> :)
[12:06] <ogra> pitti, well, not to important, i just saw the changelog entry
[12:09] <james_w> Keybuk: hi, bug 256216 looks sensible to me, am I missing something?
[12:12] <directhex> people run ubuntu on clusters?
[12:25] <lool> tjaalton, bryce_: dropping vcs-* from -intel as well, didn't find ubuntu branch in git.d.o
[12:25] <unggnu> hi all
[12:26] <unggnu> I just wanted to know if the Adobe Flash Ubuntu package is maintained through the Ubuntu devs and if so will it be considered while e.g. upgrading to Intrepid?
[12:26] <directhex> yes, yes, and wrong channel.
[12:26] <unggnu> It seems to have a different package naming than the standard one
[12:26] <unggnu> ok, thx
[12:33] <mvo> evand, so gobuntu-desktop is now gone in intrepid, right? what should the upgrader do for people who have it installed (and no other meta-package)?
[12:33] <kelemengabor> hi mvo
[12:34] <mvo> hey kelemengabor
[12:34] <kelemengabor> what's the schedule for publishing the ddtp descriptions's updates?
[12:34] <kelemengabor> I mean, tomorrow is non-langpack freeze
[12:35] <kelemengabor> and they will be published on the servers, but after that?
[12:36] <kelemengabor> we have currently lots of pending translations and would be really nice to see them later in Intrepid
[12:36] <kelemengabor> is there any public schedule/plan at all?
[12:40] <rainct> Will OO.o 3.0 from https://launchpad.net/~openoffice-pkgs/+archive get into Intrepid?
[12:42] <Hobbsee> rainct: not for release.
[12:44] <rainct> Hobbsee: and as an update? or hasn't that been decided yet?
[12:44] <Hobbsee> rainct: possibly.  currently undecided
[12:44] <rainct> Ah. Well, anyway, if some of the maintainers is around: I've been told that the Catalan translation of the documentation is missing
[12:44] <Hobbsee> calc: ^
[12:46] <lool> jcristau: Weird, there are two entries in Pas for xorg-intel: one for binary and one for source; not quite sure how this works to decide building sources
[12:49] <lool> Looks like launchpad and wanna-build have two different interpretations
[12:50] <tjaalton> lool: is it necessary to remove those tags?
[12:52] <ogra> oh, console-tools confolcts with ubuntu-minimal now ?
[12:52] <lool> tjaalton: I don't know; the !s390 entry looks funny if you ask me, but I filed a bug on soyuz
[12:53] <lool> bug #283731
[12:53] <BenC> cjwatson: linux-restricted-modules (sans firmware), linux-firmware and linux-meta (with linux-image-foo deps on linux-firmware) are being uploaded now
[12:54] <BenC> cjwatson: FYI, nic-restricted-firmware => nic-firmware
[12:55] <tjaalton> lool: I meant the Vcs-* tags :)
[12:56] <lool> tjaalton: Well we don't use this Vcs, so it's confusing for ubuntu developers; for instance apt-get source will complain, and debcheckout will do the wrong thing
[12:57] <lool> tjaalton: but if you ask me, we should just use git repos; would make merging painless
[12:59] <tjaalton> lool: yeah
[12:59] <liw> hmm, X has frozen twice for me today.
[13:00] <tjaalton> liw: fglrx?
[13:00] <liw> tjaalton, should not be, should be the free driver
[13:00] <tjaalton> liw: ok
[13:03] <liw> [mi] EQ overflowing. The server is probably stuck in an infinite loop.
[13:03] <liw> [mi] mieqEnequeue: out-of-order valuator event; dropping.
[13:03] <liw> tjaalton, there's a lot of that in Xorg.0.log
[13:04] <BenC> cjwatson: all uploads complete
[13:04] <BenC> cjwatson: linux-firmware is the only one that needs handling
[13:05] <tjaalton> liw: ok.. there's a patch which dumps the trace when that happens. would be better than nothing to aid debugging it
[13:05] <liw> tjaalton, can I do something before I reboot to regain control of the machine? (first time it happened, restart X did not help)
[13:05] <tjaalton> liw: probably not
[13:06] <liw> tjaalton, this patch, how would I use it?
[13:07] <tjaalton> liw: patch the server and build it
[13:08] <tjaalton> liw: http://cvs.fedoraproject.org/viewvc/devel/xorg-x11-server/xserver-1.5.2-mieq-backtrace.patch?revision=1.1
[13:08] <liw> tjaalton, ok, I'll give that a try later
[13:08] <tjaalton> liw: great, thanks
[13:10]  * ogra doesnt understand ow he can end up having console-tools, console-setup and kbd installed at the same time on his laptop
[13:11] <ogra> trying to install conaole-setup and -tools on a thin client results in removal of kbd :/
[13:12] <ogra> hmm, and installation of libconsole
[13:12] <Hobbsee> ogra: you installed them all before the conflicts were set?
[13:12] <ogra> when did that hapen ? the client build is from friday
[13:12]  * ogra checks -changes
[13:13] <ogra> no
[13:15] <cjwatson> BenC: thanks
[13:15] <ogra> my prob is that recommends break the thin client chroots so it omits them, apparently the console stuff is resolved through recommends normally
[13:15] <cjwatson> ogra: the conflicts were set eons ago
[13:15] <cjwatson> ogra: also, ubuntu-minimal Depends: kbd, not Recommends
[13:15] <ogra> cjwatson, right, but i dont get why i have all three installed on my laptop and am not able to install them on a thin client
[13:15] <cjwatson> ogra: I don't get how you have them all installed on your laptop; the latter is expected
[13:16] <cjwatson> hardy => console-setup + console-tools; intrepid => console-setup + kbkd
[13:16] <cjwatson> kbd
[13:16] <ogra> ooooh
[13:16] <ogra> illy me
[13:17] <ogra> i looked at the initscripts :)
[13:17] <cjwatson> ah
[13:17] <cjwatson> purge console-tools ;-)
[13:17] <ogra> yeah
[13:30] <cjwatson> mvo: excuse my command-not-found upload, just trying to hoover up some bugs I found
[13:30] <cjwatson> it's all in bzr
[13:31] <mvo> thanks cjwatson
[13:32] <stefanlsd_> mm. i wish people did specific vcs commits more often.
[13:32] <rainct> mvo: btw, a  try: .. except KeyboardInterrupt: sys.exit(1)   in command-not-found wouldn't hurt :P
[13:33] <stefanlsd> trying to pull security updates out of a commit which includes a bunch of feature stuff.
[13:44] <emgent> hello
[13:45] <rainct> hi emgent
[13:45] <cjwatson> seb128,pitti: did either of you have any thoughts about my proposal to turn totem content acquisition plugins on by default?
[13:46] <pitti> cjwatson: I don't think I saw that proposal?
[13:47] <cjwatson> pitti: sent by mail
[13:48] <cjwatson> Subject: Re: BBC: New code drop?
[13:48] <seb128> cjwatson: only if the download happens when selecting the plugin in the combo and not when totem starts
[13:48] <cjwatson> on Fri 10
[13:48] <cjwatson> seb128: right, Collabora are going to be working on that RSN
[13:48] <cjwatson> seb128: is it feasible/sane/acceptable otherwise?
[13:48] <cjwatson> I agree that ought to be a blocker
[13:49] <pitti> argh kyboard fail, rboot, brb
[13:49] <seb128> cjwatson: I forget to reply to the mail, I was in a rush before the weekend and it forgot to keep it unread to reply then
[13:49]  * cjwatson nods
[13:49] <seb128> cjwatson: but otherwise I agree with what you wrote
[13:49] <cjwatson> good thing I checked if pitti didn't see it though :)
[13:49] <seb128> cjwatson: I think it's a good idea if they manage to fix that
[13:53] <cjwatson> seb128: is it a fairly trivial switch to flip in gconf?
[13:56] <seb128> cjwatson: add a debian/totem-common.gconf-defaults which has "/apps/totem/plugins/bbc/active true"
[13:57] <cjwatson> and youtube presumably
[13:57] <cjwatson> ok
[13:57] <evand> mvo: tough call as they wont want any non-free software
[13:57] <seb128> cjwatson: right
[13:57] <cjwatson> mvo: ask them if they want to disable restricted if it isn't already, maybe? install abrowser rather than firefox?
[13:57] <ogra> hmm
[13:58] <seb128> cjwatson: btw the bbc plugin displays a "could not connect to server" in the playlist at the moment for me, is that a known issue?
[13:58] <evand> mvo: but I guess we shouldn't leave them in a poor state, so perhaps s/gobuntu-desktop/ubuntu-desktop?
[13:58] <ogra> why is discover1 in main (or discover-data in universe) ?
[13:58] <cjwatson> seb128: worked for me just now
[13:58] <ogra> discover1 Depends: discover1-data
[13:58] <ogra> oh
[13:59] <ogra> sigh, i guess i need glasses
[13:59] <seb128> cjwatson: do you use the same server is the uk that in other countries?
[13:59] <cjwatson> ogra: http://people.ubuntu.com/~ubuntu-archive/germinate-output/ubuntu.intrepid/rdepends/ALL/discover1 says ltsp-client-core
[13:59] <cjwatson> oh, you meant that, ok
[13:59] <ogra> is that all thats keeping it in main ?
[13:59] <cjwatson> ogra: yes
[13:59] <ogra> do we want to get rid of it ?
[13:59] <cjwatson> seb128: yes, any filtering is supposed to be handled server-side by geoip
[13:59] <cjwatson> ogra: if possible, yes
[14:00] <ogra> i think its only there because mdetect used to use it
[14:00] <pitti> argh, e ky is still brokn
[14:00] <seb128> 0:00:01.897669340  7415  0x80a4490 WARN                python contentview.py:672:_query_done_cb: Could not query http://open.bbc.co.uk/rad/uriplay/availablecontent: Error while getting mount info: Invalid reply
[14:00] <mvo> evand, hm, I may just do that
[14:00] <seb128> 0:00:01.897778225  7415  0x80a4490 WARN                python contentview.py:793:_on_content_pool_error: Failed to load available content: Could not connect to server
[14:00] <seb128> cjwatson: that the gstreamer debug log
[14:00] <pitti> cjwatson: I didn't s33 it, I wond3r wh3r3 it w3nt, looking
[14:01] <seb128> oh
[14:01] <cjwatson> seb128: can you open that url in a browser?
[14:01] <cjwatson> it should be a pile of rdf
[14:01] <davmor2> mvo: afk.  Any preference on what from hardy/gutsy/dapper for the upgrade?
[14:01] <pitti> cjwatson: last mail I got was from 12.09.08, and containd python-rdflib
[14:02] <seb128> cjwatson: yes, works fine in firefox
[14:02] <cjwatson> pitti: it was sent to Martin Pitt<EMAIL_ADDRESS>- shall I bounce it?
[14:02] <pitti> cjwatson: plas
[14:02] <cjwatson> seb128: odd, maybe transient
[14:02] <cjwatson> ?
[14:02] <pitti> argh
[14:02] <cjwatson> done
[14:02] <pitti> lt m sort out my kyboard, bbl
[14:03] <seb128> cjwatson: seems that I managed to confuse gvfs rather, gvfs-cat on the mount doesn't work either
[14:04] <seb128> brb restarting session
[14:07] <mvo> davmor2, hardy->intrepid with cd please
[14:08] <davmor2> mvo: NP's
[14:10] <Keybuk> james_w: we're attempting to get rid of groups like "rdma" which are for device access only
[14:11] <davmor2> mvo: should the tabs look like this http://www.davmor2.co.uk/cli.png
[14:11] <james_w> Keybuk: does that require modifications to the applications that want to access the devices?
[14:11] <Keybuk> james_w: yes, in some cases. they would use a D-Bus backend to access the device and authorise through PolicyKit
[14:11] <Keybuk> otherwise we can always provide implicit "at console" authorisation through HAL's PolicyKit backend
[14:12] <mvo> davmor2, the gnome-terminal tabs?
[14:12] <davmor2> mvo: yes
[14:12] <james_w> Keybuk: is rdma going to be a good subject for that?
[14:13] <Keybuk> james_w: who should have permission to access rdma devices?
[14:13] <Keybuk> what _is_ rdma?! :p
[14:13] <james_w> I have no idea :-)
[14:14] <james_w> Keybuk: I'll ask for some more details in the bug, unless you want to do it. I'm sure you will ask more insightful questions.
[14:15] <Keybuk> there tends to be a pattern upstream of "just create a gnomovision group" when dealing with permissions
[14:15] <MacSlow> greetings everybody
[14:16] <seb128> cjwatson: ok, it's working now, I managed to screw gvfs by running non matching gvfs and libgvfscommon versions while doing some testing
[14:24] <Keybuk> james_w: commented, though I can't unsubscribe the sponsor team
[14:24] <james_w> Keybuk: thanks, I can do that
[14:33] <davmor2> mvo: sorry closed the wrong window.  Should the tabs on terminal be transparent?
[14:33] <stefanlsd> crimsun: you around?
[14:34] <mvo> davmor2: hm, no
[14:39] <doko> ubuntu-archive: please process xorg-xserver binaries in NEW. breaks installation of xvfb
[14:41] <seb128> doko: looking
[14:42] <seb128> doko: accepted
[14:42] <doko> thanks
[14:44] <Keybuk> liw: "python-fstab" ?!
[14:45] <Keybuk> *please* don't tell me that parses it itself
[14:45] <ogra> it probably rewrites it more beautifully :P
[14:46] <liw> Keybuk, it does, in order to be able to write it back without losing comments, etc
[14:46] <ogra> with flowers and decoration
[14:46] <Keybuk> liw: but how many of the corner cases of that file do you handle?
[14:46] <Keybuk> read the glibc implementation of getfsent() - it's *complicated* to parse
[14:47] <tseliot> ogra: and this is why we have decorators in Python
[14:47] <liw> Keybuk, everything I could think of, based on the manpage spec for the format of the file
[14:47]  * tseliot hides away
[14:47] <Keybuk> it's just just "non-space chars" "space chars" "non-space chars"
[14:47] <Keybuk> ie. do you cope with spaces in the mount point name?
[14:47] <ogra> tseliot, ah, i knew they were useful for something :)
[14:48] <liw> Keybuk, fstab(5) says tabs and spaces separate fields; do you have a better spec?
[14:49] <Keybuk> liw: I don't think there's a spec; getfsent() etc. is the canon way to read that file
[14:49] <liw> Keybuk, they don't seem to allow _writing_ it
[14:49] <Keybuk> no, sadly not
[14:50] <lool> tjaalton, bryce_: hmm tested new xorg on jax10; a PCI id needed to be added; pushing a new xorg-server as a result; also merged the xvfb-run patch in git, makes more sense IMO if patches are for upstream changes only
[14:50] <Keybuk> certainly not rewriting it
[14:51] <cjwatson> you can write spaces in the mount point name using %40
[14:51] <Keybuk> cjwatson: and \040 and \x20 and "\ " etc.
[14:51] <cjwatson> I don't think "\ " is reliable
[14:51] <cjwatson> I'm sure I tried that last time I needed to figure it out and it didn't work
[14:51] <Keybuk> it's unreliable in that the silly repeated shell in our init scripts will choke on it ;P
[14:52] <Keybuk> it probably won't get mounted :p
[14:56] <cjwatson> Keybuk: seems sort of important :)
[14:57] <liw> the libc code does not seem to support escaping a space with a backslash; it splits a line based on spaces and tabs and then decodes those
[14:57] <liw> where decoding un-escapes certain things
[14:57] <tjaalton> lool: hmm, you mean that our changes should poke the code directly?
[14:57] <lool> tjaalton: xvfb-run is in debian/
[14:57] <lool> tjaalton: So it's like our debian/control changes
[14:57] <tjaalton> lool: oh, heh
[14:58] <Keybuk> liw: ah, I could be mistaken there then
[14:59] <tjaalton> lool: yep, got that right. the patch was old
[15:30]  * ogra wonders where all these segfault messages in his dmesg for firefox come from
[15:31] <ogra> FF is definately not crashing or something
[15:31] <ogra> firefox[24482]: segfault at b794fa9e ip b7c8d571 sp bff2f0a4 error 4 in libc-2.8.90.so[b7c5f000+158000]
[15:33] <\sh> bryce_: thx for the new ati working crack :) I wonder how much you paid for that to amd ;-)
[15:34] <ogra> a truck of beer :)
[15:37] <\sh> ogra: that's cheap ;)
[15:37] <ogra> \sh, do i see you on the weekend ?
[15:37] <\sh> ogra: where?
[15:38] <ogra> \sh, its UBUCON !!!! man, you guys are so uninformed down there in the south
[15:39] <\sh> ogra: ah ubucon...no, sorry...
[15:39] <ogra> http://ubucon.de/index.php
[15:39] <calc> crap, i forgot a line of code in rules that broke i386 build :(
[15:39]  * calc kicks himself
[15:42] <calc> at least powerpc works now :)
[15:42] <kwwii> \sh doens't really live in the south, or?
[15:42] <\sh> kwwii: karlsruhe is more south then cologne ;)
[15:43] <\sh> kwwii: but not as south as bamberg, right?
[15:43] <kwwii> \sh: *exactly*
[15:44]  * ogra looks from kassel and notes that *most* of germany is south
[15:44] <kwwii> lol
[15:44]  * kwwii should take another trip to see ogra ;-)
[15:44] <ogra> :)
[15:45] <\sh> kwwii: if you do, just come to karlsruhe and hijack me ,-)
[15:45] <\sh> kwwii: if you go to kassel I mean...
[15:46] <\sh> or I'll plan visiting ogra around xmas time...when I hopefully have some days off from work
[15:46] <\sh> kwwii: the "bamberg" next to würzburg"? then karlsruhe is more south ;)
[15:48] <maswan> \sh: are you in karlsruhe?
[15:52] <lool> liw: mir acked for systme-cleaner
[15:52] <liw> lool, cool, I was just about to ask you. thank you
[15:54] <\sh> maswan: yes
[15:55] <maswan> \sh: Ok, cool. I might ping you closer to january, I might be visiting.
[15:55] <liw> hmm, trying to eject a cd from the drive: it gets ejected and then immediately pulled back in and mounted again
[15:55] <\sh> maswan: try to make it around the 11th :)
[15:56] <maswan> \sh: Unfortunately I'm not the one scheduling it. :)
[15:56] <\sh> maswan: much better around the 10th and we can celebrate into my birthday ,-)
[15:56] <maswan> \sh: hehe. good plan.
[16:06] <\sh> maswan: you are not visiting the university here in KA?
[16:17] <Riddell> dholbach: I've removed the triaged packages in bug 283543, do you know a clever way to close all those entries?
[16:18] <dholbach> hang on :)
[16:20] <maswan> \sh: FZK which is now KIT or something like that
[16:22] <dholbach> Riddell: "An internal server error occurred. Please try again later." :-/
[16:22] <Riddell> aww
[16:23] <dholbach> Riddell: bug basically http://paste.ubuntu.com/57928/
[16:23] <dholbach> but
[16:25] <dholbach> thekorn: do you know why http://paste.ubuntu.com/57928/ could fail?
[16:28] <sistpoty|work> dholbach: karma overflow? *g*
[16:28] <dholbach> sistpoty|work: that might be :)
[16:29] <dholbach> commiting each individual change does not work either :-/
[16:36] <ogra> asac, its a fn key combo, i dont have a HW switch
[16:37] <rainct> dholbach: here it worked
[16:37] <dholbach> rainct: great
[16:38] <asac> ogra: ok. that works for me too i think
[16:38] <asac> ogra: hardware thing was broken. i will verify latest fix by slangasek
[16:39] <ogra> [104163.897885] iwlagn: Radio Frequency Kill Switch is On:
[16:39] <ogra> [104163.897890] Kill switch must be turned off for wireless networking to work.
[16:39] <ogra> [104169.336140] wlan0: No ProbeResp from current AP 00:14:6c:e5:f7:ef - assume out of range
[16:39] <ogra> [104176.983910] Registered led device: iwl-phy0:radio
[16:39] <ogra> [104176.983969] Registered led device: iwl-phy0:assoc
[16:39] <ogra> [104176.984036] Registered led device: iwl-phy0:RX
[16:39] <ogra> [104176.984066] Registered led device: iwl-phy0:TX
[16:39] <ogra> [104176.994772] wlan0: authenticate with AP 00:14:6c:e5:f7:ef
[16:39] <ogra> thats the dmesg for switching off and on once
[16:40] <slangasek> ogra: and does NM keep pace when you toggle it?
[16:40] <ogra> oh, wait, i didnt check NM ... only noticed the slack meter in xchat went to 100%
[16:41]  * ogra tries again
[16:42] <rainct> Uhm.. Epiphany's URL bar currently has "search the web (ie, google)" and "debian BTS". Shouldn't we add LP Bugs?
[16:43] <ogra> yup
[16:43] <ogra> its not really immediate, but does what it should after a bit delay
[16:46] <slangasek> right
[16:46] <slangasek> then I think the real issue in there is the one bdmurray identifies, that if you boot with the rfkill switch on, you can never associate
[16:47] <rainct> seb128: ^
[16:48] <ogra> ah, well, i never tried that, i'm not even sure that would work with the fn key combo my lappie uses
[16:50] <slangasek> ogra: oh, I read you backwards; yeah, if you don't have a hw kill switch, nevermind
[16:51] <Riddell> mvo: that update notification from gnome-panel is surprisingly confusing when popping up on a non gnome desktop
[16:51] <ogra> get a gnome desktop then :)
[16:52] <seb128> rainct: what?
[16:52] <mvo> Riddell: hm, we need a "per-desktop" swithc maybe
[16:52] <rainct> seb128: if I add Ubuntu & LP bookmarks to Epiphany (browser), will you sponsor that?
[16:53] <mvo> Riddell: but seriously, I think we can fix that
[16:53] <Riddell> mvo: yeah I've no paticular suggestions on how to improve it, a OnlyShowIn= key maybe, also s/your Quit button/the Ubuntu Quit button/ might help
[16:53] <seb128> rainct: there is already such bookmarks?
[16:54] <rainct> seb128: nope, only Debian and GNOME
[16:54] <thekorn> dholbach: let me check
[16:54] <dholbach> thekorn: seems it worked out for rainct - nevermind :)
[16:54] <dholbach> thekorn:  it was a LP failure
[16:55] <seb128> rainct: bug #137491
[16:55] <thekorn> dholbach: okay
[16:55] <dholbach> thekorn: might have been a too-old cookie too
[16:55] <dholbach> *shrug* :)
[16:56] <seb128> rainct: seems that the intrepid version didn't get the change, will fix that
[16:56] <siretart> is there some hickup with archive.u.c?
[16:56] <thekorn> dholbach: you should start using launchpadlib for such things, it's much more comfortable ;)
[16:57] <mvo> siretart: I was wondering the same
[16:57] <dholbach> thekorn: I slowly have to get used to it :)
[16:57] <rainct> seb128: OK :). I'd change the "Ubuntu Bugs" one to "Launchpad", though
[16:57] <slangasek> bdmurray, mdz: please confirm whether you're still having any problems with bug #193970; I'm optimistic that the hal change is all that was needed to fix this
[16:58] <seb128> rainct: feel free to raise the topic for discussion on the lists
[16:58] <lool> tjaalton, bryce_: noticed an error being printed on console during upgrade on my crownbeach in xserver-xorg-core; shouldn't confuse debconf, but there's a risk so I prefer pushing
[16:58] <seb128> rainct: I'm just going to use the hardy patch for now
[16:58]  * lool needs to cut on xorg-server uploads lalala
[16:59] <bdmurray> slangasek: Alright, I'll test today.
[16:59] <slangasek> thanks :)
[16:59] <mdz> slangasek: can do
[16:59] <seb128> lool: and you need to start using -v so people reading -changes know what debian changes you backported ;-)
[16:59] <rainct> seb128: if it's that one from the patch on the bug, does it even work?
[16:59] <cjwatson> bryce_: there's another task on 185311 which is still targeted, btw - pygtk
[16:59] <seb128> rainct: no, I didn't use the debdiff on the bug, try on hardy
[17:00] <rainct> seb128: oh ok, because there's a %s missing there :)
[17:00] <cjwatson> bryce_: ah, thanks, you sorted it
[17:00] <bryce_> cjwatson: yep, in fact was just looking into that
[17:01] <lool> seb128: Bah I could have included more, but it's completely confusing because an old Debian entry moved around
[17:02] <pitti> tjaalton, bryce_: http://gitweb.freedesktop.org/?p=mesa/mesa.git gives me "no such directory"; do you happen to know a working gitweb for mesa?
[17:02]  * lool should start a wider discussion about best practices on the debian/changelog merging front
[17:04] <bryce_> cjwatson: I'm quite tempted to break out all the remaining issues as separate bugs.  The original issues are long since gone, and the current remaining ones just got me-too'd onto it.  Well, something to look at for jaunty I guess.
[17:04] <cjwatson> I'm all for small, focused bugs
[17:04] <bryce_> pitti: checking
[17:05] <bryce_> pitti: hmm should work - see http://www.mesa3d.org/repository.html for full directions
[17:06] <pitti> bryce_: that's what I was looking at
[17:06] <pitti> bryce_: I wanted to provide a gitweb URL to bug 283175 (and for the SRU changelog)
[17:06] <bryce_> pitti: ah, use cgit.freedesktop.org
[17:07] <bryce_> pitti: they took down gitweb because it got too slow; guess the mesa docs didn't get updated
[17:07] <pitti> bryce_: ah, I didn't know that; anyway, http://cgit.freedesktop.org/?p=mesa/mesa.git gives me the same error
[17:09] <bryce_> pitti: ok, fdo infrastructure goes down a lot, maybe it's just one of their typical outages
[17:10] <pitti> bryce_: anyway, WDYT about that SRU request? sounds like a new feature, but I can't say at all whether it is important
[17:11] <bryce_> pitti: I've mentioned the dns or whatever issue on #xorg-devel
 there's an apache suicide script that runs on annarchy when the load gets too high
[17:11] <bryce_>  should be back up shortly
[17:11] <pitti> bryce_: fun, that causes errors like "no such path"? ok, thanks for poking
[17:12] <bryce_> pitti: I must have missed the link in the scrollback - bug id please?
[17:12] <pitti> bug 283175
[17:12] <bryce_> fdo looks back up btw
[17:12] <ogra> tjaalton, bryce_ was there any outcome for teh nsc driver yesterday ?
[17:13] <ogra> its still failing here (and for lool as well)
[17:13] <pitti> bryce_: swell, works now; thanks
[17:14] <bryce_> pitti: 283175> it includes an API change, are you certain it's safe?
[17:15] <pitti> bryce_: not at all; I have NFC about what "swizzling a TEX argument" is
[17:15] <bryce_> me either
[17:16] <bryce_> well, it adds a calling arg to i915_emit_texld(), so unless this code is the only place where that API is called I think it could cause breakage in other things
[17:16] <pitti> right, I asked the same thing in the bug
[17:16] <bryce_> ok reading
[17:17]  * bryce_ comments there
[17:18] <lool> ogra: I think I only dropped -nsc from video-all yesterday; there should also be a breaks in palce somewhere, dunno why there's not
[17:18] <lool> ogra: Might not have been in todays images
[17:18] <ogra> ah
[17:18] <ogra> well, i thought tjaalton and jcristau were working on getting a git fix in
[17:18] <ogra> but i might have gotten that wrong
[17:19] <lool> dunno
[17:21] <Hix-2> morning yall
[17:25] <doko> slangasek: well, jaunty can't be yet targeted
[17:25] <bryce_> pitti, heh, if I google "swizzle TEX" I get our launchpad bug.  Guess we can both be forgiven for having no idea what this guy's talking about.  ;-)
[17:25] <slangasek> doko: yes, but the bug shouldn't be targeted to 'intrepid' either then :)
[17:25] <ogra> doko, i use "later"
[17:26] <slangasek> ogra: targets, not milestones
[17:26] <doko> slangasek: how can a target be undone?
[17:26] <ogra> ah
[17:26] <bryce_> pitti: ok wikipedia to the rescue - http://en.wikipedia.org/wiki/Swizzling_(computer_graphics)
[17:26] <geser> jdong: Hi, about the jhead security bug: have you had already time to look at the new jhead version?
[17:26] <slangasek> doko: for a stable series, fix released or wontfix; for a devel series, wontfix
[17:27] <doko> slangasek: not a solution for me, it's not on my radar anymore in the bts
[17:27] <slangasek> doko: (if you look at the bug state now, you'll see there's a status for 'intrepid', but also one for Ubuntu without a target)
[17:27] <slangasek> doko: why not?
[17:29] <bugabundo_work> jdstrand: ping
[17:29] <doko> slangasek: ohh, I see
[17:29] <jdstrand> bugabundo_work: yes?
[17:29] <bugabundo_work> hi
[17:30] <jdstrand> hi
[17:30] <bugabundo_work> about that pidgin LP bug
[17:30] <bugabundo_work> with a pass on the log?
[17:30] <bugabundo_work> lol
[17:30] <bugabundo_work> 274380
[17:30] <bugabundo_work> which account was it?
[17:31] <bugabundo_work> do you know?
[17:31] <bugabundo_work> so I can protect my self and change it
[17:31] <jdstrand> bugabundo_work: I stripped out the password and reuploaded the log
[17:31] <bugabundo_work> still
[17:32] <bugabundo_work> other users were notified
[17:32] <jdstrand> before marking it public
[17:32] <bugabundo_work> and might have access to it
[17:32] <bugabundo_work> I want to safe guard my self
[17:32] <bugabundo_work> as you understand
[17:32] <jdstrand> sure
[17:32] <bugabundo_work> didn't know pidgin crash logs would send passwords in the clear
[17:32] <bugabundo_work> :(
[17:34] <tjaalton> ogra: the package we have already includes the pciaccess-patch from upstream, but it was made blindly. so, someone with the hardware should fix it :)
[17:34] <ogra> ah
[17:34] <ogra> well, i wont have time to do that before freeze
[17:34] <ogra> oh, wait and i only have gode HW ... no nsc
[17:40] <geser> jdstrand: Hi, about bug 271020: would it be a good idea to contact the Debian Maintainer and the Debian Security Team about the issue?
[17:41] <geser> jdstrand: it's the jhead security bug
[17:44] <jdstrand> geser: yes, as it's now public, I'll mark the bug public too
[17:45] <ogra> cjwatson, bug 283861 look like its worth to have in intrepid
[17:45] <ogra> *looks
[17:48] <bdmurray> slangasek: I still had to use the workaround in bug 193970
[17:49] <slangasek> bdmurray: "the workaround" -> "rmmod && modprobe"?
[17:49] <bdmurray> slangasek: yeah
[17:49] <slangasek> ok :/
[17:50] <slangasek> bdmurray: before you do the rmmod, does iwlist scanning return any results?
[17:50] <slangasek> that would pin down whether this is truly a driver bug, vs. a hal issue
[17:52] <bdmurray> slangasek: No iwlist scan does not return anything and I see "iwl3945: MAC is in deep sleep!" after deactivating the kill switch
[17:53] <ogra> sounds like kernel then
[17:53] <slangasek> ok
[17:53] <ogra> do you have yesterdays kernel ?
[17:53] <ogra> iirc there were some firmware updates
[17:53] <ogra> but meta seems to be not there yer
[17:53] <slangasek> bdmurray: can you follow up to the bug report with this info, then?  I'll close the hal task
[17:53] <ogra> *yet
[17:54] <slangasek> ogra: er?  there was no new linux ABI yesterday
[17:54] <slangasek> 2.6.27-7 is current, and meta already points to itt
[17:54] <ogra> slangasek, see the lrm changelog, at least something changed
[17:55] <pitti> slangasek: do you have an opinion about the proposed xml-core pre-depends? (on u-devel@); it's for an RC bug, so I'd rather settle it sooner than later
[17:55] <slangasek> ogra: ok, but why does that involve meta?
[17:55] <ogra> slangasek, and there was  2.6.27-7.11
[17:55] <slangasek> pitti: hrm, let me go back and look
[17:55] <bdmurray> ogra: 2.6.27-7.11
[17:56] <ogra> well, u-m cleary wanted to remove linux-image-generic here
[17:56] <slangasek> ... that's not normal, even during an ABI change
[17:56] <slangasek> sounds like you've got something wrong locally
[17:56] <ogra> linux-meta (<IP_ADDRESS>.9) intrepid; urgency=low
[17:56] <ogra>   * linux-image-<flav> now depends on linux-firmware for upgrades
[17:56] <mdz> slangasek: I still don't see an event from hal when I flip the kill switch
[17:57] <jdstrand> jdong: fyi-- requested CVEs for jhead and CC'd you, so you can respond if there are any questions
[18:00] <slangasek> mdz: ok.  hmm, and it seems I can confirm the can't-recover-from-kill-switch behavior here, which I wasn't able to previously
[18:00] <ogra> slangasek, might it be that linux-firmware sits somewhere in NEW ?
[18:00] <mvo> ogra: I see this too, looks like linux-firmware needs to go through NEW
[18:00] <ogra> snap :)
[18:00] <slangasek> ogra, mvo: yep, apparently
[18:07] <cjwatson> ogra: oem-config> thanks for the heads-up, we'll look at that
[18:12] <Awsoonn> is there a timeline for OOO3 to be uploaded?
[18:13] <cjwatson> Awsoonn: after Oct 30
[18:13] <cjwatson> Awsoonn: i.e. not for intrepid, sorry
[18:13] <cjwatson> I posted a detailed explanation on whatever bug report it was, as did calc
[18:13] <Awsoonn> cjwatson: thanks
[18:14] <sbeattie> TheMuso: is bug 275233 related to or the same as bug 274124?
[18:17] <heno> TheMuso: could you join #ubuntu-meeting?
[18:18] <sebner> TheMuso: does your jailbreak also works for the new ipodtouch2?
[18:34] <pitti> okay, with that f-spot upload digicam handling should be back to sanity; now off to Taekwondo, see you all tomorrow!
[18:45] <slangasek> gstreamer0.10-packagekit
[18:45] <slangasek> ... what
[18:46] <slangasek> is that a source or a sink for gstreamer? :P
[18:47] <tedg> slangasek: apt-get netflix wizard-of-oz
[18:47] <james_w> slangasek: codec installer alternative, sorry, I forgot it would hit NEW
[18:47] <slangasek> james_w: ah, weird
[19:02] <sebner> james_w: do we already have intrepid-security?
[19:02] <james_w> sebner: I don't think so, there's no need for it, just target intrepid for that upload
[19:03] <sebner> james_w: with -ubuntu2 or -ubuntu1.1 (CVE-fix) ?
[19:03] <james_w> ubuntu1
[19:03] <james_w> er ubuntu2
[19:03] <sebner> kk thx
[19:03] <kees> sebner: technically, the repository exists (i.e. you can add it to your sources.list without error) but it will be empty until intrepid releases.
[19:03] <sebner> kees: ah, k
[19:05] <emgent> evening people :)
[19:05] <sebner> emgent: \o/
[19:05] <calc> Awsoonn: it is however in the ppa already
[19:14] <Awsoonn> calc what ppa? is there a wiki page for installing it yet?
[19:16] <ogra> superm1, hey, typig from my BT freedomkeyboard, apart from my GPS reciever all BT devices work with a different dongle with bluez 4.x now
[19:16] <superm1> ogra, that's awesome :)
[19:16] <ogra> yeah
[19:16] <superm1> ogra, do you know what was wrong with the old dongle?
[19:16] <ogra> sad though that the gps doesnt work
[19:17] <ogra> some weird very old MSI thing
[19:17] <superm1> ogra, if i remember right, it was because it expected a particular pin code?
[19:17] <superm1> that you didnt have the ability to enter
[19:17] <ogra> yeah, but that seems to actually work with the new dongle
[19:18] <superm1> oh.  i was gonna say, we could always add a quirk for it to the bluez-gnome source and submit it upstream
[19:18] <ogra> i didnt know the kbd would be able to input a pin, its not documented
[19:18] <superm1> oh that was for the keyboard - what's the issue with the GPS then
[19:18] <ogra> nah, all fine now, i discovered today that i had timeouts in dmesg
[19:18] <ogra> gps simply says "cant pair" now
[19:19] <ogra> no info in dmesg about that one
[19:19] <ogra> headset has still the same alsa issue
[19:19] <ogra> but the BT side works fine
[19:20] <ogra> and i can still browse my razr
[19:21] <superm1> while i'm adding this patch for my apple keyboard, is there a particular way to do imported translations?  Or is there a document explaining what i'm supposed to do?  Someone else has always done the translation imports on the packages i've worked on
[19:21] <ogra> the new dongle is a "Cambridge Silicon Radio, Ltd"
[19:22] <ogra> the translations should automatically end up in the langpack
[19:22] <ogra> soyuz strips them out of your package
[19:22] <superm1> okay so I dont need to do anything for them then.  awesome
[19:23] <ogra> just have them in your source package
[19:23] <superm1> well i'd say that part is covered, they got imported: https://translations.edge.launchpad.net/ubuntu/intrepid/+source/bluez-gnome/+imports
[19:23] <superm1> so i'll not need to worry then
[19:23] <sebner> james_w: around?
[19:24] <james_w> hey sebner
[19:25] <sebner> james_w: hey. I'm off for today but I attached a debdiff for ssmtp/intrepid (But also used the Security wiki posted by you). If you are fine with it I'll prepare the debdiffs back to dapper tomorrow. just comment if it's ok or not :)
[19:27] <slangasek> pitti: xml-core pre-depends> eew, but ok, I don't see any better options
[19:54] <mvo> Riddell: I will disable the kde debian frontend during upgrades if you don't mind. it seems to cause crashes during the upgrade
[19:59] <calc> Awsoonn: https://launchpad.net/~openoffice-pkgs/+archive
[20:14] <dashua> Quick search in synaptic is buggied.  Type a few letter and CPU spikes over 50%, completely locks up synaptic.  Will check for bugs.
[20:18] <mvo> dashua: how fast is your machine/how much mem do you have?
[20:20] <lool> bryce, tjaalton: Just for the record, the xorg uploads were not in vain and it finally works almost out of the box with current xserver-xorg-core on psb hw to use vesa; sorry for the high number of uploads to fix misc things
[20:20] <lool> thanks for your help in reviews
[20:20] <bryce> excellent
[20:21] <lool> There are two things which remain high on my list of things to fix, the -nsc symbol lookup error should be garded by some conflict (any idea of the specifics?) and xvfb is still useless on ppc, ia64, sparc, hppa etc.
[20:21] <kirkland> anyone around here use wireless N under Ubuntu on a daily basis?
[20:21] <lool> Will start looking at it in qemu soon now; fetching ppc alternate cd
[20:23] <bryce> lool: sounds good, I've had my eye on the xvfb issues, but haven't had time to really dig into sorting them out
[20:24] <dashua> mvo: Dell XPS m1530 2 gig of RAM Core 2 Duo 1.66 GHz
[20:25] <dashua> I have to killall synaptic at times to clear it
[20:25] <mvo> dashua: uh, that is quite a powerful one - strange. could you create a screenshot for me when it freezes?
[20:26] <lool> ogra: BTW the vesa psb patch is now a noop as jcristau pointer out; vesa is the default when this function doesn't match any PCI ids
[20:26] <dashua> I tried to add a debug symbol to the synaptic package, no luck.
[20:26] <dashua> mvo:  Sure
[20:26] <lool> Will be a template when we get psb for real
[20:26] <ogra> lool, well, drop it if you feel like
[20:27] <lool> I could drop it in git; doesn't change any really, as I said it will serve as a template when we get back psb
[20:27] <lool> in 2 years
[20:27] <ogra> or four :P
[20:28] <bryce> 2 years??
[20:28] <nxvl> heh
[20:28] <nxvl> lool: i still can't configure xorg because with the psb error
[20:29] <lool> nxvl: What's the error?
[20:29] <lool> nxvl: what's your xserver-xorg-core version?
[20:30] <nxvl> mm
[20:30] <nxvl> i will look for the bug report
[20:30] <ogra> nxvl, note that lool just fixed it with the very recent packages
[20:30] <lool> nxvl: The bug report you filed was failing with -nsc symbol errors
[20:30] <nxvl> Bug #265035
[20:30] <lool> bryce, ogra: one thing which remains broken is for people with Driver "psb" in their xorg.conf
[20:30] <nxvl> i tried it yesterday
[20:30] <lool> Should be actually upgrade these people to vesa?
[20:30] <nxvl> with my system up to date
[20:31] <lool> nxvl: Xorg -configure should pick up vesa if you don't have -psb installed now; and there's a conflicts against -psn
[20:31] <lool> *-psb
[20:31] <nxvl> oh
[20:31] <nxvl> i will try it with Xorg instead of X
[20:31] <lool> But that's since a couple of hours
[20:31] <nxvl> but, shouldn't it be the same?
[20:32] <lool> nxvl: Well with X
[20:32] <nxvl> ok i will try later
[20:32] <nxvl> thank you
[20:32] <dashua> mvo: http://picpaste.com/pics/Screenshot-1.1224099130.png
[20:32] <bryce> lool, yeah probably.
[20:33] <jcristau> lool: xserver-xorg.postinst has some code to handle the upgrade, because i had to deal with the i810 -> intel transition, so you can probably adapt that
[20:33] <dashua> mvo: Just locks then Compiz' OBS saturates the screen
[20:34] <lool> jcristau: yeah, that's actually why I thought about doing this
[20:34] <lool> jcristau: So we should provide a dummy package in this case?
[20:34] <lool> jcristau: (for -psb)
[20:34] <jcristau> lool: why would you do that?
[20:34] <lool> Or should we simply rely on the conflict deselecting -psb?
[20:35] <jcristau> the conflict should be fine
[20:35] <lool> jcristau: I just fear that people stay with the old -psb and server, but upgrade their kernel
[20:35] <lool> Ok; thanks!
[20:35] <lool> Then it's not too hard to copy the upgrade code; thanks
[20:36] <mvo> dashua: thanks, that is with the latest intrepid version? I remember I fixed a problem with that some days ago
[20:37] <dashua> mvo: Yes, latest with all the updates.
[20:37] <mvo> dashua: and does it matter what charackters you type there? ie "li" ? or is it any char combination?
[20:38] <dashua> mvo: ii  synaptic       0.62.1ubuntu9  Graphical package manager
[20:38] <dashua> It seems to really lock on characters with multiple entries, like lib
[20:44] <dashua> mvo: bug #282188.
[20:45] <dashua> Not much info though
[20:46] <lool> jcristau: I think the upgrade snippet doesn't work when there are trailing comments
[20:47] <lool> jcristau: Since I have some lines with trailing comments in my xorg.conf, it might be worth fixing
[20:47] <jcristau> lool: yeah. this is a "don't do that then".
[20:47] <lool> jcristau: Why not support it?  it's just a matter of removing "[[:space:]]*$"
[20:47] <jcristau> well. i'm happy enough if i keep dexconf-generated stuff working
[20:48] <jcristau> but i won't complain if you fix that :)
[20:48] <lool> Ok, will do
[20:48] <mvo> dashua: I can reproducce it on one of my machines (but not the other) - how strange
[20:49] <dashua> This is 32 bit, I had tried 64 and don't recall this issue.
[20:50] <mvo> dashua: that is my impression as well, seems to be fine with 64bit
[20:53] <lool> nxvl: Did you upgrade yet?  Please don't if possible
[20:53] <lool> nxvl: It'd be nice if we could use your system to check for upgrades of -psb
[20:54] <nxvl> i think i'm up to date
[20:54] <nxvl> let me check
[20:55] <lool> Well don't fix your xorg.conf manually
[20:55] <nxvl> i'm up to date
[20:55] <nxvl> i haven't touch it
[20:55] <nxvl> it still sayd nothing
[21:04] <kirkland> slangasek: hey, i was wrong about one thing yesterday, related to bug #272232 ....
[21:06] <kirkland> slangasek: actually, jeez, nevermind, i've confused myself
[21:09] <kirkland> slangasek: okay, sorry.  you can smack me.
[21:09] <mvo> dashua: could you rebuild synaptic and see if that fixes it? its funny, I just build a debug version and that makes the issue disappear for me
[21:11] <slangasek> kirkland: if I smack you will that unconfuse you, or reconfuse you? :)
[21:12] <kirkland> slangasek: actually, i'm still not sure what's going on....  i will wait to speak more, until I have enough concrete data to report :-)
[21:14] <lool> nxvl: xserver-xorg 7.4~5ubuntu1 should convert your xorg.conf to use vesa on upgrades; could you confirm that happens correctly?
[21:15] <kirkland> slangasek: okay ...  here we go ....
[21:15] <kirkland> slangasek: passwd, enter a "Correct" current password, and then, enter 3x2 times a password that's too simple
[21:15] <nxvl> lool: what am i supposed to have in my xorg.conf?
[21:16] <kirkland> slangasek: the system password change will fail, the spurious "success" message will happen
[21:16] <lool> slangasek: Around?  Would you like to discuss a release note: we don't have psb in intrepid anymore, so people with psb (such as dell mini owner AIUI) will lose 3D and 2D acceleration on upgrades; is this release notes worthy?  How do I make it happen?  file a bug tagged release-notes?
[21:16] <kirkland> slangasek: and, very, very, very unfortunately, ecryptfs will re-wrap your passphrase
[21:16] <nxvl> lool: i have this: http://paste.ubuntu.com/58028/
[21:16] <lool> nxvl: What does it have right now for Driver?
[21:16] <lool> nxvl: oh
[21:17] <lool> nxvl: Then everything we did doesn't matter to you, your config has absolutely nothing to do with psb whatsoever
[21:17] <nxvl> i fixed it 2 days ago, before that i didn't have the Driver line
[21:17] <lool> nxvl: You're just a victim of the -ncb symbol issue, that's all
[21:17] <lool> nxvl: You don't need one
[21:17] <lool> nxvl: It should autodetect based on PCI ids
[21:18] <lool> bryce, ogra: (xorg_7.4~5ubuntu1 (grah forgot to -v the debian changes) should upgrade psb driver lines now)
[21:18] <slangasek> kirkland: ok, noted
[21:18] <kirkland> slangasek: i'm checking the pam_ecryptfs source, at the moment, in case the bug is there
[21:18] <slangasek> it's not
[21:19] <slangasek> :)
[21:19] <slangasek> it's a bug in the pam stack; pam_ecryptfs should never be invoked in this case
[21:19] <kirkland> slangasek: okay, thanks.
[21:19] <slangasek> I think I can fix this at the same time as fixing the rest of that bug
[21:20] <kirkland> slangasek: cool, thanks.
[21:20] <kirkland> slangasek: sorry for the back and forth messages
[21:21] <slangasek> kirkland: no worries, compared to the stock market this is downright placid ;)
[21:22] <lool> slangasek: Ok; I just confirmed that Dell mini users wont see the "upgrade to intrepid" popup; so the hardy psb user base is much smaller
[21:22] <kirkland> slangasek: funny, even though it shouldn't be :-)
[21:22] <lool> slangasek: So probably not release notes worthy
[21:22] <slangasek> lool: so you're saying you don't think it will need release notes? ok
[21:23] <slangasek> lool: otherwise, for reference, you can open a bug task on the 'ubuntu-release-notes' project for anything you think should be noted
[21:23] <lool> slangasek: Unless there's a way to trigger the notes only when Xorg uses psb?
[21:23] <slangasek> lool: nope :)
[21:23] <slangasek> for that you'd have to talk to mvo about adding it to u-m
[21:23] <lool> Ok; then not worth it to pollute everybody with it
[21:24] <slangasek> well, are there /any/ users of psb that are affected?
[21:26] <mvo> lool: xorg.conf rewrite? on upgrade? no problem, buy one, get one free!
[21:26] <mvo> lool: we do that for nvidia already (and used to do it for fglrx)
[21:26] <lool> slangasek: I'd say developers with dev hardware, so it's fine I think
[21:26] <slangasek> ok
[21:26] <lool> mvo: The rewrite part is done; I'd like to use something like for fglrx to tell them about the loss of acceleration
[21:27] <lool> mvo: But now that I see that real world mass users aren't affected, it's not worth it
[21:27] <lool> mvo: Just for my own curiosity: any drawbacks in doing it in xserver-xorg instead of update-manager?
[21:29] <mvo> lool: doing it in xserver-xorg is better because it will work for apt-get users too
[21:30] <slangasek> calc: hmm, are there more ooo uploads coming yet? if so, I have a request for a Recommends->Suggests downgrading to clean up the component-mismatches report :-)
[21:30] <mvo> lool: the nvidia case is a bit more complex because the driver changed from hardy->intrepid, basicly we have 4 now instead of just 3
[21:30] <slangasek> mvo: nuh-uh, we only have 2 because the other two are bustificated ;)
[21:33] <mvo> slangasek: right, but you can't tell that from the one that is installed in hardy, you need to check which one you would need in intrepid to figure it out :)
[21:33] <lool> mvo: Ok; thanks
[21:43] <DktrKranz> zul, xen-restricted-modules-2.6.17 is still in Intrepid, can it be dropped from the archives?
[21:47] <lool> james_w: I think you worked on clutter recently?  two tarballs were just announced, including the long awaited pyclutter 0.8
[21:48] <lool> Thought you might want to know :)
[21:48]  * slangasek resents that the PAM module writer's guide documents a different set of PAM return values for pam_sm_setcred() than the ones pam_unix will actually return
[21:48] <lool> james_w: they were announced on<EMAIL_ADDRESS>btw
[21:48] <lool> slangasek: It's to filter programmers allowed to program with pam
[21:49] <bdmurray> slangasek: I've updated bug 193970 with my findings
[21:49] <slangasek> lool: hmm, you seem to be positing that there is a conscious force responsible for anything in PAM :
[21:49] <ogra> slangasek, do you have an actual time for the freeze set ?
[21:50] <ogra> 0:00 UTC today or rather noon UTC tomorrow ?
[21:50] <slangasek> ogra: morning-ish, UTC
[21:50] <ogra> oki
[21:54] <james_w> lool: yeah, I requested the removal of pyclutter yesterday :-/
[21:54] <james_w> lool: what was the other?
[21:55] <slangasek> bdmurray: looks good, thanks
[21:56] <bdmurray> slangasek: not good but informative I guess
[21:56] <slangasek> bdmurray: right - consistent with what I'm now seeing, and lets us narrow the scope of the bug :)
[21:57] <mdz> slangasek: is 263059 on your radar?  it's looking very serious
[21:58] <mdz> slangasek: intermittent boot failure, apparently on systems using iwl3945
[21:59] <slangasek> mdz: yes, high+targeted; FWIW it only seems to happen with Dell hardware (== I can't reproduce it here), I'll nudge the kernel team
[22:00] <mdz> slangasek: both davidm and silbs reproduced it on ThinkPads
[22:00] <slangasek> hmm
[22:00] <mdz> slangasek: or at least something which matches the symptoms closely
[22:00] <mvo> I have a 3945 and it seem to not happen for me
[22:01] <bdmurray> nor I and I've been rebooting a lot lately
[22:01] <james_w> was there a suggestion it was 3945 + intel sound?
[22:02] <NCommander> hey apachelogger
[22:02] <davidm> mine hangs very frequently from cold boot
[22:03] <davidm> james_w, I do have intel sound too.
[22:03] <apachelogger_> yo NCommander
[22:03] <slangasek> james_w: yes; but AFAIK that's the common case as well, I definitely have both snd_hda_intel and iwl3945 and have never seen this
[22:03] <NCommander> apachelogger, what's up?
[22:03] <james_w> slangasek: probably not that then
[22:03]  * apachelogger_ is waiting for his core to get in sync with all his channels :P
[22:04] <slangasek> well, it might be specific hardware revisions, or specific motherboards
[22:05] <mdz> slangasek: it seems racy, could be anything
[22:05] <dashua> mvo: Sure, I'll give it a try.
[22:07] <ScottK> slangasek: Clamav announced a RC for a clamav 0.94.1.  It's almost all bugfix, but one new feature.  Typically their RC are followed by release ~ a week later.  Assuming this doesn't break any rdepends (generally correct for their .x releases) I think we want it.
[22:07] <ScottK> slangasek: What do you want from me for an FFe next week when they release so I can be ready?
[22:08] <NCommander> ScottK, got any good packaging tasks that needs doing?
[22:08] <NCommander> superm1, ping
[22:08] <superm1> pong NCommander
[22:09] <slangasek> ScottK: upstream changelog, debdiff, and preferably some confirmation that the package is tested and works
[22:09] <lool> james_w: other is Clutter-GTK 0.8.2
[22:10] <lool> slangasek: I don't have dell hardware and I get the bug
[22:10] <ScottK> slangasek: OK.  Thanks.
[22:10] <slangasek> lool: can you send your lspci -nn to the bug, so we can start trying to pin down the common denominator?
[22:10] <lool> mvo: Do you have snd-hda-intel?
[22:10] <slangasek> is there anybody who has iwl3945 that *doesn't* have snd-hda-intel?
[22:10] <james_w> lool: thanks, I might upload that tonight then.
[22:11] <lool> slangasek: I think it's a race between two modules doing irq detection or something; I often see snd-intel-hda in dmesg when it hangs
[22:11] <lool> slangasek: I tried loading them in shell for loops concurrently to no luck, but I couldn't hang my laptop in this way
[22:11] <slangasek> lool: yes, but it's a race condition that's hitting some users frequently, and other users not at all
[22:11] <lool> Yeah
[22:11] <lool> I'm using root on lvm on md
[22:12] <lool> perhaps that influences my initrd's code path to trigger it
[22:12] <slangasek> well, please send any information you think might be relevant to the bug log then
[22:12] <lool> slangasek: Also another thing which might be of interest is that I sometime hang in thinkpad-acpi since about the same time, but much less frequently
[22:13] <lool> slangasek: Will update the bug with what I just wrote here; I tried to do some research when I worked on another iwl3945 hang which seemed similar with amitk, but didn't update the bug after the irc exchange
[22:18] <calc> slangasek: i don't believe so, but the suggestion could be helpful in case it happens
[22:20] <slangasek> calc: openoffice.org-qa-tools currently recommends openoffice.org-qa-ui-tests, which is in universe; downgrading that relationship looks right to me, unless you think we should MIR the other way
[22:20] <calc> erm something is broken on ia64 buildd
[22:20] <calc> The following packages have unmet dependencies: default-jdk-builddep: Depends: default-jdk (= 1.6-30ubuntu3) but it is not going to be installed
[22:21] <calc> slangasek: taking a look
[22:21] <slangasek> openjdk-6 was uploaded about the same time as OOo, yes
[22:21] <calc> ah ok
[22:21] <calc> so it just needs to be retried once it has finished building i guess
[22:23] <slangasek> that's my best guess, I haven't chased that trail to be sure yet
[22:23] <calc> slangasek: if i am reading annotate correctly the recommends has been there for a long time
[22:24] <slangasek> sure
[22:24] <slangasek> this is the first cycle we care about Recommends outside of main
[22:24]  * calc looking at the reasoning if i can find when it was added
[22:24] <calc> ok
[22:24] <calc> yea been there for ~ 2.5 years, heh
[22:25] <calc> slangasek: as best as i can tell if qa-tools is in main then qa-api-tests should as well
[22:25] <calc> qa-tools appears to be the bit that runs the tests in the tests package :)
[22:26] <calc> and the description of qa-tools tells you to make sure to install qa-api-tests also
[22:27]  * calc does a rdepends on qa-tools
[22:27] <slangasek> oh, actually qa-tools isn't in main...
[22:27] <lool> slangasek: Upstream bug on iwl3945 also hints at hda
[22:28] <calc> slangasek: ok... so is there something that is causing the problem? :)
[22:28] <calc> i don't see a rdepends on qa-tools that should be causing an issue
[22:28] <slangasek> calc: now I'm not sure :/
[22:28] <calc> of course i am going by slightly old data
[22:28]  * calc chroots into intrepid
[22:29] <ogra> chroots ?
[22:29] <ogra> you mean you dont run it after beta ?
[22:29] <slangasek> maybe I need to take another look after the latest OOo publishes on amd64
[22:29] <calc> ogra: i didn't want to risk breaking my machine in the middle of a bunch of OOo updates, so haven't updated yet
[22:29] <ogra> heh
[22:29] <calc> ogra: i am planning to probably later this week since i got everything uploaded finally :)
[22:30] <ogra> well, final freeze is tomorrow
[22:30] <ogra> should only improve after that
[22:30] <calc> i booted a amd64 cd and it still was giving be weird resume issues so i think i will have to stick with i386 on my laptop
[22:30] <calc> some sort of fs issue (i forget now which it is)
[22:31]  * calc kicks apt-cache
[22:31] <calc> ogra: yea :)
[22:32] <TheMuso> sbeattie: re 275233 I am not entirely sure. The only thing I can do is ask those people to let us know if the rash still exists once we reduce the possaibility of the race conditions occurring.
[22:33] <TheMuso> sebner: What jail break?
[22:34]  * ScottK idly wonders if the response would be different off a publically logged channel.
[22:34] <sebner> TheMuso: ipod. I think you are the maintainer
[22:34] <TheMuso> sebner: No I am not.
[22:35] <calc> slangasek: yea on up to date intrepid i still don't see anything that would be pulling in qa-tools, only rdepends are -qa-ui-tests -qa-api-tests
[22:37] <sebner> TheMuso: argh, you are right. Sorry
[22:38] <crimsun> stefanlsd: hi
[22:39] <ScottK> slangasek: If you have a moment, would you please accept kdepim in hardy-backports?
[22:39] <sbeattie> slangasek: elisa-plugins-bad/main depends on python-cssutils/universe; want bug?
[22:41]  * calc is glad he managed to not annoy slangasek too much this cycle ;-)
[22:47] <nixternal> bryce: do you have a quick second?
[22:47] <nixternal> I might have an issue you are familiar with concerning X
[22:48] <ogra> spm, wow, thats the worst timing you guys had yet
[22:48] <ogra> spm, you know that we have final release freeze tomorrow ?
[22:48] <bryce> nixternal: okay... sort of in the middle of debugging two issues but if its quick go ahead
[22:49] <ogra> spm, and everyone will need to make heavy use of LP, soyuz etc to get the last fixes in
[22:49] <nixternal> intel gm965, external monitor blinks, log shows the following:
[22:49] <nixternal> (EE) intel(0): Unable to write to SDVOCTRL_E for SDVOB Slave 0x70.
[22:49] <bryce> nixternal: bug id?
[22:49] <nixternal> I fixed this the other day I am sure, but I have totally brain died
[22:49] <nixternal> bryce: no bug id yet
[22:50] <nixternal> just wondering if you have come across this one yet
[22:50] <bryce> dude, I've been looking at sooo many bugs, if I did come across it I wouldn't remember :-P
[22:50] <bryce> no it doesn't sound familiar offhand
[22:50] <nixternal> hehe, OK thanks
[22:50] <bryce> but all these bugs seem to run together after a while
[22:50] <mthaddon> ogra, we were asked to delay from our normal time of 22:00 UTC to 00:00 UTC - I think kiko co-ordinated with engineering...
[22:51] <bryce> nixternal: did you search launchpad?
[22:51] <nixternal> ya, there are other reports with it, but no fix or anything
[22:51] <nixternal> actually a few of them I have found are "RESOLVED" or "FIX RELEASED"
[22:52] <ogra> mthaddon, even that is bad, i would have asked for 24h delay if i had been involved ... (i wasnt though) ... its one of the two busiest days for the distro team in a release
[22:52] <ogra> mthaddon, it wont affect me personally but i guess a lot of universe contributors would try to get their fixes in tonight
[22:53] <mthaddon> ogra, well, sorry you weren't involved - might be worth taking it up with kiko and/or Rinchen to make sure you're involved next time
[22:53] <bryce> nixternal: if there are open ones with that, it'd be great if you could lend a hand triaging those.
[22:53] <ogra> mthaddon, well, i dont ask to be involved :)
[22:53] <bryce> nixternal: although, be aware that it's often the case where two people will see the same symptoms/error message yet may not have the same problem exactly
[22:53] <mthaddon> yeah, careful what you ask for, eh?
[22:54] <calc> why isn't there a hardy or intrepid updates milestone target?
[22:54] <ogra>  mthaddon i just noticed that whoever was involved didnt really get across how important pre-final freeze day is :)
[22:54] <bryce> often different error conditions can trigger the same error message
[22:54] <ogra> mthaddon, at least its not the day before release ;)
[22:54]  * calc has some bugs he needs to make in some way and those two would be helpful
[22:54] <calc> er s/make/mark/
[22:54] <slangasek> sbeattie: bug, and you might want to grab lool's attention on that
[22:54] <ogra> mthaddon, as i said i'm mostly safe myself
[22:54] <mthaddon> ogra, we'll do all we can to make sure the downtime is as short as possible (in any case, should be way less than 2 hours)
[22:54] <slangasek> ScottK: hmm, try me again in a few hours please
[22:55] <bryce> nixternal: if you're uncertain if you have exactly the same bug, file a new one via ubuntu-bug xserver-xorg-video-intel, which will collect all the files and stuff.  Make sure to describe the error message, symptoms, steps to reproduce, etc.
[22:55] <cjwatson> calc: for hardy, would ubuntu-8.04.2 make sense?
[22:55] <ogra> mthaddon, i'm just surprised that the distro team didnt actually ask for a 24 delay or for doing the outage a day earlier ...
[22:56] <calc> cjwatson: yea i suppose that will work well also
[22:56] <mthaddon> ogra, fraid I wasn't involved in the discussions either - we just rollout when we're told to :)
[22:56] <cjwatson> calc: I'll create ubuntu-8.04.3, ubuntu-8.04.4, and intrepid-updates now
[22:57] <cjwatson> ogra: I think it's probably better to have it now rather than later; wouldn't want it in the middle of the final freeze cycle either
[22:57] <ogra> mthaddon, yeah, i didnt mean to complain, no worries
[22:57] <cjwatson> ogra: at this point pretty much all times such
[22:57] <cjwatson> suck
[22:57] <ogra> yeah
[22:57] <mthaddon> ogra, no offense taken :)
[22:57] <calc> cjwatson: ok
[22:57] <crimsun> TheMuso: do you need any assistance w/ munging pulseaudio to retry sinks (and sources) upon a new client connecting?
[22:58] <calc> gar i found a bug in launchpad, i think
[22:58] <calc> i approved hardy task for 173090
[22:58] <TheMuso> crimsun: If you can offer help, that would be much appreciated. Last I was looking was sink-input.c in src/pulsecore.
[22:58] <calc> it approved it for both openoffice.org2 and openoffice.org
[22:58] <calc> now i can't mark it invalid for openoffice.org2 because it tries to reassign it openoffice.org
[22:58] <crimsun> TheMuso: ok
[22:58] <TheMuso> But I think this may need to be done in each of the connection type modules.
[22:58] <cjwatson> calc: milestones done
[22:59] <calc> i really wish we could get a feature to nuke whole package entries on bugs
[22:59] <calc> i often end up with bugs like that which can't have a package incorrectly associated with it deleted
[23:00] <cjwatson> calc: reproduced, yes that does look like a bug
[23:04] <ogra> bryce, is i810 dead now ? seems there are some usecases whaere it would be worth having it
[23:05] <bryce> ogra: it's dead jim
[23:05] <ogra> thats bad
[23:05] <TheMuso> heh
[23:05] <pitti> slangasek: eek indeed, but I don't have a better solution either :(; but xml-core is so low in the stack that there shouldn't be any circular dependencies
[23:05] <ogra> we just have a user whose HW doesnt work with intel
[23:05] <ogra> in -mobile
[23:07] <bryce> ogra: what's the chipset?
[23:07] <ogra> Intel GMA 900
[23:07] <ogra> seems to result in a black screen
[23:07] <ogra> ASUS R2h
[23:07] <bryce> ogra: bug id?
[23:07] <ogra> no bug, the user just popped n asking for help
[23:08] <bryce> dah
[23:08] <bryce> ok, well talk to me again if/when there is a lp#
[23:08] <ogra> though he is running -mid which is lpa
[23:08] <ogra> *lpia
[23:08] <bryce> upstream no longer supports -i810; we are not in a position to take over maintenance of it
[23:08] <ogra> not sure there are any diffferences wrt intel
[23:08] <ogra> yeah, i thought so
[23:08] <ogra> lool, can we get him to file a bug ?
[23:09] <bryce> for supported chipsets (i855 or newer), upstream will provide support, so bugs can be upstreamed for those
[23:09] <lool> ogra: I think we should
[23:09] <ogra> yeah
[23:09] <lool> ogra: I'd like to make sure he can retrive some info
[23:09] <ogra> not sure it helps that late in the release though
[23:10] <lool> It's probably too late unless we can debug it
[23:10] <bryce> people asking for help with unreported X bugs this late in the release cycle just aren't going to get help; there's already too many bugs already reported where we're close to a solution, that we're focusing the limited time on
[23:10]  * ogra really wonders how intel will support their scaling and panning modes in teh classmate without the i810 driver
[23:11] <bryce> best bet is for them to help us help them get the bugs upstream and fixed there, so they'll have a chance with jaunty
[23:11] <ogra> the intel driver will never support either by design
[23:20] <pitti> slangasek: rarian with pre-depends uploaded now, FYI
[23:20] <pitti> yay, that will make https://bugs.edge.launchpad.net/ubuntu/intrepid/+bugs?field.assignee=pitti empty
[23:28] <ScottK-palm> NCommander: Upstream react.  He'll have a patch shortly, so you may as well move onto something else.
[23:28] <NCommander> ScottK-palm, too late
[23:28] <NCommander> I just kicked out a patch myself
[23:28] <NCommander> :-)
[23:28] <NCommander> (three line fix, it needed an addition check)
[23:28] <ScottK-palm> Did you mail it to me?
[23:28] <NCommander> I *just* finished it
[23:28] <ScottK-palm> Send it to Shevek too then
[23:28] <NCommander> Had to make sure it worked ;-)
[23:29] <NCommander> Who?
[23:29] <ScottK-palm> I'll tell him to expect it.
[23:29] <NCommander> Wher?
[23:29] <NCommander> What?
[23:29]  * NCommander is lost
[23:29] <ScottK-palm> The upstrw
[23:29] <ScottK-palm> upste
[23:29] <ScottK-palm> urgh
[23:30] <ogra> that thing where our software comes from :)
[23:30] <ScottK-palm> Upstream.
[23:30] <bond`> what needs to be done to get a patch backported to 8.04?  Bug #276472
[23:30] <NCommander> ScottK-palm, I can't find his email
[23:30] <NCommander> bond`, if its a small patch, it can usually done via SRU
[23:31] <ScottK-palm> It's in the contributors file
[23:32] <bond`> NCommander: bug 276472 is still status incomplete, what is missing?
[23:32] <ScottK-palm> NCommander @annares.org I think)
[23:33] <NCommander> Sent
[23:33] <ScottK-palm> K.  thanks
[23:49] <NCommander> ScottK, he fixed the bug but didn't release a new upstream
[23:49] <NCommander> Which is anonying but ...