[01:16] crimsun: AFAICS you're not currently subscribed to bugs for pulseaudio; but perhaps you could take a look at bug #187469 since you're the last uploader? [01:16] Launchpad bug 187469 in pulseaudio "pulseaudio should have versioned dependency on sysv-rc for use of update-rc.d multiuser" [Medium,Confirmed] https://launchpad.net/bugs/187469 [01:17] * TheMuso checks whether he is on the audio team, but doesn't think so. === Ubulette_ is now known as Ubulette [01:19] Ok, the kernel team is a member of the audio team, but crimsun deactivated himself a while ago. [01:19] right; that didn't stop him from uploading the package 5 days ago ;) [01:20] I know, I think he just tracks debian and upstream. [01:20] And has a look at the buglist from time to time. [01:20] But I'm only guessing here. [01:20] if you're saying you'd rather take care of the bug yourself, be my guest :-) [01:21] No, I'm just saying that unless he's around now, he may not get to it for another day or so, so I'll take a peak, since I intend to get more involved with audio work in Ubuntu anyway. [01:23] slangasek: I'd do it, however it may be quicker for a core-dev to do it, as I don't yet have core-dev membership. [01:23] Since its only a small change. [01:24] * ScottK2 wonders when the Tech Board will get to processing applications.... [01:24] ScottK: I was supposed to be on Tuesday, but only mdz was around, so it was a no go. [01:25] So it's in two weeks then ... [01:25] * ScottK2 hopes more people get added to the agenda. [01:25] DOn't know. mdz said he'd contact the others and see what could be sorted. [01:26] ScottK: Have you been emailed to ask if you can attend a meeting? [01:26] I don't remember seeing one. [01:26] If it was CCd to the mc list. [01:26] TheMuso: No. I haven't. I'm waiting on that still. [01:26] IIRC I was the next applicant after you, so I was expecting to hear something maybe after your meeting. [01:29] Is there a way to remove unnecessary binary files from a source package? [01:30] The diff doesn't cover it; seems like it'd need a new source archive. [01:30] IntuitiveNipple: rm it in the rules file [01:31] Mithrandir: but how would that change what's in the original tgz ? [01:31] IntuitiveNipple: it wouldn't [01:31] but why is that important? [01:31] For that you need to repack the tarball. [01:32] I discovered in fixing these bugs in the mysql-query-browser package that it has been shipped with the .lo and .o 32-bit binaries in the gtksourceview sub-package [01:32] Well, it's a lot of space for one, not good practice for two, and the 32-bit static stuff was causing various SIGSEGVs for amd64 and once those were fixed, causing failed 32-bit builds! [01:33] I'll push the debdiff for now but it'd make sense to clean it up, although I'm not sure how to go about and I've wasted a day on this already [01:33] sure, tell upstream to fix it [01:33] slangasek: / TheMuso: on it, I'll upload a new one with a couple other bug fixes. [01:34] crimsun: Ok. [01:34] upstream would be... debian, or mysql? [01:34] * TheMuso needs to get onto pulse's lists and bug tracker. :) [01:34] IntuitiveNipple: mysql, I'd say. [01:34] Hmmm, that'll be fun :) [01:35] I've built 32 & 64 bit here now, I'm just confirming it on my PPA before I publish the debdiff [02:12] * TheMuso -> getting lunch. === asac_ is now known as asac === lamont` is now known as lamont === fabbione is now known as thegodfather [07:15] good morning [07:19] moin [07:19] hi stgraber [07:20] Good morning [07:24] Morning pitti. [07:26] hey TheMuso [07:30] soren: oh, oops; libvirt is in main, but needs xen; xen-3.1 is in universe, and the newer xen-3.2, too [07:30] soren: since I understood that we only want to support kvm in hardy [07:31] soren: any idea what to do about this? [07:31] soren: (and libvirt still uses xen 3.1) [07:35] pitti: When will the first Alpha4 candidates be released ? [07:36] stgraber: I don't know, that's slangasek's now [07:36] stgraber: the current live images are out of date [07:36] maybe because of the gnome-control-center and gnome-settings-daemon file conflict, I haven't checked yet [07:37] Good morning [07:45] pitti: libxen3.1 at least used to be in main? [07:45] soren: yes, it was [07:45] hi warp10 [07:45] pitti: It was needed for libvirt which in turn was needed by redhat-cluster-suite. [07:46] hey pitti! [07:46] bdmurray: do you plan to get new versions of py-lp-bugs and bughelper uploaded soon? [07:46] pitti: What changed? [07:46] soren: if the server team is really ready to support and endorse xen-3.2, I can promote it again [07:46] soren: changed> first, we got xen-3.2, and second I was told by mdz that we should have never really had xen in main in the first place [07:46] pitti: Well, afaik, we were never ready to support and endorse xen-3.1, which is why most of it stayed in universe. Only libxen was in main. [07:46] soren: and thirdly someone told me that 'kvm it is!' for hardy [07:47] soren: ok, I see [07:47] pitti: I see. [07:47] pitti: Erm.. [07:47] soren: so, is it possible to build libvirt against xen-3.2? [07:47] soren: then I'll promote the client libs to main and leave the rest in universe [07:47] pitti: I'll try. [07:52] pitti: Er... It's still stuck in NEW. [08:47] mvo: What CPU do you have in that KVM-able AMD machine? [08:51] soren: what exactly? [08:51] pitti: xen 3.2 [08:53] soren: hm, it only built on i386 so far [08:53] pitti: Yeah. I'll poke zul about it this afternoon, when he shows up. [08:54] pitti: It seems to fail because the binary-arch target assumes latex is present, but texlive is int b-d-i. [08:54] gnome-settings-daemon broken in last updates [08:57] soren: a am2 X2 (model 107, stepping 2) - let me know if you need the full /proc/cpuinfo output [08:58] mvo: Hm... I'm looking at a AMD Athlon 64 X2 5600+ [08:59] mvo: That wouldn't happen to be the same, would it? [09:01] soren: no, mine is just a 4400+ :) [09:01] soren: are you looking into buying one? [09:01] mvo: I'm strongly considering renting one. [09:02] Is Jono Bacon here? [09:03] I'm very happy with mine, upgrade testing runs nice and smooth now [09:05] Awesome. [09:07] There. Ordered. === cjwatson_ is now known as cjwatson [09:11] coyctecm: sometimes, though not right now [09:15] cjwatson, ok [09:15] pitti: FYI, I edited Bugs/HowToFilter to add locking to the rules that deliver mail to actual folders rather than /dev/null, as otherwise you can corrupt folders if you're unlucky [09:16] cjwatson: oh, is that the final : in :0: ? [09:17] cjwatson: thanks, I wasn't aware of that actually [09:17] yeah, it is [09:18] cjwatson: wow, I hadn't expected procmail to be dangerous by default [09:19] * pitti fixes his local .procmailrc then [09:20] pitti: What exactly needs fixing? Mine seems to work fine. [09:20] so does mine; TBH I'm not sure what can go wrong [09:23] if two procmails try to deliver to the same folder concurrently and you haven't specified a lockfile (just putting ':' at the end of the rule header uses a default folder-specific lockfile) then you can get the usual corruption you might expect from two programs trying to write the same file at the same time [09:24] probably lost mail, but if you're really unlucky I suppose interleaved mail is just about possible [09:24] Maildir ftw! [09:24] (I'm not sure exactly how procmail opens files) [09:24] soren: a lockfile's hardly rocket science :) [09:25] cjwatson: True that. [09:25] Nevertheles.... Maildir ftw! [09:26] I prefer maildir on my desktop/laptop, too, but on the server mbox is nicer for backup === doko_ is now known as doko [09:27] * TheMuso never runs more than one procmail at a time here, well at least doesn't think so, with using fethcmail. [09:27] pitti: You think? [09:28] soren: ten files, one for each folder, is much easier to handle/check/move around than a million subdirectories [09:28] pitti: I found that having to back up a multi-GB mbox just because one mail was edited was quite annoying. [09:28] soren: yeah, huge mboxes are painful; I don't have them, though [09:29] pitti: Well, I used to host mail for quite a few people. I couldn't just tell them to "please don't use large folders" :) [09:29] WEll, I could, but they wouldn't listen. [09:29] heh [09:29] soren: lol [09:34] pitti: thanks for checking the apport mail (attachments being patches) [09:34] dholbach: gern geschehen [09:43] Will Alpha 4 be released today? [09:51] SlimG: yep === cjwatson_ is now known as cjwatson [09:52] TheMuso: on my system, fetchmail delivers to exim, which can process multiple mails concurrently [09:52] (sorry, pinged out, you may have got that twice) [09:53] cjwatson: No I didn't, and I understand what you're getting at. [09:53] stgraber: Any knowhow on when? 1 hour? 5 hours or 11 hours from now? :) [09:55] SlimG: well, the release manager is in the US timezone + we haven't really done any important testing yet (ISO aren't even on the tracker) [09:55] SlimG: so it'll likely be late today [09:56] mkay, thanks for the info stgraber, I apprechiate it [10:09] way cool. fully noninteractive self tests of the jockey GTK interface [10:12] Is synaptic ever likely to use policykit for hardy? [10:14] TheMuso: no, very unlikely [10:14] pitti: with dogtail? [10:14] mvo: no, just with using .response() for dialogs and .emit('clicked') etc. for buttons [10:15] mvo: it's not 100% functionality coverage, but it runs through all widgets and dialogs at least [10:15] mvo: since the GTK UI implementation does not have any logic, just an implementation of AbstractUI (which does have the logic and has its own full test suite), that's enough for my purposes [10:16] * mvo nods [10:17] mvo: Ok thanks. What about gnome-app-install? [10:18] TheMuso: it uses synaptic as its backend (for all the operations that require root) [10:18] mvo: Oh ok then., [10:19] TheMuso: any specific reason that you ask? I haven't looked what it would take yet [10:20] mvo: Just wanting to know so that I can 1) recommend a tool for people to use for package installation who use assistive technology, and 2) be able to target testing for gnome-app-install to find any accessibliity bugs relating to the use of assistive technology. [10:29] ooh, I nearly have vim omnicompletion for Launchpad bugs working [10:32] seb128: did you notice the gnome-settings-daemon vs. gnome-control-center file conflict for /usr/bin/gnome-settings-daemon? [10:32] pitti: yes, I'll upload a fixed version [10:32] seb128: awesome, thanks; so I won't report it [10:33] pitti: that's just an upgrade issue, new g-c-c doesn't contain this one [10:33] apt or dpkg could handle that better [10:41] http://people.ubuntu.com/~cjwatson/tmp/lp-omnicomplete.png [10:41] cjwatson: cool! [10:47] cjwatson: Awesome! [10:47] * soren drools uncontrollably [10:48] hi soren [10:48] Hello. [10:48] 'zup? [10:49] soren: taking over the world. pondering what to do, if anything, about MOTU. === Mez_ is now known as Me === Me is now known as Mez [11:53] Hi all! === hunger_t_ is now known as hunger [12:42] Riddell: fancy some support for non-ASCII manual pages in konqueror? [12:43] cjwatson: in the man:/ ioslave? [12:43] yeah [12:43] cjwatson: could do, what needs changed? [12:43] about to attach a patch to bug 44548, just wanted to know if you cared :) [12:43] Launchpad bug 44548 in kdebase "Problems with accentuated characters in man pages" [Medium,Confirmed] https://launchpad.net/bugs/44548 [12:46] cool [13:03] Hi, seb128. Did pidgin crashed today with you? (I guess it's glib related) [13:04] jwendell: it does crash on one of my boxes but not on the one I'm using right now [13:04] seb128, is g-s-d wanting to overwrite /usr/bin/gnome-settings-daemon in g-c-c known ? [13:05] (upgrade error here) [13:05] seb128, I've got a trace, gonna fill a bug [13:05] ogra: yes and the fix has been uploaded some hours ago [13:05] jwendell: where? [13:05] seb128, launchpad? :) [13:05] jwendell: I doubt anybody reads piding bugs on launchpad, in case you want to file there [13:05] seb128, thanks [13:05] :( [13:05] jwendell: k, feel free, don't expect a quick reply though [13:06] jwendell: and I doubt it's a pidgin issue, it didn't change for weeks now [13:06] seb128, my guess is glib [13:07] seb128, look at the crash line: [13:07] IA__g_logv (log_domain=0x0, log_level=G_LOG_LEVEL_CRITICAL, format=0xb77b0cd4 "%s: assertion `%s' failed", args1=0xbfe9cd8c "?G\216·\nÃ\215·PÜô·\027") at /build/buildd/glib2.0-2.15.4/glib/gmessages.c:503 [13:07] 503 /build/buildd/glib2.0-2.15.4/glib/gmessages.c: No such file or directory. [13:07] in /build/buildd/glib2.0-2.15.4/glib/gmessages.c [13:07] that usually means it hits an assert [13:08] seb128, maybe that define in glib being deprecated? [13:08] what do you mean? [13:09] seb128, G_GNUC_[PRETTY_]FUNCTION ? [13:10] why would that create a crash? [13:10] that's a build time thing [13:10] seb128, ok, I'm sorry [13:10] no need to be sorry [13:10] but I don't think it's due to that ;-) [13:14] jwendell: looks like there is no bug on launchpad about that yet, maybe use apport to send it? [13:15] seb128, apport is ignoring the pidgin crash [13:15] what do you mean? [13:15] seb128, does it ignore a crash after three times hitting 'don't send the bug' button? [13:15] yes [13:15] hehe [13:16] seb128, anyway I got a backtrace with gdb [13:16] seb128, just filled the bug upstream [13:16] you can still send the crash using apport [13:16] ok [13:16] just go to /var/crash [13:17] and double click in nautilus on the crash you want to report [13:17] nice [13:17] or use apport-cli or apport-gtk [13:18] seb128, the backtrace contains my password. Is there any way to hide it after the bug is filled? [13:19] apport bugs are marked private by default [13:19] and you can edit the description after sending it [13:19] the coredump is removed when the bug is retraced [13:19] seb128, but can't edit an attachment :( [13:20] hum, right [13:20] did you send it already? [13:20] seb128, nope [13:20] you can remove an attachment though [13:20] don't send it if you don't like that [13:20] seb128, sent *edited" backtrace to upstream [13:20] ok [13:21] Wow... a debhelper-less package. That's something you don't see every day. [13:22] soren: I've plenty of cdbs packages ;-) [13:22] seb128: cdbs uses debhelper, too. This one is *actually* debhelper-less. [13:23] soren, which one? [13:23] heh, is that something still maintained? [13:23] Seveas: dnsmasq [13:23] Seveas: Oh, yes. [13:23] Er.. [13:23] soren: I wrote a debian/rules without debhelper once, not again ;-) [13:23] seb128: Oh, yes. [13:24] pitti: I've uploaded the konqueror flash SRUs ready for your next archive day [13:25] pitti: I can't work out what the status of the flashplugin-nonfree SRUs is [13:26] ohhhh [13:27] i just did a 'rm *' on my $HOME. is there an 'undelete'? === cjwatson_ is now known as cjwatson [13:30] jwendell: Restore from backups [13:30] jwendell: no, sorry [13:30] there are some low-level methods for doing it on some filesystems but they are much less likely to work on ext3 [13:30] * persia notes that there are data recovery tools, but they are not easy to use, and installing them can cause data corruption [13:31] if you want to try, you should remount the filesystem read-only immediately [13:31] if you want to use them though i'd suggest hitting the power button immediately [13:31] oh, right [13:31] fortunately I have a backup, from last week. And, for my luck, I didn't '-rf' [13:31] colins suggestion is better :) [13:32] * ogra did that recovery thing once ... massively painful === chand is now known as cdl === cdl is now known as c2l [13:48] asac: I think we should just do a quick SRU for [13:48] flashplugin-nonfree now [13:50] Riddell: Even if it breaks konqueror (or did that get fixed)? [13:52] persia: that's been fixed noew [13:52] Riddell: how? [13:52] now [13:52] * persia agrees with Riddell that's it's time for the SRU [13:52] asac: update the md5sum and whatever else needs done [13:52] where? by adobe or konqueror? [13:53] asac: konqueror has a workaround for adobe's changes [13:55] Riddell: could you do it this time? ... i am completely swamped because moz has changed sec release date from "in two weeks" to "now" [13:56] i could do it tonight ... or tomorrow [13:56] asac: I can probably do it, but is it just the md5sum that needs changed? [13:57] brandon did an upload previously but I can't see any debdiffs from him [13:57] imbrando1: alive? [14:00] ok lets wait a bit ... if he isn't avail we can talk about plan B :) [14:01] have to go for lunch anyway now === \sh_away is now known as \sh [14:27] seb128: do you know the internals of yelp much? [14:27] cjwatson: no, why? [14:27] seb128: I'm trying to make it support UTF-8 manual pages by calling out to 'man --recode UTF-8' [14:27] err, support any non-ASCII manual pages that is [14:28] seb128: but weirdly, with my patch it says it can't find the file and then displays it anyway :) [14:28] cjwatson: maybe attach the patch upstream and mention the issue? they are usually quite responsive [14:29] it's not an upstreamable patch unfortunately [14:29] as in it depends on man-db which is distro-specific [14:29] ah, ok [14:30] whom would I be best off talking to? [14:30] hi all [14:30] completely offtopic question but hopefully answers :) [14:30] cjwatson: maybe ask mdke when he's around, he's often in contact with DonS who is upstream [14:30] say you want to develop a gpl application which uses tango icons which are licenses under the cc-sa [14:30] and the application is a web application and the icons used as part of the theme [14:31] is that possible? [14:31] cjwatson: open a bug in launchpad with the patch so it's easy to point upstream to it [14:34] I'll attach it to bug 154829, which is the relevant one [14:34] Launchpad bug 154829 in yelp "Yelp uses wrong encoding for localized manpages" [Low,Triaged] https://launchpad.net/bugs/154829 [14:34] thanks [14:35] thank you [14:40] seb128, definately it' a glib bug. I got exactly same backtrace for a crash in evolution [14:41] jwendell: do you have the backtrace online somewhere? [14:41] jwendell: what do you do to crash evolution? [14:42] seb128, I was about to create a filter based on mailing list [14:42] seb128, wow, there are similar bugs [14:43] bug #187603 [14:43] Bug 187603 on http://launchpad.net/bugs/187603 is private [14:43] bug #187637 [14:43] Bug 187637 on http://launchpad.net/bugs/187637 is private [14:45] jwendell: those are totally different backtraces [14:45] seb128, but the title is the same :) [14:46] seb128, Bug #187667 [14:46] Bug 187667 on http://launchpad.net/bugs/187667 is private [14:46] seb128, this is mine [14:46] jwendell: right, which means that a g_return_if_fail_warning() condition has been hit [14:46] seb128, exactly [14:46] jwendell: but any program or library can use g_return_if_fail_warning() on any condition [14:46] that doesn't mean it's a glib bug or that they are similar [14:47] seb128, indeed, but it's a bit weird to have various programs crashing *today* with this same assert [14:48] dholbach: is pidgin crashing on your hardy box where evolution doesn't work? [14:53] jwendell: and your liferea crash too, bug 187622 [14:53] Launchpad bug 187622 in liferea "liferea-bin crashed with signal 5 in IA__g_return_if_fail_warning()" [Medium,New] https://launchpad.net/bugs/187622 [14:53] jwendell: can you try if downgrading glib fix your issue? [14:54] pochu, yes [14:54] ah [14:54] seb128, sure, if you tell me how :) [14:54] let me try something [14:54] * jwendell thinks seb128 found the problem :) [14:55] jwendell: how to trigger the evolution crash? [14:55] jwendell: not really [14:56] seb128, right click on a message, create an rule->based on mailing list [14:56] jwendell: does opening the properties dialog work correctly? [14:57] seb128, what properties? you mean preferences window? [14:57] jwendell: yes [14:57] seb128, oops, crash again [14:58] pitti: can you give-back rtfm please ? [14:58] Lutin: done [14:59] pitti: thanks [15:00] <\sh> hmmm [15:01] <\sh> pitti, did you have any problems with gtk+2.0 sources fetching with ia32-libs/fetch-and-build? [15:01] \sh: if source/binaries are out of sync, that happens [15:02] <\sh> pitti, hmm..let me update my local system...apt-get source gtk+2.0 works for me until now ;) [15:02] * jwendell wonders if seb128 has 2 machines, one for daily use and other for tests and crashes :0 [15:02] :) [15:02] <\sh> pitti, na, it will fetch a nwe version, yes but works [15:02] <\sh> ah i386 [15:03] jwendell: no, not due to the new gtk [15:03] jwendell: what architecture do you use? [15:03] seb128, i386 [15:04] Btw, has anyone considered making dpkg use a faster database than plaintext sequential files? [15:04] asac, pitti: flashplugin-nonfree updates uploaded for gutsy and feisty, edgy and dapper are harder to do [15:05] <\sh> nope i386 works as well [15:05] jwendell: https://launchpad.net/ubuntu/+source/glib2.0/2.15.3-0ubuntu1/+build/496254 [15:05] jwendell: you can get binaries from there, download those you need and sudo dpkg -i *.deb [15:10] pitti: why don't the buildds install the build-depends-indep (or at least seem not to) ? [15:10] seb128, same thing. (must i reboot?) [15:11] jwendell: no need to reboot, just restart the application [15:11] jwendell: or try to start pidgin [15:11] Lutin: the i386 one does; other arches don't (they just do dpkg-buildpackage -B) [15:11] seb128, same crashes in pidgin and evolution [15:11] jwendell: ok, so that's not glib [15:12] jwendell: want to try downgrading gtk? https://launchpad.net/ubuntu/+source/gtk+2.0/2.12.5-1/+build/495133 [15:15] pitti: what's the reason for this ? [15:16] Lutin: Arch: all should be built just once, not 5 times in vain [15:16] Lutin: so in Ubuntu, the i386 buildds build Arch: all packages, and the other arches do -B [15:16] Lutin: that's why we have one more i386 buildd [15:19] seb128, I quit, same crashes [15:19] jwendell: that is weird [15:20] pitti: is anyone working on adding consolekit support to login? [15:20] pitti: eek, I was looking at the wrong build log. got it, thanks [15:20] I'm a bit surprised that isn't there === jwendell is now known as jwendell|lunch === jdstrand is now known as jdstrand_ === jdstrand_ is now known as jdstrand [15:23] cjwatson: not to my knowledge ATM; there is a PAM integration package for CK, but I never tested it; do we need it? === PriceChild is now known as pmdgandalf_ === pmdgandalf_ is now known as PriceChild [15:28] are there any archive admins online that can shove transmission 1.00-1~gutsy1 through binary NEW? [15:28] it's causing repo breakage for backports users (bug 187526) [15:28] Launchpad bug 187526 in transmission "can't install/upgrade package in gusty if gusty-backports is enabled" [Undecided,New] https://launchpad.net/bugs/187526 [15:28] Riddell: why? [15:29] Riddell: konqueror not updated yet? (thanks btw) [15:39] dholbach, remind me, how do you tell whether a bug is in the sponsoring queue? [15:39] seb128: yes :) [15:39] mpt: if ubuntu-{universe,main}-sponsors is subscribed [15:39] dholbach: can you handle the archive issue I mentioned above? [15:39] dholbach, excellent, thanks [15:40] jdong: no, I'm afraid I'm not an archive admin [15:40] (which is probably a good thing) [15:40] dholbach: oh, I could've sworn you were! oops :) [15:40] jdong: I'm one, what do you need? [15:40] seb128: it seems like i386 gutsy-backports transmission is stuck in binary NEW while everything else went through [15:41] bug 187526 [15:41] Launchpad bug 187526 in transmission "can't install/upgrade package in gusty if gusty-backports is enabled" [Undecided,New] https://launchpad.net/bugs/187526 [15:42] jdong: everything else had no need binaries likely? [15:43] asac: edgy and dapper are harder to do because they need updating from flash 7 and there's debconf stuff. it didn't work when I tried at any rate, probably I just missed somehting [15:43] seb128: yeah, that's what I'm guessing. the transmission metapackage seems new [15:43] seb128: though it's really odd it seems like only i386 had the problem? [15:43] jdong: no, what is new is the transmission-common [15:43] ah [15:43] dholbach, would it make sense for the sponsoring queue to be handled more explicitly by Launchpad, rather than by subscribing/unsubscribing a particular team? [15:43] jdong: only i386 build arch all [15:44] well that explains that too :) [15:44] mpt: how do you think that should happen? [15:44] jdong: accepted [15:45] dholbach, I don't know -- I'm sure you or someone has explained to me how the queue works at some stage, but I've forgotten [15:45] but Launchpad should make easy the process of getting stuff fixed [15:45] mpt: in the perfect world we'd have NoMoreSourcePackages and everything would be in one or the other bzr branch :-) [15:45] seb128: thanks :) [15:45] you are welcome [15:46] dholbach, ah, so sponsoring would be replaced by merging? [15:46] mpt: yes [15:46] ok [15:46] Is NoMoreSourcePackages likely to happen in the next, say, 3 years? [15:47] * jdong gives mpt the optimism award of the day [15:47] mpt: maaaaaybe [15:48] jdong, no no, I'm being pessimistic, that's about how long it would take to implement anything sponsorship-queue-specific in LP ;-) [15:48] <\sh> pitti, requestsync is broken ;) There is no project named 'distros' registered in Launchpad. ;) [15:49] if we all work towards it it should be achievable ... [15:49] <\sh> pitti, forget it, I'm using an old one [15:49] it's a lot of infrastructure change, but I can't wait for it to happen :) [15:49] \sh: it's in ubuntu-dev-tools nowadays [15:50] <\sh> pitti, yepp..I just had the old one still in my all the time in svn ~/bin/ dir ;) [15:52] mvo: can you sponsor me nvidia-settings again? bug #178255 (though I must admit, that I didn't test-build it since I added the debdiff) [15:52] Launchpad bug 178255 in nvidia-settings "NVCtrl.h and NVCtrlLib.h should be installed in /usr/include/NVCtrl not /usr/include" [Undecided,Confirmed] https://launchpad.net/bugs/178255 [15:53] * ogra kicks evo in the guts .... with run-up [15:53] evil thing ... [15:54] mpt: ah yes, but how long for it to be fixed, after it being *broken* in LP? [15:54] :) [15:54] eh? [15:55] mpt: first implementations are often wrong :) [15:55] ogra: what did it do? [15:55] * ogra cries ... why does my mailer have to be so mean to me *sniff* [15:56] seb128, it decided to collapse all threads after the last crash [15:56] because no-one's implemented a good one yet? :-) [15:56] and obviously the 2exapnd all threads" function always only expands one level [15:56] ogra: ctrl-T [15:56] i'm clicking my ass off to get to the last (new) message in a thread here [15:57] seb128, yay, now all collapsed again [15:57] ctrl-t wasnt such a good idea [15:57] do it again [15:57] it switches threading off/on but doesnt expand the threads [15:58] does * do anything? [15:58] actually if i expand one it collapses it again [15:58] i'll just click my way through [15:59] oh, another restart helped :) [16:00] <\sh> ogra, use claws ,-) [16:01] \sh, or balsa :) [16:02] evolution is good [16:02] <\sh> ogra, hmm..balsa...tested it only once....I like claws now ;) it works ;) [16:03] balsa doesnt have much overhead ... thats what i like about it [16:04] claws ... to many options i'll never need ... [16:05] * ogra remembers times where mail clients were 300k big :) [16:05] <\sh> cjwatson, how do I tell your new "show LP bugs" addon to sort for importance e.g.? :) [16:05] which gui mail client comes with less than a meg nowadays .... ? [16:06] <\sh> ogra, these days all mail clients were named mail, elm, pine (or mutt) ;) [16:06] ogra: telnet is 90k here :) [16:06]