[01:04] <defendguin> superm1 i got my dvi to hdmi cable  :-)
[01:04] <superm1> nice defendguin
[01:04] <superm1> try it yet/
[01:04] <defendguin> yup
[01:04] <defendguin> TV is about the same but there is a much better difference in the gui
[01:05] <superm1> well as expected, same tv content
[01:05] <defendguin> the fonts on the program manager are tiny
[01:06] <superm1> what resolution you running at now?
[01:06] <defendguin> no idea
[01:06] <defendguin> ouch
[01:07] <superm1> well you can hit ctrl alt right
[01:07] <superm1> and right click the desktop
[01:07] <superm1> and then type xrandr
[01:07] <superm1> in the temrinal
[01:07] <defendguin> i'll ssh in
[01:08] <defendguin> hmmm that doesn't seem like the right number though
[01:08] <superm1> you'll need to export DISPLAY=:0
[01:08] <superm1> on ssh
[01:08] <superm1> to see xrandr info
[01:09] <defendguin> it says 640x480
[01:10] <superm1> well thats not good.... you need that higher
[01:10] <superm1> it should be running 1280x720
[01:10] <superm1> or 1920x540
[01:10] <superm1> or 1920x1080
[01:10] <defendguin> for a regular TV?
[01:10] <superm1> oh regular tv.....
[01:10] <defendguin> yeah
[01:11] <superm1> can you pastebin /var/log/Xorg.0.log
[01:12] <defendguin> http://pastebin.ca/526759
[01:13] <defendguin> the normal dashboard is fine but any of the preferences dialogs the font is so tiny its unreadable
[01:14] <superm1> you probably need to set the DPI appropriately
[01:15] <defendguin> is that something i need to change in my xorg.conf?
[01:15] <superm1> for DPI, yes
[01:15] <superm1> its being set to 25,25 according to that log
[01:16] <superm1> do you have any funny modelines or anythign in your xorg.conf
[01:16] <superm1> given the fact that you have UseEdidDpi on?
[01:16] <defendguin> Section "Monitor"
[01:16] <defendguin>     Identifier     "Generic Monitor"
[01:16] <defendguin>     HorizSync       28.0 - 51.0
[01:16] <defendguin>     VertRefresh     43.0 - 60.0
[01:16] <defendguin>     Option         "DPMS"
[01:16] <defendguin> EndSection
[01:16] <superm1> there you go
[01:16] <superm1> comment out that horizsync and vertrefresh
[01:16] <superm1> let it figure that stuff out from the driver
[01:17] <defendguin> i dont see any DPI specifis stuff besides this
[01:18] <superm1> well you can add an option for DPI if it doesnt calculate right
[01:18] <superm1> after commenting those two out
[01:18] <defendguin> FontPath        "/usr/share/fonts/X11/100dpi"
[01:18] <defendguin>     FontPath        "/usr/share/fonts/X11/75dpi"
[01:19] <defendguin> ok i commented them out and killed X
[01:20] <defendguin> fonts still look tiny
[01:20] <superm1> is the res still 640x480 though?
[01:20] <superm1> thats what I was getting at with that
[01:21] <defendguin> yup
[01:21] <defendguin> i thought that was normal for a regular CRT
[01:21] <superm1> well i think it should be doing 1024x768, but i cant be certain
[01:21] <defendguin> wouldn't that make the fonts look smaller?
[01:22] <defendguin> if the resolution were increased
[01:22] <superm1> well here is how ot fix the dpi
[01:22] <superm1> in the monitor section
[01:22] <superm1> add this:
[01:22] <superm1> Option "DPI" "100x100"
[01:22] <defendguin> ok
[01:23] <defendguin> lets see what that does
[01:23] <defendguin> much better
[01:23] <defendguin> hmmm i may try 75 75
[01:24] <defendguin> this is a bit big
[01:24] <superm1> 100x100 is the recommended size for tvs
[01:24] <superm1> especially once you make the tv work at 1024x768 (if you can)
[01:25] <superm1> okay time for me to get going.  i'll be back on later this evenin likely
[01:25] <defendguin> ok 75 75 looks about right for this resolution
[01:40] <rogue780|mythser> anyone here use proftpd
[01:41] <rogue780|mythser> ?
[03:14] <tgm4883_laptop> whats the correct way to purge the mythtv database for a reinstall
[03:31] <Xenocide> superm1, myth looks fantastic on hdtv
[03:31] <Xenocide> i coudnl't believe it
[04:07] <superm1> hehe
[04:07] <superm1> yes it does
[04:07] <superm1> you need hd content now
[07:15] <defendguin> yo yo
[09:17] <gardengnome> morning
[03:52] <superm1> imbrandon, you there?  Wanted to ping you again about getting pegasus to build on buildds.
[04:16] <imbrandon> superm1, i'm here ( and off work today ) so i'll do it nowish
[04:27] <superm1> awesome imbrandon thanks :)
[04:28] <imbrandon> superm1, np, i'll poke in here when i get it updated
[04:28] <gardengnome> i hope the mainboard will behave in this new case. otherwise i'm gonna have a crying fit :)
[04:28] <superm1> gardengnome, what was happening in your old box?
[04:30] <gardengnome> it would hang on reboot after a few hours. i suspect it happened because the case was bent slightly and would stress the PCB
[04:30] <gardengnome> maybe some hair crack.
[04:30] <gardengnome> i'll find out
[04:30] <gardengnome> if it survives one week, i'll keep it
[04:31] <superm1> hopefully that resolves it...
[04:31] <gardengnome> yes
[04:31] <superm1> I was looking at my 'sensors' output yesterday for one of my boxes that is unstable
[04:31] <superm1> -12V:  -18.27V
[04:31] <gardengnome> although i put a lot of work into that old case.
[04:31] <gardengnome> wow
[04:31] <gardengnome> sounds good
[04:31] <superm1> i dont know if the sensor is failing or if that might be the cause
[04:31] <gardengnome> did you check that with a fluke meter?
[04:31] <superm1> because in the bios there isnt even a -12V output
[04:31] <superm1> i didnt bring my mult to my internship
[04:31] <superm1> left it at school
[04:32] <gardengnome> they should equip cell phones with those
[04:32] <superm1> haha
[04:32] <superm1> even so though, where can I find a -12V rail for sure to probe?
[04:32] <superm1> the pings on the atx connector aren't exposed
[04:32] <superm1> s/pings/pins/
[04:32] <gardengnome> make them so then ;)
[04:33] <superm1> thats safety there.
[04:33] <gardengnome> true
[04:33] <gardengnome> which is also the reason why i'll be replacing a few PSUs here. i'm not comfortable anymore with some because i'd exchange fans in them a few years ago
[04:34] <superm1> well the thing is this whole machine was just built in august last year
[04:34] <superm1> and its been this way since
[04:35] <superm1> every 24 - 89 hours it will freeze
[04:35] <superm1> with an indiscernable kernel oops
[04:35] <gardengnome> great
[04:35] <superm1> and i've yet to figure out what it was in the box causing it
[04:37] <gardengnome> VIA? ;)
[04:38] <superm1> nope :(
[04:38] <superm1> i pulled out all the tuners in it too
[04:38] <superm1> its just got a few hard drives, a gig of ram and a video card now
[04:38] <superm1> (and of course memtest comes up clean)
[04:38] <gardengnome> the GF donated her old computer. i found out that 7-8 capacitors are broken +after* installing my capture card. now she's told me she knew about that *sigh*
[04:39] <superm1> haha
[04:39] <gardengnome> i should throw away everything even remotely related to computers, sell some internal organs to get money and start over with fresh, working parts.
[07:14] <gardengnome> rogue780|mythser: :)
[08:38] <superm1> imbrandon, once you've got the buildd account set up, 'sudo weekly_build' will build source packages on pegasus.  it should be in your $PATH (its in /usr/local/bin).  The resultant packages end up in /var/cache/mythbuntu_build/builds/pool/feisty/weekly
[08:45] <superm1> imbrandon, and falcon is set up on there too already - so 'su mythbuntu -c "falcon update"' will handle updating when the binaries are done from the buildds
[08:49] <imbrandon> kk
[08:49] <imbrandon> sounds good
[09:50] <gardengnome> hey
[09:50] <gardengnome> is there any .deb with unofficial themes?
[09:54] <superm1> I had one, but took it down since the package is being scrapped in favor of doing debs for each one
[09:54] <superm1> the source for it is still up on revu though
[09:54] <gardengnome> oh, nifty
[09:55] <superm1> Daviey is supposed to be doing the individual ones
[09:55] <gardengnome> hum
[09:55] <superm1> and submitting them to revu and such
[09:55] <gardengnome> juski has updated his themes
[09:55] <superm1> the licensing is all settled with them and such too
[09:55] <superm1> recnetly?
[09:55] <gardengnome> i guess i'll better get the fresh ones
[09:55] <superm1> like a few days ago?
[09:55] <gardengnome> yeah
[09:55] <gardengnome> yes.
[09:55] <superm1> oh neat i better update them when i get home tonite too then
[09:55] <superm1> improvements?
[09:55] <gardengnome> um
[09:55] <gardengnome> it's shinier :)
[09:55] <gardengnome> http://juski.co.uk/
[09:56] <gardengnome> see the news there
[09:56] <superm1> shinier is typically synonymous with better  :)
[09:56] <superm1> oh no blootube updates
[09:56] <superm1> no big deal for me then
[09:57] <gardengnome> heh
[10:04] <superm1> gardengnome, hows the svn trunk packages going?
[10:04] <superm1> now that you have the mythweb patch in, whats left?
[10:04] <gardengnome> the mythweather patch still needs to go in. i have been busy with other things lately
[10:05] <superm1> oops yea i meant mythweather
[10:05] <gardengnome> right now, i'm setting up my "new" mythtv box.
[10:05] <superm1> it should hopefully apply pretty cleanly
[10:05] <superm1> is that it though?
[10:05] <gardengnome> which means i can try the packages in a better environment now
[10:05] <gardengnome> um
[10:05] <gardengnome> pretty much, yes
[10:06] <superm1> do you have hosting sorted out already for these?
[10:07] <gardengnome> well, i assumed i'd provide you with the .diff.gz/build script and you guys build them on your buildd
[10:07] <gardengnome> i've got a server, though
[10:07] <superm1> well it might make sense to just host them on mythbuntu.org
[10:08] <gardengnome> yup
[10:08] <superm1> i dont know, i'm not sure how this buildd stuff will work as of yet
[10:09] <superm1> are you adapting a revision number in the version naming too
[10:09] <superm1> or just dates like the current packages
[10:10] <gardengnome> i think i've got the revision and the date in tzhere
[10:11] <gardengnome> i haven't been thinking a lot about that ;)
[10:11] <superm1> are 0.20-fixes revision numbers the same as trunk?
[10:11] <superm1> or a completely different scheme?
[10:11] <gardengnome> they're the same as trunk.
[10:12] <superm1> hm
[10:12] <superm1> well perhaps that is something we both need to think about before either of us have packages set out in the wild
[10:12] <gardengnome> yup
[10:13] <superm1> perhaps instead of dates at all, use something like fixes-REVISION
[10:13] <superm1> and trunk-REVISION
[10:13] <gardengnome> that'd be smart
[10:13] <gardengnome> because dates don't mean anything
[10:13] <superm1> well for fixes, dates are fine
[10:13] <superm1> but trunk i think they mean nothing
[10:13] <superm1> more so
[10:14] <superm1> only problem is this will stray completely from the debian-multimedia way of doing things
[10:15] <gardengnome> what about the libmyth-0.20 package? maybe it's name would have to change every time the API version increases
[10:15] <gardengnome> (see mythfrontend --version)
[10:15] <gardengnome> truwe
[10:15] <superm1> well that name changed
[10:15] <gardengnome> true*
[10:15] <superm1> its reflected in my latest packaging
[10:15] <superm1> oh you mean the normal libmyth-0.20
[10:15] <gardengnome> yes.
[10:15] <superm1> not the -dev
[10:15] <superm1> yes everytime that the api changes it would have to change
[10:16] <superm1> which at most is once a year
[10:16] <gardengnome> no
[10:16] <gardengnome> way more often, at least back then...
[10:17] <gardengnome> remember, we're talking about trunk here
[10:17] <superm1> good point
[10:17] <gardengnome> Library API version     : 0.20.20070327-1
[10:17] <superm1> well i guess i dont know "how" frequently then it does change
[10:17] <gardengnome> well
[10:17] <gardengnome> the build script could change the package name
[10:17] <superm1> where does that info come from?
[10:17] <gardengnome> mythfrontend --version
[10:18] <gardengnome> yours will likely be different
[10:18] <superm1> well the build script won't know that
[10:18] <gardengnome> the build script can grep in the source
[10:18] <gardengnome> it's got to be defined somewhere
[10:18] <superm1> well whats the advantage
[10:18] <superm1> of having it in the version number though?
[10:19] <superm1> why not just use the major version number (ex trunk is 0.21 and fixes 0.20)?
[10:19] <gardengnome> well, if there's one thing i remember from reading all those maintainer guides
[10:19] <gardengnome> you are supposed to rename the package/append a version string if the API changes, AFAIK
[10:19] <gardengnome> or ABI
[10:20] <gardengnome> thing is, $stuff will break if the plugins are linked against the wrong version. usually, you'll gert a message saying that you need to recompile the plugins
[10:20] <superm1> right
[10:20] <superm1> but if plugins and mythtv are built at the same time
[10:20] <gardengnome> but that could be fixed by having the plugins depend on the right version of libmyth.
[10:20] <superm1> you upgrade both at the same time
[10:21] <superm1> well why dont you just grep for that number you had
[10:21] <superm1> for the api version
[10:21] <superm1> and see if you can find where it is in the sources
[10:21] <gardengnome> we can't just make trunk libmyh-0.21 because the API version still is 0.20.20070327-1
[10:22] <gardengnome> i'm probably just being a smart-ass here, but i don't know how this should be handled
[10:22] <gardengnome> allright, i'll grep
[10:22] <superm1> hm so many ways to handle versions here.  i wonder what is really most appropriate in a debian/changelog verison number then
[10:22] <superm1> I *think* the optimal solution is to grab the revision by svn info | grep Revision | cut -b 11-
[10:22] <superm1> or something to that effect
[10:22] <superm1> and use that
[10:23] <superm1> because then you will make plugins depend on the same Revision number
[10:23] <superm1> and you solve the api problem
[10:23] <superm1> and make ubuntu normal packages adapt the same thing
[10:23] <gardengnome> yep.
[10:24] <gardengnome> um..
[10:24] <gardengnome> wait a second
[10:24] <gardengnome> libs/libmyth/mythcontext.h:#define MYTH_BINARY_VERSION "0.20.20070327-1"
[10:24] <gardengnome> here we go
[10:24] <superm1> but again, you really dont want to mix and match in the first place different svn co's
[10:24] <superm1> of plugins and mythtv
[10:24] <superm1> so isnt svn rev# a better way to go
[10:25] <gardengnome> yes, we can fix that by using versioned depends, i guess.
[10:25] <gardengnome> superm1: see version.pro in the top level directory of the mythtv source
[10:25] <superm1> so the current naming scheme is $MAJORVERSION-svn$DATE-0.0ubuntu$UBUNTUVERSION
[10:26] <gardengnome> hum
[10:26] <superm1> I say instead we adapt $MAJORVERSION-fixes$REVISION-0.0ubuntu$UBUNTUVERSION and $MAJORVERSION-trunk$REVISION-0.0$UBUNTUVERSION
[10:27] <superm1> might need to add an epoch though to override the current naming scheme
[10:27] <superm1> because f is < s
[10:28] <gardengnome> but $REVISION can be the same for trunk and fixes
[10:28] <superm1> right
[10:28] <superm1> so we need to specify trunk and fixes in the version numbers
[10:28] <superm1> so an example would then be:
[10:29] <superm1> 0.20-fixes13585-0.0ubuntu0mythbuntu1
[10:29] <superm1> for fixes
[10:29] <superm1> 0.20-trunk13585-0.0ubuntu0mythbuntu1
[10:29] <superm1> for trunk
[10:30] <gardengnome> what would happen if an user had both repositories (for fixes and for trunk) in his sources.list?
[10:30] <superm1> keescook, could you comment about version numbers?  Would 0.20-svn20070122* be newer as recognized by debian or 0.20-fixes13585* or 0.20-trunk13585?
[10:30] <superm1> I think trunk overrides
[10:31] <superm1> because t > f
[10:31] <keescook> you can test with dpkg actually.  dpkg --compare-versions
[10:32] <keescook> dpkg --compare-versions 0.20-svn20070122 gt 0.20-fixes13585 && echo newer
[10:32] <keescook> newer
[10:32] <keescook> yeah svn > fixes
[10:32] <superm1> thats a shame, so do you need to add an epoch to override that behavior?
[10:33] <keescook> why not bump the svn date?
[10:33] <superm1> well we are considering dropping the date
[10:33] <superm1> and using revision numbers instead
[10:33] <superm1> and the word fixes and turnk
[10:33] <superm1> and the word fixes and trunk
[10:33] <gardengnome> date could still be the same for both packages
[10:33] <keescook> yeah, probably keep it for the 0.20 lifetime, and once 0.21 comes out, switch to trunk/fixes?
[10:34] <superm1> hm.  then for the current packages how is the most ideal way to handle this?
[10:35] <superm1> so that trunk will always be > fixes packages
[10:35] <superm1> and be clear that its >
[10:36] <keescook> many people use "+", so maybe 0.21-trunk  and 0.21-trunk+fixes123  ?
[10:36] <keescook> maybe I'm misunderstanding the needed packages
[10:36] <superm1> ooh.  so maybe for fixes - 0.20+fixes123 and then 0.20+trunk123
[10:37] <superm1> the idea is going to be for the weekly builds for those interested in more up to date trunk or -fixes branch packages
[10:37] <keescook> oh, I see, the svn# is going to be the same, since it's the same svn repo
[10:37] <superm1> right
[10:37] <superm1> just two different branches
[10:38] <keescook> yeah, I think that gets you what you want, t > f always.
[10:38] <superm1> still have that ugly svn in the name right now though that needs to be ditched
[10:38] <keescook> seems that "+" is > than "-"
[10:39] <superm1> oh then problem solved
[10:40] <superm1> and when 0.21 is the new version number adapted in trunk it will have to rename the package to be 0.21-trunkNUM, once 0.21 is released they will turn into 0.21+trunkNUM until 0.22 is announced
[10:42] <superm1> gardengnome, you follow that?
[10:42] <keescook> aaah, yeah, sneaky
[10:43] <keescook> stable releases get "-"'s, and the daily builds get "+"s.  I'll see if this is totally crack or not.  :P
[10:43] <gardengnome> um, yes. almost falling asleep, though :)
[10:43] <superm1> that seems like a much more sensible way to be using the +/- anyway as in 0.20 release + that
[10:43] <gardengnome> is this channel being logged?
[10:43] <superm1> yes gardengnome
[10:43] <gardengnome> good
[10:43] <gardengnome> because i'm great at forgetting things.
[10:43] <superm1> or 0.21 release - this
[10:43] <gardengnome> when do we change the trunk packages to 0.21? once they change the binary version to 0.21?
[10:43] <superm1> keescook, oh thats a step even further, you think stable should still use -svnDATE?
[10:44] <superm1> i was thinking, switch it all to this
[10:44] <superm1> yes gardengnome
[10:44] <superm1> so the weekly build script can grep for that possibly
[10:44] <superm1> won't be too bad to do
[10:45] <keescook> superm1: for gutsy, there is no reason to require -svnDATE for 0.21.  For 0.20, we should probably stick to -svnDATE.
[10:45] <gardengnome> superm1: AFAIK, the binary version is changed very shortly before a new release, so sometimes we won't even have to bother
[10:45] <gardengnome> what about changes in -fixes that break compatibility? eg when the protocol version changed in fixes after 0.20
[10:45] <superm1> okay then to summarize the decisions and make sure we're on the same page:
[10:45] <superm1> for 0.20:----
[10:45] <superm1> gutsy gets the same version numbers
[10:45] <superm1> svnDATE
[10:46] <superm1> weekly fixes get
[10:46] <superm1> 0.20+fixesNUM
[10:46] <superm1> trunk gets
[10:46] <superm1> 0.20+fixesNUM
[10:46] <superm1> for 0.21----
[10:46] <superm1> everything switches to 0.21-fixesNUM and 0.21-trunkNUM
[10:47] <superm1> err trunk gets 0.20+trunkNUM not 0.20+fixesNUM
[10:47] <keescook> line below "trunk gets" should read "0.20+trunkNUM" yeah
[10:47] <superm1> yes
[10:47] <keescook> okay, so, let's say 0.21 is released before gutsy releases.
[10:47] <keescook> what would go into gutsy, -fixes or -trunk?
[10:48] <superm1> well depends on when 0.21 happens
[10:48] <superm1> if its is like two weeks before ubuntu release
[10:48] <superm1> and we rush to get it in
[10:48] <keescook> right, I should say "before gutsy freezes"
[10:48] <superm1> i think it'd be fixesNUM where NUM is the checkout number of the ""release""
[10:48] <superm1> or possibly even just 0.21
[10:48] <superm1> with nothing attached to it
[10:49] <superm1> depending on how close to release it is
[10:50] <keescook> hm, ya know, in looking at version numbers, perhaps we shouldn't use "-" ... isn't that supposed to be reserved for the packaging revision?
[10:50] <superm1> that's what we've been using though
[10:50] <keescook> yeah, I know...
[10:50] <superm1> is that a bad idea then?
[10:51] <keescook> yeah... this is where my knowledge falls down a bit
[10:51] <keescook> for apparmor, I used "+" because I'd seen it done in places like firefox and inkscape
[10:51] <superm1> i remember reading about the +'s and -'s last year
[10:52] <superm1> because + was just introduced recently
[10:52] <superm1> in debian
[10:54] <superm1> http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-f-Version
[10:54] <superm1> so + and - and . are all valid
[10:57] <superm1> another possibility here it to migrate the packages to svn-buildpackage
[10:57] <superm1> i haven't use it before myself, but it might just make sense for this
[10:58] <keescook> isn't there a bzr-buildpackage too?
[10:58] <superm1> I think so
[10:58] <superm1> I'll add these on my todo list to look into
[10:58] <superm1> for now, the solution discussed above with the wrapper shell script i have written for weekly builds will do the trick
[11:09] <superm1> keescook, I think that once libhdhomerun gets uploaded these next few days i'm going to go for MOTU.  I'm assuming i'm supposed to CC you and other people who have sponsored on the app.  Any recommendations I should say in it?
[11:11] <keescook> superm1: I'm happy to support you going for motu.  For details, I'd just call attention to all the packages you've got in universe already.  :)
[11:11] <superm1> k :)
[11:35] <ompaul> superm1, put all your "kudos" on your wiki page before you do it, if you want ping me and I'll give you some pointers if you are not happy about it
[11:36] <ompaul> I went through it before I got into this very bad crack :)
[11:36] <superm1> sure that'd be great.  i haven't worked on my wiki page for ages
[11:36] <superm1> haha
[11:36] <superm1> last time i touched it was when i went for ubuntu member
[11:39] <superm1> ompaul, i finally got around to watching that video you sent me yesterday
[11:39] <superm1> unfortunately the questions at the end were completely inaudible
[11:39] <ompaul> woops
[11:39] <ompaul> superm1, sorry the motu was not what I went for
[11:40] <ompaul> :)
[11:40] <superm1> what'd you run for member?
[11:40] <ompaul> I used to be one
[11:40] <superm1> oh it times out?
[11:40] <ompaul> long story and nothing to do with gnewsense
[11:40] <ompaul> it does
[11:40] <superm1> oh okay
[11:40] <ompaul> but I pulled mine as I said long story
[11:41] <ompaul> keep the karma high and you will be okay :)
[11:41] <superm1> well most of the stuff I'm doing doesn't earn me karma.  hm better start using launchpad more then i guess
[11:41] <ompaul> yeap
[11:42] <superm1> was is it 2 years to time out?
[11:42] <ompaul> but what you do should get karma
[11:42] <ompaul> yeap
[11:42] <superm1> ah i got plenty of time to bump it up then
[11:42] <superm1> especially once this ubiquity mess is straight with mythbuntu
[11:42] <ompaul> superm1, the questions iirc were why was there such a low spend from the embedded people on kernel dev
[11:43] <ompaul> superm1, some file system stuff
[11:43] <superm1> i was suprised to hear about how xfs functions
[11:43] <superm1> about writing its data last
[11:43] <superm1> and metadata first
[11:43] <ompaul> superm1, ehhh stop
[11:43] <superm1> ?
[11:43] <ompaul> superm1, you are so wrong that should have been: <superm1> i was suprised to hear about how xfs malfunctions
[11:43] <superm1> haha
[11:44] <superm1> not an xfs fan?
[11:44] <superm1> lets see, likely not zfs - jfs?
[11:44] <ompaul> ext3
[11:45] <ompaul> for all things
[11:45] <superm1> how do you deal with the slow IO though?
[11:45] <ompaul> scsi if I need fast
[11:45] <superm1> i mean try copying a big file or deleting a big file
[11:45] <superm1> and see what happens to the CPU
[11:45] <superm1> its pegged
[11:45] <ompaul> file transfers are not a large part of my life
[11:46] <ompaul> so I don't suffer it a lot
[11:46] <superm1> ah -
[11:46] <superm1> well its a big problem for a mythbox
[11:46] <superm1> you can lose a lot of data if your stuck deleting a file at the same time you do video capture
[11:47] <ompaul> let me come back in a moment I want to read the wiki for a moment before I ask the next question, I want to know what I am asking :)
[11:48] <gardengnome> wee, mythweb on my PDA!
[11:48] <gardengnome> \o/
[11:48] <superm1> k
[11:48] <superm1> gardengnome, your not cool until you have mythweb on opera mini on a little mobile phone screen.....
[11:48] <superm1> but on a pda is still pretty neat :)
[11:48] <gardengnome> (loading the guide just cost me 2x 0.19. fsck.)
[11:49] <superm1> damn why?
[11:49] <gardengnome> superm1: it's a palmone treo and i_'m using GPRS. does that count? ;)
[11:49] <superm1> Yes it does.
[11:49] <superm1> gardengnome, your now cool.
[11:49] <gardengnome> superm1: because my phone plan is really expensive for GPRS. i'll get a better one for this PDA
[11:49] <gardengnome> 24 cent for one megabyte sounds reasonable to me
[11:49] <superm1> you guys dont have unlimited plans?
[11:49] <gardengnome> we do
[11:50] <gardengnome> but i'm not going to pay 30/month just for that
[11:51] <superm1> i guess i can see that.  its only $10 a month here for one, so i can easily justify it
[11:51] <gardengnome> true
[11:51] <superm1> with how much time i spend reading gmail in the car on the way anywhere
[11:51] <gardengnome> i usually spend two or three bucks for my phone a month, that's why i don't like expensive plans.
[11:52] <gardengnome> i'll go prepaid for my GPRS needs
[11:52] <gardengnome> ICQ and SSH on the palm is cool, too
[11:53] <superm1> gotta be slow though
[11:53] <gardengnome> although screen and irssi are a bit hard to use
[11:53] <ompaul> superm1, so looking at the other stuff in that video would you think there should be some motivation for the acsync kernels and aio for the drive
[11:53] <gardengnome> superm1: ssh?
[11:53] <ompaul> sorry
[11:53] <superm1> aio for the drive?
[11:53] <ompaul> superm1, so looking at the other stuff in that video would you think there should be some motivation for the acsync kernels / aio to drive it forward
[11:53] <superm1> gardengnome, yes ssh slow i'd think
[11:53] <ompaul> I should go to bed :)
[11:53] <gardengnome> superm1: right, but it's usable
[11:54] <gardengnome> superm1: vim might give you fits, but it's ok for quick checks
[11:54] <superm1> ompaul, what vendor would benefit most from async kernels is the real question
[11:54] <superm1> acsync*
[11:54] <ompaul> ya - google I suppose
[11:55] <ompaul> all them clock cycles going to waste being used for counting not working
[11:55] <superm1> gardengnome, i was really proud when i drove home last year (roch to chic) and help a mobile phone int connection for 4 hours
[11:55] <superm1> chatting away on aim
[11:55] <superm1> and gtalk
[11:56] <gardengnome> superm1: i hope you were not the one operating the car ;)
[11:56] <superm1> haha nope
[11:56] <superm1> ompaul, does google sponsor any kernel dev ever?
[11:56] <gardengnome> superm1: it's pretty sad: being online while interacting with the real world ;)
[11:56] <ompaul> andrew morton?
[11:56] <gardengnome> superm1: um, andrew morton?
[11:56] <ompaul> superm1, ^^
[11:56] <ompaul> superm1, they have several on staff
[11:56] <superm1> ompaul, wasnt sure :)
[11:56] <superm1> dont look into that sort of thing very often
[11:57] <ompaul> superm1, the guy who was talking was am :)
[11:57] <superm1> i should have specified - other than him :)
[11:58] <superm1> okay guys i need to get going.  few more sims to go and then i'm headed home
[11:58] <superm1> ompaul, get some sleep
[11:59] <ompaul> superm1, I should, I got the richard feynman book of letters this evening - I am afraid to go to bed - I will spend the night reading not sleeping
[11:59] <ompaul> irc is thus easier for the soul :)
[11:59] <gardengnome> ompaul: better than rotting away in IC, huh?
[11:59] <gardengnome> heh
[11:59] <gardengnome> whatever works for you :)
[12:00] <superm1> ompaul, you geek :)
[12:01] <ompaul> haha
[12:02] <gardengnome> bah
[12:02] <gardengnome> such a show-off.
[12:02] <gardengnome> ;)
[12:02] <gardengnome> beer++
[12:03] <ompaul> snail mail ftw :)
[12:04] <gardengnome> drool wtf :)
[12:04] <gardengnome> http://www.koenigsbacher.de/includes/binary_details.php?id=507&show=1
[12:09] <ompaul> it would be the same kind of stuff afics
[12:09] <ompaul> disk io
[12:09] <ompaul> pushing down the method of getting the whole thing to go faster for the sake of the media processing
[12:11] <gardengnome> true
[12:11] <gardengnome> there is a low-latency kernel, right?
[12:11] <gardengnome>                       linux-image-lowlatency - Low latency Linux kernel image
[12:11] <ompaul> there is, and ubuntu is heading towards kernel.org
[12:12] <gardengnome> what does that mean? ubuntu is going to ship vanilla kernels?
[12:12] <ompaul> they want to try to get to that
[12:12] <gardengnome> nice
[12:12] <ompaul> any delta is a bad delta unless it is my delta :)
[12:12] <gardengnome> it won't always work.. eg some distros were already using the new wlan stack
[12:12] <gardengnome> true :)
[12:21] <gardengnome> ah, great
[12:22] <gardengnome> the mythweb authentication stuff works slightly different in edgy's apache than in feisty's apache.
[12:22] <gardengnome> "    #  * If you're running Apache earlier than 2.2, you will need to use
[12:22] <gardengnome>     #    the AuthDigestFile command instead of AuthUserFile (3rd line above).
[12:22] <gardengnome> "
[12:23] <gardengnome> i was going to make something debconf-ish to allow people to protect their mythweb install, but this makes porting those changes to edgy slightly harder
[12:24] <ompaul> I have not had a big look at mythtv, so it raises a question in my mind, does it have a set of confs in a single location
[12:25] <gardengnome> the whole configuration is stored in an SQL database
[12:25] <gardengnome> mysql, that is
[12:26] <ompaul> so dumping it with some xml tags and allowing them to be used in the next one might be useful :)
[12:26] <ompaul> as in the next upgrade
[12:26] <gardengnome> i just restore my database
[12:26] <ompaul> meta data this
[12:26] <ompaul> hmm
[12:26] <gardengnome> or rather the most important parts, like channel lineup
[12:27] <gardengnome> meta data for recordings? you can already do that with mytharchive or nuvexport
[12:27] <gardengnome> i'm not sure about videos stored in mythvideo