[00:03] * stgraber still has a new ltsp, ltspfs, ldm and pastebinit to upload before FF (doing intensive testing at the moment as I'll both release and package these at the same time) [00:03] (probably the most tested version of LTSP ever ;)) [00:03] stgraber: as long as the topic isn't changed there is no FF :P [00:03] sebner: can we lock it somehow ? ;) [00:04] stgraber: become op and kick everyone else :P [00:04] I'm pretty sure it's against some part of the CoC :) === maxb_ is now known as maxb [00:05] stgraber: it runs under the name "netsplit" ;D [00:05] rofl [00:05] sebner: ok, so I need to bribe some freenode admin ? :) [00:06] stgraber: what still needs to happen with pastebinit? [00:07] highvoltage: cyphermox is doing pre-release testing, then I'll release 1.0 and push it to Ubuntu [00:07] stgraber: no one needs to know *psssssst* [00:07] ah [00:07] has been a long long time since I last released and I really want the new version in Lucid (as it brings a flexible way of adding pastebin servers and a few others long awaited features) [00:08] I've been running it for a few months now without any issue and I guess some others too but I want to make sure everything works before releasing [00:08] stgraber, i swear people feel this weird need to change the way they design pastebin sites :) [00:08] * slangasek creates pastebin.csszengarden.com [00:09] cyphermox: yeah ... that sucks :) especially the ones adding some javascript "human check" ... I had to drop quite a few pastebin websites because of that [00:09] slangasek: as long as you use a supported pastebin engine, it's fine, it'll work ;) [00:09] stgraber: Be *really, really* fast on that release, as we're technically in FeatureFreeze (although I haven't seen the mail yet) [00:10] persia: yeah, for pastebinit, I'm ready to tag, just waiting on some additional testing. For LTSP, I'm waiting on LP to build PPA packages faster ;) [00:10] though I guess I can already go ahead and tag ldm and ltsp, as only ltspfs is having a small issue worth fixing before releasing [00:10] stgraber: I understand. I've been CPU-limited for the past 12 hours for the same reasons :) [00:18] sebner: uploaded [00:19] * sebner hugs crimsun [00:21] gn8 folks [00:47] * Laibsch curses his computer (and karmic) for constantly overheating and shutting down at inopportune times since karmic [00:57] there's an opportune time to overheat and shut down? [00:59] yes [00:59] just before switching off ;-) [02:28] would something in universe Recommends'ing something in Multiverse cause it to FTBFS, or would that only happen from something in universe Depends'ing on something in Multiverse? [02:38] is there something we should do with merge proposals to ensure main sponsors see them ? [02:39] lifeless: are they subscribed? [02:39] Laibsch: are you saying thats what we should do? Note that I'm not talking about bugs. [02:39] so the bug policies don't apply. [02:39] of course [02:40] ?? [02:40] Do you have a patch? [02:40] something ready to apply? [02:40] A merge proposal. [02:40] superm1: Run time recommends can't cause FTBFS, but that would require the package to move to Multiverse. [02:40] lifeless: do the merge, open a ticket, subscribe sponsors ;-) [02:40] Laibsch: I don't think you understand what I'm talking about. [02:41] maybe not [02:41] you want somebody else to do some work [02:41] correct? [02:41] a merge proposal is a proposal to merge two branches in launchpad [02:41] Oh [02:41] it *is* the record that the work needs to be done. [02:41] its not a bug. [02:41] I thought you were talking about merge/sync kind of merge [02:41] for a package [02:41] no, because for those we have procedures. [02:41] well, yes [02:42] so I ask again, to the floor. "is there something we should do with merge proposals to ensure main sponsors see them ? [02:42] " [02:42] I stay away from bazaar as much as possible, so I have no experience with that and can't help you [02:44] it's not even obvious where merge proposals are listed for ubuntu, from what I can see [02:44] I can find a few through ~ubuntu-main-sponsors [02:45] ajmitch: most will be on ~ubuntu-branches at this point [02:45] ajmitch: there is discussion on this on the udd list [02:46] right, found that thread [02:47] [join the list ;P] [02:47] * ajmitch is on the list [02:47] but the discussion was more than 2 weeks ago :) [02:48] paged out already? [02:49] yep [03:44] anyone here have a some spare knowledge to share on how a seed works ? [03:44] the reason I ask is that the uec builds have 'uec^' as a seed. [03:45] the install process does 'apt-get install uec^' [03:45] at this point in karmic, that is resolving to 2 different packages providing a kernel [03:46] linux-image-2.6.31-14-virtual and linux-image-2.6.31-19-virtual [03:46] i'm not sure when it started, but I think it might be related to a kernel being added to -updates [03:50] hmm... digging a bit http://people.canonical.com/~ubuntu-archive/germinate-output/ubuntu.karmic/uec lists the older package [03:54] anyone happen to know how that is updated? === Laibsch1 is now known as Laibsch [04:24] kirkland now that the other two builds have caught up, could you by chance release myththemes and mythplugins so tonight's media will pick em all up? (or some other archive admin seeing this) === micahg1 is now known as micahg [04:37] * lamont wants to stab libtool [04:37] -version-info 61:4:1 \ [04:37] ...-Wl,-soname -Wl,libisc.so.60 -o .libs/libisc.so.60.1.4 [05:01] superm1: I'll look at that for you in a sec [05:03] thanks [05:15] superm1: myth{themes,plugins} accepted. [05:16] awesome, thanks! [05:16] I'm trying to apply an upstream patch to gnome-media, which is maintained in bzr. I applied the patch, but I have no idea how to go about building the package when its maintained in bzr. Is there some place I can see a guide for this or could someone guide me through it? [05:37] whoa [05:37] this rsyslog bug is awesome [05:37] https://bugs.launchpad.net/bugs/523610 [05:37] Ubuntu bug 523610 in linux-ec2 "20100218 EC2 image (ami-0512fe6c): Cannot read proc file system: 1 - Operation not permitted." [Undecided,New] [05:37] (happening for me with the linode kernel) [06:46] Good morning [06:46] mdeslaur: yes, I don't think anyone will object against adding apport symptoms post-FF [06:46] mdeslaur: (FF is already in place, btw; but I'll do an upload anyway) [06:50] pitti: do you think an apport symptom for flash would be good? [06:50] micahg: what would it do more than just filing a bug against flashplugin-installer? [06:51] micahg: well, it could check whether you have the proprietary plugin, and not file a bug at all then [06:56] pitti, well good news on the gvfs/gdu pool creation crashes I was seeing... at least with the latest version it looks like it's a simple fix (bug 523634) [06:56] Launchpad bug 523634 in gnome-disk-utility "libgdu0 should Depends on udisks" [Undecided,New] https://launchpad.net/bugs/523634 [06:57] pitti: well, there are multiple flash plugins [07:04] micahg: right, the symptom could figure out which one you are using, and return the correct package [07:04] pitti: right, or ask which browser you are using if there are multiple [07:04] and file it against the browser [07:05] superm1: ah, that would be it [07:05] superm1: I'm glad that the original race was fixed [07:07] pitti: if you're ok with idea, I already filed a bug and can try to create the symptom at some point [07:07] micahg: sure, sounds great [07:09] superm1: thanks, committed [07:10] pitti: how late in the cycle can we get symptoms in? [07:10] micahg: with my release team hat on, at least until beta-2 [07:10] pitti: k, that's what I'll set it for then, thanks [07:10] this helps us to improve quality, and won't break the actual system [07:10] but of course we'll get lots of feedback/bugs for beta-1 and beta-2 [07:10] cool [07:11] so the really useful symptoms should be in before that ideally [07:11] so that we can actually make use of them :) [07:11] pitti: I just don't know if I'll get to it before then [07:11] there's still a lot of mozilla stuff to be done before beta 1 [07:44] leonardr: yup. packaged, uploaded to Debian and then synced. thanks! [08:03] good morning [08:03] aha [08:03] hey dholbach [08:03] heya jdub [08:04] #523610 <- rsyslog missing the dd trick now it's an upstart job [08:10] james_w: can lp:~bmillemathias/ubuntu/lucid/bluez/main and its merge proposal be marked as merged? [08:18] zul, soren: can you guys please seed ec2-init, so that the transitional package is in main? (cleaner upgrades) [08:18] pitti: Sure. [08:20] kees: I removed the obsolete devmapper source, FYI [08:29] pitti: I don't want to put ec2-init in the uec seed, since that is a task and I don't want to install a transitional package as part of a task. It also seems odd to put in on the dvd (again, because it's a transitional package), but the top of supported suggests that everything should go on the dvd unless it's much too large to fit there. [08:29] soren: no no, just "supported" is enough [08:29] no need to install that on any medium [08:29] it just needs to be in main for a clean upgrade from karmic [08:30] Yeah, that's what I thought. [08:30] Oddly, the dvd seed has a "Transitional packages" section. [08:30] soren: ah, perhaps if you use the DVD as a package source for dist-upgrading? [08:31] * soren ponders [08:31] pitti: Yeah, that would make sense, I suppose. [08:32] I'll put a note in the seed explaining that use case. [08:33] dvd seed it is. [08:36] pitti: Done. Thanks for catching this. [08:37] thanks soren [08:38] can somebody please sync bzr from sid? it fixes at least one ugly merge bug [08:38] doing [08:38] * dholbach hugs pitti [08:38] * bryceh waves [08:39] I see rhythmbox-ubuntuone-music-store was added to the seeds, but no such package exists. Is that intentional? [08:39] pitti, I got the X freeze apport hook working today :-) [08:39] hey bryceh [08:39] bryceh: ooh! you were able to produce a freeze? great! [08:40] pitti, and got a *single* .crash file generated in /var/crash === steveire_ is now known as steveire [08:44] Oh, I see it's in the NEW queue. Never mind. === debfx_ is now known as debfx [08:54] RAOF: your most recent libdrm upload doesn't seem to be marked uploaded in the git repository? [08:55] slangasek: That would probably be because I didn't upload it; bryceh did. I can't upload libdrm, not being in ~core-dev :) [08:56] RAOF: well, you have commit access to the repo at least, could you commit that? [08:56] Yep. [08:56] (I don't have commit access to the repo; request pending) [08:58] erf [08:58] we really need to decide git vs. bzr for maintaining all this stuff [08:59] I'd really, really like bzr. If only everyone else used it, too :( [08:59] I always assumed that core-dev's rights include those of motu, is my assumption wrong? [09:00] RAOF, ditto [09:00] if I understand mako's comment on http://revu.ubuntuwire.com/details.py?upid=7876 correctly, he's not able to contribute to revu even though he's a core-dev [09:01] If someone could spend a month or so making bzr-colocated work, I could just drop git entirely. [09:01] does ubuntu use dkms? [09:02] mtx_init, yes [09:02] thx [09:03] bryceh: the source package has an ubuntu version number, points at a git repo, and the git repo has an ubuntu branch, so I assumed that was official? [09:04] if you're telling me I can ignore this in favor of lp:ubuntu/libdrm, I'll do a little dance :) [09:04] slangasek, no your original assumption is correct [09:04] drat [09:04] :-) [09:05] we started using git for maintaining the packaging before a lot of james_w's bzr stuff became available [09:06] whats the best way to get into kernel level development. Ive takes OS classes before and written system calls and stuff. Ive added ACL's to a FS and created my own message passing ipc. But the whole thing is incredibly intimidating. any idea on a good point to start. [09:09] mtx_init: http://www.linuxhq.com/lkprogram.html [09:09] bryceh: it seems that -nouveau is still in universe; can you please add it to -video-all, so that we can promote it? [09:10] SwedeMike: thanks [09:10] pitti, before I do that, we've been waiting on lbm being updated [09:11] Are we getting an lbm-nouveau metapackage that x-x-v-nouveau can depend on? [09:11] bryceh: oh, the current linux-backports-modules-nouveau-2.6.32-13-generic is not recent enough? [09:11] RAOF: that would be wrong [09:11] we certainly don't want to pull in lbm by default [09:11] we need to get along with the nouveau in the default kernel [09:11] pitti, actually we do [09:11] no, we don't [09:11] seriously [09:12] pitti, no, the nouveau in the default kernel is not going to be good enough [09:12] lbm ships a lot of stuff that is prone to break machines [09:12] pitti: no, linux-backports-modules-nouveau-2.6.32-13-generic, not "lbm" as a whole [09:12] pitti, we need to pull the lbm nouveau binary module (and include it on the cd) [09:12] ah [09:12] but why can't we just put that one into the main kernel then? [09:12] pitti, its complicated [09:13] slangasek: ah, ok [09:13] bryceh: There *isn't* any nouveau in the default kernel :) [09:13] pitti, drm is hard to pull in a per-driver fashion [09:13] ok, so it's _only_ shipped in lbm [09:13] ok, that sounds better [09:13] bryceh: so, current linux-backports-modules-nouveau-2.6.32-13-generic isn't recent eonugh yet? [09:14] pitti, there is a (short) email thread on kernel-team@ and ubuntu-x@ you may want to look at [09:14] pitti: thanks for syncing restfulclient! I thought it was in sync already, but I was wrong :) [09:14] ok, thanks; so this is blocked on pulling a new version by the kernel team? [09:15] l-b-m-nouveau should be new enough; what we really need is a linux-backports-modules-nouveau metapackage that the DDX can depend on and gets updated with the kernel ABI. [09:15] * pitti updates work items then [09:15] thanks for the heads-up [09:16] That reminds me! I'll file a bug against initramfs-tools to add nouveau to the framebuffer hook. [09:17] bryceh: ok, I updated https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-xorg-driver-selection-for-nvidia-hardware [09:20] hm. [09:23] i want to make an ubuntu1 upload of monodevelop, with moonlight support enabled. should i wait for the mozilla team to get their ff3.6 stuff (including moonlight) ready? it's a binary-only dep on a separate monodevelop-moonlight binary package (i.e. doesn't affect compilation). [09:27] RAOF: I would argue that the lbm package should provide its own hook to take care of itself [09:28] and presumably the in-kernel one lands in kernel/drivers/gpu like the others? [09:29] It might end up in staging/ [09:29] But it will eventually end up in kernel/drivers/gpu like the others, yes. [09:30] bryceh: git of course ;) [09:31] tjaalton: I'm thinking bzr actually [09:31] of course [09:31] tjaalton: there's pros and cons each way, but I favor bazaar [09:31] The problem with shipping it in lbm is that the various ABI versions should be parallel installable. I guess the linux-backports-modules-nouveau package could ship it. [09:32] but I'm also co-maintaining it in debian, so using two toolsets to maintain stuff is suboptimal fo me [09:32] for [09:32] but your call [09:32] no problem, just convince the Debian comaintainers to use bzr ;) [09:32] tjaalton, yes I recognize that issue [09:32] slangasek: and upstream too? [09:33] nah, just use bzr-git for that [09:33] well, that's unlikely to happen [09:33] using bzr-git is? [09:34] that [09:35] It's really pretty good, although it does suffer from bzr not having any way to refer to colocated branches. [09:36] I understand that it's harder for people to touch this stuff if it's in git.d.o, but is that any different from any other team? I don't think it's a good practise for random core-devs to directly touch and upload packages "owned" by some team [09:36] without discussion [09:36] no, it's no different than any other team, and I regularly complain at other teams too when I can't commit to their repos as a core-dev [09:37] heh, well I don't count you as a "random" core-dev ;) [09:38] :( [09:39] being the release manager and all :) [09:40] I don't think the release manager should be special in that regard; all core-devs should be trusted w/ commit access, and to know when to discuss before uploading [09:40] in theory yes [09:47] no manpage for bzr-git [09:56] tjaalton: bzr help <...>? [09:57] * hypera1r is more interested in git-bzr [09:58] hypera1r: bzr git-import <...>? [09:58] (from bzr-git package) [09:58] dholbach: i don't like bzr. [09:58] dholbach: to put bluntly. [09:58] ah, I misunderstood you then [09:58] ;-) [09:59] yeah, it's a one-way journey, because there's no way to push [10:00] so for that there would need to be two sets of the trees, one for git and one for bzr-git [10:04] It's not one-way; you can bzr dpush git+ssh://whatever [10:04] * sebner waves in the round [10:04] o/ [10:05] RAOF: ok, that's what the launchpad page claimed though [10:06] * slangasek succeeds in pushing to libdrm on alioth [10:06] (the hard way though, using git) [10:07] slangasek: does it give you that great slightly masochistic sense of achievement? ;-) [10:08] dholbach: I carefully monitor my git use to ensure I don't become too comfortable with it :) [10:09] slangasek: Didn't I successfully push that? [10:09] RAOF: you successfully pushed *your* commit, I was pushing /mine/ :) [10:09] tjaalton: Yeah. It technically doesn't “push” because it needs to do some rewriting of the local objects to keep the remote and local branch in sync. [10:09] jelmer: the description on https://edge.launchpad.net/bzr-git is misleading if push has been working sinec 0.3.2 [10:10] tjaalton, push still doesn't work [10:10] jelmer, RAOF: ok, I give up :) [10:11] tjaalton: you can use the "bzr dpush" command, but that's not the same thing as push [10:11] jelmer: My description of the difference above is roughly correct, right? [10:11] oh, dpush wasn't a typo, heh [10:13] RAOF: Basically, yeah [10:15] what's the equivalent of 'git show $hash'? [10:15] tjaalton: bzr diff -c revno [10:15] tjaalton, "bzr log -p -r X" [10:15] eww, that's hard :) [10:16] “bzr alias show=log -p -r -X” [10:16] but it accepts the hash as the revno? [10:16] Let me check... [10:16] tjaalton: s/X/$hash/ [10:16] jelmer: ah, gotcha === hypera1r is now known as hyperair [10:18] -r git:$hash [10:19] the git: bit is optional in newer versions of bzr [10:19] so it detects it? ok [10:20] meh, that's the second time that X.org freezes and goes to 100% CPU a couple of minutes after login [10:20] bryceh: were there any X.org/intel updates yesterday? [10:21] only libdrm [10:21] pitti: better than me. I just tryed out of the gdm/plymouth whatever bug is fixed but I guess no. Gdm appears, I move my mouse and it evidently crashes because mouse and keyboard don't work anymore :( --hardreset [10:21] I already disabled plymouht [10:21] this now manages to break every boot [10:22] oh [10:22] plymouth++ then [10:22] slangasek: should the rc-sysinit/network race bug be reopened, following up on keybuk's https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/461725/comments/15 ? [10:22] Ubuntu bug 461725 in upstart "rc-sysinit job might start before loopback is up" [Medium,Fix released] [10:22] cjwatson: hmmm, does the by-id stuff you were doing affect what will get written to /etc/crypttab by the installer? [10:22] pitti: how to disable it? apt-get remove? [10:22] hmm we already had libdrm 2.4.17 before the new merge [10:23] sebner: boot without splash; that won't really disable it, but disable the graphical splash [10:23] so no intel changes there [10:23] which is what seems to break X [10:23] tjaalton: currently trawling through dpkg.log to see what was new [10:24] pitti: aye, thanks :) [10:24] there are no kernel related messages in dmesg when it happens, and strace Xorg is silent - it's just spinning [10:24] ttx: no, that bug is fixed; the regression has really only been confirmed on systems with a broken network config [10:25] slangasek: ok, just checking :) [10:26] pitti: ehm, stupid question .. what happened to menu.lst ^_^ [10:26] sebner: menu.list is grub 1, which became obsolete in karmic [10:27] tjaalton: right, I didn't even get a new libdrm [10:27] oh, would that it were actually obsolete :) [10:27] pitti: oh right, I haven't haXX0red anything in lucid yet. so what's the new thing? [10:27] tjaalton: so it must be between new libc6, new udev, or me dropping "splash" from kernel comand line [10:28] pitti: I'll try that on mine [10:28] tjaalton: I'll gdb X the next time it happens; thanks so far! [10:33] pitti: dropping splash from the kernel commandline is a near-guaranteed way to make X hang in lucid :P [10:34] hmm [10:34] pitti: bug #518352 [10:34] Launchpad bug 518352 in plymouth "[lucid] if booting without 'splash', gdm starts X on wrong vt" [Medium,New] https://launchpad.net/bugs/518352 [10:34] hah [10:34] if you don't use 'splash', then 'plymouth --show-splash' doesn't change VT [10:34] well, X is on vt7 now [10:35] is that where it was at boot time, or did you restart it? [10:36] it's only the *first* X server after boot that winds up on the wrong VT, because gdm does - if (plymouth_is_running) { get_cur_vt_for_X_args(); kill_plymouth(); } [10:36] I don't think I restarted it [10:36] !grub2 | sebner [10:36] sebner: GRUB2 is the default Ubuntu boot manager in Karmic. For more information and troubleshooting on GRUB2 please refer to https://wiki.ubuntu.com/Grub2 [10:39] jussi01: thx but this seem to cause even more breakage *muahahha* [10:39] *g* [11:05] mvo, hi, how is ratings+reviews? Are you blocked on anything? [11:26] slangasek: not to my knowledge - I didn't think crypttab had much to do with grub? [11:26] cjwatson: I wouldn't think so, no :) [11:26] StevenK: regarding openal-soft, LP does support syncing .orig.bz2 now afaik?! [11:27] cjwatson: just an odd bug report that came in, with someone having listed their source device as /dev/disk/by-id/fwibble in /etc/crypttab [11:27] asac, is debian/patches/mono-arm-thumb2-ftbfs.dpatch forwarded to upstream? [11:37] sebner: not properly [11:37] sebner: it supports the first sync. thereafter, it is believed that subsequent syncs with the same .orig.tar.bz2 will fall over [11:38] slangasek: IIRC the installer even generates crypttab before grub-installer runs [11:38] ok [11:55] mpt: not blocked as such, just drowned in other stuff, I plan to work on the new approach with ubuntuone today, lets see how well that goes. the old code that use launchpad will have to be replaced in parts [11:55] mvo, ok, best of luck :-) [11:55] is there an existing bug report for the plymouth failure? perhaps with some hints how to debug this? I now got 7 failures in a row [11:56] thanks :) [11:56] pitti: hmm? other than the one I pointed to above about booting w/o splash? [11:56] slangasek: still the same one from the sprint [11:56] i. e. X starts up with a mouse cursor over VT [11:56] ctrl-alt-f1 > switches to VT [11:56] pitti: yes; are you booting without splash? [11:57] crtl-alt-f7 -> back to X, but press enter -> freeze [11:57] slangasek: no, that's with splash [11:57] oh, no, that sounds like the in-between-VTs case [11:57] Keybuk said taht he can't reproduce, so I'm happy to collect some data [11:57] but I'm afraid I don't know where to start [11:58] it happens on both of my machines (dell mini ssd and latitude) [11:59] pitti: for starters, make sure you have libplymouth2 0.8.0~-10ubuntu1 installed and file a bug with apport, so we at least have a record of /proc/cmdline and /proc/fb [11:59] ah, bug 516412 [11:59] Launchpad bug 516412 in plymouth "Pressing causes X to freeze" [High,Fix released] https://launchpad.net/bugs/516412 [11:59] noooo, not that one :-P [11:59] that's the freeze part [11:59] once I switch to vt1 and back to 7 [12:00] slangasek: ok, so there's no existing bug with suggestions/explanations what to look out for? [12:00] ok, I'll file a new one then [12:00] slangasek: (I have that version) [12:01] nope - we have an explanation of *what* that behavior means, but no model for *why* it happens [12:01] could it be related to fsck? [12:01] Keybuk might be able to give some debugging advice, but I can't [12:01] since obviously I need to powercycle this machine every time now [12:01] slangasek: ok, thanks [12:01] "obviously"? [12:01] Alt+SysRq+K doesn't fix it? [12:01] No SysRQ on the mini :/ [12:01] snerk [12:02] plug in a USB keyboard? :) [12:02] * pitti will boot in rescue mode, make sure that partitions are okay [12:02] oh, I can login/reboot from VT1 [12:03] (didn't help, though) [12:03] anyway, relation to fsck is only distant AFAIK, in the manner of races [12:06] mpt: one thing we should discuss (not necessarily now) - apparently the gtk patch take make almost-fixed height mode fast is going going to be upstream and we will have a hard time getting it in as a distro patch. nzmm implemented a alternative layout that does not grow/shrink so we can have fixed_height mode [12:06] mvo, "going going" -> "not going"? [12:06] mpt: I would like you to look at it (I or he can do screenshots) and comment. without a patched gtk the user experience is going to be really bad [12:06] mpt: not going to [12:07] mpt: I'm willing to work more on the patch, but I have the feeling its a lost cause [12:07] slangasek: right, once I put back cups, it works again [12:07] slangasek: I think this machine is naturally avert to booting in 10 s; the closer you get, the more it acts up :) [12:07] pitti: bwuh? cups? [12:07] haha [12:07] slangasek: (just for testing) [12:07] mvo, so first, why will it not be upstream? [12:07] * pitti calls that "Scott's law" [12:07] * pitti -> supermarket [12:07] mvo, or if you'd prefer to discuss this later, let me know [12:08] mpt: I had no official reply yet in the bugreport, but the unoffical is that it makes the fixed_height mode case slower and that its a hack (both is true). the slowness should be really small [12:08] pitti: perhaps annotating the gdm upstart job to run fuser -v /dev/tty7 before starting? [12:09] but its a hack and it does things that fixed_height is supposed to not support (namely making rows grow/shink) [12:09] (stabbing the dark) [12:10] mvo, and why would it be hard as an Ubuntu patch? Is it because we'd be carrying it forever? [12:12] mpt: we would have to carry it for the full LTS time and carrying a patch that got rejected upstream will make bugreports against gtk by us handled less favorable (because it might be a side effect of our patch(es)). seb128 is the gatekeeper for this [12:12] (upstream reports) [12:13] mvo, so maybe the question for upstream is, *how* in GTK should we achieve what we want to achieve (rows changing size but being fast with long lists) [12:13] mpt: correct [12:15] and I believe at this point the answer is "you can't" - at least not without massive amounts of gtk events that infere with the webkit rendering (and other stuff) [12:15] but I'm happy to change my opinion if someone comes up with a good way of achieving this [12:15] mvo, did you get any comment on this bug? [12:15] I do think we shuld have a backup plan ready [12:16] mvo, how does Banshee do it? Do they not use fixed-height mode? [12:16] Or are they using a completely custom list control? [12:16] banshee has quite some custom widgets [12:16] mpt: someone told me they embedded a complete copy of the treeview [12:16] but I have not verifed this [12:17] How difficult would that be? [12:17] well, it would be a very big hammer [12:18] the question is not "is it possible" - the question is "is it sensible" (or "how much are we going to hack") [12:18] alternatively: "growing row design" > pain-to-make-it-happen [12:18] Right, that's why I was asking specifically about how difficult it would be [12:19] not easy, but possible [12:19] ok [12:19] What does nzmm's layout look like? [12:20] http://people.canonical.com/~mvo/tmp/Screenshot-Ubuntu%20Software%20Center.png [12:20] mpt: ---^ [12:23] that looks quite odd [12:23] I suppose it would look a bit less odd if the stars and the buttons swapped places === MacSlow is now known as MacSlow|lunch [12:27] crimsun, hi [12:27] crimsun, have you seen bug #523716? [12:27] Launchpad bug 523716 in pulseaudio "pulseaudio version defined as UNKNOWN" [High,Confirmed] https://launchpad.net/bugs/523716 [12:28] seb128: no, but I'll fix it [12:29] crimsun, thanks! [12:29]