[06:32] <ailo-w> good morning Europe. Good night America
[06:37] <ailo-w> And maybe HK hasn't come home from school yet?
[08:26] <ailo-w> Would anyone like to volunteer for updating this page? https://wiki.ubuntu.com/Testing/Cases/UbuntuStudio
[08:33] <smartboyhw> Let me finish my publishing one first:)
[08:38] <ailo-w> It was last updated 2008. I'm sure there is something there that is worth
[08:40] <smartboyhw> Well but then now balloons is planning to rewrite testcases in a standard form + distro special items
[08:40] <smartboyhw> So ailo-w: I'm not sure we should update it
[08:56] <ailo-w> smartboyhw: Who is balloons?
[08:56] <ailo-w> smartboyhw: We need a special testcase for Ubuntu Studio
[09:00] <smartboyhw> ailo-w: Oh you don't know. balloons is Nicholas Skaggs, the Canoncial QA guy responsible for community testing:)
[09:00] <smartboyhw> Anyway I will contact him for special testcase writing
[09:28] <ailo-w> smartboyhw: He's of course not responsible for Ubuntu Studio test cases
[09:28] <smartboyhw> I know he's the coordinator ailo-w
[09:28] <smartboyhw> For ALL flavors
[09:28] <ailo-w> smartboyhw: What we need to consider is what we can use from generic test cases, such as those for Ubuntu and Xubuntu, whether we need to use those at all, and what we should add of what is specific to Ubuntu Studio
[09:29] <ailo-w> smartboyhw: He's not responsible for what is specific for Ubuntu Studio
[09:29] <ailo-w> We are
[09:29] <smartboyhw> I know then who gonna write it?
[09:29] <ailo-w> smartboyhw: Anyone here
[09:30] <smartboyhw> Grrrrr
[09:30] <ailo-w> astraljava1: You veru busy? I know you were wanting to handle Ubuntu Studio testing QA
[09:30] <ailo-w> very*
[09:31] <smartboyhw> ailo-w: He's busy for three weeks... I can't seem to find him either
[09:31] <ailo-w> smartboyhw: I'm working on Ubuntu Studio developer docs, and will write about testing myself, something that I have not dealt with yet, unless someone else volunteers to do that part
[09:32] <smartboyhw> OK then you write the testcase ailo-w:)
[09:33] <ailo-w> smartboyhw: I'm doing all of this https://wiki.ubuntu.com/UbuntuStudio/DeveloperDocumentation. Just looking for some help on specific items
[09:33]  * smartboyhw is looking at it
[09:34] <smartboyhw> That is big work:)
[09:35] <smartboyhw> ailo-w: So er what can I help then?
[09:36] <ailo-w> smartboyhw: I was just suggesting test cases, since you were mostly interested about that
[09:36] <smartboyhw> Oh alright:)
[09:37] <ailo-w> Time for lunch. bbl
[09:37] <smartboyhw> bbl
[09:37] <smartboyhw> Oops that's quick
[12:22] <smartboyhw> OK so ailo-w is back at work:)
[12:31] <ailo-w> smartboyhw: Seems like I'm going in 5 min
[12:31] <smartboyhw> That's quick ailo-w:)
[12:31] <ailo-w> I have no choice. They are closing this place down
[12:31] <smartboyhw> I miss scott-work
[12:31] <ailo-w> For today
[12:31] <smartboyhw> ailo-w: What do you mean by closing this place down?
[12:32] <ailo-w> Everyone gets to go early
[12:32] <smartboyhw> Ooh congrats:)
[12:33] <smartboyhw> Wow faster than 5 min
[13:27] <smartboyhw> yeah ailo is back
[21:08] <Laney> hey
[21:09] <Laney> I was trying to fix your seeds to reflect the ubuntu-default-settings → ubuntu-settings rename, but I can't push to the branch
[21:09] <Laney> does someone here want to take care of that? :-)
[21:14] <holstein> len-dt: ailo ping ^
[21:15] <holstein> Laney: lemms see if i can find someone who can do that
[21:15] <Laney> try micahg ;)
[21:15] <holstein> i think len-dt can too
[21:15] <holstein> scottL can, but he's not here right now
[21:16] <ailo> I have yet not done any of that, so I don't even know if I as -dev am able
[21:16] <ailo> len-dt would know
[21:16] <ailo> Or Scott
[21:16] <ailo> And micahg, of course
[21:16] <Laney> you can update the seed branch if you are in -dev
[21:17] <ailo> Laney: If you can give me a step by step, I can do it right away (I presume it's fairly simple)
[21:17] <ailo> I have so far not dealt with bzr much at all
[21:17] <Laney> in desktop in ubuntustudio.quantal, change ubuntu-default-settings to ubuntu-settings
[21:18] <Laney> commit with an appropriate message ("desktop: renamed ubuntu-default-settings to ubuntu-settings, following rename in the archive")
[21:18] <Laney> and push
[21:18] <Laney> but don't worry if you aren't confident, feel free to leave it for someone else
[21:19] <ailo> I'm confident, just not done it before. I had a look at seeds. Just a textfile
[21:20] <Laney> make sure that `bzr whoami' is right
[21:20] <Laney> and that you are logged in (bzr lp-login yourusername)
[21:21] <ailo> Ok. I'll have a look
[21:31] <ailo> Well, I'm on it. Just need to get names and login right :P
[21:47] <len-dt> ailo, have you got it figgured out?
[21:48] <ailo> len-dt: Yep
[21:49] <ailo> len-dt: I had to do a bzr bind to get the adress right
[21:49] <ailo> Just commited
[21:49] <ailo> Used to git, so there's nothing after commit, right?
[21:49] <len-dt> Ok, I haven't had much time. Thanks
[21:50] <len-dt> I think micahg does the rest, he gets mail every time theres a seeds commit
[21:50] <ailo> Well, now I know a few things to add to the dev docs about seeds :)
[21:51] <len-dt> Seeds is different from all the other packages.
[21:51] <Laney> I'll upload it
[21:51] <Laney> thanks
[21:51] <ailo> Laney: Thanks for the help
[21:52] <len-dt> It's been my sons birthday today.. lots going on... and my first week back to work.
[21:53] <ailo> len-dt: No worries. I would think things go pretty smoothly. Only thing I come to think of is that no one is giving much feesback on recent changes, which I think is important, so we get things done as good as possible
[21:53] <ailo> len-dt: You've done some work on the menu, and seems like no one has really had the chance to look at that yetr
[21:54] <len-dt> I was waiting for the ISO to have all the metas in it and then for them to actually build...
[21:55] <ailo> Aha, not everything is there yet..
[21:55] <len-dt> We should have a new ISO tomorrow.
[22:19]  * micahg wonders what he does
[22:20] <micahg> ah
[22:20] <Laney> upload -meta, presumably
[22:20] <len-dt> micahg, I think it has been done
[22:20]  * micahg asked len-dt to update the seeds for that
[22:21] <len-dt> Ya, len had family to deal with :-)
[22:21] <micahg> len-dt: ok :)
[22:21]  * micahg can upload the meta as much as laney could
[22:21] <Laney> i did it
[22:21] <micahg> Laney: I need to talk to scottl about fixing the branches so core-dev can commit
[22:22]  * micahg didn't see the -meta on -changes yet
[22:23] <Laney> LP has it
[22:31] <ailo> len-dt: Is there a way to have the "*-extra" item in the menu be at the top of the menu?
[22:41] <len-dt> ailo, yes.
[22:42] <len-dt> I would put it just below any subdirectories if I was going to move it.
[22:46] <ailo> len-dt: Why not at the top of the menu?
[22:46] <ailo> It's a function for adding more stuff to the menu. But, it'
[22:46] <ailo> it's neither an application, or a menu
[22:47] <len-dt> ailo, in the Audio production men (for example) the sub menus have their own extra...
[22:47] <ailo> So, it should be at the top of the menu, preferably with a line under it, separating it from the other items in the menu
[22:47] <len-dt> 6 of one half dozen of the other... ;-)
[22:48] <len-dt> ailo, it was partly for that reason I didn't place it.
[22:49] <ailo> len-dt: I was thinking about the submenus a bit. It striked me that there were a lot of extras. Something one is not used to seeing in a menu. Intuitively, I feel it's enough having the extras for each workflow, but I guess it doesn't hurt to keep it as is
[22:50] <ailo> I mean, the user will have the possibility to do his/her own searches.
[22:50] <len-dt> The reason I broke it up is that the number of apps that can be added is limited by the length of the command line. So I thought that would give more room for adding things
[22:51] <len-dt> in hind sight... I have not run out of room on any of them.
[22:51] <len-dt> maybe it doesn't matter
[22:52] <ailo> Well, that's my initial perception of it. I can safely say, I had a fresh first encounter with it
[22:52] <len-dt> I'm not even sure if I chose the right apps
[22:53] <ailo> I never looked at that actually. But, I did feel this could be helpful
[22:53] <ailo> However, even one link could already do a lot
[22:54] <ailo> One for each workflow felt like more than enough
[22:54] <len-dt> That was why I did it a month ago so we could have more input. But it took some time to get it in. I think 13.04 might have something better thought out if some people try it.
[22:56] <ailo> I think it's the right way to try things. Go the full way, so to speak.


  Reviews. :3
[02:52] <Unit193> bluesabre: I'm sorry, doing it now.  Feel free to poke if I seem like I'm ignoring you.
[02:53] <Unit193> Hah, usr/share/icons/elementary-xfce/devices/symbolic/computer-laptop-symbolic.svg and usr/share/icons/elementary-xfce/mimes/symbolic/application-x-firmware-symbolic.svg are executable (I don't care, but maybe something to fix upstream. :P)
[11:20] <bluesabre> Yes, definitely. :)
[11:21] <bluesabre> I've drafted our beta release notes: https://wiki.xubuntu.org/releases/22.04/release-notes
[11:35] -SwissBot:#xubuntu-devel- ::platform:: supported-cloud: add linux-gke @ http://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/commit/?id=025f48f718c359e8447f6cdfd36ace383884273d (by Dimitri John Ledkov)
[11:35] -SwissBot:#xubuntu-devel- ::platform:: supported-kernel-common seed intel-iotg kernel @ http://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/commit/?id=f9aabebcf41f238f7615c9c160b2645ad20bddb0 (by Dimitri John Ledkov)
[11:40] -SwissBot:#xubuntu-devel- ::platform:: Seed LRS for every LRM @ http://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/commit/?id=3f3a05281bc75864ed9de82bd27162f5f051dec4 (by Dimitri John Ledkov)
[11:45] -SwissBot:#xubuntu-devel- ::platform:: Seed oem-5.17, instead of oem @ http://git.launchpad.net/~ubuntu-core-dev/ubuntu-seeds/+git/platform/commit/?id=3a0926b5eeecb6c57770edb831cdaa0aef73274e (by Dimitri John Ledkov)


[06:59]  * duflu vomits on the boost docs
[07:59] <alf_> RAOF: After the latest saucy updates, any program that uses libglx crashes. Unfortunately this includes firefox, too, so I can't really do a proper search for this problem... Have you seen this?
[08:00] <alf_> mlankhorst: ^^?
[08:02] <alf_> mlankhorst: (btw, this is plain X not XMir)
[08:06] <mlankhorst> no?
[08:06] <mlankhorst> lets see..
[08:06] <mlankhorst> alf_: what card? open or closed d rivers?
[08:07] <alf_> mlankhorst: 5750, r600g, Xorg log: http://paste.ubuntu.com/6174634/
[08:08] <alf_> mlankhorst: EGL works fine (e.g. glmark2 crashes X, glmark2-es2 works fine)
[08:08] <mlankhorst> ok
[08:10] <mlankhorst> wouldn't compiz crash too, then?
[08:12] <alf_> mlankhorst: I am not running compiz
[08:13] <alf_> mlankhorst: my WM doesn't use GL
[08:17] <mlankhorst> alf_: starts for me(TM)
[08:18] <mlankhorst> oh glamor
[08:18]  * mlankhorst installs
[08:21] <mlankhorst> still no issue with glamoregl installed :P
[08:22] <mlankhorst> alf_: can you install xserver.*dbg and xserver-xorg-glamoregl-dbgsym?
[08:22] <alf_> mlankhorst: sure
[08:24] <alf_> mlankhorst: does glamoregl-dbgsym need a special repository?
[08:25] <mlankhorst> yeah ddebs.ubuntu.com
[08:25] <alf_> mlankhorst: thanks
[08:26] <mlankhorst> hm doesn't exist i think, grr
[08:30] <alf_> mlankhorst: the backtrace using xserver.*dbg is not more helpful...
[08:30] <mlankhorst> meh, valgrind? :P
[08:34] <alf_> nick alf|debugging_x
[08:41] <alf|debugging_x> mlankhorst: http://paste.ubuntu.com/6174709/
[08:43] <mlankhorst> string = (const char *) CALL_GetString(GET_DISPATCH(), (name));
[08:44] <mlankhorst> can you try with valgrind? :P
[08:45] <mlankhorst> oh missed a bunch of updates
[08:49] <mlankhorst> hold on updating first then retrying
[08:52] <alf|debugging_x> mlankhorst: the interesting part of the valgrind log: http://paste.ubuntu.com/6174744/
[08:53] <mlankhorst> nope interesting part is the whole log :P
[08:56] <alf|debugging_x> mlankhorst: whole log: http://paste.ubuntu.com/6174771/
[08:58] <alf|debugging_x> mlankhorst: (all of these are produced by starting X and then glmark2)
[08:59] <mlankhorst> hmz, works for me :S
[08:59] <mlankhorst> do you have libgl1-mesa-dri/glx installed correctly?
[09:00] <alf|debugging_x> mlankhorst: I think so, let me --reinstall them
[09:01] <mlankhorst> same with whole of xserver-xorg-core and xserver-xorg-video-radeon to be sure
[09:04] <duflu> alf|debugging_x, mlankhorst, Confirmed -- I get the same valgrind error/crash
[09:04] <duflu> That's relatively new... only must have crept in past couple of weeks
[09:04] <mlankhorst> but I don't :/
[09:04] <mlankhorst> is that with usc?
[09:05] <alf|debugging_x> mlankhorst: not in my case, just plain X
[09:05] <duflu> mlankhorst: Using mir_demo_server_basic and connecting a Xorg to it manually
[09:05] <mlankhorst> hm..
[09:05] <alf|debugging_x> mlankhorst: reinstalled packages, no difference
[09:05] <mlankhorst> something like Xorg :0 & DISPLAY=:0 glmark2 right?
[09:06]  * duflu tries without Mir
[09:06] <alf|debugging_x> mlankhorst: right, here are my package versions http://paste.ubuntu.com/6174795/
[09:06] <mlankhorst> alf|debugging_x: can you remove glamoregl ?
[09:07] <mlankhorst> and meh, same versions here
[09:08] <alf|debugging_x> mlankhorst: removing glamoregl removes video-ati...
[09:08] <mlankhorst> hm indeed
[09:11] <duflu> I don't remember X being this bad in valgrind. Now I get a huge stream of uninitialized jumps from libpixman and the intel DDX
[09:11] <mlankhorst> duflu: oh ignore that
[09:12] <mlankhorst> intel ddx needs valgrind enabled, and it might not have been
[09:12] <duflu> Dear ickle, that's slightly silly
[09:13] <mlankhorst> I mean for valgrind warnings
[09:13] <mlankhorst> but it should work with the most recent versions afaict
[09:14] <mlankhorst> anyway I have no idea what you 2 have in common that glx fails, my system works :/
[09:17] <mlankhorst> even with mir_demo_server_basic, although it has the same bug that cursor has in multimonitor, afaict..
[09:17] <mlankhorst> frames that jump backwards
[09:19] <mlankhorst> it happens when i only run glmark2 in the nested xorg..
[09:23] <duflu> mlankhorst: The jumpy frames fix landed upstream today. Should hit the archive soon enough
[09:23] <mlankhorst> ah k
[09:24] <mlankhorst> anyway running only the versions in the archive doesn't seem to trigger it for me..
[09:31] <alf|debugging_x> duflu: do you get the crash with plain X?
[09:32] <duflu> alf|debugging_x: No. Although my system is all over the place now. Not reliably doing the same thing
[09:41] <mlankhorst> meh could it be from some residual mir stuff?
[11:11] <alf|debugging_x> mlankhorst: @residual mir stuff, I don't think its very likely
[11:11] <mlankhorst> alf|debugging_x: meh I have no idea what's different then :/
[11:11] <mlankhorst> you're on amd64 right?
[11:14] <mlankhorst> alf|debugging_x: oh btw this is for your egl image branch http://paste.debian.net/47487/
[11:14] <alf|debugging_x> mlankhorst: yes
[11:15] <alf|debugging_x> amd64
[11:15] <mlankhorst> afaict that should be the correct paths here, it still doesn't work but it looks like it's because garbage gets copied or something
[11:18] <alf|debugging_x> mlankhorst: thanks
[11:19] <mlankhorst> so I would try without bypass first :P
[11:21] <alf|debugging_x> mlankhorst: I need to fix my development environment first :)
[11:22] <mlankhorst> ok then bypass second, I guess
[11:22] <mlankhorst> O:-)
[12:02] <alf|debugging_x> mlankhorst: it seems that I am getting a NULL struct gl_api table..., i.e. _glapi_tls_Dispatch is NULL
[12:06] <mlankhorst> hm
[12:06] <mlankhorst> that's in fact possible
[12:07] <alf|debugging_x> mlankhorst: arghh... for some reason glx is looking in /usr/lib/dri/... to find drivers, but the drivers are in fact in /usr/lib/x86_64/dri, creating a symlink fixes the problem...
[12:08] <mlankhorst> now THAT is weird :P
[12:08] <mlankhorst> I have no /usr/lib/dri either, but glx works
[12:09] <mlankhorst> dpkg-shlibdeps: warning: debian/libgl1-mesa-dri/usr/lib/x86_64-linux-gnu/dri/radeon_dri.so contains an unresolvable reference to symbol _glapi_tls_Context: it's probably a plugin
[12:09] <mlankhorst> I should probably link radeon_dri against libglapi now
[12:09] <mlankhorst> and the other *_dri.so too
[12:11] <mlankhorst> but that would only affect classic drivers
[12:13] <alf|debugging_x> mlankhorst: before symlinking http://paste.ubuntu.com/6175350/
[12:14] <mlankhorst> hm just why..
[12:15] <mlankhorst> alf|debugging_x: somewhere something is seriously messed up, mesa is built debian/rules:   --with-dri-driverdir=/usr/lib/$(DEB_HOST_MULTIARCH)/dri \
[12:15] <mlankhorst> debian/rules:   --with-dri-searchpath='/usr/lib/$(DEB_HOST_MULTIARCH)/dri:\$$$${ORIGIN}/dri:/usr/lib/dri' \
[12:16] <mlankhorst> do you have anything in your environment?
[12:16] <mlankhorst> env |grep usr.lib
[12:17] <mlankhorst> and ldd /usr/bin/glxgears to make sure the right libgl is used
[12:19] <mlankhorst> In fact you probably have a different libGL, built with static glapi. It's the easiest way to explain why _glapi_tls_Dispatch is NULL..
[12:21] <mlankhorst> same for duflu I guess :P
[12:24] <alf|debugging_x> mlankhorst: you are right, it seems there were /usr/lib/libGL.so* files, but I have no idea where the came from... perhaps some upgrade path is not working correctly?
[12:25] <alf|debugging_x> mlankhorst: thanks for the hint!
[12:26] <mlankhorst> more like ancient mir leftovers, or compiled yourself..
[12:26] <mlankhorst> even precise didn't stuff libGL in /usr/lib any more
[12:27] <alf|debugging_x> mlankhorst: could be, although I had been using this setup without issues before the upgrade
[12:33] <mlankhorst> shrug, maybe during updates it disabled the alternative and added it again, causing it to find the old libgl or something because it was cached?
[12:35] <alf_> mlankhorst: we will probably never know, I am just happy that I have a working system again...
[12:36] <mlankhorst> I'm guessing leftover from egl-image testing:P
[12:41] <mlankhorst> plus a bug in xorg, it seems
[12:42] <mlankhorst> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/1232000
[12:43] <mlankhorst> yep, crashes here too, ok lets fixup that fail..
[12:49] <mlankhorst> alf_: but it looks like the glapi_tls_Dispatch thing is a separate issue :P
[12:50] <mlankhorst> DISPLAY=:0 LIBGL_ALWAYS_INDIRECT=1 glxinfo
[12:53] <alf_> mlankhorst: confirming that glapi_tls_Dispatch is still a problem
[12:53] <alf_> mlankhorst: (confirmed)
[12:53] <mlankhorst> yeah easy to reproduce like that
[12:55] <mlankhorst> normally glapi is pulled in, I guess xorg-server doesn't because it doesn't use libGL
[12:56] <mlankhorst> hm what does it use, though..
[12:59] <mlankhorst> oh no it loads /dri/* directly
[13:13] <mlankhorst> ok one line patch made
[13:20] <mlankhorst> nope, weird stuff :/
[13:32] <mlankhorst> afaict the dri libs deliberately do not link against shared libglapi, and xserver provides its own
[13:55] <mlankhorst> meh :/
[14:01] <davmor2> kgunn: Video of sf vs mir done, uploading to u1 currently will paste the link once complete.  https://pastebin.canonical.com/98152/  stop unity line here throws up the following stop: Unknown job: unity is the command correct and do I just carry on?
[14:02] <kgunn> davmor2: crap...i told you wrong...stop unity8
[14:02] <kgunn> davmor2: also i learned from some chatting on fri
[14:02] <davmor2> kgunn: http://ubuntuone.com/78ciDgDqX8zEZfFAWs5KmW here is the video link it might take a while to download it and it's mov format so it works for me on raring no idea about saucy yet :)
[14:02] <mlankhorst> alf_: wow it looks nasty
[14:04] <davmor2> kgunn:   or not phablet@ubuntu-phablet:/$ stop unity8           stop: Unknown job: unity8
[14:04] <kgunn> davmor2: i learned that for su phablet you want to do....sudo -u phablet -i (instead of just su phablet)
[14:04] <mlankhorst> oh god it's exactly what I thought it was.. damn
[14:04] <davmor2> kgunn: ah right will do
[14:04] <kgunn> davmor2: sorry...should've pinged you when i learned  it :)
[14:05] <kgunn> davmor2: also...i had to totally reboot...to get the state right
[14:05] <alf_> mlankhorst: what did you think it was? :)
[14:05] <kgunn> davmor2: if you've been su phablet'ing
[14:05] <davmor2> kgunn: I wrote down the steps that I've done anyway so I'll just replicate it again with the timings now :)
[14:05] <mlankhorst> alf_: interaction with glamor-egl..
[14:05] <mlankhorst> rm /usr/lib/xorg/modules/libglamoregl.so is a workaround
[14:06] <alf_> mlankhorst: :/
[14:09] <davmor2> kgunn: overall I think mir is a good 20 seconds slower that sf on this fairly simple set of tests.  The biggest ones being app launch, indicator pull down (it's much smoother but slower because of it by the look of things) app switch is slower, rotate is slow on both but worse on mir and I'll retry the commands once the phone is back up
[14:10] <kgunn> davmor2: what  image are you on? (i tried late friday afternoon...and it looked really good)
[14:11] <kgunn> davmor2: but i had seen pretty awful rotation prior to that
[14:11] <davmor2> kgunn: todays
[14:11] <kgunn> w/ mir
[14:11] <kgunn> ah...ok
[14:11] <kgunn> still downloading video...
[14:11] <kgunn> i should watch that first
[14:11] <davmor2> kgunn: rotate is crappy on sf and mir
[14:12] <kgunn> davmor2: oh yeah...and you're on maguro/galaxynexus right ?
[14:12] <davmor2> kgunn: 2 vids first is mir second is sf.  I'm on maguro yes and I'm on image 70
[14:13] <kgunn> i keep forgetting that
[14:14] <kgunn> davmor2: galaxynexus has an omap4460 in it
[14:14] <kgunn> davmor2: i managed the gfx team at ti for 5 yrs
[14:14] <kgunn> davmor2: let's just say...omap4470 was a truly awesome chip...and  i would totally work on a program that used the chip
[14:15] <kgunn> davmor2: omap4460....mmm....well.....
[14:15] <davmor2> kgunn: I have to admit mir is a hell of a lot better just a little slower.  It's still a little jerky on app switch but everything else is really smooth
[14:15] <davmor2> kgunn: haha
[14:15] <kgunn> davmor2: there are some things that really effect gfx/ux there...
[14:16] <kgunn> davmor2: and some secret sauce we don't have access to using binaries
[14:18] <davmor2> kgunn: You can stop with the excuses already, man are you a race driver in your spare time? ;)  No I get there are issues between all the layers that need to be overcome.  There are issues on sf that don't seem to be present on mir and visa versa
[14:19] <kgunn> davmor2: just lots of scar tissue (years of it) listening to people talk/complain about gfx performance that have no clue :)
[14:20] <kgunn> davmor2: so thank you for understanding :) most people just throw rocks instead
[14:25] <davmor2> kgunn: I'm amazed at how stable it has become and how quickly mir has been put together to be honest.   But more import for me is it's this |   | short of being a daily driver :)  rather than this much  |                                             | a couple of weeks back :)
[14:25] <davmor2> typical line breaks in the wrong place but you get the idea ;)
[14:25] <greyback> alf_: alan_g: question for you guys. I need to get the display geometry when a mir server isn't running. You think there's some way to fetch that information without actually running the mir server?
[14:25] <kgunn> davmor2: lol....gonna use ascii art on my progress tracking
[14:26] <alan_g> greyback: what counts as "running"?
[14:26] <greyback> alan_g: I've not started any compositor or event handler - I've not called "run_mir"
[14:29] <alan_g> You can create a configuration object and init part of the system by getting the objects you need. That doesn't start the compositor
[14:29] <alf_> greyback: you could call the_display() to get the display and then get the current configuration, but keep in mind that if you release it the next the_display() call would be a different object
[14:30] <greyback> alf_: that'll probably be enough. Will try
[14:31] <hikiko> hey:)
[14:31] <hikiko> question
[14:31] <hikiko> is the include/share/mir
[14:32] <hikiko> the right place to add an fd wrapper clasS?
[14:32] <alf_> greyback: also note that getting the_display() brings up the display, and releasing it tears it down (i.e. there will probable be visual effects of doing so)
[14:33] <greyback> alf_: this is for autopilot tests to get screen geometry before it starts running the shell. Visual flicker should be ok
[14:33] <alf_> greyback: ok then
[14:34] <greyback> alf_: can you think of any other way I could fetch that information?
[14:34] <alf_> greyback: not really in a platform independent manner
[14:34] <greyback> alf_: ok, I'll try this idea and will see
[14:39] <kgunn> greyback: so that flicker will really only be associated with AP tests...not 100% of boot times
[14:39] <kgunn> ?
[14:39] <greyback> kgunn: only for AP
[14:39] <kgunn> coolio
[14:40] <davmor2> kgunn: https://pastebin.canonical.com/98223/ posted to to phablet by accident, my phone is hating your commands you know :(
[14:41] <kgunn> davmor2: are you cdimage or system ?
[14:41] <davmor2> kgunn: system
[14:41] <kgunn> wonder if writability is an issue...
[14:41] <kgunn> just a thot
[14:42] <davmor2> kgunn: I'll make it rw and try again
[14:42] <kgunn> davmor2: cool....just a guess
[14:45] <alf_> greyback: you could probably avoid any effects by holding the_display() until mir is finished (i.e. after run_mir returns). Mir will reuse the same instance internally in that case.
[14:47] <davmor2> kgunn: No it just hates me https://pastebin.canonical.com/98225/  no the touch command at the end to ensure RW was in play :)
[14:48] <davmor2> s/no/note
[14:48] <kgunn> davmor2: lol...crap
[14:49] <kgunn> davmor2: i admittedly have seen what you see every now and then...i usually suspect myself...and reboot/reflash...and 99% it corrects
[14:49] <kgunn> but wonder if something else is going on there
[14:50]  * kgunn imagines the phone silently hating davmor2  while the screen is off...waiting for him to just hit the power button
[14:52] <davmor2> kgunn: No hit the power button sends it into rage mode I mean it's got power then and everything :)  It quietly hates me while it is turned off :)
[15:02] <mhall119_> kgunn: I'll be a couple minutes late
[15:02] <kgunn> mhall119_: np
[15:04] <davmor2> kgunn: no just hates me https://pastebin.canonical.com/98226/  that's all the commands so you can confirm I'm not missing something
[15:07] <davmor2> kgunn: /me needs to stop playing with this now as I need my phone and I got loads to do, feel free to give me a ping if you figure something out :)
[15:08] <kgunn> davmor2: will do
[15:08] <kgunn> davmor2: i'll try to pester someone else on my team with a galaxy nexus...wonder if we broke something somehow
[15:17] <FunnyLookinHat> I know this isn't the right place to ask about it - but maybe you guys know where it would be?  Wondering about feature-set of Multitouch on Ubuntu w/ touchscreens - specifically, a lack of two-finger scrolling ?
[15:17] <FunnyLookinHat> Wow - I've never typed less of a grammatically correct sentence in my life.
[15:25] <kdub> mir supports multigesture, its up to the shell and the applications to use them
[15:26] <FunnyLookinHat> Ah ok - I'll take my question to #ubuntu-unity :)
[15:49] <racarr> Good morning team mir
[15:53] <davmor2> kgunn: looking at it another good test is to get your contacts on the phone and then scroll through them.
[16:26] <davmor2> kgunn: mir might of introduced an old bug,  open 2 apps, close the one on the left, the one on the right should now replace it.  What is happening for me is it is opening the second app instead
[16:27] <davmor2> kgunn: In fact you know what.  Tomorrow I might try and spend the entire day on mir and see what bugs I hit :)
[16:43] <kgunn> davmor2: all good
[16:43] <kgunn> appreciate it
[16:43] <kgunn> racarr: mornin'
[16:46] <racarr> kgunn: Morning :)
[16:48] <kgunn> ok, gonna take a break and go run...
[16:48] <kgunn> bbiab
[16:53] <racarr> Enjoy :D
[17:03] <kgunn> ok bbiab for real
[17:46] <greyback> racarr: quick question, in case you know it on top of your head: you have 2 apps open. You unfocus. Then one app closes. Does Mir keep the unfocus state, or give focus to the remaining app?
[19:02] <kdub> stupid darn hwc implementations
[19:16] <kdub> exynos5 hwc checks that a garbage value is set in a deprecated field (and fails without error code if not set) just because surfaceflinger sets the field
[19:16] <kdub> -_-
[19:29] <ChickenCutlass> kdub, wow
[19:33] <kgunn> kdub: good old semico software :)
[19:35] <kdub> yeah... grumble grumble
[19:41] <kgunn> racarr: hey, would you mind reviewing https://code.launchpad.net/~gerboland/unity-mir/whitelist-musicplayer/+merge/188387
[19:41] <kgunn> ricmm: or you could ^
[19:42] <kgunn> hot one...of course
[19:42] <kgunn> looks simple tho
[19:42] <kgunn> dandrader: ^ or you could
[19:43] <kgunn> just someone holler as to who's gonna take it
[19:43] <ricmm> looks fie
[19:43] <ricmm> fine*
[19:49] <ricmm> kgunn: I'll do some testing later and I'll get it in trunk before EOD
[19:49]  * ricmm takes it
[20:01] <FunnyLookinHat> Yo guys - it looks like Mir / Unity System Compositor still are only in universe ( not default ) - any idea on when  that's getting tightened up?
[20:10] <FunnyLookinHat> brb
[20:18] <kgunn> racarr: ping
[20:40] <robert_ancell> thomi, are you working on bug 1232054 at the moment?
[20:42] <kgunn> robert_ancell: thomi is runing errand/appt right now afaik
[20:43] <robert_ancell> k
[20:43] <robert_ancell> kgunn, there were no problems with that other change yesterday?
[20:44] <kgunn> robert_ancell: none that i'm aware of
[20:46] <robert_ancell> kgunn, regarding duflu's email about the merging to lp:mir making it harder to bisect. I guess he's right there, the other option is just to bzr push the dev branch to lp:mir periodically. Any thoughts on that?
[20:46] <robert_ancell> If we did switch to that we'd have to do a bzr push --overwrite the first time which would change the history but not the contents
[20:47] <robert_ancell> Or the other option is to perhaps cherry pick each commit over and manually push them. Seems like a lot of work though
[20:49] <racarr> kgunn: Ponnng sorry, IRC session was hung
[21:20] <kgunn> racarr: hey was wondering if you were working on the api/support that zanetti needs to make the hud spyglass work (i think there was something else requiring that...nbut can't remember)
[21:20] <racarr> kgunn: https://bugs.launchpad.net/mir/+bug/1233378 :)
[21:21] <racarr> halfway done
[21:21] <racarr> :)
[21:21] <kgunn> racarr: awesome! thanks...i don't mind it not being there for a day or so....kind of want to avoid an api break while we're turning on mir by default :)
[21:22] <kgunn> robert_ancell: it is true...about what duflu says...
[21:22] <racarr> ok
[21:22] <kgunn> robert_ancell: but on the other hand...there's also no mystery where those changes are coming from :)
[21:22] <racarr> I just want to get it out of the way so I can get back to API
[21:22] <kgunn> so, one could easily go look at the dev branch
[21:23] <robert_ancell> kgunn, yeah, and I guess it's possible to bisect inside a merge perhaps?
[21:23] <kgunn> racarr: ack...no worries...you get it on dev branch and robertA and i will manage the api break
[21:23] <kgunn> robert_ancell: i think this would actually be worthwhile to have a session on at the management sprint
[21:24] <kgunn> e.g. why are we on sacred lp:mir/trunk
[21:24] <kgunn> we should be on lp:mir/sacred
[21:24] <robert_ancell> kgunn, i.e. reverse it?
[21:24] <kgunn> and see if we can effect some change that way
[21:24] <kgunn> robert_ancell: well...i think most engineers are bothered that "trunk" is considered sacred
[21:25] <racarr> kgunn: ill come in my ripped jeans, tell the story of a poor developer forced out on to the streets through branching practices
[21:25] <racarr> it will be a real sob piece.
[21:25] <kgunn> :))
[21:25] <robert_ancell> racarr, ha!
[21:25] <kgunn> robert_ancell: i'm actually not suggesting to change anything at the moment - we should stay the course for the moment
[21:26] <kgunn> just because we're finaly landing things without issue (other than duflu upset about having to dig a litte :)
[21:26] <robert_ancell> kgunn, yeah, we've had enough change to confuse everyone. The current system is not great but it works for now and it's ultimately temporary
[21:26] <kgunn> rigth
[21:26] <kgunn> right even
[21:26] <kgunn> robert_ancell: more like just a session with asac & didrocks on a proper pulling system
[21:27] <robert_ancell> kgunn, yep
[21:27] <kgunn> that would in effect help us in the upstream branch managemewnt
[21:27] <kgunn> or management even
[21:27] <kgunn> racarr: have you ever run autopilot on the phone?
[21:36] <racarr> No.
[21:51] <racarr> having to implement the inverse of mia::Lexicon
[21:51] <racarr> ><
[21:53] <kdub> at least you can have some interesting class names as a result
[21:54] <kdub> mir::input::ReverseLexicon
[21:57] <racarr> haha no just new methods on the lexicon
[21:57] <racarr> alternatively mir::input::Leximonicon
[22:02] <kdub> mir::input::Lexicant
[22:02] <racarr> kdub: Which is of course the concrete implementation.
[23:06] <racarr> had a misconfusion about the input dispatcher API...there is still a missing piece of machinery for the input injection
[23:06] <racarr> trying to sort out which path to take...but it will take a little longer any way.
[23:08] <racarr> The input dispatcher injection goes through the normal targetting interface, rather than taking a target at injection time
[23:09] <racarr> adding a direct injection interface, isn't trivial, and requires mucking around with InputDispatcher a bunch
[23:09] <racarr> it would be pretty easy to add like
[23:09] <racarr> input_injection_mode_skip_shell_surfaces
[23:09] <racarr> which works well
[23:09] <racarr> but then we need, something internal to ms::Surface which indicates
[23:09] <racarr> a 'shell' surface
[23:24] <kdub> seems not very generic
[23:24] <kdub> i guess this goes back to the central model problem
[23:26] <kdub> racarr, the problem is you need to dish out input to certain clients, but we iterate over the ms::Surfaces
[23:26] <kdub> ?
[23:29] <racarr> kdub: Yes.
[23:29] <racarr> or the alternate problem is modify the input dispatcher to support injection in a particular clients queue
[23:29] <racarr> I think that may be the harder/riskier approach though
[23:34] <kdub> yeah
[23:37] <kdub> hmm, maybe there should be a bitmask (of sorts) that filters the input to the surfacestack
[23:37] <kdub> (just musing, might be a dumb idea :) )


[11:25] <saispo> hi cjwatson
[11:25] <saispo> anything have been changed in the mirror or other ?
[11:26] <saispo> now when i create a cd, i have an error in the installer which say me that it doesn't found the kernel modules :/
[11:26] <saispo> the latest changes i do it's a rsync...
[11:35] <saispo> d-i try to catch Packages and Packages.gz in dist/feisty/debian-installer/binary-i386/
[11:49] <cjwatson> make sure you're absolutely current; such problems are common when the kernel ABI is in the middle of being changed, and there was such a problem yesterday.
[12:28] <saispo> cjwatson: yep, and i think my seeds it's not up2date
[01:40] <CIA-15> ubiquity: cjwatson * r1965 ubiquity/ (4 files in 3 dirs): * New partitioner: Mark unusable free space as such (part of LP: #86202).
[02:36] <saispo> cjwatson: i confirm, it's a seed problem, i sync with the latest and all work fine, thank you.
[02:36] <cjwatson> ok, you need to do that frequently if you're maintaining a seed branch.
[02:37] <saispo> yep
[02:37] <saispo> it's possible to sync them all the time i launch a create cd ?
[02:38] <cjwatson> your seed branch is modified in some way, yes?
[02:57] <saispo> cjwatson: yep, it's modified
[02:57] <saispo> i add a file
[02:57] <saispo> and modify STRUCTURE file
[02:58] <cjwatson> so no, it's not possible to merge them automatically, unless you have an artificial intelligence hidden away; merging can require human intervention
[03:06] <saispo> yep, or shell script ? ;)
[05:38] <CIA-15> oem-config: cjwatson * r273 oem-config/ (debian/changelog lib/frontend/kde-ui.py): merge from Anirudh
[05:40] <CIA-15> oem-config: cjwatson * r274 oem-config/ (debian/changelog debian/copyright lib/frontend/gtk-ui.py): * Update other copyright notices.
[07:38] <CIA-15> ubiquity: cjwatson * r1966 ubiquity/ (3 files in 2 dirs):
[07:38] <CIA-15> ubiquity: * Old partitioner: Work around yet another hard-to-explain crash due to a
[07:38] <CIA-15> ubiquity:  partition being missing from /proc/partitions (LP: #73058).
[07:41] <evand> huh, still maintaining the old partitioner code for Feisty, or is it for Dapper LTS?
[08:15] <cjwatson> evand: only vaguely. going through old bugs
[08:16] <cjwatson> I'll delete the code after feisty, but it doesn't seem right to reject bugs yet when I can see the workaround
[08:16] <evand> gotcha
[08:16] <cjwatson> and yes, it might be useful to merge back at some point


[01:42] <ardchoille> I'd like to layoutmy Homepage Content area using html <br><a> and <ul>. How can I do that?
[01:43] <wgrant> ardchoille: it is not possible at the moment.
[01:44] <ardchoille> Is there any way to layout things in paragraphs? carriage returns don't seem to work
[01:45] <wgrant> ardchoille: Works fine for me...
[01:46] <ardchoille> wgrant: Doesn't work here:  https://launchpad.net/~ardchoille42
[01:46] <ardchoille> carriage returns there
[01:48] <ardchoille> Oh, I just added "About me:" and a link,and the link isn't parsed either.
[01:48] <wgrant> Ah, it's probably because you have no karma.
[01:49] <wgrant> Users without karma don't get formatted, due to spam concerns.
[01:49] <ardchoille> That's just plain silly, IMHO
[01:49] <Peng> File a bug about it. Then you'll have karma and it'll work! :D
[01:49] <ardchoille> I had lots of karma, must have been taken away since I didn't have much input lately
[01:49] <ardchoille> Peng: hehe
[01:49] <wgrant> Right, it should probably instead detect whether you have any karma actions, not whether you have any karma.
[01:49] <ardchoille> KArma decreases over time so that'd be a waste of time
[01:49] <wgrant> https://launchpad.net/launchpad-registry/+filebug
[01:50] <ardchoille> Thanks folks.
[01:50] <Peng> Is he going to file a bug?
[01:50] <wgrant> Probably not.
[01:50] <wgrant> If I don't see one soon, I will file it.
[01:51] <Peng> <3
[05:08] <mrooney> is anyone else seeing staging.launchpad.net as down?
[05:09] <wgrant> mrooney: It should be back in about 25 minutes.
[05:09] <wgrant> It's currently updating.
[05:09] <mrooney> oh I see, is that normal and happens every time it syncs?
[05:11] <mrooney> now that I've automated packaging and uploading to PPAs, I'm exciting to start LP API scripting and automating release process stuff as well!
[05:12] <wgrant> I don't know whether it's normal. But it has been the case for a few days now.
[05:12] <mrooney> I was thinking of something that you give a milestone, and it will create a release, mark all fix committed as fixed released, upload tarballs/debs, and such, make LP announcement
[05:12] <wgrant> That would be nice.
[05:12] <mrooney> though I don't want to reinvent anything, is there similar public stuff out there?
[05:12] <wgrant> (although announcements aren't yet exposed in the API)
[05:12] <mrooney> ah, alas
[05:13] <mrooney> though adding stuff to the API isn't that hard, right?
[05:13] <mrooney> maybe if I get up to that point, I can find a mentor and add that
[05:13] <wgrant> No.
[05:13] <wgrant> I think somebody's already working on it.
[05:13]  * wgrant looks.
[05:14] <wgrant> Bug #409090
[05:15] <mrooney> oh I wonder if quickly is doing some LP release automation?
[05:16] <wgrant> that appears to be the case.
[05:16] <mrooney> I shall ask in the appropriate channel!
[05:16] <mrooney> thanks for the bug link :)
[05:28] <mrooney> oh no, the instructions for launchpadlib on help.lp.net are quite broken in multiple ways
[05:28] <mrooney> should I file a bug somewhere?
[05:30] <wgrant> mrooney: Sure you're not just using an old version?
[05:35] <mrooney> wgrant: the first step of getting the latest launchpadlib is "bzr branch lp:oauth"
[05:35] <mrooney> at least for me that's quite an error
[05:37] <mrooney> can anyone else confirm or deny my sanity?
[05:39] <wgrant> Ah, yes, it has no default branch.
[05:39] <wgrant> Odd.
[05:39] <mrooney> yeah I looked at the branches and don't see an obvious "right" one
[05:40] <mrooney> I'll grab malept's he's a good guy :)
[05:50] <RAOF> How long does it take for Ubuntu uploads to get merged into the package branches?
[05:52] <wgrant> RAOF: That's probably more of an #ubuntu-devel question. It's not actually part of Launchpad.
[05:52] <RAOF> Really?  Launchpad isn't responsible for the package import service?
[05:53] <wgrant> No.
[05:53] <wgrant> it's run by james_w, using launchpadlib.
[05:53] <RAOF> Colour me surprised.
[05:53] <RAOF> Aaah.
[06:01] <mrooney> okay staging is back, albeit a few weeks at least out of date, odd
[15:30] <thopiekar> hi. got a question about packaging.. I have the package, called "foo", and want to create the same package with the unstable version, called "foo-testing".. but other packages are depending on "foo".. so what do I have to do?
[15:36] <qense> thopiekar: This channel is for Launchpad, which is a webapplication. I think you should ask your question in #ubuntu-motu.
[16:56] <paki> hi at all
[16:57] <paki> how can i compile a project with py file for upload to launchpad ppa?
[17:34] <kklimonda> is it possible to disable sending of the failed builds logs to all team members?
[18:30] <jgoppert> hey, would be nice if we could use launchpad ppa for lenny packages, would be a nice way to give back to debian
[18:57] <mok0> branching an LP branch doesn't work from a hardy machine
[18:57] <mok0> It says:  ERROR: Unknown branch format: 'Bazaar Branch Format 7 (needs bzr 1.6)\n'
[18:57] <mok0> :-(
[18:58] <idnar> I don't think that has anything to do with Launchpad, per se
[18:58] <mok0> oh?
[18:59] <jpds> bzr |    1.6.1-1 |      intrepid | source, amd64, i386
[18:59] <idnar> mok0: the branch format is determined by whoever put the branch there
[19:00] <idnar> or perhaps I should say, whoever created the branch
[19:00] <mok0> idnar: that was on a karmic system
[19:00] <mok0> idnar: but I need to branch onto servers that run hardy
[19:00] <mok0> idnar: and supposedly, hardy should still be supported
[19:01] <idnar> you need to pick a format that's supported by the version in hardy
[19:02] <mok0> idnar: Can I convert the already existing branch or do I need to zap it
[19:02] <mok0> ?
[19:02] <idnar> I'm not sure of the details; you might be better off asking in #bzr, though
[19:02] <mok0> idnar: ok, thanks, will do...
[19:03] <mok0> It is a bad idea to change the repo format to something that is not backward compatible
[19:03] <mok0> ...forward I should say
[19:18] <mok0> Heh. Now I have converted the LP branch so it is compatible with hardy. However, now I can't push to the repo from my karmic workstation. Bah
[19:23] <idnar> mok0: the repo on your karmic workstation probably needs to be in the same format
[19:24] <mok0> idnar: it is. I branched it from LP but can't push to it
[19:24] <mok0> idnar: conclusion is that you can't work across distributions with LP
[19:24] <mok0> idnar: which is _really_ bad given that hardy is supported for another 2.5 years
[19:31] <doctormo> What's the quickest way to get from a bug object to a project object using launchpadlib?
[19:31] <doctormo> Is it task = bug.bug_tasks; task.target ?
[21:37] <thopiekar> plpower
[21:38] <wgrant> mok0: What goes wrong when you push it? All version of bzr >= 0.92 can push to pack-0.92 branches, which is the hardy default.
[21:38] <mok0> wgrant: I got an error message
[21:38] <wgrant> doctormo: A bug can have multiple tasks, each on a different project, distribution or package. You would need to pick one of them.
[21:38] <wgrant> mok0: That's not terribly descriptive.
[21:39] <doctormo> wgrant: Aye, I got it working. Thanks.
[21:39] <mok0> wgrant: I know, but I got very annoyed and upgraded my hardy server to bzr-2.02
[21:39] <mok0> wgrant: so I can't reproduce sorry
[21:39] <mok0> wgrant: I'm in work mode, which means I become impatient :-)
[21:40] <mok0> wgrant: and Ubuntu doesn't seem to care about older releases anyway
[21:40] <wgrant> mok0: s/Ubuntu/Bazaar/, and only sort of.
[21:45] <mok0> wgrant: AFAIAC, it is outrageous to introduce a bzr version on LP that is not backwards compatible with hardy *without* making sure that there's a new version of bzr in -updates
[21:46] <mok0> wgrant: I wasted a lot of time on this today, but at least I was able to fix it for myself.
[21:46] <wgrant> mok0: It's nothing to do with Launchpad. It doesn't choose the format.
[21:46] <wgrant> The client chooses the format.
[21:46] <mok0> wgrant: then it shouldn't have been upgraded
[21:46] <wgrant> And I don't see how you got a 1.6 branch without explicitly upgrading to it, since IIRC the default was never 1.6.
[21:47] <mok0> wgrant: I have bzr on my mac to
[21:47] <mok0> too
[21:47] <mok0> wgrant: I don't know what version, I just made the repo and pushed it to LP.
[21:47] <wgrant> mok0: Anyway, this is entirely a #bzr problem.
[21:48] <mok0> wgrant: then I couldn't use that from hardy. Then I zapped the repo and made it from hardy, but that didn't work with the newer versions of bzr
[21:48] <mok0> wgrant: yeah I guess.
[21:48] <wgrant> mok0: It did work with newer versions of bzr.
[21:49] <mok0> wgrant: it didn't work the way  I described
[21:49] <wgrant> mok0: In the normal case, they interoperate fine.
[21:50] <mok0> wgrant: I don't know what the reason was. Creating a repo from hardy, pushing to LP, I couldn't branch that on karmic
[21:50] <mok0> wgrant: as I said, I was annoyed and not in debug-mode
[21:51] <mok0> wgrant: so I didn't make note of my steps
[21:52] <mok0> It was fortunate that bzr-2.0.2 builds fine as a hardy package
[21:52] <mok0> It should be pushed to backports ASAP
[21:53] <wgrant> That is difficult, because of the default incompatible format change.
[21:54] <mok0> wgrant: that seems to be an integral problem of bzr. You'll just have to make a new repo
[21:58] <wgrant> mok0: See ppa:bzr
[22:07] <mok0> wgrant: I hope the bzr devs will take note NOT to change the format again
[22:08] <wgrant> mok0: They will again. But it seems that they're going to be less insane about it.
[22:09] <mok0> wgrant: well, perhaps we should take care to properly test the bzr package before it's introduced in Ubuntu
[22:10] <wgrant> mok0: Why?
[22:10] <mok0> wgrant: we really can't upgrade bzr as long as there are supported releases that don't support the newest format
[22:11] <wgrant> mok0: But then we can never introduce a new bzr, because we can never introduce a new format.
[22:11] <wgrant> (also, further testing is unnecessary. the format changes are well documented,)
[22:11] <mok0> wgrant: not true, the new format will be rolled out at a slower pace
[22:12] <mok0> wgrant: I.e. when hardy goes away, we can move to the next level, when intrepid dies, the next, etc.
[22:12] <wgrant> mok0: So you mean that the *default* format should not be changed?
[22:12] <mok0> wgrant: right
[22:13] <wgrant> mok0: That would be the right solution, but LTSes live just about forever.
[22:13] <mok0> wgrant: I don't see git or the other VCSes have the need to update their formats at the same insane pace
[22:14] <mok0> wgrant: In fact, I can still access svn repos I created years ago
[22:14] <wgrant> Accessing old branches is fine.
[22:15] <mok0> wgrant: It failed for me
[22:15] <wgrant> mok0: I suspect that you did something slightly wrong. It normally Just Works.
[22:16] <mok0> wgrant: I can't say
[22:16] <mok0> wgrant: As I said, I was impatient and annoyed...
[22:17] <mok0> wgrant: But changing the format so that old (but recent) versions don't work anymore, is criminal
[22:17] <mok0> IMO
[22:18] <mok0> I have the most recent bzr on my mac, and it is 1.18
[22:18] <mok0> most recent from fink, that is
[22:18] <wgrant> Then Fink is six months out of date.
[22:19] <mok0> wgrant: so you mean, if you have a version 6 months old, it's just tough luck that it suddenly can't read the repos?
[22:19] <wgrant> mok0: I strongly disagree with how the 2a migration was done (making it the default before support was in any Ubuntu release, and right in the middle of the LTS cycle -- it could hardly have been worse timing).
[22:20] <mok0> wgrant: I agree with that.
[22:20] <wgrant> 2a is a very good thing.
[22:20] <wgrant> But the migration path is suboptimal.
[22:20] <mok0> wgrant: I doubt most users care
[22:21] <mok0> wgrant: it may matter if you maintain an extremely large repo
[22:21] <wgrant> mok0: It's an awful lot faster and smaller. That was probably the main complaint about bzr.
[22:22] <mok0> wgrant: most users have < 100 files, I don't think you can notice any speed difference there
[22:22] <mok0> wgrant: If I needed a VCS for a large project, I would choose git
[22:23] <wgrant> mok0: Why?
[22:23] <mok0> wgrant: it's better
[22:23] <wgrant> Apart from the bad release/format cycle, which is now history?
[22:23] <mok0> wgrant: faster
[22:23] <wgrant> Why?
[22:23] <mok0> wgrant: I don't know why, but it is
[22:24] <mok0> wgrant: great design perhaps
[22:24] <wgrant> mok0: 2.0+ narrows the margin immensely.
[22:24] <mok0> wgrant: hm ok
[22:24] <wgrant> It's a really, really big difference.
[22:24] <mok0> wgrant: I can try to upgrade my 0.92 repo now, and see if it makes a difference
[22:26] <mok0> wgrant: ah, I can't... I still need my mac to work
[22:28] <wgrant> mok0: I think 1.18 should support 2a.
[22:29] <mok0> wgrant: I wont risk it to try... I
[22:29] <mok0> wgrant: 0.92 is actually fast enough for me ;-)
[22:30] <mok0> wgrant: It works, which is #1
[22:30] <mok0> wgrant: ... but it would work with LP
[22:30] <mok0> would not
[22:31] <wgrant> It does.
[22:31] <wgrant> Lots of branches are still 0.92
[22:32] <wgrant> I work with 0.92 branches from bzr 2.1 RCs.
[22:32] <mok0> ah ok. But I don't want this repo on LP anyway... it's just my personal documents
[22:33] <mok0> wgrant: so what's the problem with bzr 2 on hardy again?
[22:34] <mok0> wgrant: the package builds w/o problems
[22:34] <wgrant> mok0: Right, backporting is no problem. It's all in the bzr PPA. But 2.0 changes the default format!
[22:34] <wgrant> Backporting something which will then start making incompatible branches is probably a seriously bad idea.
[22:35] <mok0> wgrant: perhaps that could be fixed in the backport?
[22:35] <wgrant> I don't know. You should ask #bzr.
[22:35] <mok0> (Like it should have been in the first place)
[22:36] <mok0> wgrant: yeah I will look at it
[22:38] <mok0> wgrant, how many times have they changed the format?
[22:41] <wgrant> mok0: I don't know.
[22:42] <mok0> wgrant: there's a whole bunch of them, I just don't know how many of them have been default at some point
[22:43] <wgrant> mok0: pack-0.92 was the last default before 2a.
[22:43] <mok0> wgrant: and knit was the default in 0.8
[22:45] <wgrant> mok0: dirstate-tags was the default until the end of 2007.
[22:46] <wgrant> So it was the default for nearly two years.
[22:46] <mok0> Heh
[22:46] <wgrant> Er, 'it' being pack-0.92.
[23:42] <Peng> Changing the default format is like one line of code, not counting imports. In fact, a plugin already exists to use an older default format.
[23:42] <Peng> IMO it would be confusing if Ubuntu had a 2.0 that used an older default format, though.
[23:42] <Peng> But probably still worth it.
[23:47] <spreadsheet> Why do all translations in launchpad have to be bsd-licensed?
[23:48] <mrooney> hey all, any API experts know if there is a faster alternative to: for bug in milestone.searchTasks(): bug.transitionToStatus(status="Fix Released") ?
[23:48] <mrooney> I assumed I could do bug.status = "Fix Released" but no matter what object I call lp_save on it doesn't get persisted or ends up with an error
[23:51] <wgrant> mrooney: You need to call lp_save on every object.
[23:52] <mrooney> oh, that results in an error, and probably wouldn't be faster anyway, right?
[23:52] <wgrant> Right.
[23:52] <mrooney> okay, I will stick with the transitionToStatus call then, thanks :)


[12:47] <TrioTorus> hi all, I'm on the lookout for an gutsy ubuntu laptop that has 3D acceleartion, preferably a nvidia graphics card and intel core duo2 processor. No politics, what does just work?
[12:48] <TrioTorus> I've looked at the wiki page, but understandibly for gutsy it is a bit out of date.


[03:33] <tgm4883> So i'm about half way done with the mythtv "quick start guide"
[03:34] <tgm4883> is it still a quick start guide if it's going to be about 30 pages?
[15:58] <pauldsmyth> Any Ubuntu TV gurus around?
[16:01] <pauldsmyth> Ghost town!!
[16:13] <tgm4883> pauldsmyth, whats up?
[16:14] <pauldsmyth> I've followed the instructions on the wiki to install 12.04 + ubuntu tv
[16:14] <pauldsmyth> but the settings icon on the bottom right corner just leads to a blank lens
[16:14] <pauldsmyth> This is a VM in Virtual Box
[16:15] <tgm4883> hmm
[16:16] <tgm4883> that seems like a bobweaver question :/
[16:16] <pauldsmyth> Is that a person or an application?
[16:17] <tgm4883> a person
[16:17] <tgm4883> he wrote most that code
[16:17] <pauldsmyth> Ah I see
[16:17] <pauldsmyth> Is he likely to be around today?
[16:18] <tgm4883> pauldsmyth, probably
[16:19] <pauldsmyth> Ok I'll check back later, thanks
[18:09] <CrestedNewt> meeting?
[18:15] <CrestedNewt> tgm4883 - meeting?
[18:35] <tgm4883> CrestedNewt, sorry, joining now


[17:15] <zaki> hey pavlushka
[17:31] <pavlushka> hey zaki
[17:32] <pavlushka> I have figured out that nothing wrong with the anemometer, its the library which is rubbish
[20:16] <pavlushka> zaki: https://arduino.stackexchange.com/questions/62201/how-to-get-the-switchdoc-labs-weather-kit-working-using-arduino-uno :p
[20:16] <u-la-la> [ How to get the switchdoc Labs' weather kit working using arduino (UNO)? - Arduino Stack Exchange ] - https://arduino.stackexchange.com
[20:18] <zaki> still not working ?


 @kc2bez Rudra Hey.. fixed the issue 😃😃
 Haha ..thanks 😃
 @kc2bez The issue was infact with the NTFS format of the bootable usb. While installing the os, the bootable usb was not getting mounted properly due to NTFS format and hence the squashfs extraction error.
 I created the bootable usb with rufus and in fat32 file system and rest of it worked like a charm
 Seems Lubuntu and Manjaro both have issues with mounting NTFS out of the box while installing the os
[07:27] <crystal_water> after installing openttd and installing the needed packages i got this error: openttd: symbol lookup error: /lib/x86_64-linux-gnu/libiculx.so.60: undefined symbol: _ZNK6icu_6012LayoutEngine14getCharIndicesEPiiR11LEErrorCode . nows somebody a solution?
[09:02] <guiverc> crystal_water, which release of Lubuntu?
 @arnabdafadar [Seems Lubuntu and Manjaro both have issues with mounting NTFS out of the box whi …], Thanks for the information. I appreciate you getting back to us. It makes sense that Manjaro is the same, we use the same installer.
 @kc2bez Thanks. I think this should be put in the lubuntu wiki for others' reference. Should they face this problem in future, it might be of help. What say?
 Kubuntu is using the same installer i guess
 @arnabdafadar [@kc2bez Thanks. I think this should be put in the lubuntu wiki for others' refer …], I will see that it gets added to the manual.
 @kc2bez [I will see that it gets added to the manual.], Thanks again! Appreciate that.
 @Rudra Bali [Yup], Kubuntu still uses Ubiquity
 I urge you to fact check that information.
[09:16] <guiverc> Kubuntu uses a ubiquity with a skin I'm pretty sure...
 It looks like calameres..but don't know whats the backend
 Just curious..which environment do you all prefer...KDE Plasma or Gnome?
 Ok.. great. Same here
[09:18] <crystal_water> guiverc, i use lubutu 19.10 on this machine
 wget --quiet -O - http://cdimage.ubuntu.com/kubuntu/daily-live/current/focal-desktop-amd64.manifest | grep -P '(ubiquity|calamares)'
 @Rudra Bali [You know, it does look great with QT], Totally agreed!
 With CSS you can make a HTML page look like Calamares
 @Rudra Bali [Calamares does look like that], Yes..the look and feel is same..
 @Rudra Bali [https://www.makeuseof.com/tag/why-kde-better-gnome/], Thanks..gnome to me feels like extra work to search and open an application
[09:31] <guiverc> sorry crystal_water, I've been called away, will return when I can
 Rudra Why do you post this in the support channel?
[09:55] <sam_> sam
[10:00] <guiverc> crystal_water, can you please `apt-cache policy openttd`  (bionic needed libiculx60, eoan shouldn't though..)
[10:01]  * guiverc adds and please pastebinit as apt-cache policy is multi-line sorry
[10:01] <crystal_water> guiverc, this is the output: 'openttd:  Geïnstalleerd: 1.9.3-0  Kandidaat:     1.9.3-0  Versietabel: *** 1.9.3-0 100        100 /var/lib/dpkg/status     1.9.1-1 500        500 http://archive.ubuntu.com/ubuntu eoan/universe amd64 Packages'
[10:07] <guiverc> thanks..  that's no the lubuntu package; 1.9.1-1 as shown in your apt-cache policy and https://packages.ubuntu.com/eoan/openttd ; why not use the standard ubuntu package for 19.10?
[10:07] <guiverc> crystal_water, ^
[10:10] <crystal_water> guiverc, The link that you send my is for openttd 1.9.1 is there not a version for openttd 1.9.3 (that is the latest stable version))?
[10:12] <guiverc> focal will use 1.9.3-1build2; but 1.9.1 is the eoan version..  you could try snapstore  (https://snapcraft.io/search?q=openttd)
[10:13] <crystal_water> @guiverc, i have found that version a second a go. must i by fist deinstall the current install?
[10:13] <guiverc> where did you get the package?   i wonder if it was build for bionic
[10:13] <guiverc> if it was me, i would uninstall it, but I've little experience with openttd on eoan/19.10
[10:14] <crystal_water> guiverc, i have download it from this source (the official site ): https://www.openttd.org/downloads/openttd-releases/latest.html
[10:15] <guiverc> yep & i see files there for bionic, I suspect you downloaded one of those
[10:16] <crystal_water> guiverc yes i have downloaded the version for 18.10
[10:16] <guiverc> it maybe possible to make it run, but I'd be guessing; and I'm likely to make misakes (i'm tired) so unwilling to guess work-around..
[10:16] <guiverc> i think it was for bionic (18.04)
[10:18] <guiverc> it want's this I suspect (https://packages.ubuntu.com/bionic/libiculx60) but I don't know the consequences of that on eoan...
[10:25] <crystal_water> guiverc, i have uninstalled the other version and installed the new build  where can i get libicu66 (>= 66.1~rc-1~)?
[10:26] <guiverc> that is a focal package..
[10:26] <crystal_water> is this the good version: https://packages.ubuntu.com/focal/libicu66 ?
[10:27] <guiverc> it's tested for 20.04/focal, not for 19.10/eoan.. if you open it's deps, it can cause changes to your system that will snowball...
[10:28] <crystal_water> guiverc, so  it is a good idea to not install that? because i can corrupt my system?
[10:33] <guiverc> it could cause part of your system to become focal (20.04); if things go wrong the fix will be to take all your system to focal/20.04 where in less than a month you can upgrade to focal anyway... there are risks/costs as focal is still a development release...
[10:34] <crystal_water> guiverc so the best thing that i can do now is wait a month and upgrade to the stable version of focal/20.04?
[10:35] <crystal_water> and what are risks for upgrading to the not stable build it is not a production machine where i will install openttd on?
[10:36] <guiverc> if you open the link page you provided (libicu66) you'll note the packages requred for that, you could check each of those requirements to see if your eoan packages already meet them... or try `apt install` and your box will tell you what is required to be upgraded (which is quicker), just do NOT use -y so you can decline upgrade if it's going to change too much or anything critical
[10:37] <crystal_water> guiverc, i take now i coffeebreak i will sone where back.
[10:51] <Spir0>  /msg NickServ identify KiAt2018@#
[10:51] <Spir0>  /msg NickServ identify
[10:52] <guiverc> Spir0, you just published your password, I suggest changing it
[10:52] <guiverc> (you had a space before the /msg, so it wasn't taken as a command)
[11:04] <crystal_water> guiverc, i can only found libicu66 (66.1-2ubuntu2)  for focal and not for a older version of lubuntu
[11:14] <guiverc> yes, the focal version is built for focal.. each package required will have it's own dependency rules that could pull in extra packages... turning parts of your system into a fraken-eoan/focal... fixed by fully going to focal.., or waiting a month.  your choice (moving to focal/development version I'm running now myself may have other issues for you I cannot predict..)
[11:16] <guiverc> the benefit for you here is focal is a LTS release... it's more of a problem when installing standard releases (ie. eoan packages into say bionic; parts of your system will eol with the eoan/interim release, not when bionic/lts eol's... ubuntu-support-status can show us some of these issues
[11:17] <crystal_water> guiverc, if i want to the develpent version (daily build?) is it than needed to do a clean install or can i as normal update without a clean install?
[11:20] <guiverc> `sudo do-release-upgrade -d` will bump your release to 20.04, you don't need to re-install (though re-install will likely be quicker)
[11:24] <crystal_water> guiverc, thanks for the command i will think about of i will upgrade to the daily build of that i will wait a month.
[11:28] <guiverc> fyi: the 'daily' build refers to the ISO (that is built ~daily).. once installed/release-upgraded it's just 20.04
[11:30] <crystal_water> guiverc, the 'daily' build is the iso file. but whats the name from the build that i get after execute the command?
[11:32] <guiverc> it'll just be lubuntu 20.04  (or lubuntu 20.04 lts after april-23rd)
[11:34] <guiverc> `neofetch` reports my system as "OS: Ubuntu Focal Fossa (development branch) x86_64"  , ie. 20.04, the (development branch) will automatically disappear a day or so before release-date (april-23)
[11:35] <guiverc> fyi: it's not a timer that changes the string, an update will change it..
[11:40] <crystal_water> guiverc, thanks for all the info it will help my a lot.
[11:41] <guiverc> you're most welcome crystal_water
[17:49] <santimir[m]> trying to set up a random wallpaper on lubuntu 19.10 for everytime I turn on the laptop
[17:49] <santimir[m]> I wrote `Wallpaper=$(ls $HOME/.local/share/wallpapers/** | shuf -n1)`
[17:50] <santimir[m]> on the config file, but probably this is not the way to do it?
[17:51] <santimir[m]> I'm editing the system wide config file as the user config file for pcmanfm-qt > desktop settings is overwritten every time I log in
[17:51] <santimir[m]> 😕
[19:10] <axel_> Hello I try to open software-properties-qt through terminal but it tells me this error ModuleNotFoundError: No module named 'PyQt5.QtCore'
 @axel_ [<axel_> Hello I try to open software-properties-qt through terminal but it tells …], which lubuntu version?
[19:19] <axel_> 19.10
 @axel_ [<axel_> 19.10], you might have deleted teh dependency
 python3-pyqt5
 why exactly was I pinged?
 @lynorian I haven't had time to verify if it is there already but we may want make sure we highlight the fact that USBs need to be formatted with fat 32 and not NTFS.
 USBS for what?
 USBs for what
 to write the live iso to for installation
 in 1.2?
 in like chapter 1
 yes. I know we've got a couple of external links there but maybe if we had a caution or warning.
 It seems that windows users are formatting their USB with NTFS and then the install fails.
 install fails or writing the image fails
 The install fails on unsquashfs
 it actually boots which is confusing.
 so ntfs formatted usb boots an iso how?
 I am not sure what it does. I would have to dig up a Windows machine to test further.
 Is the users making the usb then fomratting most of it as ntfs but still having the uefi on the 64 bit image?
 I think so, yes. They used Rufus which I am unfamiliar with.
 I don't have a windows machine to figure out what is going on
 Ok I will dig further and get back to you.
 @kc2bez [Ok I will dig further and get back to you.], wrong channel?
 oh sorry
 Me too.
[23:21] <bim> huhu