| Wednesday, January 5th, 2011, 00:00 UTC | ||
| [00:00:34] | jannau: | xris: with a raid partition it's just annoying but with luks the only storage of the key is lost |
| [00:01:27] | jannau: | I'm pretty sure I made a backup of the header but I can't find it |
| [00:01:28] | danielk22: | Yeah.. It's a reinstall that overwrites the system directories. It's supposed to leave non-system stuff alone.. Which is true of all users except the primary user. |
| [00:02:08] | danielk22: | Chutt: It did come with big warnings to do a backup, but upgrades alway do that.... |
| [00:02:08] | stuartm: | jannau: that truly sucks and you have my sympathy |
| [00:02:12] | xris: | jannau: no, it decided to reformat. it saved the data on the md* raid partitions, but overwrote the sd* headers as if it was a blank array. |
| [00:03:05] | xris: | stuartm: if you don't get to the github svn stuff by next week, I'll try to take a look at it when I get back from CES |
| [00:03:13] | Chutt: | heh, ces |
| [00:03:17] | Chutt: | go see all the tablets |
| [00:03:37] | Beirdo: | heh. I already have mine... nook color... rooted. |
| [00:03:38] | xris: | hey, you're supposed to be there, too. :P |
| [00:03:44] | Chutt: | no way |
| [00:03:56] | stuartm: | danielk22: I don't think in all the time I've used mandriva that it's _ever_ touched the home directory (new configs aside) on an upgrade or reinstall, whether that's an online upgrade or via the CD |
| [00:03:57] | Chutt: | if i were to go to ces, i'd have to be doing work stuff |
| [00:04:06] | xris: | supposed to be our face-to-face board meeting for good karma. |
| [00:04:11] | Chutt: | yeah, yeah |
| [00:04:20] | stuartm: | danielk22: I would have thought that was just common sense and applied to all distros |
| [00:04:25] | xris: | and booze-drinking for camaraderie. |
| [00:04:37] | jannau: | Beirdo: I'll be around and will answer to questions but don't expect any answers to mailing list mails. I haven't read them since before christmas |
| [00:05:07] | Beirdo: | jannau: fair enough. |
| [00:05:40] | Beirdo: | kick Canonical in the head :) |
| [00:05:53] | stuartm: | there is simply no hope that I could ever backup all of my data, I prioritise the stuff that I'd miss most but I cannot afford to buy twice as many drives and start mirroring the lot |
| [00:05:57] | jannau: | I contemplated suing Mark personally |
| [00:06:05] | danielk22: | stuartm: yeah, it's a bug. Mario asked me to report it. I had full intentions of doing so until other priorities intervened. |
| [00:07:29] | xris: | stuartm: I back up the important stuff (HUGE stack of DVDs via dar), but mostly just try to mirror everything of mediocre importance. |
| [00:08:05] | danielk22: | jannau: Will you still be contributing to ffmpeg? Having more practical people over there is a huge win for MythTV... |
| [00:08:52] | jannau: | danielk22: yes, I intend to |
| [00:09:58] | danielk22: | jannau: Well then AFAIC we're not totally losing you :) Although having you here too is even better. |
| [00:10:46] | Beirdo: | jannau: and for ffmpeg resyncs... it would be great to have your help on that if we could. |
| [00:12:07] | danielk22: | Beirdo: heh, don't push it. Those are probably Janne's biggest PITA wrt MythTV. |
| [00:12:22] | Beirdo: | hehe, as I said... if we could :) |
| [00:12:45] | Beirdo: | but if we can't, we'll make it work, just might take significantly longer. |
| [00:14:28] | danielk22: | mpegts.{c,h} is really the remaining killer AFAIK. We no longer support most other MythTV only features like XvMC-VLD. |
| [00:14:40] | jannau: | it is much easier now, most ffmpeg commits apply cleanly against external/FFmpeg |
| [00:15:06] | Beirdo: | cool :) |
| [00:15:48] | danielk22: | I started working on getting ATSC/DVB teletext support into ffmpeg proper some months ago; but it looks like what they like will require significant changes in avformatdecode so it got delayed... |
| [00:16:38] | jannau: | configure is another pita but it's also much easier now |
| [00:17:22] | xris: | danielk22: we just need to transcode everything internally to $CODEC and get rid of mpeg. :) |
| [00:17:31] | jannau: | mpegts.]ch is not that bad since the last two syncs |
| [00:18:10] | jannau: | it's much closer on ffmpeg's and hopefully didn't introduce to much regressions |
| [00:18:30] | stuartm: | jannau: I really hope you are able to continue contributing in future |
| [00:21:14] | danielk22: | jannau: me too :) |
| [00:24:18] | danielk22: | xris: Right, just as the patents final MPEG-2 patents expire we need to switch everything to h.264, quick! ;] |
| [00:24:47] | Beirdo: | hehe |
| [00:25:10] | Beirdo: | that would be just so much fun for OTA recordings too |
| [00:25:15] | Beirdo: | need a supercomputer |
| [00:26:49] | wagnerrp: | danielk22: hey now, didnt thy promise not to go after anyone for that until at least 2016? |
| [00:27:25] | wagnerrp: | i remember the moratorium was about up, and they decided to extend it for another several years |
| [00:28:57] | stuartm: | welcome to my web said the spider to the fly |
| [00:29:05] | Beirdo: | heh |
| [00:29:08] | wagnerrp: | heh |
| [00:29:08] | Beirdo: | BURP |
| [00:29:42] | wagnerrp: | go ahead, use it for free... once you cant turn back well start charging |
| [00:31:05] | stuartm: | didn't one of you guys work for Google at one point? |
| [00:31:24] | stuartm: | or am I mis-remembering? |
| [00:31:55] | abqjp (abqjp!~abqjp@97-119-168-204.albq.qwest.net) has quit (Quit: abqjp) | |
| [00:33:44] | stuartm: | I'll take that as a no ... |
| [00:34:31] | xris: | danielk22: well, I can still hope that vp8 becomes feasible. |
| [00:34:47] | Chutt: | it's going to take a few years before vp8's accelerated in hardware |
| [00:34:51] | xris: | but my main issues with mpg2 are that they don't play on android/ios |
| [00:35:02] | xris: | then again, there are good rumors of a functional vlc client for android.... |
| [00:35:09] | Chutt: | vlc's going to be software codecs |
| [00:35:18] | Chutt: | from what i heard |
| [00:35:22] | xris: | Chutt: not surprising. |
| [00:35:36] | Chutt: | well, software + neon, most likely |
| [00:35:40] | xris: | h.264 gets us into a big patent mess, though. a lot more so if we add encoding. |
| [00:35:50] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 240 seconds) | |
| [00:36:11] | xris: | then again, vp8 could theoretically be no better.. companies claiming that google can't just open source the whole thing |
| [00:36:32] | rooaus: | jannau: From a users point of view I would like to thank you for all you have contributed to MythTV it has been very valuable work and clearly has made MythTV better. It is a pity there is so little we can offer devs back apart from our sincere appreciation. |
| [00:42:12] | stuartm: | right, not exhaustive but I've tested that avfdecoder patch against mp3, ogg, flac, aac, alac, and wma – any other suggested samples/formats? |
| [00:43:24] | knightr (knightr!~knightr@mythtv/developer/knightr) has quit (Ping timeout: 265 seconds) | |
| [00:43:35] | wagnerrp: | rooaus: patches of your own? |
| [00:45:11] | rooaus: | wagnerrp: Good call :) I have done so in the past and hope to do a bit more of that in the future as well. |
| [01:07:16] | Mekon (Mekon!~quassel@host-84-9-39-136.dslgb.com) has quit (Remote host closed the connection) | |
| [01:18:53] | Chutt: | stuarta, raw .aac or .mpa? |
| [01:19:01] | Chutt: | eaac+? |
| [01:19:01] | Chutt: | heh |
| [01:26:01] | stuartm: | I'll just keep collecting samples and throw everything at it ;) |
| [01:27:43] | knightr (knightr!~knightr@mythtv/developer/knightr) has joined #mythtv | |
| [01:27:52] | stuartm: | it's just a lot easier when those samples are long enough and preferably musical – spotting problems such as dropped frames isn't easy in white noise or drum loops |
| [01:28:52] | xris: | stuartm: m4a? |
| [01:28:55] | stuartm: | decent free samples are hard to come by, most of the samples on the ffmpeg server are trimmed down to the couple of KB which triggered a segfault etc |
| [01:30:00] | stuartm: | xris: tried that |
| [01:30:35] | Chutt: | heh |
| [01:31:05] | Chutt: | you did a fairly comprehensive list, i'd think it's safe-ish |
| [01:31:38] | stuartm: | everything I've so far tried has played just fine, but statistically it's a very small sample – I used to have a whole load of samples but I think I must have deleted them after I finished testing the last avfdecoder changes I made |
| [01:32:01] | xris: | stuartm: wasn't in your list so I thought I'd add it just in case. I think I'm about ready to give up apple ever supporting ogg properly. |
| [01:32:04] | j-rod|afk is now known as j-rod | |
| [01:32:21] | ** xris packs up and goes home to pack for CES ** | |
| [01:33:19] | stuartm: | Chutt: if it does break something then someone will squeal :) |
| [01:34:01] | Chutt: | always the best way to test |
| [01:39:11] | stuartm: | it would be nice to build up an official collection of re-distributable samples that can be used for all regression testing of both video and audio, something a little more official than that directory on the server which no-one really uses |
| [01:40:09] | stuartm: | I'm sure that's something that the other media-playing projects would collaborate on |
| [01:40:32] | gigem_ (gigem_!~david@host137.12.intrusion.com) has quit (Ping timeout: 240 seconds) | |
| [01:59:19] | danielk22: | stuartm: I thought ffmpeg already had such a repo, no? |
| [02:03:40] | stuartm: | only tends to contain samples of stuff that breaks ffmpeg and from my experience of looking through it tonight, samples are clipped to be as small as possible, so if you want a 100kb sample of wmv9 that used to cause a segfault in ffmpeg in 2005 then that's the place to look, but it's not going to yield many samples which show playback working without dropping frames or maintaining audio-sync |
| [02:12:38] | stuartm: | I'm day dreaming about something a little more standardised, which can be used in a documented testing procedure – samples of the same length, even better if they show the exact same video but encoded in a wide range of codecs, formats and containers – we'll never have something exactly like that of course but we can aspire to it |
| [02:13:50] | stuartm: | take the BBC samples I've made available before now – good for testing not only playback of mpeg2 and H.264 as broadcast over here, but MHEG, DVB subtitles, audio-description tracks and more |
| [02:16:16] | stuartm: | create a wiki page listing each sample, with screenshots showing what each is supposed to look like for video/mheg/subtitles or describing it in the case of audio. Plus listing what features can be tested using each sample |
| [02:32:14] | ** j-rod eyes 'Encoder 22' on his backend status page... ** | |
| [02:33:08] | wagnerrp: | thats a lot of inputs |
| [02:33:23] | j-rod: | only 14–22 defined |
| [02:33:50] | j-rod: | which is two dvb cards, an hdhomerun and a pvr-250 |
| [02:34:27] | j-rod: | thought I cleared out all cards last time I moved them around |
| [02:34:41] | j-rod: | which used to reset the card counter to 0, I thought |
| [02:34:54] | j-rod: | maybe I done screwy up tho |
| [02:34:56] | wagnerrp: | it does, but only if you do so globally |
| [02:35:05] | wagnerrp: | 'delete all cards on <X host>' does not |
| [02:35:13] | j-rod: | yeah, that's probably what I did |
| [02:39:03] | andreax (andreax!~andreaz@p57B95A2F.dip.t-dialin.net) has joined #mythtv | |
| [02:41:27] | j-rod: | pfsense is really starting to tick me off. effing thing up and decides its dns server doesn't feel like replying randomly. |
| [02:52:22] | j-rod: | jams: I believe you were waiting patiently for 2.6.37? |
| [02:53:17] | j-rod: | seems I'm going to have to submit a number of patches for -stable… |
| [02:54:07] | j-rod: | I see now why lircd isn't working with mceusb and rc5 remotes |
| [02:54:27] | j-rod: | just not sure yet where in the kernel IR stack the fault is |
| [02:55:08] | wagnerrp: | that the issue where lircd fails because the socket created by the driver is not writable? |
| [02:55:31] | wagnerrp: | ended up having to revert back to the external 0.9.0 drivers from that one |
| [02:56:01] | jams: | yeah i was waiting for .37 for streamzap and some ivtv issues |
| [02:57:05] | j-rod: | wagnerrp: bwha? no, that's a new one to me... |
| [02:57:21] | j-rod: | with rc5 signals, the trailing space from the signal isn't getting out to userspace for some reason |
| [02:57:55] | j-rod: | by the time it gets there, at the start of the *next* signal, its way too late, and lircd has moved on. and is further confused by a signal that starts with a space instead of a pulse. |
| [02:58:00] | wagnerrp: | yeah, some issue with the internal 'mceusb.ko' in 2.6.36, but the 'lirc_mceusb.ko' from 0.9.0 still worked fine |
| [02:58:00] | j-rod: | or something along those lines |
| [02:58:18] | j-rod: | I can't recall wtf is in 2.6.36 anymore |
| [02:58:34] | j-rod: | 2.6.37's mceusb.ko *should* be 100% fine with the mce remotes, less certain with others... |
| [02:58:35] | danielk22: | stuarta: "_dvb_has_eit = i < sdt->ServiceCount();Â " that's really strange for an assignment to a bool. AFAICT just _dvb_has_eit = i whould work in this case. I can't speak to the overall patch looks like it's saying that if any service on a mux has EIT they all do. I don't know enough about DVB-x. |
| [02:58:57] | wagnerrp: | well let me know if you want me to do anything |
| [02:59:33] | wagnerrp: | the whole system is snapshotted, so its trivial for me to tinker around |
| [03:00:32] | danielk22: | stuarta: It also removes a lock in HasEIT(), but I dunno if that is really needed. |
| [03:02:11] | j-rod: | wagnerrp: would definitely be interested to hear how 2.6.37's mceusb.ko fares, I'm already planning to send some patches for 2.6.37.y stable |
| [03:23:43] | abqjp (abqjp!~abqjp@174-28-182-216.albq.qwest.net) has joined #mythtv | |
| [03:36:32] | elmojo: | just used git stash... very neat |
| [03:36:51] | Beirdo: | yeah, it can be quite handy |
| [03:37:03] | xris: | elmojo: yeah. I haven't used it more than one layer, but I have coworkers who swear by it for doing tons of stuff |
| [03:37:14] | ** xris learned of a new git macro to track down ** | |
| [03:51:09] | elmojo: | I still don't understand why git pull --rebase is so dangerous – seems like the entire planet agrees it's the proper way to do things |
| [03:51:39] | elmojo: | if all I'm doing is cloning master and making simple commits |
| [03:52:04] | elmojo: | I know it's been discussed but I don't want to go researching it again |
| [03:53:31] | elmojo: | as long as I verify everything looks fine then what's the danger |
| [03:54:26] | xris: | https://github.com/ex-nerd/scripts/blob/master/.bashrc.d/git |
| [03:55:08] | xris: | elmojo: it's just because users can screw things up (or get very confused/frustrated) if they abort the rebase-merge halfway through |
| [03:55:16] | xris: | it was a LOT worse with git < 1.7, though... |
| [03:55:41] | xris: | afk |
| [03:56:16] | elmojo: | at some point we have to try it though and figure it out |
| [04:03:53] | Beirdo: | yeah, doing so with a test repo might be a decent plan :) |
| [04:04:32] | elmojo: | well I just committed a change so if someone checks something in in the meantime I'm going to git pull --rebase |
| [04:04:57] | xris: | elmojo: yeah. or on a non-master branch. |
| [04:05:04] | xris: | though really once you've done a few merges you should be ok |
| [04:05:06] | elmojo: | if Github catches fire then so be it |
| [04:05:14] | Beirdo: | heh |
| [04:05:32] | Beirdo: | if it gives odd behavior, stop before pushing :) |
| [04:05:41] | Beirdo: | let me commit a small change here for ya |
| [04:05:53] | xris: | and once you understand how git works as a tree (vs svn like a cross section of a linear progression) then it's not so bad |
| [04:06:43] | elmojo: | I understand that the rebase will undo my commits then apply the changes then redo my commits – definitely can cause a merge issue but what's the big deal – you'd have to fix that with an svn update too |
| [04:07:06] | Beirdo: | OK, committed a README change :) |
| [04:07:42] | Beirdo: | well, if you get commit conflicts, it CAN (not often though) get really messy, especially if you don't pay attention to it |
| [04:07:54] | elmojo: | heh, I'm on the fixes/0.24 branch |
| [04:08:03] | Beirdo: | hehe, oops :) sorry |
| [04:08:56] | Beirdo: | there, try that |
| [04:11:44] | elmojo: | done but it did say something about and error with the master repo |
| [04:11:53] | elmojo: | something about fast-forwarding |
| [04:12:07] | Beirdo: | pastebin it? |
| [04:12:22] | elmojo: | ! [rejected] master -> master (non-fast-forward) |
| [04:12:22] | elmojo: | error: failed to push some refs to 'git@github.com :MythTV/mythtv.git' |
| [04:12:30] | Beirdo: | ahhh |
| [04:12:37] | elmojo: | I didn't do anything on the master branch |
| [04:12:42] | Beirdo: | that was the push? |
| [04:12:43] | wagnerrp: | means someone else has |
| [04:12:50] | elmojo: | yes push |
| [04:13:00] | Beirdo: | one sec |
| [04:13:21] | elmojo: | do I just need to do a git co master and then git pull to clear it up? |
| [04:13:39] | Beirdo: | I think Janne added some config to the UsingGit page that will stop it from doing that |
| [04:13:46] | elmojo: | btw, I'm using git 1.5.2 |
| [04:13:53] | Beirdo: | it's trying to push all matching branches (default config) |
| [04:14:10] | Beirdo: | git config --global --add push.default nothing |
| [04:14:11] | Beirdo: | git config --global --add push.default tracking |
| [04:14:13] | Beirdo: | there it is |
| [04:14:14] | simonckenyon (simonckenyon!~simoncken@195.7.61.12) has quit (Remote host closed the connection) | |
| [04:14:26] | elmojo: | ah, ok |
| [04:14:28] | Beirdo: | that forces it to *only* push the branch you are on |
| [04:15:01] | wagnerrp: | which one, youre setting it to two different values? |
| [04:15:10] | Beirdo: | that's what he put :) |
| [04:15:19] | Beirdo: | I just ran it as is for my config |
| [04:15:37] | Beirdo: | I wondered about that too :) |
| [04:16:23] | Beirdo: | but I figured he had a good idea what he was talking about, and it did what he said, so good enough. |
| [04:17:16] | elmojo: | I think 'nothing' only pushes to the branch you are currently on that has the same name |
| [04:17:33] | elmojo: | and 'tracking' is whatever you are tracking even if you named them differently |
| [04:17:40] | elmojo: | either one should work fine |
| [04:17:47] | elmojo: | for most cases |
| [04:17:50] | Beirdo: | could well be. |
| [04:18:16] | Beirdo: | I'm trying to find it... oh there it is ... man git-config |
| [04:18:33] | Beirdo: | too obvious |
| [04:18:40] | xris: | elmojo: you seriously need to update to 1.7.x |
| [04:18:46] | Beirdo: | hmm, it doesn't sa how to stack them |
| [04:18:51] | xris: | that may be half of the problems people are having |
| [04:18:56] | xris: | 1.5 has some serious bugs, though. |
| [04:19:01] | Beirdo: | I'd bet the second one takes the precidence |
| [04:19:12] | elmojo: | xris: it was a joke |
| [04:19:15] | xris: | ah |
| [04:19:20] | elmojo: | hehe |
| [04:19:46] | xris: | coworker was telling me today about an issue.. if you have staged (but not committed) changes in master, and you pull, it will commit those changes along with the pull as a merge. with no record of it. |
| [04:19:49] | elmojo: | Beirdo: yes they are two different settings and he descibes each one |
| [04:19:58] | xris: | or rather, staged and committed things, separately |
| [04:20:16] | elmojo: | what is staged? |
| [04:20:27] | Beirdo: | yeah, the man page isn't clear if putting two makes any sense, but tracking is really what you'd want, I'd think |
| [04:20:46] | elmojo: | yes tracking would probably be the best default |
| [04:20:49] | Beirdo: | xris: WHAT? |
| [04:21:00] | elmojo: | you should probably edit the page and make them separated |
| [04:21:10] | xris: | Beirdo: yeah, ivan mentioned it to me today.. big issue with 1.5 |
| [04:21:11] | Beirdo: | I need Tim to move my desk closer to the devs |
| [04:21:25] | Beirdo: | Oh damn, glad I use 1.7 :) |
| [04:21:36] | elmojo: | 1.6 is a nightmare |
| [04:21:40] | xris: | elmojo: staged is what you do to files before committing them.. so you "add" something, and then it's staged/cached for commit. |
| [04:21:50] | elmojo: | ah |
| [04:22:08] | elmojo: | you could have just said "added files" instead of staged |
| [04:22:16] | xris: | git itself refers to things as cached (e.g. git diff --cached), but git-using devs seem to use the word "staged" |
| [04:22:17] | elmojo: | you git people just have to be cool with your lingo |
| [04:22:33] | xris: | well, you can stage changes without adding.. like when deleting files |
| [04:22:34] | Beirdo: | hehe, don't blame us, we're just the messengers |
| [04:22:53] | xris: | yeah, I'm in the "I got forced to use it at work"... |
| [04:23:02] | elmojo: | I do blame you because you not only are messengers but oppressors too |
| [04:23:21] | xris: | but after a few weeks with it I started to like it. |
| [04:23:25] | Beirdo: | Hey now... I'm not trying to oppress you :) |
| [04:23:31] | elmojo: | you already have |
| [04:23:36] | Beirdo: | Sorry, dude |
| [04:24:04] | Beirdo: | anyways.. at work... I'm blessed with having to use CVS, SVN and git... all the time |
| [04:24:06] | elmojo: | you are behind forcing git upon me and I didn't really have a choice... it's oppression... plain and simple |
| [04:24:14] | Beirdo: | that's always fun |
| [04:24:36] | elmojo: | nice... I still use cvs so git is like something of a science fiction experiment for me |
| [04:25:08] | Beirdo: | switch from one to either of the other two and you have to stop and rethink every time |
| [04:25:14] | elmojo: | anyways, just having fun |
| [04:25:43] | xris: | elmojo: I really wish people would have had the time/desire/whatever to check out git for the month that we asked them to... |
| [04:26:00] | xris: | it would have at least delayed this migration (if not prevented it) |
| [04:26:15] | elmojo: | to be fair to everyone, I didn't really notice or pay attention to that |
| [04:26:20] | xris: | but there's that hindsight thing... |
| [04:26:24] | Beirdo: | or perhaps make it smoother |
| [04:26:29] | xris: | Beirdo: yeah. |
| [04:26:35] | Beirdo: | one of the three :) |
| [04:26:38] | elmojo: | I don't think many people realized it would be rushed like it was |
| [04:26:44] | elmojo: | we can't read your mind |
| [04:26:53] | xris: | only a couple of the anti-git folks have actually admitted that they regret waiting until it was "too late" |
| [04:27:04] | elmojo: | and not you didn't convey it very well... if so, people wouldn't be so surprised |
| [04:27:10] | wagnerrp: | you really have to rush these things |
| [04:27:13] | xris: | I think the transition took about a month and a half. not exactly rushed. |
| [04:27:20] | wagnerrp: | its not like you can slowly transition to a new RCS |
| [04:27:27] | Beirdo: | yeah, there is that too |
| [04:27:28] | xris: | or rather, about that much warning. |
| [04:27:29] | wagnerrp: | its an all or nothing kind of thing |
| [04:27:40] | elmojo: | was talking about the actual transition but the decisions, trial, etc |
| [04:28:22] | Beirdo: | yeah, it might have been a bit rushed, in retrospect |
| [04:28:50] | elmojo: | and anyways... it's not so much git the gets me, it's the state of the team and just not the best time for such a transition... and yes, I had strong feelings about this causing irreversible damage but kept my mouth shut |
| [04:29:10] | Beirdo: | well, I hear you there. |
| [04:29:42] | elmojo: | dunno, I guess some people just don't either pay attention or have the ability to read into people's moods |
| [04:30:17] | Beirdo: | But I think as well, it's been used as the sacrificial goat by those that are now blaming it for sidetracking the setup project... that was already sidetracked |
| [04:30:48] | xris: | elmojo: "state of the team" is a big deal to me. heck, it's one of the reasons I pushed for a change like git. just didn't think it would backfire. |
| [04:31:11] | Beirdo: | neither did I |
| [04:31:27] | elmojo: | obviously it was done with the best of intentions so I don't hold and grudges |
| [04:31:30] | Beirdo: | and I'm sorry we've degenerated such as we have. |
| [04:31:45] | elmojo: | it's been nice to learn this stuff although I still believe it's overly complicated for what we do |
| [04:31:57] | Beirdo: | however, I'm happy to see that some of the "meh to git" types are actually trying to make a go of it |
| [04:32:08] | elmojo: | I don't have a choice |
| [04:32:10] | xris: | but combined with a few personal clashes (some fairly serious, though I won't point fingers), a lot of the "team" has been fighting against itself. |
| [04:32:12] | elmojo: | thanks to you |
| [04:32:13] | elmojo: | :) |
| [04:32:29] | Beirdo: | it opens the doors to allowing big feature adds cleaner |
| [04:32:46] | Beirdo: | if we'd quit screwing up as we do it, of course (again, my bad on that one) |
| [04:33:32] | Beirdo: | but, be as it may... it all comes down to how people treat it |
| [04:33:36] | Beirdo: | as a change |
| [04:34:03] | Beirdo: | some people (in general, not just in our team) are very anti-change at all cost |
| [04:34:17] | Beirdo: | those people are impossible to please and have progress |
| [04:34:19] | xris: | s/people/developers/ |
| [04:34:49] | Beirdo: | then some like constant change, and you can't please THEM and have stability |
| [04:34:55] | xris: | because really, developers are among the worst. otherwise we wouldn't have religious wars over text editors. :) (nano forever!) |
| [04:34:55] | elmojo: | that's why you have to a cost/value projection ahead of time |
| [04:35:20] | Beirdo: | nano?! hehehe |
| [04:35:22] | xris: | elmojo: easier said than done with a project staffed by volunteers who don't always even know what they want. |
| [04:35:31] | xris: | Beirdo: joke. though I do use it almost as much as I do vi. |
| [04:35:44] | Beirdo: | hehe, I know, it's very Seattle of you. |
| [04:35:53] | elmojo: | heh, you can at least determine if you can tolerate the risk |
| [04:36:11] | Beirdo: | UW-written software was the basis of nano. |
| [04:36:13] | Beirdo: | anyways |
| [04:37:14] | xris: | elmojo: but from the pseudo-vote we had before migrating to git, it was low risk. |
| [04:37:22] | Beirdo: | I think part of the issue at hand really is that it's hard to get people to "sit down" and have a civil conversation when their opinions differ |
| [04:37:48] | xris: | at worst, people were hesitant but open to the idea of learning (or like Isaac who doesn't like it, but hasn't been planning to do any work) |
| [04:37:54] | Beirdo: | we get caught up in the dumbest little details, and people's emotions take over |
| [04:38:10] | xris: | Beirdo: and when you're typing everything instead of speaking. |
| [04:38:16] | xris: | afk again.. baby tme. |
| [04:38:20] | xris: | tim |
| [04:38:20] | xris: | \ |
| [04:38:26] | xris: | t.i.m.e. |
| [04:38:29] | Beirdo: | and then the people who *could* help fix the little issues are all too pissed at each other to pitch in |
| [04:38:39] | Beirdo: | and the cycle continues |
| [04:39:10] | Beirdo: | let's face it, we're humans |
| [04:40:12] | Beirdo: | and humans with limited spare time |
| [04:41:54] | Beirdo: | I really appreciate the folks that have tried to help out, and have come up with constructive ideas as to how to make things better |
| [04:46:05] | Beirdo: | or at a minimum didn't throw up more barriers every time I turned around |
| [04:58:11] | j-rod: | swapping out master backend hardware starting at 10pm on a tuesday night seems to have been… maybe not the best choice. |
| [04:58:52] | j-rod: | but hey, only two mildly interesting soccer games set to record tomorrow anyway |
| [05:00:59] | wagnerrp_ (wagnerrp_!~wagnerrp_@mythtv/developer/wagnerrp) has joined #mythtv | |
| [05:01:19] | wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has quit (Disconnected by services) | |
| [05:01:23] | wagnerrp_ is now known as wagnerrp | |
| [05:02:16] | Beirdo: | hehe |
| [05:02:24] | Beirdo: | I've had nights like that |
| [05:02:42] | Beirdo: | good to see you survived the holidays :) |
| [05:03:25] | wagnerrp: | Beirdo: shouldnt 9446 be closed duplicate of 9424? |
| [05:03:56] | Beirdo: | Hmmm, I'd have to look again, but they are certainly related |
| [05:04:26] | Beirdo: | slightly different bug, perhaps |
| [05:05:26] | wagnerrp: | well i commented as such, just so its not lost |
| [05:05:28] | Beirdo: | the newer one gives different info (although in a FRWOP method) :) |
| [05:05:37] | Beirdo: | k :) |
| [05:05:38] | xris: | j-rod: https://github.com/ex-nerd/scripts/blob/master/.bashrc.d/git |
| [05:06:14] | Beirdo: | and I'm not impressed by the hackage in #9446, but if we can model the headers from minidlna may well be a good plan |
| [05:07:34] | j-rod: | xris: huh, interesting stuff |
| [05:08:09] | xris: | yeah, handy |
| [05:08:28] | j-rod: | not a huge fan of automated pruning of branches though |
| [05:08:31] | xris: | the cleanup thing probably won't help with kernel stuff.. but it's great for our work style where every bugfix is a branch |
| [05:08:47] | brfransen (brfransen!~brfransen@adrianDHCP-47.216-254-250.iw.net) has quit (Remote host closed the connection) | |
| [05:09:02] | xris: | they started to add up at 20+ per week... since we push them all to origin for sharing/qa. |
| [05:09:05] | wagnerrp: | i know why my web server keeps changing IPs |
| [05:09:05] | j-rod: | yeah, makes more sense there |
| [05:09:11] | brfransen (brfransen!~brfransen@adrianDHCP-47.216-254-250.iw.net) has joined #mythtv | |
| [05:09:23] | wagnerrp: | theres never any traffic on that, so my ISP times out the allocation and recycles it |
| [05:09:49] | Beirdo: | hehe |
| [05:09:51] | jya (jya!~avenardj@mythtv/developer/jya) has joined #mythtv | |
| [05:10:19] | wagnerrp: | apparently when they do so, they force a full modem reconnect for good measure |
| [05:11:45] | clever: | wagnerrp: what are you using for a router? |
| [05:12:13] | Beirdo: | wagnerrp: I could set a cron job to hit your server every 2h or something :) |
| [05:12:15] | Beirdo: | heh |
| [05:12:41] | wagnerrp: | old cisco modem/router in bridging mode, bsd/pf as a router |
| [05:13:11] | wagnerrp: | yeah, was just going to set up a cron to ping something from each allocated address once an hour or so |
| [05:13:16] | wagnerrp: | (i get six) |
| [05:13:25] | xris: | wagnerrp: odd to get 6 with no statics |
| [05:14:33] | wagnerrp: | im still using my same account from back in 1998, when the internet was relatively safe, and IPs were bountiful |
| [05:14:51] | wagnerrp: | people were supposed to just use the router in bridge mode, and stick their machines straight onto the internet |
| [05:14:56] | wagnerrp: | let DHCP handle the rest |
| [05:15:04] | Beirdo: | I did something similar with IPv6 from an EC2. one ping out the IPv6 tunnel every 15min keeps it from closing down |
| [05:15:20] | wagnerrp: | technically, i get a sequence of 10.xxx addresses, which are mapped individually by the ISP |
| [05:17:54] | antifoo (antifoo!~antifoo@123.200.143.227) has quit (Read error: Connection reset by peer) | |
| [05:18:46] | antifoo (antifoo!~antifoo@123.200.143.227) has joined #mythtv | |
| [05:18:57] | elmojo: | j-rod: too bad Naren has never gotten back to us on the CrystalHD problems we reported |
| [05:19:15] | j-rod: | bah. forgot about them myself. |
| [05:19:44] | elmojo: | they just recently announced that ffmpeg/mplayer has support – the author mentioned having issues with some MPEG-2 interlaced content which sounds like it might be the driver |
| [05:19:47] | j-rod: | he's been answering questions from philip langdale (sp?) on crystalhd-development |
| [05:19:56] | elmojo: | ah, cool |
| [05:20:05] | j-rod: | …who wrote the code you're referring to :) |
| [05:20:19] | elmojo: | maybe, hopefully he runs into the same issues and gets Naren to look at it :) |
| [05:20:32] | elmojo: | where is this crystalhd-development? |
| [05:20:47] | j-rod: | crap, did I not give you a pointer to that before?... |
| [05:20:53] | elmojo: | you may have |
| [05:20:58] | j-rod: | its a google group, but everyone uses it as a mailing list |
| [05:21:12] | elmojo: | does it have archives? |
| [05:21:35] | j-rod: | http://groups.google.com/group/crystalhd-development |
| [05:21:37] | j-rod: | I believe |
| [05:21:54] | elmojo: | ot, but have you found a native 64-bit adobe flash version that doesn't crash all the time? |
| [05:22:09] | j-rod: | haven't tried in a while |
| [05:22:31] | j-rod: | I do see archived stuff after logging in, but I'm already in the group, not sure if that matters... |
| [05:23:17] | j-rod: | my current solution for anything flash is my core 2 quad w/a GTX 460 running windows |
| [05:23:51] | j-rod: | works fine on my macbook pro too :) |
| [05:23:59] | j-rod: | too many battles, not enough time to fight them |
| [05:24:03] | j-rod: | -EKIDS |
| [05:31:06] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [05:33:58] | MaverickTech (MaverickTech!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 255 seconds) | |
| [05:50:48] | j-rod is now known as j-rod|afk | |
| [06:24:14] | wagnerrp_ (wagnerrp_!~wagnerrp_@NR-FT1-66-42-240-159.fuse.net) has joined #mythtv | |
| [06:24:14] | wagnerrp_ (wagnerrp_!~wagnerrp_@mythtv/developer/wagnerrp) has joined #mythtv | |
| [06:24:14] | wagnerrp_ (wagnerrp_!~wagnerrp_@NR-FT1-66-42-240-159.fuse.net) has quit (Changing host) | |
| [06:24:24] | wagnerrp (wagnerrp!~wagnerrp_@mythtv/developer/wagnerrp) has quit (Disconnected by services) | |
| [07:04:04] | sphery: | elmojo: Webkit 2 has a workaround for the bug in Flash 10.1 and 10.2-square-preview-alpha-beta-whatever. Qt 4.7 has Webkit 2, so you really need to go to Webkit 2 (or find an old link to a Flash 10.0.x 64-bit release--which many sites, like Hulu, will refuse to let you use because of the Flash security issues that were since fixed) |
| [07:08:36] | dakeyras (dakeyras!~dakeyras@pool-173-64-149-152.sttlwa.fios.verizon.net) has quit (Quit: dakeyras) | |
| [07:19:53] | Beirdo: | we should look into when Qt4.7 will become officially the minimum |
| [07:55:56] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [08:12:27] | simonckenyon (simonckenyon!~simoncken@195.7.61.12) has joined #mythtv | |
| [08:15:39] | leprechau (leprechau!leprechau@c-98-240-50-163.hsd1.tn.comcast.net) has quit (Ping timeout: 240 seconds) | |
| [08:17:50] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Read error: Operation timed out) | |
| [08:39:51] | Mekon (Mekon!~quassel@84.9.39.136) has joined #mythtv | |
| [08:49:25] | stoffel (stoffel!~quassel@p57B4B976.dip.t-dialin.net) has joined #mythtv | |
| [08:52:49] | leprechau (leprechau!leprechau@c-98-240-50-163.hsd1.tn.comcast.net) has joined #mythtv | |
| [09:22:02] | stuarta: | danielk22: which eit patch were you commenting on? |
| [09:43:16] | stuarta: | qt-4.7.1 doesn't parallel build on the mac. must be a missing dep somewhere in their makefiles |
| [09:46:02] | balor (balor!~aidan@87.127.55.57) has joined #mythtv | |
| [09:46:10] | Goga777 (Goga777!~Goga777@shpd-95-53-181-252.vologda.ru) has joined #mythtv | |
| [10:06:41] | Mekon (Mekon!~quassel@84.9.39.136) has quit (Read error: Connection reset by peer) | |
| [10:40:03] | jamesba (jamesba!~jamesba@gateb.kw.bbc.co.uk) has joined #mythtv | |
| [11:03:46] | XChatMav (XChatMav!~MaverickT@111.86.233.220.static.exetel.com.au) has joined #mythtv | |
| [11:05:56] | MavT (MavT!~MaverickT@111.86.233.220.static.exetel.com.au) has quit (Ping timeout: 240 seconds) | |
| [11:17:17] | Goga777 (Goga777!~Goga777@shpd-95-53-181-252.vologda.ru) has quit (Read error: Connection reset by peer) | |
| [12:17:22] | stuartm: | elmojo: the latest 10.2 64bit beta is relatively stable, doesn't seem to crash that frequently for me |
| [12:19:07] | ** stuarta changes his earlier statement to qt-4.7.1 doesn't build on the mac ** | |
| [12:19:30] | ** stuarta looks for hammer ** | |
| [12:20:16] | stuartm: | Beirdo: fwiw I don't blame git for sidetracking the setup project, but I do think we might have been back on track already without this added distraction |
| [12:20:38] | stuarta: | which one's the setup project? that my one? |
| [12:21:10] | stuarta: | if so i blame things at work breaking, not git |
| [12:21:12] | stuartm: | stuarta: err, yeah |
| [12:21:53] | stuarta: | unfortunately my critical stuff at work broke on a regular basis :( |
| [12:21:56] | stuartm: | stuarta: we've not be waiting for you, there were parts of this plan and code which were already done, written in stone and ready for committing |
| [12:22:40] | stuarta: | ah well, from where i sit, i've not managed anything on it due to work |
| [12:24:04] | stuartm: | the whole thing ground to a halt because it was hijacked by everyone who suddenly had a strong opinion on what should or shouldn't be done and how it should be done, we went from a relative certainty to collapse pretty quickly |
| [12:25:10] | stuarta: | i was planning to start from the beginning and send an email to try to get some consensus on what we wanted |
| [12:25:57] | stuartm: | danielk22 was the original driver behind this project, he's been working on it for a while and has patches out there already but I think he's lost interest :( |
| [12:27:05] | balor (balor!~aidan@87.127.55.57) has quit (Ping timeout: 264 seconds) | |
| [12:27:25] | stuarta: | well i know what i want to achieve |
| [12:27:32] | stuarta: | easy web based setup for a newby |
| [12:28:01] | stuartm: | stuarta: I've already mentioned this to xris but I think it was a mistake to take this out of danielk22's hands and try to design by committee, that has never worked well for us in the past |
| [12:28:32] | stuarta: | i didn't think we took it out of his hands, i thought he just stopped working on it |
| [12:29:07] | stuartm: | it would have been much easier to just get on with it then mould/polish/fixup the final product than to try and agree on a fully formed plan from day one |
| [12:29:22] | stuarta: | a vague plan would be nice |
| [12:29:51] | stuartm: | we already have that, we've had that for months |
| [12:31:21] | stuartm: | but somewhere along the way it suddenly became important to dot every i and cross every t, I can blame myself as much as anyone else, we got carried away and quite probably crushed danielk22's spirit in the process |
| [12:33:25] | stuarta: | we've become a bit distracted of late |
| [12:33:43] | stuarta: | i feel things are settling down now and we might be able to start making some progress |
| [13:07:53] | dapper-daniel (dapper-daniel!~daniel@ppc1h1.ia.hg.tu-darmstadt.de) has joined #mythtv | |
| [13:08:07] | dapper-daniel (dapper-daniel!~daniel@ppc1h1.ia.hg.tu-darmstadt.de) has left #mythtv () | |
| [13:44:08] | balor (balor!~aidan@87.127.55.57) has joined #mythtv | |
| [13:45:39] | stuarta: | so many toys being thrown out of the pram |
| [13:49:54] | stoffel (stoffel!~quassel@p57B4B976.dip.t-dialin.net) has quit (Ping timeout: 260 seconds) | |
| [13:49:55] | balor (balor!~aidan@87.127.55.57) has quit (Ping timeout: 246 seconds) | |
| [14:01:33] | danielk22: | stuarta: #9445. It was just submitted. It looks like a hack that got someone's broken providers EIT to work. |
| [14:04:48] | danielk22: | stuarta: stuartm: I haven't lost interest in the http/xml mythtv-setup |
| [14:05:08] | stuartm: | danielk22: well I'm glad to hear that |
| [14:06:24] | stuarta: | danielk22: i think i finally found it in my inbox :) |
| [14:14:40] | stuartm: | I can't remember whether I'm supposed to merge master to branch or not, I'd rather avoid a storm of commits when I do push but I can't keep testing changes if my database schema has changed since the branch point :/ |
| [14:16:01] | stuarta: | my current understanding based on everything that's been said, is no you shouldn't merge head to your branch as when you merge your branch back to head it spews lots of commit messages |
| [14:16:22] | stuarta: | which is when you get into the rebase stuff |
| [14:19:22] | stuartm: | well then being practical it seems to develop in branches you also need to maintain a separate install/database etc for each branch :/ |
| [14:20:24] | stuartm: | which is where I don't really want local branches, but local working directories, so I can keep changes seperate but still revisioned and current with the lastest origin/master |
| [14:22:14] | stuarta: | i'm still using quilt to manage my patches |
| [14:22:14] | stuartm: | in that respect, neither git nor svn are going to help and I might be better off maintaining my massive patch collection |
| [14:22:30] | stuarta: | still by far the simplist way i've found |
| [14:23:26] | stuartm: | quilt doesn't suit my disorganised way of working, it assumes you'll work on one feature at a time |
| [14:23:57] | stuartm: | whereas I'd get bored if I did that |
| [14:24:16] | stuarta: | i bend it to my will when i want to work on something else :) |
| [14:24:33] | stuarta: | after all it's not difficult to hack a text file |
| [14:26:30] | ** stuarta attempts git commit #1 ** | |
| [14:26:36] | elmojo: | abqjp: if you have the time/energy could you try removing the #7964 patch and just apply the first one line change in#7964 and see if that keeps the playback smooth – you mentioned earlier than without the patch of remaining changes it had issues every few seconds |
| [14:28:27] | PointyPumper (PointyPumper!~pintlezz@190.244.73.13) has quit (Ping timeout: 265 seconds) | |
| [14:28:28] | elmojo: | err, apply just the first line changed in vsync.cpp – if (ret_val < -m_frame_interval && m_frame_interval >= m_refresh_interval) |
| [14:35:15] | j-rod|afk is now known as j-rod | |
| [14:35:28] | PointyPumper (PointyPumper!~pintlezz@190.244.73.13) has joined #mythtv | |
| [14:45:09] | stuarta: | well that wasn't too bad |
| [14:47:01] | stuarta: | stuartm: looking at the network graph various people have merged master into their branches so dunno what's recommended now |
| [14:47:42] | gigem_ (gigem_!~david@host137.12.intrusion.com) has joined #mythtv | |
| [14:55:53] | j-rod: | stuartm: re: developing in branches... |
| [14:56:18] | j-rod: | what I do to keep things separate, but still have a common testing ground is keep several topic branches |
| [14:56:34] | j-rod: | and then a merged branch, which carries all of them together |
| [14:56:57] | stuartm: | right, so merge to another branch that is kept current for testing? |
| [14:57:06] | j-rod: | yeah |
| [14:57:27] | j-rod: | the case I have in mind, the topic branches are still based on a few kernel revisions back |
| [14:57:52] | j-rod: | but the merged branch, I reset to master periodically, and then cherry-pick the changes from all the topic branches in |
| [14:58:23] | stuarta: | is the merged branch local only (or does that concept not exist) |
| [14:58:29] | j-rod: | the branches can be merged in as well, rather than cherry-picked, but that causes issues with some of the automated kernel srpm generation tools we use here |
| [14:58:42] | j-rod: | the merged branch is local only in my case |
| [14:58:57] | j-rod: | actually, the topic branches are as well |
| [14:59:07] | stuarta: | that is created how? |
| [14:59:25] | j-rod: | but I'm not collaborating with anyone one them, they're all targeted bugzilla-specific fixes |
| [14:59:39] | ** stuarta hopes j-rod doesn't confuse stuart's ** | |
| [15:00:04] | j-rod: | heh. I had to do a double-take and re-read who said what for a sec. :) |
| [15:00:32] | j-rod: | stuarta: which "that" are you referring to in "that is created how?" |
| [15:00:41] | stuarta: | private branch |
| [15:00:52] | ** stuarta is reading manpage ** | |
| [15:01:00] | j-rod: | ok, got it. |
| [15:01:13] | j-rod: | so assuming a fresh/clean checkout, you're in branch 'master' |
| [15:01:19] | stuarta: | yup |
| [15:01:31] | ** stuarta is guessing it's an option to branch ** | |
| [15:01:47] | j-rod: | git checkout -b staging |
| [15:01:56] | j-rod: | will check out and create a branch called staging |
| [15:02:15] | j-rod: | at this point, its entirely local, as you've not pushed it anywhere |
| [15:02:32] | stuarta: | i guess i'm thinking how do i prevent it from ever being pushed? |
| [15:02:44] | stuarta: | just never run git push in that checkout? |
| [15:02:57] | j-rod: | when you do a push, you can do a simple "git push" |
| [15:03:09] | j-rod: | or you can do a "git push <dest repo> <branch name>" |
| [15:03:16] | stuarta: | which most of us will do |
| [15:03:23] | stuarta: | the first one |
| [15:04:03] | j-rod: | there's actually a git config option that I believe sets push to *only* push the current working branch to the repo its tracking |
| [15:04:10] | ** j-rod hunts around for that ** | |
| [15:04:50] | stuarta: | so a git push will push only the checked out branch? |
| [15:05:10] | j-rod: | hrm, not sure on this one. |
| [15:05:20] | j-rod: | I have push.default = tracking in my .gitconfig |
| [15:05:35] | stuarta: | it's not a biggie, i just like to know where i stand before i break things :) |
| [15:05:50] | j-rod: | so pushes only push to the remote branch I'm actually tracking w/the current local branch |
| [15:06:01] | stuarta: | excellent |
| [15:06:21] | j-rod: | generally, I find it easiest to just always say exactly what repo and branch I want to push to as a safety net |
| [15:07:01] | j-rod: | well, maybe not easiest, but definitely safest |
| [15:07:51] | j-rod: | the push.default=tracking thing may only work if your local branch was created specifically to follow an already existing remote branch |
| [15:08:58] | j-rod: | for rhel5 kernel stuff, I have only three branches, master, patches and scratch |
| [15:09:34] | j-rod: | the patches branch is purely local, constantly reset to master |
| [15:10:25] | j-rod: | scratch very infrequently gets pushed, and is non-fast-forward. only gets pushed if there's some integration issue I need someone else to look at for some reason, and its easiest done by sharing a git tree. |
| [15:10:38] | j-rod: | otherwise, its almost always 'git push eng master' |
| [15:11:13] | j-rod: | with 'eng' being an alias for origin, aka our internal engineering dept git host |
| [15:12:01] | ** j-rod possibly not helping here, may only be further muddying the waters… :) ** | |
| [15:12:12] | stuarta: | i guessed the eng bit :) |
| [15:42:18] | prologic (prologic!~prologic@unaffiliated/prologic) has joined #mythtv | |
| [15:42:31] | prologic: | IS anyone aware of an appliance that runs mythtv ? |
| [15:44:24] | ** stuarta points at the topic ** | |
| [15:44:40] | Kunalagon (Kunalagon!~Kunalagon@212.200.241.52) has joined #mythtv | |
| [15:45:28] | prologic: | ta |
| [15:45:31] | prologic (prologic!~prologic@unaffiliated/prologic) has left #mythtv ("Leaving") | |
| [15:53:13] | stuartm: | stuarta: "git push" will out push the branch you currently have checked out |
| [15:53:43] | stuartm: | e.g. if you're working on 0.24/fixes and run 'git push' it won't push any changes you have in master |
| [15:54:34] | stuarta: | i may have to modify my workflow a bit, i used to have a checkout for each of head and fixes |
| [15:54:49] | stuarta: | which i've tried to replicate with git |
| [15:55:41] | stuarta: | seemed to work but it threw an error about "non-fast-forward updates were rejected" |
| [15:55:53] | stuarta: | against master |
| [15:56:11] | stuarta: | clearly i hadn't pull against master in that workdir |
| [15:56:29] | stuartm: | btw, one feature of git that is actually pretty neat and we might have started using if the whole thing wasn't up in the air is --author and --signoff – that allows you to make commits where the 'author' is someone else and --signoff indicates that you were the reviewer of the patch |
| [15:56:31] | stuarta: | although i thought doing a git pull did it for every branch |
| [15:56:44] | elmojo: | j-rod: thanks for the pointer to that CrystalHD user group – sounds like progress is alive and well – and we get to receive the same driver benefits that will happen to help the mplayer code |
| [15:56:48] | stuarta: | that was one of the reasons for moving to it |
| [15:57:29] | stuartm: | e.g. in applying a patch from a ticket unmodified you'd want to do 'git commit --author Joe Blogs <joe@blogs.com > --signoff' |
| [15:57:53] | stuarta: | i probably should use that more |
| [15:58:14] | stuarta: | majority of my commits are like that these days |
| [15:59:30] | j-rod: | elmojo: able to see past discussion okay then? |
| [16:00:55] | stuartm: | stuarta: 'git pull' does not update every branch, and for local branches I'm not even sure it does anything as they don't track the remote repo by default |
| [16:01:05] | elmojo: | j-rod: yes it's all archived |
| [16:01:20] | elmojo: | Naren posted last last night |
| [16:01:37] | j-rod: | good deal |
| [16:02:04] | stuartm: | it's mildly irritating that every time I want to update 0.24 and master I need to 'git pull' 'git checkout 0.24/fixes' 'git pull' instead of just pulling the once |
| [16:02:24] | j-rod: | hrm? |
| [16:02:38] | stuarta: | my workflow might work okay now that i've set the relevant push flags as per the usingGit page |
| [16:02:54] | ** stuarta ahahs! ** | |
| [16:03:08] | j-rod: | oh, I see. yeah… each has to be updated individually... |
| [16:03:12] | stuarta: | stuartm: git pull --all "Fetch all remotes" |
| [16:03:13] | stuartm: | hmm ... I've just noticed --all in the manual, didn't see that before, that might update all branches at once |
| [16:03:20] | stuarta: | SNAP! |
| [16:03:57] | stuartm: | seems like it does |
| [16:04:10] | stuarta: | yeah, that's done the trick. it's pulled the change i did in my 0.24 workdir into my master workdir |
| [16:04:42] | j-rod: | stuartm: there are some caveats about 'git push' and only pushing to the branch you have checked out... |
| [16:05:12] | j-rod: | if the branch is created locally, from another branch that was tracking master, I believe it'll actually try to push to master |
| [16:05:50] | stuarta: | this swiss army knife has _all_ the options |
| [16:06:15] | j-rod: | I have a branch tracking the upstream v4l/dvb staging/for_v2.6.38 branch, but locally, its my 'staging' branch, and I push it to my own repo's staging branch |
| [16:06:37] | j-rod: | a 'git push' alone tries to push it to the branch its tracking, rather than to my repo branch |
| [16:07:25] | stuartm: | oh crap, just discovered the branch I created 2–3 weeks ago and have been working in since was created from the fixes branch and not master |
| [16:08:17] | j-rod: | not terribly hard to fix up |
| [16:09:16] | j-rod: | just create a new branch tracking master and suck the changes over |
| [16:09:27] | j-rod: | either with cherry-pick or merge |
| [16:09:49] | j-rod: | not sure how well merge would work, as -fixes and master may have diverged a bit |
| [16:10:03] | j-rod: | I'm a huge fan of cherry-pick myself |
| [16:10:58] | j-rod: | love that it even handles file moves/renames without a problem |
| [16:11:10] | stuartm: | stuarta: so much so that when you need to find the 'knife' and cut the main sheet before you're pulled down by the sinking boat, it takes 20 minutes of trial and error as you work through the corkscrews, nail files and thing for removing stones from horses hoofs |
| [16:11:26] | j-rod: | and insanely useful for snarfing upstream changes into something like the rhel kernel trees |
| [16:11:27] | stuarta: | :) |
| [16:12:35] | j-rod: | stuartm: I think I spent at least 3 months tinkering with git off and on, usually screwing up and doing things wrong, before I really fully grasped it, so believe me, I understand the initial pain. |
| [16:19:44] | abqjp (abqjp!~abqjp@174-28-182-216.albq.qwest.net) has quit (Quit: abqjp) | |
| [16:21:45] | stuartm: | j-rod: as I've tried to convey to the others in the pro-git camp, the insane learning curve isn't my problem with git exactly, I picked up the basics pretty quickly albeit with lots of reading and questions – the problem on a personal level is that even knowing all the commands, understanding what is going on behind the scenes, git doesn't become any less complex – in the same way that brain surgery is still challenging even for the most |
| [16:21:46] | stoffel (stoffel!~quassel@p57B4B976.dip.t-dialin.net) has joined #mythtv | |
| [16:21:46] | stuartm: | accomplished brain surgeon |
| [16:23:28] | stuartm: | svn on the other hand takes the most frequently needed aspects of a versioning system and focuses on keeping them simple – it doesn't offer everything that git does, but then 99% of the time most people won't need those extended features |
| [16:24:52] | stuartm: | svn has a chance of becoming more powerful, but it's unlikely git will ever start shedding features and redesigning the UI to become simpler |
| [16:25:31] | j-rod: | my thing with svn is that it always seems to me like you can only ever do one thing at a time. do that one thing, commit it, move on to another. that, or lots of manual work to keep multiple branches, stacks of patches, whatever. |
| [16:25:49] | stuartm: | I can understand the appeal of git, especially among those who like to make everything they do that little bit harder and more challenging |
| [16:26:35] | j-rod: | I think the biggest issue here is that there's a central repo everyone commits to |
| [16:26:45] | Rabbit^^ (Rabbit^^!~Rabbit^^@67-60-190-17.cpe.cableone.net) has joined #mythtv | |
| [16:26:50] | j-rod: | which isn't exactly what git was designed for |
| [16:26:58] | stuartm: | j-rod: svn is supposedly adding the local repo and branch concept in the next release, if they do and it works well, then git really won't offer anything for me at all |
| [16:27:04] | Chutt: | it was designed to make linus's kernel work easier |
| [16:27:15] | Rabbit^^ (Rabbit^^!~Rabbit^^@67-60-190-17.cpe.cableone.net) has left #mythtv () | |
| [16:27:20] | Chutt: | ie, pulling/merging lots of changes from lots of people |
| [16:27:23] | j-rod: | if you're the only person pushing to a repo, you don't have the constant merge/pull/rebase issues we're hitting |
| [16:27:26] | j-rod: | yep |
| [16:27:36] | Chutt: | which is not like anything we do in myth |
| [16:29:41] | j-rod: | so yeah, we're sort of shoehorning a distributed scm into a centralized model here |
| [16:30:18] | stuarta: | \o/ git stash works nicely |
| [16:30:29] | abqjp (abqjp!~abqjp@97-119-168-204.albq.qwest.net) has joined #mythtv | |
| [16:31:00] | stuartm: | stuarta: git stash and local branches have the potential to make quilt redundant |
| [16:31:08] | stuarta: | aye |
| [16:31:13] | PointyPumper (PointyPumper!~pintlezz@190.244.73.13) has quit (Ping timeout: 265 seconds) | |
| [16:31:26] | stuarta: | just playing with the OSX build and had conflicting changes |
| [16:31:33] | j-rod: | yeah, I rarely find need for quilt anymore |
| [16:31:39] | stuarta: | which i stashed; pulled; and pop'd |
| [16:31:55] | stuarta: | git.like++ |
| [16:32:16] | Chutt: | and it helps with the "oh shit, i'm working on the wrong branch" problem |
| [16:32:18] | Chutt: | heh |
| [16:33:05] | j-rod: | the bash prompt git extensions have greatly reduced the number of times I've done that recently. :) |
| [16:33:08] | stuartm: | beyond my own personal issues with git, which I could honestly live with if I had to, I've recently come to appreciate that the steep learning curve for git is not good for the casual contributors who supply most of our patches |
| [16:33:22] | abqjp: | elmojo: BTW, Paul Gardiner and I have been trading daily emails. Somehow we got "off list" (I must have hit reply instead of reply-all at some point), but we are (very slowly) working on http://code.mythtv.org/trac/ticket/9410 |
| [16:33:50] | stuartm: | if we could make svn and git run happily side by side then that would be great, since it means everyone gets to use the tool they find appropriate for the task |
| [16:34:06] | j-rod: | stuartm: I don't quite understand what they need… if they have a local checkout, make their local change, then run 'git diff'... |
| [16:34:38] | j-rod: | or rather, don't quite understand where they're having issues |
| [16:35:44] | j-rod: | creating patches against svn trunk doesn't really seem any different from creating patches against git HEAD to me, but I'm probably missing some details here |
| [16:36:17] | j-rod: | is it the differences in how branches are handled? |
| [16:37:19] | stuartm: | well I'm only speculating here, but issues such as git refusing to merge in uncommitted local changes on a 'pull' make it harder to keep patches current |
| [16:37:39] | ** stuarta stashes stuartm's patches ** | |
| [16:37:52] | stuarta: | that's exactly what i just did |
| [16:37:56] | j-rod: | yeah, 'git stash, git pull, git stash apply' may solve that for most people |
| [16:38:27] | stuartm: | j-rod: right, but can you see how doing that every single time might become a chore compared to 'svn up' ? |
| [16:39:41] | j-rod: | well, I suppose we could write some helper scripts or some such thing |
| [16:40:07] | j-rod: | stash them in the repo root or in the wiki |
| [16:40:13] | j-rod: | ./gitup |
| [16:40:33] | j-rod: | stash any local changes, update, reapply local changes |
| [16:43:35] | j-rod: | or maybe a library of 'helper' functions people can source in |
| [16:44:09] | stuartm: | or maybe they can just use the tool most appropriate for the job, svn |
| [16:44:30] | j-rod: | yeah, I was waiting for that. ;) |
| [16:45:33] | j-rod: | what happens if you svn up, and your local changes can't be merged for some reason? |
| [16:46:00] | stuarta: | you get a conflict merge with lovely '<<<<' and '>>>>' |
| [16:46:08] | stuartm: | same as with git, you're given the opportunity to manually fix the conflicts |
| [16:46:14] | iamlindoro: | And can resolve it as you go |
| [16:46:22] | iamlindoro: | ^^ exactly |
| [16:46:26] | j-rod: | ok, that was what my vague recollection was |
| [16:47:06] | j-rod: | functionally, it seems 'svn up' and 'git stash; git pull; git stash apply' are more or less identical |
| [16:47:07] | stuartm: | with a code base as large as mythtv I don't find that my local changes conflict with incoming commits very often |
| [16:47:54] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has joined #mythtv | |
| [16:47:55] | stuartm: | j-rod: or 'git pull --rebase' |
| [16:48:19] | j-rod: | I was attempting to avoid rebases, since others have said "don't do rebases, they're evil!" :) |
| [16:48:38] | ** j-rod uses rebase quite frequently ** | |
| [16:48:51] | stuartm: | either way it's the default behaviour of svn so that the end user rarely has to give it any thought at all |
| [16:49:16] | j-rod: | are long-standing not-committed changes really such a good idea though? |
| [16:49:27] | Chutt: | yeah, i rebase all the time, i don't understand the "don't rebase" suggestion |
| [16:49:50] | j-rod: | I stash even trivial changes and work-in-progress crud in branches all the time |
| [16:50:04] | j-rod: | then rebase them, squash them, reorder them, throw them out, whatever |
| [16:50:04] | stuarta: | i believe it's "don't rebase *master*" |
| [16:50:22] | stuarta: | for your own branch it makes complete sense |
| [16:51:36] | stuartm: | in arguing this same point over and over I'm reminded of a conversation I had in here or -users a while back – someone posted a complex sed/grep/auk mashup in response to a question (so complicated I wouldn't begin to remember it) and I suggested a much simpler alternative using a single command (find), their response was 'well yes I know I can use find, but I prefer my method' |
| [16:52:02] | stuarta: | there's always 10 different ways to do the same thing |
| [16:52:19] | j-rod: | stuartm: I apologize for some of the required rehashing, I was more or less computerless for the past ~2 weeks... |
| [16:52:36] | stuarta: | how did you cope? |
| [16:52:41] | stuartm: | i.e. some people _like_ to find the most complicated way of doing something that can be done simply |
| [16:52:42] | j-rod: | not well |
| [16:53:24] | j-rod: | stuarta: I had all sorts of plans for computer-y things I was going to work on, all squashed by the wife and kids. well, and being sick. |
| [16:53:39] | wagnerrp: | stuartm: do we have our own IP blacklist anywhere for spam? |
| [16:53:43] | ** stuarta can relate to that ** | |
| [16:54:49] | stuarta: | wagnerrp: i think it's a page in trac |
| [16:54:59] | stuarta: | well for trac spam at least |
| [16:55:15] | wagnerrp: | just looking at that one entry this morning |
| [16:55:35] | wagnerrp: | that was alive person who got the email required warning, and responded accordingly |
| [16:57:18] | j-rod: | wagnerrp: btw, properly clearing all cards everywhere dtrt last night, back to 1–9 now, thank you. :) |
| [16:57:34] | wagnerrp: | awesome, i broke trac |
| [16:57:40] | stuarta: | \o/ |
| [16:57:48] | j-rod: | I'm going to get that friggin' gt220 outputting audio if it kills me |
| [16:57:49] | wagnerrp: | i mean bad |
| [16:57:58] | wagnerrp: | not just a database timeout, this one needs some fixing |
| [16:58:04] | wagnerrp: | #9447 |
| [16:58:14] | j-rod: | no trac == no more bug reports. I endorse this message. |
| [16:58:22] | ** stuarta chuckles ** | |
| [16:58:48] | j-rod: | its occasionally comical here in the office if there's a bugzilla outage |
| [16:58:52] | stuartm: | wagnerrp: I thought there used to be one, but I can't find it now, might not appear in the version of the spam filter we have installed or there was another plugin for that |
| [16:59:21] | stuarta: | i can't find the updates i did to the OSX wiki page :( |
| [16:59:33] | ** stuartm takes away wagnerrp's keys ** | |
| [16:59:47] | wagnerrp: | hey now, it used to work |
| [16:59:52] | stuarta: | what? no tarring and feathering? :( |
| [16:59:58] | wagnerrp: | i just did that by having a normal login |
| [17:00:31] | wagnerrp: | tried deleting a comment that was nothing but a version info |
| [17:00:41] | wagnerrp: | after re-attaching the version info as a file |
| [17:00:55] | wagnerrp: | seems the delete left in some garbage in the database |
| [17:01:18] | balor (balor!~aidan@87.127.55.57) has joined #mythtv | |
| [17:06:30] | wagnerrp: | ok, fix in place, but its not particularly pretty |
| [17:06:46] | wagnerrp: | that ticket was now last modified 41 years ago |
| [17:07:26] | j-rod: | I like it |
| [17:10:01] | balor (balor!~aidan@87.127.55.57) has quit (Read error: Operation timed out) | |
| [17:17:25] | wagnerrp: | is there any real need to change the 'last modified' time when you delete a change in trac? |
| [17:18:02] | wagnerrp: | seems that SQL query is failing when trying to update the time, and putting a NULL in the field instead |
| [17:32:00] | xris: | hah |
| [17:35:08] | anykey_ (anykey_!~guedel@46-126-247-133.dclient.hispeed.ch) has joined #mythtv | |
| [17:53:08] | Beirdo^2 (Beirdo^2!~gjhurlbu@166.134.74.61) has joined #mythtv | |
| [17:53:32] | Beirdo^2 (Beirdo^2!~gjhurlbu@mythtv/developer/beirdo) has joined #mythtv | |
| [17:53:32] | Beirdo^2 (Beirdo^2!~gjhurlbu@166.134.74.61) has quit (Changing host) | |
| [17:56:11] | Beirdo^2: | Stuarta: I think you forgot to setup Git with your mythtv email |
| [18:00:42] | jamesba (jamesba!~jamesba@gateb.kw.bbc.co.uk) has quit (Quit: Leaving) | |
| [18:05:25] | Beirdo^2 (Beirdo^2!~gjhurlbu@mythtv/developer/beirdo) has quit (Quit: Bye) | |
| [18:09:48] | Steve_Goodey (Steve_Goodey!~steve@host86-147-81-4.range86-147.btcentralplus.com) has joined #mythtv | |
| [18:17:33] | fmilo (fmilo!~misto@64.17.253.218) has joined #mythtv | |
| [18:55:32] | gigem_ (gigem_!~david@host137.12.intrusion.com) has quit (Remote host closed the connection) | |
| [18:55:58] | gigem_ (gigem_!~david@host137.12.intrusion.com) has joined #mythtv | |
| [18:57:59] | elmojo: | iamlindoro: I'm going to go out on a limb here and say the Paul H. is an anti-git vote :) |
| [18:58:08] | iamlindoro: | Ah, right |
| [18:58:15] | elmojo: | of course I'll reserve the right to be wrong |
| [18:58:57] | elmojo: | we should also do weighted averages based on ohloh statistics so that Daniel and Stuart M. will wipe everyone out |
| [18:59:13] | elmojo: | just paying respect is all |
| [19:03:37] | elmojo: | abqjp: that's awesome you guys are working on it – I was kinda concerned they might get left out in the cold for a while since jannau had his system go down |
| [19:26:03] | danielk22 (danielk22!~danielk@96.57.9.142) has left #mythtv () | |
| [19:30:18] | balor (balor!~aidan@87.127.55.57) has joined #mythtv | |
| [19:35:18] | dapper-daniel (dapper-daniel!~daniel@ppc1h1.ia.hg.tu-darmstadt.de) has joined #mythtv | |
| [19:46:30] | stoffel (stoffel!~quassel@p57B4B976.dip.t-dialin.net) has quit (Remote host closed the connection) | |
| [19:48:03] | fmilo (fmilo!~misto@64.17.253.218) has quit (Quit: fmilo) | |
| [19:58:05] | Beirdo: | elmojo: that would be more fair if you weight it based on the past year, not all time |
| [19:58:35] | Beirdo: | but yeah, still, they'd get a strong vote if weighted |
| [19:59:15] | wagnerrp: | so seven for, seven against, five abstain... |
| [19:59:37] | wagnerrp: | love these clear cut decision |
| [20:00:57] | j-rod: | my vote is not so much "don't switch back to svn" as it is "give git more of a chance" |
| [20:01:11] | Beirdo: | mine too, really |
| [20:01:18] | j-rod: | (though if weighted, my vote means marginally more than squat) ;) |
| [20:01:44] | Beirdo: | if we switch back to svn, we need to a) plan the switchback very carefully, and b) have a git overlay like we had before :) |
| [20:02:15] | Beirdo: | either way, it will take time unless we wanna make a mess and not learn from our first mess |
| [20:03:07] | Beirdo: | so, while we are taking time anyways... let's give git a chance during that time, and whether it's end of release cycle or not, we need some time to trial this before switching back |
| [20:03:12] | wagnerrp: | personally, im just going with the flow one way or the other |
| [20:03:23] | Beirdo: | and some time to build out any future transition plan |
| [20:03:29] | wagnerrp: | i just think switching back to svn, while maintaining commit history, will be a complete PITA |
| [20:03:44] | Beirdo: | it will be, but we'll do it if we have to |
| [20:04:14] | Beirdo: | and it will need to be planned out, and will need a commit-moratorium while doing it, etc. |
| [20:04:30] | JEDIDIAH__ (JEDIDIAH__!~jedi@cpe-76-185-72-21.tx.res.rr.com) has quit (Remote host closed the connection) | |
| [20:04:31] | Beirdo: | it's not a big switch on the wall switching either direction |
| [20:04:39] | JEDIDIAH__ (JEDIDIAH__!~jedi@cpe-76-185-72-21.tx.res.rr.com) has joined #mythtv | |
| [20:04:48] | elmojo: | Beirdo: I was totally joking, again... sorry I'll stop from now on |
| [20:05:03] | Beirdo: | elmojo: it does have SOME relevance, of course :) |
| [20:05:27] | Beirdo: | I mean, someone who never commits at all shouldn't be too worried about what we use |
| [20:05:28] | elmojo: | I rather just not be involved in the vote as I don't think I should count... seriously |
| [20:05:50] | elmojo: | and I'm not going to quit if we stick with git |
| [20:05:53] | Beirdo: | of course, everyone counts... the vote isn't the important thing, really |
| [20:05:59] | elmojo: | I just want this bickering to stop sooner rather than later |
| [20:06:18] | Beirdo: | solving the issues is what I want to see. Regardless of how we need to do it. |
| [20:06:21] | elmojo: | we are collectively doing more harm by the process than the ultimate decision will cause |
| [20:06:50] | Beirdo: | so if there are real issues on the table, we need those to be respectfully aired, listened to, and respectfully listen to counter-arguments, etc. |
| [20:06:57] | Beirdo: | agreed |
| [20:07:28] | Beirdo: | I think what the voting thing does, primarily is: 1) shows we have some issues to solve and then 2) divides the team |
| [20:07:36] | Beirdo: | I like #1. #2 can go to hell |
| [20:08:57] | Beirdo: | now if we can be civil with one another long enough to talk things through, I'm sure we will come up with a good result that we can all live with |
| [20:09:25] | Beirdo: | polarizing into two camps with our own protest slogan signs just doesn't work :) |
| [20:16:16] | Chutt: | paul's email just now has most of the important points in it |
| [20:16:57] | elmojo: | except that he wasn't told that it requires the sacrifice of a "range-free" chicken for some commands to work :) |
| [20:17:21] | Beirdo: | hehe |
| [20:18:04] | Beirdo: | and nobody promised all would be wonderful in 2 weeks |
| [20:18:33] | Chutt: | that's not the point, though |
| [20:19:13] | Chutt: | learning a new vcs isn't fun |
| [20:19:26] | Chutt: | well, for most people :p |
| [20:21:14] | Beirdo: | understood |
| [20:21:18] | j-rod: | it was quite maddening for me for a while. it only became "fun" after some number of "aha!" moments. but none of which were in the first four weeks, best as I can recall. |
| [20:21:31] | Chutt: | it's different when it's for your job, etc |
| [20:21:40] | Chutt: | when you're spending your limited free time on it |
| [20:21:47] | Chutt: | whole different can o worms |
| [20:21:54] | Beirdo: | which is why the Git for SVN users page is so useful |
| [20:22:08] | Beirdo: | essentially, you don't need to learn much extra AT FIRST :) |
| [20:22:18] | Beirdo: | but yes, it's a learning curve |
| [20:22:19] | Chutt: | right, but you still have to be a lot more careful |
| [20:22:25] | Beirdo: | true |
| [20:22:29] | Chutt: | it's a lot easier to screw up your tree |
| [20:22:34] | Chutt: | even following instructions/etc |
| [20:22:43] | jya (jya!~avenardj@mythtv/developer/jya) has quit (Quit: jya) | |
| [20:23:05] | Beirdo: | Ummm, not so sure I agree there. I've had SVN screw up my local checkout numerous times in funky ways |
| [20:23:23] | Chutt: | eh |
| [20:23:39] | Beirdo: | git allows *you* to screw up your tree, whereas svn sometimes did it for me without me asking |
| [20:23:45] | Chutt: | i dunno – i _still_ have occasions where it's easier to just blow away and re-pull the tree with git |
| [20:24:04] | Beirdo: | and that's a significant issue with svn historically, hopefully has been fixed since |
| [20:24:15] | j-rod: | why not git reset --hard origin/master? |
| [20:24:33] | Beirdo: | my former job, we had svn eat itself on our production repository about every other week |
| [20:24:34] | Chutt: | j-rod, ah, well, it's not a full re-pull (using repo) |
| [20:24:46] | Chutt: | just redoes the local tree |
| [20:26:15] | Beirdo: | an/win 11 |
| [20:26:20] | Beirdo: | dang keyboard |
| [20:30:19] | balor (balor!~aidan@87.127.55.57) has quit (Ping timeout: 255 seconds) | |
| [20:31:53] | stuartm: | Beirdo: I think that 'at first' is telling, no-one that I recall qualified their early promises by mentioning that it wouldn't stop at git pull/add/commit/push |
| [20:33:01] | jya (jya!~avenardj@mythtv/developer/jya) has joined #mythtv | |
| [20:33:52] | ** elmojo goes off to build a time machine so he try and save us all ** | |
| [20:34:22] | stuartm: | elmojo: good luck |
| [20:34:37] | Beirdo: | it can if you want it to... if that workflow fits what you need, that's about all there is to it |
| [20:35:14] | Beirdo: | occasional merge conflicts aside, that's the core of a basic workflow that works. |
| [20:35:24] | elmojo: | that's the workflow I use + --rebase because I'm a wild and crazy kinda of guy |
| [20:35:36] | Beirdo: | and there's more to svn than svn up, svn commit |
| [20:35:43] | elmojo: | doing --rebase == skydiving |
| [20:35:55] | Beirdo: | but that is the basis of a perfectly sane svn workflow too |
| [20:41:16] | SteveGoodey (SteveGoodey!~steve@host86-147-81-4.range86-147.btcentralplus.com) has joined #mythtv | |
| [20:41:36] | jya (jya!~avenardj@mythtv/developer/jya) has quit (Quit: jya) | |
| [20:42:00] | Beirdo: | elmojo: yeah, skydiving... or bungee jumping off a bridge, perhaps :) |
| [20:42:04] | Beirdo: | heh |
| [20:43:21] | stuartm: | in theory it ends there, in practice you need to also need to know stuff like 'git stash', 'git pull --rebase' at a bare minimum but maybe I'm being overly picky there |
| [20:44:30] | Beirdo: | well, you can live without either of those |
| [20:44:48] | Beirdo: | just means you'll have a slightly more messy history |
| [20:44:57] | Beirdo: | which isn't the end of the world |
| [20:45:33] | stuartm: | Beirdo: nah you can't, not if you want to pull without losing local changes |
| [20:46:03] | Beirdo: | yes you can. You commit the local changes first :) |
| [20:46:17] | Beirdo: | as I said... messier history |
| [20:46:28] | Beirdo: | but it can be done |
| [20:47:32] | stuartm: | I keep wanting what I say to be the last thing I ever say on this subject but it seems I'm just unable to ignore some of the things which get said (or not said) – I have the overwhelming impression that those in the pro-git camp will never grasp why we describe git as overly complicated nor why we see that as a problem, it keeps coming back to one of two replies a) You'll learn and get used to it or b) You don't understand and therefore your |
| [20:47:33] | stuartm: | using it wrong – both of which miss the point entirely |
| [20:48:51] | kenni (kenni!~kenni@pfsense.dhcp.pop.k-net.dk) has quit (Read error: Operation timed out) | |
| [20:49:11] | stuartm: | Beirdo: well very messy history if those local changes are incomplete and messier still if those local changes encompass more than one line of work since you can't pick and choose what you later push |
| [20:49:25] | Beirdo: | agreed |
| [20:49:26] | Beirdo: | :) |
| [20:49:37] | Beirdo: | nasty messy |
| [20:49:49] | Beirdo: | but it *can* be done (shudder) |
| [20:51:38] | stuartm: | right, it *can* be done, but should *not* be done and there's the slippery slope, before long you need to know those commands/arguments you didn't need to know ;) |
| [20:51:54] | Beirdo: | there are ways around all that, but that requires using local branches for all work. |
| [20:52:59] | Beirdo: | but yeah, there are a few commands that end up in your arsenal |
| [20:53:16] | Beirdo: | same goes for svn... you need to learn more than the basics fairly quickly |
| [20:53:35] | Beirdo: | to a smaller extent, perhaps |
| [20:54:54] | stuartm: | more commands, more work, etc but as noted already, this argument seems to fall on deaf ears because for some that extra work is part of the fun – per my sed/grep/auk comment earlier, some people just like the hard way |
| [20:56:52] | Beirdo: | be back in a bit... need lunch. |
| [20:57:05] | stuartm: | just like everyone knows how to make a cup of coffee (it's not hard to learn the steps) but many people would sooner stop at the coffee shop on their way to work than stop to make their own at home |
| [20:57:05] | dapper-daniel (dapper-daniel!~daniel@ppc1h1.ia.hg.tu-darmstadt.de) has quit (Remote host closed the connection) | |
| [20:58:02] | stuartm: | I don't know why I bother with all the analogies, not one of them has so far resonated with anyone ;) |
| [20:58:09] | Beirdo: | hehe |
| [20:58:10] | j-rod: | stuartm: I don't think its more "fun" per se, its rather that I see it as acceptable overhead for the power and flexibility I get with git |
| [20:58:28] | j-rod: | yes, some things require a handful more commands and perhaps a bit more caution |
| [20:59:00] | iamlindoro: | Why get a cup of coffee when you can have the grounds mashed by teensy elves, deposit them in a microfiber filter, strain through mountain spring water conditioned to the perfect Ph level, all with swiss level toasting and browning accuracy? I mean, surely you don't just want a cup of coffee, do you? My way is SO MUCH MORE POWERFUL! |
| [20:59:03] | stuartm: | j-rod: right and for those that neither need nor want that additional power, the overhead is not acceptable |
| [20:59:49] | j-rod: | which is why I suggested perhaps something living in the repo root that would reduce the overhead of things like git stash |
| [21:00:07] | j-rod: | because then those who don't want to hassle with the overhead don't have to |
| [21:00:19] | j-rod: | but those who want to use additional batshit crazy git features can |
| [21:00:47] | j-rod: | of course, I'm talking in a purely hypothetical sense here, given that I don't commit squat myself :) |
| [21:01:16] | j-rod: | trying to help find a happy medium or some such thing |
| [21:01:52] | iamlindoro: | Are we seriously still being told we haven't read the documentation? |
| [21:01:57] | stuartm: | no-one here is arguing against anyone's rights to use git, if git rocks your world then so be it, but it's not for everyone and yet everyone is being dragged along (kicking and screaming) |
| [21:02:09] | iamlindoro: | Do I have to take a quiz to prove that I have, so that I can stop hearing it on developers? |
| [21:03:11] | j-rod: | but how does one half use git and the other not? |
| [21:03:49] | iamlindoro: | Wasn't Janne maintaining a git mirror for at least a year, and doing all his work there? |
| [21:03:54] | iamlindoro: | couldn't one just do that? |
| [21:04:12] | iamlindoro: | Heck, there could even be an official git mirror for all I care |
| [21:04:22] | j-rod: | I was just going to say, perhaps the "official" master repo could have stayed svn, then add an official-ish git mirror of it |
| [21:04:37] | j-rod: | that's what xbmc has, iirc |
| [21:04:50] | iamlindoro: | I'd just really, really like proper revisioning back, and the ability to work with relative ease and peace of mind restored |
| [21:05:15] | j-rod: | by "proper revisioning" you mean "sequential revision numbers", I presume? |
| [21:05:28] | iamlindoro: | Yes. Perhaps I shoudl have said "comprehensible" |
| [21:05:32] | j-rod: | :) |
| [21:06:15] | high-rez: | what's hard to understand tha rev e2fju324oiuejgklqj3gv9gu3ewfv comes after rev 23fuewklvjqoiewfvjhq3ityi3wfer ? |
| [21:06:48] | stuartm: | thank the Gods for mouse driven cut & paste is all I can say |
| [21:07:05] | j-rod: | of course, there *is* a magic decoder ring, but yeah, its not quite as immediately obvious as svn revision numbers :) |
| [21:07:57] | j-rod: | but why does that matter so much? (I'm honestly wondering, not trying to be a dismissive dick or anything, honest) |
| [21:08:35] | iamlindoro: | Because like everything else git, it adds four extra steps to get information that should be obvious just from looking at it |
| [21:08:41] | j-rod: | the scm not constantly getting in your way I fully understand though. ;) |
| [21:08:53] | stuartm: | of course I can't copy/paste between machines, and I don't have a photographic memory, which makes looking up a commit on my laptop from a sha1 hash on my desktop trickier |
| [21:09:48] | j-rod: | iamlindoro: well, not every piece of info is harder to get at... |
| [21:10:05] | iamlindoro: | The counter argument from the people who like git is that "revision doesn't specify branch," but that's not strictly true either-- Since the progression of commits is shared amongst branches, you have a relative and absolute progression of the timeline that is obvious without any lookups |
| [21:10:05] | j-rod: | git log tells me a TON more about what's happened code-wise than svn log ever did |
| [21:10:58] | iamlindoro: | j-rod: Yeah, but we had a beautiful, working timeline/code browser in trac, not to mention nice trac integration before |
| [21:11:02] | j-rod: | I don't have a clue how to tell who changed a specific file when or how using just svn at a console |
| [21:11:16] | iamlindoro: | git log filename? |
| [21:11:21] | iamlindoro: | er svn log filename |
| [21:11:22] | iamlindoro: | that is |
| [21:11:35] | j-rod: | does that show me the actual changes to that file too? |
| [21:11:50] | j-rod: | (amusingly, I know jack shit about svn…) :) |
| [21:11:57] | iamlindoro: | no, but trac did, when it used to work |
| [21:12:41] | j-rod: | that's exactly the sort of thing I think is much nicer to have available locally right in the repo, rather than having to dig through trac |
| [21:12:41] | iamlindoro: | Trac is like the human appendix now-- can't browse our code, can't track our changesets, and can't close or reference tickets |
| [21:12:49] | j-rod: | heh |
| [21:13:07] | iamlindoro: | Obviously tastes will vary, I much prefer the visual representations in trac to browsing commits in the terminal |
| [21:13:26] | SteveGoodey (SteveGoodey!~steve@host86-147-81-4.range86-147.btcentralplus.com) has quit (Ping timeout: 240 seconds) | |
| [21:13:28] | stuartm: | here's a question to which I've yet to find the answer, how can I list local commits which haven't been pushed? Imagine for a moment that some of those date back weeks and there have been lots 'pulls' since then |
| [21:13:47] | stuartm: | git log doesn't immediately help since you're searching a for a needle in a haystack |
| [21:13:57] | j-rod: | git status will tell you how many different local commits you have |
| [21:14:09] | stuartm: | the number sure, not the content of those commits |
| [21:14:21] | j-rod: | yeah, I'm having to dig through my memory and look some stuff up :) |
| [21:14:27] | iamlindoro: | git --virginsacrifice=yes --search=auto --casesensitive=no contains="searchterm" . origin/master HEAD |
| [21:14:28] | stuartm: | how can you know what you are pushing? |
| [21:14:29] | iamlindoro: | dug |
| [21:14:31] | iamlindoro: | er du |
| [21:14:32] | iamlindoro: | h |
| [21:14:37] | iamlindoro: | READ THE INSTRUCTIONS, DUMBASS |
| [21:14:53] | stuartm: | sorry, I'll go do that |
| [21:14:56] | iamlindoro: | heh |
| [21:15:10] | ** iamlindoro formally apologizes in advance to all those offended by the blowing off of git related steam ** | |
| [21:15:25] | iamlindoro: | I will keep all further git steam in my local git-steam branch for the rest of the hour |
| [21:15:33] | iamlindoro: | If I can figure out how to create it |
| [21:15:35] | j-rod: | a git push -n (dry-run) would tell you what it wants to push |
| [21:15:58] | j-rod: | and a git diff -p --stat origin will show you what's different in your local tree |
| [21:16:15] | j-rod: | but I'm not sure how to see just the log entries for the non-pushed changes |
| [21:16:36] | j-rod: | I typically rebase all my changes on top of the latest upstream, then 'git log origin..' suffices |
| [21:17:16] | j-rod: | but if they're interspersed, yeah, I dunno. :) |
| [21:17:49] | stuartm: | hmm, push -n isn't listing the commits, at least not here |
| [21:18:40] | dekarl1 (dekarl1!~deKarl@e180146058.adsl.alicedsl.de) has joined #mythtv | |
| [21:18:49] | kenni (kenni!~kenni@pfsense.dhcp.pop.k-net.dk) has joined #mythtv | |
| [21:19:06] | stuartm: | just shows a range of hashes, I suppose it might then be possible to feed those hashes one by one to git log |
| [21:19:24] | j-rod: | git show <hash> |
| [21:19:34] | j-rod: | will show the entire commit, log entry and code changes |
| [21:20:20] | stuartm: | unfortunately that range includes all the changes between my first and last including those merged from the remote branch (origin) |
| [21:20:28] | Beirdo: | git log -p is also handy (shows the patch contents as well as the comments) |
| [21:20:53] | stuartm: | Beirdo: I've been using -u which is much the same I guess |
| [21:20:56] | Beirdo: | anyways, I STILL need to go get lunch. I suck |
| [21:21:11] | Beirdo: | yup ;) |
| [21:21:16] | stuartm: | so "push -n" isn't the answer unfortunately |
| [21:21:16] | Beirdo: | pretty much the same |
| [21:21:31] | dekarl (dekarl!~deKarl@e180146018.adsl.alicedsl.de) has quit (Ping timeout: 276 seconds) | |
| [21:22:21] | j-rod: | stuartm: bah. crud. right. since they were merged into your local branch, atop different code, the tree looks different, so they have a new hash. |
| [21:23:29] | j-rod: | so stuff like this is why I always do changes in branches and keep master pristine. then you can always pull master, and do a rebase of your changes based on master in their branch. |
| [21:23:38] | j-rod: | (yes, I know, not helping…) :) |
| [21:25:14] | j-rod: | "make all changes in branches" is the number one thing I'd suggest for making git less painful. but that in and of itself requires knowing a lot more than just the basics that mirror svn. fuck. :D |
| [21:26:10] | j-rod: | hm. I have a thought of something that might work to extract just the changes... |
| [21:26:27] | j-rod: | involves branches and rebases though |
| [21:28:47] | balor (balor!~aidan@87.127.55.57) has joined #mythtv | |
| [21:29:06] | stuartm: | j-rod: save yourself the trouble, it was a hypothetical I'd wondered about ever since I found that git status didn't list those commits, I do know at this current time what commits are in the tree/branches but thought I should be prepared for the time when it says '3 commits' and I can only account for 2 ;) |
| [21:30:07] | stuartm: | especially if I then have to track down and remove a commit before I can safely push |
| [21:34:28] | elmojo: | yes, a git pull --rebase would be the only way I would know which commits haven't been pushed yet |
| [21:34:51] | elmojo: | but using --rebase is still being advocated as too dangerous at this point |
| [21:38:52] | balor (balor!~aidan@87.127.55.57) has quit (Ping timeout: 240 seconds) | |
| [21:55:55] | stuartm: | http://www.bbc.co.uk/blogs/markkermode/2011/0 . . . works_1.html |
| [21:56:16] | stuartm: | oops, that was meant for -users |
| [21:56:34] | stuartm: | but still, it's good for a chuckle |
| [21:57:09] | Steve_Goodey (Steve_Goodey!~steve@host86-147-81-4.range86-147.btcentralplus.com) has quit (Remote host closed the connection) | |
| [22:07:40] | lyricnz (lyricnz!a435de15@gateway/web/freenode/ip.164.53.222.21) has joined #mythtv | |
| [22:11:01] | highzeth (highzeth!~hz@hoiseth.no) has quit (Ping timeout: 260 seconds) | |
| [22:17:55] | highzeth (highzeth!~hz@hoiseth.no) has joined #mythtv | |
| [22:23:16] | highzeth (highzeth!~hz@hoiseth.no) has quit (Ping timeout: 260 seconds) | |
| [22:27:54] | j-rod is now known as j-rod|afk | |
| [22:29:36] | highzeth (highzeth!~hz@hoiseth.no) has joined #mythtv | |
| [22:36:40] | highzeth (highzeth!~hz@hoiseth.no) has quit (Ping timeout: 246 seconds) | |
| [22:45:00] | iamlindoro: | sigh |
| [22:45:06] | iamlindoro: | "PLEASE do not post anything to this ticket unless you have a patch or comment is solicited, or I will lock it." |
| [22:45:22] | stuarta: | oh well |
| [22:45:24] | iamlindoro: | I guess I should be happy that it only took three hours for them to do so anyway |
| [22:45:40] | iamlindoro: | I mean, three hours is an improvement over the seconds that it would usually take |
| [22:45:57] | stuarta: | clearly all still got a new year hangover |
| [22:54:52] | natanojl (natanojl!~jonatan@c83-252-237-63.bredband.comhem.se) has quit (Ping timeout: 240 seconds) | |
| [22:59:46] | dakeyras (dakeyras!~dakeyras@pool-173-64-149-152.sttlwa.fios.verizon.net) has joined #mythtv | |
| [23:00:28] | NightMonkey (NightMonkey!debian-tor@pdpc/supporter/professional/nightmonkey) has joined #mythtv | |
| [23:00:50] | jya (jya!~avenardj@mythtv/developer/jya) has joined #mythtv | |
| [23:12:36] | stuartm: | iamlindoro: or like me they didn't see that warning attached to that ticket |
| [23:12:46] | stuartm: | of course it's a general rule anyway |
| [23:15:02] | iamlindoro: | stuartm, It was on the users list |
| [23:15:13] | iamlindoro: | someone asked for the ticket number, I provided it with that admonition |
| [23:15:14] | iamlindoro: | and poof |
| [23:15:31] | stuartm: | ah |
| [23:16:30] | ** stuarta kicks off another OSX bootstrap ** | |
| [23:19:43] | stoffel (stoffel!~quassel@p57B4B976.dip.t-dialin.net) has joined #mythtv | |
| [23:23:19] | andreax1 (andreax1!~andreaz@p57B95AF2.dip.t-dialin.net) has joined #mythtv | |
| [23:23:30] | andreax (andreax!~andreaz@p57B95A2F.dip.t-dialin.net) has quit (Ping timeout: 265 seconds) | |
| [23:29:22] | stuartm: | dblain: it might be an edge case but SSDP discovery doesn't work if you start a second frontend on a machine, we don't go through UPNP initialisation if we cannot bind the http server port but as far as I can tell that's not actually needed for SSDP? So the question is, can we call InitialiseSSDPOnly() in the event that MediaRenderer() is unable to bind the http port? |
| [23:38:12] | Beirdo: | oh, BTW. dblain: if you want to steal any/all of the UPnP tickets from me, just let me know and/or steal em :) |
| [23:38:27] | Beirdo: | since ya already pinged him :) |
| [23:45:40] | Kunalagon (Kunalagon!~Kunalagon@212.200.241.52) has quit (Quit: Leaving.) | |
IRC Logs collected by
BeirdoBot.
Please use the above link to report any bugs.