[00:00] johanbr, then your manual call and the call by cupsfilter uses different command line options and the call out of the print queue even others. [00:01] Try to find out which command line options get actually used and which ones make pdftopdf break. If the original PDF produced by evince is good then we probably have a pdftopdf bug. [00:01] LaserJock: yea [00:01] LaserJock: but poorly, so i have to determine how to fix it or disable it entirely and use fuse [00:02] LaserJock: fuse was buggy as well so it wasn't working until the next release 1.1.8 will work with OOo [00:02] LaserJock: it didn't support truncate at all but now does for trivial cases (0 or same size as file) [00:03] calc: bummer [00:03] Has, uh, anybody run into weird issues with Jaunty's libc running under Lenny's kernel? [00:04] johanbr, is the file already the evince output or the original file? If it is the original, give me also the evince output. [00:06] 8/c [00:07] LaserJock: well gvfs fuse will work in time for jaunty, but i was trying to fix the OOo native support which takes learning how they actually work, heh [00:08] i have to make a decision by beta though to make sure it works for everyone [00:08] tkamppeter: that's the original [00:08] just a sec [00:25] johanbr, seems that your LaTeX PDF file makes evince turning all fonts to graphics when converting PDF to PDF (probably with Poppler). [00:26] Great would be if one could let evince pass the input PDF directly through to the output to minimize the number of conversions (and losses caused by them). [00:26] Oh, I see. Well, that explains the enormous file size. [00:28] tkamppeter: If you pass the original pdf file through pdftopdf, you should also get a large file (~100 megs). Is that also because it turns fonts into graphics? [00:29] pdftopdf should do page management only, not re-render the file. Please try passing the original PDF to pdftopdf. The size of the output should be in the order of the size of the input. [00:31] tkamppeter: nope [00:31] cat original_filename.pdf |/usr/lib/cups/filter/pdftopdf job1234 username test 1 jobname.pdf >copy.pdf [00:32] gives a copy.pdf that's 92 megs large === rgreening_ is now known as rgreening [00:40] johanbr, strange. pdftopdf bug probably. pdftopdf is Poppler-based, evince probably too and the two Poppler treatments perhaps produce 5 * (92/5)^2 MB. [00:43] could the problem be fixed directly in poppler? [00:43] or does the library not have enough information to know that it can just return the pdf file unmodified? [00:44] and evince does indeed use poppler [00:47] asac: ping? [00:50] any way to find out whether gnome or openGL developer positions (work at home) for canonical are wide open at this point of time apart from looking at webapps.ubuntu.employment [00:51] *webapps.ubuntu.com/employment - surprisingly it has URL starts with webapps [00:54] ooh oops sorry if i offended canonical staff here - any help will be appreciated [00:55] generally we don't know anymore than anybody else about Canonical's hiring [00:56] I suppose you could email Canonical's HR but I'm not sure if they'd tell you anything helpful regarding how "wide open" positions are [01:00] yes, there is a time frame of 21days about notification after applying for a position [01:02] couldn't find HR and there seem to be lot of ideal or desirable work-at-home positions but recession only makes it tougher [01:02] Mavericks: It's really OT here regardless. [01:03] ScottK: thank you , i know that [01:03] Mavericks: HR is simply hr@canonical.com [01:08] * calc read something interesting about intel ssd today, apparently they are limited to 20GB/day transfer to stay within warranty specs, and supposedly slow down so that you can't do more than that disk io [01:09] Hey, anyone want to look at an awesome libc bug? bug 339743 [01:09] Launchpad bug 339743 in glibc "Jaunty i386 popen() misbehaves on Lenny 2.6.26-1-amd64 kernel" [Undecided,Confirmed] https://launchpad.net/bugs/339743 [01:10] andersk: probably people on the other side of the world, who are asleep now. Also, they get mailed about bugs that they care about [01:12] * ScottK wonders how it's even a bug. [01:12] It's problematic if your Jaunty build chroots are running on a Lenny system [01:12] "Hey, your libc doesn't work with some other distro's kernel" [01:14] Surely a statically compiled binary is supposed to work on other distro's kernels. [01:14] slangasek: the -base langpacks contain all translations which were exported from Rosetta at a given point in time. the other langpacks is a diff to what has changed since then. [01:14] It works in Intrepid. [01:16] slangasek: due to a bug the first -base langpacks didn't include any mozilla and kde translations. That's why I generated a new one. Mozilla diffs only work when the -base pack has mozilla xpis already, which was not the case. [01:18] slangasek: the duplicate xulrunner and firefox for bn_IN, es_ES, pt_PT and sv_SE are due to in import error into Rosetta and will hopefully be removed from the database soon. As soon as this happens I will generate new -base langpacks. Another -base generation will happen shortly before release. Please do expect them to grow in size! === bdefreese2 is now known as bddebian === ember_ is now known as ember [03:10] so 10.04 LTS will have gnome 3.0 ? [03:14] calc: IMO that would be too risky. [03:15] Or, we extend the cycle to fix bugs. [03:24] TheMuso: So far it's seemed to me that the general view for LTS is better grab the latest so it'll be supported longer. [03:24] Perhaps next time around it'll be the opposite. [03:25] ScottK: Yeah but GNOME 3.0 will have some pretty significant changes [03:25] * ScottK doesn't really know about it. [03:25] From what I'd read in blogs it seemed likely to arrive with Perl 6. [03:25] heh right [03:29] TheMuso: At the last release team meeting I brought up the Qt 4.5 ICE on PowerPC and there were some actions assigned to look into it. [03:29] ScottK: I didn't know about that ICE [03:29] Since then I see that GCC FTBFS on powerpc in the last upload in the g++ tests. [03:30] ScottK: well aiui gnome 2.30 == 3.0 [03:30] This one http://launchpadlibrarian.net/23244739/buildlog_ubuntu-jaunty-powerpc.kde-style-skulpture_0.2.2-0ubuntu1_FAILEDTOBUILD.txt.gz is a much smaller app, but it looks like the same/very similar failure. [03:30] calc: KDE got a new version so we want one too? [03:30] ScottK: something like that probably ;-) [03:31] ScottK: they get to drop deprecated api's at 3.0 as well iirc [03:31] Right. [03:32] I'm going to try running a debug build with gio for OOo if it doesn't show anything obvious I'm going to drop gvfs/gio from OOo and go to gvfs fuse for jaunty :-\ [03:37] calc: where did you hear that 2.30 == 3.0? I can't imagine that actually happening [03:42] LaserJock: don't remember now [03:42] LaserJock: may not have been a reliable source [03:47] LaserJock: http://www.phoronix.com/scan.php?page=news_item&px=NjU4Mg [03:47] LaserJock: it seems that 2.30 will really be 3.0 unless they change their mind in july [03:58] So it sounds like the decision is not so much about what they'll add, but what they'll drop? [03:58] Corba for one [03:58] I guess the gnome-shell thingie will be part of 3.0. [03:59] That will be interesting accessibility wise. [04:02] wow i'm glad i got the gvfs truncate fix in when i did, next release is 2.26.0 [04:04] so I wonder if they're going to branch or something [04:05] I can't imagine doing all the Gtk/Gnome 3.0 breakage in 1 release [04:07] Well, there are already branches of some things. I know of the gnome shell and gtk with multi-pointer support. Probably other stuff too. [04:08] and gnome-speech may be going away, actually it will go away if I have anything to do with it. [04:14] johanbr: yeah, but if it's really supposed to be "revolutionary" the core stuff I'd think would need to be starting fairly soon [04:17] http://live.gnome.org/ThreePointZero seems a bit bare [04:38] LaserJock: apparently they forgot to update the page after guadec === asac_ is now known as asac [06:05] good morning [06:06] morning :) [06:07] hi IntuitiveNipple [06:25] TheMuso: ok, latest /ubuntu is go for Alpha 6 [06:26] Anyone around who could do an upload for bug 339449? I'd like to make a6 [06:26] Launchpad bug 339449 in mit-scheme "FeatureFreezeException: Merge mit-scheme with Debian" [High,Confirmed] https://launchpad.net/bugs/339449 [07:28] ArneGoetje: right, my question isn't really "why do we have -base langpacks" so much as "why, during the development cycle, do we ever have any translations in the normal langpacks instead of just updating the -base langpacks?" [07:28] ArneGoetje: btw, please remember to turn off the upload cronjob, alpha 6 this week :) [07:55] Good morning [07:55] heya pitti! [07:56] * pitti hugs Hobbsee [07:56] yo, Hobbsee, pitti [07:56] :) [07:56] * Hobbsee hugs pitti back, and waves to Mithrandir [07:57] hey Mithrandir, how's it going? [07:57] pitti: good, good. Was in CPH over the weekend, which was nice. [07:58] Morning pitti [07:58] pitti: So, you didn't accept syslinux. [07:58] StevenK: was I supposed to? [07:58] Mithrandir: nice, I've never been to Denmark yet [07:59] pitti: I thought you said you'd look at it on Friday? [07:59] oh, SRU? sorry [07:59] pitti: Isn't it weird not having visited a neighbouring country? [07:59] pitti: Yeah, the SRU [08:00] Mithrandir: I visited all 8 others [08:00] pitti: Fix it? :-) [08:00] StevenK: ok, seems I need to do SRUs today again [08:00] StevenK: got buried in meetings on Friday, I apologize [08:18] I'm not entirely clear on the process here. Does bug #339618 require a freeze exception? [08:18] Launchpad bug 339618 in mpb "Update libctl to use guile-1.8" [Undecided,New] https://launchpad.net/bugs/339618 === azeem_ is now known as azeem [08:21] kirkland: do you have any plans to backport screen-profiles to hardy/intrepid and eventually debian? [08:21] siretart: it's already in a ppa? [08:22] at least for intrepid [08:22] Hobbsee: I have no problem recompiling it for me personally. Actually, I'm most interested in having it in lenny-backports :-) [08:24] siretart: ahhh === tkamppeter_ is now known as tkamppeter [08:41] Hi, any Python experts here? It is about bug 153610. A Python program (here the tray applet of system-config-printer) complains about a missing Python module but the module is actually installed. [08:41] Launchpad bug 153610 in system-config-printer "applet.py crashed with IOError in module>()" [Low,Triaged] https://launchpad.net/bugs/153610 [08:45] mvo, soren: could anyone test vm-builder in hardy-proposed, which rots there for 214 days already? If not, I'll just remove it from -proposed [08:46] pitti: I did the upload, but I can do the verification as well [08:46] mvo: much better than no feedback at all, and if you use the actual .deb from -proposed, and not a local build, and exercise a few standard cases, that would suffice [08:46] mvo: danke! [08:47] Sorry, wrong bug. I mean the following: It is about bug 203808. A Python program (here the tray applet of system-config-printer) complains about a missing Python module but the module is actually installed. [08:47] Launchpad bug 203808 in system-config-printer "applet.py crashed with ImportError in ()" [Undecided,Fix released] https://launchpad.net/bugs/203808 [08:48] This only happens with Python programs which are not directly started by the user, like the system-config-printer applet which is auto-started on login or hal_lpadmin which is triggered by HAL. [08:50] tkamppeter: that bug is very old, and closed.. [08:50] pitti, I will look for other examples then ... [08:51] pitti, bug 336707 [08:51] Launchpad bug 336707 in hal-cups-utils "hal_lpadmin crashed with ImportError in () (dup-of: 291035)" [Undecided,New] https://launchpad.net/bugs/336707 [08:51] Launchpad bug 291035 in hal-cups-utils "hal_lpadmin crashed with ImportError in ()" [Undecided,Confirmed] https://launchpad.net/bugs/291035 [08:58] Hobbsee: hi. pong [09:00] asac: greetings. I presume you've been keeping tab on n-m bugs? It seems there's a fair bit more tempramental (or plain broken) behaviour for multiple wifi cards, and I was wondering if you knew anything about it [09:03] tkamppeter: I think you can close them; I fixed s-c-p for python2.6 in 1.1.3+git20090218-0ubuntu4 [09:04] Hobbsee: hmm. depends. i know that there are still issues with some types WPA enterprise. Any particular wifi chipset you have issues with? [09:05] asac: there was a broadcom mentioned earlier, and I was having temporary problems with my iwl3945 card [09:05] pitti, the mentioned ones are on hal-cups-utils. Or is it because hal-cups-utils uses a lib of s-c-p? [09:05] aah [09:06] asac: the broadcom got reported, I think i saw another couple in bugs, and I don't still have logs of my (now working) iwl3945 [09:07] tkamppeter: yes, python-cupshelpers is built by the s-c-p source (#336707) [09:07] tkamppeter: that should be good now [09:07] tkamppeter: the other two bugs fail on importing "usb" [09:07] thus they are different [09:07] tkamppeter: I don't have an usb.py on my box [09:08] Hobbsee: yes, broadcom is one of the few drivers that is no in mainline kernel afaik ... which is bad as it cannot be fixed. [09:08] tkamppeter: so I think bug 291035 is real [09:08] Launchpad bug 291035 in hal-cups-utils "hal_lpadmin crashed with ImportError in ()" [Undecided,Confirmed] https://launchpad.net/bugs/291035 [09:08] asac: ah, right [09:08] pitti, so python-usb needs to be fixed, too? It is required by hal-cups-utils. Should I assign these bugs to python-usb then? [09:08] tkamppeter: maybe it's missing a dependency to python-usb? [09:09] oh, it's usb.so [09:09] $ python -c 'import usb' [09:09] works for me [09:09] tkamppeter: no, should be fine; doko rebuilt it on Sun, 22 Feb 2009 [09:10] pitti, I have checked and hal-cups-utils requires python-usb, it is the only package to keep python-usb in a standard installation. [09:10] tkamppeter: hm; no idea then, I'm afraid [09:11] tkamppeter: ah, look at Dependencies.txt in #291035 [09:11] tkamppeter: he still has the old python-usb installed (not ubuntu1, which was the 2.6 rebuild) [09:11] * pitti hugs apport [09:12] tkamppeter: so, I'd reassign it to python-usb and close it with the last entry of /usr/share/doc/python-usb/changelog.Debian.gz [09:18] mvo: would you mind applying the intrepid SRU patch for compiz to jaunty, too? (bug 269805); it's an alpha-6 blocker [09:18] Launchpad bug 269805 in compiz "gnome-window-properties gives error about configuration tool not being "registered"" [High,In progress] https://launchpad.net/bugs/269805 [09:19] pitti, I have simply closed this bug now with a comment added that the user should update. [09:19] tkamppeter: right [09:20] pitti, I see another problem. [09:21] I have kept s-c-p all the time identical to upstream and now there was a major patch done due to the notifications. [09:21] pitti: thanks, this is already in bzr [09:22] What was the problem to have buttons in the notifications? [09:22] tkamppeter: right, please prod the dx team to forward the patch upstream [09:22] tkamppeter: notify-osd doesn't support actions in notifications [09:22] so they'd end up as dialogs [09:22] pitti: any word about the freeze exception for the compiz with protobuf support ? or should I wait for slangasek ? [09:23] pitti, is this a Ubuntu policy or a GNOME policy? [09:23] tkamppeter: it's not a policy; by design, notify-osd doesn't support actions [09:23] tkamppeter: and libnotify doesn't promise that the implementation does [09:23] tkamppeter: s-c-p just assumed that it can; with the patch, it checks whether the notification daemon actually supports actions, and if not, it does something different [09:24] pitti, and why is notifying system replaced by an inferior one only for eye-candy? [09:24] mvo: I didn't answer yet; a 0.5 MB impact on the CD for relatively little gain, after FF, and with new potential bugs due to new implementation doesn't exactly make me happy.. [09:24] I don’t understand why notification-daemon couldn’t have been patched with the eyecandy. [09:24] mvo: but "pitti feels bad about it" might not be sufficient to say "no" :) [09:25] ion_: (1) the patch would exchange the entire code, and (2) we want the original n-d to be available, too [09:25] pitti: well, startup improvement gain of 20-30% is not "relatively little" [09:25] tkamppeter: it's not just eye candy, but a new usability design [09:26] pitti: but I certainly understand this [09:26] mvo: I'm actually more concerned about changing the entire underlying configuration parsing structure that late [09:26] if we can spare the space on the CDs, I'm fine with it, but I'd really like to have slangasek decide that [09:27] pitti: sure, I wait for him. if we do it, we should do it today IMO [09:27] yes, indeed [09:27] piiti, would "if os.environ.get('GDMSESSION') == "gnome-stracciatella":" also work on non-Ubuntu distros to check whether the notify daemon is capable of actions? [09:28] pitti: ^^^ [09:29] tkamppeter: no, please don't ever use that outside of Ubuntu [09:29] tkamppeter: it's meant for something entirely different [09:30] tkamppeter: for checking action support, you need to call [09:30] GList *notify_get_server_caps(void); [09:30] (/usr/include/libnotify/notify.h) [09:30] Is there a possibility for a Python program to check whether the notification daemon supports actions? [09:30] (this also exists in python-notify) [09:31] pitti, then the patch should be changed to that. [09:31] tkamppeter: indeed it should [09:31] kenvandine_wk: ^ [09:32] tkamppeter: thanks for pointing out [09:33] pitti, kenvandine_wk: With this fixed I would commit the patch upstream. [09:34] tkamppeter: if it checks server caps, it absolutely makes sense to commit it to upstream, since this is a real bug (assuming that actions are supported without testing for them) [09:34] tkamppeter: the stracciatella test is an ubuntu specific hack and should remain Ubuntu patches [09:54] pitti, I have reported bug 339847 on the s-c-p notification problem. [09:54] Launchpad bug 339847 in system-config-printer "system-config-printer notification patch should auto-detect capabilities of notification daemon, so that it can get upstreamized" [Medium,Triaged] https://launchpad.net/bugs/339847 [09:55] tkamppeter: thanks; please assign to ken-vandine [09:56] pitti, I have already done so. [09:58] Hi, any chance that flashplugin-nonfree gets some love ? :) https://bugs.launchpad.net/ubuntu/+source/flashplugin-nonfree/+bug/304969/ [09:58] Ubuntu bug 304969 in flashplugin-nonfree "Hardy: Flash can't be installed since install_flash_player_9_linux.tar.gz can't be retrieved " [Undecided,New] [10:16] calc: GPT is the default when creating a new partition table on some (sub)architectures, of course (ia64 and Intel-based Macs), but without some way to detect whether the BIOS supports it we can't make it the default [10:17] calc: I hate the DOS partition table format as much as anyone else sensible does, but I don't much like the idea of either breaking support for anything that isn't incredibly new, or having to ask an unintelligible question [10:17] cjwatson, detecting EFI? [10:18] I guess looking for /sys/efi or whatever might work, but ... [10:18] we do already use gpt for disks larger than 2TB [10:19] except it gets more complex when using BIOS emulation [10:19] indeed [10:19] i.e. my mac has no /sys/firmware/efi [10:19] my altix does [10:19] isn't support for /sys/firmware/efi in a kernel module? [10:19] efivars or some such [10:20] but yes, BIOS emulation on Macs does throw a spanner in the works, and the installer has a special case for Intel-based Macs for that reason [10:20] I don't know whether the same goes for modern non-Mac x86 hardware [10:21] i think MSI are the ones beginning to put EFI on their motherboards [10:21] most don't [10:22] for Macs it's easy; we do the equivalent of dmidecode and see if it says Apple ... [10:22] but I'm not about to go hardcoding that for every BIOS manufacturer on the planet [10:23] i thought it might help to know who was at it :/ [10:23] aren't MSI canonical partners? i thought their netbook was ubuntu based [10:23] you could try & get ahold of one of their boards to take a peek [10:25] elilo sucks, though. that's unfortunate [10:26] mm, I'm not exactly overflowing with space for more hardware [10:27] realistically I suspect EFI systems are an excuse to try out grub2 [10:27] Incidentally, i installed grub2 recently. Seems to work fine. :-) [10:27] (jaunty) [10:27] we should have a wiki page with success/failure plus actual hardware details [10:28] cjwatson, just expense a new house :P [10:28] slangasek: were you going to set up something like that as part of the grub2 spec? [10:28] ogra: now there's an idea [10:28] :) === _Nicke_ is now known as Nicke [10:29] my shiny new muddleboard has no EFI... MSI warranties were inferior [10:31] Guys testing 20090309 the sound is crackly but it only seems really bad on the login music. I've had a quick look at https://wiki.ubuntu.com/DebuggingSoundProblems but I can't see anything for debugging the login sound. [10:41] keybuk: How soon will we get module-init-tools 3.7~, btw? :-) [10:41] slangasek: can we get freetype 2.3.8 in jaunty? ;-) it fixes evince rendering issues [10:42] seb128: bug fix only release? [10:43] pitti: "This is a bugfix release for the 2.3 series. All users should upgrade." is what is writting on the website [10:43] seb128: if the changelog confirms this, then this doesn't need any exception; bug fixes are fine [10:43] pitti: I don't plan to do the update, slangasek is the debian maintainer for it, I was just suggesting that he should have a look at doing the update ;-) [10:44] ah, I see [10:44] just tried it to confirm it fixes evince displaying wrong chars on some documents [10:48] where is doko? [10:48] bug #339337 [10:48] Launchpad bug 339337 in gnome-games "sudoko tracker crash" [Undecided,Confirmed] https://launchpad.net/bugs/339337 [10:48] hiding [10:48] slangasek: ^ that's due to the python-numpy change === lamont` is now known as lamont === smb_tp_ is now known as smb_tp [11:00] asac: I see why bug 278095 is appearing again, seems I clobbered your patch. :p uploading the re-introduced patch now [11:00] Launchpad bug 278095 in at-spi "MASTER crash in getenv() ... spi_atk_bridge_exit_func()" [High,In progress] https://launchpad.net/bugs/278095 [11:03] TheMuso: yeah. you also clobbered the changelog ;) (not nice) [11:03] No I know. I'm putting it back in as well [11:03] TheMuso: so upstream redid most of the code, but ignored our bug :( [11:03] TheMuso: well. the patch doesnt apply anyway [11:03] TheMuso: let me give you a new proposed patch [11:03] asac: ok, won't adjusting the current patch to the new code work, or will that only break things further? [11:04] TheMuso: http://pastebin.com/f2fa4dd57 [11:04] because if the former, I can do that here [11:04] oh ok thanks [11:04] TheMuso: try that. [11:04] TheMuso: i am not sure if it works, but i would think so ;) [11:04] ok [11:04] TheMuso: can you read https://bugzilla.mozilla.org/show_bug.cgi?id=460926 [11:04] Mozilla bug 460926 in Disability Access APIs "A11y hierarchy is broken on Ubuntu 8.10 (GNOME 2.24)" [Blocker,Resolved: fixed] [11:05] ok I'll have a look [11:05] TheMuso: and tell me if that means that we shouldnt use at-spi at all in firefox? [11:05] TheMuso: i think their fix does just opt-out from at-spi [11:05] TheMuso: so if we do that we might not even need the AT_SHUTDOWN patch [11:05] right, I don't know enough about that to coment whether we should be using at-=spi or not [11:06] TheMuso: yeah. lets both read the mozilla bug and discuss later today or tomorrow what to do ;) [11:06] ok [11:12] asac: I am going to try your patch anyway, because I want to see if it corrects some other behiavior I am seeing in GNOME itself... [11:13] * ogra wonders, if i have a system with an empty modules.dep it seems module-init-tools still gives me a "no such file or directory" [11:13] TheMuso: hmm are there crashes elsewhere? [11:13] asac: No crashes, but thigns not being accessible... [11:14] TheMuso: i would think that this patch is really just for crahes at shutdown [11:15] * ogra wonders why that is, at least the error should be different [11:15] asac: that new patch of yours is already applied... [11:16] asac: ah ok. Anyway it seems the first 2 hunks are already present, but hunk 3 fails to apply, so I'll look over the bug more closely later and we can chat about it when I'm more awake. :) [11:17] TheMuso: first two hunks? are you talking about the original patch we had? [11:18] asac: no, the one you pastebinned. [11:19] TheMuso: i dont understand. i did an apt-get source like 1h ago [11:19] TheMuso: how can it not apply? [11:19] ok i'll double check [11:19] yep it applies, I wasn't doing things properly. [11:35] hey doko === persia_ is now known as persia [11:58] cjwatson, uboot-mkimage made it to main without MIR ? can we do the same for flash-kernel ? [11:59] ion_: as soon as I've cleared out everything that it depend son [11:59] (it fulfills a very special usecase only, so i would expect thats ok) [12:01] ogra: I'm fairly sure that somebody on the MIR team looked over it. Please don't ask me to work around that [12:01] ok [12:01] * ogra writes a MIR then [12:02] pitti, I see that the notifications patch for s-c-p seems to be originally created by David Barth and not by Ken VanDine, Ken only packaged it (see bug 328604). Should I assign bug 339847 to David? [12:02] Launchpad bug 328604 in system-config-printer "system-config-printer shouldn't use notifications with actions" [Undecided,Fix released] https://launchpad.net/bugs/328604 [12:02] Launchpad bug 339847 in system-config-printer "system-config-printer notification patch should auto-detect capabilities of notification daemon, so that it can get upstreamized" [Medium,Triaged] https://launchpad.net/bugs/339847 [12:03] has falcon been removed from jaunty? [12:05] tjaalton, bug #336389 [12:05] Launchpad bug 336389 in falcon "Please remove falcon source and binary from Jaunty" [Wishlist,Fix released] https://launchpad.net/bugs/336389 [12:05] pitti: sigh, ok [12:05] need to look for a replacement then [12:06] Or just port the django :) [12:06] less likely ;( [12:06] oops, ;) [12:07] For distribution, you might switch to a PPA. For auto-source-building, you might look at deb-o-matic. [12:07] I can't dump matlab etc to a PPA :) [12:08] Ah, no :) [12:08] well, hardy still has it, so it's not urgent [12:14] kenvandine_wk: Can you have a look at bug 339847? I want to upstreamize the notification patch, but it needs a proper generic detection of the notification daemon type. Can you fix that? Thanks. [12:14] Launchpad bug 339847 in system-config-printer "system-config-printer notification patch should auto-detect capabilities of notification daemon, so that it can get upstreamized" [Medium,Triaged] https://launchpad.net/bugs/339847 [12:14] tkamppeter: i agree, will work on that [12:15] kenvandine_wk: Thanks in advance. [12:15] :) [12:15] tkamppeter: sorry i didn't catch it when we were pushing it through... seems pretty obviously wrong now [12:53] I noticed an interesting side effect of the "YOU HAVE UPDATES!" behaviour today [12:54] if you run apt-get update, and it's been a while, that triggers the window of death [12:54] which makes you more inclined to use it than running apt-get again ;) [12:54] the window of death can kiss my wookie [12:54] just because OSX does it, doesn't make it right [12:56] directhex: just use sreadahead instead of readahead-list [12:56] then it freaks out that you've manually broken ubuntu-desktop's deps and won't do anything [13:00] Is publisher broken? [13:00] There are binaries 3.5 hours in ACCEPTED. [13:00] s/hours/hours old/ [13:00] And sources approaching 2 hours old that I can see. [13:06] already any plans how to get 3D accelleration for ATI GPUs in 9.04? I guess, "radeonhd" isn't really usable? [13:12] wgrant: something to do with ports.ubuntu.com mirroring freaking out, I think [13:13] cjwatson: Ah, wonderful... [13:13] wgrant: I believe the root cause has been fixed, but some state cleanup is going to be needed as the publisher's crashing now [13:13] KaiL, the plan is "panic until april, then force people to use one of the slow Free drivers" [13:13] cjwatson: Eww. [13:13] Sounds lovely. [13:14] directhex, so you guess, there might be hope to get ATI to do their work? ;) === Amaranth_ is now known as Amaranth [13:14] KaiL, if they feel like it [13:15] they are going to drop support for anything older than r6xx [13:15] KaiL, superm1 is keeping on top of what's working and what isn't [13:15] it's trying to republish kde4libs 4.1.4-0ubuntu1~intrepid1.1 [13:15] at least according to phoronix [13:15] tjaalton, yes, and definitly not adding X-Server 1.6 this month [13:16] (was just a news on heise.de) [13:16] sodding ATI [13:17] so for R300-R500 the default can be changed to "radeon" today... [13:17] which gives at least 2D acc and a rather slow 3D [13:18] KaiL: It's not that slow [13:18] situation on GPUs is getting much worse these days; intels GMA 500 is another problem: last driver ran on 7.10 [13:18] "older than r600" seems highly excessive - 2k-series radeons? [13:19] KaiL, yes, poulsbo is junk. blame powervr. [13:19] 2k Serie will still be supported [13:19] yeah, but not 1k? [13:19] no 1k, no Xxxx, no 9xxx [13:20] or in very short: support droped for all non-DX10-chips [13:22] Amaranth, afaik even fglrx is far behind Windows performance, so how much worse is the free one? [13:22] power consumption will be another problem; esp. on Laptops [13:23] KaiL: fglrx should be close to the windows version, radeon should be about 70% of that, power usage is a little higher than fglrx but not much and will get better [13:23] I never did any benchmarks on my X1400 or whatever though, so that's all from phoronix :P [13:24] i'm planning on doing some benchmarking actually [13:24] i have a gtx260 and a radeon 4870 to test with [13:24] I remember my old 9250, where page flip helped a lot ;) [13:24] i have a PPA with latest radeon/nvidia in it, for intrepid, which will help === cr3_ is now known as cr3 [13:25] I guess, the radeon-driver from intrepid might differ quite a lot from the ones in jaunty ;) [13:25] .o0(I hope, in the right direction ;) [13:25] well, fglrx anyway [13:26] i wish there were more engines to test with though. where's freaking UT3? o_o [13:26] the "Unigine" test might be interesting ;) [13:27] "Tropic" should land arround 13,5 with fglrx, so that's quite demanding [13:30] yes, ungine is one i've got [13:30] and there's etqw as the latest id tech engine one [13:30] but what else? [13:30] Nexuiz? [13:31] based on Q1, but much extended [13:32] slangasek: 1. a full export from Rosetta for the -base langpacks puts significant stress onto the Launchpad database. The last export took almost 3 days to complete. The resulting tarball is about 500MB in size. The converting into language packs on rookery takes about 3.5 hours then, plus the buildds take another 2 days or so to build all the -base packs. [13:32] slangasek: 2. the users will have to download the full set of translations every time, instead of just a few kB of diffs. [13:33] nah, no offense to the developers, but a nexuiz benchmark is worhtless. doesn't do anything in a remotely modern way, wouldn't stress a modern gpu in a sensible manner [13:34] Prey is another id tech afaik, but maybe newer than etqw [13:38] directhex, maybe UT2004? Better than no UT engine at all [13:38] hm, unigine is really spot on for this. [13:39] hehe [13:39] looks great, but eats TFlops for breakfast ;) [13:40] doko, slangasek: bug #339337 due to the pygtk, numpy change [13:40] Launchpad bug 339337 in gnome-games "sudoko tracker crash" [Medium,Confirmed] https://launchpad.net/bugs/339337 [13:40] KaiL, my benchmarking machine is a core i7 with 6 giggles of ram. should hopefully be gpu-limited [13:40] I guess yes [13:40] I know, that in a 4GHz C2Q eben Quad-SLI is GPU limited [13:41] even [13:41] Riddell: hey, you aware of bug 337791? [13:41] Launchpad bug 337791 in cmake "package cmake 2.6.0-4ubuntu2, E: Sub-process /usr/bin/dpkg returned an error code (1)" [High,Confirmed] https://launchpad.net/bugs/337791 [13:45] Riddell: installing kde-devel fails, so cmake needs to depend on emacsen-common (a merge would do) [13:53] tjaalton: Riddell is on travel at a conference AFAIK. [13:53] tjaalton: If you haven't, would you please comment in the bug and I'll see if I can get someone to look at it. [13:54] seb128: fgrep -r multiarray /usr/share/python-support/gnome-games-data/gnome_sudoku doesn't show anything [13:54] mvo, pitti: enabling protobuf is almost certainly going to cost us a langpack on one or more CDs, unless we find something else to offset it. Are there some help translations we can split? [13:54] ScottK: sure, thanks [13:54] siretart: absolutely; i was planning on doing that as soon as jaunty hit beta freeze [13:55] cjwatson: wasn't planning to set up a wiki page for it, so much as figure out how to leverage the hardware DB [13:55] siretart: it should be stable enough at that point to get it into backports [13:55]