[00:04] Shortly after starting the install I get "Call Trace:" and then "Code: e6 01 00 90 etc" [00:06] any ideas? [00:06] wamty: I suggest you file a bug against ubiquity in launchpad. [00:06] ? [00:06] As the people who are most likely to be able to help you are not likely to be around at the moment. [00:06] what do u mean [00:07] why not [00:07] Well for one thing, its almost midnight where the installer maintainers live. [00:07] Because it was Sunday for them until 7 minutes ago. [00:11] wamty: /c [00:11] what does that mean? [00:11] wamty: sorry that was a typo [00:12] wamty: To file a bug, I suggest you have a read here. https://help.ubuntu.com/community/ReportingBugs [00:12] maybe its not a bug [00:12] i dont know wha it is [00:12] s [00:13] wamty: A call trace sounds like a bug to me. [00:15] call trace sounds like a kernel oops to me [00:15] especially with teh "Code: ..." after it [00:28] pitti, ping. i wanted to ask you about letting users report bugs for packages from PPAs that are very close to upstream code, so that apport doesn't complain about them being non-genuine packages. we recently (today) switched one of the mythtv trunk PPAs to build in debug mode, so between the dropping of optimizations and the dh_strip not doing any stripping for PPA builds, I think these should be pretty useful to upstream [00:51] anyone know what injects dbus messages for new devices ? [00:53] udev? [00:54] lifeless: I thought udev had its own protocol [00:55] superm1: Where would they be filed? [00:55] lifeless, maybe, maybe, or do you _know_ its that [00:55] Amaranth: so udev listens to the kernel; the get-rid-of-hal work consists of udev events that translate and broadcast to dbus [00:55] apw: I'm 95% sure [00:55] ScottK, against the same source package in the archive [00:55] * Amaranth checks code [00:55] in jaunty it looks like its hal [00:55] i think for some projects it makes a lot of sense still [00:56] superm1: I think that's horribly inappropriate. [00:56] apw: in jaunty it is hal [00:56] in karmic it is _noone_ for me [00:56] ScottK, i'd be fine with a whitelist, or drop a file in place to make it activated for any particular blessed package [00:56] there was a massive thread on d-d recently about this in the context of systems with /usr on separate fs's. [00:56] apw: hal should still be around to do that, it is used for xorg still [00:57] ScottK, but i'm sure that other projects with daily builds can get the same kind of benefits like this too then [00:57] superm1: I think what it needs is a different place to land non-ubuntu bugs. [00:57] hal is seeing the new devices i insert, just nolonger am i seeing dbus events, therefore gnome doesn't do it [00:57] superm1: I think it's great, just not against Ubuntu. [00:57] apw: gnome uses udev [00:58] Amaranth, 'used' udev .. how is it plumbed in? do you know? [00:58] uses even [00:58] lifeless: it looks like udev doesn't have a dbus dependency [00:58] apw: via libgudev? [00:58] Amaranth, hrm, thanks will look at that [00:58] apw: yeah, gvfs depends on libgudev [00:59] Amaranth: I likely have the fine detail wrong; I do recall the transition and that its udev's problem now ;) [00:59] so nautilus uses gio which uses gvfs which uses libgudev which is actually a wrapper around libudev which uses udevd [00:59] Wow I would hate to debug that [01:00] so we might not expect to see dbus events now then [01:00] i do have udev events for the new devices [01:00] apw: Well like I said we still have hal around for xorg so hal should still be reporting device connections [01:00] it maybe meant to be, but its not [01:01] maybe it was crippled somehow *shrug* [01:01] i have the problem that i know whats not happening, but not whats normal [01:01] yeah half finished sometrhing i expect [01:06] apw: devicekit-disks [01:06] for disks [01:06] other things for other types of hardware [01:06] there's no single thing like hal anymore [01:07] if there is a daemon corresponding to what you are trying to do then using the DBus connection to that works [01:07] ah, right, forgot devicekit-disks is still around [01:07] otherwise libgudev or similar to listen to udev events would work [01:07] if it has to be DBus then a devicekit-* for the class of hardware that translates from udev to DBus would be needed [01:08] devicekit-disks and devicekit-power are the only ones [01:08] yep [01:17] james_w, thanks for the info [01:18] it appears that /usr/lib/gvfs/gvfs-gdu-volume-monitor is finding out about it directly from udev [01:18] i wonder what that actually does [01:19] but gvfs itself does not appear to get told [01:32] fatal: I had/have the ultimate blackness too [01:34] fatal: if fsck is running, it could be 10 minutes+ of blackness before xsplash+gdm start [01:34] fatal: and (recovery mode) doesn't do anything === Amaranth_ is now known as Amaranth === GuilhermeCunha_ is now known as GuilhermeCunha === a1g is now known as alex4 === alex4 is now known as alex1 === alex1 is now known as a1g === a1g is now known as alex3 === alex3 is now known as alex1 === alex1 is now known as a1g [03:38] directhex: heh just noticed the nspluginwrapper bug too [03:51] What are the kernel modules that control webcams? [03:51] many.... uvcvideo is one of the more common ones [03:52] I was wondering if it is possible to control exposure time [03:52] I thought typically that's something automatically controlled by the camera [03:53] indeed it is [03:53] typically exposure time increases with the decrease of ambient light :) [03:54] but I'm doing some science experiments, and the autoexposure is screwing everything ;) [03:54] probably a webcam isn't your best tool in that case [03:54] I see [03:54] here in our MIT intro biophysics classes we use a firewire fancy module [03:54] which does allow every capture parameter to be controlled by software [03:54] nice [03:55] you mean a firewire camera? [03:56] yeah, some sort of firewire connected camera [03:56] interfacing with a Ubuntu UI [03:56] I'm only a customer of the setup so to speak, though :) [03:57] ;) [03:57] thanks for the hints! I will research more [03:57] cya [03:57] sure thing === ecanto is now known as ecanto-afk [05:04] c === bjf-afk is now known as bjf-_- === bjf-_- is now known as _bjf-afk [06:26] anyone here have experience with kerberos and capaths? [06:29] excuse me, im trying to compile a vanilla kernel in ubuntu, whats the command to make a .config file from the current running kernel? [07:11] Good morning [07:14] superm1: you can ship a small code snippet which makes them being reported against the product (see /usr/share/doc/apport/crashdb-conf.txt); is that what you need? [07:15] pitti, interesting, that looks like it would do the trick [07:16] just need to find a way to integrate it without disturbing standard packages (they use the same bzr branch) [07:16] superm1: perhaps like this: [07:17] superm1: ship a crashdb.conf.d/mythtv.conf with a "mythtv" db (use launchpad_impl and set 'product': 'mythtv') [07:17] superm1: and then ship a package hook which checks the version (ppa or not) and sets report['CrashDB'] = 'mythtv' for PPA packages [07:18] pitti, ah yeah, that sounds like the perfect way to do it. thanks! [07:18] superm1: please let me know about troubles; crashdb-conf.txt and package-hooks.txt.gz aren't very verbose about this yet [07:19] pitti, will do. i'll try'n sort out the details for it this week [07:21] good morning [07:29] * pitti hugs dholbach [07:30] * dholbach hugs pitti back [07:32] pitti: Do you have a few minutes to talk about the archive administration side of Soyuz ddeb support? [07:32] wgrant: sure [07:33] pitti: So, ddebs are represented in Soyuz just like normal debs. This means that at the moment they don't follow their debs around, so removals/overrides/copies of a binary will not drag along the ddeb. This seems like it could get pretty tedious. [07:34] So I'm going to implement some improvements which will cause overrides/removals of a deb to also detect and operate on the deb. [07:34] Sounds sane? [07:34] absolutely [07:34] I don't see why we should have the ddeb in a different component [07:35] Right. It'll also need some tricks to automatically inherit the deb's overrides at upload-time, to avoid pushing *every* binary through new once we hit the button. [07:35] Now, ddebs will be removed from the archive indices as soon as they're superseded. That's not a good thing for the retracers, is it? [07:37] wgrant: it's what we currently have [07:37] wgrant: I think it's fine for the Packages.gz files [07:37] wgrant: they don't disappear from LP, I recently learned how to retrieve all files from any build through launchpadlib [07:37] so if we wanted to make the retracers more clever about older versions, we could still do it [07:38] pitti: OK. They'll be removed from the archive disk immediately, but will still be available from the librarian. [07:38] *nod* [07:38] You'll probably need to manually NBS out ddebs, unfortunately. [07:39] wgrant: that sounds scriptable, though [07:39] I can't think of a way around that, so I hope it's OK. [07:40] wgrant: where will they land? not on archive.u.c., I hope? [07:40] pitti: No. They will exist in an entirely separate archive. [07:40] wgrant: it would be great if we could just move ddebs.u.c. to point to that archive [07:40] Otherwise it would be really easy. [07:41] pitti: That would be good, although there is the slight problem that none of the old ddebs will be in the new archive. [07:41] ah, bummer; we can't 'seed' them? [07:42] Not exactly. While it's probably technically possible, it seems like a pretty awful thing to do (inject binaries into builds). [07:43] You might just have to leave the retraces also pointing at the old archive for a while. Or convince somebody that the evil required to do the import is justified. [07:43] wgrant: ok, so I propose we keep ddebs.ubuntu.com/old/ around on macaroni, and point the main ddebs.u.c. to the new archive [07:43] so for a while we use both [07:44] pitti: Sounds sane. [07:45] I think that's probably it. Let me think.... [08:14] pitti: where's the jockey handler for bcmwl? === tkamppeter_ is now known as tkamppeter [08:20] pitti: aah, it's only in the ubuntu branch. Never mind [08:58] Hello have been told to come here as I ve got a problem with glibc. Upon fatal runtime errors the backtrace is written to the tty directly rather than stderr, which renders it impossible to redirect the error to something like less in order to read it. Is that a well known problem with the runtime of glibc or just my specific problem? [09:06] pitti: if I (successfully) install the broadcom driver in Jockey, Jockey's interface doesn't refresh and it looks like it wasn't installed: http://paste.ubuntu.com/275109 [09:07] (the module is loaded) === asac_ is now known as asac [09:18] tseliot: "unbind/rebind on driver /sys/module/wl/drivers/pci:wl: device 0000:03:00.0", nice so that actually works? [09:19] tseliot: the handler doesn't rmmod b43 and friends, do you still have any of those loaded? [09:19] tseliot: oh, wait, it does [09:19] pitti: no b43, etc. module is loaded [09:19] tseliot: does 'lsmod | egrep '43|ssb' still show anything? [09:21] tseliot: ah, I think I know what's going on; could you test something for me? [09:21] pitti: http://paste.ubuntu.com/275115 [09:21] pitti: sure [09:22] tseliot: in broadcom_wl.py, enable(), after KernelModuleHandler.enable(self) (i. e. very last line) [09:22] OSLib.__load_module_blacklist() [09:22] append this [09:22] KMH.enable() will install the package, which installs the blacklist [09:23] but jockey doesn't update its blacklist cache === dholbach_ is now known as dholbach [09:24] pitti: wouldn't it be something to add to enabled() instead (which I assume you call after enable() to make sure that it worked)? [09:24] just asking [09:25] tseliot: I think enable() is better, enabled() is called much more often, and is only a read operation [09:26] pitti: ok, let me try === cjwatson_ is now known as cjwatson [09:51] pitti: it complains that class OSLib has no attribute '_BroadcomWLHandler__load_module_blacklist or, if I remove the 1st underscore, TypeError: unbound method _load_module_blacklist() must be called with OSLib instance as a first argument (got nothing instead) [09:52] tseliot: oops, sorry; it's just a single _, not two __ [09:53] pitti: which gives me the 2nd part of my previous message [09:53] tseliot: so, it's correctly: [09:53] OSLib.inst._load_module_blacklist() [09:53] (forgot the .inst as well) [09:53] ok, let me try again === ogra_ is now known as ogra [10:02] pitti: that seems to work [10:11] pitti: any further thoughts on bug 432542? [10:11] Launchpad bug 432542 in usb-creator "UI freeze exception for usb-creator 0.2.7" [Undecided,Incomplete] https://launchpad.net/bugs/432542 [10:12] also, do you think a new upload of devicekit-disks is warranted for 007, or should we just cherry pick the crucial patches from it? [10:20] evand: hi [10:20] tseliot: great, will commit [10:20] hi pitti [10:20] pitti: thanks [10:21] tseliot: in fact, I should commit that to trunk to the generic Handler, since other packages could install blacklist files as well [10:21] evand: DK-disks 007 is in karmic, needed by new gnome [10:22] evand: usb-creator> I'll do a quick review of the PK backend, still on my todo list [10:22] ah, I didn't think to check this morning [10:22] good deal [10:22] thanks a bunch! [10:22] pitti: right, even better [12:05] cjwatson: Can you try newComponentUploader again and get an OOPS ID at some point, please? [12:10] wgrant: remind me how I get the OOPS ID out of the API? [12:11] cjwatson: Try catching the exception and check the 'content' attribute. [12:14] tkamppeter: hi! did you recently reorganize openprinting.org? my jockey test suite fails now, it doesn't find the "openprinting-ppds-postscript-hp" package for 'MFG:Hewlett-Packard;MDL:HP LaserJet 3020' any more [12:18] wgrant: confused; e.content is (, 'newComponentUploader', 'launchpad.Edit') [12:18] wgrant: and the HTTP code is 401 unauthorized [12:19] so no longer an internal server error, which IIRC it was over the erweekend [12:19] tkamppeter: I change the tests to "DesignJet 3500CP" now, according to http://www.openprinting.org/show_printer.cgi?recnum=HP-DesignJet_3500CP [12:19] cjwatson: You gave launchpadlib full write access? Because... you own the archive. [12:20] I *think* so, but I'll try again [12:20] DrPepperKid: hey Mirco :) [12:21] pitti_, I'm here in my "alter ego" form just for debugging :) [12:21] cjwatson, whats up with your locales today ? its the second time i see weirtd cahrs from you [12:21] *weird [12:21] ogra: I don't see anything weird? [12:22] * pitti_ doesn't either [12:22] the erweekend [12:22] * wgrant neither. [12:22] i see er, then two squares and then weekend attached to it [12:22] just a normal '.' here [12:22] I don't see the two squares. [12:22] strange [12:22] it's not locales, it's that my network is ridiculously laggy and so irssi/ssh is exhibiting some weird knock-on effects from typeahead [12:23] well, but i see stuf interpreted others dont, must be me then [12:23] *stuff [12:23] * sistpoty|work sees it two (running debian/stable here at work) [12:23] weechat might just filter it out [12:23] wgrant: my bad - that seems to have worked fine now. I think I had two oauth tokens with the same identifier but different privilege levels and was therefore confused. :( [12:23] too [12:23] the squares were probably raw backspace characters or something [12:23] cjwatson: So it didn't even 500 this time? [12:23] wgrant: apparently all good now ... [12:24] cjwatson: Strange, but great! [12:24] ubuntu-dev should have give-back access to that archive now, then [12:24] cjwatson: Thanks. [12:37] morning === doko_ is now known as doko [12:51] asac: time to fix the xulrunner-1.9.1 build on sparc, powerpc, ia64? [12:52] doko: mind to take a look at bug #433368? (if you want, I can try to provide a minimal test case) [12:52] Launchpad bug 433368 in gcc-4.4 "[regression] lensfun 0.2.3-0ubuntu4 freezes UFRaw." [Undecided,Confirmed] https://launchpad.net/bugs/433368 [12:53] sistpoty|work: gcc-snapshot results? [12:54] doko: haven't checked with gcc-snapshot yet [12:55] doko: will do (but only an half an hour or so... must leave for a meeting in 5 minutes) [12:57] sistpoty|work: hmm, we had something similiar, 4.4 only reserves storage so that all values of the enum fit. does adding an UINTMAX value in the enum type help? [12:58] doko: I haven't checked that yet, but I'd think so. [13:11] doko: ia64: [13:11] The following packages have unmet dependencies: cdbs: Depends: intltool but it is not going to be installed mozilla-devscripts: Depends: libxml-xpath-perl but it is not going to be installed [13:12] xpidl crashes on ppc [13:12] sparc i have a fix for [13:13] asac: retry ia64 [13:13] it was broken, it should be somewhat better now [13:14] in fact, I'm on the page anyway, I've retried it [13:16] sistpoty|work: then it's a bug in the code ... see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36917 [13:16] gcc.gnu.org bug 36917 in tree-optimization "[4.3 regression] miscompilation with -O2 and r136501" [Normal,Resolved: invalid] [13:18] thx [13:18] mpt_: hi! at bug #433838 only Get Free Software menu item needs the icon on the location bar? [13:19] Launchpad bug 433838 in software-store "Use an icon in the location bar" [Low,In progress] https://launchpad.net/bugs/433838 [13:19] or Installed, etc, etc? === mpt_ is now known as mpt [13:20] sianis, *if* we did it, we should do it for all sections that have a path button, i.e. currently both "Get Free Software" and "Installed Software". [13:21] mpt: right, I am posting a patch ... [13:23] asac: would you mind uploading the fix? you did tell me having the fix weeks ago ;p [13:23] * asac checks powerpc porter machine === Tonio__ is now known as Tonio_ [13:32] mpt: patch's attached [13:33] Thanks sianis. I'll put it on the list of things to user-test. :-) [13:42] doko: ah thanks, that 36917 matches my observations. Just wasn't sure if it's legal to reduce the size of an enum. Thanks for looking! [13:45] doko: http://paste.ubuntu.com/275224/ [13:45] doko: maybe libidl needs to be rebuild? [13:46] or any idea why something might crash in _savegpr_14 ? [13:48] asac: ENOCLUE. but why not check it on the porter box? [13:48] doko: I am on the porter box [13:48] doko: i cannot install libidl i locally built [13:48] at least not easily [13:48] and LD_LIBRARY_PATH doesn't work? [13:49] probably would [13:49] trying something else now [13:52] gcc-4.3 works [14:10] pitti, yes I did a change on OpenPrinting.org. I removed most HP PPDs, as they are maintained by HP in HPLIP but not any more on OpenPrinting. [14:10] tkamppeter: ah, ok; thanks [14:11] The recommended driver for the LJ 3020 is HPLIP now as the appropriate PostScript PPD is part of HPLIP.\ [14:19] doko: seems to a compiler bug or something further down. -Os makes it crash like the paste above ... -O2 and -O0 seem to work [14:19] http://www.mail-archive.com/linuxppc-dev@lists.ozlabs.org/msg17189.html [14:20] asac: and -Os is turned on by default? [14:20] yes [14:20] gcc 4.3 works [14:21] why do people turn it on on archs they don't use/test ... [14:21] at best we would just disable whatever feature triggers this [14:21] it worked before and noone complained. we can use -O2 on ppc, but that hides the problem imho [14:34] hi everyone. i18n question. i have written a very basic gettext(3) test program. it calls setlocale(), bindtextdomain(), textdomain(), and then gettext() on commandline arguments, and prints the results to stdout. i have straced my program, and i see glibc looking in /usr/lib/locale and /usr/share/locale-langpack, but *not* in the directory i have specified to bindtextdomain(). is this some kind of ubuntu gettext caveat? [14:38] asac: yes, but extracting a test case takes time ... [14:38] please help! i have spent way too much time on this already... :( [14:38] hdon: is the path relative? [14:38] hdon: I can't reproduce this with a trivial test program. Can you post your source code? [14:39] mattn: it may be in the future, but at the moment i am specifying a relative path. are absolute paths not allowed? [14:39] sure, one sec.. [14:39] hdon: it's supposed to work; it will fallback looking into .../locale-langpack/, but it's supposed to respect bindtextdomain [14:39] http://paste.ubuntu.com/275270/ is my test [14:40] it works here, too [14:40] http://paste.ubuntu.com/275272/ [14:40] relative paths work for me too [14:41] although I don't know that I'd expect them to be reliable [14:41] cjwatson: thank you for experimenting with me. i wonder why i can't get this to work.. [14:41] calling setlocale on both LC_ALL and LC_MESSAGES is weird [14:42] cjwatson: i know, i was just a little exasperated and added LC_ALL even though i am trying to use an LC_MESSAGES file [14:42] hdon: what is the output of "locale" [14:42] do you have that locale installed on your system? [14:43] mattn: all en_US.UTF-8 [14:43] and you have fr_WHATEVER.UTF-8 installed on your system, too? [14:43] mattn: see this: [14:43] donny@pacemates:~/gpsee/gt$ dpkg -S /usr/share/python-support/python-django/django/conf/locale/fr/LC_MESSAGES/django.mo [14:43] python-django: /usr/share/python-support/python-django/django/conf/locale/fr/LC_MESSAGES/django.mo [14:43] nono, the system locale [14:43] locale -a | grep fr [14:43] i had to install e.g. russian to text our game with a russion translation [14:44] s/text/test [14:44] that's odd, your program is only triviallly different from mine but doesn't work [14:44] nonetheless, i should be able to load this .mo file [14:44] maybe - but it won't do anything with it if you don't have that locale [14:44] mattn: I don't think this is relevant - it's failing for me even if I ditch the fr [14:44] that's indeed strange [14:45] mattn: hmm, ok, which package(s) do you think i should install to make my test program work? [14:45] if your theory seems to work, then that will at least give me a direction to go [14:45] cjwatson: have you tried watching in strace? [14:46] hdon: language-pack-fr [14:46] ttx: any reason for libgnumail-java-doc to be in main? It's trying to pull in classpath for just classpath-doc, and that pulls in a lot of other things [14:46] not sure whether it's all needed - maybe there is a separate locale package, too [14:46] cjwatson: here are the locations my glibc on Jaunty searches for the "fr" locale: [14:46] /usr/lib/locale/fr/LC_IDENTIFICATION /usr/share/locale-langpack/fr/LC_IDENTIFICATION /usr/lib/locale/fr/LC_MESSAGES /usr/share/locale-langpack/fr/LC_MESSAGES /usr/share/locale-langpack/fr/LC_MESSAGES/SYS_LC_MESSAGES [14:47] ttx: though I'm having a bit of trouble even finding what is keeping the -doc package in main. [14:47] i generated that list with this command: donny@pacemates:~/gpsee/gt$ strace ./a.out Yes 2> log && echo `grep -o '[^"]*fr[^"]*' log` [14:47] forget that, it doesn't matter [14:47] mattn: incidentally i did install that package for kicks [14:48] so the problem is that there is no such locale as "fr" *at all*, no matter what package you install [14:48] it's not a valid locale name [14:48] instead, you should just do setlocale(LC_MESSAGES, "") up top, and that will use the current locale [14:49] (actually most internationalised programs just do setlocale(LC_ALL, "") up top) [14:49] and maybe add LANG=fr ./yourApp [14:49] no, LANG=fr is an invalid locale [14:49] LANG=fr_FR>UTF-8 [14:49] err, LANG=fr_FR.UTF-8 [14:50] but i *do* have an fr locale. in fact i don't have an fr_FR locale. not in /usr/share/locale, nor in /usr/share/python-support/python-django/django/conf/locale [14:50] no, you don't [14:50] valid locales are those listed in the first column of /usr/share/i18n/SUPPORTED [14:50] ah, hmm [14:50] not subdirectories of /usr/lib/locale or whatever [14:51] hdon: you have "fr" translations [14:51] that is not mentioned in the gettext(3) manual [14:51] pitti: ah, thanks. i was using the wrong term entirely then :) [14:51] it's mentioned in locale(1) [14:51] in the FILES section [14:52] hdon: a translation is done for a language in most cases ("fr"); exceptions are countries with similar, but sufficiently differing languages such as Portugese and Brazilian Portugese, or British and American English [14:52] cjwatson: thanks, i'll read that now [14:52] checkrdepends knows about seeds doesn't it? [14:52] is a "Suggests:" enough to stop something showing up on component-mismatches? [14:53] mpt, mvo: can we chat about software-store and kde frontend? evand suggested I chat with one or both on this... [14:54] rgreening, sure, though I don't know how much help I would be. I are just the designer. [14:54] james_w: no [14:55] ok, if my program only calls setlocale() with setlocale(LC_ALL, ""), then it appears i can control where libintl/glibc looks for translation files with the LANG environment variable. however, it still does not look in the path that i provide to bindtextdomain() :( [14:55] * hdon sighs [14:55] thanks for the help btw. i realize this is probably not really a developer support channel [14:57] hdon: it worked for me as long as I actually had a valid LANG [14:57] mpt: well, I am interested in eith developing the KDE front-end or assisting in developing it. [14:57] cjwatson: where did you get your translation file? [14:57] cjwatson: i would like to try to duplicate your success [14:57] who cares, it was looking in the right places as seen by strace [14:57] mpt: I recently developed the kde front-end to usb-creator, so I figured I could help with the new software-store. [14:58] cjwatson: oh, ok, fair enough [14:58] try it with LC_ALL=en_US.UTF-8 or something like that that's guaranteed to exist [14:58] james_w: no, no reason. [14:58] open("/usr/share/python-support/python-django/django/conf/locale/en_GB.UTF-8/LC_MESSAGES/django.mo", O_RDONLY) = -1 ENOENT (No such file or directory) [14:58] ttx: do you know what is keeping it in? [14:58] ... [14:58] open("/usr/share/python-support/python-django/django/conf/locale/en/LC_MESSAGES/django.mo", O_RDONLY) = -1 ENOENT (No such file or directory) [14:59] james_w: no, I'm going to have a look. [14:59] mpt: basically, if we develop it correctly, it should be a backend with one or more frontends. Untying GTK from the backend so any interface could be written on top of it. [14:59] ttx: the only rdepend I can find is libgnumail-java suggesting it [15:00] actually, I stand corrected, mattn did have a point - the locale does actually need to be installed, but if you installed language-pack-fr already then LC_ALL=fr_FR.UTF-8 should make it work [15:00] rgreening, there already is a back end, it's called Aptdaemon. [15:00] mpt: there was a packagekit spec I helped write to cover some of what would need to be done with packagekit for a backend [15:00] cool [15:00] why is libg3d in ubuntu repos but not g3dviewer and the thumbnailer? are there even any other applications that are using libg3d? [15:00] strange [15:01] mpt: awesome, then presumably, writing a frontend should be trivial... [15:01] mpt: is there a spec for UDS-L for this? If so, I'll write a KDE frontend spec and link to the other... [15:05] james_w: same here [15:06] ttx: ok, I'll demote it as we probably don't want it, and we can see if anything complains? [15:06] james_w: nothing should :) [15:06] rgreening, writing a good front end is always the hard part. [15:07] rgreening, I'm not aware of a spec for it. This is the first time I've heard of the possibility of a Kubuntu equivalent. [15:10] mpt: I'm the kubuntu ninja concerned with making the Ubuntu-->Kubuntu transistions when everyone else has forgotten ;) haha [15:12] rgreening, good for you. What do Kubuntu users think of KPackageKit, do you know? [15:16] kpackagekit is good and bad... some missing bits and not having an Applications VIew is bad (IMO), as packagekit shows all packages/debs and cannot filter to show just applications like from within app-install-data. Though I helped write the spec to make that work in packagekit.. we can probably work on the spec and implementing it... [15:17] mpt: hi, tseliot told me I could ask you to take a short look at https://bugs.launchpad.net/hundredpapercuts/+bug/386017 - I created two checkboxes for enabling/disabling corner tapping [15:17] Launchpad bug 386017 in hundredpapercuts "Brushing right-edge of trackpad causes clipboard to paste text" [Undecided,Confirmed] [15:17] jdstrand: good morning! do I need to do anything further on bug 430544? [15:17] Launchpad bug 430544 in postgresql-8.3 "New security/bug fix microreleases: 8.1.18, 8.3.8" [High,Fix committed] https://launchpad.net/bugs/430544 [15:18] mpt: http://cgit.freedesktop.org/packagekit/plain/docs/app-install-v1.draft [15:19] pitti: hi! (reading) [15:19] Where was the LL codename announcement? I can't find it in ubuntu-devel-announce archives. [15:21] pitti: nothing further required, I'll publish this. thanks for your work on it! [15:21] maxb: Yeah, that's the thing... The announcement e-mail hasn't gone out yet. Mark revealed it at Atlanta Linux Fest. [15:21] ohhhh right [15:21] Good old verbal communication :-) [15:22] nh2, hi [15:22] nh2, the first thing to learn is that any checkbox label that starts with "Enable" probably isn't direct enough. [15:23] jdstrand: thanks [15:23] nh2, for example, "Enable right clicks with the bottom right corner of the touchpad" could be shortened to "Rght-click by tapping the bottom right corner of the touchpad" [15:24] nh2, and similar for the other new checkbox. [15:26] nh2, another thing to consider is that if someone sets up all the mice they ever use with left-handed orientation, secondary click is left click, not "right-click". So you may be better referring to "secondary click" rather than "right click". [15:26] mpt: ah ok, I just saw "Enable mouse clicks with touchpad" and so also used "enable" [15:27] nh2, yes, that will be fixed in my large-scale redesign of the touchpad settings :-) [15:27] will people understand secondary click? [15:27] mpt, cjwatson: I'm not sure a regular user can imagine that [15:27] mdz: did the additions I put into bug 43706 cover what you needed? [15:27] s/imagine/understand [15:27] Launchpad bug 43706 in casper "Excessive memory usage on live CD" [Low,Fix released] https://launchpad.net/bugs/43706 [15:29] mpt, cjwatson: perhaps "clicks" and "context menu clicks" as the secondary click is often a context menu click? [15:29] mpt, rgreening: richard is no longer working on app-install [15:30] the infrastructure changes have not been accepted by Fedora [15:30] but see you [15:30] cjwatson, I haven't been able to find a screenshot of what Windows calls it -- the interface seems to be up to the device . Mac OS X calls it secondary click, though.