[16:26] <enyc> OK, just to see if I got this right, older mythbuntu/mythtv needed 'faac' but its' use is deprecated for whatever reason now?
[19:02] <superm1> enyc: we used to have faac but it's not used for decoding
[19:02] <superm1> it comes from carrying ffmpeg in tree
[19:02] <superm1> as i understand
[19:03] <enyc> superm1: seemingly it looks irrelevant to 0.27.3 etc. -- seems to jsut be build-dep for the old 0.25 so not to be concerned about
[19:04] <enyc> my builds (after a host system crash, long story....) are all going nicely =)
[19:04] <superm1> yeah we don't retrofit the packaging for older stuff
[19:20] <bennypr0fane> Hello, I'm running 14.04, and on the desktop I'm missing the notification area, it is greyed out in the panel>properties>"add new item" dialog
[19:21] <bennypr0fane> These may not be the proper english terms I'm using, because I'm translating them from my german GUI
[19:22] <superm1> bennypr0fane: i think there might be a missing package to add for the notifications
[19:22] <bennypr0fane> So to be more specific, the notification area, where you would see that you have an active internet connection is missing from the panel
[19:22] <superm1> xfce4-indicator-plugin
[19:22] <superm1> i think
[19:22] <bennypr0fane> it says: "external" i a grey font
[19:23] <bennypr0fane> ok let me chec k if that's installed
[19:23] <bennypr0fane> is synaptic supposed to be there by default?
[19:34] <superm1> no ubuntu software center is there by default
[19:35] <superm1> or you can use apt-get to install
[19:36] <bennypr0fane> superm1, ok, I installed that package, it was acutally missing
[19:36] <superm1> yeah i believe we had a mistake with that not being caught in time
[19:36] <bennypr0fane> now I restarted the panel, removed the notif. plugin and re-added it, but it's the same now as before
[19:37] <superm1> i believe you need to add an indicator plugin
[19:39] <bennypr0fane> it's still greyed out in the "add new item" dialog and says "external". the same goes for the "action buttons" plugin. I see it also has a PID, name systray-1
[19:40] <bennypr0fane> superm1, I thought the indicator plugin was what I just installed: xfce4-indicator-plugin
[19:41] <superm1> yeah but i mean i think that's one of the items you have to right click and add to panel too
[19:41] <superm1> if i'm not mistaken
[19:41] <superm1> you might also need to log out / in to get the network manager icon in the indicator area
[19:42] <bennypr0fane> aha, I'll try that
[19:46] <bennypr0fane> superm1, no, that wasn't it
[19:46] <bennypr0fane> it's still the same :-(
[19:47] <superm1> nm-applet is running?
[19:47] <bennypr0fane> I think it's broken
[19:47] <bennypr0fane> how can I check?
[19:47] <bennypr0fane> top isn't showing it
[19:47] <bennypr0fane> but I think it never shows a complete list of running processes
[19:48] <superm1> ps aux | grep nm-applet
[19:48] <bennypr0fane> thanks
[19:48] <superm1> sure
[19:48] <bennypr0fane> ~$ ps aux | grep nm-applet
[19:48] <bennypr0fane> ben      10982  0.0  0.4 594396 18284 ?        Sl   21:43   0:00 nm-applet
[19:48] <bennypr0fane> ben      11253  0.0  0.0  10720   924 pts/0    S+   21:48   0:00 grep --color=auto nm-applet
[19:49] <bennypr0fane> so, it's running I guess
[19:49] <superm1> yeah
[19:49] <bennypr0fane> xchat should also show an icon in the notif. area
[19:49] <superm1> are you fully updated?
[19:49]  * bennypr0fane is on irc with xchat
[19:50] <bennypr0fane> I'll check
[19:50] <superm1> https://bugs.launchpad.net/ubuntu/+source/lxsession/+bug/1308348
[19:50] <superm1> because i noticed that
[19:50] <bennypr0fane> was yesterday tough
[19:50] <bennypr0fane> *though
[19:50] <superm1> which did require an xfce patch
[19:50] <superm1> but it's almost a month old already now
[19:52] <bennypr0fane> software updater offers an upstream bugfix release for htis: v
[19:53] <bennypr0fane> but it looks like a kde thing
[19:53] <superm1> i'm not sure then, those are the avenues that it should be
[19:53] <superm1> might just be another bug
[19:56] <bennypr0fane> if so, chances should be it's already known, right? since it's a rather visible problem
[19:56] <superm1> depends on how vocal people are
[19:56]  * bennypr0fane needs to restart after those updates...
[19:56] <superm1> we've had bugs that were pretty apparent not get reported for weeks sometimes
[19:56] <bennypr0fane> weeks is nothing
[19:57] <bennypr0fane> some very annoying stuff sticks arounf for like half a year
[19:57] <bennypr0fane> then along I come, try using the software and run right into it ;-)
[19:57] <superm1> haha
[19:57] <superm1> yeah sometimes stuff like that you just need to champion driving a  fix in
[19:57] <superm1> and help guide it through the process
[20:00] <bennypr0fane> ok, I'll try if that restart will accomplish anything. brb
[20:03] <bennypr0fane> superm1, nope, no luck.
[20:04] <bennypr0fane> to be honest, I'm too lazy to file a proper bug report. there's always this whole process to go through and tons of rules to observe, I can't handle that right now
[20:05] <bennypr0fane> thanks for your help though!
[20:18]  * enyc has many plans afoot and (should) be able to come up with a coherent 'here are minimal changes that fix some arm-build related and debian_wheezy-build+init-related issues' --  question is how to ultimately present this as patches or what etc.
[20:19] <enyc> looks like its now much easier than it used to be.. but i need to let my arm chroots finish going and test packages on some real arm gadgetry =)
[20:21] <enyc> especially  trusty-armhf   and  wheezy-i386  i will be getting going [...]
[20:21] <superm1> enyc: if they're packaging related, a pull request on github and pinging me is the way to go
[20:21] <superm1> if they're code related, generate patches and add them to bugs on mythtv bug traker
[20:21] <enyc> superm1: a what? ;-)  this bit I don't know about =)
[20:21] <superm1> *tracker
[20:22] <enyc> superm1: its all packaging debian/rules init script file etc. at present
[20:22] <superm1> ok cool
[20:22] <enyc> its' just a case of 'what actually works or breaks' etc...
[20:23] <enyc> I can tell you at least one of the small / definite fixes now if you like =)
[20:23] <superm1> well when you're ready, go here: https://github.com/mythtv/packaging, hit the fork button, clone your branch that you forked, apply some patches, push it back to github and hit the pull request button
[20:23] <superm1> or if that's not working or troublesome, pastebin some patches even
[20:23] <superm1> the former gets you attribution though
[20:28] <enyc> ok, can you just give me your brief thoughts on the following aspects, separately:-
[20:30] <enyc> a) build-dep line  "libtiff5-dev | libtiff4-dev | libtiff-dev,"  needs *just* re-ordering to   "libtiff-dev | libtiff5-dev | libtiff4-dev,"  -- apparently there is somewhere the libtiff developers reccomend this.  In any case this then adds capability to compile successfully on wheezy (as well as trusty, etc...) without silly compatibility problem with imlib2 .   the resident DD tells me this is the 'right way to do it' ...
[20:31] <superm1> i think that's probably the right way to do it too
[20:31] <enyc> b) debian sysvinit script for mythtv-backend needs adding.  Apparently this should cause no conflict, upstart will ignore it when its' own init is present.     I should check if the upstart script does anything clever wrt myth shutdown / set-wakeup-calls ...   In any case this makes running backend on wheezy easy =)....
[20:31] <superm1> the upstart one does do some clever stuff to wait for mysql
[20:32] <superm1> you might check the mythtv wiki for if someone else has a clever sysvinit script
[20:32] <superm1> or even snag it from deb-multimedia if their's is different
[20:32] <enyc> ok so that (may) need some 'work' but should be functional at least
[20:32] <superm1> *decent
[20:32] <enyc> yes indeed
[20:32] <enyc> deb-multimedia version is a big diff though
[20:33] <enyc> i'm looking 'minimal functional wheezy support' it sounds like you are willing to add  which would be helpful to all
[20:33] <enyc> c) WRT ARM OpenGL:-
[20:33] <superm1> yeah absolutely
[20:33] <enyc> Well, this I need to test when I've got my trusty-armhf  on bananaPI  and Hummingboard  'ready' ...    It *looks like* we can just change the configure flags  and it may build ok on armhf
[20:34] <enyc> it *looks like *  Raspberry-pi is a huge mess  best left to the dedictaed xbmc-frontend-distros etc etc.
[20:34] <enyc> it *looks like* nothing  armel  is worthwhile on that front anyway
[20:35] <enyc> it *looks like* that needs an extra build-dep on the  gl-es-2.0  library etc.   for  trusty-armhf ...  wheezy's qt4 is not compiled with gl-es-2 support anyway!  [but trusty-armhf's  IS] .
[20:36] <enyc> However....  if you build without that library..  MythTV configure decides that OpenGL IS avaliable  but OpenGL-ES-2.0 is NOT ...   and this may or may not matter... I don't know (yet) if it leads to 'broken' state. =).
[20:37] <enyc> I think (there) i'm best to comment when I have demonstrated what is 'usable'  on some more-useful ARM-hardware =).
[20:39] <enyc> anyway I have 16 build chroots doing stuff at the moment.... hehehe...
[20:39] <superm1> yeah, that lines up with what i heard about pi too.  so how do you add a build dep for gl-es-2.0 library if available but not fail if it's not is the question
[20:39] <enyc> indeed...
[20:40] <superm1> maybe explicitly do something with opengl to turn on in debian/rules if we detect building on ubuntu trusty or later and explicitly turn off otherwise
[20:41] <enyc> I've decided my best line of action is to try to show first, what *can* work  when building on trusty-armhf  for  bananapi+hummingboard_i2ex ...     and also (try) to say what happens if it compiles with opengl-on-arm but not opengl-es-on-arm  ...
[20:41] <enyc> and then i'll be ready to comment on that front
[20:41] <enyc> okies
[20:42] <enyc> I was going to try the  Xen PCI Passthrough  hack  for various reasons =)... and run a wheezy-i386 VM  as a mythbackend  (partly, testing my packages / init scripts ...)  with PCI card / USB card  'passed through' to virtual machine =)
[20:42] <enyc> on my xen on wheezy box
[20:42] <enyc> anyway
[20:43] <enyc> How much disk space do I need for a MythBackend machine root FS, mysql, tmp files, etc...   If the Actual video files are on a separate SATA-disk ??
[20:44] <superm1> hmm
[20:44] <superm1> figure about 2gb-3gb should be a safe amount
[20:44] <enyc> I have limited raid1 storage etc. virtual machine
[20:44] <enyc> i'm running VMs on debian wheezy on a  trusty   Dual PIII  440BX  type box =))
[20:45] <superm1> tgm4883: rhpot1991 either of you got your backends handy?
[20:45] <enyc> but for DVB-T 'recording to disk'  it should be fine =)
[20:45] <superm1> maybe you can see how much it's taking up with X and stuff in the picture
[20:45] <enyc> no  commercial flagging / transcoding =)
[20:45] <enyc> superm1: what about RAM usage tho ?
[20:45] <superm1> and then figure take off a few hundred megs to round down from X not being there in this scenario
[20:45] <enyc> I have 1024MB (motherboard max'ed out =)) ) across my VMs hehehe ...
[20:45] <superm1> mythbackend uses most when it's commflagging
[20:46] <superm1> 1024 MB?  I'd hope more than that :)
[20:46] <superm1> just for backend you'd probably be w/ 1.5GB
[20:46] <enyc> yes, if I want to run a  mythbackend that does NOT  commflag or transcode ... just  DVB-T "record bits to disk, play over network, serve mysql...." ?
[20:46] <superm1> w/ mysql
[20:47] <enyc> how on earth would the database be that big ??
[20:47] <enyc> thumbnails in BLOBs ??
[20:47] <superm1> mm probably smaller then
[20:48] <superm1> start out with 512 and see how things work
[20:48] <superm1> but i believe that w/ mysql running ram usage will go up
[20:48] <enyc> how big is your dump of  mythconverg  database for example?
[20:48] <enyc> mysql will cache a lot in ram etc etc...
[20:50] <enyc> (not forgetting, I'm talking backend-ONLY, no frontend) ...
[20:53] <superm1> true
[20:53] <superm1> your database will start out a few megs, and go up to about 100-150 over time
[20:58] <enyc> thankyou all helpful
[20:58] <enyc> next question ;-) --
[20:58] <enyc> if arm builds ultimately get sorted out,  what do you need in order to get  'regular' trusty-armhf builds  happening?
[21:00] <superm1> Either Canonical has to give us to armhf PPA builders
[21:00] <superm1> or need to have a builder somewhere that can run the builds
[21:00] <superm1> *give us access to armhf PPA builders i mean
[21:01] <enyc> can that be an 'extra user account with fakeroot on some random armhf machine somewhere' ??
[21:01] <enyc> I (might) be able to get one etc
[21:01] <superm1> yeah, we could probably do that, just need to sort out publishing the builds somewhere then too
[22:30] <tgm4883> superm1: yes