| superm1 | Shred00: upstream mythtv does have an infrastructure in place that does builds on every commit to make sure the project remains buildable | 00:50 |
|---|---|---|
| Shred00 | superm1: cool. accessible repo? | 00:51 |
| superm1 | Shred00: i don't believe it gets packaged | 00:51 |
| superm1 | it's just a test on debian, osx, fedora, and gentoo i think | 00:51 |
| superm1 | to make sure all related libraries will link and build etc | 00:51 |
| superm1 | oh and windows | 00:51 |
| superm1 | but otherwise what tgm4883 said is right about how our builds work | 00:52 |
| superm1 | if there is a commit that breaks things really badly on a day that was fixed mid-day we'll do interim builds, but usually just rely on the daily "if something changed" build once today | 00:52 |
| Shred00 | is that a PPA build farm policy or local "Mythbuntu Developers” team policy? | 00:55 |
| Shred00 | because istm that for the ppa build machines, an idle machine is a wasted machine when it could be otherwise used to provide more frequent builds. but that's just mho having deployed and use a jenkins build farm at my day job. :-) | 00:57 |
| superm1 | well i don't know if there is an official PPA build farm policy, but other projects do similar things where they won't generally exceed more than one build per day | 00:59 |
| superm1 | and generally we're in a queue waiting an hour or two for our builds, so it's not like the machines are idle throughout the day | 00:59 |
| Shred00 | yeah, i'm seeing that we're already in the queue 32 minutes | 01:00 |
| superm1 | https://bugs.launchpad.net/launchpad/+bug/393546 sounds like it has been a problem for some projects who's builds took a long time | 01:02 |
| Zinn | [bugs.launchpad.net] Bug #393546 “Long running builds can monopolise the build farm” : Bugs : Launchpad itself | 01:02 |
| === baggar11_ is now known as baggar11 | ||
| superm1 | and according to https://launchpad.net/builders it looks like all PPA builders at this moment are keeping busy too | 01:05 |
| Zinn | [launchpad.net] The Launchpad build farm | 01:05 |
| Shred00 | i guess ultimately, i wouldn't even think this should be a decision the ppa user makes. were i in charge of the ppa farm i'd have a policy that every project gets queued to build as soon as it is different since the last build (i.e. a commit is made) but that it only gets built when it's "turn" comes up, where turn is defined as a FIFO queue of pending builds or 24h, whichever comes first. if the queue cannot regularly be ser | 01:05 |
| Shred00 | heh. lots of idle armel. :-) need to trade them in for some arm64s. :-) | 01:06 |
| superm1 | haha | 01:06 |
| superm1 | i think your message got cut off | 01:06 |
| superm1 | last saw was "if the queue cannot regularly be ser" | 01:06 |
| Shred00 | viced fully in 24h, you need more machines. as i said before, this is quite how jenkins works. i wonder if the ppa buildfarm is a home-grown jenkins-like framework and if so, why something like jenkins was not taken off the shelf for it. | 01:07 |
| Shred00 | 3 idle amd64 nodes interestingly | 01:07 |
| Shred00 | ditto for i386. i wonder why that is | 01:07 |
| superm1 | personally i haven't looked through the launchpad code to see much how it works | 01:07 |
| superm1 | but i think jenkins wasn't taken off the shelf because it's not really designed initially for projects to do uploads so frequently i think, but to act more like a debian queue | 01:08 |
| superm1 | it just so happens that projects like ours, and chromium and mozilla happened to adapt it for more frequent builds via external snapshot and upload scripts | 01:08 |
| Shred00 | jenkins will do builds as frequently as you can provide changes for it. yes, ideally it watches an SCM repo for changes but i wouldn't think having it accept tarballs, etc. to build would be difficult. | 01:09 |
| Shred00 | "allspice" has been idle for 21 minutes for example. | 01:09 |
| Shred00 | previous to that there was a 22 minute idle window between builds | 01:10 |
| superm1 | well the other thing you have to keep in mind is the downstream users of these PPAs. at least the mythtv packages have a dependency where amd64's packages need some of the i386 packages for dependencies | 01:11 |
| Shred00 | hrm. only 21 minutes of build time in the window of 1 hour ago -> 2 hours ago. | 01:11 |
| superm1 | so if builds were happening so frequently that they got skewed, the PPA is no longer usable | 01:11 |
| Shred00 | really? what's an example of an i386 dependency that amd64 packages have? just curious. | 01:12 |
| superm1 | basically any package that is "arch: all" | 01:13 |
| superm1 | only gets built by i386 | 01:13 |
| Shred00 | ahh. ok. no binary i386 dependencies. that would annoy me. :-) | 01:14 |
| superm1 | there used to be more arch all packages, but we switched some to arch any because of the build skew problem causing so many issues for users | 01:14 |
| superm1 | also the exact same reason the mythtv source package now contains mythtv, mythplugins, mythweb, and any themes. we were getting skew because the packages would take so long to build 4 different packages that had a variety of arch all packages | 01:14 |
| Shred00 | i'm still using i386, so i don't see this. :-D | 01:15 |
| Shred00 | https://answers.launchpad.net/launchpad/+question/190498 in case anyone wants to follow along... going to relax now though... | 01:19 |
| Zinn | [answers.launchpad.net] Question #190498 : Questions : Launchpad itself | 01:19 |
| superm1 | oh that looks like a fairly quick answer too then | 01:58 |
| superm1 | cool | 01:58 |
| Shred00 | indeed. as i noted in my followup, it's too bad the bare-metal hardware is not re-distributed as Xen VM hosts while demand for official builders is low. but an informative answer all the same. | 02:00 |
| gamerdonkey | !help | 04:55 |
| Zinn | !help For a complete list of my knowledge visit: http://www.baablogic.net/Zinn.cgi Other available commands: !status, !about, !bug [bug_number]. | 04:55 |
| gamerdonkey | I'll have to be going to bed soon, I've been messing with MythTv all night, but I'll check in the morning so here's my question: | 05:01 |
| gamerdonkey | I can do a channel scan and it picks up all the stations that I could find when I had the antenna plugged directly into my TV, but when I try to watch TV in Myth I only see an all pink screen with no audio. | 05:02 |
| gamerdonkey | I can get videos files on the computer to play just fine, and I've messed with my playback options (CPU+,Normal,Slim,VD-something), so I'm not sure what to do next. Is there any kind of test for my card I can try? | 05:03 |
| gamerdonkey | Oh yeah, my card is a Hauppauge HVR-1600 and I'm running MythBuntu | 05:08 |
| Chaorain | Hey, I'm looking for the "proper" format for tv episode titles. I have a series stored on my HD but the names are inconsistant. | 05:22 |
| superm1 | gamerdonkey: if you've already experimented with the different playback options, it sounds like you might not have the graphics drivers for your gfx card installed | 06:05 |
| superm1 | check the "Hardware Drivers" tool to see | 06:05 |
| gamerdonkey | thanks superm1, I'll try that tonight | 12:50 |
| BLZbubba | hello, i did the 10.10 -> 11.10 upgrade and mythtv is no longer reading the IR events. irw shows the correct key presses. did something change to how mythtv works with lirc? | 14:34 |
| superm1 | BLZbubba: re-run mythbuntu-lirc-generator | 14:37 |
| BLZbubba | ok i'll give that a try, t hanks | 15:02 |
| === qwebirc79972 is now known as synapseattack | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!