[00:10] <infinity> GrueMaster: That's cause only one was rebuilt.
[00:10] <infinity> GrueMaster: So, the others are identical in 28 and 28.1
[00:11] <GrueMaster> Ok, well it screws up automated testing, but I can live with it.
[00:15] <GrueMaster> Any guestimated eta on the openjdk issue?  Or should I temporarily remove it from my netboot image automation?
[00:41] <doko> slangasek, infinity: I can upload openjdk without running the tests if required
[00:43] <slangasek> I don't think that's worthwhile; I think GrueMaster should just drop it from the automation for now
[00:45] <GrueMaster> slangasek: The problem with dropping it is I can't run any tests w/o it, so I have to manually install it from LP (there is an arm package there).
[00:45] <slangasek> can't run any tests without it?
[00:46] <GrueMaster> we don't have libvirt to work with like the QA team does.
[00:46] <slangasek> sorry, I thought you were saying it could be easily removed from the pipeline
[00:46] <GrueMaster> I can install without it, but not run tests.
[00:47] <slangasek> well, even if it gets uploaded, it'll take several hours to build on arm again
[00:47] <slangasek> doko: what's the eta for a proper fix?
[00:47] <GrueMaster> It's already built on arm.
[00:49] <GrueMaster> Just the arch-all bits are coming from x86 to the mirror.
[00:50] <slangasek> yes; I was assuming the packages had to be in sync to be installable
[00:50] <slangasek> but it looks like they don't
[00:51] <slangasek> the i386 build took 12 hours to fail last time; I wonder how long it takes to succeed
[00:51] <GrueMaster> They do.  openjdk-6-jre-headless : Depends: openjdk-6-jre-lib (>= 6b24-1.11.1-3ubuntu1) but it is not going to be installed
[00:52] <slangasek> no, it requires openjdk-6-jre-headless to be *newer* than the arm build
[00:52] <slangasek> not in sync
[00:52] <slangasek> so a build on i386 would be sufficient to make it installable
[00:53] <slangasek> GrueMaster: why does openjdk get installed in-line as part of the tests?  The tests themselves are written in java?
[00:53] <GrueMaster> Jenkins is written in java.  The tests are automated through jenkins.
[00:54] <slangasek> I don't see why that involves running java on the host system
[00:54] <GrueMaster> And as more tests come online, the longer they take to run.  Doing it manually is very time consuming as I have to babysit each test otherwise.
[00:55] <GrueMaster> Host system?  Each platform is independent.  I don't have the luxury of tapping into a kvm session to launch jobs.
[00:55] <GrueMaster> (which is how QA is currently running most of their tests).
[00:57] <GrueMaster> Java is pulled in during netboot imaging along with jenkins-slave to start running on reboot.  Tests are queued up waiting for the system to finish reimaging.
[00:58] <GrueMaster> If I had an entire team working on arm QA, I might have come up with a better solution.  Unfortunately, I only have a team of me.  And this is how it is currently set up.
[00:59] <slangasek> ah, so the slave has to run on the host system to receive the jobs. ok.
[01:00] <slangasek> well, I'm not sure getting openjdk-6 rebuilt on i386 is going to be any faster than hand-installing the packages from launchpad
[01:01] <slangasek> all the same
[01:01] <slangasek> doko: could you go ahead and upload openjdk-6 with the tests disabled?
[01:01] <GrueMaster> the easiest solution would be to backrev the pool to the previous version.
[01:01] <infinity> That's an odd definition of "easy".
[01:01] <infinity> (As in, it's really, really not easy at all)
[01:08] <GrueMaster> Neither is re-engineering automation around package skew, but it looks like I'm stuck with it.
[01:14] <doko> slangasek, spend most of the time on it today on that. it's something which comes and goes, until now only seen with cacao and zero, now for the first time with hotspot :/
[01:15] <slangasek> doko: ok
[01:25] <ScottK> infinity: It's a question of easy for who.
[01:26] <smoser> hi. i have 2 uploads in waiting-for-approval that i'd like someone to consider.
[01:26] <smoser> cloud-init, and cloud-utils.
[01:26] <smoser> cloud-utils is more straight forward, the issue and fix were diagnosed fairly thoroughly.
[01:26] <doko> slangasek, in the queue
[01:27] <smoser> cloud-init, i'd like to have these changes in for beta, but i will not be too upset if someone says "you're too late".
[01:27]  * GrueMaster reverts to un-automated "smoke" testing.
[01:28] <smoser> so, there is my plea. i have to run. if there is a question, i'm fine with either being held off, but personally think both are small in scope.
[01:30] <slangasek> smoser: which images are impacted by these changes?
[01:31] <slangasek> is it only the server EC2 images?
[01:31] <slangasek> smoser: AFAICS we don't even have any candidates for server EC2 posted yet, so provided that those are the only images affected, it should be straightforward to accept both of these
[01:33] <slangasek> ah, cloud-utils is on the main server images
[01:35] <slangasek> doko: the upload includes a change to GCC_SUFFIX and GCJ_SUFFIX, what's that about?
[01:37] <infinity> 18:35 < slangasek> doko: the upload includes a change to GCC_SUFFIX and GCJ_SUFFIX, what's that about?
[01:41] <slangasek> smoser: both cloud-utils and cloud-init accepted
[01:42] <slangasek> doko_: see above in case infinity's repost didn't highlight you - I'm unsure of these GC[CJ]_SUFFIX changes included in the openjdk upload
[01:42] <slangasek> marking !arm server for respin on the tracker
[01:43] <GrueMaster> erm, why?
[01:43] <slangasek> !arm
[01:43] <ubot2`> ARM is a specific (RISC) processor architecture used in a variety of applications such as handhelds and networkdevices. For more information see https://wiki.ubuntu.com/ARM . For ARM specific support, stop by the #ubuntu-arm channel.
[01:43] <slangasek> no thanks, bot
[01:44] <slangasek> SpamapS: perhaps you want to delay your RAID test in light of this respin
[01:45] <GrueMaster> Oh, not arm.  ok.
[02:04] <doko_> slangasek, infinity: rejected and re-uploaded
[02:04] <doko_> now off to bed
[02:42] <slangasek> openjdk-6 accepted
[05:19] <SpamapS> slangasek: thanks for teh heads up. I have been debugging a problem in the RAID tests actually :p
[05:23] <slangasek> looks like openjdk-6 is nearly done building on powerpc; I suppose we might as well wait for it to finish before respinning the server CDs
[05:27] <skaet> slangasek, makes sense.   Daveiy should be coming on line soon, and it take <15 minutes to build it,  so suggest letting him trigger it.
[05:27] <SpamapS> Would we be at all interested in adding a PowerMac G5 1.6Ghz to the powerbc buildd farm I wonder? I have one sitting here gathering dust under my desk. :-P
[05:28] <ScottK> infinity: ^^^
[05:29] <ScottK> You could do ISO testing ...
[05:33] <SpamapS> ScottK: I've considered it, but I've always felt that if no other users than me, with my unused G5, step up to do that testing.. then why go through the trouble?
[05:33] <ScottK> There are still a few powerpc users.
[05:34] <ScottK> We just recently lost our last known Kubuntu user to hardware failure, but there are server and Xubuntu users)
[05:34] <micahg> xubuntu stopped building powerpc images due to lack of testers, if we have testers, we can start again
[05:34] <micahg> I think lubuntu was going to try to do powerpc images
[05:38] <slangasek> openjdk-6/powerpc accepted
[05:38] <slangasek> GrueMaster: that does mean openjdk-6 should be fixed again for your purposes
[05:39] <GrueMaster> slangasek: Cool thanks.  I'll probably have to wait anotehr 25 minutes for my mirror to refresh though, but great.
[05:39] <GrueMaster> (netboot installing from ports.ubuntu.com is extremely slow).
[05:42] <GrueMaster> And I seem to be fighting an issue with oem-config-gtk on beaglexm.  It seems to be hanging at the keyboard layout screen.  Passed on mx5, checking panda now.
[05:58] <GrueMaster> This doesn't bode well.  I'm seeing issues with oem-config-gtk hanging at the keyboard layout screen on both omap & omap4 images.
[06:09] <pitti> skaet: external path to log files> which log files? we do have public URLs for live fs and CD build logs indeed
[06:11] <pitti> debfx: yes, I'll do that; but wanted to do in steps
[06:11] <pitti> debfx: let me start the big universe package check, will take a few hours anyway
[06:17] <GrueMaster> sigh.  I think the latest ubiquity patches have hosed arm desktop images.
[06:18] <GrueMaster> And this would explain why mx5 works:
[06:18] <GrueMaster> 20120228.3/precise-preinstalled-desktop-armhf+omap4.manifest:oem-config-gtk     2.9.22
[06:18] <GrueMaster> 20120228.3/precise-preinstalled-desktop-armhf+mx5.manifest:oem-config-gtk       2.9.21
[06:25] <GrueMaster> grrr.  mirror is failing checksums.  refreshing with cdimage.
[06:25]  * GrueMaster needs sleep soonish.  Getting loopy.
[06:46] <GrueMaster> Can someone verify the MD5SUMS for http://cdimage.ubuntu.com/daily-preinstalled/20120228.3/ images?  After refreshing my mirror, I am still failing 4 out of 7 files.  Also, manifests indicate that ac100 and mx5 images were not respun with omap & omap4.
[06:51] <GrueMaster> And Ubuntu Desktop armhf+mx5 is missing from the tracker.  I have a bug filed for an issue specific to it.  Bug 943058.
[06:51] <ubot2`> Launchpad bug 943058 in linux-linaro-lt-mx5 "Kernel doesn't support usb on newer rev quickstart boards." [High,New] https://launchpad.net/bugs/943058
[06:52] <infinity> SpamapS: We have a fair few powerpc users.  The assertion that testers=users is provably false.
[06:52] <infinity> SpamapS: (Of the potentially millions of x86 users we have, how many "step up" to do image testing? :P)
[06:54] <GrueMaster> Someone should add it to the automation testing.  :P
[06:55] <infinity> GrueMaster: Erm, hrm.  None of those images match the md5.  Something may have gone wrong there...
[06:55]  * infinity is tempted to just respin them overnight...
[06:56] <GrueMaster> That kind of makes me feel better.  I thought I was losing it.
[06:56] <infinity> GrueMaster: Our conclusions aren't mutually exclusive. ;)
[06:57] <GrueMaster> Hold that thought for a minute.  I appear to be having issues with oem-config 2.9.22 (which appears to be only on the omap & omap4 images).
[06:58] <infinity> What sort of issues?
[06:58] <GrueMaster> yep.  2.9.22 is not working for me.  I just started 20120228.2 omap4 image and it went right through the keyboard layout with no problems.  It hangs there on 20120228.3 images.
[06:59] <infinity> Keyboard layout, eh?  Drat.  That was definitely code that was mangled in that upload.
[07:00] <GrueMaster> Yes, I know (I read the bzr log).
[07:02] <infinity> stgraber: Your keyboard dialog locking/timeout tricks may be breaking oem-config (or breaking ARM, but arch-specific seems unlikely?)
[07:03] <GrueMaster> I'm not sure x86 really tests oem-config.  QA's current test (that I know of) checks to see that it gets installed, not much else.
[07:03] <GrueMaster> I could try it in a VM here, but it will have to wait til morning.
[07:04]  * GrueMaster is feeling a bit punchy and sleep is higher on the priority list.
[07:04] <infinity> Sleep is probably a saner idea.
[07:06] <GrueMaster> My thought exactly.  Wouldn't want to flood lp with "keyboard repeats when tester's face implants on it after passing out" bugs.
[07:06] <infinity> Seems like a valid bug.
[07:06] <infinity> I still think we need to ship cat detection software by default.
[07:08] <GrueMaster> If only they had keyboards that provided electric shock "education" for those instances.
[07:09]  * GrueMaster EOD.  Back in 8h.
[07:28] <pitti> I'll use the empty builders for some more no-change rebuilds for bug 875466
[07:28] <ubot2`> Launchpad bug 875466 in libxt "Lots of packages shipping with broken md5sums" [Medium,In progress] https://launchpad.net/bugs/875466
[07:28] <pitti> (unseeded universe packages)
[07:30] <pitti> debfx: ^ FYI
[07:49] <pitti> I'm done with the first batch; I let the buildds catch up now
[08:17] <jibel> skaet, dl links fixed for arm server
[08:56] <jibel> GrueMaster, what's issue with keyboard and oem-config on arm ? do you have a bug number ?
[08:57] <jibel> GrueMaster, I filed bug 942560 yesterday, is it the same ?
[08:57] <ubot2`> Launchpad bug 942560 in ubiquity "keyboard layout screen - Keyboard navigation broken" [High,Triaged] https://launchpad.net/bugs/942560
[08:58] <jibel> GrueMaster, and I test everything single desktop install manually if that can make you sleep better.
[09:42] <Riddell> Daviey: server images still to be rebuilt?
[09:42] <Riddell> or am I reading the pad wrongly?
[10:17] <pitti> the builders (except ppc) are empty again; would you mind if I uploaded the next batch of rebuilds for the md5sum fixes?
[10:24] <pitti> Riddell: ^
[10:35] <Riddell> pitti: go for it
[10:35] <pitti> ack, brace for impact, queuebot
[10:36] <pitti> batch of 24, some 50 to go after this
[10:42] <Daviey> Riddell: no, they were all built.. done
[10:43] <Daviey> Riddell: oh, wait.. smoser cloud fixtures?
[10:43] <Daviey> Riddell: We don't need to rebuild for them.
[10:44] <jibel_> Daviey, server are marked for rebuilt on the tracker and last build is 20120228.1
[10:44] <Daviey> jibel_: who marked that?
[10:45] <Daviey> jibel_: ah, seems slangasek did.
[10:46] <Daviey> I spoke to smoser last night, and it seemed we only really cared about these fixes landing in the cloud images.
[10:46] <Riddell> Daviey: shall I mark that you don't want a rebuild and current images are good?
[10:47] <Daviey> Riddell: Well, it's not too expensive to respin tbh.. I plan to human smoke test shortly anyway, and the other test cases are automagic.
[10:47] <Riddell> Daviey: ok so you do want a rebuild?
[10:47] <Daviey> Riddell: on it now... for non-arm
[10:47] <Riddell> Daviey: "on it" meaning you are doing the rebuild?
[10:47] <Daviey> Riddell: yes
[10:47] <Riddell> groovy
[10:48] <jibel_> Daviey, ok, you were faster than me reading scroll back
[10:48]  * micahg wonders why vlc was accepted since it's on the mythbuntu images
[10:51] <pitti> eek, sorry about that, that was my fault ^
[10:51] <Daviey> micahg: Mythbuntu needed that fix for the kfreebsd and powerpc port. :)
[10:51] <pitti> so, if we need to respin and vlc is broken, I can upload a reversion (but hopefully we won't)
[10:52] <micahg> Daviey: vlc was already fixed on powerpc
[10:52] <Daviey> pitti: it 'looks safe', i wouldn't panic!
[10:52] <pitti> Daviey: yes, I'm not :)
[10:52] <micahg> it does reenable a feature that was disabled with the 2.0 upload (v4l2
[12:21] <jdstrand> that ^ does not need to go into beta1
[12:55] <scott-work> skaet: techincal overview for ubuntu studio done
[12:56] <scott-work> skaet: sorry i haven't been as invovled lately, work has gotten incredibly busy lately
[13:14] <utlemming> stgraber: can I have you add http://cloud-images.ubuntu.com/precise/20120229.1/ to the ISO Tracker?
[13:15] <smoser> Daviey, Riddell i dont tihnk that cloud-utils or cloud-init is in the server iso, is it?
[13:15] <smoser> (ie, there would not be need for respin of those due to those changes)
[13:16] <infinity> smoser: Doesn't look like, no.
[13:16] <Daviey> smoser: waaat
[13:17]  * Daviey screams..
[13:18] <Daviey> smoser: it's in the pool
[13:18] <Daviey> well, -utils is
[13:19] <infinity> It is?
[13:19] <infinity> cloud-image ends up in ship?
[13:19] <Daviey> no, cloud-utils pkg.
[13:19]  * infinity sees nothing in the tasks that indicates that.
[13:19] <infinity> Unless it's a dependency of something.
[13:19] <Daviey> infinity: http://cdimage.ubuntu.com/ubuntu-server/daily/20120229.1/precise-server-i386.list
[13:20] <infinity> Ah-ha.
[13:20] <infinity> euca2ools pulls it in.
[13:20] <infinity> Which is, in turn, in server-ship.
[13:21] <infinity> Anyhow, respinning for things in the pool but not installed by default isn't necessarily worth the effort for non-final images anyway.
[13:21] <smoser> and the change that is included would not affect install
[13:22] <Daviey> right.. which was why i said we didn't need a rebuild for them..
[13:22] <Riddell> Daviey: but it is respun?
[13:22] <Daviey> but conversation between smoser and slangasek seemed to supersede that
[13:22] <Daviey> Riddell: it was.
[13:23] <smoser> i'm confused. cloud-images need it included.
[13:23] <smoser> and it is in the 20120229.1
[13:23] <infinity> Daviey: Is there a reason, BYW, why nova-compute-xen doesn't get to be in main with the rest of openstack thingees?
[13:24] <Riddell> Daviey: best get your guys testing :)
[13:24] <infinity> Daviey: Or do we just flat our refuse to support xen, despite using it internally? :P
[13:25] <infinity> s/our/out/
[13:25] <Daviey> infinity: I believe that was legacy from when xen was still universe.
[13:26] <Daviey> Riddell: Thankfully, my guys are mostly virtual machines.
[13:40] <greyback> Hi guys, question about freeze exceptions. One feature we've nearly ready now would be easiest merged (and reviewed) in several MRs.
[13:40] <greyback> For a FFe request, is it ok to list these MRs, and build package of code with all the MRs merged in?
[13:41] <Riddell> greyback: yes that's fine
[13:41] <Riddell> greyback: file a bug, list all the useful information, subscrube ubuntu-release and ping here
[14:05] <stgraber> utlemming: looking in a sec if nobody beats me to it
[14:05] <utlemming> straber: :)
[14:07] <stgraber> infinity: is it reliably broken for you? I can reproduce the UI locking up on x86 too but it depends on how quickly you click on stuff and if you select keyboard variants
[14:08] <stgraber> infinity: I started looking into the right way of fixing the bug yesterday, will continue today. If it's always broken for you, I guess I'll just revert my commit and re-introduce the bug where using your keyboard to select layout freezes the dialog
[14:10] <stgraber> utlemming: does that look good?
[14:15] <infinity> stgraber: I haven't tested it, I was relaying GrueMaster's claims.  But I think he was seeing it lock up with reproducibility.
[14:15] <infinity> stgraber: I believe he opted for sleep instead of filing a bug, but he'll be online in an hour or three for you to ask him about it, I'm sure. :)
[14:17] <stgraber> ok
[14:18]  * stgraber really doesn't like the ubi-console-setup debconf/console-setup black amgic...
[14:18] <stgraber> it's clearly racy but there isn't a good way of preventing the race, at least not that I could easily figure out in ubiquity. Last night I started digging into the debconf/console-setup part to try and fix the problem there instead of the UI
[14:24] <utlemming> stgraber: yes, sir, thank you kindly3
[14:26] <jibel> stgraber, there's a problem with ltsp. the client starts compiz even if it detects that 3d is not supported and the desktop is unusable.
[14:27] <stgraber> jibel: sounds like a problem with unity/nux/compiz more than with ltsp...
[14:27] <stgraber> jibel: I'm guessing they thought that as the check is now done by lightdm there's no reason to run it in unity too, and they'd be wrong as not everybody uses lightdm
[14:28] <stgraber> didrocks: ^
[14:28] <didrocks> stgraber: as told to jibel, I don't really have the time to look closely at that, but I need more info from the LTSP side as how it works
[14:28] <stgraber> jibel: we could hardcode to use ubuntu-2d in LTSP but that'd be wrong as there are thin clients perfectly capable of running unity-3d
[14:29] <stgraber> didrocks: LTSP basically opens a session on the server, sets DIPLAY= to point back to the client, then calls /etc/X11/Xsession <session> directly
[14:29] <Riddell> is there actually any advantage in using unity-3d over unity-2d?
[14:30] <didrocks> stgraber: so, you don't use lightdm, right?
[14:30] <stgraber> didrocks: so my guess is that doing so bypasses the nux-whatever check
[14:30] <stgraber> didrocks: correct
[14:30] <didrocks> stgraber: so, you get the second check
[14:30] <didrocks> stgraber: which is done by gnome-session
[14:30] <didrocks> stgraber: I would need you to run gnome-session --debug on a LTSP config
[14:30] <didrocks> while starting the session
[14:31] <stgraber> didrocks: ok, hold on a sec, doing that now
[14:31] <jibel> stgraber, didrocks , I'm filing a bug. I think it can be release noted for B1 as selecting 2d loads the 2d session.
[14:32] <stgraber> jibel: yeah, release note is fine, I just want to make sure we know exactly what the bug is and can have it fixed first thing after beta-1
[14:34] <dobey> does https://bugs.launchpad.net/ubuntu/+source/ubuntuone-control-panel/+bug/934270/comments/15 make sense to release team?
[14:34] <ubot2`> Launchpad bug 934270 in ubuntuone-control-panel "We need to drop the current GTK+ UI in favor of the Qt UI" [Undecided,New]
[14:44] <stgraber> didrocks: it's an LTSP bug
[14:45] <stgraber> our dmrc parsing is wrong
[14:45] <didrocks> stgraber: ah see!
[14:45] <didrocks> :)
[14:45] <stgraber> it's using TryExec for some reason instead of Exec, so it's calling "/etc/X11/Xsession unity" directly
[14:45] <didrocks> stgraber: ah, that explains then
[14:48] <stgraber> didrocks: apparently we fixed that bug a few days ago in LTSP upstream ;)
[14:48] <stgraber> didrocks: just need to sync the new bugfix version from Debian
[14:48] <didrocks> stgraber: excellent! :)
[14:49] <stgraber> jibel: bug 820417 is the upstream bug
[14:49] <ubot2`> Launchpad bug 820417 in ltsp "LDM doesn't set ~/.dmrc correctly" [Low,Fix released] https://launchpad.net/bugs/820417
[14:51] <stgraber> I'll send a sync request for ldm now but unless we need to rebuild Edubuntu and the alternates anyway, I don't think it's worth fixing for beta1 (release note should be fine)
[14:55] <stgraber> sent the sync request. The only feature change I see in the upstream code is the change of background image, though that doesn't affect Ubuntu as we ship our own theme anyway
[14:55] <jibel> stgraber, thanks
[15:34] <pitti> Riddell: do you need the buildds for anything? if not, I'd like to upload the next 25 packages for md5sums (then 23 left to go)
[15:42]  * pitti assumes not; these are all small builds anyway, and will readily yield for any main package
[15:46] <GrueMaster> stgraber: Morning.  The oem-config issue was very consistent with v2.9.22, but not with v2.9.21.
[15:47] <Riddell> ruby?  I hear that's big in Japan.
[15:48] <ogra_> "big in japan" ... thats alphaville, no ?
[15:48] <pitti> Ruby galore done
[15:49] <Riddell> morning skaet
[15:50] <skaet> Good afternoon Riddell - all looks nice and quiet on the pad
[15:50] <skaet> any worries that haven't made it there yet?
[15:50] <Riddell> yes I think it is, Daviey did a rebuild of -server today but he has his team of virtual machines testing it now
[15:50]  * skaet working through backscrolls still...
[15:51] <stgraber> GrueMaster: ok, I'm currently in a meeting but I have a VM setup to debug that one and try to find the right fix for it...
[15:51] <Riddell> kubuntu is good from my tests
[15:51] <skaet> :)
[15:51] <stgraber> GrueMaster: are you selecting your keyboard layout using the mouse or keyboard? also are you using a specific variant of the layout?
[15:51] <skaet> Riddell,  release notes updated for Kubuntu?
[15:51] <infinity> stgraber: I think he was saying that it locks up when entering the keyboard config dialog (as in, he never even gets a chance to select)
[15:52] <GrueMaster> Actually, I have been letting it go with default, just hitting enter to continue.
[15:52] <ogra_> at least he gets that dialog
[15:52]  * ogra_ has issues on ac100 with that
[15:52] <pitti> back in 20 mins
[15:52] <GrueMaster> But with 2.9.22, it just sits with the mouse indicating it is busy.  It will not budge from there.
[15:53] <Riddell> mvo: does do-release-upgrade need a sudo or not?
[15:53] <ogra_> it surely did in the past
[15:53] <mvo> Riddell: it will ask you for sudo when it needs it
[15:53] <Riddell> mvo: what does it use to ask?
[15:53] <mvo> Riddell: do-release-upgrade will use plain sudo
[15:54] <mvo> Riddell: the other frontends should use there native tool, gksu/kdesu
[15:54] <Riddell> right, so for beta I do want to advise using kdesudo since that's just a command line
[15:55] <mvo> Riddell: I don't know much about the kde part of this, but for ubuntu we run it without and it will ask when it needs it
[15:56] <Riddell> yeah but nicer not to make people have to do more command line stuff if possible, I'm not that elitest on my users :)
[16:00] <stgraber> GrueMaster: hmm, well, the known issue with my change is that the dialog can be "insensitive" while waiting for debconf/console-setup and sometimes never unlock at all but I don't see anything in my change that'd prevent the dialog from showing up at all
[16:00] <stgraber> GrueMaster: can you check /var/log/syslog and /var/log/installer/debug for traceback?
[16:01] <GrueMaster> I have never been able to get decent debug info from oem-config (and the only thing in /var/log/installer/ is version).
[16:02] <GrueMaster> And the dialog shows up, just never goes away.
[16:02] <ogra_> isnt there another file where ubiquity-dm logs to ?
[16:03] <stgraber> GrueMaster: hmm, ok...
[16:04] <GrueMaster> It has been one of my greatest frustrations for several cycles.
[16:05] <stgraber> skaet: do you think we should revert that workaround then? it's going to re-introduce bug 645449 but should fix GrueMaster's bug and bug 942560
[16:05] <ubot2`> Launchpad bug 645449 in ubiquity "Ubiquity hangs at Keyboard layout if you use keyboard to navigate / select" [High,Fix released] https://launchpad.net/bugs/645449
[16:05] <ubot2`> Launchpad bug 942560 in ubiquity "keyboard layout screen - Keyboard navigation broken" [High,Triaged] https://launchpad.net/bugs/942560
[16:05] <stgraber> I'm working on a different and hopefully "proper" fix but I have no clue when I'll have something ready for upload
[16:06]  * skaet reading
[16:07] <GrueMaster> stgraber: Was bug 645499 even reproducible in recent releases?  Seems a bit old, especially for a fix mid-release week.
[16:07] <ubot2`> Launchpad bug 645499 in nautilus "nautilus crashes when unmounting microSD card (dup-of: 630884)" [Medium,Invalid] https://launchpad.net/bugs/645499
[16:07] <ubot2`> Launchpad bug 630884 in nautilus "nautilus crashed with SIGSEGV in g_closure_invoke()" [Critical,Fix released] https://launchpad.net/bugs/630884
[16:07] <stgraber> I could probably keep the delays and drop the "locking the UI" part of the workaround, this should somewhat limit the number of occurences of bug 645449 and hopefully fix the regression
[16:08] <ubot2`> Launchpad bug 645449 in ubiquity "Ubiquity hangs at Keyboard layout if you use keyboard to navigate / select" [High,Fix released] https://launchpad.net/bugs/645449
[16:08] <stgraber> GrueMaster: yes, it's very easy to reproduce
[16:08] <GrueMaster> oops. wrong bug.
[16:08] <stgraber> GrueMaster: just keep the down arrow key pressed and see the dialog freeze
[16:08] <GrueMaster> ok.
[16:08] <skaet> stgraber,  is this only showing up on arm?
[16:09] <stgraber> skaet: I didn't see GrueMaster's specific issue on anything else but I haven't tested oem-config myself, I can reproduce bug 942560 and its duplicates on x86 though
[16:09] <ubot2`> Launchpad bug 942560 in ubiquity "keyboard layout screen - Keyboard navigation broken" [High,Triaged] https://launchpad.net/bugs/942560
[16:10] <GrueMaster> stgraber: On a side note, I was able to get through IF I unplugged the network cable before booting.  Just tried that.  Seems odd.
[16:11] <stgraber> GrueMaster: indeed seems really odd and should be unrelated ;) are you sure you're not getting stuck on the timezone dialog (that's just before the keyboard dialog)?
[16:11] <stgraber> GrueMaster: the timezone dialog uses the network so that could explain it
[16:12] <GrueMaster> No, it takes a little longer, then defaults to NYC.  I click on Los Angeles and can move on.
[16:13] <skaet> stgraber,  am worrying a bit about whether jibel has bandwidth for retesting images if we respin at this point.   Is there a workaround for 942560?
[16:14] <stgraber> skaet: the workaround is to use the mouse to first click the keyboard layout and then the keyboard variant, waiting for the UI to refresh between each action
[16:15] <stgraber> trying to do things too quickly or clicking to many different entries in a row can cause the bug
[16:15] <stgraber> *too many
[16:15] <skaet> stgraber,  got cha.  :)  thanks.   if we have a workaround for it am leaning towards leaving things as is.
[16:16] <GrueMaster> I think reverting might be the safer option at this point.  The bug that it fixed has been around for quite a while.
[16:18] <skaet> GrueMaster,  if you feel that way - its good to know.  *sigh*
[16:19] <stgraber> skaet: I'm doing an x86 OEM test install now
[16:19]  * skaet waiting to see if she can get a response from jibel about the testing load,  since this is more than arm
[16:20] <GrueMaster> The other option for me is releasing 20120228.2 images (prior to the fix).  They will be slightly out of sync, but that can be addressed between now and Beta 2.
[16:21] <GrueMaster> And would require less retesting overall.
[16:21] <GrueMaster> Besides, not all of the arm desktop images were respun for this fix.
[16:22] <skaet> GrueMaster - if that works for you,  am fine with that option.
[16:23] <skaet> do you want me to go into the tracker and change them to point to those images now?
[16:23]  * skaet would prefer not to revert if we can avoid it at this point.
[16:23] <GrueMaster> Sure.  I have already partially tested those images to figure out this issue.
[16:24] <skaet> GrueMaster - going and changing now.
[16:25] <GrueMaster> Please delete 20120228.3 from cdimage too if possible.  That directory isn't right anyways (4 out of 7 md5sums failed).
[16:27] <GrueMaster> Oh, and Ubuntu Desktop armhf+mx5 needs to be added to the tracker.
[16:28] <stgraber> skaet: OEM works here, though you have to select your keyboard variant on the first go as the dialog gets locked when you do...
[16:28] <stgraber> now back to figuring out a real fix for that stuff...
[16:29] <skaet> stgraber,  k,  release note time then.   thanks!
[16:30] <stgraber> skaet: writting something now, will also add the LTSP issue jibel found earlier
[16:30] <stgraber> highvoltage: can I let you do the Edubuntu section?
[16:30] <skaet> Thanks stgraber.  :)
[16:32] <stgraber> skaet: just thought of a workaround for the case where the dialog is locked, I added that too
[16:32] <infinity> The livecd-rootfs that queuebot's about to warn about has a fix for ac100 images (and nothing else) that would be kinda nice, but obviously not critical, since it's a community image.
[16:34] <skaet> infinity,  prefer not at this point.   in a couple of hours if no other respin triggers occur,  we can probably let it in and do a rebuild of it for tonight.
[16:34] <ogra_> yeah, its not urgent
[16:34]  * skaet wants to hear from jibel about the images and if there's any other criticals on the horizon.
[16:34] <ogra_> and has an easy workaround
[16:35] <skaet> thanks ogra_ ,  yeah then lets hold off on it until after beta 1.   Please document the workaround in the release notes.
[16:35] <ogra_> will do
[16:35] <ogra_> (not actually a workaround, there are kde bits ending up in the install ... you can just apt-get remove them
[16:36] <ogra_> )
[16:36] <infinity> skaet: Well, livecd-rootfs doesn't ship on any images, so there's no real harm in letting it in, pending a later respin.
[16:36] <infinity> (But if there are no respins, no big deal either way)
[16:39] <skaet> infinity,  thanks.
[16:40]  * pitti uploads the remaining 17 rebuilds for broken md5sums, buildds are still bored
[16:42] <jibel> skaet, it's too short to retest desktop images properly. But i'm trying to reproduce on x86 what GrueMaster's seeing so it can be documented
[16:42] <jibel> skaet, major issues remaining with the live session and the installer are
[16:42] <jibel> bug 940908
[16:42] <ubot2`> Launchpad bug 940908 in ubiquity "Keyboard layout not set on persistent USB image" [High,Confirmed] https://launchpad.net/bugs/940908
[16:42] <jibel> bug 939450
[16:42] <ubot2`> Launchpad bug 939450 in ubiquity "ubiquity crashed with TypeError: argument of type 'NoneType' is not iterable in ubi-partman.py" [High,Triaged] https://launchpad.net/bugs/939450
[16:42] <jibel> and bug 942560
[16:42] <ubot2`> Launchpad bug 942560 in ubiquity "keyboard layout screen - Keyboard navigation broken" [High,Triaged] https://launchpad.net/bugs/942560
[16:46] <skaet> thanks jibel
[16:54] <GrueMaster> skaet: I have tested the armhf+mx5 desktop image, but have no place to put results.  Can it get added to the tracker?
[16:54] <ogra_> yes, please
[16:59] <infinity> (pretty please)
[17:00] <infinity> skaet: I've taken sign-off duties for mx5/ac100, you can yell at me if they don't get test results. :P
[17:01] <pitti> skaet: https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview -> the "section missing" is from your new parser? what is it looking out for?
[17:01] <skaet> GrueMaster,  have cleaned up other images to .2 (please verify)
[17:01] <skaet> pitti,  meant that the section wasn't in the weekly report
[17:01] <GrueMaster> Yes, they are on .2 now, thanks.
[17:01] <pitti> skaet: I guess I mis-named it then
[17:01] <skaet> Release Notes section.  :)
[17:02] <GrueMaster> Still need the mx5 image added.
[17:02] <skaet> pitti, https://wiki.ubuntu.com/ReleaseTeam/Meeting/Agenda/TeamTemplate
[17:03] <skaet> GrueMaster,  yup.  Will add it after I get off my call.   its on the list. sorry to be slow.
[17:03]  * skaet is fine if someone else on the release team adds it before I get to it.  ;)  hint, hint ^ infinity ;)
[17:04] <infinity> Don't make me learn how to use the tracker!
[17:11] <infinity> GrueMaster / skaet: That should do it.
[17:12] <GrueMaster> I can live with it, but the download link is mia.
[17:12] <infinity> It's MIA for omap4 too, which is what I copied. :P
[17:12] <infinity> I can fix, though.
[17:12] <GrueMaster> As I said, I can live with it (I know where the images are).
[17:16] <infinity> GrueMaster: Download link fixed too.
[17:16] <GrueMaster> k, thanks.
[17:20] <pitti> skaet: I added the desktop bits to https://wiki.ubuntu.com/PrecisePangolin/TechnicalOverview, but some bits (like the HUD description) will still be improved
[17:21] <SpamapS> no more respins?
[17:37] <Daviey> SpamapS: nein.
[17:37] <Daviey> (correct)
[17:43] <SpamapS> Cool.. just wrapping up RAID1 test again
[17:51] <skaet> pitti,  thanks
[17:51] <skaet> thanks infinity.  :)
[18:17] <skaet> GrueMaster, 20120228.3 removed
[18:20] <GrueMaster> skaet: Thanks.
[18:40] <Riddell> skaet: I'm about done for the day, what's the plan for tomorrow?
[18:42] <skaet> Riddell,  will see what emerges from rest of testing today.
[18:42] <Riddell> skaet: ok but if it's all good when are we hoping to release and who cranks which handles?
[18:43] <skaet> Riddell, will leave you summary of the bits from the checklist - marking the ones good to start.
[18:44] <skaet> while I'm sleeping.  :)
[18:46] <Riddell> skaet: and if all goes well aim for release my late afternoon your morning?
[18:48] <skaet> Riddell,  yup.
[19:34] <GrueMaster> Riddell: Did you ever get your panda running?  Also, have you asked anyone to step up and test kubuntu armhf?
[20:04] <scott-work> i should be testing the remaining ubuntu studio test cases this afternoon (i.e. 64 bit) for beta1
[20:06] <skaet> scott-work, yes please.
[20:07] <skaet> scott-work - no respins planned at this point ( but waiting for all the test results to come in though)
[20:33] <GrueMaster> Well, having seen no response to my question on Kubuntu armhf testing, I guess I can fire them off.  Fortunately, they only take a few minutes to smoke test.
[20:34] <iulian> GHC has just landed in the unapproved queue. Does anyone fancy hitting the 'accept' button?
[20:34]  * iulian giggles.
[20:36] <skaet> looks like we're going to need a respin for lubuntu this evening to get the artwork usable for them.
[20:36] <skaet> https://launchpad.net/bugs/938472
[20:36] <ubot2`> Launchpad bug 938472 in lubuntu-artwork "dialogs are barely readable-- grey on black????" [Undecided,Confirmed]
[20:38] <skaet> NCommander, Riddell, slangasek, ScottK, iulian ^ please let fix through the queue as soon as you see it if I'm not around.
[20:38] <slangasek> ack
[20:43] <GrueMaster> sigh.  Kubuntu Daily-preinstalled 20120228.1 MD5SUMS is wrong.
[20:47] <GrueMaster> As are the daily-preinstalled/201228.2/MD5SUMS for Ubuntu Desktop.
[20:53] <GrueMaster> As far as I can tell, NONE of the arm images match the md5sums from the same directory.
[20:53] <GrueMaster> Kubuntu, Ubuntu Desktop, and Ubuntu server are all wrong.
[20:55] <slangasek> infinity: ^^ can you have a look at what's going on with md5sums?
[21:12]  * skaet curious why suddenly this might have changed.... werid.
[21:15] <slangasek> I'm not sure it's ever been working, GrueMaster brought it up last milestone as well
[21:15] <slangasek> a fix was applied but perhaps it was incomplete
[21:16] <GrueMaster> I should probably add this to my daily tests.  I don't check daily images normally.
[21:16] <skaet> thanks slangasek.
[21:17] <skaet> GrueMaster, yeah would have been good to know about this much earlier.  Was there a bug number?
[21:18] <GrueMaster> No.  I only file bugs when I know what to file bugs for.  In this case, I wouldn't know what to file against.
[21:18] <GrueMaster> Besides, I just picked it up.
[21:18] <slangasek> the ubuntu-cdimage project
[21:18] <GrueMaster> It's one of the last things I check before release.
[21:18] <GrueMaster> slangasek: ok.
[21:20] <skaet> thanks for checking it GrueMaster.   hopefully we'll sort it now.
[21:21]  * skaet has updated pad with latest status she's aware of
[21:21]  * skaet --> lunch (finally!)
[21:22] <skaet> :)
[21:36] <jibel> skaet, bug 940908 is more serious that it seems finally
[21:36] <ubot2`> Launchpad bug 940908 in ubiquity "Keyboard layout not set on persistent USB image" [High,Confirmed] https://launchpad.net/bugs/940908
[21:37] <jibel> not only keyboard but all boot parameters like oem-config are ignored with persistence enabled
[21:38] <GrueMaster> Please do not respin arm images due to md5sums being broken.  That will pull in oem-config 2.9.22, which is broken.
[22:32] <gilir> skaet, lubuntu-artwork uploded, sorry for the late request
[22:43] <micahg> stgraber: queuebot was flooded out about 7 hours ago
[22:44]  * micahg wonders if it should stay away so no one accepts the new ghc :)
[22:46] <ajmitch> micahg: is ghc a bit of a 'rebuild-the-world' situation? :)
[22:46] <micahg> yes, which I personally think is insane while the archive is frozen
[22:46] <iulian> ajmitch: No, not really. :)
[22:46] <ajmitch> iulian: I thought it was going to be quite a few rebuilds & possibly a few syncs as well
[22:47] <Laney> the rebuilds won't be happening when the archive is frozen
[22:47] <iulian> ajmitch: I wouldn't say "a few". :)
[22:47] <slangasek> not the world, just the universe
[22:47] <Laney> we did think of this.
[22:47] <iulian> slangasek: Heh.
[22:47] <ajmitch> Laney: oh I expected you'd think about it :)
[22:47] <micahg> iulian: you make a whole bunch of things uninstallable with the first upload and the manual processing makes the whole thing tedious
[22:48] <micahg> the archive should be unfrozen in ~24 hours at which point it's a lot easier to do this
[22:48] <stgraber> micahg: apparently irclib doesn't respect the flood restrictions ;) I guess I'll have to implement it myself then (or use a more complete irc library)
[22:48] <slangasek> lubuntu-artwork accepted
[22:49] <micahg> stgraber: well, pitti flooded teh archive with ~25 uploads at once
[22:49] <micahg> it was a very unusual case for a freeze I would think (but I haven't been keeping score)
[22:50] <iulian> micahg: We won't do anything when the archive is frozen, like Laney said above. It'd be a mess!
[22:50] <GrueMaster> There have been other updates that slipped in during image builds.  For example, libxml2.  I have different versions for omap & omap4 images.
[22:51] <micahg> iulian: than why were you asking for ghc to be accepted?
[22:51] <micahg> s/than/then/
[22:51] <iulian> micahg: Having said that, it doesn't really matter whether ghc is accepted now or after.
[22:52] <slangasek> GrueMaster: libxml2 was an opportunistic security upload, discussed on here yesterday
[22:52] <micahg> iulian: sure it does, anything that depends on the virtual provides will be uninstallable
[22:52] <iulian> Yes, we'd end up with loads of uninstallable packages but that's going to be fixed soon anyway.
[22:52] <micahg> unless they got the domination scripts to factor that in as well
[22:52] <micahg> iulian: but why do that when you can minimize the impact
[22:53] <GrueMaster> Ah, well kubuntu omap4 got it, but not omap.  Not that I care, it was the only update for omap and largely doesn't affect many users for beta 1 (seeing as how I'm the only one testing them).  :)
[22:53] <Laney> it takes hours to build on arm
[22:53] <Laney> so should be accepted ~12 hours before the freeze ends
[22:54] <micahg> Laney: with the pandas?
[22:54] <GrueMaster> Which is why I panic at the mention of respins.  :P
[22:54] <Laney> 12 hours is down from 2 days
[22:54] <GrueMaster> Image builds on arm are serial.  None are posted to cdimage until all for that build are done.
[22:55] <Riddell> GrueMaster: no I'm waiting on jason to tell me I can expense the necessary equipment to get the panda running
[22:55] <GrueMaster> arm builds will see greater improvement once we start seeing real arm server hardware.
[22:56] <GrueMaster> Riddell: Images have been tested, results posted.
[22:57] <GrueMaster> And I emailed you on how I think we need to test going forward.
[23:00] <Riddell> GrueMaster: yes, it's up to jason for now
[23:07] <slangasek> GrueMaster: no, image builds on arm are parallel across two builders, and as of alpha-2 we're spitting out the images in sub-batches precisely so the testing isn't held up waiting for them all to finish
[23:07] <GrueMaster> Ah, well that is an improvement then.  Didn't know that had been fixed, thanks.
[23:09] <slangasek> that's why you were getting .1 on the tracker while still testing .0
[23:09] <slangasek> an artifact of how the publishing happens when we split the batch
[23:44]  * skaet catches up on backscroll...
[23:45] <skaet> jibel, slangasek - is there a known fix likely to land for 940908?
[23:46] <skaet> gilir,  will start off the respins as soon as bits get published.
[23:46] <skaet> GrueMaster - no arm respins... (if we do any)  "noted"  :)
[23:47] <GrueMaster> Ok.  I just saw the note on the pad.
[23:48] <slangasek> skaet: 940908> do you want a respin for that one if you can get it?  it seems it'd be fairly intrusive?
[23:48] <slangasek> stgraber: ^^ 940908 is the one you're working on right now?
[23:49] <skaet> slangasek, yeah don't want to unless it can't be release noted.   I think it can, but figured better check with the experts.  ;)
[23:49] <skaet> s/can/can be release noted/
[23:49] <slangasek> looks release-notable to me
[23:51] <stgraber> bug 940908
[23:52] <skaet> slangasek - ok,  that's what we'll do.
[23:52] <ubot2`> Launchpad bug 940908 in ubiquity "Keyboard layout, oem-config not set on persistent USB image" [High,Confirmed] https://launchpad.net/bugs/940908
[23:52] <stgraber> slangasek: no, that's the next one on my list
[23:52] <skaet> I'll start off the lubuntu rebuilds as soon as the artwork publishes, and get that up there.
[23:52] <stgraber> slangasek: I'm on bug 942560
[23:52] <ubot2`> Launchpad bug 942560 in ubiquity "keyboard layout screen - Keyboard navigation broken" [High,Triaged] https://launchpad.net/bugs/942560
[23:52] <slangasek> stgraber: ack
[23:55] <skaet> infinity,  will you be able to patch the ARM images MD5SUMs in the directory?
[23:55] <jibel> skaet, I think it is release notable, the workaround for oem installation is to install from a media without persistence enabled
[23:56] <jibel> for keyboard with persistence, setting the right layout in /etc/default/keyboard should work
[23:56] <skaet> thanks jibel.
[23:57] <jibel> that's the most visible side of this bug probably
[23:58] <skaet> jibel,  given that lucid -> precise updates don't seem to be working in the smoke tests - I think we'd better be making that prominent in the release notes to avoid doing.   Am I being overly pessimistic?


[17:02] <Saviq> hi Renato! ;)
[17:03] <Saviq> hi Albert :)
[17:03] <Saviq> hey Zoltan
[17:05] <tsdgeos> Saviq: you greeted me while i wasn't here yet
[17:06] <Saviq> tsdgeos, that's because I heard you on Icecast :)
[17:06] <tsdgeos> did you?
[17:06] <tsdgeos> ok
[17:06] <tsdgeos> stop looking at the screen jonathan
[17:07] <thiago> hello
[17:07] <tsdgeos> hi
[17:07] <Mirv> hello world
[17:07] <Saviq> hey
[17:07] <thiago> #ubuntu-uds-junior-ballroom-1 (for those who can't read the shortened version on screen)
[17:08] <bzoltan> Hello Saviq
[17:08] <Saviq> I wonder who can kick udsbotu to update the title
[17:08] <Saviq> yes we can
[17:08] <shirgall> We can hear you on the stream.
[17:09] <thiago> http://www.macieira.org/blog/qt-stats/
[17:10] <txwikinger> o/
[17:12] <txwikinger> just saying hallo
[17:16] <Saviq> hey  pstolowski
[17:16] <thiago> http://qt-project.org/wiki/QtMediaHub
[17:18] <mikhas> AlanBell, o/
[17:19] <Saviq> in Ubuntu with QML (a11y backported into 4.8 by fregl), Unity-2D is said to be "99% accessible"
[17:19] <Saviq> AFAIK the same went into Qt5
[17:20] <mikhas> I would like to see A11Y be moved lower in the stack anyway (e.g., wayland), and then, as thiago said, it would be in the framework bits of Qt, without app developers having to worry about it too much.
[17:21] <Saviq> mikhas, not that easy, just reading the text of, say, a button, is often not enough
[17:21] <Saviq> mikhas, there needs to be additional data about things that are represented visually
[17:22] <mikhas> no, it isnt, you need screen reading, UI navigation and input.
[17:22] <mikhas> (at least)
[17:22] <pstolowski> Saviq, hey
[17:22] <Saviq> simple screen reading could be implemented lower, but an app developer still would need to be able to influence it, or replace, even
[17:23] <pstolowski> Saviq, I talked to fregl several times, and to my understanding Qt5 has a11y reworked compared to 4.8+a11 patch
[17:23] <Saviq> mikhas, think the launcher icons, we have data like app name, how many windows are running, progress bars, notification count
[17:23] <Saviq> pstolowski, API wise, or just backend wise?
[17:23] <pstolowski> Saviq, e.g. in 4.8+patch there are still areas that just have stub/unimplemented code (e.g. text input in qml)
[17:24] <Saviq> pstolowski, yeah, sure, so it got even better in Qt5
[17:24] <mikhas> Saviq, that's a good reason why it needs to lower in the stack.
[17:24] <pstolowski> Saviq, afaik public api stays, but underneath it has been reworked and cannot even be backported easily anymore
[17:25] <mikhas> Imagine Unity running on Wayland, then you'd have all the bits in one place.
[17:25] <girishr_> http://wiki.qt-project.org/Devices pi packages - http://wiki.qt-project.org/Devices/RaspberryPi
[17:25] <Saviq> mikhas, all that data needs to be presented to a11y, you don't want to navigate from icon to progress bar to notification counter etc.
[17:26] <mikhas> I know, there has been some great research by http://www.aegis-project.eu/ to find out more about that, and to come up for solutions.
[17:26] <mikhas> *with solutions
[17:30] <mikhas> re: Wayland + runtime switch; a good example of why frameworks can be useful ;-)
[17:38] <Saviq> what about functional testing? testability seems to be orphaned? what's the recommended UI testing platform going forward?
[17:41] <mikhas> Saviq, there is TDriver right now, for UI testing, but it uses Ruby as its scripting language …
[17:41] <Saviq> mikhas, yes, and AFAIK it's being orphaned i.e. noone sponsors it anymore
[17:41] <mikhas> (TDriver probes into Qt UIs through A11Y layer, AFAIK)
[17:42] <Saviq> not a11y
[17:42] <Saviq> it introspects the object tree
[17:45] <Saviq> gtg
[18:34] <SpamapS> FYI: Parallel discussion regarding "cloud agnostic way to define resources in juju" in room 201 .. OpenStack interested folks might want to join in.
[18:40] <SpamapS> We could use a glance expert in room 201 actually, trying to figure out how much glance exposes about what OS an image provides.
[18:50] <udsbotu> uds-junior-ballroom-1: 5 minutes left in this session!
[18:51] <udsbotu> uds-junior-ballroom-1: 4 minutes left in this session!
[18:52] <udsbotu> uds-junior-ballroom-1: 3 minutes left in this session!
[18:53] <udsbotu> uds-junior-ballroom-1: 2 minutes left in this session!
[18:54] <udsbotu> uds-junior-ballroom-1: 1 minute left in this session!
[18:55] <udsbotu> uds-junior-ballroom-1: This session has ended.
[19:00] <zyga> hello
[19:02] <zyga> anyone in the room?
[19:04] <zyga> hmm
[23:16] <SpamapS> hallohallo
[23:16] <SpamapS> o/ reading you
[23:16] <med_> you are on screen
[23:16] <med_> how was the audio check?
[23:17]  * med_ waves at rnathuji
[23:17] <rnathuji> I'm not able to get audio
[23:18] <JoseeAntonioR> Anyone else having audio problems?
[23:18] <SpamapS> http://icecast.ubuntu.com:8000/junior-ballroom-1.ogg direct link.. works great for me.
[23:18] <rnathuji> got it now
[23:19] <med_> cool.
[23:19] <med_> adam_g is talking through the etherpad.
[23:19] <SpamapS> awsome?
[23:21] <SpamapS> adam_g: The CI lab charms should be the ones that are in lp:charms/* ... is that the case?
[23:22] <SpamapS> Its no small feature. Its huge!
[23:24] <ttx> SpamapS: It's almost awesome.
[23:24] <SpamapS> It allows hooks to defer their actions until they can succeed, so charms don't need to be dependent on the order relations are established.
[23:26] <SpamapS> I have one idea for that using 'charm splice'
[23:27] <med_> can you then kill the existing spliced charm once other nodes providing that service are up?
[23:28] <SpamapS> subordinates are done, but they carry a 1:1 relationship for all components
[23:29] <SpamapS> I/O death
[23:30] <SpamapS> building 7*mini-ubuntu's are painful for I/O
[23:30] <SpamapS> agreed ttx .. splice is a hack
[23:30]  * SpamapS said the Hacker
[23:30] <med_> heh.
[23:32] <SpamapS> Should work on RAX or HP Cloud if we can solve the S3 issues.
[23:32] <SpamapS> its not anywhere official yet because its fairly hacky
[23:33] <SpamapS> To be clear, for basic dev purposes, you can use the 'placement: local' hack
[23:33] <SpamapS> lp:~clint-fewbar/charm-tools/add-splice-command <-- the hack
[23:33] <med_> "placement: local" is the LXC local provider? Or something else?
[23:34] <SpamapS> med_: placement: local causes services to be deployed to node 0
[23:34] <med_> in containers?
[23:34] <SpamapS> LXC has the ability to do copy-on-write for the 'lxc-clone' already
[23:34] <SpamapS> that would help a lot
[23:35] <SpamapS> There were also issues with scsi namespacing
[23:35] <SpamapS> perhaps somebody could go find smoser so he can comment?
[23:36] <SpamapS> yes
[23:36] <SpamapS> The CI lab charms should be the ones that are in lp:charms/* ... is that the case?
[23:37] <SpamapS> drbd should be doable as a subordinate
[23:38] <SpamapS> pacemaker needs a reliable network between nodes does it not?
[23:38] <SpamapS> SURE!
[23:38]  * SpamapS <heart> subordinates
[23:39] <SpamapS> I just wonder about how well we can define "a dedicated network between those nodes" w/o tagging in maas
[23:39] <SpamapS> drbd really needs the same thing
[23:40] <SpamapS> I want all the goodness in the main charms. No me gusta forks.
[23:40] <SpamapS> You should make your hacks subordinates.
[23:40] <SpamapS> Or config.yaml items
[23:41] <ttx> subordinates ?
[23:41] <SpamapS> I want people to be able to use the charm store to be able to repeat the CI testing. It will gather effort around CI testing of openstack around the same place rather than encouraging it to diverge.
[23:42] <SpamapS> ttx: subordinates can be used to add custom functionality to a generic charm.
[23:42] <med_> rnathuji, anything you wanted to bring up in the charm discussions?
[23:42] <SpamapS> Alright I trust you to give us all/most of the important stuff :)
[23:42] <SpamapS> Thats all I have.
[23:45] <rnathuji> no, nothing specific.  it sounds like things are in a state to try throwing onto arm clusters w/lxc as virt.  I haven't yet done that exercise, though :).  I'm also curious as to quantum support, but that sounds nascent yet.
[23:45] <SpamapS> ++++
[23:46] <SpamapS> session tomorrow about openstack+ceph/rbd
[23:47] <med_> thanks adam_g
[23:47] <SpamapS> CEPH upstream will be in attendance
[23:47] <SpamapS> ceph charm sucks
[23:47]  * SpamapS said the author
[23:47] <SpamapS> cheers!
[23:51] <SpamapS> ttx: I hear you, and I agree. Make a juju based devstack so real deployments are more like developer deployments thus eliminating disconnect bugs!
[23:52] <SpamapS>  ___________________________________
[23:52] <SpamapS> < somebody tell ttx to look up here >
[23:52] <SpamapS>  -----------------------------------
[23:52] <SpamapS>         \   ^__^
[23:52] <SpamapS>          \  (oo)\_______
[23:52] <SpamapS>             (__)\       )\/\
[23:52] <SpamapS>                 ||----w |
[23:52] <SpamapS>                 ||     ||
[23:53] <SpamapS> corvus: you sound great ;)
[23:54] <SpamapS> 10 seconds?
[23:54] <SpamapS> yes
[23:54] <SpamapS> :( I hate living in the past
[23:55] <SpamapS> so true
[23:55] <udsbotu> uds-jb-1: 5 minutes left in this session!
[23:56] <udsbotu> uds-jb-1: 4 minutes left in this session!
[23:57] <udsbotu> uds-jb-1: 3 minutes left in this session!
[23:58] <udsbotu> uds-jb-1: 2 minutes left in this session!
[23:58] <SpamapS> juju set mysql dataset-size=8M  <-- tunes mysql to use almost no RAM
[23:59] <udsbotu> uds-jb-1: 1 minute left in this session!
[23:59] <SpamapS> juju set mysql tuning-level=fast <--- tunes mysql to not use fsyncs much
[23:59] <SpamapS>  __________________
[23:59] <SpamapS> < jim look up here >
[23:59] <SpamapS>  ------------------
[23:59] <SpamapS>         \   ^__^
[23:59] <SpamapS>          \  (oo)\_______
[23:59] <SpamapS>             (__)\       )\/\
[23:59] <SpamapS>                 ||----w |
[23:59] <SpamapS>                 ||     ||


[00:13] <infinity> xnox: It doesn't need to be fixed in eglibc at all, stokachu was testing a fix I gave him for the hugetlbfs package.
[00:17] <infinity> slangasek: Yeah, as xnox said, the jenkins pass/fail seemed a reasonable enough test-case, despite the lack of SRU headers in the description to that effect.
[01:26] <slangasek> xnox, infinity: perfect, thanks
[03:56] <infinity> slangasek: I kinda want to close #1001904 with extreme prejudice, but I'm curious why you didn't do so, rather than triaging and assigning it.
[04:11] <slangasek> infinity: at this point I don't recall
[04:12] <infinity> Yeah.  I totally missed the assignment happening, just noticed it when wandering through bugs that were assigned to me.
[04:12] <infinity> But, it only happens if you mix-and-match precise and hardy.  And it's a by-product of apt freaking out and trying to install all the Essential packages you're missing.
[04:13] <infinity> Which is a handy and useful feature.
[04:13] <slangasek> infinity: I agree we don't support installation of hardy packages on later releases; and the pastebin is long gone now; grepping logs now
[04:13] <infinity> But not if you're silly enough to include ancient sources.
[04:13] <infinity> At least, I assume that's what's happening, cause I can't fathom anyone doing this to themselves on purpose.
[04:13]  * infinity tosses hardy in a precise chroot for a second to see.
[04:15] <slangasek> infinity: per the meeting logs, the reason people were doing this is because there's a sun-java package still in the hardy release pocket and they're trying to install it
[04:15] <infinity> Ahh.
[04:15] <infinity> Well, we could reintroduce the Replaces, but I really don't think we should carry it "forever" just for this odd use-case.
[04:16] <infinity> Or reintroduce the sysvutils transitional package.
[04:16] <slangasek> so if you have logs handy, there was a long discussion in #ubuntu-meeting on 2012-06-06
[04:16] <infinity> And yeah, just confirmed that adding hardy to sources.list and dist-upgrading pulls in sysvutils
[04:18] <slangasek> infinity: if you think wontfixing it is the thing to do, I don't have any objection; I think the bug assignment was "delegating" :)
[04:19] <infinity> Yeah.  I'm reading the log, and not sure we came to a conclusion, per se.
[04:19] <infinity> The other option is to reintroduce either the replaces or transitional package just for precise, since by the time 14.04 ships, hardy will be EOL, and people still doing this from old-release will be extra insane.
[04:20] <infinity> But the grumpy old man in me is more on the Won't Fix side of that fence.
[23:06] <xnox> infinity: ok thanks. Unsubscribed sponsors from the eglibc bug in that case. Thanks for reducing the sponsorship queue \0/
[23:12] <stgraber> Riddell, ScottK: will Kubuntu do an alpha-1 release?
[23:27] <phillw> stgraber: do you know who is responsible for the naming of the daily build iso's via the cron job?
[23:30] <stgraber>  /win 43
[23:31] <stgraber> phillw: what are you referring to?
[23:32] <phillw> stgraber: I've had a bug reported... all the network iso's are called mini.iso
[23:32] <stgraber> and why is that a bug?
[23:32] <phillw> well, try loading two of them, then using zsync?
[23:32] <phillw> i686 / AMD64...
[23:33] <stgraber> just store them on your machine with a different filename?
[23:33] <phillw> http://archive.ubuntu.com/ubuntu/dists/raring/main/installer-amd64/20101020ubuntu195/images/netboot/mini.iso
[23:33] <stgraber> besides, you can't zsync them as they are on archive.ubuntu.com, not on cdimage
[23:33] <phillw> http://archive.ubuntu.com/ubuntu/dists/raring/main/installer-i386/20101020ubuntu195/images/netboot/mini.iso
[23:34] <stgraber> sure, that's the filename that debian-installer has always been using for the netboot images, changing that would break a lot of things for close to no benefit
[23:34] <phillw> So, they are being built daily, but in a totally different naming schedule to the all the isos?
[23:34] <stgraber> they're not built daily
[23:35] <stgraber> they're built as part of a debian-installer package build, so they're built whenever someone uploads a new debian-installer to the archive
[23:35] <phillw> okies, thanks.. i'll be able to reply to the tester for which the names are causing problems
[23:35] <stgraber> and they're built through the package build process, not through the image build process, that's why they're on archive.ubuntu.com as are all binary packages and not on cdimage.ubuntu.com
[23:35] <cjwatson> And it's perfectly possible to supply a different output file name when using zsync.
[23:36] <cjwatson> Or rsync or whatever.
[23:36] <xnox> phillw: zsync -o flag or wget -O flag.
[23:37] <cjwatson> I'm responsible for those file names and I won't change them.
[23:37] <phillw> I see that they only have direct (http) entry for download... sorry.. i didn't look deep enough into the issue reported by the tester.
[23:38] <phillw> cjwatson: is it possible to zsync when there is no zsync link?
[23:38] <xnox> phillw: yes.
[23:38] <cjwatson> If it is, it will provide no meaningful benefit over just using wget.
[23:38] <xnox> phillw: it will redownload the whole file =)
[23:39] <phillw> okies, I'll mark it down as "won't fix" :) Thanks for clearing it up.


[08:41] <astraljava> Hey guys, I know this ain't the correct place but seeing I won't get an answer over the mainline, and there are some really bright and knowledged minds here, I'm gonna try anyway.
[08:41] <astraljava> Anyone know or are in possession of a whitepaper or something similar where Canonical explains how they ensure the security of the official repositories?
[08:42] <astraljava> My google-fu is failing me atm. Cheers!
[14:33] <pleia2> astraljava: maybe ask the folks in #canonical-sysadmin?
[14:46] <astraljava> pleia2: Okay, I'll try there. Thanks a lot! :)
[14:59] <jphilips> bluesabre: any update on the meeting?
[20:09] <xubuntu1804> Hi, I am still on Xubuntu LTS 18.04. Unlike two years ago, I have not yet received a message from apt to distro upgrade to 20.04.1. Is that normal?
[21:27] -SwissBot:#xubuntu-devel- ::xfce4-announce:: ANNOUNCE: libxfce4util 4.15.3 released @ http://xfce.10915.n7.nabble.com/ANNOUNCE-libxfce4util-4-15-3-released-tp59394.html (by Simon Steinbeiss)
[21:34] -SwissBot:#xubuntu-devel- ::xfce4-announce:: ANNOUNCE: Xfce 4.16pre1 released @ http://xfce.10915.n7.nabble.com/ANNOUNCE-Xfce-4-16pre1-released-tp59395.html (by Simon Steinbeiss)
[22:58] <RikMills> bug reports says this is still impacting xubuntu LP: #1885414
[23:56] <Unit193> ochosi: Should X-GNOME-Gettext-Domain be handled in libxfce4util?
[23:56] <Unit193> http://codesearch.debian.net/search?q=X-GNOME-Gettext-Domain&literal=1


[14:56] <dkessel> hello. i have applied for an ubuntu membership certificate in december and have not received it yet. is this the right channel to find someone who can do something about that?
[16:16] <pleia2> dkessel: folks in here should at least know who to ask :)
[16:16] <pleia2> I never got mine either actually, I requested back in august or something
[16:19] <dkessel> pleia2: thanks, I dleOne and h ggdh already helped me
[16:19] <pleia2> ah ok
[17:17] <IdleOne> well, we helped you with something else :) I still have no idea who to poke about the certificates
[19:42] <jose> IdleOne, pleia2: the person to poke would be Michelle
[19:57] <jose> popey: is Katie Taylor still Canonical?
[19:59] <popey> jose: no
[20:00] <jose> popey: who will be hosting the Design Clinic on Wednesday, then?
[20:01] <popey> jouni
[20:07] <jose> that's his/her IRC handle?
[20:08] <popey> jounih is his irc nickname.
[20:08] <popey> Jouni Helminen is his full name, he's lead visual designer at canonical
[20:09] <jose> cool, good to know
[20:10] <jose> calendar has been updated with him as the speaker
[20:10] <popey> thanks jose
[20:10] <jose> sure :)


[09:59] <xnox> slangasek: or stgraber: please review https://code.launchpad.net/~xnox/upstart/bug-1199778/+merge/174372 to unblock SRU. stgraber - wasn't there something else that needs to go in the SRU? (we now pulled the last one)
[09:59] <xnox> in the mean time I'm preparing saucy upload.
[10:00] <xnox> stgraber:  lp:~ubuntu-core-dev/ubuntu/raring/upstart/raring
[13:17] <stgraber> xnox: the respawn fix
[13:18] <xnox> stgraber: ack. So we need to cherry-pick the respawn fix, above chroot-reexec-fix. Can you review above merge-proposal, if you are in the mood for upstart subtle bugs =)
[13:25] <stgraber> xnox: I'll take a look once I'm fully awake ;) currently still at the processing IRC backlog and e-mails phase ;)
[14:52] <stgraber> ok, I think I'm as awake as I'll be today, taking a look at that branch now
[15:32] <stgraber> xnox: should test_session_upgrade do some checks of the unserialized data or is checking the return code sufficient?
[15:33] <xnox> stgraber: i think it should be checking unserialized data for a complete test.
[15:33] <xnox> stgraber: checking the return code is sufficient test for the bug in question: "upstart upgraded failed with active chroot session"
[15:34] <stgraber> xnox: ok, can you add some tests to at least ensure those lists and hashes contain stuff post-unserialization? I don't think we need a ton of asserts but just checking that they aren't empty anymore would be nice
[15:34] <xnox> right, I see what you mean.
[15:39] <xnox> stgraber: and that caught a bug =)
[15:43] <stgraber> xnox: yay!
[17:04] <xnox> stgraber: so, pushed more asserts. As it turns out chroot-sessions only have CONF_JOB_DIR, unlike normal system init which has CONF_FILE & CONF_JOB_DIR.
[17:04] <xnox> stgraber: so it checks that the correct session got deserialised with proper conf sources and that none of the job classes belong to a session.
[17:05] <xnox> stgraber: since we don't deserialise those at the moment.
[17:12] <xnox> stgraber: right, I'm off to my lunch break....
[17:12]  * xnox scratches head
[17:12] <xnox> will be back to poke upstart or android a bit more.


[13:22] <sparkiegeek> is https://launchpad.net/~ubuntu-mozilla-daily/+archive/ubuntu/ppa the right place to get Firefox Nightly builds ?
[13:22] <sparkiegeek> it's not clear to me why that latest update was 3 weeks ago
[13:23] <sparkiegeek> e.g. mozilla.org download links have 54.0a1
[13:48] <dexterp> sparkiegeek, as far as I know that's the correct link
[14:22] <ricotz> sparkiegeek, it is the correct place, but only updated as needed
[14:22] <sparkiegeek> ricotz: what does "as needed" mean?
[14:23] <ricotz> to catch up with upstream change which require packaging updates
[14:23] <sparkiegeek> ricotz: what determines the schedule of updates?
[14:23] <sparkiegeek> ah, so package version doesn't rev when the day changes?
[14:23] <ricotz> the beta ppa is updated more frequently as the upstream beta releases are tagged
[14:24] <sparkiegeek> I'm trying to find a PPA that lets me easily consume Firefox Nightly
[14:24] <ricotz> the version *do* reference the day of change
[14:24] <sparkiegeek> e.g. will normally change 1/day
[14:26] <ricotz> if you really require that pace of updates you likely want to follow upstream directly by using their builds
[14:26]  * sparkiegeek nods
[14:26] <sparkiegeek> but I guess they're not shipping .deb s? (nor .snap s)
[14:29] <ricotz> I don't think so, there are tars which include an auto-upate mechanism, so you can install it to e.g. ~/bin/firefox/*
[14:41] <chrisccoulson> https://launchpad.net/~ubuntu-mozilla-daily/+archive/ubuntu/ppa isn't going to be building anything again until we've bootstrapped rustc everywhere (currently being worked on)
[14:43] <sparkiegeek> chrisccoulson: ack, thanks


[15:47] <kyrofa> cjwatson, using the LP snap builders, is there a way to automatically upload to a store account not associated with my SSO?
[15:49] <wgrant> kyrofa: There isn't. I'd do that by adding my account as an admin on that snap's store page.
[15:50] <kyrofa> wgrant, go to bed man :P
[15:50] <kyrofa> wgrant, but that's interesting, I didn't actually realize such things were supported. I wonder why the Canonical shared account isn't set up that way
[15:50] <wgrant> kyrofa: It's a relatively new feature, I think.
[15:50] <kyrofa> Historical reasons, I imagine
[15:50] <kyrofa> Ah
[15:50] <wgrant> kyrofa: It's called "Sharing" in the store UI, but that will be renamed this week.
[15:51] <kyrofa> wgrant, alright I'll look into that. Also, any idea why requesting snap builds results in a timeout error?
[15:51] <kyrofa> (Error ID: OOPS-5abd3fe96a8cc9172e36fd54a178d434)
[15:51] <wgrant> kyrofa: That's why I'm still awake :P
[15:51] <kyrofa> *cough*
[15:52] <kyrofa> Sorry man
[15:56] <kyrofa> wgrant, "Sharing" seems to be specific to each snap, correct? And if I "share only with" myself, I'll be able to upload it? The phrasing makes it sound like it's only for letting people download it
[15:56] <wgrant> kyrofa: Hence the in-progress rename.
[15:57] <kyrofa> wgrant, but functionally, it allows me to upload/publish new revisions?
[15:57] <wgrant> kyrofa: Yep
[15:57] <kyrofa> wgrant, great, thanks!
[15:57] <wgrant> np
[16:13] <wgrant> kyrofa: Should be working now.
[16:13] <kyrofa> wgrant, now I can't visit the snap itself:  (Error ID: OOPS-1fe2ad5c87d469cf6036bbf7c1a7de4e)
[16:13] <wgrant> kyrofa: Ah, heh.
[16:14] <wgrant> Requesting the build should work fine.
[16:14] <wgrant> Or just submit a no-op edit form somewhere, and things will work.
[16:14] <wgrant> Or just wait a few minutes.
[16:14] <wgrant> (if you haven't POSTed in a while, you'll be on a slave DB. and given what we just unblocked the slave might take a few minutes to catch up with the fix)
[16:18] <kyrofa> wgrant, ah ha, brilliant
[16:19] <kyrofa> wgrant, verified, seems to be working fine now, thank you!
[16:19] <wgrant> Lovely.
[16:20] <kyrofa> wgrant, last question: is there a way to "share" a snap that has been registered but has no uploads?
[16:20] <wgrant> kyrofa: I don't think so. I believe it's only a name until there's an upload, at least at the moment.
[16:21] <kyrofa> wgrant, alright, that's what I thought, just checking
[16:21] <kyrofa> Now go to bed!
[16:21]  * wgrant obeys.


[00:42] <darkmatter> vish: eat message style and die! http://i.imgur.com/SCrNb.png :D
[05:57] <hyperair> sb levelclear -level clientcrap,crap,joins,parts,quits,nicks,clientnotice
[12:40] <vish> zniavre: what is the class/widget_class for combobobox text color?
[12:41] <vish> i'm able to change the bg color for the box, but just not the text :s
[12:45] <vish> yay! found it! i ended up using gtkparasite on twf :D
[13:01] <zniavre> sorry i just came nack from school
[13:01] <zniavre> back*
[14:51]  * vish scratches head..
[14:51] <vish> why do people think i'm trying to remove some feature!
[14:52] <vish> heh, and i wonder what customization has to do with anything that i wrote ;p
[14:53] <thorwil> vish: that's all you are about, isn't it? vandalizing the wiki and removing their precisous features!!!
[14:53] <vish> hehe!
[14:55] <thorwil> vish: zekopeko's most recent reply on the design problem thread is most excellent, though
[14:56] <vish> oh? /me checks
[14:57] <vish> ha! yea, i thought i'd just ignore that reply about customizations..
[14:57] <vish> is there some site which says "FOSS is about choice" !!!
[15:05] <Islington> I have always had trouble swallowing zeko's argument, even when I read in the mouth of some gnome person
[15:06] <coz_> Islington,  is there another mailing list thingy?
[15:06] <Islington> coz_: this is on the ayatanna list
[15:06] <coz_> oh?
[15:06] <coz_> mm
[15:07] <coz_>  Islington  it is worth subscribing to?
[15:07] <Islington> honestly? no
[15:07] <coz_> lol
[15:07] <Islington> a lot of circlejerking and very few actual descicions afa have seen
[15:08] <coz_> Islington,  sounds typical mailing list stuff
[15:08] <Islington> The problem with the argument for me has always been that it degrades the value of customization in FOSS.
[15:10] <Islington> customization as a feature
[15:10] <coz_> Islington,  shouldnt you be saying this on #ayatana as well ??
[15:11] <Islington> nah just responding to vish's comments above
[15:11] <coz_> oh sorry ,, I will have to read scroll back
[15:11] <Islington> I was just before you logged in lol
[15:12] <Islington> *It
[15:12] <coz_> oops  didnt have xchat opened on the other machine,, cant read scrollback,,,darn
[15:13] <vish> Islington: right, customization is a feature sure, but not a must have.. , heck! even i want to customize.. :)
[15:13] <coz_> oo customizatioin is the issue ?
[15:14] <Islington> not a must have vish? Its one of the most important features that differentiates linux now
[15:14] <vish> but i really dint know what anything in my reply had to do with customization
[15:14] <coz_> Islington,  absolutely
[15:14] <Islington> customizing both windows/mac is incredibly tedious, but I agree its way off topic
[15:15] <coz_> well "customization"  is sort of artsy :)
[15:15] <vish> Islington: yea surely, not the way Canonical does stuff. there must be a way for things to plugin
[15:15] <vish> Canonical does have a tendency to not allow easy ways to plugin and change things though..
[15:15] <Islington> coz_: lol off topic to the topic on list
[15:16] <coz_> oh :)
[15:16] <Islington> vish: that particular problem is endemic to gnome
[15:16] <Islington> with its rejection of compiz especially
[15:17] <vish> that was STUPIDITY!
[15:17] <coz_> gnome is a pain inthe A@@
[15:17] <coz_> as far as choices / customization goes
[15:17] <vish> seriously, i can not digest the fact that they blatantly rejected Compiz from even participating in GNOME Shell
[15:18] <vish> their reasons were total bullcrap!
[15:19] <vish> if not for compiz, i would bet GNOME would have had less than 25% of users they have now
[15:19] <coz_> well,, in some respects..compiz poses a threat,, in a minor way,, I was talking about compiz as a DE  long ago... lately ,, I have been reading more people wanting to to actually be realized,, I doubt it will
[15:20] <Islington> it can be a de, with compiz-menu
[15:20] <vish> well, Compiz DE is not Unity :D
[15:20] <vish> s/not/now*
[15:20] <coz_> this is true
[15:22] <coz_> Islington,  well compiz + cairo dock is really all you need
[15:22] <vish> yay! cairo dock!
[15:22] <coz_> Islington,  and of course  kde and or gnome libraries
[15:22] <coz_> vish,  :)  I am "forced" to agree :)
[15:22] <Islington> I never got into cairo dock, awn was good though
[15:23] <coz_> Islington,  oo dude,, cairo dock is far more configurable
[15:23] <Islington> oh yeah, I remember
[15:23] <vish> coz_: DBO threw a fit when he saw me using cairo-dock! haha! ;p
[15:23] <coz_> Islington,  the config dialog is not very far off from ccsm
[15:23] <coz_> vish,  are you serious?
[15:23] <coz_> vish,  why the hell would he be peeved at that?
[15:24] <coz_> Islington,  and with nearly as many options as compiz
[15:24] <vish> coz_: well, not for too long.. just that he was like : Cairo-dock is blasphemy or something similar
[15:24] <coz_> vish,  oh man,, some developers are just  nuts  :)
[15:26] <vish> coz_: i think he dint expect to see people actually using cairo-dock! ;)
[15:26] <vish> or any dock other than Docky ;p
[15:26] <coz_> vish,  strange,, :)
[15:26] <vish> coz_: well, Docky is quite popular, and does seem to have a large user base
[15:27] <coz_> vish,  I know ,, I have tried it,, not as nice in my opinion
[15:27] <coz_> but I have to be predjudiced about it :)
[15:28] <vish> i actually wonder what Canonical plan is for Touch, they seem to be investing a lot of time+effort in that
[15:29] <coz_> vish,  that touches on one of my pet peeves.. I would like a detailed listing of exactly what is "canonical's ( shuttleworth's) long term vision for ubuntu in general
[15:32] <vish> i'm quite certain(which is my best guess of-course) they have someone from design team working on a touch device (or something close to it)  with some device manufacturer
[15:32] <coz_> vish,  hopefully,, touch is , again, a big thing, especially since the advent of  iPad
[15:33] <coz_> but  windows 95 had a pen tablet years ago... it never really caught on except in some busnesses/ corporate envionments
[15:33] <coz_> I would prefer the more accurate,  pen tablet, which is generally drive by wacom
[16:30]  * vish wonders if i was too rude on Bug 737183 ?
[16:30] <ubot2> Launchpad bug 737183 in humanity-icon-theme "Home folder icon should be a *folder* with the home symbol, not a home symbol" [Wishlist,Opinion] https://launchpad.net/bugs/737183
[16:33] <coz_> vish,  nah,, sounds right to me
[16:34] <vish> *phew* , dint expect Mark to just accept it … ;)
[16:34] <coz_> vish,  really? cool
[16:34] <vish> coz_: yea, he filed that bug, and i closed it ;)
[16:34] <coz_> :)
[18:34] <Ronnie> For a project in our local community im creating a webchat app based on IRC (maybe/hopefully this will result in chat.ubuntu.com sometime). I made some mockups and want some feedback on this. so fire away
[18:34] <Ronnie> http://img228.imageshack.us/i/plains.png/
[18:34] <Ronnie> http://img857.imageshack.us/i/contacts.png/
[18:34] <Ronnie> http://img62.imageshack.us/i/topicm.png/
[18:34] <Ronnie> http://img843.imageshack.us/i/mouseonheader.png/
[18:34] <Ronnie> http://img199.imageshack.us/i/textinputselected.png/
[19:00] <vish> Ronnie: looks good, but i'm confused which channel is focussed there, is it ubuntu-nl or ubuntu-nl-mwanzo?
[19:00] <vish> if its not the second channel, why is it underlined?
[19:00] <Ronnie> the first channel is active, the second channel has "new messages"
[19:00] <vish> ah!
[19:03] <vish> Ronnie: you could play with just using color/bold/italics and see how that works, to me it is a bit confusing atm
[19:03] <Ronnie> good idea, ill have a shot
[19:14] <Ronnie> vish: http://oi56.tinypic.com/25kirmt.jpg
[19:14] <Ronnie> not yet what i expected
[19:15] <vish> hmm, maybe with the orange color it might be better
[19:15] <Ronnie> what if i put the color on the top instead of bottom on the tab?
[19:17] <vish> might work, but it would still seem like "selected" , what about just using an icon for new messages? (a color chat bubble)
[19:18] <Ronnie> http://oi56.tinypic.com/21dg710.jpg
[19:19] <vish> heh, now its just  barely visible :D
[19:19] <Ronnie> is possible, but could make the tabsbar make "jumpy"
[19:19] <vish>  you could just use the icon as a partial-overlay,
[19:20] <vish> but just colored text should work IMO, most clients just do that.. or the blinking bubble
[19:21] <Ronnie> thats possibe. do you know any method to make difference between "new messages" and "new messages with your name in it"
[19:21] <Ronnie> colored tekst is also possible, but orange is very ugly on that 'grey', and i dont want to introduce more colors
[19:22]  * vish nods
[19:22] <vish> maybe using " @ " for messages with name?
[19:23] <Ronnie> vish would you like to have the xcf file to play around with?
[19:23] <vish> sure, but not right now.. :)
[19:25] <Ronnie> aargg, ubuntuone is down
[19:28] <Ronnie> vish: what about a line under the channelname, or does that look too much like a link
[19:30] <vish> not sure, would need to actually see it.. :)
[19:32] <Ronnie> vish: http://www.2shared.com/file/RgpjlcGI/Visual.html <== gimp file (made with the beta, contains layer groups)
[19:33] <vish> cool! will play with it.. :)
[19:33] <Ronnie> http://img834.imageshack.us/i/activetabvariations3.png/
[19:38] <Ronnie> vish, glow - shadow should be possible too
[19:39] <vish> Ronnie: ha! exactly what i was thinking right now! :)
[19:39] <Ronnie> have to go now
[19:39] <Ronnie> ill be back later
[20:30] <darkmatter> heya coz_
[20:36] <coz_> darkmatter,  hey guy :)  watching all variation of numa numa guy :)
[20:37] <darkmatter> coz_: cool. just collecting some crap and starting a theme extravaganza. tm just slightly hacked template stuff, but whatever
[20:37] <darkmatter> http://i.imgur.com/SCrNb.png
[20:38] <coz_> nice
[20:38] <coz_> darkmatter,  which client is that?
[20:39] <darkmatter> coz_: not my theme bits atm. just a "reference template" for the general mood
[20:39] <darkmatter> empathy
[20:39] <coz_> darkmatter,   ok cool,, never used empathy
[20:39] <darkmatter> modded 'fluffy' wip from adium for the style
[21:39] <Ronnie> back