:: #mythtv

Daily chat history

Current users (80):

aarcane, aloril_, Anssi, Beirdo, brfransen, caelor, Captain_Murdoch, cesman, Chutt, clever, coling, Cougar, danielk22, dblain, dekarl, eharris, ElmerFudd, fetzerch, gary_buhrmaster, ghoti, ghoti_, Gibby, gigem, gregL, GreyFoxx, jams, jarle, jarryd, jheizer, joe_____, johanbr, joki, jpharvey, jst, jwhite, kc, kenni, knightr, kurre2, kwmonroe, laga_, materdaddy, MaverickTech, moparisthebest, mrand, MythBuild, MythLogBot, Nothing4You, peper03, poptix, purserj, rhpot1991, rkulagow, robink, rsiebert, Seeker`, seld_, Sharky112065, skd5aner, sl1ce_1g, SmallR2002, sphery, sraue, stichnot, stuarta, stuartm, superm1, taylorr, tgm4883, Tobbe5178, toeb, tonsofpcs, tris, wagnerrp, wahrhaft, wolfgang4, XDS2010, xris, _charly_, _nyloc_
Wednesday, October 2nd, 2013, 00:01 UTC
[00:01:44] dekarl1 (dekarl1! has joined #mythtv
[00:04:11] dekarl (dekarl! has quit (Ping timeout: 248 seconds)
[00:13:28] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds)
[00:19:03] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[00:46:48] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[01:04:02] nyloc (nyloc! has quit (Remote host closed the connection)
[01:04:11] nyloc (nyloc! has joined #mythtv
[01:18:51] drrngrvy (drrngrvy! has quit (Ping timeout: 260 seconds)
[01:32:08] gigem (gigem!~david@mythtv/developer/gigem) has quit (Quit: WeeChat 0.4.1)
[01:33:23] gigem (gigem! has joined #mythtv
[01:33:24] gigem (gigem! has quit (Changing host)
[01:33:24] gigem (gigem!~david@mythtv/developer/gigem) has joined #mythtv
[01:36:35] gigem: skd5aner: The patch just turns on extra debugging when the scheduler tries to schedule around live TV. This should tell us if the scheduler is doing the right thing or not.
[01:57:42] NightMonkey (NightMonkey!~NightrMon@pdpc/supporter/professional/nightmonkey) has quit (Quit: Body blow! Body blow!)
[02:04:11] allesmueller__ (allesmueller__! has quit (Ping timeout: 248 seconds)
[02:08:58] allesmueller (allesmueller! has joined #mythtv
[02:08:58] allesmueller (allesmueller!~N@unixboard/users/allesmueller) has joined #mythtv
[02:08:58] allesmueller (allesmueller! has quit (Changing host)
[02:13:57] jya: stuartm: so I have the frontend showing up on the pi, without x11 running... i only get to see something using the qt painter though.... with the OpenGL or OpenGL 2 painter, i only get a white screen
[02:16:16] _nyloc_ (_nyloc_! has joined #mythtv
[02:18:08] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Remote host closed the connection)
[02:20:39] nyloc (nyloc! has quit (Ping timeout: 252 seconds)
[02:24:45] rkulagow (rkulagow!45f6d03f@gateway/web/freenode/ip. has joined #mythtv
[02:25:02] rkulagow: howdy.
[02:25:16] rkulagow: did i miss a memo about
[02:26:31] rkulagow: seems to be down at the moment
[02:52:18] joki (joki! has quit (Ping timeout: 264 seconds)
[02:56:59] peper03 (peper03!~peper03@mythtv/developer/peper03) has quit (Ping timeout: 248 seconds)
[02:57:12] joki (joki! has joined #mythtv
[02:57:47] peper03 (peper03!~peper03@mythtv/developer/peper03) has joined #mythtv
[03:00:39] wagnerrp_ is now known as wagnerrp
[03:11:29] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has joined #mythtv
[03:12:00] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[03:13:01] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[03:16:46] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Client Quit)
[03:59:16] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has quit (Ping timeout: 264 seconds)
[04:00:21] fetzerch (fetzerch!~quassel@unaffiliated/fetzerch) has joined #mythtv
[04:08:48] amessina (amessina!~amessina@2001:470:c1dc:7779:d6be:d9ff:fe8d:7c1e) has quit (Quit: Konversation terminated!)
[04:34:56] dekarl1: rkulagow: I was wondering the same yesterday...
[04:35:01] dekarl1 is now known as dekarl
[04:46:45] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[05:56:29] SteveGoodey (SteveGoodey! has joined #mythtv
[06:11:34] SteveGoodey (SteveGoodey! has quit (Quit: Konversation terminated!)
[06:50:04] FabriceMG (FabriceMG!~Thunderbi@ has joined #mythtv
[06:55:41] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[07:05:16] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[07:07:10] jya (jya!~jyavenard@mythtv/developer/jya) has joined #mythtv
[07:26:19] dekarl (dekarl! has quit (Ping timeout: 248 seconds)
[07:31:04] dekarl (dekarl! has joined #mythtv
[07:47:59] purserj (purserj!~purserj@ has quit (Ping timeout: 260 seconds)
[07:59:03] purserj (purserj! has joined #mythtv
[08:36:54] Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:64dc:5319:50b6:b51) has joined #mythtv
[09:36:30] stuartm: dekarl, rkulagow: better?
[09:36:40] stuartm: restarted smoon
[09:36:52] stuarta: does that not autostart?
[09:37:00] stuarta: or did it wedge?
[09:37:29] stuartm: appears as though it deadlocked or something, was running but not responding
[10:07:36] dekarl: stuartm: yup
[10:20:08] ghoti (ghoti! has quit (Ping timeout: 240 seconds)
[10:20:17] ghoti (ghoti! has joined #mythtv
[10:51:29] stuartm: we need to create a README for the server, there's a lot of stuff that I only figured out by searching long and hard, e.g. Who would know that the Smolt daemon is called Smoon, it's only because the first three letters are the same that I took a closer look at it
[10:53:34] stuartm: which reminds me, now that init scripts are passé I need to found out if there is a way of listing the various service names, it was so very simple in the past just to ls /etc/init.d/
[11:09:52] dekarl: initctl list?
[11:10:20] dekarl: or ls /etc/init/*.conf
[11:21:37] jya (jya!~jyavenard@mythtv/developer/jya) has quit (Quit: jya)
[11:32:07] stuarta: systemctl list iirc
[11:34:30] knightr: systemctl list-unit-files --type=service ?
[11:34:47] stuarta: stuartm: but yes, i agree, we need to fully document how all the services on alcor hang together, so if we do have to split them up, we know how and where
[11:38:44] ghoti_ (ghoti_! has joined #mythtv
[12:17:56] stuartm: knightr: thanks, that looks like what I was after
[12:18:49] stuartm: dekarl: not all distros keep the configs in that directory, or even in the same place
[12:32:57] stuarta: i wouldn't mind implementing something like kerberos, so that we could have consistent accounts / passwords across all server /trac etc...
[12:35:21] stuartm: it would be nice if trac would remember me across browser sessions, probably a plugin for that
[13:06:05] Jordack (Jordack! has joined #mythtv
[13:17:17] dekarl: hmm, "lock after X months of inactivity" would be nice, too :) Last time I search I didn't find anything though
[13:17:26] dekarl: ^- wrt trac tickets
[13:19:20] dekarl: hm, the fixes to the hardware_profiler resulted in more instead of less Unknown :(
[13:19:42] dekarl: ^- wrt MythTV Version/Branch in smolt
[13:20:28] dekarl: well, maybe
[13:21:23] drrngrvy (drrngrvy! has joined #mythtv
[13:40:25] stichnot: Woo-hoo, new 4TB drive in the production system makes 13TB total!
[13:53:13] stuartm: you don't need all that, surely? I can make some room here ...
[13:54:27] stuartm: dekarl: strange – from 0.27 all builds, even exported ones should be producing something better than 'Unknown' in --version output
[13:54:43] stuartm: maybe I should backport those changes to 0.26 and 0.25
[14:00:07] superm1: stuartm: maybe one of the packagers is checking out from git but not getting that version thing because they build a tarball or don't have .git during build or something?
[14:00:18] superm1: i know we had to go above and beyond for deb packages to make it work right
[14:01:36] stuartm: superm1: the changes I made specifically ensure we get a version string even on exported or tarball builds — but it would still fail if the packager was doing something stupid like manually deleting the .git folders instead of exporting
[14:02:40] superm1: that's what we were doing because of the way it had to be organized, wouldn't be too surprising if others were
[14:08:19] stuartm: well the only step left to take would be to prevent it building if a properly formatted version string was missing
[14:08:28] stuartm: I'm not sure if we want to take it that far
[14:09:39] stuartm: superm1: I'm surprised that the Ubuntu build system doesn't account for all those projects using GIT which would be similarly unable to populate version strings correctly
[14:09:41] stuarta: alternatively, use the protocol version if we can't work out the version number? or something else like that
[14:10:27] stuartm: protocol version doesn't tell us much, it may not even change between releases and certainly won't in a stable release
[14:11:13] stuartm: the last ditch fallback is the VERSION file, which is updated before each release, but apparently some builds are managing to strip even that
[14:12:24] stuartm: that would at least give us the 0.27, 0.26.3 or whatever in the Smolt stats – even if that's not really specific enough for debugging purposes
[14:20:18] Merlin83b: Oh, smolt is being retired!
[14:20:36] Merlin83b: Always interesting to slick through the stats.
[14:23:02] stuartm: is it?
[14:23:35] Merlin83b: It is:
[14:23:46] Merlin83b: In about 4 weeks.
[14:27:59] dekarl: Smolt is being retired without a replacement (at least the last time I looked into it)
[14:28:50] dekarl: or has anybody seen this "Census" yet?
[14:30:27] Merlin83b: That wiki page hasn't been updated since January, and the census trac seems empty.
[14:31:48] drrngrvy (drrngrvy! has quit (Ping timeout: 240 seconds)
[14:35:11] drrngrvy (drrngrvy! has joined #mythtv
[14:36:04] stuarta: it doesn't really matter if they retire smolt. it still works for out purposes
[14:36:17] stuarta: *our
[14:41:09] Merlin83b: I didn't know if there was a dependence on some server outside Myth's control.
[14:41:24] stuarta: nope, we control it end to end
[14:41:32] Merlin83b: Good good :)
[14:42:23] moparisthebest (moparisthebest! has joined #mythtv
[14:46:22] stuartm: I'm still waiting for the stats to be turned into pretty graphs, power point presentations and conference calls lasting half a day
[14:47:48] gary_buhrmaster: stuartm: It will be a mandatory all-hands discussion, where participation will be measured for input into your evaluation :-)
[14:47:56] drrngrvy (drrngrvy! has quit (Ping timeout: 245 seconds)
[14:50:06] stuartm: if I contribute zzZZ to the debate, can I expect to retain my end of year bonus?
[14:51:33] Merlin83b: I like pretty graphs :)
[14:51:59] gary_buhrmaster: stuartm: Only if you contribute it enthusiastically. Enthusiasm is mandatory.
[14:55:36] dekarl: hey, a simple graph with the adoption rates of 0.26 and 0.27 would be nice after all. Although I prefer to not know what this PowerPoint is that you talk about... Wasn't that a Karaoke Player?
[14:57:47] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds)
[14:58:05] gary_buhrmaster: dekarl: The karaoke player will be used for the mandatory company sing-along.
[14:58:33] stuarta: powerpoint?? meh, gnuplot!
[14:58:48] dekarl: never heard of gnuplot karaoke
[15:00:42] Merlin83b: According to smolt, the adoptions rates are very low. I don't know of another data source, or I'd be happy to produce the pretty graphs!
[15:01:03] gigem: dekarl: Thanks for stepping in in the record weekly thread while I slept. Some users really don't understand the intent of that rule type.
[15:01:14] dekarl: What is so great about weekly recordings that the radio times users want to use it, too? Is that some variant of a bike shed where everyone thinkgs they understand "weekly" but have a hard time figuring out what "duplicate detection" voodoo is?
[15:01:37] gary_buhrmaster: stuarta: Hand created ascii art.
[15:02:40] dekarl: gigem, thanks for adding the new location for the poor NZ users who must fly under the eye in the NZ Sky :(
[15:04:11] dekarl: although I wonder why the NZ crowd has not adopted the AU grabber solution
[15:04:53] gigem: I don't know (about the radio times users). FWIW, if I had the guide data I have now back then, record weekly and daily would have never been invented.
[15:05:29] stuartm: git can be so f'ng dumb sometimes – can't unstash changes to my working tree because "Your local changes to the following files would be overwritten by merge"
[15:06:14] stuartm: that's NOT a merge then, and it's stupid because the changes aren't even close the ones I'm asking to be merged, two entirely different parts of the file
[15:06:38] ** stuarta hands stuartm quilt **
[15:08:20] stuartm: couldn't get along with quilt because it assumes a linear order to patches, i.e. patch C must be applied on top of patch B and you can't just skip both of those to apply patch A
[15:09:03] stuartm: git stash, when it's not being a royal pain, at least allows you to unstash unrelated patches in whatever order you want
[15:09:08] stuarta: well you can... vi patches/series, find C & B, insert #, quilt push
[15:09:44] stuarta: :)
[15:10:42] gigem: dekarl: I don't understand your comment with the :(. It really isn't, well shouldn't be, that hard to quickly create a simple, title only custom search rule. Just press MENU and choose custom edit. Hmm, after trying it, it seems the EPG is missing some functionality that other screens like ProgLister and ProgFinder have. I'll have to fix that and see if it can be backported to 0.27 without adding new
[15:10:44] gigem: strings.
[15:12:52] stuartm: those screens were meant to be pretty much identical when it came to scheduling, hence why I created the ScheduleCommon base class
[15:12:58] skd5aner: hey guys, quick question... ever week or two, mythfrontend tells me there's No Recordings Available. When I go to look on the backend server, mythbackend is running at 100% on 2/4 cores...
[15:13:36] skd5aner: what's the best way to capture what's going on? Can I attach to the PID and do a backtrace?
[15:15:39] dekarl: gigem: two parts. a) thanks for pointing at the new location b) the situation in NZ is not funny due to the piheaded fellows from Sky
[15:16:02] stuarta: skd5aner: you can use gcore to make it dump core for future analysis
[15:16:26] stuarta: skd5aner: and yes you can also attach to it with gdb to find out what is happening
[15:16:26] skd5aner: stuarta: it's completely random and I have no clue how to trigger it...
[15:16:28] gigem: stuartm: Yeah, I know. Something strange is [not] happening for me. I don't get any popup menu at all when I press MENU in the EPG.
[15:16:53] skd5aner: stuarta: so, now that it's in it's current state, I'd like to grab whatever I can that'd be useful to troubleshoot
[15:18:16] stuarta: skd5aner: so attach gdb, and do `thread apply all bt full`; `detach`; `quit`
[15:18:18] skd5aner: damn, it just fixed itself after 20 mins
[15:18:24] skd5aner: missed it :(
[15:18:24] stuarta: doh
[15:18:40] skd5aner: stuarta: yea, I'll be more prepared next time it happens
[15:18:58] skd5aner: 95% of the time my wife is trying to watch TV and I don't have time to troubleshoot, I just have to get it fixed :)
[15:19:15] skd5aner: this time, I just walked in the door, and saw the problem and thought that I'd give it look
[15:19:21] stuarta: skd5aner: gcore then
[15:19:51] skd5aner: stuarta: I'm familiar with gdb, but I've never used gcore... any link you could provide me to get me up to speed on how to use it?
[15:19:52] stuarta: at least that way you then have a core file, and a matching binary, and you can debug at leisure
[15:20:01] stuarta: lemme see what i can find
[15:20:04] skd5aner: ty
[15:20:07] gigem: dekarl: Okay. Thanks. I do empathize with those with really bad guide data, but they need to realize they are the exception and any work-arounds they may need don't need to be front and center for everyone else.
[15:21:22] stuarta: skd5aner: usage: gcore [-o filename] pid
[15:21:35] stuartm: git stash show -u | patch -p1
[15:21:50] skd5aner: stuarta: thanks, I'll take a look
[15:22:03] skd5aner: stuarta: I did notice multiple PIDs
[15:22:13] stuarta: try to find the parent pid
[15:22:29] skd5aner: I'm assuming that when it threads it'll create a new PID, but it'll all wrap up to an original PID
[15:22:58] stuarta: skd5aner: no a new thread gets a new TID, but the PID stays the same
[15:23:09] skd5aner: oh, ok
[15:23:28] stuarta: lemme pastebin you some foo
[15:23:46] skd5aner: I was just looking in htop and noticed different PIDs for mythbackend running at 100% on a couple cores at the time
[15:30:54] stuarta: i may be imagining things
[15:42:48] clever: under linux, each thread kinda gets its own pid, but its not visible in the main pid list
[15:43:12] clever: ls /proc/rootpid/task/ will list this kinda-pid for every thread in the rootpid
[15:44:06] clever: strace can be used to trace a single thread, and kill can be used to fire signals to just one
[15:50:43] clever: top will also list that number under the PID column if you hit H (which switches it to thread mode)
[15:56:58] FabriceMG (FabriceMG!~Thunderbi@ has quit (Quit: FabriceMG)
[15:59:07] stuarta: clever: it's called a TID :)
[16:00:02] stuarta: clever: strace will also happily trace threads
[16:00:06] stuarta: you just have to ask it
[16:01:42] stuarta: strace -vftT -o <logfile> <cmd> is my favourite
[16:05:00] clever: that only works if you can start it via strace
[16:05:13] clever: i sometimes want to trace a thread in something like mythbackend, after its already started
[16:05:39] clever: top in thread mode reveals the id, then strace -p id# lets me trace just that thread on demand
[16:05:40] stuarta: yeah, in that situation, you would have to strace the thread
[16:06:04] clever: its also usefull with php-fpm is being naughty and refusing to log errors
[16:06:20] clever: get the raw errno directly from the syscall!
[16:07:56] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[16:08:28] stuarta: surely not!
[16:08:34] ** stuarta likes php-fpm **
[16:09:03] clever: ive found it tricky to get it to log to the right spot
[16:09:21] clever: sometimes it shows up in the lighttpd error.log, sometimes in its own php log, sometimes syslog, and sometimes nowhere at all
[16:09:35] stuarta: that's upsetting
[16:10:14] clever: i think its a matter of what ubuntu and gentoo default to, and how they differ
[16:11:56] clever: while i'm here, is there anything i should add to this page?, ive currently hit a dead-end with the conditional access stuff,
[16:17:35] knightr: stuartm, you are welcome (4 hours later :) )...
[16:18:03] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds)
[16:19:03] knightr: stuartm, I don't know if you saw that so just in case I am reiterating my offer:
[16:19:08] knightr: <knightr> stuartm, if you mean help to convert to mythui I could try it, I had looked at his patches and it *seemed* to be relatively straightforward to do. It would also have the advantage that I would learn more how the UI works...
[16:20:51] stuartm: knightr: thanks, I'd definitely appreciate help, there's a lot I want to do for this cycle and only so much time available – I know Paul was interested in getting this done and there may be others with UI experience who can contribute some of their time
[16:21:52] stuartm: the patches only need work so that they can be applied to master, they were apparently feature-complete but since they are several months old they conflict because of code changes made since then
[16:24:11] stuartm: knightr: just to be clear, the patches convert the settings to mythui, so knowledge of the UI code required is minimal – it's just a question of fixing the bits which don't apply cleanly
[16:24:40] stuartm: time consuming, but hopefully not difficult
[16:40:31] knightr: even if I had to manually reapply some of those patches it would give me a better idea of how it works. I did have the occasion to modify some of the old UI (and maybe some MythUI stuff) to improve their translation or make them translatable and it wasn't very hard to do and we already have the patches as a guide.
[16:41:20] knightr: if at all possible it would be best to commit them as we convert them back to avoid bit rot...
[16:43:41] stuartm: knightr: that's what I'd suggest doing
[16:45:43] knightr: and don't worry about time consuming stuff, I had to put over 4 hours to track down the classes for each of the screens in globalsettings.cpp to cleanup their translation so I don't mind if it improves the situation...
[16:47:32] knightr: (that file should be split or reorganized eventually, it's difficult to track down what some of the settings in there are related to since some of them are not close to where they are actually used...)
[16:48:09] knightr: stuartm, yep, I think that would be best...
[16:53:40] Merlin83b (Merlin83b!~Daniel@2a00:1ee0:3:1337:64dc:5319:50b6:b51) has quit (Quit: Leaving)
[16:53:55] knightr: (over 4 hours is nothing when it comes to programming but I didn't really consider what I was doing to be programming, it was just something that had to be done...)
[16:55:35] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv
[17:03:10] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has joined #mythtv
[18:11:58] rsiebert (rsiebert! has joined #mythtv
[18:14:14] stuartm: sphery, dekarl: can you foresee any problem with using 'MythFillSuggestedRunTime' for xmltv grabbers by simply taking the start/end time of the last run and adding 24 hours?
[18:16:44] dekarl: hmm, need to look into the current logic. isn't it something like "about once a day" already?
[18:18:18] stuartm: dekarl: yeah, the purpose isn't to force it into that 24 hour cycle which it's already using, but to leverage that existing setting when the backend shuts down to set the wakeup time
[18:19:38] dekarl: Ahh, so it wakes up to update the guide once a day. I see. btw, does if move the update windows around to match a recoring if its close?
[18:19:44] stuartm: currently when the backend shuts down it looks at when the next recording will happen and wakes up then, it won't wake up to grab guide data – it's entirely possible for the backend to _never_ be up when the 'mfdb' window happens
[18:20:27] stuartm: dekarl: not atm, that's something I'd consider but for now I'm keeping it Simple :)
[18:21:53] dekarl: I don't see an issue. Its a hack either way :) Keeping the min/max hours will make it intersting though.
[18:21:54] stuartm: if the run was moved to coincide with a recording (it would have to occur after, not during) then it would always need to be later than normal, not earlier as some guide data sources update just once a day
[18:23:12] stuartm: since mfdb generally tries to run at the quietest possible period (2am-6am), the next scheduled recording is going to be several hours away, so the extra logic might be more hassle than it's really worth
[18:23:19] dekarl: that does not make sense. if the guide source updates once a day, say at noon, and we ran mfdb around 8pm last time. What wrong with running it at 7pm the next time?
[18:24:35] stuartm: dekarl: if it updates at noon, and we run at 12:30 the last time and 11:30 the next ...
[18:24:40] dekarl: hmm, girls are coming home. I think faking up the suggested run time is ok
[18:25:38] stuartm: keeping the time consistent between runs is the best way to ensure that the guide data we get is not what we grabbed the last time
[18:30:21] SteveGoodey (SteveGoodey! has joined #mythtv
[18:33:04] stuartm: thanks for mentioning the mix/max stuff btw, I'd forgotten about that ... makes the solution a little more 'interesting'
[18:34:26] stuartm: can easily normalise the time within those limits, but I'll need to ensure that we update the suggested run time if the user alters either of those settings
[18:41:44] doev (doev! has joined #mythtv
[19:20:21] doev (doev! has quit (Ping timeout: 252 seconds)
[19:25:19] Chutt_ (Chutt_! has joined #mythtv
[19:26:51] Chutt (Chutt! has quit (Ping timeout: 248 seconds)
[19:28:34] warped_ (warped_! has joined #mythtv
[19:37:32] warped_ (warped_! has quit (Remote host closed the connection)
[19:37:53] warped_ (warped_! has joined #mythtv
[19:59:26] warped_ (warped_! has quit (Quit: warped_)
[20:02:51] Chutt_ is now known as Chutt
[20:40:05] jpabq (jpabq!~quassel@mythtv/developer/jpabq) has quit (Remote host closed the connection)
[20:45:37] jpabq (jpabq! has joined #mythtv
[20:45:37] jpabq (jpabq! has quit (Changing host)
[20:45:37] jpabq (jpabq!~quassel@mythtv/developer/jpabq) has joined #mythtv
[20:59:13] Jordack (Jordack! has quit ()
[21:09:07] Steve-Goodey (Steve-Goodey! has joined #mythtv
[21:13:41] superm1: dblain: hmm why is there a debian/ directory in the mythtv/platform/win32/msvc/external/lame directory?
[21:22:54] natanojl (natanojl!~jonatan@mythtv/developer/natanojl) has quit (Ping timeout: 264 seconds)
[21:24:15] SteveGoodey (SteveGoodey! has quit (Ping timeout: 260 seconds)
[21:38:14] Guest59384 (Guest59384! has quit (Ping timeout: 240 seconds)
[22:02:16] Steve-Goodey (Steve-Goodey! has quit (Quit: Konversation terminated!)
[22:09:18] dblain: superm1: The external directory includes all the source needed for the various dependencies. I kept all files that were part of any particular library.
[22:10:02] dblain: most libraries can compile to multiple platforms (even though I'm only compiling for windows)
[22:10:10] doev (doev! has joined #mythtv
[22:10:11] superm1: dblain: could you remove the debian/ directory from it though? it should only be needed for building on debian right? it's freaking out the build for us
[22:10:56] dblain: I can, but would need to read the copying file first to make sure it's okay per the license.
[22:11:47] dblain: why would the packager even look that deep into the directory structure. The high level directory is win32
[22:12:12] superm1: it's because when our tarball gets built it automatically excludes any directories named debian/
[22:12:26] superm1: so it gets confused when it finds something in git named debian/
[22:12:49] superm1:
[22:13:25] superm1: if you can take it out, that would simplify things immensely, but if you're not able to i'll keep trying to find another way to not freak out the build
[22:14:20] dblain: I'll see what can be done, but I won't be able to look at it for a few hours.
[22:14:25] superm1: ok, thanks
[22:22:52] dblain: took a minute to look at the lic. it's GPLv2. Anyone familiar with the license enough to know if removing a subdirectory from the source is allowed?
[22:23:47] stuartm: can do pretty much whatever you want so long as you supply a copy of the license and the source code
[22:24:47] stuartm: even then, you only have to do the latter on request (but you're covered since it's in a publicly accessible git repo)
[22:24:49] dblain: but isn't excluding a directory of the source not supplying the source? I don't care either way, just don't want to cause issues for anyone
[22:25:25] dblain: ok, so should be safe to only keep the files needed for windows in the mythtv repository.?
[22:25:29] stuartm: dblain: no, you only have to provided your modified copy of the source, not the work you derived it from
[22:26:18] dblain: wish there was an easier way... I hated including the source in our repo, but wanted to make it as easy as possible for people to compile on windows.
[22:26:37] dblain: stuartm: thanks
[22:26:37] stuartm: so removing code, removing whole directories is permissible under the license if you are not using them
[22:27:24] stuartm: you'd only be in breach if you remove code from the distributed source that was compiled into your application
[22:28:03] dblain: makes sense.
[22:34:50] stuartm: that detail has caught out a few companies in the past, they released source code minus files pertaining to particular features and thought no-one would notice, but someone with a lot of time on the hands was able to go through and disassemble the binary to determine that it contained instructions for which no corresponding code was supplied
[22:39:06] doev (doev! has quit (Ping timeout: 264 seconds)
[22:41:25] materdaddy (materdaddy! has joined #mythtv
[23:31:07] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has quit (Ping timeout: 260 seconds)
[23:35:13] dblain: superm1: found a few minutes to push the deletes. Let me know if you need something else.
[23:55:10] stichnot (stichnot!~stichnot@mythtv/developer/stichnot) has joined #mythtv

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