[14:43] <gimmic> pmatulis: I want to change an interface from dhcp to static
[15:07] <mup> Bug #1702919 opened: displayed lease IP information not updated when entering rescue mode <dhcp> <MAAS:Incomplete> <https://launchpad.net/bugs/1702919>
[15:17] <pmatulis> gimmic, yep, i've got something for you
[15:18] <pmatulis> gimmic, it's a bit indirect to change an interface's IP assignment
[15:18] <pmatulis> via the CLI
[15:22] <pmatulis> gimmic, still in the oven: https://git.io/vQobJ
[15:22] <pmatulis> scroll down to 'Change the IP assignment mode of a network interface'
[15:23] <gimmic> Ah, I got most of the way there yesterday. I didn't think to remove the existing one first
[15:23] <gimmic> When I was adding it manually, it was making it an alias on :1
[15:24] <pmatulis> 'xactly
[15:29] <gimmic> Looks like that works. Might save me some clicking, thank you.
[15:29] <gimmic> I see hostname change there in the doc too :)
[15:29] <pmatulis> (welcome)
[15:29] <gimmic> How about where to hook some custom commissioning bits? Like If I just wanted to exec a command while the node was netbooted
[15:30] <gimmic> I assume commissioning would be the right place for that? Stuff I'm having to use rescue mode for right now
[15:31] <pmatulis> yeah, i haven't dived into that subject yet. i agree that it is important to have
[15:31] <gimmic> would be nice to have a simple place to define postexec stuff for the different stages, even
[15:31] <gimmic> "run this command"
[15:32] <gimmic> Right now curtin is failing due to an odd disk configuration issue with my nodes, I repopulated systems using existing disks from other 'donor systems', which still have LVM metadata on it
[15:33] <gimmic> when it tries to wipe the disk partitioning, LVM sees duplicate volgroups and errors out the process
[15:33] <gimmic> simplest way I've found to fix it so far is to use wipefs -a /dev/sd* -f
[16:11] <roaksoax> gimmic: please file a bug aginast 'curtin' and post the version of curtin-common running on the maas server
[16:29] <gimmic> Yeah. I'm also getting this after configuring raid on some hosts:
[16:29] <gimmic> /sys/class/block/dm-7 had no syspath (/sys/class/block/dm-7)
[16:29] <gimmic> curtin: Installation failed with exception: Unexpected error while running command.
[16:29] <gimmic> Command: ['curtin', 'block-meta', 'custom']
[16:47] <julen> pmatulis: I found your bug report from last year, on the connection refused for the websocket with juju and maas, did you figure out some workaround?
[16:48] <vogelc> roaksoax: Question, once a client does a dhcp request and gets an IP tftp responds with the boot information, what protocol is used to pull down the boot images?
[16:49] <roaksoax> vogelc: pxe
[16:49] <roaksoax> vogelc: from there, you mean pxelinux or efi/grub
[16:50] <vogelc> roaksoax: I see booting under MAAS direction and then every thing just stops.  do you know if its trying to use http to pull down the boot images?
[16:50] <gimmic> pxe boot should be TFTP transfer, afaik
[16:51] <roaksoax> vogelc: well it sounds like you are using legacy, so it should be booting pxelinux and getting the images from tftp
[16:51] <vogelc> Legacy?
[16:51] <roaksoax> vogelc: maybe it is not showing you console output because the right kernel params are not there ?
[16:51] <vogelc> I was thinking that too.
[16:51] <roaksoax> vogelc: what hardware are you using ? Is it configured to do Legacy boot or EFI  ?
[16:52] <vogelc> Yes we are using BIOS, not UEFI
[16:55] <roaksoax> vogelc: ok, so the booting under maas direction should yield pxelinux downloading the kernel and initrd
[16:55] <vogelc> it does look like the kernel parms might have caused some conflicts. I was able to boot removing the global parameters.
[16:55] <roaksoax> vogelc: yee that could  e too
[16:55] <roaksoax> vogelc: you could add per node kernel params too
[16:56] <vogelc> do you have a list of all the ports that need to be open on the firewall?
[16:57] <roaksoax> vogelc: from the machines to MAAS ?
[16:57] <vogelc> correct
[16:57] <roaksoax> vogelc: dns,dhcp,http on 5240,power management (ipmi).
[16:57] <roaksoax> that shoudl be it
[16:57] <vogelc> iscsi too
[16:58] <vogelc> thats where I am hung up now
[16:58] <roaksoax> that too, that will hopefully go away in 2.3 though
[17:00] <vogelc> once I get the ports opened I will let you know where we land.  thanks for the help
[17:17] <julen> roaksoax: I think I found two little bugs in the code of maas, but I don't have time to make a patch are you interested?
[17:18] <roaksoax> julen: you should file bugs for them though
[17:18] <julen> yes.. I did.. but I just wanted to speed up the thing a little bit
[17:19] <roaksoax> julen: if they are already triaged, we will look at them when we get a change
[17:19] <roaksoax> atm we are focused on fixing other critical issues
[17:19] <pmatulis> julen, bug URL?
[17:20] <julen> https://bugs.launchpad.net/maas/+bug/1702332
[17:20] <julen> the solution would be very simple, but it might require some discussion with other people
[17:21] <pmatulis> julen, i was expecting "my bug report from last year"
[17:21] <julen> it's basically dumping the http_proxy variables into /etc/environment or /etc/profile, probably within the file /usr/share/maas/maas-proxy-common.sh
[17:22] <julen> oh! I thought it was about what I asked to roaksoax :P
[17:22] <julen> https://bugs.launchpad.net/juju-core/+bug/1592179
[17:23] <pmatulis> julen, no, i never found a way out
[17:23] <julen> I am really stuck at that point too, and that websocket thing seems to me like a real black box
[17:23] <julen> oh no!
[17:23] <pmatulis> no idea why it expired
[17:24] <julen> so, how does the people manage?
[17:25] <pmatulis> julen, if it's the same issue i propose: a) you comment in it that you just got bit by it b) send a mail to the juju mailing list about it
[17:26] <julen> the maas seems to work fine (after plenty of hacks) and the juju does bootstrap almost completely. It cannot be so difficult
[17:26] <pmatulis> julen, are you running a recent version of juju?
[17:27] <julen> I just started with the maas two days ago, and juju since yesterday. So... they should be recent
[17:27] <julen> juju 2.2.1
[17:28] <pmatulis> julen, since you are so new to this stuff we value your insights. i recommend you also send a msg to the maas mailing list about why maas works only after plenty of hacks
[17:28] <pmatulis> just be positive :)
[17:29] <pmatulis> see irc channel topic for mailing list
[17:29] <julen> well... ok...
[17:30] <julen> I prefer forum format or Q&A type, but I'll subscribe for some time
[17:45] <gimmic> I just realized after upgrading to 2.2 my nodes are now using .maas dns zone instead of my old configured one. How do I configure the default?
[17:45] <gimmic> having a hard time finding that
[17:46] <gimmic> I see how I can change them manually.. but with the number of nodes it's probably just easier to redeploy them unless I can mass-change them..
[17:46] <gimmic> (Assuming I can change the default to my pre-existing zone)
[17:48] <gimmic> Would be nice if it was tied to Physical Zones
[17:58] <mup> Bug #1702976 opened: Cavium ThunderX nodes fail to auto-enlist <MAAS:New> <https://launchpad.net/bugs/1702976>
[17:59] <gimmic> 1.9 was pretty simple to set the DNS zone name, but I can't find it in 2.2? https://docs.ubuntu.com/maas/1.9/en/cluster-configuration
[18:04] <mup> Bug #1702976 changed: Cavium ThunderX nodes fail to auto-enlist <MAAS:New> <https://launchpad.net/bugs/1702976>
[18:16] <mup> Bug #1702976 opened: Cavium ThunderX nodes fail to auto-enlist <MAAS:New> <https://launchpad.net/bugs/1702976>
[18:18] <pmatulis> gimmic, sounds like something that should be reported as a bug
[18:33] <roaksoax> gimmic: 1.9 and 2.0 changed the way how DNS is managed
[18:33] <roaksoax> 1.9 used per rack, and 2.0 adds first class support for dns
[18:33] <roaksoax> gimmic: in 2.2 you have a tab that says 'DNS'
[18:34] <gimmic> All my 1.9 maas nodes had a default zone of 'example.net' and all my 2.2 nodes use '.maas'. I'd rather just change the default back to 'example.net' (and also change all existing deployed nodes to that dns zone)
[18:34] <gimmic> so I guess it's twofold: 1) I need to change my default maas dns zone 2) I need to bulk-change existing hosts' dns zone
[18:34] <gimmic> both dns zones are managed by maas
[18:52] <roaksoax> gimmic: so update the name of 'maas' to 'example.net'
[18:52] <roaksoax> gimmic: you can do that via the API
[19:01] <roaksoax> effectively, remove 'example.net', udpate 'maas' with 'example.net'
[19:16] <mup> Bug #1665057 opened: [UX] No Save button on fabric/vlan/subnets <accessibility> <canonical-bootstack> <ux> <MAAS:Fix Committed> <https://launchpad.net/bugs/1665057>
[19:28] <mup> Bug #1660819 changed: [2.1.3] webUI unusable during windows image create -- rackd gets disconnected <oil> <performance> <MAAS:Invalid> <https://launchpad.net/bugs/1660819>
[19:37] <mup> Bug #1660819 opened: [2.1.3] webUI unusable during windows image create -- rackd gets disconnected <oil> <performance> <MAAS:Invalid> <https://launchpad.net/bugs/1660819>
[19:46] <mup> Bug #1660819 changed: [2.1.3] webUI unusable during windows image create -- rackd gets disconnected <oil> <performance> <MAAS:Invalid> <https://launchpad.net/bugs/1660819>
[21:15] <catbus> roaksoax: Hi, does maas update the /etc/resolv.conf or run some tool which updates the /etc/resolve.conf in any event? I see in regiond.conf, [info] b'/etc/resolv.conf' changed, reparsing  [info] Resolver added ('<IP_ADDRESS>', 53) to server list  [info] Resolver added ('<IP_ADDRESS>', 53) to server list.
[21:19] <catbus> I have a node which looks to maas (<IP_ADDRESS>) for dns (/etc/resolv.conf in the node), but can't resolve names. I think in the /etc/resolv.conf on MAAS, it should have the external dns ip (<IP_ADDRESS>) and its ip (<IP_ADDRESS>) and <IP_ADDRESS>, but it seems maas keeps updating the /etc/resolv.conf back.
[21:20] <catbus> I know manually editing the /etc/resolv.conf is not recommended, where can I find where maas finds these ip address for dns name servers to update the resolv.conf?
[21:21] <catbus> Resolver is running, is it because my friend used Network Manager to configure network interfaces?
[21:28] <roaksoax> catbus: maas doesn't update that
[21:28] <roaksoax> catbus: you probably have network manager that updates that
[21:29] <catbus> ok.
[21:29] <exodusftw> anybody been able to successfully configure raid1 over the MaaS API? or have some examples of that
[21:30] <exodusftw> I can get the raid device to create - but i'm having issues getting a filesystem setup on the device
[21:30] <exodusftw> it would appear that when I add 2 unformatted block devices to a raid 1 device, the sda device always registers in the raid device as a partition named sda-part1 - and i'm not able to add a filesystem to that partition without it removing itself from the raid device
[21:37] <mup> Bug #1703035 opened: MAAS should warn on version skew between controllers <MAAS:Triaged> <https://launchpad.net/bugs/1703035>
[22:38] <exodusftw> nevermind -  I was able to figure it out...just had to do some magic
[22:46] <catbus> exodusftw: is that something maas.io documentation can improve on?
[22:47] <exodusftw> it certainly couldn't hurt
[22:49] <exodusftw> for example - on node creation - the current 2.0 /devices/ doc doesn't event show power_parameters as a valid key on node creation - but it certainly works
[22:50] <exodusftw> granted, I can sympathize with how difficult it is to keep up documentation across an active code base
[22:59] <pmatulis> exodusftw, what 'devices doc'?
[23:10] <mup> Bug #1702329 changed: Set NTP server for 'timesyncd' <ntp> <MAAS:Incomplete> <https://launchpad.net/bugs/1702329>
[23:22] <roaksoax> exodusftw: devices dont have power parameters
[23:22] <roaksoax> exodusftw: and yes, it is a PITA to keep documentation when there's so much movement
[23:22] <roaksoax> exodusftw: pmatulis should know :)


[03:24] <tgm4883> Do previews no longer support a URL for the thumbnail_uri?
[05:32] <smspillaz> duflu: heya, do you want a fix for a stacking bug before we cut 0.9.9 or do you want to wait till next year ?
[05:33] <duflu> smspillaz: Pretend I never mentioned <IP_ADDRESS>. The dust has to settle and there be a stabilization period before such a tag
[05:33] <duflu> So not this week anyway
[05:33] <smspillaz> duflu: that won't really happen unless we say that a stabilization period has begun :)
[05:33] <smspillaz> duflu: so ... do you want a stacking fix or should it wait ?
[05:34] <duflu> smspillaz: No, just finish the keybinding and nvidia issues I think
[05:34] <smspillaz> duflu: ok, well the nvidia thing is more or less done
[05:34] <smspillaz> resizing windows is something else we can look at, but that's a can of worms IMO because it would involve redesigning the decor protocol
[05:34] <smspillaz> that's the main slow part
[05:34] <duflu> smspillaz: I have not seen any work on on the resize problem, so not done. But possibly simple to fix
[05:35] <smspillaz> duflu: nah, its going to be complicated
[05:35] <duflu> smspillaz: I doubt it. There's no reason to query the shape for every non-shaped window. That's the main problem
[05:35] <smspillaz> duflu: a "simple" fix if you wanted one would be to simply not update the decorations while the window is being resized
[05:35] <smspillaz> duflu: well, the biggest hit is that we do XGetWindowProeprty per-size-increment
[05:36] <smspillaz> I think not querying the shape might help a little, but not a lot
[05:36] <duflu> smspillaz: Well in my testing it always hangs in the XSync, and after that the XShareGetRectangles
[05:36] <duflu> And removing those made a big difference
[05:36] <duflu> Compiz is a bit buggy if you don't let it use XShape. That might be a bigger problem
[05:38] <duflu> smspillaz: Anyway, pretend I'm not here for the rest of the week. I have enough commitments to management to complete before vacation without spending days on such things
[05:38] <smspillaz> duflu: ok. In any case, the stacking fix is ready to go, and I think it fixes one of this biggest problems we had with it
[05:38] <smspillaz> so if you want it, its there, just give me the word
[05:39] <duflu> No really. Not interested myself. :)
[05:39] <duflu> +t
[05:39] <smspillaz> ok
[05:39] <smspillaz> duflu: I'll get some stuff together for the new year then, looking at resize perf and other things
[05:40] <smspillaz> duflu: I have an experimental branch to support GLX_EXT_buffer_age too, which will help with fbo performance as soon as the drivers support it
[05:40] <duflu> smspillaz: XShape be gone!
[05:40] <duflu> (where possible)
[05:40] <smspillaz> ok, I'll look into it
[05:40] <smspillaz> thanks
[05:41] <duflu> smspillaz: I found the same problem with hanging on intel graphics (Atom) but did not check the stack to verify the same place
[05:42] <smspillaz> duflu: well, my understanding is that resizing is slow in two places. 1. is the xshape thing, 2. is updating the decor pixmap every single time the window gets a new size
[05:42] <duflu> smspillaz: Actually, yeah. I don't remember a test in which it was fast with decor still loaded. But while it was the primary issue was that XShape call
[05:43] <smspillaz> you can sort-of optimize 2. by only fetching a new pixmap every time the window gets bigger, and then just re-using the last largest one when resizing the window to be smaller. It looks a little weird but is much faster
[05:43] <smspillaz> I have an experimental thing somewhere which did that
[05:43] <smspillaz> but the xshape thing is worth looking at
[05:44] <smspillaz> duflu: in any case, lets stabilize 0.9.9 from this point onwards, and only look at new stuff once we've released it
[05:44] <duflu> smspillaz: Try scripting up a delayed stack trace to fire off while the screen is frozen, if you haven't already
[05:45] <duflu> You'll find the results are very consistent
[07:04] <didrocks> hey Mirv!
[07:04] <didrocks> so I looked at the compiz precise branch
[07:05] <didrocks> it seems you didn't base on the packaging branch (it was still debian/ only, remember?). It was up to date on ~ubuntu-desktop/compiz/precise
[07:05] <didrocks> oh, it's the quantal one, forgot that one
[07:05] <didrocks> however:
[07:05] <didrocks> * we did decide to only include unredirect fixes, it seems there are some additional for the grid, isn't it?
[07:06] <didrocks> * for enabling it by default, did you try to upgrade on one of your quantal machine and ensure it was picking up the new gsettings default value? (on a machine where you never changed it?)
[08:19] <duflu> smspillaz: Let me know if you're available to fix the segfault I just assigned you. If not I will...
[08:29] <didrocks> sil2100: hey!
[08:29] <didrocks> how are you?
[08:40] <sil2100> didrocks: hello!
[08:40] <sil2100> didrocks: fine, thanks - and you? I'm rebuilding compiz, testing the fix with the fixed python packages
[08:40] <sil2100> So far so good!
[08:41] <didrocks> sil2100: excellent! I'm good as well, thanks :) And thanks again for fixing it :)
[08:41] <sil2100> np! :)
[08:43] <sil2100> didrocks: you think it's safe to self-approve?
[08:44] <sil2100> didrocks: since the compiz build succeeded
[08:44] <didrocks> sil2100: it seems that duflu approved already :)
[08:44] <didrocks> sil2100: but yeah, I was fine otherwise with self-approving ;)
[08:45] <sil2100> Oh, hehe, indeed
[08:45] <sil2100> duflu: thanks for testing and approving!
[08:45] <hyperair> didrocks: speaking of the unredirect fixes, what exactly do they fix?
[08:45] <duflu> sil2100: No testing on that one. It's right in theory and if there's a mistake then Jenkins will find it
[08:46] <didrocks> hyperair: fullscreen opengl apps framerate
[08:46] <didrocks> hyperair: compiz won't touch it automatically
[08:46]  * hyperair is running unity from the something sru ppa
[08:46] <hyperair> didrocks: wasn't it working before?
[08:46] <didrocks> hyperair: compiz was handling the windows
[08:46] <hyperair> how do you tell if a window is being unredirected properly (besides looking at the frame rate)?
[08:46] <didrocks> hum? the fix is about unredirect them or not automatically
[08:46] <hyperair> didrocks: i mean i manually flipped that setting using ccsm. did it not work before?
[08:46] <didrocks> that's it
[08:47] <didrocks> hyperair: well, it's manual, not automatic for some reason
[08:47] <hyperair> er
[08:47] <didrocks> like driver crashes and more fixes needed
[08:47] <hyperair> ah.
[08:47] <didrocks> so the fixes are getting in
[08:47] <hyperair> so basically you couldn't turn it on by default because there were driver crashes?
[08:47] <didrocks> and we'll switch it on by default
[08:47] <didrocks> yep
[08:47] <hyperair> i see.
[08:47] <hyperair> i had it on already on snb, so i guess that worked..
[08:48] <didrocks> you would have known really quickly if it didn't :)
[08:48] <hyperair> how so?
[08:48] <didrocks> like exiting the fullscreen opengl app -> crash :)
[08:48] <hyperair> hmm.
[08:48] <hyperair> but what if compiz doesn't successfully unredirect the app?
[08:48] <hyperair> does that happen?
[08:48] <didrocks> I don't think so, duflu can answer
[08:49] <didrocks> but you can check with the framerate :)
[08:49] <hyperair> eh well it's really hard to tell with team fortress 2
[08:49] <hyperair> it lags all the time anyway
[08:49] <didrocks> :)
[08:49] <hyperair> it's hard to tell whether it's lagging more or less
[08:49] <hyperair> it depends on the number of bots running around in the map too
[08:50] <hyperair> one thing i did notice -- when i turn on the unredirect full screen windows setting, alt-tabbing out and alt-tabbing back in results in a frozen image
[08:50] <hyperair> it's like it takes 1-2 minutes for team fortress 2 to notice that it's been unredirected.
[08:50] <didrocks> not sure, maybe duflu would know about it, I didn't have time to play with the setting
[08:50] <hyperair> okay
[09:03] <duflu> hyperair: Alt-tab freezes are mostly fixed in compiz <IP_ADDRESS>, with an extra fix in <IP_ADDRESS>. Also, if you're using the fglrx or nouveau drivers then they cause such freezes sometimes too
[09:07] <hyperair> duflu: it's snb.
[09:07] <hyperair> sandy bridge
[09:07] <hyperair> hmm, i'm running <IP_ADDRESS>, and the freeze is present.
[09:07] <hyperair> it takes around 2 minutes for tf2 to "notice" the unredirection and start drawing an image again, weirdly enough.
[09:08] <didrocks> sil2100: do you know if Mirv is working today? I pinged him 2 hours ago
[09:09] <duflu> hyperair: Sounds like bug 1084401 if you're alt-tabbing to a window on another workspace. But even if not then it could still be the same bug.
[09:10] <hyperair> duflu: that doesn't quite sound like it. i don't have issues alt-tabbing away. i have issues alt-tabbing back into the game.
[09:11] <hyperair> duflu: after i alt-tab into the game, it shows the screen, and you can click on things in the game and interact with things, but the image doesn't refresh
[09:11] <hyperair> so you can hear stuff like button hover effects
[09:11] <hyperair> and if you alt-tab out and alt-tab back in again, the image refreshes.
[09:11] <hyperair> but you don't actually get a live image until you sit with the game in foreground and wait for ~2 minutes.
[09:11] <duflu> hyperair: I'll test it but if it's a problem then you should disable unredirection in CCSM>Composite for now
[09:12] <hyperair> hmm
[09:14] <sil2100> didrocks: I would think he is, but let me double check that
[09:14] <didrocks> thanks :)
[09:16] <popey> didrocks, he sometimes has to go afk downstairs to do multi-monitor testing with his TV :)
[09:16] <didrocks> ok ;) 2 hours, it's a long film! :-)
[09:16] <popey> haha
[09:16] <duflu> EXPECT_TRUE (popcorn)
[09:16] <didrocks> ;)
[09:17] <duflu> hyperair: You mean you're using Sandy Bridge graphics and not just the CPU, right? :)
[09:18] <duflu> hyperair: Also, what Ubuntu version and/or Mesa version?
[09:18] <Mirv> didrocks: hi, sorry, didn't look at freenode side at all
[09:19] <hyperair> duflu: yes.
[09:19] <hyperair> duflu: 12.10, mesa from xorg-edgers
[09:19] <hyperair> OpenGL renderer string: Mesa DRI Intel(R) Sandybridge Mobile
[09:19] <hyperair> OpenGL version string: 3.0 Mesa 9.1-devel
[09:19] <duflu> hyperair: We have countless bugs with xorg-edgers. Please test with regular quantal Mesa 9.0 too
[09:20] <didrocks> Mirv: I'll let you backlog
[09:20] <Mirv> didrocks: so quantal indeed. the final <IP_ADDRESS> included the two grid related commits, aside from that it's only unredirect. I thought grid plugin can be tested at the same time.
[09:20] <Mirv> didrocks: and sure, the new default was also tested and various people have reported back on having speedups and also reported on the tearing problems which were then worked upon
[09:21] <didrocks> Mirv: by tested, I meant:
[09:21] <didrocks> they have an old default configuration
[09:21] <didrocks> added the new one
[09:21] <duflu> Mirv: You squeezed the fix for bug 1084401 into your <IP_ADDRESS> didn't you?
[09:21] <didrocks> and the switch is one?
[09:21] <didrocks> on*
[09:22] <didrocks> (without having to play in ccsm)
[09:22] <Mirv> duflu: yes, and the tearing blacklists
[09:22] <duflu> didrocks, Mirv: FYI I am aiming to have unredirect on by default for precise in <IP_ADDRESS>
[09:22] <Mirv> didrocks: and yes, it switches it if default is in use
[09:22] <hyperair> duflu: i did have issues with it, that's why i went and upgraded to xorg-edgers.
[09:23] <Mirv> didrocks: so tested in both guest session and a normal user
[09:23] <duflu> hyperair: We have lots of bugs with xorg-edgers but I have not encountered such a hang with 9.0 on Sandy Bridge quite like yours yet. Please log "ubuntu-bug compiz" so we don't forget your issue
[09:24] <hyperair> okay
[09:24] <hyperair> i'll ppa-purge later and check again
[09:24] <hyperair> duflu: do i have to downgrade my kernel as well?
[09:24] <duflu> hyperair: Unfortunately, yes. We can't provide effective support unless you at least test with vanilla versions
[09:24] <didrocks> Mirv: excellent, ok, it's a little bit different than the initial planning as I only wanted unredirect by default, but let's try that
[09:25] <didrocks> thanks duflu, do you have anything more? like crashes in driver?
[09:25] <hyperair> hmm okay.
[09:25] <duflu> didrocks: I have lots of unredirect issues. For quantal aim to have it all resolved in <IP_ADDRESS>, and precise <IP_ADDRESS>
[09:25]  * popey has crashes in precise with unredirected :(
[09:25] <popey> but you know about those
[09:26] <duflu> popey: Your driver will soon be blacklisted because Bryce can't yet figure out what Mesa fixes it needs
[09:26] <popey> "awesome"
[09:26] <popey> :)
[09:26] <hyperair> duflu: is SNA enabled or disabled in stock ubuntu?
[09:26] <hyperair> quantal i mean.
[09:27] <duflu> hyperair: Not sure. I thought it was off. Is there an easy check?
[09:27] <hyperair> check Xorg.0.log
[09:27] <hyperair> there's a mention of it
[09:27] <hyperair> just grep -i sna
[09:27] <duflu> hyperair: No mention. I suspect it's not compiled into quantal (still)
[09:27] <didrocks> duflu: do you have a list somewhere of the remaining precise compiz unredirect issues?
[09:27] <hyperair> i see.
[09:28] <hyperair> i recall there being a regression in xorg-edgers when sna got flipped off, and at the same time tf2 fixed itself. i should try testing with sna off to see how that fares
[09:29] <duflu> didrocks: https://bugs.launchpad.net/compiz/+bugs?field.tag=unredirect for compiz bugs. The driver bugs I don't have a reliable filter for right now. Just assume nouveau and intel are bad on precise. They will be automatically blacklisted in <IP_ADDRESS>
[09:29] <Mirv> didrocks: thanks.
[09:29] <didrocks> duflu: ok, thanks for the head's up
[09:30] <didrocks> duflu: I guess you work with RAOF and bryce on the driver side?
[09:30] <didrocks> for intel and nouveau?
[09:30] <didrocks> (especially intel)
[09:30] <Mirv> bryce has been cc:d in all discussions
[09:31] <Mirv> hyperair: yes SNA is still not enabled even in raring, although probably it'd be considered during the cycle given the benefits and the time it has now been maturing (and mostly the only thing getting new work done)
[09:32] <hyperair> Mirv: i noticed rc6 residency is a lot better with sna than without
[09:34] <duflu> hyperair: residency? You mean it sticks to rc6 more of the time with SNA?
[09:34] <Mirv> I used to have regressions on i915 / GMA 3100 (integrated into Atom N470), but now I think SNA has been playing fine also on my netbook.. and on my 965G (GMA X3000) machine, everything seems fine
[09:35] <hyperair> duflu: yes. a lot more.
[09:35] <duflu> hyperair: Exciting, thanks. How are you measuring time spent in rc6 BTW?
[09:35] <hyperair> duflu: powertop reports something like 0-10% RC6pp residency without SNA, but with SNA, it goes up to 60-80% when compiz is idling.
[09:35] <hyperair> duflu: the second tab of powertop
[09:36] <duflu> Thought so.
[09:36] <duflu> Cool
[09:36] <duflu> (literally)
[09:36] <hyperair> hahaha
[09:36] <hyperair> yes, there's a significant temperature difference when rc6 comes into play.
[09:36] <hyperair> when the kernel disabled rc6 by default, i noticed a 10°C jump in idle temperature
[09:36] <duflu> Hmm, I wonder if that's the big change in raring. I noticed my Sandy Bridge laptop getting much better power usage in raring than quantal
[09:37] <hyperair> it could be
[09:37] <Mirv> but, I still have this one regression on sandy bridge where in Unity/compiz the inactive window title bar decoration is drawn wrongly
[09:37]  * duflu covers ears
[09:37] <didrocks> mmrazik: not sure if your utf8 fix worked: https://code.launchpad.net/~didrocks/ubuntu-wallpapers/bootstrap/+merge/139400
[09:37] <didrocks> or is the queue just crowded?
[09:38]  * Mirv files bug
[09:42] <Mirv> duflu: FYI it might be interesting also for you to see how it's drawn incorrectly on SNA https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/1089269/+attachment/3458107/+files/inactivewindowtitlebar.png
[09:43] <Mirv> duflu: rc6 has been enabled by default in Ubuntu kernels since precise, and SNA is still not enabled by default (except for xorg-edgers)
[09:44] <duflu> Mirv: Yeah I know
[09:45] <hyperair> Mirv: weird, i don't get that here.
[09:49] <didrocks> Mirv: looking good and working fine here, sponsoring to quantal-proposed! Thanks :) FYI, I pushed the branch as we discussed last time to ~ubuntu-desktop/compiz/quantal
[09:54] <Mirv> didrocks: thanks a lot, and yes I remember. let's see how long it takes to spend in the queue.
[09:54] <didrocks> Mirv: want to bet on that? :p
[09:58] <Mirv> no bets, but I hope for slightly faster turnaround than with the last updates when queue just kept queueing more
[10:34] <didrocks> hey JohnLea! do you have a minute to discuss about wallpaper?
[10:34] <JohnLea> didrocks; good timing, fire away?
[10:34] <JohnLea> ignore the '?@
[10:34] <JohnLea> can't type this morning again ;-)
[10:35] <didrocks> heh, so reading https://bugs.launchpad.net/ayatana-design/+bug/1081702 I think people are right about compression quality
[10:35] <didrocks> JohnLea: as we don't have the CD size limit, can we envision have lower compression? even maybe none at all with loseless png?
[10:36] <JohnLea> didrocks; are we no longer space limited then?  There is also one other problem we are solving with the noise however, on cheep monitors you get 'colour banding' that the noise fixes, this isn't a problem on high quality monitors
[10:37] <JohnLea> didrocks; I'll speak to Otto and see what he says
[10:37] <didrocks> JohnLea: ah, so maybe it's linked, indeed :)
[10:37] <didrocks> JohnLea: ok, keep me posted, I'm not pushing before that
[10:37] <didrocks> thanks!
[10:37] <JohnLea> didrocks; will do, thx!
[10:37] <didrocks> yw ;)
[10:40] <JohnLea> didrocks; can we use .png as wallpapers?
[10:40] <didrocks> JohnLea: you can encode in png, just leave the filename the same
[10:42] <didrocks> it's already a filename containing .png btw
[10:42] <didrocks> JohnLea: if you want to test on your system, just replace /usr/share/backgrounds/warty-final-ubuntu.png with your file
[10:42] <didrocks> fail :)
[10:43] <didrocks> 11:40:35   JohnLea | didrocks; can we use .png as wallpapers?
[10:43] <didrocks> 11:40:52  didrocks | JohnLea: you can encode in png, just leave the filename the same
[10:43] <didrocks> 11:42:01  didrocks | it's already a filename containing .png btw
[10:43] <didrocks> 11:42:12  didrocks | JohnLea: if you want to test on your system, just replace /usr/share/backgrounds/warty-final-ubuntu.png with your file
[10:43] <JohnLea> didrocks; thx for re-posting
[10:44] <didrocks> yw! :)
[10:55] <mmrazik> didrocks: srry. I was on a phone...
[10:55] <didrocks> no worry :)
[11:01] <sil2100> JohnLea: I assigned the design team to 2 bugs
[11:02] <sil2100> https://bugs.launchpad.net/unity/+bug/1076424
[11:02] <sil2100> https://bugs.launchpad.net/unity/+bug/1089258
[11:06] <JohnLea> didrocks; bug #1081702 updated with the non-compressed wallpaper.  I have tested it on my computer and it works well.
[11:06] <didrocks> sweet, let me look at the size :)
[11:06] <JohnLea> sil2100; looking at them now
[11:07] <JohnLea> didrocks; 5.5MB
[11:07] <didrocks> JohnLea: did you notice any slowliness?
[11:07] <didrocks> like login time?
[11:07] <didrocks> JohnLea: I would appreciate a middle-ground if possible :)
[11:07] <didrocks> not going like 10x bigger
[11:08] <didrocks> (wondering about the speed on a hard drive)
[11:09] <sil2100> JohnLea: thanks! :)
[11:09] <JohnLea> didrocks; I was soo stunned by the improved quality of the background, that all other thoughts and considerations faded into meaningless
[11:09] <JohnLea> ;-)
[11:10] <didrocks> JohnLea: ahah! I can see that ;) do you think you can find this middle-ground between quality and size?
[11:11] <JohnLea> didrocks; I'll ask Otto, he is in a meeting atm, will have to grab him later.  But I know this image is hard to compress because the noise which is added to fix banding makes compression harder.
[11:11] <didrocks> keep me posted :)
[11:17] <didrocks> mmrazik|lunch: hum, I then didn't see your answer on the wallpaper stalled merge :)
[11:52] <JohnLea> didrocks; hyia, just spoke to Otto, he said that if possible it would be much better to use the 5.5MB png image I uploaded, because making it any smaller will require changing to .jpg compression that *will* introduce artefacts even at low levels of compression
[11:53] <didrocks> JohnLea: I'm a little bit worrying about reading that and effects on boot time
[11:53] <didrocks> JohnLea: can we try to first have a 2Mb image, put that for now, then, when the benchmarking is there, we can try to switch to it?
[11:53] <JohnLea> didrocks; can we quantify that?  also is their any gain to offset the increased read time as a result of not having to decompress a .jpg?
[11:53] <didrocks> and mesure :)
[11:54] <didrocks> JohnLea: not right now, well, decompression of a .jpg file is not an issue as it's handled by the gpu nowadays natively
[11:54] <JohnLea> didrocks; or put the 5.5MB image in, and then see the effect?  we can always revert if people complain
[11:54] <didrocks> so it's more quicker to pass small amount of data AFAIK :)
[11:54] <didrocks> JohnLea: well, we don't do that anymore in ubuntu, breaking and seeing the feedback :)
[11:55] <didrocks> otherwise, I'll just put the 700 kb if there is no way to have a middle-sized image
[11:58] <JohnLea> didrocks; the question is 'what is the impact of a 5.5BM image versus a 2MB image on boot time' and how does the cost of this balance against 'a high quality background with no compression artefacts versus some background compression artefacts'.  My vote is that for example a less than 1 second increase in boot time is a worthwhile price for a better fidelity background, but I know others may have other opinions ;-)
[11:58] <JohnLea> more than 1 sec increase in boot time is not worth the cost IMHO
[11:59] <didrocks> JohnLea: well, you can count 1s of boot time is fine for design, but when you budget is 4s to load the whole desktop, 25% of this time just to load the background is not acceptable
[11:59] <didrocks> JohnLea: so as long as we don't have benchmarks, I would prefer that we don't explode the time on presumption
[12:00] <JohnLea> didrocks; Otto is having a go at making a mid way file now, will see how that goes
[12:00] <JohnLea> didrocks; agreed, difficult to decide without benchmarks
[12:00] <didrocks> JohnLea: yeah, so let's get better for now, without going bindly in one direction :)
[12:46] <solancer> Any c++ devs in the house
[12:46] <solancer> anyone ?
[12:47] <solancer> anyone who can fix this PPA https://launchpad.net/~ikarosdev/+archive/unity-revamped
[12:52] <Mirv> solancer: according to the user page the PPA is maintained by IRC nick ikarosdev or isaacj87, but he's not on this channel
[13:01] <mhr3> JohnLea, could you comment on https://bugs.launchpad.net/unity-lens-music/+bug/972987 ? (it's a quick one) :)
[13:11] <JohnLea> mhr3; does the word "Classical" fit in the button?  If so +1 from me
[13:11]  * mhr3 checks
[13:18] <JohnLea> sil2100; I've attached the new Dash nav bar icons to a bug report for uploading, see bug #1089373  Could you upload these?
[13:25] <sil2100> JohnLea: I'll try creating a merge request after I'm done with lunch - thanks!
[13:27] <mhr3> JohnLea, it fits, can you add your +1 on the bug?
[13:28] <didrocks> mhr3: can you try to grab existing translations to not break them, please?
[13:28] <mhr3> didrocks, i'm doing it now so translators have enough time
[13:28] <mhr3> and we don't have the translations upstream
[13:29] <didrocks> mhr3: well, it's better to grab and keep current translations right now
[13:29] <didrocks> mhr3: that's something which can be fixed :)
[13:29] <mhr3> i had a feeling it was desired
[13:29] <didrocks> mhr3: I think it would be nice to the whole translator community to not break that
[13:32] <mhr3> didrocks, so what do you want me to do exactly?
[13:34] <didrocks> mhr3: maybe do the change, and let's keep an eye on it, right?
[13:34] <JohnLea> sil2100; thx!
[13:34] <didrocks> mhr3: if we don't see that many translations coming by the end of the cycle, we can steal from them
[13:34] <didrocks> wdyt?
[13:34] <JohnLea> mhr3; already added +1 to https://bugs.launchpad.net/unity-lens-music/+bug/972987
[13:35] <mhr3> didrocks, it's conflicted anyway, will give the author some time to fix it
[13:35] <didrocks> we'll see :)
[13:36] <mhr3> JohnLea, thx
[13:47] <solancer> Unity-Revamp PPA is not working any solutions ?
[13:48] <didrocks> solancer: you already asked here and Mirv answered you
[13:48] <didrocks> this is not an official ppa
[13:48] <didrocks> and you should ping the maintainers that are not on that IRC it seems
[13:48] <didrocks> sil2100: seems your compiz fix failed: https://launchpadlibrarian.net/125569887/buildlog_ubuntu-quantal-i386.compiz_1%3A0.9.9~daily12.12.05bzr3524pkg0quantal0_BUILDING.txt.gz
[13:48] <didrocks> :(
[13:49] <solancer> oh I din't see that
[13:49] <solancer> sorry
[13:49] <didrocks> sil2100: oh it did work!  * State: Failed to upload
[13:49] <solancer> my question was if there was a way to clone the PPA and work on it
[13:49] <didrocks> sil2100: sorry, was trapped by the email :)
[13:49] <didrocks> solancer: you can add the deb-src in your source file
[13:49] <didrocks> and apt-get source from it
[13:50] <didrocks> you will get the code that way :)
[13:50] <solancer> oh no I'm not gud with C++ I'm more of a python guy
[13:51] <solancer> I was looking for someone who could do work on the PPA
[13:51] <didrocks> solancer: ok, not sure who apart from the maintainers of this PPA is working on it, but here, you have more the upstream guys, making unity in ubuntu, no tweaked changes :)
[13:51] <mmrazik> didrocks: is the "Fix Committed" for the Autopilot task here a bug?
[13:51] <mmrazik> https://bugs.launchpad.net/autopilot/+bug/1067161
[13:52] <mmrazik> shouldn't it be Fix Released?
[13:52] <didrocks> mmrazik: not really, so this is a discussion I should open after the end of years holidays
[13:52] <solancer> didrocks, oh I see
[13:52] <mmrazik> didrocks: okay :)
[13:52] <didrocks> mmrazik: there is a debate if the autoupload should only close downstream bugs or should close the upstream ones
[13:52] <mmrazik> didrocks: I was just asked by thomi yesterday
[13:52] <mmrazik> fginther: ^^^
[13:52] <didrocks> mmrazik: I have no strong opinion either way :)
[13:52] <solancer> didrocks, where can I discuss this topic ?
[13:53] <didrocks> solancer: no idea, try to reach/contact the maintainers that Mirv pointed out first
[13:54] <solancer> didrocks, I did but the guy never replied back, looks like he's on vacation or something
[13:54] <solancer> didrocks, thanks for your help I try looking into the code and see if I can't find a hack
[13:54] <solancer> didrocks, nice talking to you
[14:04] <fginther> mmrazik, didrocks thanks
[14:18] <mterry> fginther, hello!  Are you aware that we forgot about libunity-misc in the last round of inlining?  I have an inline-packaging branch, but I didn't want to set it to approved until the landing job is adjusted for it
[14:18] <fginther> mterry, please point me to the merge proposal and I'll get it set up
[14:19] <didrocks> thanks mterry, fginther :)
[14:19] <didrocks> mterry: how was your day off?
[14:25] <mterry> fginther, thanks: https://code.launchpad.net/~mterry/libunity-misc/inline/+merge/139110
[14:25] <mterry> didrocks, fine!  Hung out with some friends
[14:26] <didrocks> mterry: sweet! :) you missed again the fun with python breaking compiz ;-)
[14:26] <mterry> didrocks, perfectly planned then  :)
[14:26] <mterry> didrocks, what happened?
[14:26] <didrocks> indeed, you have a gift I guess!
[14:26]  * mterry is still reading emails
[14:27] <didrocks> oh, it's not on emails, it's just that they multiarched one file
[14:27] <didrocks> and they broke a few project using the direct path for including it, some indicators, compiz, and apparently firefox
[14:27] <didrocks> but sil2100 pushed a fix :)
[14:28] <didrocks> mterry: once you would have finished with your catch up, can you sanitize the hud project to follow the same packaging than the rest? bootstrapping and so on…
[14:28] <didrocks> also, https://launchpad.net/testapp if you have time
[14:28] <mterry> didrocks, yup, still got that on my TODO
[14:28] <mterry> didrocks, testapp?
[14:29] <didrocks> mterry: yeah, apparently, autopilot needs it to run some of the tests from unity
[14:29] <mterry> didrocks, seems poorly named....
[14:29] <didrocks> mterry: and finally, I know that cyphermox is stricking in 4 projects to have the tests running in a chroot, would be nice if you can give a hand
[14:29] <didrocks> mterry: do you sometimes overlap with thomi?
[14:30] <didrocks> he's just living at the opposite side of the world and my 12 hours of daily presence is missing him :)
[14:30] <didrocks> I would agree it should be renamed
[14:30] <mterry> didrocks, I haven't noticed
[14:30] <mterry> cyphermox, heyo!  Poke me when you get a chance if I can help with the chroot projects
[14:30] <didrocks> mterry: well, try to catch him in your evening if you can (there is no hurry on this one)
[14:30] <mterry> didrocks, what's this about?
[14:30] <didrocks> mterry: oh, the testapp naming :)
[14:30] <didrocks> he's the upstream
[14:31] <mterry> didrocks, ah ok
[14:31] <didrocks> mterry: FYI I know that cyphermox is sick today, so maybe not really reponsive :)
[14:31] <didrocks> that's it for you, I'll let you go back to your catchup! Thanks a lot mterry :)
[14:31] <mterry> didrocks, OK, I'll lie in wait for him
[14:32] <didrocks> sounds good :)
[14:32] <didrocks> unico powerpc finally built \o/
[14:32] <mterry> didrocks, now that I'm subscribed to unity bugs and merges, catchup takes so much longer.  Though I realize I'm whining to the wrong person here
[14:32] <didrocks> mterry: if you only saw what was the frequency of bugs and merges just a year ago… :)
[14:33] <didrocks> it's really quiet, you should enjoy it! :-)
[14:37] <JohnLea> sil2100; Matthieu has just added a updated icon for the Gwibber Lens to bug #1089373     Did you see how quickly this was posted by omg!
[14:38] <didrocks> JohnLea: btw, did you find anything for the wallpaper?
[14:38] <JohnLea> they wrote a story about it only 15min after I posted the bug!
[14:38] <sil2100> JohnLea: ACK ;)
[14:38] <sil2100> hohoho
[14:38] <sil2100> Nice
[14:38] <didrocks> sil2100: ignoring my messages about the test results? I'm not sure if it's a ack or nack :p
[14:39] <JohnLea> didrocks; not yet, otto's has been at lunch and in meetings, will try to grab him when he gets back
[14:39] <didrocks> JohnLea: ok, let's try to do that before christmas holidays :)
[14:39] <didrocks> JohnLea: and I won't push that on Friday! :p
[14:39] <JohnLea> didrocks; I want to try to get it over to you today
[14:39] <didrocks> JohnLea: that would be awesome!
[14:44] <seb128> sil2100, hey
[14:51] <didrocks> mterry: oh btw, for everything that could use a test, please note them on http://pad.ubuntu.com/ubuntu-unity
[14:51] <didrocks> that's easier to track then :)
[14:51] <mterry> ah right
[14:51] <didrocks> thanks ;)
[15:07] <sil2100> didrocks: wait wait!
[15:07] <sil2100> didrocks: I'm working on the autopilot test failures, which in fact cause closing of all my terminals
[15:07] <sil2100> So I didn't see what's going on on my screen's, sorry about that ;)
[15:07] <sil2100> Let me read up what's going on
[15:07] <didrocks> sil2100: ahah, that's not a funny bug :)
[15:08] <sil2100> It's due to me using self.start_app instead of self.start_app_window ;p
[15:08] <sil2100> seb128: hi!
[15:09] <sil2100> didrocks: hm, what test results do you have in mind exactly? It seems I would have to backtrack a lot to get to it!
[15:09] <seb128> sil2100, hey, we were wondering if you were receiving IRC pings or not ;-)
[15:10] <sil2100> seb128: sorry about that, damn that autopilot clean-up code!
[15:10] <seb128> sil2100, no worry ;-)
[15:16] <didrocks> sil2100: the one I pointed to you:
[15:16] <didrocks> http://dc-jenkins:8080/job/ps-indicators-autopilot-release-testing/28/testReport/
[15:16] <sil2100> Aaaaaaaah
[15:16] <sil2100> Ok, sorry, I'm working on those just now ;)
[15:17] <sil2100> hehe, man, I think hm, I was a bit confused and just didn't register your question correctly ;p
[15:17] <didrocks> sil2100: oh, you just didn't answer me, hence I was wondering :)
[15:17] <sil2100> didrocks: ok, so a few tests are a bit unsafely written, which I am modifying a bit so that the failures won't happen gladly
[15:17] <didrocks> sil2100: excellent, keep me posted! :)
[15:18] <didrocks> excellent ;)
[15:18] <didrocks> hence the flackyness?
[15:18] <sil2100> Most likely yes
[15:19] <fginther> sil2100, I can spare some cycles if you need me to look at some of those failures
[15:22] <fginther> mterry, libunity-misc is ready to autoland. I'll keep an eye on it in case it fails
[15:23] <mmrazik> fginther: btw. it looks like jenkins has (again) issues picking up new jobs/configs (long queue). Not sure if its because something got stuck or it naturally grows now
[15:23] <mterry> fginther, awesome, thanks
[15:23] <mmrazik> fginther: I was triggering some autolandings manually today with the trigger-autolanding job
[15:23] <fginther> mmrazik, :-( I'll trigger this one as well
[15:39] <didrocks> fginther: it seems unity-merger picked it up first
[15:39] <didrocks> fginther: maybe it's still configured for libunity-misc :)
[15:40] <fginther> didrocks, I also noticed that and disabled it :-). I had completely forgot about that
[15:40] <didrocks> ok ;)
[15:50] <mhr3> mterry, ping?
[15:52] <mterry> mhr3, hello
[15:53] <mhr3> mterry, hey, re https://code.launchpad.net/~mterry/unity-lens-music/valac-0.18/+merge/139037 could you revert the m4 changes? i don't think it makes sense to change the behaviour for a single lens, if there was a standard macro that did this, it'd be awesome but this just adds to confusion imo
[15:54] <mhr3> plus one can just do `./configure VALAC=/usr/bin/valac-0.18`
[15:54] <popey> didrocks, bug 1060543  . what's that waiting for?
[15:55] <popey> needs to go to raring first?
[15:55] <mterry> mhr3, sure, for this simple case.  I use that macro in a lot of packages though, and sometimes you want to prefer say 0.16, allow 0.18, and fallback to unversioned.  But sure.  I can revert the m4 change and manually specify it in the rules file instead
[15:56] <mhr3> mterry, as upstream i can promise we'll support latest stable vala ;)
[15:58] <mhr3> although with warnings from time to time :)
[16:03] <didrocks> popey: a release?
[16:06] <didrocks> popey: if you don't see one past this holidays period, just ping me back
[16:07] <popey> didrocks, ok thanks
[16:07] <popey> just seeing people complaining that searching for "drivers" gets them golf clubs
[16:07] <popey> which is sub-optimal :)
[16:08] <didrocks> ahah, really?
[16:08] <didrocks> awesome!
[16:13] <mterry> mhr3, branch updated
[16:15] <mhr3> mterry, thx, approved
[16:17] <mterry> didrocks, did you want me to keep an eye on the hud package going forward?  (i.e. add it to my list of cared-for-packages)
[16:17] <didrocks> mterry: it's more on cyphermox's plate I guess, but as it's cross stack, one more isn't bad :)
[16:17] <mterry> k
[16:18] <mterry> wait, I don't follow
[16:18] <mterry> You want us both to look at it?
[16:18] <mterry> didrocks, or I guess I'm reading that as me
[16:19] <didrocks> mterry: no the "one more" is that, if you can double check this one in particular
[16:19] <didrocks> as it's going to a lot of changes in the coming days (as most of the code is moving for indicator-appmenu), it's good to be more than one looking at it
[16:19] <didrocks> then, on a maintenance base, cyphermox alone should be enough :)
[16:20] <mterry> didrocks, gotcha
[16:20] <didrocks> thanks :)
[16:20] <mterry> didrocks, what about testapp?
[16:21] <didrocks> mterry: will be on cyphermox's plate for sure
[16:21] <mterry> who owns autopilot?
[16:21] <mterry> ok
[16:21] <didrocks> "misc" stack
[16:53] <didrocks> JohnLea: I guess there will be no new wallpaper today?
[16:55] <sil2100> didrocks: besides the badly written autopilot tests, we were able to find a regression as well \o/
[16:55] <sil2100> https://bugs.launchpad.net/unity/+bug/1089482
[16:55] <sil2100> Confirmed with trunk on both raring and quantal
[16:55] <didrocks> sil2100: excellent \o/ this is useful as well! :)
[16:55] <didrocks> sil2100: and you are writing/fixing a test for it? :)
[16:57] <sil2100> No, I fixed another test, this AP test was actually working correctly ;) And failing as it should!
[16:58] <didrocks> ahah ;)
[17:01] <JohnLea> didrocks; I have a new wallpaper for you, 2.1MB ;-) https://bugs.launchpad.net/ayatana-design/+bug/1081702
[17:02] <didrocks> JohnLea: sweetness!
[17:02] <JohnLea> didrocks; skype?
[17:03] <didrocks> JohnLea: mumble or hangout, my skype setup doesn't really work
[17:08] <mterry> tedg, why does the hud install hud-service in the indicator-appmenu location?
[17:09] <mterry> tedg, (are there hardcoded paths to it outside of the service file?)
[17:09] <tedg> mterry, hud package?
[17:09] <tedg> mterry, Or the indicator-appmenu package?
[17:09] <mterry> tedg, yeah in the new hud split package
[17:09] <tedg> mterry, Uhm, bug.  I thought I'd fixed it though...
[17:10] <mterry> tedg, oh maybe you have in a separate branch, but not in trunk.  OK
[17:10] <mterry> tedg, I'm working on a branch to have the packaging do the same stuff as the rest of PS packages (dh9 etc)
[17:11] <tedg> mterry, ?  Trunk is dh 9 for me.
[17:11] <mterry> tedg, fascinating...
[17:11] <tedg> mterry, bzr branch lp:hud ?
[17:11] <mterry> tedg, ah...  you mean you depend on dh9, but you didn't bump compat
[17:11] <mterry> doesn't do much good without bumping compat
[17:12] <tedg> Oh, oops.
[17:12] <tedg> mterry, But yeah, the hud service is a libexec program.
[17:12] <tedg> mterry, It shouldn't be in indicator-appmenu.
[17:13] <tedg> Oh, the install file is moving it.
[17:13] <tedg> Weird
[17:13] <mterry> tedg, yup.  it was just installing into /usr/lib/indicator-appmenu and I thought it was for compatiility reasons
[17:13] <tedg> I must have looked through the code and forgot to change that line twice.
[17:13] <mterry> OK.  no biggie, I can fix in my branch
[17:59] <didrocks> fginther: is this one merging? https://code.launchpad.net/~didrocks/ubuntu-wallpapers/raring-wallpaper/+merge/139517
[20:30] <mterry> alesage, https://jenkins.qa.ubuntu.com/job/testapp-ci/build=pbuilder,distribution=quantal,flavor=amd64/7/console
[20:30] <mterry> alesage, fails during 'archiving the artifacts'
[20:30] <mterry> alesage, looks coverity related.  Do I need to do something to fix coverity for this branch?
[20:31] <alesage> mterry this has to do with finding JUnit-type test results, simply untick that box in the config
[20:31] <alesage> if this is mmrazik template job, both JUnit test reporting and coverage results are enabled by default--if you have none you should disable
[20:31] <alesage> mterry what's testapp?
[20:31] <mterry> fginther, ^ for the testapp package
[20:32] <mterry> alesage, some helper for creating windows to test a window manager.  I'm working on getting them to change the name
[20:32] <alesage> as if they could encompass all of testing of apps in Ubuntu indeed :)
[20:36] <fginther> alesage, testapp is some tool that thomi built to provide specific application features to an autopilot test. Like creating an app that doesn't have a menu
[20:36] <alesage> fginther, o gotcha
[20:36] <thomi> ...I think someone needs to package it for raring however
[20:37] <thomi> not sure if veebers fixed that or not
[20:38] <veebers> thomi: no I didn't
[20:38] <veebers> thomi: let me know what needs to happen and I will :)
[20:39] <thomi> veebers: I guess we need inline packaging, if it's not already got it, and then we need to talk to fginther about adding it to the new fancy-pants build system
[20:39] <veebers> thomi: sweet, sounds good. I'll start badgering fginther about that then :)
[20:39]  * alesage admires fginther's pants
[20:40] <fginther> veebers, the dull-pants build system will probably suffice
[20:40] <veebers> fginther: heh, nice :) Alright sounds good
[20:40] <fginther> veebers, but I can still help get that going :-)
[20:41] <veebers> fginther: awesome
[20:44] <fginther> veebers, looks like lp:testapp already has inline packaging
[20:44] <veebers> ah cool, was just branching to check
[21:10] <fginther> mterry, it looks like the testapp-ci job was just configured incorrectly. I removed the step where it was looking for test files which did not exist
[21:10] <mterry> fginther, thanks!


[17:04] <nhaines> ianorlyn: you around?
[18:44] <nhaines> I had a scheduling conflict (two compounded, actually) and almost certainly won't be back in town this Sunday night.  ianorlyn, if you can run the meeting, that'd be great.
[18:44] <nhaines> (Although there's no reason anyone else in here who's a LoCo member can't run the meeting, too.)
[21:22] <ianorlyn> I am pretty sure I can run meeting this sunday night
[21:27] <nhaines> I might even b back by then, but I can't guarantee it.  Okay, I'll announce the meeting tonight then.