[16:23] <jamespage> hml: commented on https://bugs.launchpad.net/juju/+bug/1689683
[16:23] <mup> Bug #1689683: Can't bootstrap openstack in some cases where compute AZ exist but not networking AZs <cpe-onsite> <new-york> <openstack-provider> <uosci> <usability> <juju:Triaged by hmlanigan> <https://launchpad.net/bugs/1689683>
[16:23] <jamespage> maybe I'm missing something but I don't feel that you're trying to use the feature correctly
[17:23] <hml> jamespage: agreed - we’re not using the feature correctly - for that bug - we’d like to  to determine how we should use it.
[17:29] <hml> jamespage: sounds like we should make no coorelation between instance AZ and network AZ.  If using FIPs, and no external network specified, we should find an external network in the same network AZ as the network.


[02:47] <nuckleosn> http://img510.imageshack.us/img510/6677/screenshot7s.png
[02:47] <nuckleosn> good? ^-^
[13:34] <coz_> good day


[02:02] <Mm_nn> hi all
[02:02] <Mm_nn> may i ask?
[02:02] <Mm_nn> none could help here?
[02:03] <Mm_nn> it's a very easy question....
[02:06] <Ampelbein> !ask | Mm_nn
[02:06] <Mm_nn> ok
[02:08] <Mm_nn> i have to configure VPN connection, but i don't internet access. i downloaded pptp-linux_1.7.2-1_i386.deb $ NetworkManager-pptp-0.7.1.tar
[02:09] <Mm_nn> i installed pptp-linux_1.7.2-1_i386.deb and everything is ok. but with NetworkManager-pptp-0.7.1.tar i have problems
[02:11] <Mm_nn> when i type ./configure something happen like install, then configure: error: couldn't find pppd.h. pppd development
[02:11] <Mm_nn> and i don't know what to do
[02:12] <Mm_nn> anybody knows how to solve this problem?
[02:25] <wgrant> Mm_nn: You want #ubuntu. This channel isn't for user support questions.
[04:29] <bryce> anyone else having trouble uploading to upload.ubuntu.com?
[04:35] <bryce> feh figures, *just* as I'm about to do a major upload for mesa ><
[04:35] <wgrant> bryce: Indeed, poppy seems to have died on cocoplum...
[04:35] <bryce> wgrant, what's poppy?
[04:35] <wgrant> bryce: The FTP server.
[04:35] <bryce> wgrant, any way to work around it?
[04:35] <wgrant> I wonder if you can upload to ppa.launchpad.net instead... that might work.
[04:35] <bryce> wgrant, yes I can
[04:36] <bryce> in fact I'd uploaded the package to ppa in order to verify it builds, and given that it is, was ready to stick it in the hopper
[04:37] <elmo> restarted poppy
[04:37] <wgrant> I don't see why ppa.launchpad.net wouldn't accept a primary upload. Try that if you don't want to wait. The worst that can happen is it will reject it...
[04:37] <wgrant> Ah.
[04:37] <wgrant> Thanks elmo.
[04:37] <bryce> ah cool
[04:37] <bryce> sweetness
[04:38] <bryce> elmo, thanks muchly!
[11:16] <nacho_> hi
[11:16] <nacho_> shouldn't libvte depend on glade-ui?
[11:16] <nacho_> having a look at the deps glade-ui doesn't appear
[11:17] <nacho_> we are thinking on gtksourceview to add the catalog but we would like to hear about the distro packagers to know if it would mean a problem or something
[15:31] <zyga> lucas: hi, I changed the wiki link of moturuby team to https://wiki.ubuntu.com/MOTU/Teams/Ruby
[15:35] <lucas> zyga: ok, thanks
[18:29] <ebroder> So who can accept milestone nominations for bugs? ubuntu-core-dev/ubuntu-motu? Or do they have to be ubuntu-sru/motu-sru?
[22:13] <Max__> hello


[00:48] <bryceh> doko_, I've chased down fixes for the three nvidia build failures you mentioned a while back.  Two are basically due to unresolved differences in packaging strategy between us and debian (see bug #950963), but the packages in question have been fixed to work with ubuntu, and now build.
[00:50] <bryceh> dobey, the third build failure I located a fix and worked with debian on getting a fix.  Debian's 2.0.8-1+dfsg-3 includes this fix, and I'll sync it to quantal once LP picks it up.
[00:50] <bryceh> damn tab completion
[00:50] <bryceh> sorry dobey.
[00:51] <bryceh> doko_, bug #1061969 tracks the sync request for that issue.
[00:53] <bryceh> doko_, you also asked me to look into the vnc4 issue.  I investigated this and figured out what's wrong.  Looks like the fix is to backport some of the arm support from xorg-server to vnc4's embedded copy of xserver.  See bug #945368 in ubuntu and debian #621409.
[00:55] <bryceh> doko_, unfortunately I'm starting another project and won't have further time to work on it.  I think the porting work should be straightforward C hacking, so really anyone could do it.  I was hoping Debian would take care of it for us since it's a bug on their end, but not so far.
[00:57] <infinity> bryceh: And by "backport", you mean "stop having an ancient embedded copy of X in vnc"?
[00:58] <bryceh> infinity, no I mean cut and paste the #ifdef arm bits from the shiny new xserver into the antique xserver
[00:59] <infinity> bryceh: Yeah, I knew what you meant, I was just hoping for the other. :P
[00:59] <bryceh> but the two files are vastly different so it's a little unclear where exactly to paste.  It'll take some care to make sure it doesn't break some other random obscure hardware...
[01:01] <bryceh> infinity, you and me both.  I had forgotten that was in there, so it was a bit creepy browsing through it
[01:20] <smoser> hey all. looking for some hints.
[01:20] <smoser> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1061977 is my bug.
[01:21] <smoser> machine boots with console=ttyS0, generally boots fine until some point an upstart job that has 'console output' fails
[01:21] <smoser> running it through upstart again, will fail
[01:21] <smoser> running the same thing not through upstart will succeed.
[01:23] <smoser> and if we do: echo HELLO | sudo tee /dev/console
[01:23] <smoser> we get
[01:23] <smoser> tee: /dev/console: Input/output error
[01:26] <mwhudson> smoser: i ask this from a position of ignorance, but why have console=ttyS0 in the kernel arguments if that's not the correct value?
[01:26] <mwhudson> which that looks like
[01:26] <smoser> because they're default parameters.
[01:26] <smoser> and in general the target for this is something that is likely to have ipmi serial or logged serial or something.
[01:27] <smoser> as i understood it, the kernel would basically go through console= taking the last valid entry and making that /dev/console
[01:27] <smoser> but it seems to be convinced that /dev/ttyS0 is "good enough" and then croaks later when user space writes a bunch more data there.
[01:28] <mwhudson> ah
[01:28] <mwhudson> no idea then
[01:29] <sarnold> what's cc_keys_to_console.py supposed to do?
[01:31] <sarnold> smoser: "console=tty1 console=ttyS0" ?
[01:33] <smoser> sarnold, supposed to just write the ssh keys for the hsot to the console
[01:34] <sarnold> smoser: does it rely upon any 'odd' terminal escape sequences or termcap/terminfo along the way?
[01:34] <smoser> (on ec2 and other clouds, the serial console is logged and you can collect it)
[01:34] <smoser> nah. just normal text.
[01:35] <sarnold> aha, and I see multiple consoles should be supported. Hrm.
[01:37] <smoser> well, yeah, it *does* work.
[01:37] <smoser> ie, in kvm when i boot i see kernel messages on both, and then user-space messages on the serial
[01:42] <sarnold> smoser: "Read 3 bytes from /home/ubuntu/.ssh/authorized_keys" -- why only 3 bytes?
[01:43] <smoser> i dont knwo. that is strange.
[01:43] <sarnold> (not that this _really_ helps with the /dev/console, but it's odd, and maybe you'll get lucky?)
[01:44] <smoser> i dont think so. i thikn its probably just abug.
[01:44] <smoser> in cloud-init.
[01:44] <smoser> as that file likely doesn't have anything in it.
[01:44] <smoser> as there were no ssh keys imported
[01:46] <sarnold> the logs did say "read 0 bytes" elsewhere though, so it seems prepared to handle zero-byte files alright.
[01:48] <stgraber> hallyn: I'm around now :)
[01:56] <smoser> sarnold, well thanks for the thoughts.
[01:58] <hallyn> stgraber: i went ahead and pushed part of the fix for grub updates to lxc in quantal
[01:58] <hallyn> stgraber: cjwatson will push the other bit to grub tomorrow
[02:03] <stgraber> hallyn: is fstab processed before the /dev/lxc/* entries are created? if not, I'd expect that fstab entry to hide them and start giving direct access to the host devices which would be kinda bad
[02:07] <hallyn> stgraber: it is.  mounts are done first
[02:12] <stgraber> hallyn: good, so yeah, should be fine. I'll takk a look at github in a sec
[03:40] <micahg> @pilot in
[04:08] <micahg> hrw: BTW, if we can get wine ported to use a different gcc before release, gcc-4.5 will be removed from quantal
[04:11]  * micahg decides to stop trying to UDD merge when people aren't using the VCS as a VCS...
[04:34] <infinity> micahg: That's a pretty hopeful "if".
[04:36] <micahg> infinity: I can dream, can't i?
[04:36] <infinity> micahg: Sure, carry on.
[05:24] <darkxst> I have a small accounts services fix, that needs sponsoring https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/1059090/comments/4
[05:32] <bkerensa> infinity: any reason xserver-xorg-video-displaylink was deleted from Quantal?
[05:32] <RAOF> bkerensa: I think because it's supported by the kms driver, now?
[05:33] <bkerensa> RAOF: idk I just had a Mozilla colleague indicate that they have zero USB Monitor support since the package was deleted
[05:33] <bkerensa> I will check back with him
[05:33] <RAOF> It should be picked up by the kms driver and then xf86-video-modesetting should kick in.
[05:40] <pitti> Good morning
[05:41] <epikvision> Good evening.
[05:44] <hrw> micahg: when gcc-4.[45] get removed I will post for removal of cross one as well
[05:50] <infinity> hrw: We may as well just remove the cross 4.5 now, to be honest, we don't want to encourage people to be using old toolchains.
[05:50] <infinity> hrw: If the only reason to keep it around it one package, why make it two?
[05:53] <micahg> @pilot out
[06:01] <hrw> infinity: right
[06:49] <cjwatson> bryceh: nvidia-texture-tools - FWIW it would have been great if you'd filed a bug about that somewhere (Debian or Ubuntu) in advance.  I spent half an hour or so on it only to find you'd been dealing with it already out of public view.
[07:12] <bryceh> cjwatson, did you see bug #1061969?
[07:13] <cjwatson> bryceh: That was filed after I spent some time working on it (having checked all the bug lists first) only to have the Debian maintainer tell me you already had.
[07:13] <bryceh> cjwatson, any issue if I proceed with the sync?
[07:13] <cjwatson> bryceh: No, go ahead
[07:13] <cjwatson> (Why file bugs for syncs you don't need sponsorship for anyway?)
[07:14] <bryceh> cjwatson, because we're in freeze, for traceability if the package is held
[07:15] <cjwatson> Well, sync it and I'll accept it, anyway
[07:16] <tjaalton> is bug 1017603 valid? it's what I had in mind too
[07:16] <cjwatson> bryceh: accepted
[07:17] <cjwatson> (oops, accepted my -2ubuntu1 as well, but no harm done there)
[07:17] <cjwatson> tjaalton: the principle is valid and the Linaro guys have been working on this
[07:17] <tjaalton> cjwatson: oh cool
[07:17] <cjwatson> triaged the bug
[07:18] <tjaalton> could it be sru'd to precise too, or are such changes not acceptable?
[07:18] <bryceh> cjwatson, doko had asked me to look at the build issue, but there wasn't a bug report.  didn't realize there was a protocol for how to work on build failures.
[07:19] <cjwatson> bryceh: Well, I would suggest that if you're working with Debian you should do it through the bug system rather than by e-mailing the maintainer directly
[07:19] <cjwatson> (the Debian bug system that is)
[07:19] <cjwatson> That way I'd have seen it and moved on :)
[07:19] <cjwatson> aaaaaaargh, why does my right trackpad button randomly stop working
[07:21] <bryceh> cjwatson, well don't ask me for help with that button, I might fix it but fail to file a bug report on it.  ;-)
[07:21] <cjwatson> heh
[07:21] <cjwatson> Sorry, glad you fixed it
[07:22] <bryceh> no prob, night.
[07:33] <zyga> pitti: ping
[07:34] <zyga> pitti: two questions, same as before: can we ship python3-pyudev on the CD (for checkbox)
[07:34] <pitti> zyga: (in interview, bbl)
[07:34] <zyga> pitti: and can we upgrade that package (rdepends are empty) from 0.13 to 0.17
[07:34] <zyga> pitti: k, thanks
[07:34] <zyga> pitti: (debian does not have updated versions but it's pure python so it should be trivial to do)
[07:34]  * zyga looks into the new source package
[07:35] <pitti> zyga: so, the marathon guys let me go :)
[07:36] <pitti> zyga: no objections, but I think pyudev is a dead end
[07:36] <pitti> zyga: we have had introspection bindings for years which work very well
[07:37] <zyga> hmm
[07:37] <zyga> so which api should I use/
[07:37] <zyga> gi + gudev?
[07:38] <zyga> pyudev has some pythonic goodness on top of raw udev, I'd rather not loose that
[07:39] <pitti> I think gi.repository.GUdev works very well, but as I said, I don't object to pyudev
[07:39] <pitti> zyga: what goodness, OOI?
[07:39] <pitti> if you use this in a GLib-ish project already, then gudev is certainly the way to go; you have automatic main loop integration, signal support, etc.
[07:39] <zyga> pitti: I'll have a look at that
[07:40] <pitti> if you use this in a Qt-ish project, you might not want the additional dependencies
[07:40] <pitti> is this for checkbox?
[07:40] <zyga> pitti: well, I only used it briefly but it has python wrappers for udev devices and attributes
[07:40] <zyga> yes
[07:40] <zyga> sadly we need udev too
[07:40] <zyga> it's not merged in yet
[07:40] <pitti> "udev is not merged"?
[07:41] <zyga> the branch that depends on udev has not landed
[07:41] <zyga> https://code.launchpad.net/~zkrynicki/checkbox/usb3/+merge/127993
[07:41] <zyga> have a look at the brief discussion there
[07:42] <zyga> hmm
[07:42] <zyga> GUdev looks very similar
[07:42] <pitti> zyga: ah, you already use gi.repository.GObject, so you already have all the glib, libgirepository and pygobject dependencies anyway
[07:42] <zyga> that's right
[07:43] <zyga> pitti: so it's my first time with using gi.repository magic, where do I find docs on the GUdev module, in the upstream C version?
[07:45] <pitti> zyga: http://www.freedesktop.org/software/systemd/gudev/ is the C API
[07:45] <pitti> it translates to the Python API in a straightforward way, but if you prefer a really Python-ish doc, you can get that as well
[07:46] <zyga> I know the idea behing gobject introspection
[07:46] <pitti> mkdir /tmp/gudev; g-ir-doc-tool -o /tmp/gudev/ /usr/share/gir-1.0/GUdev-1.0.gir; yelp /tmp/gudev/
[07:46] <zyga> just never used it in practice
[07:47] <zyga> ohhh
[07:47] <zyga> thanks a lot
[07:47] <pitti> that's still a bit inconvenient, sorry
[07:47] <zyga> I'll try to use that instead
[07:47] <pitti> but you get the class/method name separation instead of the C-style class_name_method()
[07:48] <zyga> pitti: g-ir-doc-tool? where is that from cnf does not know about it
[07:48] <pitti> "gobject-introspection" package
[07:48] <zyga> thanks
[07:49] <pitti> oh, indeed that's not on a default install
[07:52] <zyga> pitti: which package has /usr/share/gir-1.0/GUdev1.0.gir
[07:52] <zyga> it's not in gir-1.2-gudev
[07:52] <pitti> zyga: gir1.2-gudev-1.0 is the typelib, libgudev-1.0-dev has the gir
[07:52] <zyga> ah
[07:52] <zyga> ok
[07:52] <zyga> thanks
[07:52] <pitti> (yay for confusing package names)
[07:53] <zyga> :D
[07:53] <zyga> no, it's okay
[07:53] <zyga> well
[07:53] <zyga> it's not better than anything else
[07:53] <pitti> zyga: at runtime you only need the .typelib, which is the compiled gir (which is XML and human readable)
[07:53] <zyga> I wish something like online apt-file was built into ubuntu by default
[07:53] <zyga> right
[07:56] <pitti> yeah, similar to rmadison
[07:56] <zyga> pitti: hmm it crashes on missing GObject-2.0.gir
[07:57]  * zyga looks for that
[07:57] <pitti> zyga: libglib2.0-dev
[07:58] <seb128> pitti, speaking of gobject-introspection, did you not package 1.34 on purpose?
[07:58] <seb128> (it's one of the few tarballs were we didn't upate to the stable GNOME 3.6 one)
[07:58] <pitti> seb128: oh, it might have been released late
[07:58] <pitti> seb128: doing now
[07:58] <zyga> pitti: no, I already have that
[07:59] <pitti> seb128: I'm currently updating udisks to 2.0.0 final
[07:59] <seb128> pitti, danke
[07:59] <zyga> pitti: there are no .gir files in that package
[07:59] <seb128> zyga, libgirepository1.0-dev
[07:59] <pitti> zyga: whoops, sorry; gobject/glib girs are special, what seb128 says
[08:00] <zyga> thanks
[08:00] <pitti> zyga: (glib2.0 source cannot build its own girs)
[08:09] <zyga> pitti: I'm trying to use that, how do I enumerate devices, Enumerator is not really iterable and there are no other methods that look like something accessing a collection
[08:10] <pitti> zyga: calling .execute() on the enumerator after setting it up will give you an iterable Python array
[08:11] <zyga> ahh, thanks, I've missed that
[08:11] <zyga> pitti: reading the docs on that
[08:11] <zyga> pitti: do I need to worry about gobject references form python?
[08:11] <pitti> no, pygobject does that for you
[08:12] <zyga> ok, cool
[08:12] <zyga> it seems to work, thanks, I'll take it form there
[08:12] <pitti> nice
[08:30] <zyga> pitti: Device.get_parent() does not exist, I need that method, could this be a bug in gir? (it's documented that this method exists)
[08:30] <zyga> http://www.freedesktop.org/software/systemd/gudev/GUdevDevice.html#g-udev-device-get-parent
[08:30] <pitti> zyga: indeed, it's marked as non-introspectable; presumably a missing annotation
[08:31] <zyga> ohhh
[08:31] <pitti> zyga: you can use os.path.dirname(path) to get the parent, too; but I'll investigate
[08:31] <zyga> crap
[08:32] <pitti> I'll get this fixed upstream and backport it to our udev
[08:32] <zyga> thanks
[08:51] <zyga> pitti: dirname() on which path? sysfs?
[08:51] <pitti> zyga: right, in sysfs; getting the parent dev is just that
[08:52] <zyga> cool, thanks
[08:53] <wookey> doko_: do you have guesses as to which patches might be responsible for http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=680439
[08:54] <wookey> don't worry if not - I'll just wait for infinity to wake up
[08:57] <pitti> zyga: ah, it's fixed upstream already, it's just that our udev is really old; I'll backport the fixes
[08:58] <zyga> pitti: good news, thanks
[08:59] <zyga> 193 vs 175
[08:59] <zyga> 194 even
[09:12] <darkxst> we need to drop an  old debian patch in accounts services to make the autologin toggle work in user accounts on ubuntu gnome remix. I attached a debdiff to this bug, if anyone is able to sponsor it. https://bugs.launchpad.net/ubuntu/+source/gdm/+bug/1059090/comments/4
[09:22] <hrw> Bug #1062137 filled to get rid of old cross compilers
[09:23] <zyga> pitti: hmm, it seems I cannot just chop the path to traverse devices
[09:24] <zyga> pitti: for /dev/sdb1 I got /dev/sdb but then stop -- I wanted to traverse all the way up to the USB hub device (it's a thumb drive)
[09:24] <pitti> yes, it should do that
[09:24] <zyga> pitti: starting from /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-7/1-7:1.0/host0/target0:0:0/0:0:0:1/block/sdb/sdb1
[09:24] <pitti> zyga: (anyway, test-building udev now)
[09:25] <zyga> it only got to /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-7/1-7:1.0/host0/target0:0:0/0:0:0:1/block/sdb
[09:25] <pitti> zyga: sure, that's the next parent
[09:25] <zyga> going higher made Client.query_by_sysfs_path() return None
[09:25] <pitti> you have to iterate through all parents
[09:25] <pitti> zyga: libudev's get_parent() really does the same -- just chop off the last path component
[09:25] <cjwatson> hrw: Thanks, I'll process that
[09:26] <zyga> pitti: so until I get all the way up to /sys?
[09:26] <hrw> cjwatson: thanks
[09:26] <cjwatson> hrw: I assume I can reject the corresponding uploads in the unapproved queue?
[09:26] <zyga> ignoring things that don't look like devices?
[09:26] <hrw> cjwatson: yes
[09:26] <cjwatson> OK, done
[09:26] <hrw> cool
[09:26] <cjwatson> Just triple-checking reverse dependencies
[09:26] <pitti> zyga: perhaps you want get_parent_with_subsystem() if you are looking for a particular kind of parent dev
[09:27] <cjwatson> Which is hard with a headache and a toddler talking to me
[09:27] <pitti> zyga: well, in kernel teams all of those are devices
[09:27] <pitti> zyga: you have to specify "what shoudl the device look like" yourself, in terms of subsystem, attributes, and properties
[09:28] <pitti> $ grep introspectable /usr/share/gir-1.0/GUdev-1.0.gir
[09:28] <pitti> $
[09:28] <pitti> zyga: ^ voila :)
[09:29] <zyga> pitti: for me /sys/devices/pci0000:00/0000:00:1d.7/usb1/1-7/1-7:1.0/host0/target0:0:0/0:0:0:1/block/ is empty apart form the 'sdb' directory, there are no attribute files there
[09:29] <pitti> ah, right
[09:29] <zyga> pitti: anyway, ignoring stuff that fails to create a udev device they way I said seems to work
[09:30] <pitti> zyga: right, sorry; udev's skips directories without an "uevent" file
[09:30] <pitti> zyga: I uploaded the fixed udev, now waiting for a release team member to review, then you'll have it an hour after that
[09:30] <jtaylor> doko_: do you have objections to syncing poco just to test if bug 903347 is fixed in quantal?
[09:31] <jtaylor> or someone here has the hardware could test it for me :)
[09:31] <zyga> pitti: awesome, thanks for the help! :-)
[09:33] <cjwatson> hrw: all right, all done now
[09:34] <pitti> dholbach, jono, dpm, jcastro_, mhall119: wohoo, > 5000! go, go, go!
[09:34] <dholbach> :-D
[09:35] <mhall119> \o/
[09:35] <jono> pitti, :-)
[09:35] <mhall119> ..zzZZ
[09:35] <dpm> pitti, \m/
[09:36] <ajmitch> jcastro_: live juju demo
[09:39] <pitti> doko_: https://launchpad.net/ubuntu/+source/ubuntu-drivers-common/1:0.2.71 :)
[09:40] <pitti> dholbach: who's DJing, you?
[09:41] <dholbach> pitti, very short :)
[09:41] <dholbach> just a bit
[09:49] <cjwatson> mlankhorst,tjaalton: so, I notice you removed xserver-xorg-video-geode from xserver-xorg-video-all, which has caused it to be listed for movement to universe on http://people.canonical.com/~ubuntu-archive/component-mismatches.txt; was it intentional to drop it out of main, or just out of the default set?
[09:51] <pitti> zyga: If you are anxious for the fixed packages, grab them from https://launchpad.net/ubuntu/+source/udev/175-0ubuntu12
[09:52] <tjaalton> cjwatson: move to universe is fine, it's not that useful anymore since the kernel requires PAE support. but keep it there for now if some folks want to use their own kernels..
[09:54] <cjwatson> tjaalton: OK, moved to universe
[09:54] <cjwatson> thanks
[10:01] <mlankhorst> cjwatson: intentional :)
[10:01] <pitti> jono, dholbach: ah, the last few minutes weren't broadcasted any more; anyway, good night! awesome job!
[10:01] <mlankhorst> but tjaalton beat me to it
[10:01] <dholbach> pitti, they were - we had to restart the hangout
[10:01] <jono> thanks, pitti!
[10:02] <jono> thanks for joining us earlier!
[10:02] <pitti> dholbach: right, I tried to reload several times, it always said "will be available soon"
[10:02] <dholbach> hum
[10:02] <pitti> jono: de rien
[10:02] <dholbach> it seems to have worked for others
[10:02] <pitti> *shrug* no biggie
[10:02] <pitti> why are you still online anyway! :)
[10:03] <pitti> james_w: hey James, how are you?
[10:04] <pitti> james_w: who can I bother about pushing buttons for UDD imports these days? (gvfs is out of date)
[10:13] <chrisccoulson> jono, have you started hallucinating yet? ;)
[10:13] <chrisccoulson> i think i would be after 24h
[10:13] <jono> chrisccoulson, getting there :-)
[10:13] <chrisccoulson> hah :)
[10:13] <cjwatson> That usually starts at around 35h for me
[10:13] <cjwatson> Not that I'm much use between 24h and 35h
[10:14] <pitti> jono: for example, you might imagine it was already over :)
[10:15] <ogra_> you guys dont take the day off, do you ? :)
[10:24] <doko_> wookey, http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33763
[10:25] <doko_> wookey, my understanding is, that this should be fixed in glibc
[10:36] <doko_> jtaylor, why? is there a fix for GCC?
[10:36] <jtaylor> don't know
[10:50] <doko_> wookey, no, apparently I'm wrong. just drop it for now
[10:58] <pitti> davmor2: FYI, I now added a gvfs test case for recognizing media players as such :)
[10:58] <pitti> davmor2: this broke $DEITY knows how many times already..
[10:59] <davmor2> pitti: just tested it, S3 works correctly although the system thinks it's a tablet and the music player is detected however the icon in the launcher isn't a music player but a usb stick is this a change in behaviour?
[11:01] <pitti> davmor2: yes, very close to gnome bug 631809
[11:01] <davmor2> pitti: I'm just happy that I have my sansa fuse to keep testing it is broken or not hopefully now :)
[11:01] <pitti> davmor2: these bugs apply to any media player, though (same for my xperia mobile)
[11:02] <davmor2> pitti: indeed
[11:03] <davmor2> pitti: mine just happens to be a sansa fuze that I've had for a while so seem to keep finding the breakage with it :)  I'm happy to here that there could be an upstream fix for it now though :)
[11:03] <pitti> davmor2: my fix from yesterday to detect them at all already went upstream
[11:03] <pitti> icons and volume names still need to be fixed, that's on my list
[11:04] <pitti> (and now that's trivial to test)
[11:04] <davmor2> pitti: cool :)
[11:08] <zyga> pitti: thanks
[11:13] <davmor2> pitti: on a plus side the system thinks I have a music player WooHOO!!!!
[11:29] <ogra_> hmm, i have two packages that should never be unpacked on the same system at the same time, can i just use Conflicts here ?
[11:30] <cjwatson> That's the exact meaning of Conflicts
[11:30] <ogra_> k
[11:30] <ogra_> no need to use replacess i guess
[11:30] <cjwatson> Not in general but you might want to if one of the two is going away
[11:31] <cjwatson> The policy manual has detailed advice
[11:31] <ogra_> by going away you mean that the other package then comes in as a replacement ?
[11:31] <ogra_> thats definitely not waht i want ...
[11:31] <ogra_> *what
[11:32] <cjwatson> for example
[11:36] <cjwatson> pitti: is the stack of language pack uploads yours?
[11:41] <cjwatson> pitti: Never mind, looks like a straightforward update so I'll just accept it all
[11:42] <pitti> cjwatson: (OTP) presumably from the automatic cronjob
[11:42] <cjwatson> OK
[11:45] <jamespage> @pilot in
[13:19] <pitti> ev: hey Evan
[13:19] <ev> hi Pici
[13:19] <ev> pitti even
[13:19] <pitti> ev: I assigned a bug to you this morning about unpacking xz debs not working any more
[13:19] <ev> yikes, on it
[13:19] <pitti> ev: it seems that none of our three implementations gets it right :(
[13:20] <pitti> ev: but I'm really concerned about dpkg-deb -x having that bug; how does it deal with symlinks in the actual system?
[13:20] <ev> pitti: how does dpkg -x deal with symlinks?
[13:20] <ev> or dpkg -i?
[13:20] <ev> dpkg -i notices that there's something there already and happily carries on
[13:21] <pitti> ev: or whichever bug you wanted to fix by moving to python-debian/apt_inst
[13:22] <cjwatson> dpkg -x should extract symlinks perfectly normally
[13:22] <ev> https://bugs.launchpad.net/ubuntu/+source/apport/+bug/1059621
[13:23] <cjwatson> the random package I have to hand that contains symlinks extracts just fine
[13:23] <ev> cjwatson: it extracts symlinks fine. But while dpkg -i notices that the symlink it's trying to create already exists as a directory and skips it, dpkg -x does not.
[13:23] <ev> thus the "tar: ./usr/share/doc/gnat-gps: Cannot create symlink to `gnat-gps-common': File exists"
[13:24] <cjwatson> that looks like an outright bug in the package to me, really
[13:25] <cjwatson> gnat-gps-common should put features.gz and known-problems.gz in /usr/share/doc/gnat-gps-common/, not gnat-gps/
[13:25] <cjwatson> the way it is right now, even with dpkg -i it's probably nondeterministic what ends up in gnat-gps/
[13:26] <ev> hmm
[13:26] <cjwatson> Debian #684194
[13:27] <ev> pitti: do you think we should back out the change and consider these unretraceable?
[13:27] <ev> cjwatson: massive, massive thanks
[13:28] <cjwatson> (so fixed in quantal, I believe)
[13:28] <cjwatson> might not be totally insane to SRU that fix
[13:34] <smoser> jodh, around ?
[13:35] <smoser> i'm running into a problem where getting the "right" console= parms is not easily done. and as a result, /dev/console (stdout for upstart) is hosed.
[13:35] <smoser> that, in turn, hoses anything that has 'console output'.
[13:36] <smoser> is there any way in upstart to fix that case?  ie, if stdout gives io error when written to, try somewhere else.
[13:46] <pitti> ev: works for me
[13:48] <jodh> smoser: what console= kernel param are you specifying
[13:48] <jodh> smoser: ?
[13:48] <smoser> https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1061977/comments/4 has more info
[13:48] <smoser> i'm specifying "console=tty1 console=/dev/ttyS0" which tells the kernel to make /dev/console == /dev/ttyS0
[13:49] <smoser> but /dev/ttyS0 might not actually be a device.
[13:49] <ogra_> smoser, sudo in an upstart job ?
[13:50] <smoser> where do you see that?
[13:50] <smoser> ah. that was just an example.
[13:50] <ogra_> ahm, thats only manual test code ?
[13:50] <jodh> smoser: I thought that meant redirect console output to *both* devices? One sec...
[13:50] <smoser> saying /dev/ttyS0 is busted.
[13:50] <smoser> err... /dev/console.
[13:50] <smoser> jodh, it sends kernel messages to both devices
[13:50] <ogra_> hmm, it shoudlnt
[13:50] <smoser> but /dev/console is not a multiplexer. "last one wins"
[13:51] <ogra_> the second console= option is ususally handed to userspace
[13:51] <smoser> ogra_, right.
[13:51] <ogra_> while the first one is used for kernel messages
[13:51] <smoser> no.
[13:51] <ogra_> (if you actually use two)
[13:51] <smoser> kernel messages go to both.
[13:51] <smoser> user space gets the last.
[13:51] <ogra_> they shouldnt
[13:51] <smoser> the doc and experience say otherwise :)
[13:51] <jodh> smoser:
[13:51] <jodh> You can specify multiple console= options on the kernel command line.
[13:51] <jodh> Output will appear on all of them. The last device will be used when
[13:51] <jodh> you open /dev/console.
[13:52] <jodh> smoser: so, trying changing the order.
[13:52] <smoser> jodh, yeah, that will work.
[13:52]  * ogra_ has never seen the kernel output to more than one tty
[13:52] <jodh> smoser: that was from Documentation/serial-console.txt in the kernel fwiw.
[13:52] <smoser> jodh, i liked to that.
[13:52] <smoser> linked to that
[13:53] <smoser> jodh, my problem is that if i do that, i will *never* (well, 98% of never) get /dev/console == /dev/ttyS0.
[13:53] <seb128> ev, do you know when bug #1061867 is not registering on the front page of e.u.c ... it's a recent issue and it has been ranking high on the launchpad retracer, that's reality the sort of issues we need to know about, it's a bit disturbing that the error tracker doesn't catch those
[13:53] <smoser> which is better in the case where there *is* a ttyS0
[13:54] <smoser> jodh, the reason i bothered you, is that there seems no [easy] way to change /dev/console, and whatever is the last 'console=' parm will become /dev/console.
[13:54] <smoser> but upstart could potentially recognize that its stdout is busted.
[13:55] <smoser> and i could potentially tell upstart (configuration or kernel cmdlines) "if your stdout is busted, try others in this order"
[13:55] <jodh> smoser: that's kernel behaviour I'm afraid :) You could try playing tricks likehttp://upstart.ubuntu.com/cookbook/#versions-of-upstart-older-than-1-4 maybe?
[13:56] <ogra_> you can surely work around it in /init in the initrd
[13:56] <jodh> smoser: ... where the device is passed in as a job param maybe or config variable?
[13:56] <ogra_> (theoretically it does that already)
[13:56] <smoser> ogra_, well, i sort of could.
[13:56] <jodh> smoser/ogra_: but do you even need an initrd for those cloud images I wonder.
[13:57] <smoser> i could set init's stderr, stdin, stdout to something other than /dev/console if /dev/console was busted, yes.
[13:57] <smoser> and that would be essentially the same as having upstart do it.
[13:57] <ogra_> just easier to hcak it into the shell script :)
[13:57] <smoser> jodh, we like initrd.
[13:58] <ogra_> *hack
[13:58] <smoser> ogra_, right.
[13:58] <ogra_> jodh, you neeed one if they use root=UUID=
[13:58] <ogra_> our kernel cant mount by UUID
[13:58] <jodh> ogra_: I know
[13:58] <smoser> i was hoping that from user space i could tell the kernel "please re-assign /dev/console to be /dev/tty0"
[13:58] <smoser> but it seems not possible.
[13:58] <smoser> ogra_, jodh we like initrd.
[13:59] <smoser> we do clever, valuable things there.
[13:59] <ogra_> ++
[13:59] <ogra_> thats what its for ;)
[13:59] <smoser> (iscsi root, overlayroot, grow a partition)
[13:59] <ogra_> yep
[14:00] <smoser> so, yeah, in the initramfs i coudl change 'exec >/dev/console 2>&1 </dev/console' to be 'exec >$MYDEVICE ... '
[14:00] <smoser> but writes explicitly to /dev/console would still fail.
[14:00] <ogra_> hmm, i would rather look for why you cant write to it and fix that
[14:01] <smoser> hm..
[14:01] <smoser> jodh, one question.
[14:01] <smoser> the doc for upstart says: [console] output: If output is specified, the standard input, standard output and standard error file descriptors are connected  to /dev/console.
[14:01] <smoser> is that really mean "by convention"
[14:02] <smoser> or does upstart explicitly close stdin/stdout/stderr and re-open them from /dev/console
[14:02] <smoser> (in which case i cannot hack in the initramfs)
[14:02] <jodh> smoser: it actually closes and reopens.
[14:02] <smoser> so i can't workaround in initramfs
[14:03] <smoser> ogra_, yeah, i meant where $MYDEVICE is the result of a search.
[14:03] <smoser> but i dont think that will work anyway.
[14:05] <ev> seb128: https://errors.ubuntu.com/bucket/?id=/usr/lib/indicator-datetime/indicator-datetime-service%3A11%3Ae_client_open_sync%3Aupdate_appointment_menu_items%3Ag_closure_invoke%3Asignal_emit_unlocked_R%3Ag_signal_emit_valist
[14:05] <smoser> well, i can't seem to see any solution other than removing console=ttyS0 as a default parameter.
[14:05] <seb128> ev, I wonder why it has 1 instance where launchpad has 6 duplicates, whoopsie is supposed to bring more report than successful launchpad retraces no?
[14:05] <smoser> which means that "by default" systems that would have logged ttyS0 will get no messages written to them at all if they have a vga device.
[14:06] <smoser> :-(
[14:06] <KRF> could someone please have a look at https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1036283 ?
[14:06] <ev> seb128: indeed, I'm curious about that as well. It is *possible* - they might have whoopsie in a stopped state. But it seems unlikely.
[14:06] <ogra_> smoser, oh, coudl it be that you have a job anywhere that has "console owner" ?
[14:06] <smoser> console output
[14:06] <ogra_> console will get detached from the tty for that
[14:07] <ogra_> if any job cals it
[14:07] <ev> seb128: I've made a note to dig into that deeper
[14:07] <smoser> possible. but i have 'console output' on my jobs.
[14:07] <seb128> ev, thanks
[14:07] <ev> sure thing
[14:07] <smoser> which, seems to mean /dev/console even if that is busted.
[14:07] <ogra_> smoser, well there might bew jobs you didnt add :)
[14:07] <smoser> oh well.
[14:07] <smoser> right.
[14:07] <smoser> but why would that matter?
[14:08] <smoser> at least i dont care about those jobs at the moment.
[14:08] <ogra_> i just noticed that my tty's die if console owner is set (and respawn due to their job)
[14:08] <smoser> well, ogra_ jodh thanks for the discussion.
[14:09] <smoser> it seems to me the only way to do this would be to be able to tell the kernel "hey, could you make /dev/console point somewhere else please"
[14:09] <smoser> and have that work even with open filehandles
[14:09] <smoser> well, maybe in the initramfs i could get all /dev/console closed.
[14:16] <smoser> hm.. i guess the other hting i could do is kexec from initramfs.
[14:37] <doko> mvo: can you just black-list pentium-builder for command-not-found? see bug #1062043
[14:41] <mvo> doko: yeah
[15:06] <doko> pitti, seb128: would be nice if somebody could look at libgtk2-perl, bug #1056811. update needed for gtk changes?
[15:08] <pitti> c'est un travail pour l'équipe de desktop :)
[15:09] <pitti> oui, Monsieur Bacher?
[15:09] <pitti> mvo: so we still have libgtk2-perl for debconf?
[15:10] <seb128> pitti, on dirait oui ...
[15:10] <seb128> doko, I will try to have a look, no promise today though, release team meeting just started and it will be 6pm after the meeting
[15:11] <doko> it's the last real build failure in main
[15:12] <pitti> Riddell: ah, so we should remove language-pack-* from quantal, except for the ones you created manually?
[15:12] <seb128> doko, kick a build while the meeting is ongoing, let's see
[15:12] <Riddell> pitti: yes I think so
[15:12] <doko> well, maybe except for webkit on arm
[15:12] <Riddell> pitti: including the base ones
[15:13] <Riddell> I guess
[15:13] <pitti> Riddell: that's all except language-pack-kde-{engb,zhcn,zhtw}?
[15:13] <Riddell> pitti: I've removed language-pack-kde-{engb,zhcn,zhtw} already
[15:14] <Riddell> pitti: here's the ones I make http://paste.kde.org/562928/
[15:14] <pitti> Riddell: ah, thanks; so I'll remove all but those
[15:16] <Riddell> pitti: thanks
[15:17] <mvo> pitti: I think so - if we want to support debconf gtk dialogs
[15:17] <mvo> pitti: still in the suggests line of debconf, but TBH i haven't payed much attention to debconf lately
[15:26] <smoser> can i get someone from SRU team to look at https://launchpad.net/ubuntu/precise/+queue?queue_state=1&queue_text=cloud-init please ?
[15:26] <smoser> i have other things in cloud-init that are fairly high priority to get fixed in 12.04 and i need that ximple fix through the queue sooner rather than later.
[15:27] <pitti> Riddell: oh, bloody CRLF line endings on pastebin
[15:28] <pitti> Riddell: I was staring at my join command for 5 minutes, wondering why it didn't work
[15:28] <Riddell> pitti: I know, I really should report that to the kde sysadmins
[15:28] <pitti> Riddell: http://paste.ubuntu.com/1262096/
[15:29] <pitti> command and output, this would be the "to kill" list
[15:29] <Riddell> pitti: looks right
[15:31] <pitti> Riddell: could you add Conflicts to the -base packages to the transitionals, to get them cleaned up on upgrade?
[15:33] <Riddell> pitti: can do
[16:39] <cjwatson> pitti,seb128: if you guys can't figure out the libgtk2-perl failure I expect I'll take a look at it on Monday and see if any of the recent upstream changes help
[16:39] <cjwatson> I hadn't been going to ask you to support it because I know how much you love the perl bindings
[16:40] <seb128> cjwatson, I indeed *love* perl :p
[16:40] <seb128> cjwatson, I started looking at it but the test seems to run fine when ran manually
[16:40] <cjwatson> in an sbuild chroot?
[16:40] <seb128> cjwatson, I will poke a bit longer to it today but I don't figure it out help on monday would be welcome
[16:41] <seb128> cjwatson, no, on my box, but the package build hangs on the same environment
[16:41] <seb128> well "same environment", the package run through fakerook, xvfb, etc
[16:48] <wookey> infinity: libc_extra_config_options = --with-selinux $(extra_config_options) which ends up coming after the --without-selinux in the eglibc stage1 build and turning selinux back on.
[16:49] <wookey> any idea where the right place to fix that is?
[16:49] <wookey> in 2.15 libc_extra_config_options = $(extra_config_options)
[16:49] <wookey> so it worked
[16:54] <infinity> wookey: Oh, has aurel turned on selinux unconditionally in 2.16?
[16:54] <wookey> apparently
[16:54] <wookey> which may well be OK for normal builds, but not bootstrapping
[16:55] <cjwatson> seb128: Yeah, hangs for me too in sbuild, at least
[16:56] <infinity> ifeq ($(DEB_STAGE),stage1)
[16:56] <infinity>     libc_extra_config_options = $(extra_config_options) --without-selinux
[16:56] <infinity> endif
[16:56] <infinity> ?
[16:57] <wookey> seems sensible.
[17:01] <micahg> could someone familiar with objective c binary dependencies take a look at this bug for me and see if my concerns are valid or not?
[17:01] <micahg> Bug #1051389
[17:50] <mlankhorst> who handles apt bugs?
[17:50] <KRF> could somebody take care of https://bugs.launchpad.net/bugs/1036283 please?
[17:51] <KRF> that's a pretty trivial fix
[17:51] <mlankhorst> hitting a weird bug in apt that seems multiarch related
[17:57] <cjwatson> mlankhorst: normally mvo
[18:20] <mlankhorst> ah what time is he on?
[18:20] <mlankhorst> I was hitting a bug switching stacks but it kind of looks like I've hit that one before
[18:30] <slangasek> mlankhorst: Europe/Berlin; but if you can describe the problem perhaps someone else can help
[18:30] <Darxus> A sensors-applet package is "waiting in New for approval".  It got an FFE.  What needs to happen?  Is there any part of that I can see?  Bug 1049343.
[18:32] <mlankhorst> slangasek: basically I am working on q-lts-backport in ~mlankhorst/ppa, but switching between normal and other stack with apt-get install xserver-xorg-lts-quantal libgl1-mesa-{glx,dri}-lts-quantal{,:i386} is broken and dies on swapping out libglapi
[18:32] <slangasek> ok, what's the error?
[18:32] <mlankhorst> just that libglapi-mesa-lts-quantal is extracted for i386, then it dies on trying to extract libgl1-mesa-glx-lts-quantal which requires that package for 64-bits
[18:33] <slangasek> please show the exact apt output
[18:33] <mlankhorst> with problem resolver debug enabled http://paste.ubuntu.com/1262441/
[18:34] <mlankhorst> sadly in dutch but should still be understandable
[18:34] <smoser> infinity, it would appear to me that the last upload of software-properties did not fix
[18:34] <smoser> https://bugs.launchpad.net/ubuntu/+source/software-properties/+bug/1060335
[18:34] <infinity> smoser: Erk.  It fixed it when I tested...
[18:35] <smoser> look at the comment there. comment 5. i'm fairly sure i didn't make a user error of some sort.
[18:36] <slangasek> mlankhorst: English (and without the resolver debug) would be helpful, if you can reproduce this easily; the Dutch is slowing me down a bit
[18:36] <infinity> smoser: Yeah, I'm reading.  I'm just stumped as to why my testing went okay.  Maybe it was multiple runs in a row that broke something.
[18:37] <smoser> infinity, so this wasn't 100% instance.
[18:37] <smoser> i had tried once with the old version
[18:37] <infinity> smoser: Anyhow, mvo was going to land something that removed all that code and replaced it with a call into python-apt.  Maybe I should review that and give him an FFe instead of fiddling with it more.
[18:37] <smoser> but you would still need to fix that case anyway, and it surely dodn'st look like it.
[18:38] <infinity> smoser: No, having run it once with the old version shouldn't matter, it just looks like I missed one spot where I needed home-dir, from your log.
[18:38] <slangasek> mlankhorst: fwiw I don't think I've ever seen this bug before
[18:38] <infinity> smoser: (Though, I'm curious where that is...)
[18:38] <slangasek> seems to be a previously-unnoticed apt bug
[18:40] <mlankhorst> slangasek: yeah my q-lts-backports archive kind of hits the limits in many way of apt :)
[18:45] <infinity> smoser: Did you upgrade python3-software-properties as well?
[18:45] <infinity> smoser: That's what actually contains the fix.
[18:45] <smoser> i did not.
[18:45] <smoser> duh.
[18:46] <infinity> smoser: Double-check that for my peace of mind, but it should fix you up.
[18:49] <smoser> well, in a new machine with that installed it is fixed, infinity
[18:49] <mlankhorst> slangasek: but my ppa has the stack I was using, I think it worked before because of a workaround
[18:52] <james_w> pitti, oops, sorry, missed the message, you can poke me, or people from the bzr team should be able to do it
[18:53] <slangasek> mlankhorst: what kind of workaround do you mean?
[18:53] <mlankhorst> i had a conflicts on everything before
[19:00] <mlankhorst> or maybe because i only tested pure 64-bits before mostly
[19:10] <mlankhorst> shall I just file a launchpad bug?
[19:11] <slangasek> mlankhorst: yes, please
[19:25] <james_w> pitti, should be up to date now
[19:32] <mlankhorst> slangasek: bug 1062503 ?
[19:34] <slangasek> mlankhorst: attach the apt output in English, please
[19:34] <mlankhorst> slangasek: tomorrow :P
[19:34] <slangasek> ok
[19:34] <mlankhorst> ah who am I kidding, got nothing better to do, sec breaking my system again
[19:38] <mlankhorst> there
[19:40] <micahg> slangasek: infinity: either of you familiar with binary dependencies for objective C apps?
[19:40] <slangasek> moreso than I would like?
[19:41] <micahg> can you look at Bug #1051389 to tell me if I'm right or wrong?
[19:43] <slangasek> micahg: ok, hmm; I've never heard this before at all
[19:43] <micahg> heh, ok, I don't feel so bad now :)
[19:44] <micahg> but I'm quite unsure of where to go from here as sogo 1.3.16 is already in quantal
[19:45]  * micahg can always punt to release team...
[19:46] <slangasek> micahg: checking a random library, I can confirm that there are only symbols for the classes.  This seems quite horrid.
[19:47] <slangasek> but if sogo is broken without the new sope, seems like it ought to get in as a bugfix
[19:47] <slangasek> I'm sure both our gnustep users will be happier that way. :)
[19:49] <micahg> slangasek: so, do I have a pass from you to sync it or should I make him write an FFe?
[19:49] <ScottK> That sounded like a pass to me.
[19:49] <Laney> Yeah. Paste it in the bug for audit, and do it.
[19:50] <slangasek> yep
[19:52] <micahg> slangasek: thanks


[02:46] <defendguin> does mythtv work with digital cable?  my cable company is switch to all digital cable in this week.    Much of digital cable is encrypted.
[02:47] <rhpot1991> defendguin: tricky question
[02:47] <defendguin> i figured it would be encrypter
[02:47] <rhpot1991> http://www.mythtv.org/wiki/Digital_Television
[02:47] <defendguin> encrypted
[02:50] <defendguin> so i will need a set top box then :-(   this is a real bummer
[02:57] <defendguin> i don't suppose the encryption is easily cracked?
[03:00] <defendguin> my cable company is a pretty lousy one i wonder if they would encrypt it
[03:00] <rhpot1991> defendguin: you can hope they don't encrypt much over firewire
[03:01] <rhpot1991> other than that OTA channels should be available in clear QAM
[03:03] <defendguin> AVerMedia AVerTVHD MCE  A180 TV Tuner would replace my hauppage pvr 150 i guess
[03:33] <shadoxx_> Hello all. Had a question about a TV tuner I can't seem to get working on a Live distro of 8.10. It's an EVGA inDtube. Comes up in lsusb as 'ID eb1a:2883 eMPIA Technology, Inc.' and an lsmod shows it's using the em28xx modules.
[03:38] <tgm4883> shadoxx_, are you trying to work the tv tuner from the live disk?
[03:39] <shadoxx_> tgm4883: yessir, don't have a dedicated partition to try this out on
[03:39] <tgm4883> ah
[03:39] <tgm4883> the live disk is for the frontend only
[03:39] <tgm4883> for backend support, you have to install it
[03:39] <shadoxx_> This includes a backend though?
[03:39] <tgm4883> yes, once you install it
[03:40] <shadoxx_> I mean, I'm running the backend right now from live.
[03:40] <shadoxx_> Or is that kind of like a filler backend?
[03:40] <tgm4883> no you are not
[03:40] <tgm4883> you won't be able to run the backend from the live disk
[03:41] <shadoxx_> mythtv   18799  0.0  1.0<PHONE_NUMBER>6 ?        Ssl  03:38   0:00 /usr/bin/mythbackend --daemon --logfile /var/log/mythtv/mythbackend.log --pidfile /var/run/mythtv/mythbackend.pid
[03:41] <shadoxx_> What's that?
[03:41] <tgm4883> was that started by default?
[03:41] <shadoxx_> No, had to start it myself.
[03:41] <tgm4883> ah
[03:42] <tgm4883> then let me rephrase
[03:42] <shadoxx_> The problem I seem to be having is for whatever reason I can't get it to see my card as a ATSC device.
[03:42] <shadoxx_> i can't even get analog even
[03:42] <tgm4883> as you shouldn't be able to
[03:42] <shadoxx_> but i do have a /dev/video0
[03:42] <tgm4883> is mysql running?
[03:42] <shadoxx_> Yeah
[03:42] <shadoxx_> Had to start that myself as well lol
[03:43] <tgm4883> did you run mythtv-setup?
[03:43] <shadoxx_> yes
[03:43] <tgm4883> where are you storing the recordings?
[03:43] <shadoxx_> The default directory I suppose? I haven't explicitly set it.
[03:44] <tgm4883> see, being that you have mounted a read only file system, i'm guessing that it's not going to store them anywhere
[03:44] <tgm4883> which is one of the reasons the backend isn't available in the live disk
[03:44] <tgm4883> out of curiosity, did you have to install the backend?
[03:45] <shadoxx_> well, I'm not really worried about recording. I'm trying to use it as a TV viewer
[03:45] <shadoxx_> And no
[03:45] <shadoxx_> Basically I just ran the setup
[03:45] <shadoxx_> and it started
[03:45] <CRXLPY> When I select archivefiles I get a window telling me mytharchive is not compiled with the same libraries as mythtv and I need to recompile them. I swapped to the mythtv trunk mirrors a few months ago. a month or more ago mytharchive stopped working following an update. I have been searching the mirrors for newer mytharchive packages, none have come. Since I find no chatter about a similar issue in my searches I figure I have someth
[03:45] <tgm4883> you have to record
[03:45] <shadoxx_> For the pause live tv feature?
[03:45] <tgm4883> yes
[03:45] <shadoxx_> Isn't there a way to disable that?
[03:45] <tgm4883> no
[03:45] <shadoxx_> hmm
[03:46] <shadoxx_> well, on the ramdrive there is 712MB of space
[03:46] <shadoxx_> Is there a way to figure out, via the commandline, why my card isn't being recognized by MythTV?
[03:47] <shadoxx_> Some sort of log?
[03:47] <CRXLPY> look in /var/log
[03:47] <shadoxx_> found it
[03:47] <shadoxx_> that was a stupid question on my part
[03:47] <CRXLPY> ;)
[03:48] <shadoxx_> hahahahahah
[03:48] <shadoxx_> mythtv   18799  0.0  1.0<PHONE_NUMBER>6 ?        Ssl  03:38   0:00 /usr/bin/mythbackend --daemon --logfile /var/log/mythtv/mythbackend.log --pidfile /var/run/mythtv/mythbackend.pid
[03:48] <shadoxx_> errr
[03:48] <shadoxx_> nvm, sorry, pasting in the channel. i know how annoying that is
[03:48] <shadoxx_> it just has a note in the log to read the installation instructions and i lol'd
[03:50] <CRXLPY> what does the log show about it probing your usbtuner?
[03:51] <CRXLPY> burp
[03:51] <tgm4883> and everyone is backc
[03:51] <shadoxx_> Says I don't have any valid capture cards in the database. I think I deleted it though, lemme go re-add it
[03:51] <tgm4883> so yea
[03:52] <CRXLPY> would you have any feedback at all on my situation tgm4883?
[03:53] <CRXLPY> mytharchive is really the only plugin I care about and it doesnt work (
[03:53] <tgm4883> sec
[03:53] <tgm4883> have to put the dog out
[03:53] <CRXLPY> bowow
[03:54] <tgm4883> CRXLPY, you still using trunk repo?
[03:54] <CRXLPY> yes
[03:54] <tgm4883> what version of mytharchive and mythtv are you running?
[03:55] <CRXLPY> from what I read on the site, I cant go back right?
[03:55] <tgm4883> yea, IIRC the db's are not able to be downgraded
[03:56]  * tgm4883 just dropped his macaroni all over the floor
[03:56] <tgm4883> :(
[03:57] <CRXLPY> mytharchive 0.21+trunk19693     mythtv 0.21+trunk19951
[03:57] <CRXLPY> at least you have a dog
[03:58] <tgm4883> hmm
[03:58] <tgm4883> ok, they are both trunk which is good
[03:58] <tgm4883> do you have a mouse and keyboard on this box?
[03:58] <tgm4883> or can you vnc in
[03:58] <CRXLPY> and those are what I see on the trunk mirrors, no newer version of MA for a long time
[03:59] <CRXLPY> I am in front of it (tho not irc on it)
[03:59] <CRXLPY> no vnc req
[03:59] <tgm4883> can you fire up synaptic on it?
[03:59] <CRXLPY> in it now
[04:00] <tgm4883> go down to mytharchive and see if you can do "force version" and make it match the mythtv version
[04:01] <CRXLPY> no, only the fixes version is offered as an alternative
[04:01] <rhpot1991> darthanubis: if thats a 1.99.x version of mythexport you may need to stop the daemon as well sudo /etc/init.d/mythexport stop, then sudo apt-get -f install
[04:01] <rhpot1991> darthanubis: that should be fixed on the latest though, so for the record what version?
[04:01] <CRXLPY> I have looked on the mirrors and those are the newest on them
[04:01] <CRXLPY> tgm4883 ^^
[04:02] <CRXLPY> btw tgm4883 0.21+fixes18722 is the other version offered in Force Version
[04:03] <shadoxx_> hmm, I did a modprobe for the dvb module of my card
[04:03] <shadoxx_> ERROR: no valid capture cards are defined in the database.
[04:03] <shadoxx_> Perhaps you should read the installation instructions?
[04:03] <shadoxx_> I hate this terminal
[04:03] <shadoxx_> [ 3908.202282] Em28xx: Initialized (Em28xx dvb Extension) extension << that showed up when I probed the module for my card
[04:04] <CRXLPY> shadoxx_ what does the compatability page say about your device?
[04:04] <tgm4883> shadoxx_, so then it's not setup in mythtv-setup
[04:04] <shadoxx_> it says usually any device with a dvb extention will work
[04:04] <shadoxx_> and this is the same chipset as the hauppage capture card
[04:06] <shadoxx_> This one isn't listed at all.
[04:06] <shadoxx_> is there any way, without a gui frontend, to see how MythTV sees the card via the command line?
[04:06] <shadoxx_> the backend at least
[04:06] <tgm4883> CRXLPY, what version of Mythbuntu are you using?
[04:07] <CRXLPY> intrepid
[04:08] <tgm4883> ok
[04:08] <tgm4883> are you using the uk or us repo?
[04:08] <CRXLPY> only non-mainstream thing is use of trunk
[04:08] <CRXLPY> lemme look
[04:09] <shadoxx_> It also says in the frontend that the device is an unknown capture card. :-\
[04:09] <CRXLPY> looks like I am on the UK
[04:09] <shadoxx_> This is one of those analog/atsc combo cards
[04:09] <CRXLPY> Shadow__X the frontend does not matter till you make the backend happy
[04:09] <CRXLPY> shadoxx_ ^^
[04:10] <tgm4883> CRXLPY, might I suggest our PPA then?
[04:10] <tgm4883> https://edge.launchpad.net/~mythbuntu/+archive/ppa
[04:12] <shadoxx_> I meant in mythtv-setup, it says unknown, then my chipset.
[04:12] <shadoxx_> Also mentioned something about no extentions were found. Is there a mythtv-setup log?
[04:19] <shadoxx_> So anyone have any ideas as to why MythTV doesn't recognize my usb tuner?
[04:21] <tgm4883> shadoxx_, cause it's a live cd?
[04:22] <shadoxx_> I don't see why running as a live CD would be any different than installing.
[04:22] <shadoxx_> I mean
[04:23] <shadoxx_> Obviously I know the difference, but that shouldn't effect the way MythTV sees my card.
[04:23] <shadoxx_> It should still be able to say, "Hey, this is this card, and it can do this, this, and this."
[04:23] <shadoxx_> But it's just showing up as a generic Em28xx device
[04:24] <shadoxx_> I'm thinking maybe because it's such a new device, that this ID hasn't been added to the supported module yet.
[04:26] <crxdvr> tgm4883:  i am working on the ppa setup, will let you know how it works out
[04:32] <shadoxx_> I've found the problem. The v4l module doesn't support this device yet. http://www.linuxhq.com/kernel/v2.6/27/Documentation/video4linux/CARDLIST.em28xx
[04:33] <shadoxx_> my id is eb1a:2883
[04:33] <shadoxx_> Unknown EM2750/28xx video grabber << that's what's coming up in the MythTV setup
[04:34] <CRXLPY> good to know even if it isnt good
[04:36] <shadoxx_> Even in 2.6.28 it lists as Unknown EM2750/28xx video grabbe
[04:36] <shadoxx_> Doesn't look like there'll be support for this card for awhile. :-\
[04:38] <shadoxx_> Meh
[04:41] <shadoxx_> Is this channel log archived? For searching through I mean
[04:46] <crxdvr> tgm4883:  I cant force version to the ppa pkg. do I uninstall and reinstall the mythtv packages
[04:52] <CRXLPY> now I have errors never seen before "you have held broken packages / unable to lock the download directory"
[05:04] <crxdvr> I am here now
[05:39] <crxdvr> tgm4883:  the ppa version cannot understand the newer schema on my system (from the trunk install)
[05:39] <crxdvr> newer dbschema that is
[05:44] <crxdvr> tgm4883: now I dont even have a backend running :(
[05:50] <crxdvr> you around still?
[06:04] <crxdvr> till tuesday then... thanks
[13:24] <darthanubis> rhpot1991, sorry I was away
[13:25] <rhpot1991> and I was sleeping :)
[13:26] <darthanubis> I'm using your PPA, and just reinstalled myhtexport
[13:26] <darthanubis> it asked for my export dir and all
[13:27] <rhpot1991> darthanubis: you should use the mythbuntu testing ppa at this point (though they are currently the same)
[13:27] <darthanubis> * Starting MythExport Daemon: mythexport      syntax error at /usr/bin/mythexport-daemon line 46, near "co
[13:27] <rhpot1991> !%testing%
[13:27] <Zinn> to enable the mythbuntu-testing PPA, please go to http://launchpad.net/~mythbuntu-testing/+archive/ppa and add the sources.list entries for your distro version (gutsy, hardy, intrepid) to /etc/apt/sources.list
[13:27] <darthanubis> I'm using the mythbuntu daily builds in 9.04
[13:28] <darthanubis> Global symbol "$debug" requires explicit package name at /usr/bin/mythexport-daemon line 46.
[13:28] <darthanubis> Global symbol "$debug" requires explicit package name at /usr/bin/mythexport-daemon line 51.
[13:28] <darthanubis> Global symbol "$debug" requires explicit package name at /usr/bin/mythexport-daemon line 55.
[13:28] <darthanubis> BEGIN not safe after errors--compilation aborted at /usr/bin/mythexport-daemon line 59.
[13:28] <darthanubis> invoke-rc.d: initscript mythexport, action "start" failed.
[13:28] <darthanubis> sorry
[13:29] <rhpot1991> darthanubis: do a dpkg -l mythexport |grep ^ii
[13:29] <rhpot1991> tell me which version
[13:29] <darthanubis> weird, nothing came back?
[13:30] <darthanubis> 1.99.4
[13:31] <darthanubis> http://pastebin.com/d3bba97a3
[13:31] <darthanubis> 1.99.4.ppa3
[13:31] <rhpot1991> hmmm, intrepid or jaunty?
[13:31] <darthanubis> jaunty
[13:32] <rhpot1991> ah there we go
[13:33] <rhpot1991> maintaining multiple versions == no fun :(
[13:36] <darthanubis> I bet
[13:36] <darthanubis> I saw your threads in the forums
[13:36] <rhpot1991> I'm pushing a new version now
[13:37] <darthanubis> I've been trying to use mythexport for as long as you've been doing it
[13:37] <darthanubis> I like the web interface
[13:37] <darthanubis> now if I can just get it to work
[13:38] <darthanubis> I was/am getting the 500 error like others in the threads. BUt all my stuff checks out it seems
[13:39] <rhpot1991> most of those should be worked out by now, you'll get a 500 error if the cgi fails, then you need to look in /var/log/apache/error.log and show me that
[13:39] <rhpot1991> most of those were permission issues
[13:41] <darthanubis> [Mon Mar 16 17:12:26 2009] [error] [client <IP_ADDRESS>] '/etc/mythtv/mythexport/mythexport.cfg' couldn't be opened for writing: Permission denied at /var/www/mythexport/save_system_setup.cgi line 30., referer: http://localhost/mythexport/system_setup.cgi
[13:41] <darthanubis> yup permissions
[13:42] <darthanubis> [Mon Mar 16 17:12:26 2009] [error] [client <IP_ADDRESS>] Premature end of script headers: save_system_setup.cgi, referer: http://localhost/mythexport/system_setup.cgi
[13:43] <rhpot1991> darthanubis: pastebin ln -ls /etc/mythtv/mythexport
[13:43] <rhpot1991> !pastebin
[13:43] <Zinn> when pasting more than 5 lines of data please use http://mythbuntu.pastebin.com so you don't flood the channel.  Then please post the link in the channel.
[13:45] <darthanubis> you want me to pastebin what please?
[13:45] <darthanubis> ln?
[13:45] <darthanubis> you meant ls?
[13:46] <darthanubis> 4 -rw-r--r-- 1 www-data www-data 43 2009-03-17 09:26 mythexport.cfg
[13:49] <darthanubis> brb desktop is failing
[13:55] <rhpot1991> darthanubis: sorry ls -la /etc/mythtv/mythexport/
[13:55] <rhpot1991> interested in the results for the folder and configs inside
[13:56] <rhpot1991> prob doesn't have to be a pastebin even
[13:56] <darthanubis> http://pastebin.com/d5268760d
[13:57] <rhpot1991> hmmmm and you are still getting errors on system_setup.cgi?
[13:58] <darthanubis> yes
[14:00] <rhpot1991> ok, try to do it again and then pastebin the contents of your mythexport.cfg and apache error.log
[14:02] <darthanubis> well every link in mythexport is working
[14:02] <darthanubis> no 500 errors
[14:02] <rhpot1991> can you save the "system setup" and "mythexport setup"?
[14:04] <darthanubis> yes
[14:04] <rhpot1991> excelent, you were bit by and old permission issue then
[14:04] <rhpot1991> if you upgrade again the fix for the init script breaking should be out there
[14:04] <rhpot1991> ~ppa4
[14:04] <darthanubis> cool
[14:05] <darthanubis> I don't understand how to use ME though. This job queue..otg-full	Total Recordings: 1  	Delete?
[14:05] <darthanubis> On the go ...I get that part
[14:05] <darthanubis> Total recordings, I have yet to record anything
[14:06] <darthanubis> but it says 1?
[14:07] <darthanubis> I  chose user job 3, and user job 3 no longer appears as an option
[14:07] <darthanubis> I will read the wiki again
[14:07] <rhpot1991> well it is now a daemon, so for every action it has a queue not and loops through them
[14:07] <rhpot1991> s/not/now
[14:07] <rhpot1991> the delete option is to delete recordings you exported, say you don't want them on the RSS feed anymore
[14:08] <rhpot1991> everything in the On The Go section will just be recordings from MythTV, completely MythExport independant
[14:08] <rhpot1991> explain more whats going on with the user job?
[14:10] <darthanubis> well, I just wanted to be able to select a recording from a list and mythexport it. But the user job screen just gives my my user job list. I did not have anything assigned to 3 and 4 so I chose 3. And nothign happens except the option for 3 is blank now?
[14:12] <darthanubis> ok I see
[14:12] <darthanubis> so now mythexport is user job 3
[14:12] <darthanubis> so I have to run it from mythweb or the frontend?
[14:12] <darthanubis> mythexport did not name user job 3
[14:13] <darthanubis> so I'm doing that now via mythweb
[14:13] <darthanubis> I guess I left "description" blank
[14:13] <rhpot1991> ya sounds like it
[14:14] <rhpot1991> yep, you want to assign it to a user job, then in mythweb you can run it, or if you want it to run on that show every time there is an option in the scheduling section to do so
[14:14] <rhpot1991> I think I have screenshots on how to do that on the old wiki
[14:15] <rhpot1991> its in the bottom of the wiki, last screenshot
[14:17] <darthanubis> ok, I assigned a job, named it picked a show, it queued, and then claimed to be completed in no time, leaving no exported file?
[14:17] <rhpot1991> ok check the log: /var/log/mythtv/mythexport
[14:18] <rhpot1991> you created a config which you assigned to the userjob, right?
[14:18] <rhpot1991>  /var/log/mythtv/mythexport.log that is
[14:19] <darthanubis> yes
[14:19] <darthanubis> last entry from the 15th?
[14:19] <darthanubis> ERROR: mysqldump -hlocalhost -umythtv -p4bZJWQ1X -P3306 mythconverg recorded recordedseek recordedrating recordedprogram recordedmarkup recordedcredits --where="(chanid='1067' and starttime='2009-03-13 20:00:00')" --no-create-db --no-create-info > /mythimport.sql 2>&1 failed. at line 306 in /usr/bin/mythexport-daemon
[14:20] <rhpot1991> did you do an OTG job?
[14:20] <darthanubis> I tried, and then deleted it immediately
[14:20] <darthanubis> this job that just failed I ran from mythweb
[14:21] <darthanubis> there is no mythexport log entry for it though
[14:21] <rhpot1991> and there is nothing in the log for it?
[14:21] <rhpot1991> is it still in the jobqueue?
[14:21] <darthanubis> it says completed in myhtwebs job queue
[14:22] <darthanubis> Finished "User Job #3" for "Star Wars: The Clone Wars" recorded from channel 1066 at Mon Mar 16 17:00:00 2009
[14:22] <rhpot1991> yep, mythweb will say that as soon as its done adding it to the job queue
[14:22] <rhpot1991> now on mythexport check the job queue there
[14:22] <darthanubis> ok I see it there
[14:22] <rhpot1991> do a ps aux |grep mythexport
[14:22] <rhpot1991> verify its running
[14:25] <rhpot1991> if you haven't upgraded yet then the deamon wont be running till you do, need to get rid of that error first
[14:26] <darthanubis> technical difficulty with compiz or something after last upgrade
[14:27] <darthanubis> one sec
[14:27] <rhpot1991> ok take your time
[14:30] <darthanubis> 8527  0.2  0.2<PHONE_NUMBER>2 ?        S    10:18   0:01 gedit /var/log/mythtv/mythexport.log
[14:30] <darthanubis> 9568  0.0  0.0   7524   912 pts/0    S+   10:29   0:00 grep mythexport
[14:30] <rhpot1991> did you upgrade?
[14:30] <rhpot1991> to ppa4?
[14:30] <darthanubis> no
[14:30] <rhpot1991> do that
[14:30] <rhpot1991> otherwise your daemon can't start cause of that error
[14:32] <darthanubis> doing so now
[14:35] <darthanubis> upgrade passed without a hitch!
[14:35] <rhpot1991> great, if you check now the daemon should be running
[14:35] <darthanubis> mythtv   10602  0.0  0.1  64148 13208 ?        S    10:35   0:00 /usr/bin/perl -w /usr/bin/mythexport-daemon
[14:35] <rhpot1991> :)
[14:36] <darthanubis> SWEET!
[14:36] <rhpot1991> now if you check the log you should see messages indicating its exporting your recording
[14:36] <rhpot1991> and you should be able to see a file growing wherever your location is
[14:36] <darthanubis> The requested URL /mythexport/video/TOON-Star_Wars_The_Clone_Wars-Downfall_of_a_Droid-200903161.mp4 was not found on this server.
[14:36] <darthanubis> thats not happening
[14:36] <darthanubis> yet
[14:37] <rhpot1991> check the log to make sure there are no errors
[14:37] <darthanubis>  ERROR: cannot remove /home/anubis/store/mythrecs/mythexport/TOON-Star_Wars_The_Clone_Wars-Downfall_of_a_Droid-200903161.mp4.tmp. at line 533 in /usr/bin/mythexport-daemon
[14:37] <rhpot1991> hmmmm, I don't like using your home dir, special privledges can sometimes mess things up
[14:38] <rhpot1991> pastebin the lines in the config from today
[14:38] <rhpot1991> s/config/log
[14:38] <darthanubis> I know, we argue about that everytime you help me
[14:38] <rhpot1991> heh
[14:38] <darthanubis> I'm aware of the permissions issues
[14:38] <darthanubis> this is my recorded dir
[14:38] <darthanubis> permission permit mythtv recordings
[14:38] <darthanubis> ERROR: nice -n19 ffmpeg -i /home/anubis/mythrecs/1066_20090316170000.mpg -y -acodec libfaac -ab  -vcodec mpeg4 -b  -mbd 2 -flags +4mv+aic -trellis 2 -cmp 2 -subcmp 2 -s 320x240 -aspect '/home/anubis/store/mythrecs/mythexport/TOON-Star_Wars_The_Clone_Wars-Downfall_of_a_Droid-200903161.mp4' 2>&1 FAILED/ at line 538 in /usr/bin/mythexport-daemon
[14:39] <rhpot1991> darthanubis: run that by hand
[14:39] <rhpot1991> see what happens
[14:39] <rhpot1991> I see an issue now, nothing after -ab
[14:39] <darthanubis> Unable to parse option value "vcodec": undefined constant or missing (
[14:39] <darthanubis> Invalid value '-vcodec' for option 'ab'
[14:40] <rhpot1991> should be something like 128k after that
[14:40] <rhpot1991> so check your config and make sure you set an audio bitrate
[14:40] <darthanubis> k
[14:40] <rhpot1991> you can edit the config from the webinterface
[14:41] <darthanubis> does each field have to be completed?
[14:41] <rhpot1991> not every
[14:41] <rhpot1991> everything from title through codec should be though
[14:41] <rhpot1991> the others should be optional
[14:41]  * rhpot1991 should prob document some of this better
[14:46] <darthanubis> ERROR: nice -n19 ffmpeg -i /home/anubis/mythrecs/1066_20090316170000.mpg -y -acodec libfaac -ab 128 -vcodec mpeg4 -b  -mbd 2 -flags +4mv+aic -trellis 2 -cmp 2 -subcmp 2 -s 320x240 -aspect '/home/anubis/store/mythrecs/mythexport/TOON-Star_Wars_The_Clone_Wars-Downfall_of_a_Droid-200903161.mp4' 2>&1 FAILED/ at line 538 in /usr/bin/mythexport-daemon
[14:46] <darthanubis> WARNING: The bitrate parameter is set too low. It takes bits/s as argument, not kbits/s
[14:46] <darthanubis> Unable to parse option value "mbd": undefined constant or missing (
[14:46] <darthanubis> Invalid value '-mbd' for option 'b'
[14:48] <rhpot1991> make it 128kb
[14:48] <rhpot1991> looks like your video bitrate is missing as well
[14:48] <rhpot1991> make that something like 600kb
[14:48] <darthanubis> http://pastebin.com/d3be779f2
[14:52] <darthanubis> 500 internal server error again while trying ot change my config
[14:53] <rhpot1991> your aspect is empty as well
[14:53] <rhpot1991> darthanubis: pastebin the end of your apache error.log then
[14:54] <rhpot1991> I'd recommend you leave the remove commercials checkbox off till you have the rest working first, that code was submitted by another user and hasn't gone through much testing
[14:56] <darthanubis> http://pastebin.com/d54f90b7c
[14:56] <darthanubis> ok
[14:56] <darthanubis> thats my new cfg
[14:57] <rhpot1991> that looks better
[14:57] <rhpot1991> what was the issue with the 500 error?
[14:59] <darthanubis> I borked the cfg file
[14:59] <darthanubis> I deleted it and let mythexport rewrite it
[14:59] <darthanubis> ERROR: AtomicParsley '/home/anubis/store/mythrecs/mythexport/USA-Law_Order_Criminal_Intent-Maledictus-20090316140000.mp4' --genre "TV Shows" --stik "TV Show" --TVNetwork USA --TVShowName "Law & Order: Criminal Intent" --TVEpisode "EP004461730020" --TVEpisodeNum 22 --TVSeason 21 --description "Goren and Eames investigate the decapitation of an author who is the daughter of a jailed Russian mobster." --title "Maledictus" 2>&1 FAILED at
[14:59] <darthanubis>  line 553 in /usr/bin/mythexport-daemon
[14:59] <darthanubis> Thats with remove commercial checked
[15:00] <rhpot1991> did the ffmpeg line complete?
[15:00] <darthanubis> I just unchecked that and will now try again
[15:00] <darthanubis> I did not get an ffmpeg line this time in the log
[15:03] <darthanubis> ERROR: AtomicParsley '/home/anubis/store/mythrecs/mythexport/COMEDY-The_Daily_Show_With_Jon_Stewart--20090316100000.mp4' --genre "TV Shows" --stik "TV Show" --TVNetwork COMEDY --TVShowName "The Daily Show With Jon Stewart" --TVEpisode "SH002930530000" --TVEpisodeNum  --TVSeason  --description "A humorous slant on top news stories." --title "" 2>&1 FAILED at line 553 in /usr/bin/mythexport-daemon
[15:03] <darthanubis> I'm not gettign an ffmpeg line anymore
[15:04] <rhpot1991> verify /home/anubis/store/mythrecs/mythexport/COMEDY-The_Daily_Show_With_Jon_Stewart--20090316100000.mp4 exists?
[15:04] <darthanubis> that dir is empty as nothing has been exported
[15:06] <rhpot1991> ok what are the permissions on that dir?
[15:08] <rhpot1991> there should be directory checks all over the place by this point though
[15:08] <darthanubis> drwxrwxr-x   2 mythtv mythtv          6 2009-03-14 17:09 mythexport
[15:08] <rhpot1991> ok try to run this: nice -n19 ffmpeg -i /home/anubis/mythrecs/1066_20090316170000.mpg -y -acodec libfaac -ab 128kb -vcodec mpeg4 -b 600kb -mbd 2 -flags +4mv+aic -trellis 2 -cmp 2 -subcmp 2 -s 320x240 -aspect 4:3 '/home/anubis/store/mythrecs/mythexport/TOON-Star_Wars_The_Clone_Wars-Downfall_of_a_Droid-200903161.mp4' 2>&1
[15:09] <darthanubis> That works
[15:10] <rhpot1991> ok I'm gonna need to dig a little then
[15:11] <rhpot1991> it shouldn't be running AtomicParsley till ffmpeg is complete, and it should tell us if there was an error
[15:27] <rhpot1991> !status
[15:27] <Zinn> I am alive.
[15:40] <Daviey> tgm4883: bored?
[15:40] <tgm4883> Daviey, maybe
[15:41] <rhpot1991> tgm4883: bored and can't handle constrive criticism :)
[15:42]  * tgm4883 leaves Daviey to help support crxdvr
[15:42] <Daviey> where "constrive criticism" ==  "you suck"
[15:42] <rhpot1991> Daviey: it was something along the lines of Al Gore would make a better Jack Bower
[15:43]  * Daviey realises what channel this is :/
[15:43]  * rhpot1991 blames tgm4883 for that as well
[15:43] <Daviey> +1
[16:02] <JEDIDIAH__> ...sounds like nuvexport. I tried that, or rather extracting just the necessary ffmpeg bits. It got me nowhere. I ended up using handbrake instead.
[16:15] <hein_> Hello all.
[16:17] <hein_> One question. I tried to look HDTV on my computer with myth. If I do,  the movie ever 1  - 2 seconds stucks, but the CPU (AMD X2 3800) has only 70% - 80% load. Did anybody have an idea where I could search the bottleneck? Thanks.
[21:30] <t1ger> Hello
[21:33] <rhpot1991> !hi
[21:33] <Zinn> Hi $nick, how are you?  Something we can help you with today?
[22:24]  * t1ger looking for assitance on an issue with an DVB card and SATA
[22:24] <t1ger> "saa7146 (0) vpeirq: used 1 times >80% of buffer"
[22:24] <t1ger> 02:09.0 Multimedia controller: Philips Semiconductors SAA7146 (rev 01)
[22:25] <t1ger> Ubuntu 8.10 x64
[22:25] <t1ger> AIK seems to be related to SATA activity and recording/using the card.


[08:10] <DEvil0000> I have a issue with my 14.04 and hope to find some help here. Description: https://hastebin.com/raw/fareguzego
[08:11] <DEvil0000> in short: core dumps of 32Bit processes on a 64Bit OS are not correct somehow. so its about gdb, kernel, ubuntu 14.04/16.04 and packages
[14:30] <mamarley> apw: It looks like some of the mainline builds for 4.10.13 failed (i386-lowlatency is missing, for example).
[20:22] <dmj_s76> sforshee: Can we get a backport for intel/ibt-12-16.* for xenial?
[20:30] <sforshee> dmj_s76: soon, need to wrap something else up first
[20:35] <dmj_s76> sforshee: thanks!