[00:28] <hallyn> slangasek: the point of the separate ns is so that /run/cgmanager/fs/* mounts get cleaned up when cgmanager exits
[00:28] <slangasek> ah, ok
[00:29] <hallyn> yeah i had almost convinced myself to just not do it, but it'll lead in redisual mounts and complicate restart
[00:31] <ahoneybun> Riddell, I found a wordpress theme making who has a company who makes a few free themes from non profit companies
[00:32] <hallyn> sigh, i'm really quite bad at remembering to quilt add files to a patch
[01:31] <kees> xnox: say... can you fix mplayer in trusty? it's really really busted.
[01:31] <xnox> kees: bug #?
[01:31] <kees> https://bugs.launchpad.net/ubuntu/+source/mplayer/+bug/1352447
[01:31] <kees> and now it likes to segfault on perfectly valid streams. had to downgrade _another_ machine today :(
[01:32] <kees> xnox: also, mencoder is needed.
[01:32] <xnox> kees: =((((
[01:32] <xnox> kees: i actually hate all of that audio/video stuff, but did do "binNMUs" and patches to get them "fixed" a lot....
[01:33] <kees> xnox: easy fix! revert to precise's mplayer ;)
[01:33] <kees> actually, I have no idea. I should see if the current debian mplayer works correctly.
[01:34] <kees> regardless, mencoder is seriously needed. it's the only thing that does deinterlacing correctly.
[01:35] <kees> I suppose I should go complain to Reinhard :)
[01:40] <slangasek> kees: --> siretart ? :)
[04:16] <aeoril> darkxst I have found out that some init code in vte.c (vte_terminal_init()) which initializes the terminal gtk3 widget uses default values of 80x24 for columns and rows the call to vte_terminal_set_size().  A widget method is set to vte_terminal_set_size() also, so I would think that as the gtk3 widget responds to resizing, it probably "automatically" calls that method I guess?  Somehow
[04:16] <aeoril> maybe the timing is such between the initial setup of gnome-terminal, the resizing done via the --geometry command line argument and the loading of the vim child process within the gnome terminal sometimes the resize causes all the lines to be shown, sometimes only 24 (the default value hard coded into vte.c).  I could use a little help/direction on where to look next to figure out how
[04:16] <aeoril> all this stuff works together and where in the code I should be looking - I am thinking of downloading the gnome-terminal code to see how it uses libvte (vte3, the code I am looking at now)
[05:05] <darkxst> aeoril, but are you getting the default size? I though it was just off by a couple of lines or something?
[05:06] <aeoril> darkxst no, I am getting the default size - sorry if that was not clear - 24 lines are shown, the rest of vim down to the bottom of the enlarged gnome-terminal is blank lines, or invisible
[05:07] <aeoril> rows == 24, not sure about columns - I guess I need to test that
[05:08] <darkxst> if its a race perhaps running something like "sleep 5;vim" might identify it
[05:09] <darkxst> or you could try and hook into the resize event with gdb and see what is going on
[05:13] <aeoril> darkxst yahhhoooo!  "sleep 1;vi ..." fixes the problem
[05:14] <darkxst> aeoril, turn on debug messages that might help
[05:14] <aeoril> darkxst yes, I have been planning on that
[05:17] <aeoril> darkxst there do not seem to be command line switches to turn on debugging in gnome-terminal or vim - do I need to compile that in?
[05:17] <darkxst> aeoril, probably a env var to turn it on
[05:22] <aeoril> darkxst for gnome-terminal, I have to do both - compile debugging in and set an environment variable:  https://wiki.gnome.org/Apps/Terminal/Debugging  for vim, -g option on compile
[05:23] <aeoril> darkxst apparently, gnome-terminal has a client-server achitecture.  To debug, you have to start up the server, then hook to it with a client within 10 seconds
[05:23] <aeoril> using gdb
[05:23] <aeoril> probably make the timing issue impossible to reliably reproduce
[05:24] <darkxst> aeoril, vte has a VTE_DEBUG that should turn on debug message
[05:24] <aeoril> oh, didn't think about vte ... thanks
[05:25] <aeoril> Actually, I thought about it, but found no manpage and forgot after that
[05:25] <aeoril> thanks anyway
[05:25] <darkxst> grep -R getenv
[05:26] <aeoril> darkxst I was wondering how you found that ...
[05:27] <darkxst> aeoril, the code is often the best documentation ;)
[05:28] <aeoril> darkxst yes, I am finding that out ... :)
[05:34] <aeoril> darkxst I still need to define VTE_DEBUG when I compile, though
[05:35] <aeoril> (#ifdef)
[05:37] <darkxst> aeoril, ok
[05:38] <darkxst> I have never really worked with vte or gnome-terminal
[05:43] <aeoril> darkxst yes, but we are closer now than two days ago - thanks for the help again.  I'll tell you a secret - I have never worked with them before either ha ha!
[05:43] <darkxst> I pretty much assumed that
[05:43] <aeoril> darkxst that was a joke :)
[05:44] <darkxst> yes
[05:46] <aeoril> well, afk.  Tomorrow is another day
[05:46] <darkxst> maybe this was fixed as part of the re-wrap implementation? don't think that was in trusty?
[05:47] <aeoril> re-wrap?
[05:48] <darkxst> aeoril, http://blogs.gnome.org/mclasen/2013/12/09/a-terminal-surprise/
[05:49] <aeoril> Cool, thanks.  Will look into it tomorrow :)
[05:50] <aeoril> darkxst I think I saw some stuff about wrapping in the latest code on vte maybe?
[05:50] <darkxst> aeoril, probably
[05:50] <darkxst> likely in 14.10 also
[05:51] <aeoril> darkxst 14.10 exhibits this problem too, though much less often (about 5 % of the time as opposed to 60-70%)
[05:52] <darkxst> aeoril, races will always be tricky
[05:52] <aeoril> darkxst but races must be wone!
[05:52] <aeoril> won*
[05:53] <aeoril> darkxst I wish I could get an audience with chpe!
[05:54] <darkxst> aeoril, many of the GNOME devs are on US Business Hoursy-ish
[05:54] <darkxst> some are also EU
[05:54] <darkxst> very few around on weekends
[05:54] <aeoril> darkxst good to know - I will post Tuesday earlier my same queries (Monday is a holiday)
[05:56] <aeoril> I should know the code better by then as well, and have looked at the gnome-terminal code some
[05:57] <aeoril> darkxst I am not wondering if it has something to do with the client-server architecture of gnome-terminal - server/client hookup timing or something like that
[05:59] <aeoril> s/hookup/interactions/
[05:59] <darkxst> no idea
[05:59] <aeoril> darkxst I may be able to figure some of that out from code
[05:59] <darkxst> tbh  I don't even know what the client-server split involves (ie which bits do what)
[06:00] <aeoril> darkxst yes, I was just thinking that to myself, actually - I need to figure that out really
[06:00] <darkxst> aeoril, can you build trusty gnome-terminal with current vte?
[06:01] <aeoril> difficult I think - different so name/number/whatever
[06:01] <aeoril> not really sure
[06:01] <darkxst> aeoril, thats not actually a problem in itself at build time, however often it means there are incompatible api calls
[06:02] <aeoril> darkxst wouldn't I have to screw with the build setup though if the library has a different name?
[06:02] <darkxst> aeoril, no its automatic
[06:02] <darkxst> the build depend would be libvte3-dev
[06:02] <aeoril> ahhh ... cool - I can give that a try then tomorrow
[06:03] <aeoril> darkxst so how do I get the vivid libvte3-dev on a trusty system to replace the old one?
[06:03] <aeoril> can I do that with apt-get?
[06:04] <darkxst> no
[06:04] <darkxst> you will need to rebuild it on trusty
[06:04] <darkxst> probably in a ppa, so its easy to backout the changes with ppa-purge
[06:04] <aeoril> ok, so build from a ppa source package?
[06:05] <darkxst> aeoril, grab the vivid vte, edit changelog and make it target trusty
[06:05] <darkxst> then build under trusty (or upload to a ppa to build)
[06:05] <aeoril> ok, I'll try that then
[06:07] <aeoril> darkxst thanks again!  I should have enough to go on for now, but like I said 20 minutes ago, need to head on ... :P
[06:07] <darkxst> bye
[06:08] <aeoril> darkxst thanks! :)  You have again been incredibly helpful!
[11:42] <darkxst> pitti, why on earth would I get asked for permission to unmount a partition when extracting a file via file-roller?
[11:58] <hjd> Anyone know or have a suggestion why https://tracker.debian.org/pkg/python-click doesn't seem to have been synced to Ubuntu? I can't find it in the sync blacklist.
[11:59] <ogra_> hjd, most likely because click is uploaded to ubuntu first ?
[12:00] <Laney> it's a different 'click'
[12:00] <Laney> but it was removed due to overlapping binary packages with the other one it seems: https://launchpad.net/ubuntu/+source/python-click/+publishinghistory
[12:00] <ogra_> oh
[12:00] <ogra_> heh
[12:03] <darkxst> pitti, bug 1421938
[12:03] <darkxst> that should of course be partition though!
[12:43] <hjd> ogra_: Laney ah ok. I thought about (ubuntu-)click but didn't know that had packages with conflicting names.
[15:26] <melodie> hello
[15:27] <melodie> could someone point me to the page where I can find the filesystem.manifest of Ubuntu 14.04.2 please?
[19:25] <cjwatson> melodie: Nowhere, because there's no such thing as Ubuntu 14.04.2 yet.  The current builds are at http://cdimage.ubuntu.com/trusty/daily-live/current/ and the .manifest files are alongside them.
[19:37] <melodie> hi cjwatson thanks, that's what I meant
[19:38] <melodie> cjwatson what about the other flavors? what would be the link like for them?
[19:43] <sladen> melodie: http://cdimage.ubuntu.com/kubuntu/trusty/daily-live/current/  etc
[19:43] <sladen> melodie: (follow up to the top level directory, and then back down again)
[19:43] <melodie> sladen thank you
[19:43] <melodie> yes, I get it
[22:16] <Bl4ckD34tH> why i am banned on ubuntu?
[23:27] <xnox> pitti: the set of openened lazr/launchpad bugs are fixed. Your move. ;-)
[23:53] <melodie> good night