=== Ursinha is now known as Ursinha-afk
[03:45] <pitti> Good morning
[05:33] <didrocks> good morning
[05:36] <didrocks> hum, biab
[05:59] <pitti> bonjour didrocks
[05:59] <pitti> didrocks: so what's that "BaseException: foo bar" thing that apparenlty breaks ubuntu-developer-tools-center?
[06:01] <didrocks> pitti: it's part of a test and expected (I don't remove stderr, but it's just a print)
[06:01] <didrocks> morning pitti btw ;)
[06:01] <pitti> ah right
[06:01] <pitti> so it' sjust
[06:01] <pitti> adt-run [15:39:04]: test all:  - - - - - - - - - - results - - - - - - - - - -
[06:01] <pitti> all                  FAIL stderr: 2014-08-27 15:38:35,645 [nose.plugins.manager] DEBUG: DefaultPluginManager load plugin cov = nose_cov:Cov
[06:01] <pitti> (i. e. the whole two metric tons of debug log)
[06:02] <didrocks> argh
[06:02] <pitti> didrocks: alors, tu veux ajouter "allow-stderr"
[06:02] <didrocks> or see if I can remove debug infos frmo nose-cov itself
[06:03] <didrocks> or yeah, just adding your tag
[06:03] <didrocks> on teardown of my tests, I'm ensuring I don't have any warning/error on stderr
[06:03] <didrocks> (for each tests)
[06:03] <didrocks> or it will raise in error
[06:04] <pitti> that's nicer for catching unexpected warnings, indeed
[06:04] <didrocks> so, I guess that's good enough, I control my own stderr from my tests
[06:04] <pitti> that's also why the "fail on stderr" is still useful by default
[06:04] <didrocks> yeah, but as it's covered in my tests for me…
[06:04] <didrocks> I have also a flag that I turn in some tests
[06:04] <didrocks> which do the contrary
[06:04] <didrocks> like "I know I'll have a warning/error here, raise if there is none"
[06:05] <didrocks> ok, so, let me add this tag
[06:05] <didrocks> I fixed the coverage wrong report issue as well
[06:05] <didrocks> so now, small tests covers 77%
[06:05] <didrocks> and I'm still at 99% with the large ones
[06:07] <pitti> didrocks: wow
[06:08] <pitti> didrocks: in things like umockdev I find it excessively hard to get above 80%, as the remaining code paths are error handling for obscure conditions which are not practially reproducible in tests..
[06:08] <pitti> so, congrats!
[06:08] <didrocks> pitti: that's why large tests are integration tests (small are units/modules)
[06:09] <pitti> yeah, but rare corner cases are even harder to hit with integration tests than with unit tests
[06:09] <pitti> like, malloc() failures, or socket() failing, etc.
[06:09] <didrocks> and medium are large tests without network and fake data (they inherit from large tests) + as, I'm in control of the mocks, I play with sending download not matching md5sum for instance :p
[06:09] <didrocks> yeah
=== jpds_ is now known as jpds
[06:15] <didrocks> pitti: ok, pushed now! Thanks for the help, I'll know where to look at now :)
[06:15] <didrocks> pitti: so, as soon as you have a minute for enabling the medium tests…
=== jpds is now known as Guest68298
[06:15] <pitti> didrocks: that should have failed the same way in a local run, though? didn't it?
=== Guest68298 is now known as jpds_
[06:16] <pitti> didrocks: ah, that's the one which needs webternet access?
[06:16] <didrocks> pitti: I'm pretty sure it didn't, (RET code was 0)
[06:16] <didrocks> I can check again if needed
[06:16] <didrocks> pitti: right, so medium only need to download a docker image from the docker hub
[06:17] <didrocks> large, if enabled, would need a fake X server (I guess xvfb can work) + webternet access
[06:19] <pitti> didrocks: ok, you can sort out adding xvfb-run (you can test that locally), I'll look into wiring the http_prxy
[06:19] <pitti> I'll use the gem2deb autopkgtest for that, it fails for the same reason
[06:20] <didrocks> pitti: yeah, I'll try with the medium tests first anyway, not sure I want to wire the large tests in that stage, or will do only in my daily tests run in another vm
[06:20] <didrocks> pitti: ok, you're right, exit code was 4 btw without the allow-stderr
[06:20] <didrocks> locally
[06:21] <didrocks> I'll blame jetlag in China when I did this
[06:21] <didrocks> (I guess the OK at the end derouted me)
[06:43] <seb128> good morning desktopers
[06:44] <pitti> bonjour seb128
[06:44] <seb128> pitti, salut, wie gehts?
[06:44] <pitti> seb128: quite fine, thanks!
[06:45] <pitti> seb128: we made an interesting observation today
[06:45] <pitti> seb128: messaging-app has 31 strings upstream, and 65 strings in ubuntu
[06:45] <seb128> is "today" started enough to be able to do observations? ;-)
[06:45] <pitti> at first I thought it was an error in message sharing/imports, but it's actually correct
[06:45] <seb128> pitti, outdated upstream template?
[06:45] <pitti> seb128: right
[06:45] <seb128> that makes sense
[06:45] <pitti> seb128: IOW, it seems ubuntu's are always current (after landing, anyway)
[06:46] <pitti> so it's possible/better to translate the ubuntu one than the upstream one, as that's notoriously outdated
[06:46] <seb128> hum
[06:46] <pitti> I directly pushed a POT update to messaging-app, but it affects others, too
[06:46] <seb128> well
[06:46] <seb128> the issue is clicks
[06:46] <seb128> they don't use langpacks
[06:46] <pitti> yes, of course
[06:46] <seb128> we need to ship back the translations to trunk
[06:46] <pitti> but still, it helps somewhat for the debs
[06:46] <seb128> right
[06:46] <seb128> but those are supposed to be the minority
[06:47] <pitti> well, "supposed", but they aren't yet
[06:48] <pitti> seb128: anyway, it seems the imports worked well, and message sharing works
[06:48] <seb128> great
[06:48] <pitti> seb128: and FTR, yes, it was early enough :) 2014-08-28 05:43: arrived
[06:49] <seb128> so upstream got updated translations?
[06:49] <seb128> bah, you early bird ;-)
[06:49] <pitti> seb128: yes, I pushed the pot, and now upstream has the same ones
[06:49] <pitti> seb128: I noticed some broken strings, I sent an MP
[06:49] <pitti> https://code.launchpad.net/~pitti/messaging-app/i18n-fixes/+merge/232507
[06:49] <pitti> (still needs to be reviewed)
[06:49] <seb128> https://translations.launchpad.net/messaging-app
[06:49] <seb128> 46 untranslated in french, what is our team doing!
[06:49] <pitti> right
[06:49] <pitti> strings are changing like mad
[06:50] <pitti> and the POT hasn't been updated in ages
[06:50] <pitti> and some strings like the attachment ones can't be translated as they are buggy
[06:50] <pitti> (see above MP)
[06:50] <seb128> right
[06:50] <seb128> I wish we had a proper solution/option to commit pot updates to trunk
[06:51] <seb128> ideally launchpad should have recipies or integration to refresh/commit those
[06:51] <pitti> well, you'd need to actually be able to update them without installing a gazillion build deps and building
[06:51] <pitti> then it could be done on landing
[06:54] <didrocks> sweet! https://jenkins.qa.ubuntu.com/job/utopic-adt-ubuntu-developer-tools-center/2
[06:54] <pitti> didrocks: c'est vert !
[06:55] <didrocks> pitti: j'aime le vert :)
[06:55] <pitti> didrocks: moi aussi !
[06:55] <seb128> pitti, well, usually the pot update is basically running xgettext
[06:55] <pitti> c'est la plus bonne coleur
[06:55] <pitti> couleur
[06:56] <pitti> (je suis sûr que c'est ^ encore faux ☺ )
[06:57] <seb128> belle
[06:57] <seb128> if that's what you mean
[06:57] <seb128> ou "la meilleur"
[06:57] <seb128> we don't use "plus bon"
[06:57] <seb128> well, we do, but not in the "+" meaning ;-)
[06:59] <pitti> seb128: ah, I thought "plus adv" -> "more adv", "la plus adv" -> "the most adv", but yeah, "good" is always special
[06:59] <pitti> good/better/best, gut/besser/bester
[06:59] <seb128> yeah
[06:59] <seb128> it's like "more good" in english
[06:59] <pitti> seb128: so it's mieux ("plus bon") and meilleur ("la plus bon")?
[06:59] <seb128> sounds wrong
[07:00] <seb128> yes
[07:00] <pitti> seb128: but it would be "cette pomme est plus grand que l'autre pomme", and "c'est la plus pomme"?
[07:00] <pitti> "c'est la plus grande pomme"?
[07:00] <seb128> grande
[07:00] <seb128> but yes ;-)
[07:01] <pitti> oui; merci !
[07:01] <seb128> de rien !
[07:24] <ypwong> Is bug 1362086 a known issue in current daily build?
[07:24] <ubot2`> Launchpad bug 1362086 in ubuntu "install the system, start the os, some windows flashing" [Undecided,New] https://launchpad.net/bugs/1362086
[07:24] <ubot5> bug 1362086 in Ubuntu "install the system, start the os, some windows flashing" [Undecided,New] https://launchpad.net/bugs/1362086
[07:29] <willcooke> Morning all
[07:29] <willcooke> Hi TheMuso
[07:29] <seb128> hey ypwong
[07:29] <seb128> hey willcooke
[07:29] <seb128> not a known issue
[07:29] <ypwong> seb128, morning
[07:30] <ypwong> seb128, another bug 1356825 saying compiz is not running
[07:30] <ubot2`> Launchpad bug 1356825 in ubuntukylin "Compiz doesn't run after log in system" [Undecided,New] https://launchpad.net/bugs/1356825
[07:30] <ubot5> bug 1356825 in Ubuntu Kylin "Compiz doesn't run after log in system" [Undecided,New] https://launchpad.net/bugs/1356825
[07:30] <TheMuso> Hey willcooke.
[07:31] <seb128> ypwong, look at .cache/upstart/gnome-session-Unity.log?
[07:32] <didrocks> morning willcooke
[07:32] <seb128> ypwong, is that a liveCD iso? or an installed system?
[07:32] <seb128> hey TheMuso
[07:32] <ypwong> seb128, not sure, it's tested by NUDT QA
[07:33] <TheMuso> Hey folks.
[07:34] <didrocks> evening TheMuso :)
[07:37] <happyaron> didrocks: don't forget the fcitx MIR
[07:37] <happyaron> :)
[07:38]  * happyaron off of the day, 0:37AM...
[07:38] <ypwong> happyaron, goodnight
[07:38] <didrocks> happyaron: don't worry, told you I couldn't yesterday with the backlog, but it's on my list
[07:39] <happyaron> ok
[07:39] <happyaron> ypwong: thanks, :)
[07:49] <willcooke> happyaron, where are you atm?
[07:49] <willcooke> happyaron, do you want to meet today?
[07:49] <happyaron> willcooke: I'm at Debconf, can't make it I think...
[07:49] <willcooke> ahhhh - yes of course.
[07:49] <willcooke> My brain is like swiss cheese at the moment
[07:49] <willcooke> ok, happyaron I'll email you some stuff
[07:49] <willcooke> happyaron, have fun!
[07:50] <happyaron> thanks!
[07:51] <pitti> didrocks: ok, I adjusted autopkgtest's VM build script for proxy handling and tested gem2deb manually in the DC; now deploying this
[07:52] <didrocks> pitti: excellent!
[07:53] <willcooke> didrocks, is the PPA for dev desktop in your PPA?
[07:53] <didrocks> willcooke: for trusty yeah (ppa:didrocks/ubuntu-developer-tools-center), for utopic, just use distro
[07:53] <willcooke> didrocks, thx
[07:53] <didrocks> install ubuntu-developer-tools-center should be enough
[07:53] <didrocks> yw
[07:54] <didrocks> (the command is udtc)
[07:55] <pitti> didrocks: the command name obviously should have started with "udev-"!
[07:55]  * pitti apologizes; you can tell I'm waiting for test runs to finish, which don't take long enough to do something useful in between :)
[07:56] <didrocks> pitti: I can see in particular that you still endure pain with the halsectomy and all this udisk/udev/ubrokenbrain things :p
[07:56] <pitti> udev is fine :)
[08:04] <pitti> didrocks, jibel: *screw* *hammer* *lube* *wrench* et voilà -- your new interweb tube for autopkgtests!
[08:04] <pitti> https://jenkins.qa.ubuntu.com/job/utopic-adt-gem2deb/?
[08:05] <larsu> interweb tube! *giggle*
[08:06] <didrocks> pitti: \o/
[08:07] <didrocks> pitti: no metadata to add to enable the proxy?
[08:08] <pitti> didrocks: there is, the proxy needs to be set in the cloud-init metadata
[08:08] <pitti> didrocks: but that's done automatically now
[08:08] <pitti> didrocks: so the tests themselves don't need to do anything
[08:08] <didrocks> excellent :)
[08:08] <didrocks> I need to build a new vm locally, to try?
[08:08] <didrocks> with cloud-init?
[08:08] <pitti> didrocks: no
[08:08] <didrocks> I just add the tests then and cross fingers without testing locally? ;)
[08:08] <pitti> didrocks: that's just for the DC as it is firewalled; your local VMs (presumably) have unrestricted webternet access
[08:08] <didrocks> ok
[08:09] <pitti> didrocks: no, please do test locally first
[08:09] <pitti> if they don't pass locally, they won't pass in the DC either
[08:09] <didrocks> sure
[08:09] <didrocks> I'm fixing the medium tests as we speak, I understand why it's failing, but not why it changed
[08:10] <pitti> didrocks: btw, now that the test succeeded once, any future failure will block the package
[08:10] <pitti> (we block on regressions, but not on "always failed")
[08:10] <didrocks> yeah
=== hikiko-lpt is now known as hikikoo
=== hikikoo is now known as hikiko
[08:19] <didrocks>   Issued certificate has expired.
[08:19] <didrocks> snif :p
[08:31] <Sweetsha1k> moin!
[08:33] <willcooke> hey Sweetsha1k
[08:33] <willcooke> wrong name :)
[08:34] <willcooke> didrocks, JackYu will have those translations done today he thinks
[08:35] <seb128> hey Sweetsha1k
[08:35] <didrocks> willcooke: yeah, I received an email as well, thanks a lot!
=== Sweetsha1k is now known as Sweetshark
[08:38]  * Sweetshark feels better.
[09:19] <pitti> didrocks: I'll retry the failed udtc run on i386
[09:19] <didrocks> pitti: I was wondering if I can do that myself?
[09:19] <pitti> self.assertTrue(len(map_result) == 1)
[09:19] <pitti> argh!
[09:19] <pitti> didrocks: yes, if you have VPN
[09:19]  * didrocks changes silently for an equals :p
[09:20] <pitti> didrocks: I find this useful:
[09:20] <pitti> self.assertEqual(len(map_result), 1, str(map_result))
[09:20] <pitti> didrocks: then you see the actual value on failure
[09:20] <didrocks> pitti: oh nice, didn't know that one, will update in multiple places then, thanks!
[09:20] <pitti> unless you can assert the string contents of course, then assertEquals(map_result, ['foo']) is even better
[09:20] <didrocks> I can't assert the content
[09:21] <pitti> didrocks: yes, assert*() all take an optional last argument which is shown on failure; usually a string
[09:21] <pitti> like assertEqual(a, b, 'got %s, my debug variable x = %s' % (b, x))
[09:21] <didrocks> ok, let me update that, while I'm testing the fixed medium tests with new certificate in adt
[09:22] <pitti> didrocks: do you see http://d-jenkins.ubuntu-ci:8080/job/utopic-adt-ubuntu-developer-tools-center/ ?
[09:22] <pitti> didrocks: i. e. do you have VPN set up?
[09:22] <didrocks> pitti: sure, I do, the whole CI was based on it :)
[09:22] <pitti> didrocks: if so, you can log in and click on "Build now"
[09:22] <didrocks> pitti: yeah, doing that meanwhile
[09:23] <didrocks> thanks!
[09:23] <pitti> didrocks: ah, and now of couse udtc holds back python-apt :) (but nevermind, we are in freeze anyway)
[09:23] <didrocks> ahah, sorry ;)
[09:23] <didrocks> (relaunched)
[09:23] <pitti> #4 running, Gestartet durch Benutzer Didier Roche
[09:23] <pitti> \o/
[09:24]  * pitti ^5s didrocks
[09:24] <pitti> didrocks: don't use the "matrix reloaded" btw, it confuses things
[09:24]  * didrocks high five back pitti
[09:24] <didrocks> pitti: yeah, we had issues with it as well in CI
[09:25] <didrocks> ok, I had assertEqual for all the others
[09:25] <didrocks> let me add the arg though
[09:31] <didrocks> pitti: ok, I'll need to dig in medium tests why it can't start a docker container there. Ideally, I will be able to find how to drop myself inside the chroot
=== alan_g is now known as alan_g|afk
=== alan_g|afk is now known as alan_g
[09:56] <didrocks> pitti: 2014/08/28 09:56:24 Post http:///var/run/docker.sock/v1.12/containers/create: dial unix /var/run/docker.sock: permission denied
[09:56] <didrocks> pitti: do I need to relax any constraint? (I guess maybe the allow-root?)
[09:57] <didrocks> the docker service (which needs more perms) is activated by the docker command (which doesn't need root)
[10:01] <pitti> didrocks: if you need to be root to access docker, then yes, "needs-root"
[10:01] <didrocks> pitti: but it doesn't log me as root, right?
[10:01] <pitti> didrocks: you can run those in a separate Tests:, so the others run as user
[10:01] <didrocks> (as I have tests where I don't want that)
[10:01] <didrocks> hum
[10:01] <pitti> and it's better to have finer-grained tests anyway
[10:01] <didrocks> yeah, it will just change my coverage report logic :p
[10:02] <pitti> didrocks: it runs the test script as root with "needs-root"; otherwise, a user (usually "ubuntu", but can be "phablet", or something else -- that depends on the testbed)
[10:02] <didrocks> ok, let's try the medium tests with that separately first
[10:03] <didrocks> pitti: the command itself doesn't need to be root, it's the activated service that needs that, let's see if the tag will allow that
[10:03] <pitti> didrocks: activated by what?
[10:03] <pitti> didrocks: if it's a system service which is running, then your test doesn't need root
[10:03] <pitti> didrocks: if you want to access the socket yourself, then you need to, of course
[10:06] <didrocks> hum, /me checks the docker documentation
[10:06] <didrocks> ah, actually, I think it's just that the "ubuntu" user needs to be in the docker group
[10:06] <didrocks> but then, it needs to refresh the groups list
[10:07] <pitti> didrocks: hm, that makes it complicated indeed
[10:07] <didrocks> yeah, need to add manually, and the launch bash?
[10:07] <pitti> you'd need to start as root, detect some user (uid >= 500), add that to the group, then call the tests through su "testsuite" $user
[10:08] <didrocks> yeah, not sounds hackish…
[10:16] <tkamppeter> willcooke, around?
[10:18] <willcooke> hey tkamppeter
=== jpds_ is now known as jpds
=== MacSlow is now known as MacSlow|lunch
[11:51] <didrocks> pitti: ok, I'm quite unsure, I'll be able to get the medium tests running soon inside autopkgtests though
[11:51] <didrocks> I can download the container, starts it
[11:52] <didrocks> but for weird reason, I can't ssh to it, like if the user (that has harcoded password for this temporary session) wouldn't let me log in
[11:52] <didrocks> and same container (checked the ID) would let me log in outside the autopkg chroot, weird
[11:52]  * didrocks starts a second container manually inside the chroot to check users
[11:53] <didrocks> ah, it seems that stdout is blocked, if I cat anything…
[11:54] <didrocks> and so then, I get no prompt back
[11:54] <didrocks> (I guess someone in the autopkg setup)
[11:55] <didrocks> ahah, it all comes down to that: su: System error
[11:56] <didrocks> hence ssh not answering
[12:02] <didrocks> 52 results only on google
[12:02] <didrocks> that's the cost of trying something really new I guess ;)
[12:02]  * didrocks tries to build an image with utopic docker's version, just in case there is an incompatibility
=== alan_g is now known as alan_g|lunch
[12:18] <pitti> didrocks: yeah, I don't remember any test that involves docker so far
[12:19] <didrocks> pitti: I'm trying 2 things: building a new trusty image with the new docker or trying utopic docker image on utopic
[12:19] <didrocks> but building an image is taking ~30min, so I switched back to the MIRs meanwhile
[12:19]  * pitti hands didrocks the "Pioneer!" shirtr
[12:19] <pitti> s/r$//
[12:20] <didrocks> pitti: ahah :) on the back, is it written "suffering"?
[12:20] <pitti> didrocks: aren't these synonyms?
[12:20] <didrocks> I guess you're right ;)
[12:20] <pitti> To boldly test where noone has tested before!
[12:20] <didrocks> heh
[12:20] <didrocks> speaking of pain! no space left inside the chroot
[12:20]  * didrocks <- sad face
[12:21] <pitti> didrocks: reminds me of the first time we tried to run autopilot tests in autopkgtests
[12:21] <didrocks> yeah, I guess that was "fun"
[12:21] <didrocks> Sweetshark: of course, it stopped on libreoffice! all your fault
[12:21] <pitti> after 3 days or so we finally figured it out; I spent a whole afternoon with jibel trying to track down a 30 s timeout which eventually turned out to be a bamf issue
[12:22] <didrocks> argh "nice"
[12:22] <pitti> didrocks: uh, you're building a biiig image there .. why not start with something smaller?
[12:22] <didrocks> pitti: well, that's what I used for my medium tests, I'm building the desktop image
[12:23] <didrocks> to "simulate" the real env udtc in running in
[12:24] <didrocks> I can strip down for this test at least
[12:27] <Trevinho> pitti: oh, what is doing wrong bamf?
[12:28] <didrocks> pitti: yeah, there is really something inside the chroot: PAM: System error
[12:28] <didrocks> /usr/bin/chfn -f  user returns 1
[12:28] <didrocks> (inside docker)
[12:31] <pitti> Trevinho: I think back then the issue was that autopilot talked to bamf without declaring a dependency, so we didn't install it in the test env
[12:31] <pitti> Trevinho: so it just dbus-timed out for 25 s on each test, which blew up the test time from the usual 10 seconds to like 20 minutes
[12:31] <pitti> but it was not at all easy to see that :)
[12:32] <Trevinho> ouch :P
[12:32] <pitti> and then some fun setting up enough of Xvfb, dbus-server, some Xvfb options etc. to make everything actually work
[12:32] <Trevinho> yeah, bamf is a subtle dependency...
[12:32] <pitti> then autopilot-sandbox-run was born to do all that automagically :)
[12:33] <Trevinho> probably that bamf module should be moved away from new AP, and just kept for the desktop version
[12:33] <Trevinho> cool
=== MacSlow|lunch is now known as MacSlow
=== Ursinha-afk is now known as Ursinha
=== alan_g|lunch is now known as alan_g
[13:07] <Sweetshark> didrocks: what stopped on libreoffice?
[13:08] <Sweetshark> didrocks: nobody expects to stop on libreoffice!
[13:08] <didrocks> Sweetshark: apart if your disk is full! ;)
[13:08] <Sweetshark> lo
[13:08] <Sweetshark> lol
=== Ursinha is now known as Ursinha-afk
[13:10] <Sweetshark> didrocks: see the text on the back of the t-shirt: http://vmiklos.hu/blog/so-many-bugs.html
[13:11] <didrocks> ahah :)
[13:11] <larsu> haha, nice one
=== Ursinha-afk is now known as Ursinha
=== jmunsch is now known as Guest11861
=== gatox is now known as gatox_lunch
[14:37] <didrocks> ok, i18n translations merged back in udtc done (and udtc 0.0.4 uploaded), now, time for a very late run :)
[14:41] <larsu> didrocks: it's not that late…
[14:41] <larsu> enjoy anyway ;)
[14:41] <didrocks> larsu: no break for 9h, I count that late :)
[14:41] <didrocks> thanks ;)
[14:42] <larsu> didrocks: man, take more breaks
[14:42] <didrocks> but you know this "just that and I'll be done"… :p
[14:43] <didrocks> and it's just to reveal more issues, of course :)
[14:43] <larsu> yeah I know the feeling
=== m_conley_away is now known as m_conley
=== gatox_lunch is now known as gatox
[15:26] <happyaron> willcooke: ping
[15:27] <willcooke> happyaron, hey - in a meeting, but can type
=== tiheum_ is now known as tiheum
=== alan_g is now known as alan_g|EOD
[17:15] <didrocks> happyaron: I'll finish the MIR 2nd pass tomorrow morning
[17:15]  * didrocks EOD, see you tomorrow guys!
[17:16] <happyaron> great, see you, :)
[17:19] <seb128> kenvandine, hey
[17:19] <seb128> kenvandine, would it be annoying if I ask to rename that DialpadSounds property?
[17:19] <seb128> like DialpadSoundsEnabled
[17:19] <seb128> or something that makes it clear from reading it that it's a on/off bool
[17:19] <seb128> and not a sound name
[17:22] <Laney> MakeDialpadSounds
[17:22] <happyaron> bad day bad day
[17:22] <Laney> ?
[17:23] <happyaron> relatively personal issue..
[17:23] <kenvandine> seb128, fine with me
[17:24] <seb128> kenvandine, ok, please do it then ;-)
[17:24] <kenvandine> seb128, and i still want feedback from boiko
[17:24] <seb128> k
[17:35] <kenvandine> seb128, renamed
[17:36] <seb128> kenvandine, thanks, approved
=== shiznix_ is now known as shiznix
=== m_conley is now known as m_conley_away