[00:04] gwaaaaan, dare you. double dare you! [00:06] calc: will that be in the final? [00:08] Man "glitch-free" pulseaudio is a barefaced lie :) [00:09] so, i wonder if Hobbsee here feels like being a hero & uploading that ickle security-driven mono merge [00:10] TheMuso: If you're interested in pulseaudio 0.9.13 feedback, it suffers from _more_ underruns than 0.9.12 [00:10] RAOF: Oh wonderful. :S [00:10] RAOF, thank god for my soundblaster! [00:11] The more I deal with hda hardware, the less I like it. [00:11] I belive crimsun came to the same conclusion! [00:11] directhex: mono? No. [00:11] aw, poopies. [00:11] RAOF: it's glitch free for me. *shrug* [00:11] WHen does jaunty open specifically? [00:11] Start of november, right? [00:12] NCommander: fail. [00:12] * NCommander never claimed to succeed ;-) [00:12] NCommander: you've just managed to make this the worse release we've had that question :P [00:12] o_o? [00:12] My English parser failed [00:12] 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] 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] yeah, i think my english writer failed in the first sentence, too [00:13] start of November? [00:13] Hobbsee, I only ask because we have a serious bug that happens to a backport [00:13] NCommander: now you've gone beyond that record (asking a couple of days after release). [00:13] RAOF: Did you post your alsa-info output anywhere? [00:13] er wait [00:13] NCommander: ahhh. I thought you were just desperate to start merging, or something. [00:13] intrepid was released and I missed it? [00:13] no. [00:13] Hobbsee, no, this is just backport related [00:14] We normally only backport from the latest release [00:14] right, yes. [00:14] We need a new upstream to fix the bug [00:14] The new upstream is in sid [00:14] you can see where this is going [00:14] 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] IIRC, that was the policy previously [00:14] 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] er, no, not intrepid. jaunty. whatever the release after this one is. [00:14] We have bent the "Must be a packaged version" to do a backport rule before [00:15] I'd like to avoid doing that if possible however [00:15] 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] Hobbsee, ok, I'll talk to ScottK/jdong and see if we're willing to bend the rule in this case [00:16] RAOF: I'll have a dig first. [00:16] I'm going to guess the general archive opening won't be for more like a month, right? [00:16] But later... [00:17] (like second week of November) [00:17] NCommander: they usually are. [00:17] NCommander: and yeah, that's probably a reasonable estimate. [00:17] Hobbsee: no 2.4.1 will be in intrepid final [00:17] Ok [00:17] Hobbsee: final is for most intents this thursday [00:17] calc: ahhh [00:17] I'll have to ask ScottK on bending the rule [00:17] calc: i thought we delivered an rc of it now [00:17] Hobbsee: and 3 days of shake out for 3.0 wouldn't be nearly enough [00:18] Hobbsee: just in the ppa [00:18] ah. [00:18] Hobbsee: even with 2.4 in hardy it had major issues until a few months later [00:18] Hobbsee: so i updated it with 2.4.1 later but that was a lot of work [00:18] calc: fair enough. I've just seen lots of people asking. [00:19] 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] 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] calc: fun. have you gone mad yet? [00:20] Hobbsee: some of them are a bit crazy it seems [00:20] Stupid question [00:20] If we do a new upstream in an SRU or security, what is the versioning? [00:21] 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] directhex, do you need any mono help? [00:22] NCommander, i need a merge, which should be the absolute final version for intrepid [00:22] a merge from Debian? [00:22] NCommander, yeah. latest upload, 1.9.1+dfsg-4, includes a bunch of bug fixes including two security holes [00:23] NCommander, note the name in the 1.9.1+dfsg-4 changelog \o/ [00:23] Sounds like *fun* [00:23] wait [00:23] O_o? [00:23] calc: hah. [00:23] Why does that sound like its going to burn? [00:24] 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] directhex, that looks like loads of fun [00:27] seeing as debian has been in freeze for a while i think it should be safe :) [00:27] calc, i can't think of any changes that would be harmful for libuno-cil [00:27] ok [00:27] * ogra hopes the OOo upload doesnt blow up his lpia-linux build :P [00:28] i remember before the packaging split surprised me :) [00:28] ogra: >:-) [00:28] :) [00:28] calc, okay, advance warning then: jaunty will have a new mono package split [00:28] directhex: ok that should be fine [00:29] directhex: as long as it doesn't happen right before final freeze ;-) [00:30] 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] calc, you could sponsor my mono merge, y'know. it'd be neat! [00:32] Hmm there is no daily-live for ppc [00:34] cjwatson: needed a couple other fixes :-/ but seems to all work now running in multiple locales [00:35] see this tiny diffstat? it's a teeny tiny diffstat! http://launchpadlibrarian.net/18515040/mono_1.9.1%2Bdfsg-4ubuntu1.diffstat [00:43] directhex: i have a fairly large merge to finish by tomorrow, sorry :( [00:45] cjwatson: I'm assuming you've gone to bed so I've uploaded language-selector (and shall go to bed also) [00:45] calc, poo, never mind. i was hoping to avoid bugging pitti, but i really wanna make sure -4 gets in [00:45] TheMuso: http://www.alsa-project.org/db/?f=dad977e638055d5d42e035221185e6c519cd3990 if you haven't already found it. [00:45] RAOF: thanks [00:45] calc: will you do another upload for intrepid? [00:46] asac, he's only doing PPA uploads atm [00:46] 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] calc: could you please fix the milestoned bug #272772 :) [00:46] Launchpad bug 272772 in ubuntu-docs "packages that Depend/Recommend/Suggest firefox (meta-package) must alternatively Depend/Recommend/Suggest abrowser" [High,Fix committed] https://launchpad.net/bugs/272772 [00:47] ogra: PPA only until jaunty? [00:47] asac: yes [00:47] calc: did you miss that bug above? [00:47] heh [00:48] asac: er no i am doing another upload for intrepid tonight (hopefully unless i pass out) [00:48] asac: i will include the abrowser fix in the upload tonight [00:48] calc: ok. please remember to fix that bug. shouldnt be that hard ;) [00:48] cool [00:48] thanks a bunch [01:07] jdong, ping [01:14] 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] slangasek: i'm trying to figure out if pam_ecryptfs is the culprit [01:16] slangasek: hmm, okay, not an ecryptfs problem [01:16] ummm ok :) [01:17] slangasek: well, it occurs on a system without ecryptfs ;-) [01:17] slangasek: intrepid system, non-root user, run "passwd" [01:17] slangasek: enter an "incorrect" current password [01:18] slangasek: passwd exits with "password updated successfully" even though it isn't (thankfully) [01:18] slangasek: same thing if you enter two non-matching new passwords [01:19] kirkland: bug #272232 [01:19] Launchpad bug 272232 in pam "passwd - passwords do not match but updated successfully" [Undecided,Confirmed] https://launchpad.net/bugs/272232 [01:19] slangasek: excellent, thanks. [01:19] slangasek: i think this is leading to some confusion on the pam_ecryptfs front [01:19] slangasek: i'll point at that bug [01:19] 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] Hiya, pardon the attention getting, but I think it is deserved in this case. I've just nominated it for Intrepid: [01:20] https://bugs.launchpad.net/ubuntu/+source/linux/+bug/264019 [01:20] Launchpad bug 264019 in linux "unable to visit some websites and ftpsites with 2.6.27" [Undecided,New] [01:21] Seems to be some bug in TCP that gets triggered somehow when using Verizon DSL. [01:22] slangasek: okay, thankfully, pam_ecryptfs isn't re-wrapping the passphrase [01:22] slangasek: my heart stopped for a few minutes back there ;-) [01:23] kirkland: yes, I got /that/ part of the framework right, it's really just the error messages that we got wrong :) [01:23] slangasek: :-D thanks for that, at least [01:36] fbond: could you please provide wireshark captures in pcap format, instead of text dumps? [01:36] RAOF: and its Realtek ALC660 is that correct? [01:39] TheMuso: Yes. The other one would be the USB speaker. [01:40] RAOF: yeah. Well the hda code supports your notebook with no problems so what causes the underruns I don't know yet. [01:40] 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] 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] slangasek: I can provide pcap files, sure. [01:42] I saved them. [01:42] RAOF: Right. [01:42] slangasek: Um, maybe wget uses HTTP/1.0? [01:42] slangasek: I did some manual tests, too, but I think those were with wget. [01:42] wget might use HTTP/1.0 by default, I guess [01:43] Should I upload pcap files? [01:43] well, no, I don't see any options to wget to specify the protocol, so that doesn't seem possible [01:43] fbond: yes, please [01:43] slangasek: Okay, brb. [01:44] (Hoping my pr0n d/l cron job wasn't running then ;) [01:48] Ah, crap, one of them is 2MB. Forgot to compress, sorry. The last may be the most interesting, anyway... [01:48] slangasek: uploaded [01:49] Hm. Wget appears to use HTTP/1.0. [01:51] fbond: hmm, I didn't remember HTTP/1.0 supporting Host: headers at all... ohwell [01:51] fbond: do you have a firewall configured on your Intrepid system? [01:51] (i.e., does iptables -L -n return anything?) [01:52] slangasek: Just default policy accept on everything. [01:52] Default configuration. [01:53] 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] 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] problems with drive encryption on install by chance? I am having issues [01:59] fbond: and given that you don't see the same thing, it's likely that your router isn't passing them through [02:09] 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] slangasek: Thanks. The issue at hand is that the problem only exists with 2.6.27. [02:46] I'm on 2.6.24 now and it does not exist at all. [02:47] (2.6.24 with intrepid userland) [02:47] You think it might be a library? [02:47] no [02:49] 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] 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] TheMuso: I think the latter is Obviously Correct, but maybe there's some reason you don't? [03:07] 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] 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] crimsun: pulse 0.9.11 or greater is needed for canberra. [03:37] 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] 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] does lennart use pulse yet ? [03:38] lifeless: I believe so. [03:38] it should improve soon then :P [03:39] TheMuso: ok, I've tried putting pulseaudio into the X11 session here as you suggested in the bug, and it worked [03:40] TheMuso: but I still have concerns that we're only reducing a race, not solving it [03:41] 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] TheMuso: no, the point is that each component should be /resilient/ in the face of races [03:42] 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] unless there's specifically a reason that it's also wrong for these other bits to start before pulse is running [03:47] 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] Unless crimsun has any other ideas to make things more resilliant. [03:48] TheMuso: not really any more (hence my first question regarding libcanberra0.6) [03:48] 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] 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] 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] so fixing pulse is whats needed, I'll see what I can find. [04:01] 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] 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] 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] 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] slangasek: okay, thanks, will do. [04:05] slangasek: thats what I'm doing now. [04:06] 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] in that case, pulseaudio --fail does not fail catastrophically, which is also a problem [04:10] 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] The fun bit is finding where in pulse we need to tell it to try again. [04:12] TheMuso: I would propose that you tell it to try again when it receives a new client request [04:13] slangasek: My thoughts as well. === bdmurray_ is now known as bdmurray === mcasadevall is now known as NCommander [04:52] 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] Hey TheMuso [05:37] * calc remembered to write the mimetype identification for Microsoft files :) [05:59] 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] 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] ah, okay, as long as its already known. thanks. [06:07] * StevenK tries to find run-init [06:08] Since this device booting jumps out of the initramfs and seems to hang. [06:09] Hobbsee fixed it. [06:09] Err Hobbsee changed it to avoid a brain dead area of Soyuz. [06:15] one last bit to fixup then final OOo 2.4.1 test build :) [06:21] is there a /usr/lib/abrowser/plugins dir? [06:34] good morning [06:36] good morning dholbach [06:36] hi evand [06:40] ScottK, so now what? (w.r.t to the backport) [06:41] NCommander: I'm gonna upload it. [06:41] Cool :-) [06:41] Its in the PPA to save you some work [06:42] It's just a debian/changelog entry, so I just grabbed it from Debian. [06:43] Oh ;-) [06:44] Uploaded. [06:44] uploading openoffice.org 1:2.4.1-11ubuntu1 now [06:44] \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] NCommander: it definitely will on hppa [06:45] NCommander: it doesn't support hppa at all, configure fails [06:45] O_o; [06:45] OpenOffice supports m68k o_o;;; [06:45] * calc is hoping this build will pass on ppc though [06:45] NCommander: yea, i'm not exactly sure why it hates hppa, haven't taken the time to look into why [06:46] We even managed to build it on m68k [06:46] probably it works on m68k because someone bothered to fix it ;-) [06:47] 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] calc: I'm mailing mine tomorrow too. [06:50] i have until jan but i don't know if they extended the stimulus checks for texas also [06:50] so i am filing tomorrow to be safe [06:54] Ah. Well I had until tomorrow. [07:05] slangasek: If you're still around, it's be nice if you would accept kdesvn in hardy-backports. [07:26] hi. I'm trying to semi-automate adding debian/changelog info. Any pointers? [07:26] (cat leaves EOF markers which break dpkg-buildpackage) [07:27] dch? [07:28] Yeah, dch will can do it semi-automatically [07:28] s/will // [07:28] s/semi-// [07:28] * RAOF uses dch from a script for nouveau. [07:28] calc: didn't build with -v1:2.4.1-9ubuntu2? [07:28] 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] ScottK: done [07:32] sten_, what are "EOF markers"? [07:38] Is anyone here a Linux kernel guru? [07:38] NCommander: #ubuntu-kernel [07:39] ooh [07:39] handy [07:41] 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] liw: anyways, this produces and EOF in the middle of a file, apparently: [07:42] liw: echo "This is normal text" > orig.txt ; echo >> orig.txt ; echo "This is line 3 of normal text" >> orig.txt [07:42] liw: then, [07:43] liw: echo "This is going to be pre-pended text" > additions.txt [07:43] Good morning [07:43] liw: and finally, cat additions.txt orig.txt > newfile.txt [07:44] 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] 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] sten_: I'm afraid you're mistaken, that command will not produce an EOF where you suggest it does [07:45] liw: (of course, I was mucking with the changelog. It's really nice to know about "dch" :-) [07:46] slangasek, liw: then why does dpkg-buildpackage fail with this output? [07:46] sten_, http://paste.ubuntu.com/57761/ [07:46] I don't know, your example text isn't exactly a valid changelog entry [07:46] sten_, I think you did something else that went wrong [07:47] sten_, anyway, I'm glad you find out about dch [07:47] indeed, dch is Happy [07:50] 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] 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:51] Launchpad bug 281144 in bluez-utils "Please remove the bluez-utils source from Intrepid (dup-of: 281135)" [Wishlist,Confirmed] https://launchpad.net/bugs/281144 [07:51] Launchpad bug 281135 in bluez-libs "Please remove bluez-libs from Intrepid" [Low,Fix released] https://launchpad.net/bugs/281135 [07:52] StevenK: argh, that would be me not being able to read [07:52] * StevenK removes it [07:52] StevenK: thanks [07:54] 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] (steps to replicate: change ipv6 on L11 to off, reboot, attempt to start a gnome session) [07:59] 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] pitti: I'm not sure what to do about libflashsupport -- some people say kill it, and others say it is useful. [08:01] wasn't there discussion about libflashsupport being the cause of all flash crashes everywhere? [08:01] and/or conflicting with pulseaudio? [08:03] slangasek: can you please commit your hal change to bzr? [08:03] oops [08:04] yes, sorry [08:04] slangasek: That's what I've heard. But I've heard others say it makes Flash work with Pulse ... [08:04] So, I'm fairly confused about it. [08:06] StevenK: I don't know about libflashsupport, I'm afraid; I think we shuold ask ogra [08:07] pitti: Sounds good to me, I need to ask him about the lpia kernel, too [08:10] pitti: done [08:11] slangasek: thanks [08:19] hrm; how did pwlib build prior to the latest upload, given that it depends on libdc1394-13-dev in universe? [08:23] slangasek: libdc1394 was demoted on the 26/07/2008 [08:23] StevenK: ah, where do you see that? [08:23] slangasek: https://edge.launchpad.net/ubuntu/+source/libdc1394/1.1.0-5ubuntu1 [08:24] slangasek: Specifically, the Superseded section with "Removal requested on 2008-07-27. " [08:24] Er, rather "Superseded on 2008-07-26 by libdc1394 - 1.1.0-5ubuntu1" [08:24] * StevenK glares at his mouse [08:24] ah, yes [08:25] Pity it doesn't tell who changed the overrides. :-) [08:25] yeah :/ [08:25] not that any of us are likely to remember now the reason :) [08:25] well, the build-dep is probably expendable anyway, from what I see [08:25] maybe it just appeared in component-mismatches and we demoted it en masse? [08:26] if it previously was in main, there shouldn't be a problem just promoting it back [08:26] pitti: Speaking of component-mismatches, how does one go about fixing some of that stuff? [08:26] StevenK: main -> universe can "just be done" [08:26] pitti: AFAICS it should never have appeared in component-mismatches since pwlib build-depended on it continuously [08:26] but I think that b-d can be scrapped, checking [08:27] 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] ah, it is needed, the plugin package it builds just winds up in universe [08:27] so yes, I'll re-promote it to main [08:30] ogra: I don't remember now what needed to be done for rasmol, but it's still dep-wait in intrepid... [08:30] 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] if it's supposed to be in main, it should've been seeded by now [08:31] usb-creator is in main, and is "supposed" to be. [08:32] bluez-utils erroneously appears, but that has to wait for a britney run [08:33] Reverse-Depends: Rescued from sendmail] [08:33] The hell? Like sendmail is in main anyway [08:34] the source is (libmilter) [08:34] Oh, eeek. [08:36] 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] StevenK: also, please NB that some of the main->universe are not justified, because they are in the mobile seed [08:37] StevenK: like midbrowser [08:37] The mobile seed is in universe [08:38] StevenK: it's transitive, and something else wants gst-plugins-ugly0.10 (elisa) [08:38] StevenK: oh, I thought you wanted those packages in main for langpacks, or so? [08:38] pitti: It's a long story [08:38] StevenK: is the result "they are fine in universe"? [08:38] StevenK: and I'm pretty sure that's not britney... [08:39] pitti: The result is "They can stay where they are for the moment" [08:39] slangasek: I was wondering if it was britney or annastacia [08:39] StevenK: hm, then we need to teach britney about the mobile seed [08:39] StevenK: britney doesn't know anything about germinate [08:39] StevenK: otherwise it's just too easy to accidentally demote either those or (less obvious) one of their dependencies [08:41] 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] Ïðèâåò âñåì. [08:52] Ñêàæèòå, ó êîãî ïîëó÷èëîñü ñäåëàòü êóá è 4 îòäåëüíûõ ðàáî÷èõ ñòîëà? [08:56] mvo: hi [08:56] mvo: did I see the "u-m must revert fglrx migration" bug I threw at you last night? [08:57] pitti: yes, I talked with bryce_ about it, I upload the revert soon [08:57] * pitti hugs mvo, thanks [08:57] cheers [08:57] mvo, thanks :-) [08:59] pitti: Hi [09:00] 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] bug 256131 [09:00] Launchpad bug 256131 in rarian "failed to upgrade : "update-xmlcatalog: error: entity already registered"" [High,Fix committed] https://launchpad.net/bugs/256131 [09:00] jibel: I know [09:01] jibel: that's why the rarian task is still open; I need some feedback on ubuntu-devel@ on it [09:02] oh, ok. [09:17] mvo: there are lots of dupes of the screensaver bug coming in :( [09:19] davmor2, meh, ok [09:20] 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] 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] mvo: this morning after I drop my wife off at a meeting so np's there [09:26] Koon, thanks, did you do some bug triage on the screensaver bugs? or did you ran accross it yourself? [09:26] mvo: I ran accross it myslef, found the two bugs and merged them [09:27] mvo: do you already have an idea how to fix it or are you still searching ? [09:29] 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] Koon, what video card/driver do you use? [09:29] for me it went away after upgrading to compiz 0.7.8 [09:30] 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] I have it both on my laptop (Intel X3100) and my workstation (nvidia 8xxx) [09:32] Koon, ok, thanks [09:33] mvo: if you can't reproduce it, don't hesitate to ping me for any test you may require [09:34] Koon, thanks, will do [09:36] ScottK: well, I *tried* to fix it. Then managed to somehow get an interesting dpkg error. [09:39] mvo: I commented on bug 282830; update-manager is still failing for me in that VM despite apt-get dist-upgrade -y working. [09:39] Launchpad bug 282830 in update-manager "update-manager claims to do a release upgrade, but doesn't actually install packages" [Undecided,New] https://launchpad.net/bugs/282830 [09:40] sbeattie, ok, good (or bad) - that narrow the problem down a bit, I check it out and sent you debug patches [09:41] mvo: cool. it will probably have to wait a few hours, I need to sleep soon. [09:41] 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] Launchpad bug 269904 in nvidia-graphics-drivers-177 "Screen refresh problems with nvidia on intrepid" [Medium,Confirmed] [09:41] sbeattie, sure, it must be really late in your TZ [09:43] tseliot, no thanks for pointing it out [09:43] mvo: I think it's something worth having ;) [09:44] tseliot, yeah, I need to check how complete it is before adding it [09:44] ok === mdz_ is now known as mdz [10:00] 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] liw: it'll tell you that you don't have the applet and that you need to update the configuration [10:02] seb128, what configuration is that? (I already told it not to bother) [10:02] those are question for mvo ;-) [10:03] but right the migration tool is not really smart right now [10:03] I think it doesn't verify if the switch user applet is installed either before adding it [10:03] I admit that I'm probably an unusual case for removing the quit button in the first place [10:03] 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] liw, so while we could do it with some extra work so far I stayed away from it assuming it would be somewhat unusual === ara_ is now known as ara [10:04] 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] liw, it moves the fast-user-switch applet to the top right corner and removes the quit button object [10:07] mvo, how does it do that? that still requires talking to the users gconf, doesn't it? [10:09] 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] liw, htere is a InteractiveUpgradeHooks wiki page with more information [10:10] liw, its a somewhat underutilized feature, but quite useful for cases like this [10:11] 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] TomaszD: you mean the package doesn't build one/ [10:12] ? [10:12] pitti, https://translations.launchpad.net/ubuntu/intrepid/+source/cheese/+imports [10:12]