[00:05] stokachu: are you planning to get the fix for bug 1169740 into raring, as well as SRU? [00:05] bug 1169740 in rsyslog (Ubuntu Raring) "rsyslog hangs loading modules" [Undecided,Confirmed] https://launchpad.net/bugs/1169740 [00:11] oh. one more thing for you guys. I think this UEFI nonsense is going to be a big stumbling block [00:11] there's no way around it anymore [00:11] so, some clearer guides, online and in installer, on what to do, would be nice [00:12] we've put a great deal of effort into UEFI already; it would be best if you could file bugs about specific things you feel are missing, rather than a general comment ... [00:12] cjwatson: heh. was just typing something longer :) [00:12] cjwatson: but. specifically, the installer was aware Windows 8 was there [00:13] (also, distinguish plain UEFI from UEFI Secure Boot, as the issues are quite different) [00:13] but did not warn me I was not in EFI mode [00:13] hey, I'm not going to try to understand anything UEFI-related at 1am local [00:13] only my own paranoia made me halt before blowing away existing setup [00:13] that's why I suggested filing bugs :) [00:13] also. none of the docs explain how to get to EFI boot from Windows 8 - which was what I had to do. BIOS failed horribly in this regard [00:14] (I'll have forgotten this conversation by the morning ...) [00:14] oh well [00:14] these are useful comments and I heartily encourage you to file them as bugs so they don't get lost [00:18] Oh. Also, getting this information to someone who is in Windows 8 and just plugged in USB drive or CD. 'cause booting straight off it sure didn't work. [00:18] relative to where they are at that moment. that's similar to (2) I guess [00:18] And. Man, is it hard to get into the BIOS screen on one of these fast-booting UEFI setups these days :( [00:18] Booting to UEFI from USB is certainly meant to work, and has in the past [00:19] cjwatson: well. Depends on BIOS setup possibly [00:19] Perhaps [00:19] Lots of room for intersection of our bugs and firmware bugs [00:19] thise was a lenovo g780 [00:19] No idea about the specifics of that [00:19] when I finally got into BIOS screen there were options for boot order. I made sure USB was on top [00:19] there was also, under UEFI, windows boot loader and some USB boot loader [00:20] I put the USB one on top. Unfortunately, that still sent me straight to windows. [00:20] * cjwatson -> overdue sleep [00:20] When I went to bios, the boot sequence was right, but windows was back on top [00:20] setting boot to USB from the windows 8 options was the only way to get it to work [00:20] well. actually legacy mode worked too, but that's how I got to a point in the installer that would have completely screwed everything up [00:21] oh well. g'nite [00:37] cjwatson: i have debdiffs ready for precise, quantal and raring [00:37] cjwatson: do you want me to attach raring, quantal? i was waiting on the OP to return with his testing [00:37] and i see he updated [00:54] cjwatson: if you see this and im not here i went ahead and filled out most of the SRU, waiting on OP to send me his test case and ill submit it up [00:56] cjwatson: and to answer your original question (sorry its late) precise is my main concern as raring can be after release === security is now known as megha === udienz_ is now known as udienz [03:53] Good morning [04:33] doko_: pong === tkamppeter_ is now known as tkamppeter [06:42] good morning === smb` is now known as smb [07:41] apw: interestingly, we've only ever received 23 KernelOops reports with an OopsText field in them. [07:41] It doesn't include 12.04, which doesn't have the version of whoopsie that sends the OopsText field, but I wonder if we're failing to correctly process these crashes at an earlier stage. [08:06] apw: http://paste.ubuntu.com/5718063/ - you can look those up individually by going to https://errors.ubuntu.com/oops/$the_oops_id === mvo__ is now known as mvo [08:15] ev, indeed they mostly look reasonable, a couple seem truncated to the left ... and 23, i have had more than 23 this cycle i would think [08:15] apw: truncated to the left? [08:15] ('d4ae7486-568d-11e2-a835-2c768aafd08c', OrderedDict([(u'OopsText', u'ence at 00000004\nIP [08:16] and yeah, I have no doubt that we're missing a lot, but I'm not sure why. The daisy.ubuntu.com frontend is very liberal in the reports it'll insert into the database. [08:16] oh interesting [08:16] i don't know of any bugs or oopses which start that way [08:16] right [08:16] in fact i think they probabally all start bug or oops === doko_ is now known as doko [08:16] so I'm wondering if this is some corner case in apport / whoopsie. (why we have so few) [08:16] right [08:17] you should be able to trigger them i think, isn't there a sysrq for that [08:20] no it always forces a complete reboot. we could so with a mechanism in our kernel to allow you to trigger them for testing me thinks [08:20] apw: I think there is a magic sysrq for it, but I can't remember what it is either. [08:21] StevenK, sadly it sets panic_on_oops before it oopses, which is a hard fatal reboot jobbie [08:21] i cannot sensibly find one to trigger them quietly [08:21] That isn't playing fair [08:29] tjaalton, any reason not to merge the JITEmitter.patch in llvm-3.2? [08:32] doko: is it from debian? [08:32] tjaalton, yes [08:35] doko: hmm can't find it on 3.2-4? [08:36] tjaalton, because it's in -5? [08:36] ah [08:37] packages.d.o is lagging behind.. [08:37] tjaalton, or #1160587. note that Sylvestre mostly complains about stuff not being in Debian, but he's not caring much for the other way around :-/ [08:38] right.. [08:39] I guess it's fine [08:39] doko: are you merging it with -5? [08:39] getting the r600 updates would be nice too [08:40] although we didn't get radeonsi support included in raring, glamor-egl isn't uploaded yet and I doubt it would make it in main on such short notice :/ [08:40] then a couple of commits to x-x-v-radeon to use these [08:45] tjaalton, well, I can apply the jitemitter patch [09:08] tkamppeter: did you pull the whole touch-grab branch from whot, or just that one commit? [09:09] tkamppeter: I can still crash it easily by changing between the dash icon and indicator menus [09:17] tjaalton, I only picked that one commit. [09:19] ok [09:19] tjaalton, what sequence of finger clicks I have to do exactly? I clicked the dash icon (Ubuntu symbol at the upper left) and after that one of the indicator icons (Network Manager) and again the dash icon and nothing crashed for me (on the Lenovo Thinkpad Twist). [09:19] tkamppeter: doing that a few times crashes it here with the branch [09:19] i'll try without [09:36] tjaalton, llvm-3.2 waiting in the queue [09:36] diwic: I'm seeing quite some people complaining about pulseaudio taking 99% of their CPU since last update. I wonder if inotify doesn't go crazy if /run isn't there or something is tweaked. Heard about it? [09:37] didrocks, no, not yet [09:37] tjaalton, I cannot reproduce the crash, I tried on both the Nexus 7 and the Thinkpad Twist. [09:37] didrocks, do you have a bug or person affected that I can work with? [09:38] diwic, seems like ricotz has it [09:38] ricotz, ^ [09:38] diwic: do you speak french? ;) (a lot of people on the unstable part of the french forum are complaining, so not just one isolated case) [09:38] diwic: I can get them opening a bug report, is there anything I should add in addition to what ubuntu-bug will bring to them? [09:39] if ricotz can do live debugging, that's even better [09:39] ricotz: diwic: FYI, people report that if they kill pulseaudio in their session, then it works fine [09:39] tkamppeter: i'm building with your patch now [09:39] I wonder if it's a race before /run is set for the user or anothing… [09:39] didrocks, I guess attaching to the process and seeing where it's stuck would be the first thing [09:40] diwic: yeah, they are not *that* technical :p [09:40] didrocks, diwic, i killed pulseaudio several times and it constantly uses 100% of one cpu again [09:40] ricotz: ah, at least, it's more reliable for you, mind helping diwic? ^ [09:41] ricotz, can you attach to it with gdb? [09:41] didrocks, already downgraded :\, to be able to use my laptop [09:41] tjaalton, you do not need to build. For Intel I have packages on my PPA and for Nexus 7 there is the tarball attached to the bug. To try without patch, go back to the official packages. [09:41] diwic, i will give it a try in a moment [09:42] tkamppeter: building already [09:42] ricotz, or run sysprof on it could work too, if that easier [09:42] diwic, although i am running an older kernel here [09:44] I am not seeing the cpu issue, but why would pulseaudio be using 3GB of ram .... [09:50] diwic, http://paste.debian.net/plain/250235 [09:51] ricotz, all threads appear sleeping in that post [09:53] diwic, seems like attaching to it released the "loop" [09:53] ricotz, oh. [09:53] ricotz, maybe you can try sysprof instead? Have you used it? [09:53] tkamppeter: it's trivial to get the grab hang with it [09:54] tkamppeter: just hit the indicators with two fingers a few times [09:54] diwic, not yet [09:57] tjaalton, you mean, clicking two indicators at the same time? [10:01] stgraber, i forwarded your mail to the ubuntu phone list [10:04] diwic, http://people.ubuntu.com/~ricotz/pulseaudio/ [10:05] diwic, not sure how to interpret it [10:05] ogra_: thanks. I guess I probably should subscribe to some of those lists... [10:09] ricotz, hmm, what does the screenshot look like? [10:12] didrocks, http://people.ubuntu.com/~ricotz/pulseaudio/sysprof.png [10:13] I think this is for diwic ^ [10:13] ah sorry [10:16] ricotz, hmm, I loaded your log in my sysprof. It seems to point at e1000e_poll_eerd_eewr_done, but isn't that some kind of network related thing? [10:16] diwic, actually yes, does pulseaudio probe those for something [10:17] like discovering bluetooth adapters [10:17] tkamppeter: no, but rapidly change between two or more indicators by tapping on them with two fingers [10:17] ricotz, you haven't mounted /run/user on a network drive or something? [10:17] diwic, no [10:20] diwic, maybe you missed some prerequisite for the cherry-picked patch [10:21] ricotz, I wrote the inotify patch yesterday myself [10:21] diwic, ah i see, alright [10:22] +- valid_pid_file = TRUE; [10:22] ++ valid_pid_file = true; [10:23] ricotz, yeah, I changed pa_bool_t to bool too [10:26] ricotz, argh, I don't get it. Why would adding an inotify watch cause the e1000 driver to eat cpu? [10:28] tjaalton, https://blueprints.launchpad.net/ubuntu/+spec/client-1305-convertibles-and-touch-desktop [10:31] mlankhorst, bryc: ^^ === ara_ is now known as ara [10:31] ricotz, if you do "sudo fuser -v /run/user/ricotz/pulse/pid" a few times, does anything show up? [10:31] bryce, ^^ [10:31] ricotz, (assuming your logged in user is "ricotz") [10:34] diwic, nothing shows up [10:35] diwic, /run/user/*/pulse/pid contains the correct pid [10:35] tkamppeter: we're aware of the touch problem, if it was easy to fix, or even not that hard to fix by the upstream maintainer it would already have been fixed [10:37] ricotz, hah! I reproduced it here: If I edit the pid file manually (with gedit), PulseAudio starts taking up 100% CPU [10:39] ricotz, probably there is some software on your machine that accesses it in some way [10:39] Anyway I have a fix for bug 1170074, it seems nobody tests on x86 these days but it would be unsurprising if x86 was completely broken for nouveau/radeon because of it. :s [10:39] bug 1170074 in mesa (Ubuntu) "mesa 9.1 regressed Tibia on nouveau" [High,Fix committed] https://launchpad.net/bugs/1170074 [10:39] ricotz, and that triggers the loop [10:39] diwic, hmm, i see, running gdm/gnome-shell here [10:41] ricotz, anyway, if I can reproduce it here, I can hopefully come up with a fix too with some analysis [10:41] ricotz, thanks so far! [10:42] diwic, yeah, touching the file triggers it too while running in gdb [10:42] diwic, ok, yq [10:42] yw [11:03] jodh: seen the LWN article on upstart? [11:03] (just FYI, in case you're interested) [11:03] rbasak: not yet :) [11:32] is there a way to select apt-proxy via ubiquity somehow? [11:33] zyga: i'm considering to seed squid-deb-proxy-client package to desktop CDs.... === hrww is now known as hrw [11:53] didrocks, ricotz, ok, I believe I have fixed it now. Since this is last minute, what precautions do you suggest I take before pressing the "upload" button? [11:54] diwic, i guess you can put it in a ppa and let someone test it [11:54] ricotz, are you volunteering? :-) [11:55] ricotz, I don't know exactly when Final Freeze is, but some time today I believe [11:55] diwic: is there any risk of things going worse? [11:55] didrocks, ^ [11:55] diwic, just put the source package somewhere [11:55] diwic: I can get some people testing from a ppa if you want [12:00] didrocks, ricotz uploaded to ppa:diwic/pulseaudio-testing [12:02] diwic, alright [12:03] build starts in 2 hours [12:04] pitti: can we have a small bump on https://launchpad.net/~diwic/+archive/pulseaudio-testing/+build/4501878? [12:05] diwic: forum updated, they will install it once it's available, will keep you posted [12:05] didrocks, thanks, I'll go for lunch in the mean time [12:05] diwic: enjoy, thanks! :) [12:08] didrocks: done, it's now next in line [12:09] thanks pitti :) [12:15] didrocks, as for risks for things going worse, I guess the risks are 1) PA crashing or 2) bringing back the original bug (stale PA processes after logout/login) [12:16] diwic: ok === mvo_ is now known as mvo [12:35] diwic, looks good, can't reproduce it so far [12:43] diwic: one confirmation on the forum as well :) === _salem is now known as salem_ [12:54] not sure if this is the place, i'm currently testing raring ringtail and have had some problems getting it to boot. [12:55] while it is kubuntu (i think its actually pre to any distro stuff) [12:55] Kalidarn: #ubuntu+1 is probably a better place if you're looking for support/ [12:55] basically comes up with grub menu, and then when you select "Start Kubuntu" it says you need to load the kernel first. [12:55] yeah i think it might be a bug actually. [12:56] unfortunately the error doesn't really tell me that much, the media is fine, already checked that. [12:57] the error i get is: [12:57] error: failure reading sector 0x6d500 from `cd0'. [12:57] error: you need to load the kernel first. [12:57] i might actually try with standard ubuntu media not kubuntu to test that as well [12:57] i think it probably affects all variants [13:00] didrocks, ricotz, ok, I'm uploading it now then [13:00] diwic: \o/ thanks a lot :) [13:01] Pici: would it be recommended to get the latest beta or current daily? [13:01] diwic: 3 people confirmed on the forum now :) [13:02] you should certainly try a current daily, although I don't know how much difference it'll make [13:02] "you need to load the kernel first" is a consequent error and not the real cause - you should generally look at the first error not the last [13:02] didrocks, thanks for organising the testing! [13:03] yw ;) [13:03] didrocks, uploaded, fingers crossed [13:03] heh ;) [13:03] yeah cjwatson i wonder why its failing to read that particular sector though :) the drive works fine and the media burnt fine hmm. [13:03] evidently the boot loader is having genuine trouble with one or the other [13:04] it tried asking the BIOS to read that sector three times, and it failed every time [13:05] it's a fairly straight INT 13h Function 42h, and I doubt that that was the first sector it tried to read, so my money would be on a drive and/or media failure that your tests didn't pick up, with a backup option of some problem in your BIOS [13:05] the error here is close enough to the firmware call that I don't think it's likely that this is our bug [13:07] cjwatson: yeah that's rather odd because ive burnt it twice (two dvds) and the drive does work as other distros have no issue [13:07] so ill try booting off a usb stick [13:08] Kalidarn: well, it could be that other distros just happen to miss the problematic bit, or maybe Linux tries harder to read it than your BIOS does and the other distros have no need to read that sector with raw firmware calls [13:09] Kalidarn: sadly, experiment does not actually rule out faulty drive/media [13:09] this includes previous versions of kubuntu such as quantal or ubuntu so yeah [13:09] Kalidarn: sure, but it could depend on exact position of data on the disk [13:09] ill try a different type of media entirely and see if it occurs, the debian wheezy bug (pre RC1) happened the same to me on both optical and usb drive [13:10] Kalidarn: drive cleaning kits are IME worth a shot as well, but yes, you probably stand a better chance with USB [13:10] yeah, i doubt the drive has anything wrong with it. but i guess ill know soon enough [13:10] it's just rather odd i only seem to be having that issue with raring ringtail [13:12] the boot loader code in question hasn't changed for a year or more (I did go and read it before replying to you). Random chance can produce odd things sometimes [13:12] i guess :) time for more experimentation! :D [13:13] the boot loader code *is* Ubuntu's responsibility, but I think in this case whatever the bug actually is is out of our hands [13:13] i figured at that point it wouldn't matter what variant of buntu was being used. [13:14] lool, ready? [13:15] Kalidarn: the boot loader code is identical, but the different flavours of Ubuntu might happen to have the kernel in a different position on the disk [13:15] which in this case could make a difference [13:16] dholbach: eh was just joining #ubuntu-on-air and just moved the invite 5 mn earlier to make sure people join on time [13:17] thanks for your time cjwatson. [13:17] cool [13:20] cjwatson: hey did you see my messages from last night? (not sure if you logged off to sleep by then) [13:21] Oh, I did but hadn't quite got round to them yet - I'll look shortly, thanks [13:21] cjwatson: ok no problem just making sure they made it to you [13:21] stokachu: We're before final freeze (just), so I'd like to get the raring fix in if possible [13:21] Since it ought to be there before precise [13:22] cjwatson: ah ok, ive got everything attaached to the bug and sru template done [13:22] cjwatson: so not sure if you want to just pull that raring one in before freeze [13:23] Right, I see. I will stare at it a bit [13:41] mlankhorst: http://paste.ubuntu.com/5718775/ is a rather bigger diff than the changelog suggests - is that intentional? [13:41] 14:37 tjaalton, slangasek, Laney: the libgl1-mesa-dri update makes unity segfault on start in vms [13:41] mlankhorst: ^- and is it likely to fix that? [13:44] are they i386 vms? [13:44] mlankhorst, yes [13:44] the one I tried was === security is now known as megha [13:44] cjwatson: it was a result of a merge back to ubuntu branch from ubuntu+1, the patches that were dropped were already no longer applied. [13:44] hm I think it might [13:45] I have it on my ppa anyway [13:45] mlankhorst, do you have a deb handy ? [13:45] https://launchpad.net/~mlankhorst/+archive/ppa?field.series_filter=raring [13:46] Would it be worth sorting the rebuild failure reports in popcon order? I'm still struggling to prioritise what to look at. [13:46] popcon doesn't get updated any more [13:46] :-( [13:46] How about Debian popcon? [13:47] cjwatson, mlankhorst: libgl1-mesa-dri_9.1.1-0ubuntu3~ppa1_i386.deb from that ppa fixes it [13:47] good [13:47] and what I expected [13:48] mlankhorst, still a bit annoying that this slept through, we should have at least one people running unity under a vm on i386 and amd64 before upload [13:48] mlankhorst, thanks for the fix ;-) [13:49] seb128: it was a case of conflicting symbols specifically for i386 [13:49] mlankhorst, well, it means nobody tested on i386... [13:49] and only happened specifically on nouveau < nvc0, or llvmpipe i386 === wedgwood_away is now known as wedgwood [14:01] wonderding do we have latest kde ppa for 12.04? [14:02] sorry, wrong channel [14:04] freeflying: ppa:kubuntu-ppa/backports [14:04] mitya57: thanks, typed in errors here, meant to ask in kubuntu-devel :) [14:20] achiang: ping? === Sweetsha1k is now known as Sweetshark [14:21] Sweetsha1k: hey, in a hangout-on-air now, but what's up? [14:21] mlankhorst: so what's the plan for getting the fixed mesa uploaded? [14:22] erm it's already been uploaded before everyone was panicking about it ? [14:22] :P [14:22] so I guess poking you until you accept it [14:23] oh was already accepted 7 minutes ago [14:23] no plans, then.. [14:23] the plan is to kick back with a nice jug of sangria [14:24] mmm I think I'll go biking [14:24] while the weather is nice [14:24] so dutch [14:24] and the storm hasn't calmed down yet [14:48] running ReText under qt5 makes gnome-session crash... interesting [14:49] s/gnome-session/Xorg/g, which is even more interesting [15:19] * mitya57 installs Xorg dbg symbols, fastens seat bells and tries again [15:22] slangasek: could you have a look at bug 1169621? [15:22] bug 1169621 in plymouth (Ubuntu) "encrypted LVM desktop does not boot with cirrus driver (no password prompt)" [High,New] https://launchpad.net/bugs/1169621 [15:23] bdmurray: i can test it again. there have been updates to kernel and/or qemu as e.g. background is now colorful. [15:26] bdmurray: that's been a problem for a couple of cycles, IIRC there was a change in the kernel that triggered this... it's not going to get fixed for r [15:27] slangasek: got it, thanks [15:36] FWIW I've found the issue: it's bug 1005677, for which we have a patch only in Qt 4, not in Qt 5. [15:36] bug 1005677 in overlay-scrollbar (Ubuntu Quantal) "Re-emergence of "Gtk-CRITICAL **: IA__gtk_widget_style_get: assertion `GTK_IS_WIDGET (widget)'" Makes vlc and other Qt apps crashing crashing" [High,Fix released] https://launchpad.net/bugs/1005677 [15:55] cjwatson: ping? [15:55] GunnarHj: pong [15:56] cjwatson: Hi Colin. I just posted a comment on bug 1160441. I do disagree on that change. [15:56] bug 1160441 in ubiquity (Ubuntu Raring) "Calendar is still in English despite French is selected as the Language during the installation" [Medium,Fix committed] https://launchpad.net/bugs/1160441 [15:57] Sigh, "not discussed with you" != "without discussion" [15:57] cjwatson: Ok, true, but... [15:58] I can't wait indefinitely for feedback about every change [15:58] You haven't actually refuted my point about LC_TIME being a conflation of language-dependent and language-independent data [16:00] glib and indicator-datetime notwithstanding, anything that does even just something as simple as ctime() will have day/month abbreviations from the wrong language [16:00] "wrong", anyway [16:00] cjwatson: It's true, no doubt. But given that we won't change the fundamentals easily, such as splitting LC_TIME into two locale categories, we need to do our best to meet user expectations. [16:00] I think day/month from "wrong" language is more likely to break those expectations than other parts of the format [16:02] cjwatson: Possibly. But the conflict typically gets visible in the calendar, and I have an idea - admittedly hackish - how to deal with that. [16:02] I really profoundly disagree with the notion of hacking around locale categories in individual applications [16:03] All it will do is introduce inconsistency among applications [16:03] psivaa: ^- since this was your bug [16:03] bdmurray: ^- and you were investigating it [16:04] If I revert this for raring, I'm not sure how anything will change in future releases; we will still have the fundamental issue of a conflated locale category [16:06] cjwatson: Well, it's better IMO than doing nothing. At the same time I think that doing nothing is better than preventing the users from controlling the date and time format, which is what LC_TIME primarily is about. [16:06] I'm not preventing users from doing anything! [16:07] They can change the categories themselves if our guess (and it can be no better than a guess) was wrong [16:07] cjwatson: Well, currently they will do so automatically if they use language-selector to set the region. So it's inconsistent. [16:08] If we start changing individual applications then we're just going to have a succession of bugs like the one psivaa reported; the system will get more complex as we add more and more and more manual workarounds [16:08] This is how things get to the point where nobody understands them [16:08] cjwatson: I believe the change makes sense [16:08] I agree that we have an inconsistency here [16:08] That's the only reason I'm considering reverting [16:08] If I reverted for raring, I haven't seen any reason yet why I wouldn't put the change back in the first upload for S [16:09] And I'm not at all convinced that I would consider that indicator-datetime change acceptable for raring [16:10] cjwatson: At least it would give us a possibility to consider the issue more carefully. [16:10] Unfortunately we have already changed something from quantal, namely the mixed-locale improvements in ubiquity, and the handling of LC_TIME was one of them [16:11] So we don't get to say "let's just leave it how it was in quantal and consider more carefully later" [16:12] cjwatson: But language-selector has considered LC_TIME a region thing for many, many cycles. [16:12] And we probably only didn't notice that was a problem because relatively few people set their language through language-selector rather than setting it once in the installer and leaving it there. [16:12] So it didn't come up in this kind of test. [16:14] cjwatson: Those who distinguish between language and region have typically used language-selector, I think, considering that the installer only lately has made a similar distinction. [16:14] GunnarHj: i live in the uk, but on many machines want Russian UI, and that means my calendar should say Четверг and not Thursday. Just because my current timezone is here, doesn't magically make me understand that language. [16:14] Perhaps. Some of them have probably set the locale categories manually ... [16:14] cjwatson: That too. [16:14] GunnarHj: Or are you proposing that we print time in German, when the timezone is set to Berlin? even if the rest of the UI is French?! [16:15] xnox: Gunnar is proposing that we do the language parts of this at the application level, I believe [16:16] https://code.launchpad.net/~gunnarhj/indicator-datetime/days-months/+merge/159214 [16:16] Which I think is really dangerously wrong [16:17] For reasons given above [16:17] cjwatson: I mean the ultimate incornation of this bug is how currencies are displayed by default in Libreoffice calc. Cause when a Russian UI in the UK one would want £ currency & Четверг as name of the day. [16:17] No, don't drag currencies into this [16:17] Those are LC_MONETARY which is different [16:18] I don't believe anyone disagrees that LC_MONETARY should be location-dependent [16:18] And it is, with current installer and language-selector code [16:18] ok, good. [16:20] cjwatson, xnox: Personally I think I won the debate at https://bugzilla.gnome.org/687945, but Matthias had access to the button... [16:20] Gnome bug 687945 in i18n "Display names of days and months using the current language" [Normal,Resolved: wontfix] [16:20] GunnarHj: Exactly the same argument applies to glib as to applications - it's the wrong place, fixing this belongs at the standards / C library level [16:21] Which is certainly harder, but ... [16:21] cjwatson: So the question is what's the best thing to do until the standards are changed. [16:22] GunnarHj: the questions is did you raise it for standards to consider fixing yet? [16:22] cjwatson: works off USB ;) [16:22] Kalidarn: excellent [16:22] i should try another cd drive actually. [16:22] cos i don't believe the media is bad. [16:23] i don't like problems that go away by themselves. [16:23] (especially as two seperate discs had exactly the same issue) [16:23] i wouldn't mind betting though cjwatson it's probably my dodgy BIOS [16:24] cjwatson: I have discussed the issue quite a lot the past few months. Winows and Apple are said to fix the distinction in accordance with the users' expectation, i.e. despite of the standards. [16:24] i've had nothing but trouble with this GA-X58A-UD3R [16:25] xnox: No, I haven't. Isn't that a 'mission impossible'? ;-) [16:26] GunnarHj: i haven't pushed anything into C std library, but e.g. ubuntu community did push a few things into other standards and languages. [16:26] GunnarHj: I really don't see how Windows or Apple are relevant to a discussion of POSIX standards :-) [16:27] Sure, they're big OSes, but they're not exactly well-known for POSIX compliance in general [16:27] isn't OSX more posix compliant than linux? [16:28] GunnarHj: If we don't try then *certainly* nothing will happen [16:28] GunnarHj: it's a valid problem, and needs a solution that works =) standards committees are suppose to be good at resolving such things, or at least defining/clarifying the expected when mixed LC_* locales are set. [16:28] s/expected/expected behaviour/ [16:28] cjwatson: Their success is probably partly because they set user expectation before bad standards. [16:29] GunnarHj: Sigh, I guess this discussion is useless if we're going there [16:29] False dichotomies 'r' us [16:30] cjwatson: For now, can't you please take a step back and revert? [16:30] GunnarHj: I'll revert this change in the installer for raring, but only because it has additional interactions I hadn't thought of which are now too late for 13.04. I intend to reinstate it as soon as raring is out. [16:30] Unless there is a better option, and I don't count application-level changes ... [16:31] cjwatson: Good, then I can sleep well tonight, at least. ;-) [16:31] cjwatson: sorry was still trying to understand the conflict and the inconsistency. i like the correct language to be displayed but if that's going to change the timezone, then i dont have a preferance :) [16:31] psivaa: It's not about changing the timezone [16:32] barry, doko: ubuntu python now has native access to the multiarch tuple right? [16:32] where was i again? [16:32] sys._multiarch is only py2 :/ [16:32] jtaylor, depends on what you want to use it for [16:32] to find tk/tcl [16:33] if you can, use sysconfig.get_config_var('MULTIARCH') [16:33] ok seems to work, thx [16:35] cjwatson: ok, I think its safe for me to leave the decision to you guys then :) [16:35] or is there a compat package one can use for tk/tcl build dependencies? [16:36] GunnarHj: Reverted. :-( Now I really do have to go. [16:37] Oh blast, I have to wait until localechooser is approved before reuploading ubiquity. [16:37] So that will probably miss final freeze now. [16:37] Hrm. I wish ubuntu software centre offered a way for devs to get in contact w/ users who give bad reviews [16:37] cjwatson: Thanks. :) [16:37] cjwatson: I can review it now if you want [16:37] I mean. I don't *care* that much, I just feel sorry for poor "John" who was having trouble starting the game which was almost certainly due to bad gfx driver [16:37] and could probably have been fixed w/ application of jockey-gtk [16:38] and might be having bad exp w/ other games too [16:38] nemo: wrong channel =) [16:38] cjwatson: accepted (confirmed that diff from ubuntu2 to ubuntu4 is only removal of .gitignore) [16:38] xnox: oh? [16:39] nemo: i'm not sure where you can discuss apps published in the software center. Wait is that about a review on a package from Ubuntu OS or about an app you published in Software Center as a developer? [16:39] Hedgewars. 2nd FOSS game in Games category :) [16:40] xnox: but. it wasn't really about the game itself [16:40] was more about ubuntu software centre - I wish it offered a way for me to somehow help john is all [16:40] every time I go to the game, his review is there, and I feel bad [16:40] nemo: hmmm... [16:41] I know what is happening. hwengine is crashing. which is usually due to opengl probs, thus need for another driver. well, it sometimes is 'cause people screwed w/ sound system or pulseaudio is crashing [16:41] but john doesn't seem like the type to screw w/ sound system, and pulseaudio is better behaved these days [16:42] if john had linked to a launchpad issue, I would have commented there :) [16:42] but given cjwatson's complaints yesterday, I guess I shouldn't talk about filing issues :-p [16:46] cjwatson: that version change you made in rsyslog was that the only thing I should be aware of? i couldnt find versioning schemes for development in the wiki anywhere [16:47]