:: #mythtv

Daily chat history

Current users (80):

aloril, Anduin, anykey_, Beirdo, ben1066, brfransen, brtb, CaCtus491, Captain_Murdoch, cattelan, Chutt, clever, coling, Cougar, damaltor, danielk22, dekarl, dlblog, ElmerFudd, foobum, ghoti, gigem, gregL, GreyFoxx, highzeth, J-e-f-f-A, j-rod|afk, jafa, jarle, jcarlos, joe_, joki, jpabq-, jstenback, jwhite, k-man, knightr, kormoc, kurre2, kwmonroe, laga, mag0o_, markcerv, MaverickTech, mike|2, mrand, MythBuild, MythLogBot, mzanetti, NightMonkey, peitolm, pheld, poptix, purserj, rhpot1991, seld, skd5aner, Slasher`, sphery, sraue, stuarta, superm1, sutula, taylorr, tgm4883, TheAsp, The_Ball, ThisNewGuy, tomimo, tris, Unhelpful, vallor, wagnerrp, wahrhaft, wseltzer, xavierh, xris, yb0t, zCougar, _charly_
Thursday, March 22nd, 2012, 00:04 UTC
[00:04:08] stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 265 seconds)
[00:11:02] TheAsp: I feel like i'm about to be eaten by a grue :)
[00:24:47] Beirdo: Captain_Murdoch: if you're in... I will be trying to work #10488 when I get home
[00:34:21] knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv
[00:37:08] knightr_ (knightr_! has quit (Ping timeout: 246 seconds)
[00:37:59] knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Read error: Operation timed out)
[00:40:20] knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv
[00:41:43] kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has quit (Quit: kormoc)
[00:52:38] cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has quit (Quit: Konversation terminated!)
[01:27:57] danielk22: TheAsp: Only if the device tells us there is no data and that loop is actually running. Just put a LOG in linux_firewire_device_tspacket_handler() that fires off a message every 1000 packets. If that keeps humming you know you've got data coming in.
[01:40:15] stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has joined #mythtv
[03:22:48] knightr_ (knightr_! has joined #mythtv
[03:26:49] knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Ping timeout: 260 seconds)
[03:29:38] mike|2 (mike|2! has quit (Ping timeout: 240 seconds)
[03:42:08] mike|2 (mike|2! has joined #mythtv
[03:58:46] cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has joined #mythtv
[04:17:54] kormoc (kormoc!~kormoc@mythtv/developer/kormoc) has joined #mythtv
[04:47:19] cattelan is now known as cattelan_away
[05:39:30] xris: danielk22: in case you're still awake:
[05:44:19] brfransen_ (brfransen_!~brfransen@ has joined #mythtv
[05:46:14] brfransen (brfransen!~brfransen@ has quit (Ping timeout: 260 seconds)
[05:46:14] brfransen_ is now known as brfransen
[06:25:57] stoffel (stoffel! has joined #mythtv
[07:31:16] Yancho (Yancho!~mpulis@unaffiliated/yancho) has quit (Quit: Leaving)
[07:32:55] kenni: Captain_Murdoch: Thanks..I don't think a version bump was performed on Terra, is this required for your script to pick up the changes or does it just pull and repackage all of the theme regardless of their versions?
[07:37:05] stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 252 seconds)
[07:50:31] stichnot (stichnot!~chatzilla@ has joined #mythtv
[07:50:31] stichnot (stichnot!~chatzilla@ has quit (Changing host)
[07:50:31] stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has joined #mythtv
[08:35:32] tr_ (tr_! has joined #mythtv
[08:36:16] tr_: seldom have i been so enraged by sw as by mythtv
[08:36:31] tr_: just as a nice introduction
[08:38:29] tr_: moving this to #mythtv-users
[08:38:32] tr_ (tr_! has left #mythtv ()
[10:05:02] mike|2 (mike|2! has quit (Remote host closed the connection)
[10:05:51] mike|2 (mike|2! has joined #mythtv
[10:41:07] stoffel (stoffel! has quit (Read error: Connection reset by peer)
[10:43:03] Yancho (Yancho! has joined #mythtv
[10:43:03] Yancho (Yancho! has quit (Changing host)
[10:43:03] Yancho (Yancho!~mpulis@unaffiliated/yancho) has joined #mythtv
[10:53:01] jya_ (jya_!~jyavenard@ has joined #mythtv
[10:53:01] jya_ (jya_!~jyavenard@ has quit (Changing host)
[10:53:02] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[11:21:04] justinh (justinh! has joined #mythtv
[11:21:22] justinh (justinh! has left #mythtv ()
[11:29:26] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_)
[11:30:48] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[11:58:43] seeker (seeker!~seeker@unaffiliated/seeker) has joined #mythtv
[12:23:42] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_)
[12:26:14] danielk22: xris: What version of MythTV is this? I can't find that error message in the code. I haven't followed HDHR development in the last couple years, but MythTV always creates an mplexid so it's a pretty fair assumption that it would be there.
[12:26:21] coling_ is now known as coling
[12:29:08] stichnot: I have a problem where (I think) MythScreenType::LoadInBackground(QString message) is calling Load() in another thread which deletes ProgramInfo data still in use in the original thread's event loop, causing a segfault. Any advice on how to deal with this?
[12:32:23] stichnot: specifically, ProgLister::Load() calls ProgLister::FillItemList() which calls m_itemList.clear() where m_itemList is a ProgramList
[12:34:00] seeker (seeker!~seeker@unaffiliated/seeker) has quit (Quit: Colloquy for iPhone -
[12:56:08] gregL (gregL! has quit (Read error: Connection reset by peer)
[13:23:18] Captain_Murdoch (Captain_Murdoch! has quit (Ping timeout: 255 seconds)
[13:29:58] stichnot: Applying lazystrings (background loading of button list items) to the Previously Recorded screen really helps when you have 15K oldrecorded items. . . . gs_v13.patch
[13:34:58] j-rod|afk is now known as j-rod
[13:35:48] j-rod is now known as j-rod|afk
[13:35:50] j-rod|afk is now known as j-rod
[13:37:33] jya_ (jya_!~jyavenard@ has joined #mythtv
[13:37:33] jya_ (jya_!~jyavenard@ has quit (Changing host)
[13:37:34] jya_ (jya_!~jyavenard@mythtv/developer/jya) has joined #mythtv
[13:38:01] Captain_Murdoch (Captain_Murdoch!~cpinkham@mythtv/developer/CaptainMurdoch) has joined #mythtv
[13:44:14] zCougar (zCougar!~cougar@2001:67c:32c:600:c1aa:ad5d:3f67:8b35) has quit (Ping timeout: 260 seconds)
[13:53:55] zCougar (zCougar!~cougar@2001:67c:32c:600:81fb:c529:5fc4:f3b5) has joined #mythtv
[13:58:41] jya_ (jya_!~jyavenard@mythtv/developer/jya) has quit (Quit: jya_)
[14:09:32] danielk22: Captain_Murdoch: It looks like we don't update the PBB when we auto-expire shows (at least short livetv ones) is that just a limitation or is it a regression?
[14:18:52] Jordack (Jordack! has joined #mythtv
[14:33:42] gregL (gregL! has joined #mythtv
[14:34:30] zombor (zombor!~zombor_@kohana/developer/zombor) has joined #mythtv
[14:41:06] gigem: danielk22 (or anyone): what's the correct way to pass a qstring between threads. basically, i want a qstring to a queue in one thread and remove it in another thread. according to, the reference counting is thread-safe but other uses still need to be protected. the enqueue/dequeue is already protected by a lock. is it sufficient then to 'detach'
[14:41:08] gigem: the qstring when enqueuing it?
[14:43:15] stichnot: I'm no expert, but I didn't think you even needed detach in Qt4
[14:46:19] cattelan_away is now known as cattelan
[14:55:41] gigem: stichnot: after re-reading the page i referenced, i think you're probably right. i'd feel better about it if the page gave a definition of what it means by 'instance'. i'll still wait for danielk22 to chime in. i need to do some other research before i start slinging the code.
[14:56:30] danielk22: gigem: Starting with Qt4.1 it is safe to pass QStrings between threads without a detach. What you can't do is have two threads modify the same QString (but they can modify their own copies).
[14:57:22] stichnot: danielk22: is that because the shared data is automatically detached?
[14:57:33] danielk22: yep
[14:58:12] danielk22: This was supposed to happen in Qt3 and Qt4.0 too, but their reference counting wasn't as atomic as they thought it was.
[15:03:59] danielk22: It's all very complicated under the hood, but the basic idea is that the QString has a pointer to to reference counted data. When a mutating function is called if the reference count is 1 it modifies that data, if not it copies the data & decrements the reference count and then modifies the copy of the data which as a new copy will have a reference count of 1.
[15:04:54] gigem: danielk22: thanks.
[15:05:05] stichnot (stichnot!~chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds)
[15:06:21] gigem: wagnerrp: (i think it was you, but it might have been Beirdo) ^^^ the above means we no longer need that hostname locking i was concerned about a few weeks ago.
[15:09:41] ** wagnerrp looks to see what gigem is referring to **
[15:10:57] wagnerrp: if it was me, i dont remember the discussion several weeks ago
[15:14:36] danielk22: gigem: I don't know the background, but if it is a m_hostname that can be modified after the constructor is called then you still need locking for the GetHostName() function as a copy made while the string is being mutated in another thread isn't safe. (the reference count of m_hostname would be 1 during the mutation).
[15:16:51] danielk22: class X { QString s; X::X(): s("b") {} void m() { s[0]='a'; } QString getS() { return s; }}; <-- not thread-safe.
[15:19:54] gigem: wagnerrp: see commit a0c9d003.
[15:20:43] gigem: danielk22: yeah, it was with the local and master host names in MythCoreContext. i didn't know we allowed those to change while we are running. if so, then, yead, we still need some locking.
[15:21:19] wagnerrp: ah
[15:34:36] seeker (seeker!~seeker@unaffiliated/seeker) has joined #mythtv
[15:51:22] seeker (seeker!~seeker@unaffiliated/seeker) has quit (Quit: Colloquy for iPhone -
[15:51:52] seeker (seeker!~seeker@unaffiliated/seeker) has joined #mythtv
[16:05:13] cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has quit (Ping timeout: 249 seconds)
[16:44:45] stichnot (stichnot!chatzilla@mythtv/developer/stichnot) has joined #mythtv
[16:53:42] cesman (cesman!~cesman@pdpc/supporter/professional/cesman) has joined #mythtv
[17:05:02] xris: danielk22: rebuilt mythtv master a couple days ago
[17:05:20] xris: I tried to find it in the code, too.. I assume it's a manufactured string, but couldn't find much by searching on partials, either
[17:05:57] xris: may need to turn on verbose logging. at least I know how to replicate *and* fix it now, so I can get more details if you want to dig into it
[17:16:46] seeker (seeker!~seeker@unaffiliated/seeker) has quit (Read error: Connection reset by peer)
[17:23:06] stuartm: danielk22: does the auto-expirer not use the same delete code as 'normal' deletes and therefore not send delete events?
[17:23:56] danielk22: stuartm: I would assume it uses the same delete code. AFAIK Only the list construction is different.
[17:25:27] stuartm: should be an easy fix then if we can figure out where it's going wrong
[17:29:18] stichnot: stuartm: yesterday you said: "we can't stop a themer placing a popup over the list, although there is markup to tell it to place the popup above/below/left/right of the list so it doesn't actually matter if the list position changes from one screen to another". I can't find anything like this in the code or docs. Do you have a pointer?
[17:33:46] NightMonkey (NightMonkey!~NightMonk@pdpc/supporter/professional/nightmonkey) has joined #mythtv
[17:35:30] stuartm: stichnot: it's not quite as I described it, seems you can set an absolute position for the search popup in the <buttonlist> definition, the syntax is <searchposition>x,y</searchposition>
[17:36:11] stichnot: ok, thanks.
[17:37:30] stuartm: same result, you can change the popup position on a list by list basis, moving it somewhere where it won't obscure the important stuff
[17:37:47] Beirdo: of course, if you wanna be extra careful that QString can't bugger you, can always queue char *
[17:46:18] sphery: superm1 / tgm4883 / mrand : just wanted to mention that it would be nice for apport to pull the right log files for "other" MythTV apps (rather than mythbackend.log for a mythtranscode crash--as at ). Before, mythbackend.log may have had the right stuff when mixed in child process log output with other, but with 0.25+, we'd have the log output in the right place. Not super important--we can ...
[17:46:24] sphery: ... always ask for logs--but something that would be nice if you guys get time to fix it.
[17:48:27] Beirdo: OK, guys...
[17:48:41] Beirdo: we have a week and a half to final release (as scheduled)
[17:48:50] Beirdo: we have 45 open tickets against 0.25
[17:49:02] Beirdo: that does not compute.
[17:50:09] stuartm: not enough people actively fixing bugs for 0.25
[17:50:11] Beirdo: we had a lot less, but some got retargeted to 0.25, even with no owner. :)
[17:50:39] Beirdo: agreed
[17:52:04] Beirdo: could we all please go through the bugs targeted for 0.25 and check if any should be punted so we can get a good idea of how close we really are?
[17:53:02] stuartm: tickets were re-targetted for 0.25 because a) They should be easy to fix b) They were serious enough that they really need fixing for 0.25
[17:53:39] Beirdo: yeah ;) I realize that. but if nobody's gonna fix em...
[17:54:09] stuartm: ... we don't release?
[17:54:12] Beirdo: I'll be looking through the unclaimed ones to see if there aren't some bugs I can squash fairly quickly
[17:54:53] Beirdo: I think someone would have to give a good reason why a particular bug is a blocker before we can consider blocking the release
[17:55:06] Beirdo: and if one IS a blocker, we should all be working on it
[17:55:59] Beirdo: a lot of these are "minor"
[17:56:24] stuartm: with the number of devs we have active, it's less than 3 bugs each, 4 days to spend on each one ... most shouldn't take more than an evening
[17:56:40] Beirdo: yup
[17:58:08] Beirdo: YAY
[17:58:10] Beirdo: one gone
[17:58:13] stuartm: Beirdo: it's always the minor bugs that get pushed indefinitely, I'm not saying it should be this release but a firm line needs to be drawn somewhere – bug fixing isn't as fun as new features but it's not asking much for everyone to give over a few hours to it
[17:58:28] Beirdo: #10405 was "this now works for me, thanks", but not closed
[17:58:46] Beirdo: heh, for some of us, bug fixing is actually fun :)
[17:58:57] Beirdo: but I hear ya
[17:59:05] stuartm: yeah, it can be, but I know some people aren't so keen ;)
[17:59:34] Beirdo: realistically though, if someone's sitting on a ticket that could block us, prepare to fix your bug, or to relinquish it to someone who will.
[18:00:15] Beirdo: we have 2 critical, a few major, and a metric buttload of minor
[18:01:07] stuartm: !svn 20523
[18:01:07] MythLogBot: SVN 20523: (branch master)
[18:27:54] stichnot: can we push tralph's #10104 to 0.26? that ain't happening for 0.25
[18:28:43] stichnot: any fix to #6974 is surely going to be too risky for 0.25
[18:34:40] sphery: yeah, #6974 should get pushed--especially as it's only a small bit of data that's not played (like whatever's buffered when we hit EOF, as I understand it)
[18:34:41] stuartm: "Opened 3 years ago" – let's just close it as "Won't fix"
[18:35:09] sphery: pushd to 0.26, that is, not to git :)
[18:42:04] wagnerrp: Beirdo: re 10405, the user reported their backend was no longer self-terminating, and triggering the bug
[18:42:13] wagnerrp: as far as we know, the bug is still there
[18:42:24] superm1: sphery: oh good call. yeah that can easily be fixed
[18:42:35] wagnerrp: although since it would only occur during teardown, i wouldnt classify it as a blocker
[18:42:45] wagnerrp: and ive not heard any additional reports of it
[18:44:12] sphery: superm1: thanks
[18:45:23] Beirdo: right, he said the bug can be closed as what he reported is fixed.
[18:45:34] Beirdo: the bug still can be around in other ways
[18:45:45] wagnerrp: right, except the bug wasnt fixed, merely hidden, so i kept it open
[18:45:57] wagnerrp: or rather, i dont know if the bug still exists
[18:46:15] wagnerrp: well, if youre trying to clean things up for release, i dont have any significant issue with it
[18:46:23] wagnerrp: if anyone is still experiencing it, they can open a new one
[18:46:28] Beirdo: well, feel free to reopen, but please not as a blocker for 0.25 :)
[18:46:37] Beirdo: unless it IS one :)
[18:50:10] stoffel (stoffel! has joined #mythtv
[18:54:15] superm1: sphery: ok i set it to capture anything in there that ends in '.log'. hopefully that will avoid rotated logs and such ( . . . evision/532)
[19:37:12] foxbuntu (foxbuntu!~foxbuntu@ubuntu/member/foxbuntu) has quit (Ping timeout: 265 seconds)
[19:44:25] stichnot: looks like something that may have been fixed by jya's audio overhaul. should we assign it to him?
[19:45:41] knightr_ (knightr_! has quit (Read error: Operation timed out)
[19:55:24] stichnot: !svn 26513
[19:55:24] MythLogBot: SVN 26513: (branch master)
[19:55:38] knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv
[20:11:08] knightr_ (knightr_! has joined #mythtv
[20:14:30] knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Ping timeout: 252 seconds)
[20:15:43] knightr_ (knightr_! has quit (Ping timeout: 252 seconds)
[20:17:12] stoffel (stoffel! has quit (Remote host closed the connection)
[20:19:19] joki (joki! has quit (Ping timeout: 264 seconds)
[20:19:26] joki- (joki-! has joined #mythtv
[20:19:40] joki- is now known as joki
[20:20:50] stichnot: For the various video playback crashes/bugs, where the cause is not clear from the logs and stack traces, is it reasonable to ask or require the reporter to provide a link to a ~50MB sample that exhibits the problem?
[20:24:07] J-LAW (J-LAW! has quit ()
[20:33:13] Jordack (Jordack! has quit ()
[20:46:57] danielk22: stichnot: Yes, but you may not get it. I've found that you need to tell them how to extract a sample and where to upload unless you are dealing with a developer.
[20:49:52] danielk22: stichnot: If something looks like it is audio I usually push it to jya. He will know if it is something to close better than me.
[20:55:43] gigem: Beirdo: can you or someone else add a milestone of 0.25-fixes? i pushed #10482 to 0.26, but i actually intended to defer it until -fixes.
[20:56:39] stuartm: might be worth distributing a script which wraps dd and will take a recording or video title as an argument to grab a small of a set size? make it as simple as possible for the user to comply with a request for a sample?
[20:57:42] stuartm: You could even have it automatically upload the sample to our server via ftp (one way, public upload, no public downloads)
[20:59:29] stichnot: stuartm: that would be a great idea. another thing is to get the sample inserted into mythvideo so that the user can verify that the sample triggers the same problem.
[21:10:13] TheAsp: Daniel, re that ticket... yeah I don't care.  :)
[21:12:30] stuartm: stichnot: might be sufficient to have the script run mythavtest on the resulting sample
[21:12:55] stichnot: yes. I forgot about that.
[21:13:37] stichnot: the biggest problem might be the lack of a seektable
[21:15:14] stichnot: but presumably only if the bug is related to seeking
[21:22:33] gast (gast!bcc294ec@gateway/web/freenode/ip. has joined #mythtv
[21:28:46] gast (gast!bcc294ec@gateway/web/freenode/ip. has quit (Ping timeout: 245 seconds)
[21:29:37] peitolm (peitolm! has quit (Changing host)
[21:29:37] peitolm (peitolm!~moreyc@unaffiliated/peitolm) has joined #mythtv
[21:29:53] mrand: Requesting video samples 11 months later? *sigh*
[21:30:14] danielk22 (danielk22!~danielk@ has left #mythtv ()
[21:31:07] j-rod is now known as j-rod|afk
[21:31:49] skd5aner: better than 4 years later (I've been on that end of the stick)
[21:32:05] stichnot_ (stichnot_!chatzilla@mythtv/developer/stichnot) has joined #mythtv
[21:32:58] danielk22 (danielk22!~danielk@ has joined #mythtv
[21:33:38] stichnot (stichnot!chatzilla@mythtv/developer/stichnot) has quit (Ping timeout: 246 seconds)
[21:33:46] stichnot_ is now known as stichnot
[21:38:13] stichnot: mrand: sorry, I guess it's the nature of last-minute bug "clearing" before the release
[21:38:51] stichnot: but I hope you still have the file around
[21:41:30] mrand: stichnot: I don't see it immediately, but I rearranged some stuff after adding a disk, so perhaps I stashed it somewhere. What would be helpful is if there was some place to upload samples that didn't go away... then trac could actively encourage people to provide samples.
[21:42:47] mrand: (like attaching it directly to the trac ticket)
[21:43:06] knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv
[21:43:34] stichnot: yeah, that would be good. I usually use Google Documents, which gives ample space with a (free) gmail account, and doesn't make anyone "sign up" to download the document
[21:44:40] stichnot: in many cases, the logs and/or stack traces make it obvious without a sample, so providing a sample should only be on request.
[21:44:46] MaverickTech (MaverickTech! has joined #mythtv
[21:46:39] MavT (MavT! has quit (Ping timeout: 260 seconds)
[21:47:38] superm1: mrand: if you put in dropbox and just keep it shared publicly maybe?
[21:48:19] mrand: I'd rather just upload it to trac ;-)
[21:48:54] superm1: yeah
[21:49:08] stuartm: stichnot: last time someone around here used Google Documents it required people to sign up just to download ...
[21:50:22] stichnot: stuartm: really? I'm 99.98% sure you can make the privacy setting visible to anyone, though that's not the default setting
[21:53:17] stuartm: mrand: the problem with trac is that it lacks any sort of tools to cleanup old attachments, a few years of samples and we'd be have some space issues :)
[21:53:55] stuartm: at least with an ftp/other upload space we can easily delete samples once we've finished with them
[21:55:05] stuartm: still, if we could find a trac plugin which made cleanups, even automated cleanups possible then it would be seriously considered
[21:55:45] stuartm: I might just increase the upload limit again since I'm tired of people compressing logs
[21:56:29] stichnot: stuartm: example: in June 2011 I provided this link in a ticket. It doesn't require signin. . . . t&num=50
[21:58:32] stuartm: hmm, that url doesn't work here, opera just shows a circular redirection error
[21:59:35] stuartm: the page it's trying to redirect to is
[22:00:12] stuartm: ah well, probably doesn't like the fact that I've got google cookies blocked or some thing
[22:00:23] stichnot: ah. yuck.
[22:00:53] stichnot: so yeah, write-only upload to trac would definitely be nice :)
[22:01:44] zombor (zombor!~zombor_@kohana/developer/zombor) has quit (Remote host closed the connection)
[22:12:36] stuartm: xavierh: looks like a typo in your Terra patch? mythtv/themes/Terra/schedule-ui.xml:400: element buttonlist: Schemas validity error : Element 'buttonlist', attribute 'from2': The attribute 'from2' is not allowed.
[22:15:14] mzanetti (mzanetti! has quit (Ping timeout: 260 seconds)
[22:16:49] mzanetti (mzanetti! has joined #mythtv
[23:12:43] taylorr (taylorr! has joined #mythtv
[23:12:51] taylorr (taylorr! has quit (Changing host)
[23:12:51] taylorr (taylorr!~taylorr@unaffiliated/elmojo) has joined #mythtv
[23:50:03] ** knightr says grrr... **
[23:50:13] Beirdo: WTF?
[23:50:51] knightr: Beirdo, if you're asking me that question, look at the last commit...
[23:51:10] Beirdo: second to last. :) and it was in response to said commit
[23:51:25] Beirdo: last was some whitespace cleanup :)
[23:52:29] Beirdo: I'm sorry, but I'd call that other one a) a feature, b) unnecessary
[23:52:34] knightr: yep, you're right...
[23:53:19] knightr: and thank you for having the same reaction I did...
[23:53:29] Beirdo: :)
[23:53:47] Beirdo: I want to see that reverted, personally. It can go in after release
[23:54:37] knightr: that would make sense especially since Danielk can apply it himself (I doubt he uses packages...)
[23:55:30] Beirdo: yeah, or sure
[23:55:42] Beirdo: message sent to -developers.
[23:56:33] knightr: thanks!
[23:56:51] Beirdo: I thought I was very clear last week that this kinda thing shouldn't be happening.
[23:56:58] Beirdo: no problemo.
[23:58:10] dekarl: please keep fingers crossed for me... PESPacket/PSIPTable separation is compiling now
[23:58:42] Beirdo: cool :)
[23:59:57] dekarl: hopefully a minimal patch, but still 300 lines patch :(

IRC Logs collected by BeirdoBot.
Please use the above link to report any bugs.