[00:21] <cjwatson> rbasak: Please could you merge libapache2-mod-perl2 (or I'll do it if you like, but you touched it last)?
[00:21] <cjwatson> Needed for Perl 5.22
[00:33] <Bluefoxicy> I wonder why do-release-upgrade never works, and then you apt-get -f upgrade and it fixes it (mostly), and then you have like... fontconfig not regenerating font cache because of missing symbols, and you do-release-upgrade again to get to the next distro and all is well.
[00:33] <Bluefoxicy> pretty cool that it can fail catastrophically and you can say "well fix it" and it does, though.
[05:52] <pitti> Good morning
[07:04] <cyphermox> hey pitti
[07:47] <dholbach> good morning
[10:08] <cpaelzer> Hi I was following this guide https://www.debian.org/doc/manuals/maint-guide/advanced.en.html#librarysymbols
[10:08] <cpaelzer> based on that I created http://paste.ubuntu.com/14086901/ for my use case
[10:08] <cpaelzer> and the symbols file I got is this http://paste.ubuntu.com/14086902/
[10:08] <cpaelzer> now I wanted to ask for a confirmation about the following
[10:09] <cpaelzer> is that a symbol that was in 2.0 and is still there?
[10:09] <cpaelzer><EMAIL_ADDRESS>2.2
[10:09] <cpaelzer> and this one, one that shows up in 2.2 but was not there in 2.0?
[10:09] <cpaelzer><EMAIL_ADDRESS>2.2
[10:12] <ginggs> cpaelzer: no, it looks like the _2.0 is part of the name
[10:18] <cpaelzer> ginggs: you mean of the symbol name?
[10:19] <cpaelzer> yeah that could be I remember they combine that in the split libraries - I just never realized how it shows up in the combined lib
[10:19] <ginggs> cpaelzer: yes, those are versioned symbols
[10:19] <cpaelzer> ginggs: great, now tihngs fall into place - thanks
[10:20] <cpaelzer> that will do until I get further to split the libs anyway
[10:45] <cpaelzer> I found an example that might have been better
[10:45] <cpaelzer><EMAIL_ADDRESS>2.2
[10:45] <cpaelzer> that seems to be added with 2.1 and existing in 2.2
[10:46] <cpaelzer> anyway, builds fine now - thanks once more
[11:21] <ginggs> cpaelzer: yw, but looking at your new example<EMAIL_ADDRESS>2.2' the _2.1 is part of the name and #MINVER# is 2.2
[11:50] <Unit193> https://bugs.debian.org/808289
[11:56] <mardy> xnox_2016: hi! Could you please run the tests on this again: lp:~mardy/libaccounts-glib/s390-tests
[12:09] <cpaelzer> mardy: IIRC xnox_2016 has said he will be out til next year, is it just about rerunning that on s390 or something more complex?
[12:09] <mardy> cpaelzer: ah, I was wondering about the nick...
[12:10] <mardy> cpaelzer: yes, just run that branch in a s390 builder; is it something that you could do?
[12:10] <cpaelzer> mardy: if it is easy to run I can help
[12:10] <cpaelzer> mardy: well in a builder I cant
[12:10] <cpaelzer> but in a "normal" s390 system if that helps?
[12:10] <mardy> cpaelzer: ah, that's probably even better :-)
[12:10] <cpaelzer> so just autogetn / configure / make / ?
[12:11] <mardy> cpaelzer: yes, but it's better if you run "dpkg-buildpackage -rfakeroot -b -us -us"
[12:11] <mardy> cpaelzer: I know that the tests will fail, and I'd need to see the logs afterwards
[12:11] <cpaelzer> ok, lets see - that system never built anything - a few package installs ahead ...
[12:12] <cpaelzer> mardy: ok I'll let you know and you can identify if it fails at the right spot :-)
[12:12] <mardy> cpaelzer: apt-get build-dep libaccounts-glib should do the trick
[12:12] <mardy> cpaelzer: excellent, thanks a lot!
[12:16] <cjwatson> mardy: Why not ask for a suitably-configured PPA where you can upload tests for yourself?
[12:17] <cjwatson> Since you're a Canonical employee so can have devirtualised PPAs ...
[12:17] <mardy> cjwatson: I didn't out of ignorance, I guess :-)
[12:17] <mardy> cjwatson: is it documented somewhere?
[12:18] <cjwatson> mardy: I don't recall, sorry
[12:19] <cjwatson> mardy: But create a dedicated PPA for the purpose for yourself, then explain the requirement on https://answers.launchpad.net/launchpad/+addquestion
[12:20] <mardy> cjwatson: excellent, will do that right now then, thanks
[12:24] <mardy> cjwatson: done: https://answers.launchpad.net/launchpad/+question/279601
[12:25] <cpaelzer> mardy: until you have set up the ppa following the hints of cjwatson you can check if this is what you were looking for http://paste.ubuntu.com/14087452/
[12:26] <mardy> cpaelzer: lovely, thanks!
[12:26] <cpaelzer> mardy: if the locale issues annoy you I've fixed those now
[12:27] <mardy> cpaelzer: nah, it's fine
[12:27] <cpaelzer> mardy: you're welcome - was worth getting my machine a few packages
[12:28] <mardy> cpaelzer: is there anything special about s390? I wonder why the tests run fine in all other archs, but fail on s390... Maybe something unique about endiannes, pointer size...?
[12:28] <cpaelzer> big endian to start with
[12:28] <wgrant> mardy: That PPA is done.
[12:28] <wgrant> mardy: PIE is also enabled on s390x by default.
[12:28] <cpaelzer> pointer size is 64bit in ss390x and 31 !31 not 32! in s390
[12:29] <cpaelzer> but I guess we only do s390x
[12:29] <wgrant> But not on the other archs yet.
[12:29] <mardy> wgrant: excellent, thanks
[12:30] <cpaelzer> mardy: in any case you can find the assorted list of "being special"  in http://www-01.ibm.com/support/docview.wss?uid=isg2b9de5f05a9d57819852571c500428f9a
[12:30] <cpaelzer> mardy: but not like a short summary :-)
[12:31] <mardy> cpaelzer: ok, I'll keep that handy for later, in case I get really stuck
[12:31] <cjwatson> wgrant: Ah, thanks for beating me to it.
[12:32] <cjwatson> mardy: https://wiki.debian.org/ArchitectureSpecificsMemo is really helpful for this kind of question.
[12:32] <cjwatson> mardy: Doesn't mention Ubuntu-specific things like PIE being enabled on s390x, but otherwise very useful.
[12:32] <cjwatson> cpaelzer: ^- more useful than single-arch docs for most people :)
[12:32] <didrocks> barry: hey! did you get any chance to find out what the issue was on the nose/coverage/html issue?
[12:33] <cpaelzer> cjwatson: I didn't know that, but I like the comparison that can be handy - worth a bookmark, thanks
[12:34] <cjwatson> And indeed, s390 (not s390x) is irrelevant in Ubuntu and was removed from Debian a while back too.
[12:34] <cpaelzer> cjwatson: hmm am I supposed to fix missing info in there?
[12:35] <cpaelzer> cjwatson: well have no user yet in that wiki
[12:36] <cjwatson> cpaelzer: Not "supposed to", though I'm sure corrections and clarifications would be welcome (anyone can create an account there AFAIK).  Do keep it in roughly the current style though :)
[12:36] <cpaelzer> cjwatson: just missing the huge page sizes, I'll request an account
[12:37] <cjwatson> Make sure that it actually matches configuration in Debian for that kind of thing.
[12:37] <cpaelzer> cjwatson: I have a debian on s390 to check
[12:38] <cjwatson> s390x, perhaps?
[12:38] <cpaelzer> cjwatson: wgrant: mardy: one thing that doesn't fit the table but is sometimes worth to know - a cache line is rather long with 256 byte
[12:38] <cpaelzer> I meant s390x
[12:38] <wgrant> I guess they can afford that with the hundreds of megabytes of L4...
[12:39] <cjwatson> cpaelzer: You could add a heading and a bit of free-form text further down the page about that if you wanted.
[12:39] <cjwatson> cpaelzer: Though does that often affect userspace porting?
[12:40] <cpaelzer> cjwatson: not porting in terms of function but a lot of performance issues with cache line bouncing
[12:40] <cjwatson> cpaelzer: OK, that's not really the point of this page
[12:41] <cjwatson> cpaelzer: The point is to provide a reference for a package maintainer scratching their head about why their package works on one set of architectures but not another, and to let them quickly match that up with characteristics of the architectures that do/don't work
[12:41] <cpaelzer> cjwatson: ok thanks, then I'll just add the huge page sizes
[12:42] <cjwatson> cpaelzer: I would think pretty carefully before turning it into a performance reference
[12:42] <cjwatson> (though there is a little bit of that relating to alignment)
[12:42] <cpaelzer> cjwatson: I'll omit the cache line thing for now, it is just my old history being s390x performance engineer for a decade that sometimes comes back :-)
[12:43] <cjwatson> If you did add that, you'd want to explain how userspace ought to take account of it
[12:44] <cpaelzer> cjwatson: that is the reason why I omit the cache line thing on this page, it would require too much space and by that not suit the page as it is
[12:47] <mardy> cpaelzer: hey, would you be able to run a command for me in the build directory?
[12:48] <cpaelzer> mardy: sure
[12:48] <mardy> cpaelzer: in the "tests" directory: make check TEST_CASE=AccountService
[12:49] <cpaelzer> mardy: http://paste.ubuntu.com/14087565/ ?
[12:50] <mardy> cpaelzer: ok, then I need to see the DB, let me find the right command to dump it...
[12:51] <mardy> cpaelzer: I guess just "sqlite3 /tmp/accounts.db" and then a ".dump" from the interactive console
[12:52] <mardy> cpaelzer: ah, but now I see that the tests passed... :-/
[12:52] <cpaelzer> mardy: http://paste.ubuntu.com/14087577/ here for you anyway
[12:53] <mardy> cpaelzer: yep, that's correct, as expected
[12:53] <mardy> cpaelzer: and make check TEST_CASE=Create ?
[12:54] <mardy> cpaelzer: just tell me if it passes or not
[12:54] <cpaelzer> mardy: fails
[12:54] <mardy> cpaelzer: excellent, then can I see the logs please?
[12:55] <cpaelzer> mardy: => http://paste.ubuntu.com/14087590/ ?
[12:55] <cpaelzer> mardy: both tests have pass=1/Fail=1
[12:56] <mardy> cpaelzer: weird that the full log is not attached; can you please paste me the tests/accounts-glib-test.sh.log file?
[12:57] <cpaelzer> mardy: http://paste.ubuntu.com/14087600/
[12:57] <cpaelzer> ah you meant the .log
[12:57] <cpaelzer> mardy: http://paste.ubuntu.com/14087602/
[12:58] <cpaelzer> cjwatson: with some help from IBM friends I was also able to calrify the float/double columns of that - now s390x looks as it should. Thanks for pointing me there
[12:58] <cjwatson> cool
[12:59] <mardy> cpaelzer: eh, it's mysterious, looks like the logs from the failing test are completely missing
[13:00] <cpaelzer> mardy: I rerun the test and see that the file is updated
[13:00] <cpaelzer> mardy: so it is not just some old content, it really writes just those few lines
[13:01] <mardy> cpaelzer: yes, I can see that's the correct file, but something is missing; looks like the output of the failed test is being discarded; might be a bug in the check testing tool
[13:01] <cpaelzer> mardy: the log still ends with "task-0: 100%: Checks: 4, Failures: 0, Errors: 0" if I run the TEST_CASE=AccountService instead
[13:02] <mardy> cpaelzer: and what if you try: make check TEST_CASE=Create WRAPPER=time ?
[13:02] <cpaelzer> mardy: /root/s390-tests/libtool: line 10051: exec: time: not found
[13:02] <cpaelzer> let me install
[13:03] <rbasak> cjwatson: doing it now.
[13:03] <cjwatson> rbasak: thanks!
[13:05] <cpaelzer> mardy: the log now at least has some errors http://paste.ubuntu.com/14087637/
[13:05] <cpaelzer> better?
[13:09] <mardy> cpaelzer: thanks, that's extremely useful!
[13:09] <cpaelzer> mardy: maye even better make check TEST_CASE=Create WRAPPER="ltrace -T -S -r "
[13:10] <cpaelzer> mardy: => http://paste.ubuntu.com/14087659/
[13:10] <cpaelzer> mardy: just in case you really want to know whats going on below :-)
[13:13] <mardy> cpaelzer: thanks, never used that command, I usually do strace, but this seems even better
[13:13] <cpaelzer> mardy: its combined and a few timing extras
[13:13] <cpaelzer> mardy: and then there is no s390x strace packet yet in the repos
[13:18] <mardy> cpaelzer: it's a bit unfortunate that it doesn't show the first parameter of SYS_open(), just ""
[13:18] <mardy> cpaelzer: actually, it fails to get the string parameters of all the SYS_* functions
[13:21] <mardy> cpaelzer: anyway, the problem is that the test is setings the permissions of a file to read-only, then the library attempts to open the file with O_RDWR, and we'd expect that to fail... but from the logs (both the test logs and the ltrace) I can see that it succeeds to open it
[13:21] <mardy> cpaelzer: what filesystem are you using on /tmp ?
[13:22] <cpaelzer> mardy: /tmp is no extra mount, btu actually on / and that is ext4
[14:06] <rbasak> cjwatson: uploaded. I couldn't run the dep8 tests local (some issue with lxc and xenial) so we'll have to see.
[14:09] <pitti> cjwatson: OOI, we have tons of idle arm64 builders on scalingstack; what's missing to use them as distro buildds?
[14:09] <pitti> rbasak: adt-virt-lxc works well here, what's up?
[14:10] <rbasak> pitti: I can't get lxc-start-ephemeral to start a xenial container on vivid (I need to replace my dev VM with something newer)
[14:10] <rbasak> So it's not adt-virt-lxc, it's just between me and lxc I think.
[14:15] <doko> pitti, kernel and qemu updates at least, afaik
[14:15] <rbasak> I haven't tried to reproduce in a fresh VM or anything yet; probably easier to just go to Wily or Xenial for a new test VM.
[14:15] <pitti> rbasak: ah yes, high time :) wily host and xenial guest kind of works, but I must pin lxc and lxcfs to wily-release (not -updatse)
[14:16] <pitti> doko: well, if anything the PPA builders should be *more* complicated and demanding as they need stronger virtualization?
[14:16]  * rbasak do-release-upgrades it
[14:16] <pitti> doko: but we have > 25 PPA builders which are just twiddling thumbs while the 5 distro builders can't keep up, hence I was curious
[14:17] <rbasak> It's sort of throwaway (I do merges, builds and tests on it and nothing else really) but it's a pain to set up again because of the large numbers of chroots, lxc template containers, adt-qemu images and stuff I end up with on it.
[14:19] <pitti> rbasak: why would you throw these away?
[14:19]  * pitti introduces rbasak to the magic of keeping $HOME between installs :)
[14:20] <pitti> I keep /srv too, which is unencrypted and contains all my VMs, containers, and schroots
[14:21] <rbasak> I like to know that I can reproduce things and not carry on state indefinitely and get myself stuck later.
[14:21] <rbasak> I could script it all, I just haven't (recently).
[14:22] <rbasak> So I don't like cruft building up in $HOME. I do carry it forward on my main personal machine, but I don't use that for dev builds and tests as I don't want to drag all of that unnecessarily into my full backups.
[14:22] <rbasak> And I don't like maintaining long exclude lists for my full backups. I consider that dangerous.
[14:23] <rbasak> Plus it saves me a ton of bandwidth and I get speed by having a machine closer to the archive.
[14:23] <rbasak> (or maybe a mirror, I don't know)
[14:23] <rbasak> Anyway, this time I'm just doing a do-release-upgrade because I can't be bothered to recreate. I'll probably do it next cycle though.
[14:24] <rbasak> It feels good when everything is clean :-)
[14:25] <barry> didrocks: not yet, but it's first on my list for this morning
[14:25] <didrocks> barry: excellent! keep me posted :-) (and good luck for the hunt)
[14:25] <barry> didrocks: will do!
[14:30] <pitti> rbasak: ah, I do my development in ~/ubuntu and ~/debian which aren't covered by backups, and I have scripts to reproduce all the virt environments
[14:30] <pitti> rbasak: and build stuff in schroots
[14:33] <rbasak> If I exclude things from backups then my restores aren't really restores any more, they're "restore and then fix stuff up manually again" which I don't want to have to deal with after a disaster.
[14:33] <rbasak> So my full backups are really full backups (I do exclude /proc, /sys and /tmp etc though), so I have more confidence in my DR plan and I will be able to restore and be productive again quickly.
[14:34] <rbasak> OTOH my dev VM could explode, which would be annoying since that isn't backed up. But I can recreate it quickly enough to do whatever task I need to do - I won't need it all on the first day after DR.
[14:34] <rbasak> I like to have that separation.
[14:35] <rbasak> I also do have to make sure that anything on the dev VM I want to keep is mirrored locally. But rsync and git make that easy.
[14:35] <cjwatson> pitti: They fail to reset a very large percentage of the time, so are currently unusable in practice (they only stay up if idle, pretty much).
[14:35] <cjwatson> pitti: We have two upgrade tickets sitting with GSA to upgrade qemu and the kernel on the hosts, which we hope will help.
[14:35] <pitti> cjwatson: ah, too bad; thanks, I was curious
[14:36] <cjwatson> pitti: And yes, those are very high priority because as you say the current five can't keep up, but GSA has been too swamped to deal with these ...
[14:42] <dobey> hmm
[14:42] <dobey> is there a preempt-rt version of the lts-wily kernel for 14.04 anywhere?
[14:45] <rbasak> pitti: fyi, upgrading to wily fixed the issue. I don't know if that's because of some side effect though.
[14:46] <pitti> rbasak: ah, then you are lucky; I have to pin the versions on the armhf production machines, but maybe that's an arch specific problem
[14:47] <pitti> rbasak: and if there's still trouble, I hear we have a xenial development series :)
[14:47] <rbasak> :)
[14:47] <rbasak> Hey someone needs to dogfood the stable release. We'd never know when we need SRUs otherwise :-P
[15:06] <barry> didrocks: looking now.  this is lp:ubuntu-make right?  on xenial?  what do i need to do to set things up to run the nosetests3 command from your pastebin?  (nosetests3 doesn't like the --cov=umake argument)
[15:07] <didrocks> barry: lp:ubuntu-make or github :)
[15:08] <barry> didrocks: ah.  what's the url?
[15:08] <didrocks> barry: if you install the build-deps, it should like --cov=umake :)
[15:08] <didrocks> barry: https://github.com/ubuntu/ubuntu-make
[15:08] <didrocks> (but lp:ubuntu-make is supposed to be a mirror)
[15:09] <didrocks> barry: so, from this, install the build-deps and run the nosetests3 command I pastebined yesterday
[15:09] <barry> didrocks: everyday i forget more and more bzr :)
[15:09] <didrocks> heh ;)
[15:10] <didrocks> barry: basically I have a wrapper "runtests" which is setting the right options, I just copied nosetests3 so that it's easier for you to reproduce this
[15:10] <didrocks> barry: oh, and yeah: xenial
[15:10] <barry> didrocks:
[15:10] <barry> Ran 1 test in 4.583s
[15:10] <barry>
[15:10] <barry> OK
[15:10] <barry>
[15:10] <barry> let me try runtests
[15:11] <barry> (after tweaking the path since i obviously don't have /home/didrocks... :)
[15:11] <barry> i used a relative path tests/__init__.py - wonder if that makes a difference
[15:12] <didrocks> barry: you did use all the options I pasted?
[15:12] <barry> didrocks: yep
[15:12] <didrocks> weird
[15:12] <barry> (after build-deps)
[15:12] <didrocks> so:
[15:12] <didrocks> try:
[15:12] <didrocks> ./runtests --publish --coverage pep8
[15:13]  * barry tries
[15:14] <barry> didrocks: ran to completion, no problem
[15:14] <didrocks> barry: hum, I wonder if a new dep isn't needed then :/
[15:14] <didrocks> barry: I'm having Coverage.py warning: No data was collected.
[15:14] <rbasak> pitti: unfortunately the dep8 test still fails because it can't upgrade systemd inside adt-virt-lxc which appears to be a test dep somehow. It times out. I won't worry about it though. I presume that'll get sorted soon.
[15:15] <didrocks> barry: same in a clean ubuntu-desktop, with just the build-deps installed
[15:15] <didrocks> xenial, right?
[15:15] <barry> didrocks: could you have some stale data?  try cleaning out everything from your git repo and try again?
[15:15] <rbasak> (the postinst times out, not adt-virt-lxc)
[15:15] <didrocks> barry: good idea
[15:15] <pitti> rbasak: yes, that's what I meant
[15:15] <barry> didrocks: yep, xenial, though i haven't dist-upgraded this morning yet :)
[15:15] <rbasak> Ah, OK
[15:15] <didrocks> barry: well, should have failed form yesterda
[15:15] <didrocks> barry: let me try a clean repo
[15:15] <pitti> rbasak: that's some lxcfs issue, and downgrading lxcfs and lxc to the release versions WFM
[15:15] <barry> didrocks: cool
[15:15] <rbasak> pitti: so pinning the versions fixes that?
[15:15] <rbasak> Right, got it. Thanks.
[15:16] <pitti> rbasak: on the armhf production machines at least; this doesn't happen with the xenial versions
[15:16] <didrocks> barry: you're right, WTH?
[15:16] <didrocks> clean repo works
[15:16] <pitti> rbasak: so maybe these two are missing an accompanying cgmanager or whatever, I didn't have time to investigte this deeply yet
[15:16] <didrocks> barry: so, staled .coverage corrupted data?
[15:16] <barry> didrocks: probably just some stale/broken data.
[15:16] <barry> didrocks: yep
[15:17] <didrocks> barry: well, "happy" at least that's not super bad :)
[15:17] <barry> that's why this is my favorite git alias: distclean = "clean -dxfi" :)
[15:17] <didrocks> ahah :)
[15:17] <didrocks> thanks for giving this hint barry!
[15:17] <barry> didrocks: sure thing!  glad it's working
[15:18] <didrocks> ;)
[15:18] <didrocks> me too
[15:22]  * didrocks can't see anything and feel tired :)
[15:23] <didrocks> feels*
[15:23] <didrocks> so, time for week-end, couldn't take any break today
[15:23] <didrocks> have a good holidays for those leaving tonight, and happy new years!
[15:23] <didrocks> for the others, see you on Monday |m|
[15:30] <mardy> cjwatson, cpaelzer_afk: just for the record, this seems to fix the libaccounts-glib tests for s390x -- so indeed, an endianness issue: https://gitlab.com/accounts-sso/libaccounts-glib/commit/a6c28fea9fa791a85b1809f00cc43d16b87f2b77
[15:33] <rbasak> pitti: and adt-run passed. Thanks! \o/
[15:33] <rbasak> pitti: is there a bug on lxc needing a downgrade? If not I can create one.
[15:34] <pitti> rbasak: I haven't filed one yet, I don't have much more information than just "it breaks"; but if it's happening on your system too, it's not just a quirk of my armhf machines
[15:34] <rbasak> pitti: I'll file one then, thanks.
[15:34] <pitti> rbasak: they are running an ancient kernel, but it seems your case is much easier to reproduce
[15:34] <pitti> rbasak: cheers
[15:57] <rbasak> pitti: I can't reproduce it any more :-(
[15:57] <rbasak> Oh no, I can. I just can't reduce it.
[16:00] <rbasak> pitti: filed bug 1527666
[16:01] <pitti> rbasak: try with looping systemctl daemon-reload
[16:01] <pitti> that will give the cgroups some exercise
[16:01] <pitti> rbasak: it quite obviously locks up doing some cgroup operations, and these are being channeled through cgmanager/lxcfs
[16:02] <pitti> rbasak: not sure about the details, but that might give you some hint if you try to reduce it
[16:02] <rbasak> That doesn't seem to work.
[16:02] <rbasak> I'll leave it for now. It is reproducible currently just by running adt-run at least.
[16:02] <rbasak> For now, anyway.
[16:04] <Laney> barry: hi, did you notice the ubuntu i386 images have been failing to build with an error from axi?
[16:05] <barry> Laney: yep, cyphermox pointed me at the build failure.  it's a 32bit thing, but i hope to have time today to investigate
[16:05] <cjwatson> mardy: Indeed, very plausible.
[16:05] <Laney> cool
[16:05] <pitti> rbasak: curious that lxcfs 0.10-0ubuntu2.1 works for you -- that's what I had to downgrade
[16:05] <cyphermox> oi
[16:05] <pitti> rbasak: anyway, followed up, thanks for filing
[16:07] <pitti> and with that, TTFN -- happy EOL holidays everyone!
[16:08] <cyphermox> end of line holidays?
[16:08] <pitti> "EOY"
[16:08] <cyphermox> happy holidays pitti ;)
[16:08] <pitti> all the more proof that I need them :)
[16:17] <rbasak> EOL?!
[16:17] <rbasak> No thanks.
[16:17] <rbasak> EOY maybe :)
[16:17] <rbasak> Oh, he said that.
[17:43] <rbasak> infinity: I'd like to talk to you about Docker. Are you around and free today? I'm gone for Christmas after today so otherwise maybe in January?
[17:50] <infinity> rbasak: I'm technically already gone (until January as well).
[17:50] <Captonjamason> quick question, i need to update to boost version 1.39, how may i do that,
[17:51] <rbasak> infinity: that's fine. Can I stick something in the calendar in Jaunary? When would be good for you?
[17:51] <Captonjamason> nvrmnd
[17:51] <Captonjamason> im just wasting my time
[17:51]  * rbasak is never sure what timezone infinity is in
[17:51] <infinity> rbasak: Well, in theory, I'm in MST7MDT.  Pick something that's not so early in the morning that I'll want to punch you.
[17:52] <rbasak> OK, thanks
[17:54] <rbasak> infinity: 1700 UTC == 1000 for you? We can bump it back further if I'm tied up that evening, but I've put it there for now. I hope I'm not about to get a punch!
[17:54] <Captonjamason> oh its not too early in the morning infinity
[17:54] <infinity> rbasak: Nah, 10ish works.
[17:56] <rbasak> OK, thanks!
[17:56] <teward> so how do I interpret update_excuses if it says for a package "Depends: [itself] perl (not considered)"?  (where [itself] indicates it depends on itself)
[17:58] <infinity> teward: You're reading it wrong.  It's saying that [itself] depends on perl.
[17:58] <teward> ah OK
[17:58] <teward> that confused me a little :)
[17:58] <infinity> teward: Makes more sense when you see a source package that produces different binary packages, that's telling you that [binary] depends on [other source].
[17:58] <teward> ok
[17:59] <infinity> Oh, actually.  No.  It is the source package.  I lied.
[17:59] <infinity> But still.  That's what it means. :P
[17:59] <teward> :P
[17:59] <infinity> teward: Look at, eg: haskell-cracknum, which shows three deps.
[17:59] <infinity> teward: Makes a bit more sense in that context.
[18:00] <teward> indeed.
[18:00] <teward> more concerned about nginx - the perl upload went in, so i'm curious how migration from proposed is impacted by that (nginx 1.9.6-2ubuntu2 was uploaded for a rebuild against the updated perl)
[18:01] <infinity> teward: It'll all go in once the perl transition is done, not much to worry about.
[18:01] <teward> ok
[18:01] <infinity> teward: http://people.canonical.com/~ubuntu-archive/transitions/html/perl5.22.html
[18:01] <infinity> teward: There's a bit to go still.
[18:01] <teward> ahh i knew there was a transition tracker somewhere
[18:01]  * teward needs to bookmark things better
[18:02] <infinity> cjwatson: Speaking of the perl transition, you never did hand that off, like you said you would.  Does that mean you're still chipping away at it?
[18:04] <teward> i assume then before uploading any more nginx versions I should wait for the transition?
[18:04] <teward> for the transition to complete*
[18:04] <teward> (being 4 revisions behind is *bad*, i think...)
[18:04] <infinity> teward: You can do more uploads if you want, they'll just be stuck in proposed until the transition is done.
[18:04] <teward> (and Debian is being slow to update)
[18:04] <teward> ok
[18:06] <cjwatson> infinity: I just uploaded another batch of rebuilds, up to libyaml-syck-perl in level 3.  Give the tracker an hour or two to catch up and then it's all yours.
[18:06] <cjwatson> There are bits and pieces from earlier that I haven't touched.
[18:06] <smoser> ok... in a post bzr distributed development world, where 'bzr branch lp:ubuntu/update-notifier' is "ERROR: Not a branch:"
[18:06] <infinity> cjwatson: Sure, I'll wait for arm64 to go idle and see what the state is.
[18:06] <smoser> how should i blame source in a package ?
[18:06] <infinity> cjwatson: Has there been any porting required, or have rebuilds done the trick consistently?
[18:07] <smoser> i want to know why something is the way it is, what is the recommended way of doing that.
[18:07] <infinity> smoser: Read the changelog?
[18:07] <cjwatson> infinity: Rebuilds and merges have handled most things so far, but I haven't had time to look into anything much non-trivial.
[18:07] <cjwatson> infinity: It's supposed to have been pretty well-prepared in Debian, though.
[18:07] <smoser> infinity, i'd like somethign that isn't almost guaranteed to be wrong.
[18:08] <infinity> smoser: don't work on software?
[18:08] <cjwatson> infinity: perlqt isn't in Debian and looks like it needs some fixing.
[18:08] <smoser> http://www.mongodb-is-web-scale.com/
[18:10] <smoser> is there a plan for something equivalent ?
[18:11] <smoser>   * debian/99update-notifier:
[18:11] <smoser>     - Now additionally triggers the an asynchronous background update of the
[18:11] <smoser>       cached info via update-motd-updates-available hooking into
[18:11] <smoser>       APT::Update::Post-Invoke-Success.
[18:11] <smoser> :-(
[18:11] <cjwatson> smoser: Hopefully earlyish next year I'll have time to finish off my plan to import history from LP using dgit, yes.
[18:11] <smoser> bah. wrong paste location. :-(
[18:12] <smoser> cjwatson, i'm very interested. as my bad paste shows, the thing i was chasing is actually in a changelog, but... i'd rather not depend on it.
[18:12] <infinity> smoser: But, but.  Does /dev/null support sharding?
[18:13] <teward> infinity: i assume that any new upload will automatically get included in the transition tracker/tracking?
[18:13] <cjwatson> smoser: Yeah, lots of people want it :)
[18:13] <cjwatson> teward: yes
[18:13] <teward> cjwatson: OK, thanks
[18:13] <smoser> "As of this moment I officially resign from my job as software engineer and will take up work on the farm shovelling...."
[18:22] <nacc> that sounds like a power play in Agricola
[18:24] <sil2100> Hey guys! We wanted to re-build oxide-qt in the archive, sadly it seems the armhf build seems to be segfaulting in the middle
[18:24] <sil2100> https://launchpad.net/ubuntu/+source/oxide-qt/1.11.3-0ubuntu2/+build/8458995
[18:24] <sil2100> /usr/lib/gcc/arm-linux-gnueabihf/5/include/arm_neon.h:6831:10: internal compiler error: Segmentation fault
[18:24] <sil2100> On the armhf builders - we didn't have that before and this version already built in the past, we're just doing a no-change rebuild
[18:24] <sil2100> We retried once but got the same
[18:24] <sil2100> Any ideas?
[18:30] <smoser> hey. so https://bugs.launchpad.net/ubuntu/+source/update-notifier/+bug/1527710
[18:30] <cyphermox> sil2100: sounds like you need someone like doko, who knows of the voodoo in there.
[18:31] <cyphermox> sil2100: did you file a bug?
[18:31] <cyphermox> I fail, nevermind :)
[18:31] <smoser> i find apt config odd. is there a way that i can 'apt-get .... --option=Post-Invoke-Success' that disabled everything ?
[18:42] <cyphermox> cjwatson: still on the perl transition? I'd start to finish level 3 after libyaml-syck-perl.
[19:16] <cjwatson> cyphermox: I've stopped for the moment
[19:17] <cyphermox> cjwatson: well, I'm very slow anyway on account of http://www.xkcd.com/# being totally descriptive of my day.
[20:13] <barry> cyphermox: ping, that apt-xapian-index bug
[20:13] <cyphermox> ah?
[20:14] <barry> okay, so here's the problem.  astrometry-data-2mass-00's installed size is<PHONE_NUMBER>4, and
[20:14] <barry> >>> log2(14215209984)
[20:14] <barry> 33.72671635922483
[20:14] <barry>
[20:14] <cyphermox> weee
[20:14] <barry> axi has a size plugin that stores the installed and package sizes as documents
[20:14] <barry> so yeah, that won't work
[20:15] <barry> ultimately, i think it's a bug in xapian1.3-bindings but that's swig so <shudder>
[20:16] <cyphermox> so, time to think some more of ripping our software-center?
[20:16] <barry> cyphermox: we could do one of two things: catch the exception and treat it like -1 (i.e. ignore the size in the plug), or squash the size to sys.maxsize
[20:16] <cyphermox> hrm
[20:16] <barry> cyphermox: yep.  that *is* happening in 16.04 but robert_ancell is still working on that
[20:16] <cyphermox> yeah
[20:16] <cyphermox> well, you know more about a-x-i than I do, what do you feel is the best solution?
[20:17] <barry> i will report the bug upstream to xapian either way and if they come up with a patch, i'll import that into xapian1.3-bindings
[20:17] <cyphermox> I think I'd rather break the size obviously rather than squashing it and reporting something that looks possible.
[20:17] <barry> i'm not actually sure where the installed size is displayed, but the code clearly expects to ignore bogus values.  it currently ignores inst_size == -1
[20:17] <sil2100> doko: hey! Any idea why this segfault is happening by any chance? https://launchpad.net/ubuntu/+source/oxide-qt/1.11.3-0ubuntu2/+build/8458995
[20:17] <barry> so, it's either dunno or lie :)
[20:17] <barry> i'm inclined to make it == -1
[20:17] <cyphermox> yeah
[20:18] <barry> i.e. not lie, but dunno
[20:18] <cyphermox> yes
[20:18] <sil2100> doko: all other builds went fine, and the oxide source did not change since last version (a no-change rebuild)
[20:18] <barry> it probably won't affect too many packages.  i bet not many are as big as astrometry, but i haven't looked at all
[20:18] <barry> cyphermox: ok, so agreed, treat it as -1?
[20:19] <cyphermox> barry: I think that's arguably better than lying about the size.
[20:19] <barry> cyphermox: agreed.  i think i can whip up and test a fix for this quickly
[20:19] <barry> thx
[20:47] <sil2100> cjwatson: ok, I'm back... let me fill in a bug regarding the build segfault - I know this sounds silly, but could it be caused by the perl transition? As I see perl-modules marked for removal at the start of the build
[20:51] <sil2100> cjwatson: although the most probable case is gcc 5.3.1...
[20:53] <cjwatson> sil2100: sorry, I can't look now.  it seems unlikely; even if it is, you'll have to deal with it anyway ...
[20:53] <cjwatson> sil2100: a toolchain change is much more probable
[20:53] <sil2100> Yeah
[20:54] <sil2100> s/case/reason
[20:59] <sil2100> doko: hey! If you could take a look at LP: #1527741 in the nearest time, maybe you would know more about what's causing this failure
[21:14] <barry> cyphermox, Laney: LP: #1527745 - i have to run out for an errand right now but i'll work out a fix when i get back.  should be quick


[20:51] <m4n1sh> desrt: ping
[21:15] <desrt> m4n1sh: hi
[21:17] <m4n1sh> desrt: I was trying to debug a vala app and getting this error. AFAIK you are the gtk dev
[21:17] <m4n1sh> http://paste.ubuntu.com/1351733/
[21:17] <m4n1sh> gactionmuxer.c: No such file or directory.
[21:17] <desrt> m4n1sh: lars wrote that code :)
[21:17] <m4n1sh> is gtk in ubuntu not compiled with gactionmuxer.c?
[21:18] <desrt>   actions = g_action_group_list_actions (group->group);
[21:18] <desrt>   for (i = 0; actions[i]; i++)
[21:18] <desrt> i bet group->group is NULL
[21:18] <desrt> and list_actions() is hitting a critical
[21:19] <desrt> m4n1sh: is this when the app is shutting down?
[21:19] <m4n1sh> I am writing vala code and not even going through all that C code. So it has to to do with vala compiler
[21:19] <m4n1sh> when starting itself
[21:19] <desrt> hm
[21:19] <m4n1sh> gdb shows this message
[21:19] <desrt> m4n1sh: can you give me the .vala?
[21:19] <m4n1sh> well, it is a big app. activity-log-manager (the privacy thing in Ubuntu)
[21:20] <m4n1sh> desrt: I will just give you the branch url
[21:20] <desrt> i assume you don't hit the error while compiling
[21:20] <m4n1sh> no, I don't
[21:20] <m4n1sh> only when running
[21:20] <desrt> right
[21:20] <desrt> it's not a vala issue
[21:21] <desrt> pretty sure...
[21:22] <m4n1sh> desrt: lp:~manishsinha/activity-log-manager/run-12-10
[21:22] <m4n1sh> after make, run it with ./src/activity-log-manager
[21:22] <desrt> k
[21:22] <m4n1sh> then it segfaults
[21:24] <desrt> m4n1sh: why do you have Makefile.in in version control?
[21:25] <m4n1sh> that is what even I am wondering. autotools and related things is something which I still can't get my head around
[21:26] <m4n1sh> desrt: build system is something I have been kinda scared of. It is still broken, but I have temporarily commented out broken parts
[21:26] <m4n1sh> desrt: brb in 15 mins. lunch
[21:44] <m4n1sh> desrt: any progress? I am totally stuck up with this. Even after commenting out a lot of lines in the source code, nothing happens
[21:56] <desrt> m4n1sh: i'm afraid i don't see the issue
[21:57] <m4n1sh> desrt: this line is worrying me
[21:57] <m4n1sh> 645	/build/buildd/gtk+3.0-3.6.0/./gtk/gactionmuxer.c: No such file or directory.
[21:57] <m4n1sh> how come gactionmuxer.c isn't found?
[21:57] <desrt> m4n1sh: because you don't have the gtk sources installed
[21:58] <m4n1sh> desrt: which package is that?
[21:58] <desrt> it's the gtk+3.0 source package
[21:58] <desrt> so like...
[21:58] <desrt> (activity-log-manager:9266): GLib-GIO-CRITICAL **: g_application_list_actions: assertion `application->priv->is_registered' failed
[21:58] <desrt> don't ignore criticals
[21:58] <desrt> they provide you with valuable information
[21:59] <desrt> and really... you have _a lot_ of criticals coming before the segfault
[22:00] <desrt> you're using GtkApplication in an extremely weird way
[22:00] <m4n1sh> really? this was my first big Gtk App
[22:00] <desrt> take a look at how some other apps are using gtkapplication
[22:00] <m4n1sh> so I won't be surprised if it isn't done well
[22:01] <desrt> bloatpad is a good example
[22:01] <m4n1sh> yeah. will do
[22:01] <desrt> basically, you should not be calling gtk_init() and gtk_main() from main()
[22:01] <desrt> now should you be creating any windows
[22:01] <desrt> *nor
[22:01] <desrt> main() should only create a Gtk.Application subclass and call .run() on it
[22:01] <desrt> like, one line:
[22:02] <desrt> int main (string[] args) { return new MyApplication ().run (args); }
[22:02] <m4n1sh> yeah. Now I understand this thing
[22:02] <desrt> MyApplication() should have a virtual function override called 'activate'
[22:02] <desrt> it should be what creates the first window
[22:04]  * m4n1sh notes everything down
[22:04] <desrt> m4n1sh: baobab is a fairly well-written modern user of GtkApplication in vala
[22:04]  * seiflotfy is a fan of desrt
[22:04] <seiflotfy> :D
[22:04]  * desrt blushes
[22:05] <desrt> m4n1sh: http://git.gnome.org/browse/baobab/tree/src/main.vala
[22:05] <desrt> m4n1sh: and http://git.gnome.org/browse/baobab/tree/src/baobab-application.vala
[22:05] <m4n1sh> I think I should get back to the board and fix the whole architecture of alm
[22:05] <m4n1sh> seiflotfy: right?
[22:05] <m4n1sh> mpt has a mockup of it
[22:05] <seiflotfy> yes sir
[22:07] <desrt> here's the 3rd most important file: http://git.gnome.org/browse/baobab/tree/src/baobab-window.vala
[22:07] <desrt> you would do well to copy this pattern
[22:07] <desrt> namespace
[22:07] <desrt> Whatever {
[22:07] <desrt>   class Application : Gtk.Application { ... }
[22:07] <desrt>   class Window : Gtk.ApplicationWindow { ... }
[22:07] <desrt> }
[22:08] <desrt> int main (string[] args) { return new Whatever.Application ().run (args); }
[22:08] <desrt> where 'Whatever' is the namespace you like for your app
[22:09] <m4n1sh> desrt: I think you gave a perfect reference to using vala
[22:09] <m4n1sh> I will keep it in mind
[22:09] <m4n1sh> desrt: thanks a lot :)
[22:09] <desrt> no problem
[22:09] <desrt> copying is always the best way
[22:09] <m4n1sh> :)
[22:09] <desrt> you just need to make sure you're copying from the right places :)
[22:10] <m4n1sh> yes
[23:16] <desrt> warp10: hey
[23:16] <warp10> desrt: hey, welcome aboard ;)
[23:18] <desrt> warp10: i have something you might find useful
[23:18] <desrt> warp10: http://imgur.com/UkTcn
[23:19] <warp10> desrt: uh... quite scary
[23:19] <desrt> no gimp... i swear it.
[23:21] <desrt> anyway... i was noticing that the team lacks an image


[00:26] <superm1> hey kees if you get a sec, i'm looking for sponsorship on something prior to FF.  (As an added benefit, its !lirc :)) bug 261665
[00:26] <Zinn> Bug 261665 in hal (Ubuntu) "Package new libsmbios upstream version 2.0.3" [Undecided, New] http://www.launchpad.net/bugs/261665
[00:28] <kees> superm1: hehe
[00:29] <kees> superm1: reading it, one sec
[00:29] <superm1> just the two parts out of main, i'll upload pommed after the other two would clear
[00:30] <kees> superm1: is there an API bump?  (why the rebuilds?)
[00:30] <superm1> yeah new binary packages
[00:30] <superm1> libsmbios2 instead of libsmbios1
[00:31] <kees> ah, so it has to get through NEW before we can rebuild hal/pommed
[00:31] <superm1> well hal i bumped the build depends
[00:32] <superm1> but pommed doesn't explicitly depend on it from what i see
[00:32] <kees> vim seems to think multi-line Build-Deps aren't valid.  hmpf
[00:34] <superm1> well that's how they were before at least, and i'm hoping to avoid too much delta to debian, they're just slow to adopt newer packages
[00:37] <kees> superm1: yup, not an issue -- more of a head-scratcher on vim.
[00:37] <kees> superm1: so, you've dropped libsmbiosxml*
[00:37] <kees> was anything using it?
[00:37] <superm1> well upstream dropped it actually
[00:37] <kees> heh, okay
[00:37] <superm1> no more libraries are produced
[00:38] <kees> I love these empty maintainer scripts in the old package.  :)
[00:38] <kees> are all the cstring changes in the current upstream now?
[00:39] <superm1> if debian continues to be unresponsive to newer versions, i'll just adopt this as maintaining in ubuntu myself probably
[00:39]  * kees nods
[00:39] <superm1> and clean a lot of that up
[00:40] <kees> the postinst can be removed -- debhelper already calls ldconfig
[00:40] <kees> but I get your point about lowering the debian delta.
[00:40] <superm1> i probably should have just attached a debdiff to point out the amount of delta i suppose
[00:40] <kees> interdiff -p1 is my friend.  :)
[00:41] <kees> yeah, okay, this looks okay to me.  I assume you've already tested this with hal, etc?
[00:41] <superm1> yeah i tested it on one laptop here
[00:42] <superm1> just basic bios reading functions and such
[00:42]  * kees nods
[00:43] <kees> cool, I'm building it now and will upload.  :)  ping me (or pitti maybe?) once the archive admins have let is past NEW, and we can get hal and pommed rebuilt.
[00:43] <superm1> okay will do.  thanks :)
[00:43] <kees> thanks for getting it updated!  :)
[00:44] <kees> you might want to report the gcc warnings to upstream, too.  nice to have them fixed.
[01:31] <kees> superm1|away: it's FTBFS :(
[01:31] <kees> bin-supported/dellMediaDirectCtl.cpp:206: error: impossible constraint in 'asm'
[02:10] <MythbuntuGuest27> how do i create a symlink to enable video view in mythweb??
[02:11] <superm1> kees, i did a build locally with no issues on i386?
[02:11] <superm1> it doesn't build on anything but i386/amd64/lpia
[02:13] <superm1> kees, https://edge.launchpad.net/ubuntu/+source/libsmbios/2.0.3-0ubuntu1/+build/701925
[02:13] <superm1> kees, and https://edge.launchpad.net/ubuntu/+source/libsmbios/2.0.3-0ubuntu1/+build/701923
[02:14] <superm1> kees, i'll let upstream know about these other arch's though
[02:15] <superm1> most of the code isn't applicable to non x86 stuff fortunately
[02:17] <MythbuntuGuest27> anyone got the answer for me, anyone, anyone??? :)
[02:20] <kees> superm1: lpia failed, though, it seems.
[02:20] <superm1> kees, no it didn't? http://launchpadlibrarian.net/17105164/buildlog_ubuntu-intrepid-lpia.libsmbios_2.0.3-0ubuntu1_FULLYBUILT.txt.gz
[02:21] <superm1> kees, regarding notifying upstream about the gcc warnings, it's a moot point. there is an effort going on to refactor it in C rather than C++
[02:22] <kees> superm1: erk, I swear I saw an email go by for lpia.  ah, nevermind then.  :)
[02:22] <superm1> i was expecting the other arch's to fail since i thought some assembly got introduced recently
[02:53] <abarber> i'm having trouble with an ir blaster
[02:53] <abarber> anyone use one?
[03:16] <acrousey> hi, i'm wondering what kind of hardware i should get to run Mythbunty. I have an older computer. It has a 750GB hard drive, but the rest is very unimpressive. It has a pentium 3 1GHz processor, no video card besides the integrated one, and 512MB RAM. Is there a way to capture TV with it?
[03:23] <abarber> need a capture card
[03:24] <acrousey> Would i need a video card to watch it on a TV after I capture it?
[03:29] <abarber> you need it to capture it
[03:30] <abarber> you can send to a TV through video card or mobo
[04:42] <pteague> i took my video card out & i'm having absolutely no problems...  only now i don't have a tv out :(
[04:42] <MythbuntuGuest32> Does anyone know how to change the card type for the bttv module?  The autodetect is wrong.
[04:43] <pteague> still not getting that to work? :(
[04:45] <abarber> pteague, just use vga or dvi on mobo
[04:45] <pteague> there's vga on mobo, but that won't work with my prehistoric tv
[04:46] <abarber> vga to s-vid?
[04:46] <pteague> which requires a coax tv out...
[04:46] <abarber> you were using coax?
[04:46] <abarber> hahahaha
[04:46] <abarber> oops
[04:46] <abarber> upgrade
[04:46] <abarber> asap
[04:46] <pteague> yeah, to replace my tv with an appropriate sized flat screen will cost me at least $2k usd
[04:49] <abarber> vizio ftw
[04:50] <pteague> vizio?
[04:51] <abarber> oh wow
[04:51] <abarber> where are you from?
[04:52] <pteague> us
[04:56] <abarber> vizio is sold by costco
[04:56] <abarber> very cheap, very awesome TVs
[04:59] <pteague> ok, maybe it wasn't that much...
[04:59] <pteague> if i've calculated this right... if it's a 16:9 i need a 33" & if it's a 16:10 i need a 30"
[05:00] <abarber> buy vizio
[05:00] <pteague> & so i was wrong in my remember of the price
[05:01] <pteague> s/remember/remembering
[05:15] <Alcomposer> pteague: why not get a cheep viewsonic?
[05:16] <Alcomposer> They have a 28
[05:16] <Alcomposer> 28" for about 600 USD
[05:19] <pteague> it must be the same height as my current tv or it's not worth wasting the money on it
[05:21] <pteague> sorry, already did the wide screen monitor & got overly frustrated at the smaller heightwise resolution
[05:23] <abarber> yeah
[05:24] <abarber> i hate widescreen monitors
[05:27] <Alcomposer> I got a 28" Viewsonic- as a replacement for my old TV- it was the same height size....  It is actually quite large in the room- and as an added bonus its 1080 HD- and it has just about every sort of video input at the back- HDMI, (DVI), VGA, svideo, component... just fantastic for $600,... and the picture is clear.   I suppose that there are some really nice LCD TV's comming out- but not anywhere near that price point
[11:14] <frink_> hey folks
[14:22] <jphillip> !hi | frink_
[14:22] <Zinn> frink_: Thanks for being polite.  But we are so dang awesome at solving problems that we wish you would just ask your question.  Thanks.
[14:25] <frink_> Zinn: no really, I wa sjust saying hello. I have no question.
[14:26] <frink_> I am so awesome that I do not need to ask questions :)
[14:26]  * frink_ can use google and read code
[14:26] <hads> Good comeback
[14:30] <frink_> ;-)
[14:30] <Lemont> wow, theres a lot of people in here
[14:30] <jphillip> lots of sleeping people
[14:30] <Lemont> aw
[14:33] <Lemont> How does one go about getting mythbuntu to run on a TV instead of a monitor? I'm basically having a "multiple monitor" problem. I have my hdtv plugged up to my video card's dvi port, but myth is only sending my tv the top right of the frame. Additionally, the signal is only 480p (according to my TV). I just have no resolution adjustment for my dvi port on my card, and I think that that is the problem.
[14:33] <Lemont> *not top right of the fram, top left
[14:37] <jphillip> Lemont how is it hooked up to the tv?
[14:38] <Lemont> out dvi port on nvidia mx440SE, over a dvi to hdmi cable and into my tv's hdmi port
[14:40] <Lemont> It just seems like my dvi port is getting a copy of the signal going to my vga out, instead of having its own properties - like resolution
[14:40] <Lemont> *as it would in windows
[14:43] <jphillip> it is only plugged into the TV, or into multiple display devices?
[14:44] <Lemont> it is plugged into a tv on the dvi port, and an lcd monitor running 1024x768 on the vga port
[14:45] <Lemont> in ubuntu, should two monitors each have their own controls/settings, assuming that they are installed correctly?
[14:47] <jphillip> yes but it might not be able to detect the settings from both easily
[14:47] <jphillip> Lemont try powering down, unplugging the vga and powering back up, see what it does
[14:48] <jphillip> you can also get some TV's/Cables that are a pain in the butt and don't send edid data properly so it will default to an incorrect resolution
[14:48] <jphillip> one of mine does this so I had to go and hardcode everything for it into xorg.conf
[14:49] <Lemont> jphillip: that results in no change at all. The resolution is still 1024x768, and the tv is only getting the top left of the frame
[14:50] <Lemont> if it helps... it all runs correctly when using xp pro
[14:50] <Lemont> all same hardware I mean
[14:53] <jphillip> have you modified your xorg.conf at all?
[14:53] <Lemont> I have not.
[14:55] <jphillip> Lemont are you running the propper nvidia/ati graphics drivers?
[14:56] <Lemont> Please elaborate on "proper"
[14:57] <Lemont> I'm running a driver that ubuntu used automatically; not any proprietary driver
[14:59] <jphillip> Lemont try the proprietary ones, open the driver manager and let it install whatever is detected
[15:00] <Lemont> ok, I will try that over lunch when I can run to my house. I will post results in here asap.
[15:00] <Lemont> Thanks for the help jphillip
[15:00] <jphillip> no problem
[15:00] <Lemont> now how does one get to the driver manager?
[15:01] <Lemont> applications >> system >> settings ?
[15:20] <jphillip> I don't recall off the top of my head, its somewhere in the menu system
[17:11] <slundell> MY HD sounds like it reads like mad, but olny when it is "idle". I have tried two different HDs, and both 8.04 and 8.04.1
[17:14] <Lemont> scsi?
[17:36] <slundell> SATA
[17:48] <thatdood> "idle"... so the backend isn't running on that system?
[17:49] <thatdood> i had something similar the other day, wasn't doing anyting on the system and my hard drive was going nuts.   did a tail -f /var/log/mythtv/mythbackend.log   and the log was filling up with errors like crazy
[17:51] <thatdood> pages and pages of "MythSocket(e67290:-1): writeStringList: Error, called with unconnected socket."
[18:33] <slundell> thatdood: That seemed to be it... Lots of errors were logged because mthconverg did not exist
[19:00] <Lemont> I have a video card that is malfunctioning, so I want to try using a proprietary driver, instead of the generic on that ubuntu is using currently. How do I change that driver? I do not see how in Applications > System >  Hardware Drivers
[20:49] <squish102> i built a new htpc and would like to install mythtv. I don't have a cdrom in it at the moment. is there any way i can do the install from a usb thumb drive?
[20:50] <laga> yes
[20:50] <laga> you can load the live disk from an usb thumb drive, check the ubuntu wiki for instructions
[20:52] <squish102> thanks
[20:52] <squish102> is that ubuntu or mythbuntu? laga
[20:52] <laga> is what ubuntu or mythbuntu?
[20:54] <squish102> istall ubuntu or mythbuntu?
[20:54] <laga> mythbuntu
[20:55] <squish102> ok so look on ubuntu's wiki to install mythbuntu from thumb drive
[20:55] <squish102> i got it
[20:55] <squish102> im slow
[20:56] <laga> ;)#
[21:31] <khaije1> hey ladies and gents
[21:32] <khaije1> i'm setting up myth now for the first time
[22:40] <khaije1> using hpg-150 i'm not getting any tv, but i also don't have a schdule guide set up yet, is the guide necessary to get any tv? i'm a little lost
[22:58] <bobbob1016> I have some HD movies I'm trying to play, and they are choppy.  I have a 3.2ghz HT P4, and an ATI x300 series card.  They play fine if I launch them from thunar in mplayer, but not in the Myth Frontend, any ideas?
[22:58] <bobbob1016> They are playing off of a local hard drive too.
[23:42] <Aquahallic> evenin' folks
[23:43] <Aquahallic> I used to run a version of mythtv way back that had a mame plugin....
[23:43] <Aquahallic> is there a mame plugin for mythbuntu?


[20:50] <capum321> hello what diff tool for lubuntu/lxde is available and current?
[21:51] <capum321> hello what diff tool for lubuntu/lxde is available and current?
[21:52] <wxl> capum321: your favorite diff tool. i use diff.
[21:53] <capum321> i saw some comments regarding meld uses gnome library packages so it would bloat it
[21:53] <wxl> doesn't mean it won't work
[21:54] <capum321> yes, i asked wrong then
[21:54] <capum321> i want to keep lubuntu lean and fast...
[21:55] <wxl> diff comes standard
[21:55] <capum321> oh it already comes?
[21:55] <wxl> it's a standard gnu tool
[21:55] <wxl> it *IS* command line
[21:56] <wxl> !info diffutils | capum321
[21:59] <wxl> if you need graphics you might look into:
[21:59] <wxl> !info diffuse | capum321
[21:59] <wxl> !info fldiff | capum321
[21:59] <capum321> ah heck monodevelop might have installed gnome stuff anyway...
[22:00] <wxl> oh monodevelop installs like the whole universe
[22:00] <capum321> at this point i should not care!
[22:01] <capum321> wxl do you know make it external svn merging tool ?
[22:08] <capum321> oh wxl i was referring to gnome bloat
[23:01] <capum321> oh lawd