[00:00] kklimonda, can I fix that in my Python code? [00:00] rickspencer3: yes [00:01] so if test() returns True, all is good? [00:01] in your sample? [00:01] sweet [00:02] rickspencer3: well, either True or False (see http://pygtk.org/docs/pygtk/class-gtkspinbutton.html#signal-gtkspinbutton--input for what should be returned in your case) [00:02] let me try it [00:06] hmm [00:06] still crashing for me [00:06] hmm.. [00:06] before my signal handler is even called [00:07] yeah, even without the handler connected it crashes [00:08] rickspencer3: that's weird - it didn't crash when callback wasn't connected before [00:08] rickspencer3: and adding return True to __changed in grid_filter.py fixed it for me. [00:08] hmmm [00:08] weird, not for me, I must be missing something really simple [00:10] rickspencer3: http://pastebin.com/1WyryErp - that's for grid_filter.py from the tarball you have uploaded to the bugreport [00:11] argh, not this - http://pastebin.com/bedubE7c [00:12] I was supposed to paste a patch, not whole script :) [00:13] kklimonda, so, it's not working for me, but I'm suspecting I am doing something really silly [00:15] rickspencer3: hmm.. if you tested the patch and not script I've pasted before (which was unpatched) then I'm not sure.. [00:15] rickspencer3: does spin.py work for you? [00:16] kklimonda, it was me being stupid [00:17] well, it happens to all of us from time to time. [00:18] it happens to me every day, so I'm used to it :/ [00:18] (hadn't set the PYTHONPATH properly when running the test script) [00:21] kklimonda, sweet, so not the widget is working properly! [00:21] thanks a million [00:23] no problem, glad to be of help [00:29] kklimonda, so ... [00:29] more to the point, you're not supposed to use the "input" signal handler in Python at all [00:29] :( [00:29] you're supposed to use "value-changed" [00:29] if ever there was a face-palm moment, this is it [00:30] rickspencer3: :) [00:30] rickspencer3: good to know [00:30] mortifie [01:01] Morning all [01:03] Argh! I just spent 30 seconds wondering why my mouse pointer wouldn't go to this screen… which is driven by a different computer. Bah! === bjf is now known as bjf[afk] === bjf is now known as bjf[afk] [01:35] hey RAOF [01:35] rickspencer3: Good evening! [01:35] RAOF, back in Sydney? [01:35] Hobart, yeah. [01:35] Sid-knee [01:35] Oh, right, Hobart [01:35] Not Syd-en-ee :) [01:35] how was the conference? [01:36] Great! [01:36] Toulouse is a pretty nice town and there were all sorts of interesting conversations. [01:37] nice [01:37] We cornered krh at one point and made him explain wayland in detail :) [01:37] heh [01:37] and? [01:37] It's pretty interesting architecturally. [01:38] And has its own special IPC mechanism, and object-based notification system. [01:38] And is not an X server in any way :) [01:39] heh [01:39] RAOF, how is xorg-xserver looking for Maverick? [01:39] Although he gave a neat demonstration of a couple of X servers + some flowers running under wayland with funky animation. [01:40] xorg-server is looking pretty good. [01:41] There are some edge-cases in mesa on strange hardware I need to look at, and to get kde to log out without crashing the server. [01:41] That's on intel. [01:41] right [01:42] well, Kubuntu is in much better shape with the new mesa, right? [01:42] I've got the kde thing half done; now it just needs to log _in_ succesfully the second time ;) [01:42] heh [01:42] RAOF: Although Wayland is basically X the way modern applications really use X [01:43] RAOF: It gives you a pixmap to draw to and tell it when you're done [01:43] Kubuntu is *much* better with the new mesa. And the new mesa helped Chase's multi-touch in unity demonstration, too, because it made unity actually work on his ati laptop :) [01:43] And that's pretty much it on the client side of drawing, the toolkit or app has to handle subwindows and such by itself [01:43] Which they all do anyway [01:43] Amaranth: Right. It's not terribly difficult to port things to it. [01:44] Although it still needs libxkb and some major work in the input area in general [01:44] That might need to wait until we actually figure out how to do input properly :) [01:44] And apparently it's still possible to write an application that hooks in to the wayland compositor to provide effects [01:45] well, so long as you can draw flowers, I guess that's all that matters [01:45] But libxkbcommon is getting split out and depended on by X, so Wayland will be able to have xkb working more easily. [01:45] It just gives you flicker free screen updates and transparency, compositing 101 stuff [01:46] Yeah. Actually, the goal appears to be to make your compositor link to libwayland and be a display server itself. [01:47] So unity-wayland would be the display server and compositor and shell. [01:47] But the major problem with wayland is it lacks all the standard we have for how windows should work, EWMH and such [01:47] By design! [01:47] Sure but you need to provide some of that, somewhere [01:48] In the desktop shell, or so says krh. [01:48] So each compositor/display server should implement their own version of docks and always on top windows and such? [01:48] Yes. [01:48] Oh boy, that's going to be a mess for a few years [01:48] Or, alternatively, should provide a separate interface to make those writable. [01:48] Until someone reinvents half the X11 standards [01:49] Over dbus! [01:49] ;:) [01:49] Yeah, I imagine it'd all be over dbus [01:49] Setting properties on the root window is such a hack [01:50] I've been tempted to get wayland running on my computer, now that you don't have to build the entire stack to do it [01:50] Yeah. And something you can't do in Wayland, because clients can't communicate. [01:50] (Over wayland, at least) [01:51] You can expect a wayland PPA pretty soon. [01:51] We'll probably end up with a new org.freedesktop.WindowManager interface every shell/display server implements [01:51] Yup. [01:51] Or even better, a library everyone uses [01:51] RAOF: if wayland a real [1] project that is aimed at replacing X at some point [1] as opposed to a tech demo of sort :) [01:51] Oooh, I don't know about that! [01:52] kklimonda: krh was talking about Meego(?) switching to wayland in the near future; it's not actually a tech demo. [01:53] RAOF: sweet [01:53] Although the nice thing about the xserver is if you don't have a driver you can still use it [01:53] RAOF: so when do we follow? :) [01:53] Yeah, apparently Nokia is looking in to using it for Meego [01:53] kklimonda: meego as in the phone UI for meego :) [01:53] Sarvatt: I know, j/k ;) [01:53] kklimonda: Right now! Just as long as you don't want anything to run! :) [01:54] But if you had a seamless way of starting a rootless X server for legacy apps... [01:54] But, more seriously, we might want to use wayland in the next couple of cycles as an intermediate compositor for switching between X servers. [01:54] RAOF: meh, as long as it runs terminal I'm all set ;) [01:54] RAOF: hmm, sounds interesting - what's the usecase? [01:54] The nice thing is you could implement that org.freedesktop.WindowManager interface for X11 too that would just set the appropriate properties and such so apps wouldn't have to care [01:55] RAOF: That sounds like the exact idea I was pushing at UDS Seville using Xgl :) [01:55] kklimonda: Keith gets his way and X is entirely out of the trusted path so each user runs one (or more) X server(s) and you want to be able to log in smoothly. [01:56] Amaranth: :) [01:56] Yeah, if wayland is running at root and managing input you could run xservers on top of it as the user running the session and expose much less code to root access [01:57] And have a spinning cube to switch user sessions or something :) [01:57] Amaranth: That's what krh was suggesting. Keith was going further; *no* display server manages input, and you push input arbitration into the kernel. [01:57] now that's something users would actually care about :) [01:57] In what seemed like a very reasonable (and small) change to the input code. [01:58] RAOF: ha [01:58] That'd be a nice way to work around not having a revoke() syscall [01:58] Right. [01:59] The idea being, you don't need revoke if the input devices don't broadcast but instead go to only one fd (as serial devices do now?) + some way for consolekit to tell the kernel which fd should get it. [01:59] It seemed very reasonable in a room full of 40-odd X hackers :) [02:00] Woot! A new fglrx which actually works on Maverick! [02:01] isn't that sort of an important thing to have before release? :) [02:01] Yes. And we've now got it. [02:02] we do?! [02:02] * Sarvatt jumps for joy [02:02] According to my bug mail, yes. Looks like Alberto just uploaded it. [02:03] oh ATI you never cease to confuse the heck out of me [02:03] beta driver that works with xserver 1.9 doesn't have newer kernel support added in the public releases for the past 4 months :) [02:05] Launchpad wishlist: The ability to add a regex to a bug, so when anyone enters a comment matching that you can pop up some text saying “We've repeatedly said that this applies to the E6410 and *not* to the E6510. Do you *really* want to add a comment about how this fix doesn't work for the E6510?” [02:06] It will be nice once all ATI cards have open source support out of the box... If that is indeed the eventual aim... [02:06] That's getting pretty close. [02:09] I *think* we're even be supporting Radeon 5xxx series 3D out of the box on Maverick, although I don't have any hardware to determine how useful this is :) [02:11] yup, no 2D acceleration though funny enough [02:11] don't worry, 6xxx series will be out really soon and drivers will lag 6 months again :) [02:12] * ajmitch just wants fast, stable & complete 3D support :) [02:14] RAOF: our friend eDP? [02:14] Hey, once all the gallium dreams happen having 3D support will get you 2D support for free [02:14] Neat, i just got root on my laptop. Without putting in my password [02:15] the xorg state tracker seems to be on life support, I think only vmware cares about it [02:15] Sarvatt: Indeed. We talked of eDP in hushed tones at XDS, so as to not traumatise Jesse any further :) [02:15] hah! [02:15] Sarvatt: That's why I said dreams :) [02:16] I suppose I'll get it the same time I get native Direct3D support [02:16] Oh, wait... [02:17] yeah speaking of that, adding wine-dev to the mesa build-deps sure is fun! it's bad enough mesa depends on x which depends on mesa in xorg-edgers for vmwgfx [05:20] crimsun: Need your help again with Marvell Dove audio in Maverick. Seems the new board changed codecs. [05:59] GrueMaster: What has changed exactly? Mixer elemt names? === almaisan-away is now known as al-maisan [06:41] Good morning [06:50] Heya pitti [07:01] TheMuso: Hey. No, the entire codec chip. [07:01] It used to use an AD1980, now it uses an ALC655. [07:07] GrueMaster: oh ok [07:07] Hey pitti, how's it going? [07:07] hey bratsche; pretty well, thanks! [07:09] TheMuso: I have found in my research that there are several x86 motherboards that use the same codec. I am trying to decipher the pci/ac97 code for similarities, but coming up short. Alsa speaker-test works, but nothing through pulseaudio. [07:13] TheMuso: If you get a chance, scan http://paste.ubuntu.com/499485. The ASoC machine driver is exporting AC97 HiFi, AC97 LFE, and AC97 Surround. Not sure what pulseaudio needs. [07:16] If you have any insights, leave me a note, thanks. I'm off to bed for now. [08:38] pitti: hey, good morning. do you think its ok to get http://paste.ubuntu.com/499517/ in? its both bugfix and feature (in order to fix the bug) - the problem is that brasero calls the packagekit session interface to find what provides the cdrdao binary and this is a nice and elegant way to fix the problem (and any other app that searches for binaries) [08:39] its currently broken (throws exception, so its going to be hard for the change to make it worse ;) [08:43] good morning [08:44] good morning mvo, hey didrocks [08:44] Guten Morgen pitti :) [08:45] mvo: oh, haven't seen try:/except:/else yet; so else is run when there's no exception? [08:46] mvo: it looks like an elegant solution indeed [08:46] fine for me [08:47] * didrocks like also try:/except:/finally: ;) [08:47] pitti: thanks! I think its a win too, I tested it with brasero and its really nice, you insert a audio cd and it will prompt to install cdrdao and continue just fine afterwards [08:53] mvo: I just thought that having wodim and growisofs would be enough [08:53] I don't remember that I installed cdrdao to burn an audio CD [08:53] this sounds like something which ought to "just work" in a default install? [08:53] mvo: so brasero doesn't use wodim any more? [08:57] pitti: not sure, I haven't looked into brasero myself. but I agree, it should just work [08:57] pitti: oddly with the current brasero it crashes :/ I worked on that branch a couple of days ago so I think its a regression [08:58] didrocks: do you know about this? what brasero is using for audio cd burning? [08:58] mvo: hum, I haven't tracked brasero recently. Let me have a look [08:59] in 2.31.3: Fix wrong report of speed with both cdrecord and wodim [09:00] so, sounds like it's still works with wodim, let me look the changelog from that [09:01] burn-wodim.c as a plugin [09:03] odd [09:06] I don't see it in the plugin list, weird… will try to have a look when having some time [09:06] alternatively we could drop wodim and just install cdrdao? [09:07] well, I guess wodim is still needed for data CDs [09:08] eh, so I have a fresh install here [09:08] but no wodim [09:08] I guess that is the problem then :) ? [09:08] no installed wodim [09:10] I have a look [09:11] wodim seems to be prefered over cdrdao when I read the plugin order correctly [09:11] shouldn't brasero depend on either of those? [09:11] yeah [09:11] for some reason it got dropped [09:11] I check the bzr history [09:11] in wodim it did [09:12] Depends: [...] wodim, genisoimage, dvd+rw-tools, [09:12] all of those are gone [09:12] can we please put them back? [09:12] yeah, in lucid it was all there [09:12] sure, I can do that now [09:12] I just want to see who/why so that I can send my wrath ;) [09:13] *phear* [09:13] * pitti hugs mvo, cheers [09:13] * mvo makes his best grim face and hugs pitti back [09:13] your best grim face still isn't very scary, sorry :) [09:14] lol [09:14] but I'm sure whoever committed it won't ever have a successful dist-upgrade again [09:14] I need to practise more [09:14] * pitti thinks mvo's revenges are a little more subtle than mere grim faces [09:15] if uid=="name": raise ResolverGeneratedBreaks("The resolver generated breaks, %s" % random.choice(apt.Cache()) [09:16] there is a new brasero-cdrkit [09:16] maybe its enough to seed that [09:16] aah [09:16] it seems to have all the dependencies [09:16] but that doesn't have dvd+rwtools? [09:17] mvo: I'd actually prefer this to be a recommends: of brasero [09:17] it sounds more correct to me [09:17] the dvd+rwtools? or wodim-cdrkit (or both)? [09:17] They are only needed for the [09:17] following operations in Brasero: [09:17] * Audio CD burning with CD-Text information [09:17] * Video DVD creation [09:17] hmm [09:18] mvo: I meant that brasero-cdrkit doesn't depend on dvd+rwtools [09:18] but lucid's brasero did [09:18] odd that this was unoticed for so long, it seems like its missing since Jul (the first merge) [09:18] well, what's a CD? [09:18] USB sticks FTW :) [09:18] haha, true [09:18] shows how the world has changed [09:18] mvo: brasero-cdrkit promoted to main [09:19] pitti: nice, thanks [09:19] * pitti leaves this in mvo's capable hands and goes back to fixing OEM stuff [09:19] I add dvd+rwtools as a recommend sand upload [09:19] thanks for your help/time pitti [09:19] if dvd+rwtools is still being used, that sounds good [09:19] mvo: and you'll add brasero recommends: -cdrkit? [09:20] yeah [09:20] either that or seeding, I don't have a preference [09:20] recommends is fine [09:20] I think recommends: is better, for derivatives or people without the metapackage [09:20] or chroots, and whatnot [09:20] ok [09:20] makes sense [09:20] * mvo prepares the upload [09:20] and we need a brasero upload anyway [09:21] oh, what for? [09:21] mvo: I thought you wanted to add the dvd+rwtools dependency? [09:22] I just checked, it gets in via the libbrasero-media1 dependency [09:22] but stil, the derivates argument makes sense [09:22] ah [09:52] hey glatzor! thanks for your sessioninstaller merge \o/ [10:02] thanks for your patchm mvo! [10:20] pitti: I'm interested in your opinion on bug #645561 [10:20] Launchpad bug 645561 in gnome-keyring (Ubuntu) "gnome-keyring prompts lack way to set default timeout (affects: 2) (heat: 14)" [Undecided,Triaged] https://launchpad.net/bugs/645561 [10:20] maybe reverting to seahorse-plugins for this release for GPG key is the solution [10:20] (as mdeslaur suggested) [10:21] hi didrocks [10:21] hey chrisccoulson, how are you? [10:21] did you have a chance to look at the gdk-pixbuf change yet? [10:21] i'm good btw thanks :) [10:21] how are you? [10:21] chrisccoulson: not yet, just jumping on it in a few :) [10:22] tired ;) [10:23] yeah, i feel a bit tired too ;) [10:30] urgh, the new hamster-applet is really broken [10:37] ok, it's pretty much not usable [10:37] what? ;) [10:37] the new hamster-applet [10:38] ah… (sorry, as just reconnected, no context) :) [10:38] chrisccoulson: so, what should I do? at least I have a graphical GNOME interface, which means gdx-pixbuf should work :) [10:38] when i fill in the "Description" field for a particular task (or even leave it empty), it shows the wrong description in todays list of tasks, and the description seems to change depending on where i put my mouse [10:39] so i can't trust that any of the information it's displaying is actually correct ;) [10:39] chrisccoulson: ahah, some kind of $random in it, sweet! [10:39] didrocks, oh, that's good gdk-pixbuf works :-) [10:39] could you run gdk-pixbuf-query-loaders through strace, and put the output somewhere for me to look at? :) [10:41] chrisccoulson: here we go: http://paste.ubuntu.com/499564/ [10:41] didrocks: yes, sounds good to me [10:41] didrocks: and filing a bug upstream about making the timeout configurable? [10:41] didrocks - oh, this commit looks suspicious - http://git.gnome.org/browse/hamster-applet/commit/?h=gnome-2-32&id=4b40e64c536a79329adbd0cae3d17c615f3904e0 [10:41] i think i might test that and then backport it if it works [10:42] i really on the hamster applet ;) [10:42] pitti: ok, so removing the conffile for gnome-keyring-gpg.desktop and filing the upstream bug :) [10:42] didrocks - ok, that output looks fine [10:42] i think it's good to go :) [10:42] chrisccoulson: ok, great t;) [10:42] chrisccoulson: needs sponsoring for that one? [10:42] didrocks, yes please [10:43] i can't upload that yet ;) [10:43] chrisccoulson: ok, doing then :) [10:43] thanks. i'll get ia32-libs done then, once that's been approved [10:44] chrisccoulson: great, setting it as fix commited [10:44] thanks [10:44] thank to you :) [10:54] chrisccoulson: so, there is nothing do to on ia32-libs? [10:54] didrocks - i need to refresh ia32-libs with the new gdk-pixbuf version, and also add a postinst hook to create the loaders.cache on install [10:55] chrisccoulson: ok, keep me in touch ;) [10:59] ok, hamster-applet is fixed [10:59] will upload that too [11:01] great ;) [11:01] do you want to work on other bugs too? [11:02] didrocks - yeah, sure :) [11:02] chrisccoulson: I think that one can be interesting to fix (bug #630753) [11:02] Launchpad bug 630753 in gnome-screensaver (Ubuntu) "gnome-screensaver activates while watching a movie in totem (affects: 2) (heat: 206)" [Undecided,New] https://launchpad.net/bugs/630753 [11:03] yeah, i can take that one [11:03] i saw that too [11:03] thanks :) [11:03] maybe totem issue as vlc isn't impacted [11:03] VLC uses a different mechanism to do this [11:05] oh ok :) [11:06] right, i've got to pop out for a little bit to pick up my car :) [11:17] see you! === al-maisan is now known as almaisan-away [12:05] RAOF: can you have a look at your WI list and state on them, please? === MacSlow is now known as MacSlow|lunch [13:15] didrocks, I'm not sure who I should best ask, but you and Robert seemed to do the latest changes for yelp, so here goes the question :) [13:15] could someone have a look at bug 605577 and remove the en.po translation? [13:15] Launchpad bug 605577 in yelp (Ubuntu) (and 4 other projects) "Help contents title bar shows cubes with numbers instead of a proper title (affects: 127) (dups: 65) (heat: 830)" [Undecided,Invalid] https://launchpad.net/bugs/605577 [13:16] I've explained in my last comment. This will still not fix the bug (we'll need a new full language pack for that), but at least will I think prevent the wrong en.po getting into LP with the next upload [13:16] dpm: don't we refresh the full yelp on 2.32.0 upload normally? [13:17] didrocks, if that's planned, that's fine, that would take care of it [13:17] dpm: I mean, take from launchpad, as create this patch [13:17] dpm: yeah, next week, we will have 2.32.0 [13:17] ok, cool [13:17] I should just add a task to remind me about it :) [13:17] :) [13:18] oh no [13:18] sorry, we have 2.30.1 [13:18] I think it's the webkit transition [13:18] so, we wont update [13:18] dpm: the best fix it to take from launchpad and refresh the patch? [13:18] rather than deleting en.po [13:19] didrocks, yeah, as it will fetch new translations in other languages people might have done [13:19] dpm: think it worthes it, adding a task for me :) [13:19] dpm: btw, bug #619816 [13:19] Launchpad bug 619816 in gnome-power-manager (Ubuntu) (and 1 other project) "Battery status line too long (affects: 2) (dups: 1) (heat: 20)" [Medium,New] https://launchpad.net/bugs/619816 [13:19] awesone, thanks didrocks [13:19] ok, let me have a look [13:19] dpm: not sure it will be accepted or not, still didn't ask, but maybe it worthes it === MacSlow|lunch is now known as MacSlow [13:32] didrocks, ok, commented on it, thanks for the pointer [13:33] thanks dpm :) [13:51] who can tell me something about the libindicator uploads? [13:51] is it correct to demote libindicator-tools ? === almaisan-away is now known as al-maisan [13:53] doko: I think you should ask tedg about it when he's around [13:53] didrocks: could you remind me/ask him? [13:53] doko: yeah, I will [13:53] thanks [13:53] yw [14:16] dpm: can you join #ayatana? [14:19] yep! [14:23] thanks :) === ara__ is now known as ara [14:33] tedg: hey [14:33] 14:51:24 doko | is it correct to demote libindicator-tools ? [14:33] tedg: ^^ [14:34] didrocks, What does "demote" mean in this context? [14:34] Oh, to universe? [14:34] I don't think there's any reason those need to be in main. They're just debugging tools. [14:35] doko, ^ [14:35] tedg: ok, thanks! [14:36] yeah, it's my feeling as well :) [14:36] dpm, we have a problem with https://bugs.edge.launchpad.net/ubuntu-translations/+bug/646653 [14:36] thanks tedg [14:36] Ubuntu bug 646653 in unity (Ubuntu) (and 2 other projects) "The number of items message in the Unity trash does not load translations (affects: 1) (heat: 6)" [Critical,Triaged] [14:36] dpm, it's getting late and I can not for the life of me figure out why ngettext() isn't working [14:36] dpm, So my last resort is to change the string into something without nggettext() [14:37] hey kamstrup, does gettext() work there? [14:37] dpm, So either (if n_items == 1) _("1 Item in trash") else _("%d items in Trash") - and pretend plural forms don't exist [14:37] dpm, yes [14:38] dpm, or simply "Items in trash: %d" - which seems a bit awkward [14:38] dpm, what's your take on this? [14:38] kamstrup, I think it might be awkward, but at this point it might be the best solution as the if/else option would only work for some languages [14:39] dpm, ok will do that then - should I notify the mailing list? [14:39] kamstrup, yes, please, that would be great [14:40] kamstrup, and thanks a lot for the work on this [14:47] didrocks, the conversation on the g-p-m time string has reminded me about bug 579134 - I know it's too late, but it might be worth reassessing the importance, as per pitti's comment there, so that it stays on the radar for natty perhaps [14:47] Launchpad bug 579134 in indicator-datetime (Ubuntu) (and 2 other projects) "The date and time indicator should respect the locale setting for time format (affects: 23) (dups: 2) (heat: 126)" [Undecided,New] https://launchpad.net/bugs/579134 [14:47] dpm: ugh, does that thing still display 12 hours only? :-( [14:48] pitti, I think there was a workaround to use a translatable string to specify the format, but I haven't tried it yet, as we haven't finished translating it in our team [14:49] I might try with another locale [14:49] dpm: but that's rather broken -- that's already specified in the locale [14:49] pitti, I know, I know, I'm just mentioning it [14:49] pitti: what do you expect from "A very, very simple clock"? [14:50] I understand that we don't want to use strftime(%c), but we can certainly ask the locale for whether it's 24 or 12 hours, and the AM/PM strings [14:50] dpm: can you remind me that later? It's one of the blocker I set to not put indicator-datetime to the desktop this cycle [14:50] geser: to at least show the correct time? :-) [14:50] didrocks, sure [14:50] tedg: ^ WDYT about just asking the locale for the format? [14:51] pitti: 50% of a day it's correct :) [14:51] pitti, I couldn't find a way to ask it that simple of a question. But, what we do is make the default string translatable. [14:51] geser: only if you work from 6 to 18, which is not quite the most preferred part of the day for geeks.. [14:54] pitti, There's also a gsettings key for those who don't like their locale's setting. [15:03] good morning all [15:03] tedg: so from a shell this would be "locale -k am_pmÄ [15:03] hey rickspencer3 [15:04] tedg: of course you'd use the libc function for that, but if it has a value, it shows the localized strings for AM and PM; if it's not set, it's 24 hours [15:04] tedg: with that we can use the info from the locales, instead of having to re-translate them all over agani (which is also quite error prone) [15:07] hey rickspencer3 [15:07] hi didrocks [15:07] tedg, pitti, dpm: I remember looking at that bug. I think one problem I had was that en_GB doesn't translate the string to say 24 hour time. Also, stfrtime can give you the time in locale format, but it has seconds attached, and there's no clean way to strip that [15:08] mterry: right, that's why I suggested asking the locale instead of strftime() [15:09] mterry: but en_GB uses 12 hours? [15:10] pitti, no? I thought not. I've used it in the past to show 24h [15:12] pitti, this is complicated. language-support says en_GB is 24h. with LC_TIME="en_GB.UTF-8", date --date="8PM" gives 20:00:00. But locale -k am_pm shows am_pm="AM;PM" [15:12] mterry: oh, indeed; seems I misremembered [15:12]