[00:02] can u say that ubuntu development is agile? if yes, do u have any links for more info? [00:02] (it's for a university assignment) [00:10] owen1_: Maybe, and not really, but http://wiki.ubuntu.com/UbuntuDevelopment may help [00:12] persia: great. thanks [01:02] pitti: around? [01:52] benc: I didn’t manage to test the grub patch yet, but i’ll see if i get around to that tonight. [01:52] ion_: thanks...CC cking@ubuntu.com with any results, please [01:53] Will do [02:01] hi [02:01] Anyone here [02:01] Nope [02:01] ok kool [02:01] At least someone [02:02] Its like no one active in IRC [02:02] I need help installing a broadcom 4311 on ubuntu [02:02] Please read the topic. [02:03] ook [02:03] thanks [03:28] Keybuk: say, any idea why pcre3 is showing up on MoM as unmerged with a 2-day-old ubuntu version? [06:47] giskard: heya [07:08] Good morning [07:09] moin pitti [07:10] hey emgent [07:10] BenC: hi [07:10] * StevenK waves to pitti [07:11] * pitti throws a cookie towards Australia [07:11] And it landed where, across the street? :-) [07:12] hey pitti! [07:17] pitti: hey [07:18] pitti: is there any progress on package-groups? [07:19] BenC: not that I can see :-( Last thing I know is that mvo proposed it to Debian, but I didn't see feedback to that yet [07:26] pitti: should we even consider it an option for intrepid at this point? [07:26] BenC: I don't think it'll make it, I'm afraid :/ [07:48] pitti: that's too bad...I did all the kernel side stuff to make it work [07:48] guess that will be 9.04 [07:48] uh, sorry for that [07:49] BenC: what did you change, out of interest? add the P-G headers already? [07:49] pitti: no, just the last-good-boot stuff so that we could reasonably get rid of the versions in the pkg name [07:49] and move things to Version: and P-G headers [07:50] so it's not a waste [07:50] and I haven't done anything that needs to be reverted :) [07:50] BenC: oh, l-g-b is a separate feature anyway, right? [07:50] ok, *phew* :) [07:50] BenC: I'll ask mvo again about the status, I'm curious myself [07:52] BenC: BTW, last time I looked at it (or, rather, the error messages), it seemed to hardlink the current kernel/initrd [07:53] BenC: will that DTRT if there is a non-abi-updating new kernel package, too? [07:53] i. e. like the current -5.13 -> -5.14 [07:53] pitti: it saves everything on every boot...so yes [07:54] pitti: when a kernel update happens, the hardlinks are broken (dpkg doesn't overwrite the existing file, it always unlinks/renames) [07:54] pitti: same with update-initramfs [07:54] great [07:55] so that means cheap operation on boot (just ln, not cp), and correct behaviour on update [07:56] asac: any news on nspr/nss in hardy-proposed? [07:58] pitti: hey, jockey/intrepid question for you... [07:58] hey kirkland [07:58] pitti: i just moved my primary laptop over to intrepid, and jockey doesn't appear to see my atheros wireless, or nvidia video [07:58] pitti: are these known issues? [07:59] kirkland: it currently doesn't have any particular support for atheros ATM (nobody wrote a handler for it, or told me what to do for it) [07:59] kirkland: nvidia should work, though; do you have a minute to debug it? [07:59] pitti: sure [08:00] kirkland: first, do you have nvidia-common installed? [08:00] pitti: no, i don't [08:00] pitti: but nvidia is listed by lsmod [08:00] kirkland: n-c is not needed by itself, but it needs its dependencies, nvidia-VERSION-modaliases [08:00] kirkland: that would be it then; without the -modalias files, it cannot map vendor/product IDs to nvidia driver versions [08:01] kirkland: apt-get dist-upgraded without recommends? [08:01] pitti: not on purpose.... [08:01] oh, a hardy->intrepid dist-upgrade wouldn't actually pull in Recommends:, true [08:01] since we only enabled it in intrepid [08:01] pitti: ah, right [08:02] pitti: okay, nvdia-common (and friends) is installed now [08:02] might be an interesting thing to discuss with mvo, but I guess the answer is "use update-manager" :) [08:02] kirkland: sudo killall jockey-backend, then try again [08:02] pitti: I did do my upgrade via update-manager [08:03] oh? definitively mvo's bug then; can you please file a bug? [08:03] I guess it forgot to pull in recommends [08:03] pitti: sure, i'll talk to mvo in real time first [08:03] pitti: just to make sure i didn't do anything bone headed [08:04] pitti: shiny, now I have two different nvidia drivers to choose from [08:04] good morning [08:04] dholbach: welcome back! :) [08:04] thanks emgent [08:05] pitti: can't we use dependencies instead of recommends for nvidia-common? [08:06] * kirkland restarts X [08:15] tseliot: sure we could, but semantically Recommends: is the right thing [08:20] pitti: right but reliability > Semantics :-P [08:22] pitti: okay, jockey bits appear to be workign [08:22] pitti: nvidia x driver, that's another story ;-) [08:22] i'll ping bryce about that tomorrow [08:22] kirkland: nice, thanks [08:22] kirkland: or ask tseliot [08:23] tseliot: any known issues with nvidia in intrepid? [08:23] tseliot: true; I'll wait for the discussion about u-m, and raise to depends if nothing else helps [08:23] tseliot: i can't get gdm to start [08:23] kirkland: can I see your xorg.conf? [08:23] tseliot: sure... [08:24] pitti: ok, thanks [08:24] tseliot: this is the broken one: http://pastebin.ubuntu.com/33925/ [08:24] tseliot: I'm running on vesa now [08:25] kirkland: it looks good. Can I see your /var/log/Xorg.0.log.old? [08:26] so that I can see where X failed [08:26] tseliot: upgrading from hardy to intrepid nvidia doesnt work with old xorg.conf atleast most people had to run nvidia config (cant remember command off hand atm [08:26] tseliot: http://pastebin.ubuntu.com/33926/ [08:26] gnomefreak: because of the RgbPath line? [08:27] gnomefreak: i tried nvidia-xconfig too... no avail [08:27] tseliot: IIRC yes [08:27] kirkland: you can rebuild xorg.conf by hand but its easier with command. kirkland you installed the right drivers? [08:27] gnomefreak: I would like to deal with this problem during the dist-upgrade. [08:29] tseliot: after fixing xorg.conf after upgrade in april/may it doesnt look any different than the old one [08:30] kirkland: you're using a Quadro card. The log shows only the VESA driver but I suspect that the unified back buffer is conflicting with Composite. Can you try creating an "Extensions" section in your xorg.conf and adding Option "Composite" "Disable" ? [08:30] tseliot: sure [08:30] gnomefreak: what are you calling the "right" drivers [08:30] kirkland: nvidia-glx-# [08:31] after removing the old drivers [08:31] hmm, something wrong with a.u.c? can't update my laptop, some packages give 404's [08:31] kirkland: did you upgraded using update-manager? if so, could you make /var/log/dist-upgrade/main.log availabe for me please (mail or so)? [08:31] gnomefreak: i had 177, now i'm trying 173 [08:31] gnomefreak: the RgbPath line was usually added by nvidia-xconfig [08:32] i dont see it [08:32] mvo: I used update-manager -d -c [08:33] kirkland: if you try the other driver, please send me your /var/log/Xorg.0.log and /var/log/Xorg.0.log.old [08:33] gnomefreak: then you had a different problem which of course I can't see without a log [08:33] tseliot: http://pastebin.mozilla.org/506105 is my xorg.conf [08:34] gnomefreak: the xorg.conf is correct [08:34] maybe ill upgrade one of my other systems to see if i can reproduce it. sometime today or tomorrow [08:34] gnomefreak: ok [08:34] tseliot: thats from nvidia-xconfig [08:35] mvo: on its way (see the 2nd email from me) [08:35] tseliot: i have old one too [08:35] kirkland: thanks [08:36] tseliot: which driver are you interested in? [08:36] gnomefreak: ok, I would be glad if you could file a bug about this and attach the 2 files [08:36] mvo: hi [08:37] mvo: any archive changes recently ? [08:37] kirkland: whatever you want as long as I get a log which reports that X tried to load the NVIDIA driver ;) [08:37] tseliot: i would like to reproduce it first ;) but ill file one if it still happens [08:37] ok [08:37] * kirkland restarts X [08:37] lifeless: hi, I just added a tiny debugging patch to the conflictsfinder to hopefully get a better idea what is the issue [08:38] mvo: :) you could tell where I was leading :) [08:39] ok the archive works properly now [08:40] lifeless: indeed :) dozens of mails from the conflictsfinder are not easily ignored (unless I add a sieve rule :P) [08:40] kirkland: thanks, got it [08:41] tseliot: http://pastebin.ubuntu.com/33931/ <- with nvidia driver [08:42] kirkland: that looks like what i got after dist-upgrade well atleast same EE [08:42] kirkland: did you disable composite? [08:46] tseliot: I did [08:46] tseliot: it failed much quicker, at least [08:47] pitti: so you are the HAL maintainer? do you have an opinion about where to put the script which generates the X input-hotplug fdi-file (sources the values from /e/d/console-setup)? either hal or xserver-xorg is probably where it should be, but jcristau thought it could be useful not just for X, which would mean hal should generate the file [08:48] kirkland: hm, that seems to be a issue with the package itself, update-manager logs look ok, it selected a driver that it thinks was appropriate. does it not work with neither-177 or -173? [08:49] kirkland: something's hiding the real error (I hope). Try adding Disable "dri2" to the Module section of your xorg.conf and then start x with this command: startx -- -logverbose 5 [08:49] then send me the log again [08:49] mvo: i have not yet gotten nvidia to work with intrepid since I upgraded earlier tonight [08:50] tjaalton: I don't particularly mind to put it into hal; the fdi is generated at package build time and then just shipped? [08:50] tjaalton: what sort of information does it contain? It might or might not fit better into hal-inf [08:50] o [08:50] pitti: no, the script is run on postinst [08:51] postinst? why's that? [08:51] pitti: see http://people.ubuntu.com/~bryce/InputHotplug/console2fdi.sh [08:51] well it needs the values from console-setup [08:51] tjaalton: but what if the default file changes? [08:52] pitti: hmm then it might be console-setup that should host it [08:52] or the hal init script [08:54] that's possible as well [08:54] tjaalton: and we need to ship hal's 10-x11-input.fdi, too, I presume? [08:54] pitti: yep [08:56] does the new intrepid kernel work for anybody in kvm? [08:58] tseliot: wanna have a look at my xorg.conf before I give it another go? [08:58] tseliot: http://pastebin.ubuntu.com/33934/ [08:59] kirkland: it's "dri2" and not "dir2" [09:00] other than this, the file is ok [09:00] tseliot: doh! [09:00] tjaalton: so, I'm ok with doing that in the hal init script for now; feels like a hack, but I don't have a better idea ATM.. [09:01] tseliot: it *is* 3am in the morning ;-) [09:02] kirkland: ah, you live in the US [09:03] howdy! has the packages.u.c host gone offline? [09:04] seb128: good morning [09:04] tseliot: yeah, silly me, i though, "I'll just upgrade to intrepid before going to bed, so I can start work next week all shiny and using the new stuff" :-) [09:04] hello mdz [09:04] * kirkland goes restart X [09:04] seb128: Keybuk told me that the plan was to go ahead and package the new gdm (as a separate package) in Ubuntu, is there anywhere I can get it? [09:06] pitti: ok, cool. I'll discuss this again with bryce to see if there's a better "final" solution for it that also fits in debian (not sure if they even use console-setup yet) [09:07] About upgrade-manager pulling recommends on upgrade: can we detect cases where users have deliberately uninstalled packages? Be frustrating for some people to find things they previously uninstalled coming back. [09:07] mdz: https://code.edge.launchpad.net/~ubuntu-desktop/gdm/ubuntu, ./autogen.sh && debuild on the code should work but be warned it doesn't log users on first boot on my box (need to be restarted and then log-in works, dunno why), settings are not applied, gnome-power-manager doesn't work correctly, etc [09:07] seb128: thank you [09:07] mdz: it builds a gdm-snapshot which conflicts on gdm and fast-user-switch-applet (the applet is in gdm now) [09:08] seb128: the thread at http://mail.gnome.org/archives/gdm-list/2008-July/msg00024.html said there hadn't been a 2.23 release yet; is that still true? [09:08] mdz: you can probably bzr merge on the current gdm trunk to try the current version [09:08] mdz: no, they rolled a 2.23. [09:08] mdz: no, they rolled a 2.23.2 tarball some days ago because somebody asked for that [09:08] but they didn't put a lot of work on gdm since 2.22, the redhat guys who work on it have other focus this cycle apparently [09:09] seb128: do you know of a page anywhere which lists the known regressions? [09:09] tseliot: following a reboot, I'm in gnome using nvidia [09:10] tseliot: this is the 173 driver, with the xorg.conf you saw earlier [09:10] mdz: http://live.gnome.org/GDM/ToDo [09:10] tseliot: I am now going to press my luck and try the 177 driver ;-) [09:10] seb128: thank you [09:10] you're welcome [09:11] kirkland: ah, then rmmod nvidia and modprobe nvidia would have done the trick. A reboot did it. [09:11] kirkland: so you had the old kernel and nvidia module loaded? [09:11] echo :) [09:11] tjaalton: console-setup is not the default in debian, afaik [09:11] must have been.... [09:12] Q-FUNK: ok, thought so [09:15] pitti: tested and uploaded nspr_4.7.1+1.9-0ubuntu0.8.04.5_source.changes nss_3.12.0.3-0ubuntu0.8.04.4_source.changes with follow up fix for #245122 to hardy-proposed. let me know when its in, so i can individually verify each bug. [09:15] asac: oh, so it did need a followup fix? o [09:15] k [09:16] pitti: for update-manager yes. only dist-upgrade worked [09:16] pitti: the last upload drops the conflicts only [09:16] on libnss3 and libnspr4 (the old feisty packages built from firefox back then) [09:16] pitti: i kept the conflicts in intrepid branch so hopefully those packages get removed when users dist-upgrade to it [09:18] tseliot: okay, fyi, the 177 nvidia driver works too [09:18] all that's remaining is that splash appears to be broken [09:18] kirkland: great. Thanks for testing it [09:19] tseliot: no prob, thanks for helping me fix it [09:21] pitti: are we supposed to use hunspell or myspell dictionnaries in intrepid? [09:21] seb128: hunspell if available, but myspell dicts should work with libhunspell [09:22] pitti: installing hunspell-fr removes thunderbird, is that expected? [09:22] erm, no? [09:22] Conflicts: thunderbird [09:22] WTH? [09:22] urgh [09:22] whats that? [09:22] hunspell-fr [09:23] yeah. but why conflicts? [09:23] dunno [09:23] maybe that was added to force use of myspell? [09:23] it has versioned conflicts to firefox, etc., but the tbird one is unversioned [09:23] that's what I'm asking [09:23] (while back) [09:23] thats new [09:23] did we sync it? [09:23] asac: openoffice.org-dictionaries (1:2.4.0~m240-2ubuntu1) intrepid; urgency=low [09:23] -- Chris Cheney Tue, 01 Jul 2008 20:54:35 -0500 [09:23] asac: no, it's 2ubuntu1 [09:24] well, it has been merged not to long ago [09:24] hmm ... most likely the conflict comes from debian [09:24] from back when we renamed thunderbird to icedove [09:25] right [09:25] let me check [09:25] otherwise installing myspell-fr didn't work in evolution, it didn't list french [09:25] hunspell-fr works correctly though [09:25] seb128: yes. the icedove conflict is versioned? [09:25] then we should just use the same version imo [09:25] for tbird [09:26] asac: yes, icedove (<< 2.0.0.0-4) [09:26] yes. debian has unversioned conflict on tbird [09:26] seb128: the same versoin should be fine for us then [09:27] though i didnt do that package back then here [09:27] but it should [09:27] and since we are far ahead, that shouldnt matter anyway [09:27] alright [09:28] seb128: can you test? [09:28] test what? [09:28] hunspell spell checking in thunderbird? [09:28] if hunspell-fr works fine :) [09:28] thought you already installed it. if not i can do that [09:28] I'm reinstalling thunderbird [09:29] I did install hunspell-fr to get evolution spell checking working [09:29] which removed thunderbird [09:29] a minute, it's downloading [09:29] right. please force it. i am not 100% sure if we added a patch to icedove 2 for that or if that was in 1.5 [09:29] I'll force the install to test [09:31] asac: I don't know whether you caught this one or not https://bugs.edge.launchpad.net/ubuntu/+source/ubufox/+bug/253762 ? I thought I'd let you know asap though so it could get fixed :) [09:31] Launchpad bug 253762 in ubufox "Intrepid: Ubufox no longer asks to install flash when going on youtube" [Undecided,New] [09:35] asac: yes, spellchecking works fine in thunderbird when hunspell-fr is installed [09:40] seb128: good. [09:40] thanks [09:45] benc: You’ve got mail. Btw, Cc: cking@ubuntu.com bounced. [09:48] mvo: syntax error:P [09:51] lifeless: *cough* that comes from editing source code before the first cup of tea === slangase` is now known as slangasek === doko_ is now known as doko === wgrant_ is now known as wgrant [10:35] thekorn: good morning [10:36] hi pitti [10:36] thekorn: was the API break in bug 254556 deliberate (cleanup) or just a glitch? [10:36] Launchpad bug 254556 in python-launchpad-bugs "API breakage: 'ConnectBug' object has no attribute 'Error'" [Undecided,New] https://launchpad.net/bugs/254556 [10:38] pitti, honestly, it was not a glitch [10:39] but I understand that this is unfortunate, [10:39] so, I think the best way is to recreate Bug.Error [10:40] depends on how ugly it is to reinstate it, I guess [10:41] pitti, there are a few more changes: https://wiki.ubuntu.com/BugHelper/Dev/python-launchpad-bugs/changes_0.3 [10:41] pitti, i will think about it later today, and comment on this bug [10:42] thekorn: ah, thanks for that [10:43] thekorn: alternatively I need to switch to a more stable branch in the retracers, and cherrypick the html screenscraping fixes myself [10:43] pitti, I'm working on integrating launchpadlib into py-lp-bugs [10:43] so no need for screenscraping anymore [10:44] thekorn: oh, already? great! [10:45] What kind of API does launchpad offer? [10:45] ah, https://code.edge.launchpad.net/launchpadlib is new to me [10:45] REST? [10:47] ion_: yep [10:47] Neat [10:59] kees: hm, your recent "fix bold fonts in the terminal" made things much worse for me; did you hear other reports about regressions? [10:59] kees: (before it looked just fine) [11:00] pitti: erk, worse how? [11:01] some characters, like 'm' now look very untidy [11:02] Yeah, m became noticeably uglier recently. === ogra_ is now known as ogra [11:07] kees, Ng: http://people.ubuntu.com/~pitti/tmp/boldfonts.png [11:08] huh. is the patch being carried in Intrepid? [11:09] I just remember that kees recently uploaded something to intrepid, but I forgot the package name; easy enough to find out again, I guess [11:09] asac: guess what I'm going to ask you? [11:10] hi, is there any reason that ffmpeg in intrepid doesn't contains anymore the h263 encoder by default [11:10] https://bugs.launchpad.net/ekiga/+bug/254201 [11:10] Launchpad bug 254201 in ffmpeg-debian "feature regression: ffmpeg lacks some video encoders (like h263+, MPEG4, maybe more...)" [Undecided,New] [11:11] pitti: .. ical gekommen? [11:11] Spads: that's a small part of my IRC window, I just moved it there to avoid copying my entire screen [11:12] kees: can't find it right now, which package was that? [11:13] his font patch ought to be in libvte [11:13] ah, indeed [11:37] norsetto: update? [11:38] norsetto: i have a huge backlog ... saw that i had a mail or two from you [11:38] norsetto: if its important tell me ;= [11:38] asac: I was just going to ask if you received an email from me ;-) [11:39] even two iirc [11:39] asac: its gnome-mplayer 0.6.3-2 which closes the ftbfs if built twice in a row bug [11:39] my mail server was down for a week ;) [11:39] norsetto: ah cool. you have it uploaded? [11:40] asac: yes, its in mentors, link in my email [11:40] asac: Justin Case: http://mentors.debian.net/debian/pool/main/g/gnome-mplayer/gnome-mplayer_0.6.3-2.dsc [11:43] norsetto: i dont have my debian system here. might take a few days till i can access that again :( [11:43] asac: well, what other choice do I have? [11:44] norsetto: stand still ... i might be able to do it on Wed if all works out well [11:44] if it takes longer we need to find some other sponsor [11:44] asac: I won't move ;-) Danke! [11:44] np === ScottK2 is now known as ScottK [12:23] hmm, shouldn't attached media be automatically umounted if the user yanks the device out without ejecting it? [12:27] yep [12:27] and you should get a "unsafe device removal" msg [12:27] What if the file cache is dirty? How about if the user reinserts it later? What about cases where there's no physical removal event reported by the HW? [12:28] I've seen the same media being listed by df/mount on two different machines, and another user reported that the media was shown on the desktop (but inaccessible of course) [12:28] persia, i doubt you can do anything for the latter case [12:29] ogra: Well, the Luddite in me likes to say we should train users to unmount before ejecting as a workaround, but you're probably right :) [12:33] the ltsp developer in me says we should have a way to overcome unmounting ;) [12:34] embedded me says we should make the device manufacturers guarantee reads and writes and not corrupt even if stupid users eject [12:34] ogra: Well, we could stop supporting removable media... [12:34] well, we could switch the whole system to ltspfs :P [12:35] (which doesnt support unmounting) [12:35] And is nicely atomic. Still means one needs to shut down to remove the USB key. [12:37] ?? [12:37] no [12:37] Maybe a udev hook on device removal into ltspfs to kill the FUSE? [12:38] you just yank it out if the progressbar of your filemanager is gone [12:38] ltspfs devices are always unmounted ... only while write operations are in progress they are mounted [12:39] ogra: so they're not POSIX, then [12:39] as in, it's not a POSIX file system. [12:39] * persia reads LtspFSAutomount, having obviously missed something [12:39] Mithrandir, they are whatever FS is on the device ... ltspfs sits on top, its a network FS [12:39] persia, the documentation is a bit sparse ... [12:40] ogra: that's irrelevant. Or do you wait until all files are closed before you umount? [12:40] yes, indeed [12:40] ogra: Very much so. I'll take your word about the umounting, as I can't see any documentation that indicates it's safe to pull a device and reinsert later, while preserving user semantics. [12:40] actually they are forcefully closed until they change [12:40] that's even worse, then. [12:40] The only issue is the 2 second sleep cycle while background mounting devices on each new read. [12:41] since you can't open file, unlink file, continue reading and writing and then the file goes away when you close it. [12:41] Mithrandir, not in the ltsp case where we have the guarantee that only the one user on the terminal acesses them ... [12:41] other users cant acess the devcie [12:42] ogra: What takes down the FUSE filesystem on device removal? Is there another udev rule not listed under "udev intereaction"? [12:42] so even if you pull out the device while openoffice is still open you will have a saved copy of the changes of the last two seconds [12:43] persia, right, there are two udev rules [12:43] one for mounting, one for unmounting [12:44] ogra: In practice, how noticeable is the 2 second delay? [12:44] not at all [12:44] Hmm... Not going to happen in the next 24 days, but tempting to add to the agenda for the next UDS. [12:44] and i havent had any reports of dataloss or anything within the three years we use ltspfs in ltsp [12:45] Well, I can construct a scenario that generates data loss or data corruption, but it would do that with the current model as well. [12:45] in fact its an assembly of autofs, fuse and some glue [12:45] you could do similar things locally with autofs afaik [12:46] Yes, but you still want the FUSE layer to provide the atomicity [12:46] right [12:46] (Otherwise Mithrandir's comments suddenly become relevant) [12:46] and the caching of the device contents [12:47] Well, for local, I'm not sure full caching is so important: imagine inserting a 700MB CD on a 384MB RAM system. [12:47] Caching of open files is critical for atomicity, but that's only one file at a time. Might choke on some DVDs though. [12:48] (Depending on the cell progression definition, etc.) [12:48] it wouldnt cache 700M :) [12:49] mvo: ubuntu ddtp stuff would seem to work. the omissions wrt Debian are probably because of different versions or Ubuntu-specific changes to package descriptions [12:49] just the directory structure ... so it appears transparently to the user while not being mounted [12:49] Mirv: aha, nice. happy to hear that [12:50] the ltspfs client side pretends that the device is mounted all the time ... for that you need to cache the structure, but not the actual content [12:51] mvo: what about the gnome-app-install's title (shown in list and detailed view) and description (shown only in the list) strings, are they coming from .desktop file's Name and Comment or where? what about commonly seen stuff like gstreamer codecs, are they untranslatable at the moment (eg. "Gstreamer ffmpeg video plugin" and "Codecs to play mpeg, divx, mpeg4, ac3, wmv and asf files" strings)? [12:54] (since those don't have .desktop files) [12:56] Mirv: the name and comment come from the desktop files in app-install-data [12:56] Mirv: good point about the codec stuff, I think I need to add some magic to make that app-install-data package iimportable into launchpad [12:56] Mirv: feel free to file a bug about that [12:57] mvo: ok, I'll do that [12:57] Mirv: thanks! [13:03] ogra: Ah. That makes more sense. [13:05] (bug 254628) [13:05] Launchpad bug 254628 in app-install-data-ubuntu "Make it possible to translate eg. codec name/description strings" [Undecided,New] https://launchpad.net/bugs/254628 [13:15] not for the first time, I wonder what wyciwyg:// means [13:34] Keybuk: What you cee is what you get [13:34] when you cry i whack you gently ? [13:35] persia: all I see whenever I see those URLs is a white page and a spinner [13:36] Keybuk: Which browser? epiphany loads them for me. [13:36] epiphany [13:36] Hrm. Maybe because I'm still running hardy? [13:36] as am I [13:36] http://stephenfry.com/blog/ [13:37] click "Read full column »" for the second article ("Well worth the wait") [13:37] same in Firefox [13:37] Hmm. For that one I'm getting a spinner. [13:38] I had a couple from liferea earlier that worked (although I forget which, but noticed as I had a browser crash at the same time, and needed to recover the session) [13:39] Ahhh.... "What you cache is what you get" [13:45] Keybuk: Looking a bit deeper, it seems that it's an AJAX call that fails on the cache load. [13:45] Link from the column title (above) works if you just want to read. [13:46]