[04:07] <StevenK> pitti: O hai! I spent some time on the weekend trying to get ekiga to build with the new opal and pt, and it's hopeless. :-(
[04:10] <pitti> Good morning
[04:10]  * micahg thought pitti uploaded a new version of htat
[04:10] <pitti> StevenK: but I already uploaded the new ekiga which works fine
[04:10] <pitti> StevenK: I mentioned that on the bug which opal and ptlib referenced
[04:10] <pitti> StevenK: sorry about the double-work
[04:12] <pitti> bdmurray: it's meant to mark the bug as a dupe of the real master bug
[04:16]  * mneptok waves to pitti
[04:17]  * pitti throws some candies towards mneptok
[04:17] <pitti> mneptok: how are you?
[04:17] <mneptok> pitti: great, thanks!
[04:17]  * mneptok is on a month-long vacation, and is quite relaxed
[04:18] <pitti> mneptok: sounds nice! you are spending it at home, or in the internets? isn't that a good time for travelling etc.?
[04:19] <pitti> uh, half of the armel builders offline?
[04:20] <micahg> pitti: system upgrades, I was told they should be back soon
[04:20] <mneptok> pitti: i spend most days on the motorcycle riding around New Mexico
[04:20] <pitti> ah, cheers
[05:15] <ScottK> slangasek: honeyd FTBFS when rebuild (needed for NBS) looks somewhat multi-arch like to me.  The error is "configure: error: Couldn't figure out how to access libc"
[05:16] <lifeless> ScottK: win!
[05:16] <ScottK> It is because it's clearly too hard for me, so somebody else's problem ...
[05:35] <micahg> doko_: pitti: hopefully by EOD you can remove the old libav binaries (uploaded and building)
[05:35] <pitti> micahg: yay
[05:43] <didrocks> good morning
[05:50] <ScottK> didrocks: I'm about to go sleep, since it's very late here, but I'd appeciate it if you could look into the qt4-x11 build failures today.
[05:55] <didrocks> ScottK: I'll try having a look, not sure I got time (already busy schedule), but will try (saw some build failure on arm, right?)
[06:21] <tkamppeter> pitti, hi
[06:25] <pitti> tkamppeter: hey, how are you? enjoyed your holidays?
[06:52] <doko> didrocks, ScottK see the ftbfs report
[06:52] <didrocks> doko: do you have a bug # handy? (did you subscribe me to it? I didn't see it)
[06:53] <didrocks> I guess it's bug #847224
[06:53] <doko> didrocks, see http://qa.ubuntuwire.org/ftbfs/
[06:55] <didrocks> doko: yeah, I'll see that with ScottK about what to do to reduce the build time as it's the timeout killing the build
[06:55] <didrocks> same on powerpc it seems
[06:56] <micahg> wow, it used to be 10 hrs on armel, I guess it was raised
[06:56] <didrocks> micahg: it's a timeout of no activity while building the documentation
[06:57] <micahg> didrocks: I understand, the timeout used to be 10 hrs, I guess it's now 13.3
[06:57] <doko> 800min ...
[07:00] <didrocks> doko: anyway, the -doc packages are arch:all as you infered, let me see how to disable the build for other archs
[07:07] <didrocks> hum, nice, seems Qt doesn't have an option to disable the build of documentation
[07:08] <didrocks> seems it will need a painful patch arch-dep
[07:09] <dholbach> good morning
[07:10] <poolie> hi all
[07:10] <poolie> could someone from the sru team (or archive admin?) promote the fix for https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/736216 in natty?
[07:10] <didrocks> hey dholbach, poolie
[07:11] <poolie> hi there
[07:11] <poolie> ... or, let me know what needs to be done
[07:14] <dholbach> hey didrocks, hi poolie
[07:15] <poolie> hi there
[07:15] <doko> cjwatson, so building with -DGDK_DISABLE_DEPRECATED seems to be as bad as -Werror ...
[07:18] <poolie> didrocks, could you suggest what i should do to get that sru to move?
[07:19] <doko> micahg, did the qt4 security upload fail with this doc timeout too?
[07:20] <didrocks> poolie: it seems you subscribe the ubuntu-sru team to it, isn't it? but the Natty curl status is fix committed, is there any reason?
[07:20] <didrocks> "Accepted curl into natty-proposed" oh, it's already in -proposed
[07:20] <poolie> i think the state is fixed in -proposed, not yet fixed in -updates
[07:21] <poolie> it's in proposed
[07:21] <poolie> it apparently works
[07:21] <poolie> it needs to go into -updates
[07:22] <didrocks> yeah, and there is verification-done-natty (but still verification-needed, I guess for other?) not sure if that puzzles pitti's script
[07:22] <poolie> perhaps that's it
[07:22] <didrocks> let's wait for him to have some time to have a look :)
[07:23] <pitti> v-done-release is an invention of the kernel team, this tag isn't recognized by the SRU report page
[07:23] <pitti> it should just be v-done
[07:23] <pitti> anyway, can release now
[07:23] <poolie> thanks
[07:23] <pitti> done
[07:29] <poolie> thanks pitti
[07:49] <dholbach> @pilot in
[07:53] <poolie> i'm surprised that ntfs mounts with umask=0 by default, although mount(8) says it's umask=077
[07:53] <poolie> is that an intentional ubuntu change?
[07:55] <tkamppeter> pitti, it is about bug 807261, the problem of cups-pk-helper breaking s-c-p.
[07:55] <tkamppeter> pitti, I have added a longer comment to it.
[07:56] <jamespage> morning all
[07:56] <jamespage> doko - any chance you could sponsor those two branches you reviewed for me on Friday?
[08:19] <doko> jamespage, sure
[08:19] <jamespage> doko: thanks
[08:29] <cjwatson> micahg: some of libav will still have to wait for insighttoolkit to finish its eight-day or whatever it is armel build so that itksnap and vmtk can be fixed - but yes, gnash was the other blocker, so thanks!
[08:30] <cjwatson> doko: yeah, it should be a maintainer-only thing rather than a release tarball thing
[08:30] <cjwatson> doko: also -DALLSORTSOFOTHERTHINGS_DISABLE_DEPRECATED
[09:02] <tkamppeter> pitti, ping
[09:05] <pitti> tkamppeter: pong
[09:12] <tkamppeter> pitti, have you seen my message above?
[09:12] <pitti> tkamppeter: yes; do you need me to do anythign with this bug?
[09:13] <tkamppeter> pitti, I want to know what you think is the best solution without loosing any functionality.
[09:14] <tkamppeter> pitti, There are the following possibilities:
[09:14] <pitti> why do we need cups-pk-helper?
[09:14] <pitti> for s-c-p?
[09:14] <pitti> we haven't before
[09:14] <pitti> I thought it's only needed for the upstream control-center printer capplet
[09:14] <pitti> (which we don't use in ubuntu/unity, just with gnome shell
[09:15] <tkamppeter> pitti, s-c-p does not need cups-pk-helper, so if there is nothing else needing it, one could simply make sure that it does not get pulled into the default installation.
[09:15] <pitti> tkamppeter: it doesn't
[09:15] <pitti> tkamppeter: if you install gnome-shell, it will be pulled in
[09:16] <tkamppeter> pitti, what pulls it in currently is gnome-shell and gnome-shell I have installed, probably because my Oneiric is grown out of daily updates from Natty.
[09:16] <pitti> does it hurt to have it installed?
[09:16] <tkamppeter> pitti, we must assure that updaters from Natty and older will not get cups-pk-helper pulled in.
[09:17] <pitti> the upstream capplet is hidden in the control center under UNity
[09:17] <pitti> so nothing ought to invoke it?
[09:17] <pitti> tkamppeter: why?
[09:17] <pitti> tkamppeter: I thought s-c-p wouldn't use cups-pk-helper; you mean it does?
[09:17] <tkamppeter> pitti, yes, if cups-pk-helper is installed, s-c-p asks for an admin password, even if the user is in the lpadmin group.
[09:17] <pitti> bah
[09:18] <pitti> it oughtn't
[09:18] <pitti> tkamppeter: we can't assure that cups-pk-helper isn't installed, as people might have gnome-shell installed
[09:19] <cjwatson> hyperair: could you please confirm my last comment in bug 756161?
[09:19] <pitti> tkamppeter: can we disable cups-pk-helper support in s-c-p easily? does it have a configure option?
[09:19] <tkamppeter> pitti, I can also patch away the cups-pk-helper support in s-c-p by adding only two lines.
[09:19] <tkamppeter> pitti, it is not a configure option, it is setting a variable to False at two points.
[09:20] <hyperair> cjwatson: ah, that package's been obsoleted by geany-plugins afaik
[09:20] <hyperair> cjwatson: rm please
[09:20] <cjwatson> hyperair: right, that was what I said in my comment :)
[09:20] <cjwatson> hyperair: shouldn't geany-plugins-doc Breaks/Replaces geanydoc as well though?
[09:20] <hyperair> did you?
[09:21] <cjwatson> hyperair: oh, it might not quite have saved yet when I asked you, reload
[09:21] <pitti> tkamppeter: do you think that would be okay? it seems like the best solution to me
[09:21] <tkamppeter> pitti, best solution would be to fix cups-pk-helper to support the user-in-lpadmin-group case, but probably this is more work, and not easy to project into the architecture of PolicyKit.
[09:22] <pitti> tkamppeter: right
[09:22] <pitti> tkamppeter: I think if/when we switch to cups-pk-helper and the upstream applet, we'll deprecate lpadmin in the desktop
[09:22] <hyperair> cjwatson: right, i guess it should.
[09:22] <pitti> it's one of the few "hardware access" groups that we still have, and it's a thorn in the eye
[09:22] <cjwatson> hyperair: want a separate bug?
[09:23] <hyperair> cjwatson: actually no. geanydoc is the source package name.
[09:23] <hyperair> cjwatson: geany-plugin-doc is the binary package name
[09:23] <cjwatson> oh
[09:23] <hyperair> Package: geanydoc
[09:23] <hyperair> Binary: geany-plugin-doc
[09:23] <hyperair> Version: 0.4-0ubuntu3
[09:23] <pitti> tkamppeter: we can then even configure polkit to allow access to local printers from a local desktop session (as these users have physical access anyway)
[09:23] <cjwatson> so it's just an orphaned source package then, fine
[09:23]  * cjwatson really must produce a report of those
[09:23] <hyperair> well more like it should have been removed
[09:23] <hyperair> i thought i got rid of all those already
[09:23] <hyperair> hmm
[09:25] <cjwatson> hyperair: oh well, this one's gone now, thanks
[09:26] <hyperair> cjwatson: geanyprj also needs to be removed.
[09:26] <hyperair> and that should be it.
[09:27] <cjwatson> hyperair: that was done a while back, bug 825069
[09:27] <hyperair> ah okay.
[09:27] <hyperair> then that should be it :-)
[09:27] <cjwatson> excellent
[09:27] <tkamppeter> pitti, another solution would s-c-p trying cups authentication not allowing a password prompt and only if the authentication fails try cups-pk-helper and as last mean try cups authentication with password. But this would be a bigger change, perhaps not doable for Oneiric.
[09:28] <pitti> tkamppeter: yeah, that even sounds upstreamable then
[09:30] <tkamppeter> pitti, this would be a good idea, switch to PolicyKit instead of lpadmin-group-based access in s-c-p (keep lpadmin group only for the command line utils of CUPS) and allowing general access to locally defined print queues for local desktop users.
[09:31] <tkamppeter> s/general access/general passwordless access/
[09:39] <Daviey> Does syncpackage, when sponsoring a sync with a bug number default to giving attribution to the bug reporter?
[09:39] <tumbleweed> not yet
[09:39] <Daviey> tumbleweed: thanks.
[09:40] <tumbleweed> Daviey: Bug 827608
[09:41] <tumbleweed> actually that's not even the sponsorship one, that's just a pre-requisite
[09:41] <Laney> that was about self syncs
[09:41] <Laney> sponsored syncs are in another one
[09:42] <Laney> ah, which is linked frmo there: bug 827555
[09:42] <Daviey> tumbleweed: ah! making good progress :)
[09:42] <tumbleweed> Daviey: unfortunatly the sponsorship one is of low importance, so it may take a while...
[09:43] <Laney> we can probably get people interested
[09:44] <Laney> they seem good like that on this feature
[09:45] <Daviey> \o/
[09:46] <Daviey> Well i just did a sync which should have been sponsored, and yes - i now feel like an ass.
[09:46] <Daviey> I don't think the chap will mind, thankfully.
[09:47] <Laney> did the tool make you think it was going to be credited correctly?
[09:47] <tumbleweed> it looks like we're going to have to sneak one more upload in, we can mention that
[09:48] <Daviey> Laney: well.. i hoped :).. Considering it said i /could/ overwrite it if i appended --no-lp
[09:48] <Daviey> so i thought! Ah!, it must be smart enough :)
[09:48] <Daviey> Although, i did suspect it might not be.. having ack-sync pulled out from under me was kinda frustrating.
[09:50] <tumbleweed> I don't think it's worth using --no-lp just for sponsorship attribution (I asked sponsorees if they minded not being attributed, and they didn't care)
[09:55] <Laney> :q
[09:56] <Laney> there appear to not be any open sync requests to test how sponsor-patch works
[09:56] <Laney> woe
[09:57] <Daviey> So syncpackage is still expected to close the bug, and not launchpad?
[09:57] <Daviey> Not ideal when the sync isn't automagic.
[09:57] <Daviey> as in, NEW.
[09:57] <Daviey> Laney: I have one you can hijack.
[09:58] <Laney> that's no worse than how it was before, but it might have been an opportunity to only close bugs on publication, indeed
[09:59] <tumbleweed> but there's another feature request bug open for this
[10:00] <tumbleweed> (although I doubt that'll help with the NEW case)
[10:15]  * didrocks wonders why he gets some FTBFS on other deps not yet published on the same arch (explicitely set in debian/control)
[10:16] <didrocks> was the same with unity-2d last Friday
[10:19] <tkamppeter> pitti, for me it looks like that the quickest solution to solve the s-c-p/cups-pk-helper incompatibility problem in Oneiric is to apply the 2-line patch to make s-c-p not using cups-pk-helper.
[10:20] <tkamppeter> pitti, letting s-c-p try password-less CUPS auth before PK auth and then passworded CUPS auth is a good idea to suggest upstream, too complicated to rush into Oneiric.
[10:25] <tkamppeter> pitti, I am trying now another possible solution: Using, as you suggested, cups-pk-helper but opening up the right to manipulate local queues for all local desktop users without password. password is only needed for server settings and manipulating remote printers.
[10:26] <tkamppeter> pitti, this I am doing by replacing most "auth_admin_keep" by "yes" in /usr/share/polkit-1/actions/org.opensuse.cupspkhelper.mechanism.policy.
[10:27] <tkamppeter> pitti, WDYT? Which method should we use in Oneiric?
[10:38] <tkamppeter> pitti, if we opt for using the cups-pk-helper-based solution, I can patch s-c-p to check for the SSH_CLIENT env variable to not use PK is s-c-p is run through SSH, a ~6 lines patch.
[10:51] <debfx> mvo: would it be a problem for app-install-data if kubuntu stopped stripping translations from desktop files?
[10:54] <bdrung> Laney, Daviey, tumbleweed: sponsor-patch just calls syncpackage (without --no-lp) and due to the mentioned bug it does not yet support crediting the requester.
[10:56] <Laney> bdrung: shouldn't it do the AA way until that is fixed?
[10:57] <bdrung> Laney: good idea. i hoped that this will be fixed before oneiric is released
[10:57] <Laney> no idea about that
[10:59] <tumbleweed> it won't be able to credit the requestor without an API change on teh launchpad function, so that seems to be a safe thing to do
[11:08] <pitti> tkamppeter: re (sorry, was at lunch)
[11:09] <pitti> tkamppeter: no, please don't replace with "yes", we should only do that for users who are in the "admin" group already
[11:09] <pitti> tkamppeter: I think for oneiric we should just do the 2-line patch you suggested
[11:18] <bdrung> tumbleweed: btw, the changes are ready for oneiric. currently sponsor-patch doesn't support sync request at all. now it supports it (except the crediting)
[11:22] <tkamppeter> pitti, OK, will do so.
[11:23] <pitti> tkamppeter: thanks
[11:23] <diwic> pitti, is there a way to force a proper retrace of bug 838453 ? Apport's conclusion is wrong.
[11:25] <tkamppeter> pitti, admin-group-only authentication (but asking for password) is the standard scenarion if one does not change the cups-pk-helper configuration. Would be great if cups-pk-helper would give the possibility to allow access for users in the admin group (in the lpadmin group) without asking for their password if they are logged in on the desktop already.
[11:25] <pitti> tkamppeter: yes, that's possible, just not in the .policy file
[11:26] <pitti> tkamppeter: but as we don't use cups-pk-helper, I wouldn't change it in oneiric now
[11:26] <tkamppeter> pitti, so this would be a feature request for cups-pk-helper in Powerful Pitti, our next LTS.
[11:26] <pitti> tkamppeter: heh
[11:27] <pitti> tkamppeter: actually it would go into policykit-desktop-privileges, but either way, it's a simple change; I can do it easily
[11:28] <tkamppeter> pitti, great. Will you add this to your TODO list or should I report a bug?
[11:28] <pitti> tkamppeter: bug report will do fine
[11:29] <pitti> we can target it to P
[11:29] <tkamppeter> pitti, OK.
[11:29] <Laney> cjwatson: pitti: I'm confused about appointing the new DMB member. Does the TB need to confirm it?
[11:30] <pitti> Laney: erm, shouldn't DMB members be voted on?
[11:30] <Laney> it has been?
[11:30] <pitti> I thought the current DMB was the result of a poll
[11:30] <Laney> did you miss the election?
[11:30] <mvo> debfx: I don't think so, should be fine
[11:30] <pitti> yeah, that's what confused me; what does the TB need to confirm then?
[11:30] <pitti> Laney: ah, you mean adding it to the team?
[11:30] <Laney> the results of the poll
[11:31] <Laney> well, that too
[11:31] <cjwatson> TB is the administrator so would need to take action on it
[11:31] <Laney> I am asking if the TB needs to explicitly confirm
[11:31] <Laney> or just push the buttons to add the new member
[11:31] <cjwatson> I think we just push buttons
[11:31] <pitti> I wouldn't see why, but I might miss something
[11:32] <Laney> I thought I recalled you ratifying previous polls, but good
[11:33] <Laney> was concerned because at the last minute I can't make the meeting tonight, so I wanted to ensure that micahg can be a full member at it
[11:33] <pitti> Laney: I actually voted, I just seem to have missed the announcement of the result
[11:34] <Laney> hasn't been done yet until after it's confirmed at this meeting
[11:34] <Laney> but you can see the result on your poll link
[11:38] <Laney> (FYI I have been trying to follow https://wiki.ubuntu.com/CommunityCouncil/Restaffing but found it a bit confusing on this point)
[11:41] <pitti> does anyone have an idea how I work around the "Server presented certificate that does not match host staging.launchpad.net"  lplib error when trying to connect to staging?
[11:41] <pitti> ('DNS', '*.staging.launchpad.net')
[11:42] <pitti> that doesn't seem to include "staging.lp.net" itself
[11:42] <pitti> ah, ignore me, it's the second part of subjectAltName, so it ought to work?
[11:50] <pitti> ah, bug 839826 ?
[11:50] <pitti> this even has a patch, trying that
[11:56]  * Laney ran into that on Debian too
[11:59] <pitti> works fine, sponsoring this
[12:04] <Laney> DktrKranz: tumbleweed: ^ any chance of uploading to debian?
[12:10] <DktrKranz> Laney: could do, non sure about "when"
[12:10] <Laney> as you please, I built a package for myself
[12:11] <DktrKranz> I think I could be able to prepare an upload on Wed at latest
[12:12] <Laney> :-)
[12:39] <jml> pitti: I'm still getting those tracebacks in .xsession-errors: http://paste.ubuntu.com/687590/
[12:40] <pitti> jml: i. e. this still crashes for you? python -c 'from gi.repository import GLib; print GLib.markup_escape_text("a&b")'
[12:40] <jml> pitti: yes. TypeError: markup_escape_text() takes exactly 2 argument(s) (1 given)
[12:41]  * pitti scratches head -- this is oneiric current?
[12:41]  * pitti tries on current live CD
[12:42] <jml> pitti: yes. fresh update today.
[12:42] <jml> pitti: if you want, I can give you some package versions.
[12:42] <jml> pitti: but I'd neet to know which ones are relevant
[12:42] <pitti> jml: I first test on current live CD, to check whether it's my system that is non-standard somehow
[12:43] <jml> pitti: makes sense. thanks.
[12:43] <pitti> no, works on current desktop live CD
[12:43] <pitti> jml: dpkg -l libgirepository-1.0-1 gir1.2-glib-2.0 python-gobject
[12:44] <jml> pitti:
[12:44] <jml> http://paste.ubuntu.com/687594/
[12:44] <pitti> gir1.2-glib-2.0     1.29.16-0ubuntu1
[12:44] <pitti> there you go
[12:45] <pitti> jml: you want 1.29.17
[12:46] <pitti> jml: strange that you got the current version of libgirepository-1.0-1, it's built from the same source
[12:46] <jml> pitti: for some reason, it's kept back
[12:46] <pitti> what does sudo apt-get install gir1.2-glib-2.0 say?
[12:47] <pitti> it might want to remove something, so don't say yes, just check what it complains about
[12:47] <cjwatson> down to merely nine LP-batched pages of build failures ...
[12:47] <pitti> jml: ^
[12:48] <jml> cjwatson: yay progress?
[12:48] <pitti> jml: well, I was referring to what I said before, but agreed to "yay progress" :)
[12:48] <cjwatson> after a long and protracted war of attrition, the enemy is now merely nine times our size
[12:48] <jml> pitti: will do. just need a sec for an upgrade I started to finish.
[12:49] <cjwatson> but I think the lesson is "don't let the enemy get that large in the first place"
[12:50] <pitti> cjwatson: doesn't the vast majority of the universe FTBFS just happen due to us having a different toolchain and through bad luck through autosyncs?
[12:50] <jml> pitti: I think it just wants new packages: python-gobject-2
[12:50] <pitti> i. e. do we actually have a realistic alternative to not introduce these?
[12:50] <jml> pitti: nothing being removed
[12:50] <pitti> jml: that's right
[12:50] <pitti> jml: so it seems you have the old python-gobject, too
[12:50] <cjwatson> pitti: no, but we did have a realistic alternative to leaving them untended for > six months
[12:50] <pitti> jml: yes, you do
[12:51] <jml> pitti: yeah, I do. Have just installed the latest gir1.2-glib-2.0
[12:51] <cjwatson> with a large queue, people get into the mindset that build failures are basically normal and that there's no rush
[12:51] <pitti> jml: don't you use dist-upgrade? a mere upgrade will hold them back, right
[12:51] <jml> pitti: my dist-upgrade has been broken for a while.
[12:51] <pitti> cjwatson: agreed to > 6 months
[12:51] <jml> pitti: http://paste.ubuntu.com/687600/
[12:52] <pitti> it's just not something I like to see us spending manmonths on right after the autosync wave
[12:52] <cjwatson> the vast majority are easy; I fixed 15 build failures yesterday despite only being around for a few hours on a Sunday when others were asleep; if we'd been putting in consistent effort, there wouldn't be a problem
[12:52] <pitti> jml: hm, flashplugin-installer is at <IP_ADDRESS>ubuntu1
[12:53]  * jml checks ppa
[12:53] <jml> s
[12:53] <jml>  flashplugin-installer : Depends: flashplugin-downloader but it is not installable
[12:54] <cjwatson> (this is not to say that some people haven't been putting in consistent effort, but there aren't enough of them)
[12:56] <Laney> which ftbfs list are you using?
[12:56] <cjwatson> https://bugs.launchpad.net/ubuntu/+bugs?field.tag=ftbfs
[12:56] <Laney> ta
[12:56] <Laney> nemerle is binaries removed; close?
[12:57] <directhex> IMHO we should just kill nemerle for real
[12:57] <directhex> it's been a waste of archive space for years
[12:58] <cjwatson> Laney: it'll still show up in test rebuilds if binaries are removed; if you close the bug it will just get refiled at some point, unless the source is removed
[12:59] <cjwatson> removing binaries is a solution of sorts to NBS, but it doesn't eliminate FTBFS
[12:59] <Laney> yeah we should probably just get it killed
[12:59] <cjwatson> I don't object but would need a bug with rationale
[13:00] <Laney> I have definitely made a net negative contribution to package numbers in Debian since I became a DD
[13:01] <pitti> Laney: well, quality > quantity :)
[13:01] <jml> Oh. Hmm.
[13:02] <jml> flashplugin-downloader exists, but only for i386. amd64 seems to be out of luck.
[13:03] <pitti> jml: flashplugin-downloader:i386 exists
[13:03] <pitti> jml: perhaps you upgraded to oneiric early, but didn't set up multiarch as per slangasek's announcement?
[13:03] <cjwatson> the idea was to magically transition people to that, but I don't think it's completed yet
[13:03] <jml> pitti: well, *that* sounds plausible :)
[13:03] <cjwatson> oh, could just be that, yes
[13:04] <pitti> he made it sound like natty -> oneiric beta upgrade would work, but natty -> alpha-2 -> beta-1 wouldn't
[13:04] <pitti> jml: https://lists.ubuntu.com/archives/ubuntu-devel-announce/2011-August/000886.html
[13:04] <jml> pitti: yeah, got it, thanks.
[13:05] <didrocks> jml: I guess it's https://lists.ubuntu.com/archives/ubuntu-devel-announce/2011-August/000886.html
[13:05] <jml> didrocks: thanks. I think I've got it though :)
[13:06] <didrocks> jml: oupss, seems I didn't read the 2 last lines, sorry for repeating :)
[13:07] <jml> didrocks: that's ok. :)
[13:10] <debfx> pitti: pkgbinarymangler doesn't touch .desktop files if they don't have a Gettext-Domain key, right?
[13:10] <pitti> debfx: it adds X-Ubuntu-Gettext-Domain to .desktop files if it can figure out the domain
[13:11] <pitti> (and then removes translations)
[13:11] <debfx> pitti: oh, how does it figure out the domain?
[13:12] <pitti> debfx: ah, sorry, I mixed that up
[13:12] <pitti> debfx: the answer to your question is "yes"
[13:12] <pitti> debfx: dh_translations adds the -Domain: key
[13:13] <debfx> ok, thanks
[13:13] <pitti> debfx: (it's built from pkgbinarymangler source, but it's not done by pkgbinarymangler, the binary package)
[13:14] <pitti> debfx: dh_translations checks a few standard places, like po/Makefile ("GETTEXT_PACKAGE"), setup.cfg ("domain="), and some cmake equivalent
[13:14] <pitti> everything which doesn't use standard intltool/automake/python distutils/cmake needs to be fixed manually
[13:15] <doko> pitti, alamanah and seahorse-plugins need a new upload
[13:15] <debfx> pitti: dh_translations isn't run automatically though?
[13:15] <pitti> doko: seahorse-plugins is gone
[13:16] <pitti> debfx: no by debhelper; it's done by cdbs' gnome.mk (and perhaps pkg-kde-* cdbs modules)
[13:16] <doko> pitti, fine, then please re-upload alamanah
[13:16] <pitti> debfx: there's a --with-translations dh module
[13:16] <pitti> doko: ah, you removed the binaries; right, doing
[13:18] <pitti> doko: uploaded; will depwait until the libcruptui binaries get NEWed and published, but will sort itself out
[13:19] <Laney> we can fix gdcm by syncing
[13:19] <Laney> not sure if it needs ffe though
[13:21] <Laney> http://sourceforge.net/apps/mediawiki/gdcm/index.php?title=GDCM_Release_2.0.18 "probably"
[13:39] <doko> Sweetshark, please could you have a look at https://launchpad.net/bugs/835773
[13:41]  * Sweetshark looks
[13:42] <Sweetshark> eek, that dep might be ugly.
[14:06] <hallyn> anyone in coredev have a few minutes to take a look at the fix for bug 838205 ?
[14:06] <hallyn> systemtap is unusable in o without it
[14:07] <hallyn> zul: ^
[14:09] <zul> hallyn: sure
[14:09] <hallyn> zul: thanks
[14:30] <tkamppeter> pitti, s-c-p uploaded and PK changes reported as bug 847896.
[14:30] <pitti> tkamppeter: I saw, thanks!
[14:37] <charlie-tca> Can I assign bug 845549 to the desktop team?
[14:54] <dholbach> pitti, I think I can close https://bugs.launchpad.net/ubuntu/+source/python-httplib2/+bug/839826?
[14:54] <pitti> dholbach: oh, didn't that get auto-closed with the upload?
[14:54] <dholbach> ok, closing :)
[14:55] <Laney> Closes: vs. LP: ;-)
[14:56] <pitti> argh, sorry
[14:56] <pitti> dholbach: thanks!
[14:56] <dholbach> de rien
[15:12] <dholbach> Laney, do you think you can update your debdiffs.txt list?
[15:12] <Laney> what for?
[15:12] <Laney> bdmurray is tagging new ones
[15:13] <Laney> s/tagging/dealing with/ (by subscribing spnosors)
[15:13] <dholbach> oh, so they should all turn up on the sponsoring overview?
[15:13] <dholbach> so is there a list of "old ones"?
[15:13] <Laney> we only have to deal with the backlog
[15:13] <Laney> that's my file
[15:13] <dholbach> ok, can you update it? :-)
[15:14] <dholbach> I came across a few ones that luckily were closed already
[15:14] <Laney> closed since I generated it?
[15:14] <dholbach> yep
[15:16] <Laney> alright
[15:16] <dholbach> thanks muchly
[15:17] <Laney> dholbach: if I give you the script, can you get it running on some qa machine?
[15:17] <dholbach> I guess I can - what does it need?
[15:17] <Laney> just lplib
[15:18] <dholbach> ok cool
[15:24] <ubuntu__> hi all, Q). lh config --mode ubuntu --tasks "ubuntu-live" --distribution lucid hangs on grub, creating file /etc/default/grub/
[15:32] <ximion> hi! could someone who has the required rights please mark lp bug #847591 as priority:"high" and mark it as "needs to be fixed until oneiric release" (target it to oneiric)?
[15:33] <cjwatson> ximion: done
[15:33] <ximion> cjwatson: Thanks!
[15:34] <ximion> this bug renders PK unusable and will result in an FTBFS very soon, if it is the bug I have in mind
[15:34] <ximion> (I'll provide a fix asap)
[15:40] <dholbach> doko, I'll close https://bugs.launchpad.net/ubuntu/+source/seahorse-plugins/+bug/832888 - it seems the package was removed from oneiric
[15:41] <doko> dholbach, yes, scroll back for pitti's comments
[15:41] <dholbach> thanks
[15:48] <desrt> doko: hey.  i was wondering if you could take a look at https://bugs.launchpad.net/ubuntu/+source/eglibc/+bug/838975
[15:49] <desrt> doko: it's causing the compiles for glib to occasionally hang on the builders
[15:51] <doko> desrt, you're sure that this is not an glib issue?
[15:51] <desrt> doko: i've attached a testcase that's written against pure libc
[15:51] <desrt> doko: so it's either libc or kernel
[15:51] <desrt> and i suspect libc (for reasons listed in the bug)
[15:52] <doko> geser, pitti: vala issues in bug 832770 and bug 832760
[15:53] <doko> soren, zul: does this still belong to server? bug 836997
[15:53] <dholbach> @pilot out
[15:54] <zul> doko: dont think so
[16:10] <doko> apw, ogasawara: is uns still maintained by the kernel team? or can it be removed? see bug 756096
[16:11] <apw> doko, erm no idea.  will have a look
[16:12] <ogasawara> doko: I'm unaware of anyone from our team maintaining it.
[16:14] <doko> jamespage, could you have a look at 835757? new minor upstream version in debian, which seems to address the build failure
[16:15] <jamespage> looking at bug 835757 now
[16:20] <bregma> hey folks, I have a fix for a FTBFS bug in oneiric but I'm not sure where to go next, could I get some guidance?
[16:21] <infinity> bregma: Follow up to the launchpad bug (or file one, if there isn't one) with a patch?
[16:22] <bregma> what kind of a patch?  a merge request?  a debdiff?
[16:22] <infinity> "A patch".
[16:22] <infinity> People are far too picky about how they get their patches, and they shouldn't be.
[16:23] <infinity> If you fixed the package, show us how.  Leave it to someone actually uploading the fix to worry about how to make it get there. ;)
[16:24] <cjwatson> infinity++
[16:24] <cjwatson> (aleph-2?)
[16:25] <bregma> I have no idea what ;people uploading the fix' prefer, but I can provide any of debdiff, merge request to the repo on launchpad, or bare diff if that what someone would rather have, how am I supposed to tell?
[16:25] <infinity> bregma: I like simple patches or debdiffs.  Others like merge requests.  Others still might like you to phone them and explain the fix.  I say, do what you find works best for you.
[16:26] <infinity> bregma: We can deal with most/all of the above, and fretting over how you submit a patch isn't my idea of fun.  Just give us what works for you, and we'll make it work for us.
[16:27] <dholbach> yeah, just attach the patch on the bug in LP (if there's a bug already) and subscribe ubuntu-sponsors - that should work
[16:28] <nigelb> infinity: That's one of the best advice I've heard :)
[16:28] <apw> doko, ok so this usn build failure seems to be include foobar again
[16:41] <jamespage> doko: minor version upgrade on uimaj looks fine for sync - however will need a sync of maven-repo-helper as has a minimum required version higher that we have in oneiric by +x.x.1 which looks OK to me as well
[16:42] <doko> jamespage, thanks, could you update the report?
[16:42] <jamespage> doko: ack
[16:45] <jamespage> doko: done
[16:49] <doko> barry: please could you have a look at bug 835762? python2.6 hard coded?
[16:50] <micahg> barry: is there a reason why python-debian wasn't converted to dh_python2?
[16:54] <Laney> dholbach: I'd forgotten how long this script takes to run ...
[16:54] <dholbach> :)
[16:55] <doko> apw, so yes, the world moves around the kernel ;-P
[16:55] <apw> doko, no i mean its another case of broken handling of the includes ... different though, and not kernel fault, am working on fixing it
[16:55] <doko> ahh, ok
[16:56] <apw> doko, looks like long standning bad code.  probabally the compiler stopped doing something evil and it broke
[16:59] <ejat> hi .. anyone looking into bug 811441
[17:02] <SpamapS> hmm.. would it be an accurate statement that the alternate and mini isos don't use ubiquity at all?
[17:04] <cjwatson> SpamapS: yes, except for oem-config
[17:07] <SpamapS> cjwatson: I've just redirected bug 847782 to d-i from ubiquity then.. I'm thinking this is actually correct behavior from d-i .. and we may just close the bug.. but its probably worth a bit of discussion first.
[17:08]  * SpamapS already s/Ubiquity/installer/ as well
[17:09] <cjwatson> I'll have a look when my internet access isn't made of stale cheese.
[17:13] <cjwatson> SpamapS: surely this is a bug in the new upstart network jobs?  the 'auto' line has been there a lot longer than they have; they're what broke things
[17:15] <cjwatson> (unless the pre-upstart init scripts behaved the same way; I forget)
[17:18] <ScottK> SpamapS: Can haz clamav in -updates?
[17:21] <ejat> thanks cjwatson
[17:22]  * ejat just upgrade to oneiric .. need to do the manual work around ..
[17:22] <SpamapS> ScottK: I did that last Friday I thought
[17:23] <SpamapS> ScottK: its possible that sru-release timed out.. Is clamav big?
[17:23] <ScottK> Not really.
[17:23] <SpamapS> cjwatson: the pre-upstart scripts would wait for 1 minute per interface.
[17:23] <ScottK> https://launchpad.net/ubuntu/natty/+source/clamav says it's not there.
[17:23] <SpamapS> cjwatson: upstart did away with that waiting.
[17:24] <SpamapS> cjwatson: which caused *a lot* of issues for server users with complex network setups.
[17:25] <SpamapS> cjwatson: so the idea now is to wait only if its listed in /etc/network/interfaces .. but I may have underestimated how many people have an 'auto eth0' that will never come up. :-P
[17:26] <SpamapS> ScottK: indeed it did not go through. Trying again.
[17:26] <ScottK> Thanks.
[17:29] <SpamapS> ScottK: succeeded this time
[17:29] <ScottK> Cool.  Thanks again.
[17:34] <ghostcube> ich kenne einen philosophie studenten der hat nen job gefunden :D
[17:34] <ghostcube> nanananana
[17:35] <ghostcube> ups wrong channel lol
[17:35] <ghostcube> i hate quassel sometimes
[17:35] <ghostcube> :D
[17:35] <ghostcube> sorry guys
[17:52] <barry> ScottK: or other kubuntuistas.  i just grabbed the daily image for kubuntu amd64, but when i try to install it in a vm, i get "No installable kernel was found in the defined APT sources".  it ask if i want to continue w/o installing a kernel, which the warning makes me think is a bad idea.  does anybody know if this is a temporary (i.e. archive) problem, or something more serious that warrants a bug report?
[17:52] <barry>
[17:52] <ScottK> It was temporary.
[17:53] <ScottK> The alternates were rebuilt after and should work.
[18:05] <barry> ScottK: cool, thanks, i'll try again
[18:08] <bdmurray> Is there somebody who might review my apport merge proposal and upload it?
[18:08] <bdmurray> https://code.launchpad.net/~brian-murray/apport/ubiquity-dupe-sig-improvements/+merge/75050
[18:38] <doko> barry, please don't set reports like bug 835001 to incomplete. it's reproducible in the rebuild. it doesn't have to ftbfs in the main archive
[18:39] <barry> doko: how can you debug it if it only ftb in the test rebuild then?
[18:41] <doko> barry, does it really build in a clean/fresh pbuilder chroot?
[18:41] <doko> most likely an issue with python versions
[18:41] <barry> it built in my sbuild cleanly.  i'll retry it in pbuilder after finishing up on python-django-nova
[18:42] <doko> Sweetshark, ooo-build-extensions is still in unstable, black-list it?
[19:03] <doko> barry, fix uploaded
[19:03] <barry> doko: fix for...?
[19:03] <doko> the build failure
[19:04] <barry> doko: acidobasic?
[19:04] <doko> yes
[19:04] <barry> doko: okay cool, thanks
[19:05] <doko> Laney, https://launchpadlibrarian.net/79716630/buildlog_ubuntu-oneiric-i386.fregression_2100.76-3_FAILEDTOBUILD.txt.gz
[19:12] <SpamapS> Hrm, so I just found that sary-ruby ftbfs on Ubuntu where it does build on sid because of libglib being multi-arch .. is Debian headed that direction already?
[19:27] <NCommander> Who maintains the rmadison CGI? I'd like to see it properly work with ports architectures
[19:28] <micahg> +1 :)
[19:28]  * Pici as well
[19:33] <soren> NCommander: I believe it's cjwatson.
[19:34]  * NCommander pokes at the script
[19:35] <soren> doko: I'd say yes.
[19:35] <soren> doko: I'm on holiday for a couple of days. I'll take a look when I get back.
[19:35] <doko> soren, thanks
[19:36] <soren> doko: Thanks for pointing it out!
[19:56] <RoboTux> Greetings everyone
[19:56] <RoboTux> The tcc package in Ubuntu suffers a quite bad bug: it generates programs which only runs on Debian and Ubuntu
[19:56] <RoboTux> The fix is in Debian and a merge package has successfuly been generated
[19:57] <RoboTux> Could anyone update the package in Ubuntu to this new version? (the changes are small and tested since 2 months in Debian)
[19:58] <RoboTux> https://bugs.launchpad.net/ubuntu/+source/tcc/+bug/820983 Here is the bug
[20:20] <doko> I want to turn off compiz. 5th crash today ... what's the best option?
[20:21] <micahg> unity-2d?
[20:21] <doko> micahg, just install on top?
[20:21] <micahg> doko: should be available from lightdm
[20:24] <doko> hey, feels even faster ...
[20:26] <RoboTux> Does anyone know who I should ask about tcc?
[20:26] <micahg> RoboTux: https://wiki.ubuntu.com/SponsorshipProcess
[20:27] <RoboTux> Thanks
[20:31] <doko> and colsXrows numbers are back again when resizing \o/
[20:33] <cjwatson> NCommander,soren: not within my control; the mirror that CGI script is inspecting doesn't have ports on it
[20:38] <cjwatson> NCommander,soren: not within my control; the mirror that CGI script is inspecting doesn't have ports on it
[21:02] <geser> cjwatson: did you sync tecnoballz? if yes, it "Failed to upload": Require Pre-Depends: dpkg (>= 1.15.6) when using xz compression. (https://launchpadlibrarian.net/79382192/upload_2868254_log.txt)
[21:27] <Laney> doko: ah, I had to use --build-dep-resolver=internal
[21:56] <Laney> doko: we need to remove 'vr'
[21:57] <doko> Laney, I assume, just the source?
[21:59] <doko> ahh, no. binary and source
[21:59] <Laney> yeah it has binaries too
[21:59] <Laney> was removed from sid a while ago & provides an uninstallable real package which would otherwise be pure virtual
[22:01] <SpamapS> @pilot in
[22:04] <cjwatson> geser: hm, I did but I never got a failure mail.  I'll fix that, thanks
[22:05] <Laney> native sync bug (due to not attributing you correctly)
[22:08] <cjwatson> Laney: is that the same as the failure to show up in +uploadedpackages?
[22:08] <Laney> I belive that's all the same bug, yes
[23:54] <SpamapS> argh
[23:55]  * SpamapS wonders when he'll be able to stop fighting unity/compiz and just use his computer. :-P
[23:59] <infinity> SpamapS: When you switch to xubuntu.
[23:59] <SpamapS> ;)


[15:31] <mmrazik> hi everyone
[15:31] <mmrazik> Lets have a meeting introducing some of the quality stuff we are doing inside Canonical and more specific the Product Strategy department
[15:31] <mmrazik> #startmeeting
[15:31] <meetingology> Meeting started Tue Jan 24 15:31:53 2012 UTC.  The chair is mmrazik. Information about MeetBot at http://wiki.ubuntu.com/AlanBell/mootbot.
[15:31] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[15:32] <AlanBell> hi mmrazik
[15:32] <mmrazik> We have one agenda topic and that is the introduction to testability -- a test automation framework for Qt
[15:32] <mmrazik> hi
[15:32] <gema> o/
[15:32] <greyback> Hi all
[15:32] <mmrazik> [TOPIC] Testability (aka automated testing in Qt environment)
[15:33] <mmrazik> greyback was so kind to do the introduction :-)
[15:33] <mmrazik> greyback, your turn :)
[15:33] <greyback> mmrazik: ok, thank you
[15:33] <greyback> Hey all, I'm Gerry Boland, team lead of the Unity 2D project. I'm here to talk about automated testing!
[15:34] <greyback> We all use our desktops every day. We know it is important for the desktop shell to be reliable, consistent and fast.
[15:34] <greyback> From the programmer's side, we strive to maintain these qualities. But we're human, and we make mistakes.
[15:34] <greyback> Sometimes a bugfix will break something else, and it's easy to miss these breakages.
[15:34] <AlanBell> are you using at-spi to do the testing?
[15:35] <greyback> AlanBell: hold on, I'm getting to it (short answer: no)
[15:35] <greyback> We have documents called "manual User Experience tests" where human beings follow a step-by-step procedure to verify the software is doing exactly what it should. But why not automate it!
[15:35] <greyback> In Unity 2D, we have just introduced an automated User Experience test system, based on a test framework called "Testability Driver" (I'll just call it 'Testability' from now on)
[15:35] <greyback> Testability is for Qt-based applications.
[15:36] <greyback> Its core feature is that it allows inspection of the tree of QObjects in a Qt application while it is running.
[15:36] <greyback> It can read and write object properties, call methods and slots, verify signals are emitted, as well as faking mouse/keyboard/gesture inputs, grabbing visual outputs, and measure performance.
[15:36] <greyback> And best of all, Testability is open source and maintained by Nokia!
[15:36] <greyback> To show it off, here is a screengrab of the Testability Visualizer application which allows you to dig into the QObject tree and investigate what's going on (here, the Launcher):
[15:37] <greyback> http://i.imgur.com/Kp7RA.png
[15:37] <greyback> On the left is a preview of the app, in the center is the object tree which you can navigate, and on the right is the list of properties, methods and signals you can interact with.
[15:37] <greyback> All these properties, methods, signals, etc, are scriptable via Ruby. Thus we can emulate every interaction that a user can make with the software, and measure the reaction.
[15:38] <greyback> This forms the foundation for the Unity 2D User Experience testing suite.
[15:38] <greyback> .
[15:38] <greyback> Testability works as follows:
[15:38] <greyback> - *any* Qt application using Qt4.6+ can be tested by executing it with the "-testability" switch (and any previous with a little code)
[15:39] <greyback> - a standalone server "qttasserver" runs in the background
[15:39] <greyback> - With the -testability switch, the Qt library tries to load a "libtestability.so" plugin which establishes a connection between the application and qttasserver, giving access to the root node of the object tree.
[15:39] <greyback> - qttasserver then climbs the QObject tree, reads all the info it can and converts it to an XML format. It also can receive commands and cause the application to react upon them (click here, type, etc..).
[15:40] <greyback> - A series of Ruby scripts connect to qttasserver, parse this XML and allow us to script tests and interactions with the application.
[15:40] <greyback> - from here, can use existing test frameworks like Test::Unit or Cucumber to run tests
[15:40] <greyback> .
[15:40] <greyback> The Unity 2D test framework also includes an extra helper library to control the X server, to control the mouse and keyboard, and to manipulate windows on the desktop. As far as X is concerned, you are controlling it.
[15:41] <greyback> With the ability to fake any form of user input, and directly read the output from the shell applications themselves, we can test almost every behaviour of the desktop shell. And as a result, the quality of the experience will only go up.
[15:41] <greyback> As a demo, here is a video of part of the Unity 2D test suite in action. On the right is Ubuntu Oneiric running inside VirtualBox, where the Launcher will be tested. On the left is my host machine terminal running the test suite:
[15:41] <greyback> https://wiki.ubuntu.com/Unity2DTestability?action=AttachFile&do=get&target=testability.ogv
[15:41] <greyback> (I hope you can all see it)
[15:42] <greyback> It shows various hide/show tests are being performed, with windows in the way, mouse being controlled, keyboard shotcuts being pressed etc.
[15:42] <mmrazik> greyback, is the X helper library developed by the Unity-2D team or is it something "standard"?
[15:42] <greyback> mmrazik: it's a heavily customised version of a ruby library for xdotool
[15:42] <greyback> mmrazik: it's in the unity-2d source repo as a result (but some stuff I want to push upstream)
[15:43] <greyback> Our policy is that every new feature and bug fix in Unity 2D will now be tested like this.
[15:43] <Riddell> greyback: is testability proprietary or free software?
[15:43] <greyback> Riddell: open source
[15:43] <greyback> Links: https://wiki.ubuntu.com/Unity2DTestability
[15:43] <Riddell> greyback: so we can package it for ubuntu and have other people be able to test unity 2d and expand that to other qt uses?
[15:43] <greyback> https://projects.developer.nokia.com/Testabilitydriver/wiki
[15:44] <greyback> Riddell: exactly. I've packaged it up in my PPA (see first link), and hope to get it into Ubuntu proper
[15:45] <greyback> Riddell: idea is that everyone can run the tests we do, and help add to them
[15:45] <greyback> Ok, that's my spiel. Thanks for your attention everybody. Questions welcome!
[15:45] <Riddell> I'm sure plenty of people would be happy to review the packaging if needed
[15:45] <AlanBell> greyback: it would be great to see tests for orca users too. With a dummy speech dispatcher module you can get the text orca would read out loud piped to a file, then the test can validate that non-visual users would be hearing something sensible
[15:46] <greyback> Riddell: I hope so. I'll need help to get it properly packaged (I made a few shortcuts)
[15:46] <greyback> AlanBell: I agree. Certainly we can read the accessibility text that is sent to Orca directly from the Qt application itself
[15:47] <greyback> AlanBell: but yes, test to ensure Orca is getting the right strings is important
[15:47] <AlanBell> reading the final output is sometimes more instructive than the individual strings
[15:48] <greyback> That's a good point. No certainly, that is something I will investigate more
[15:48] <greyback> There is still plenty to do
[15:48] <AlanBell> I can help you with the speech dispatcher module, I have one that just appends to /tmp/orca.out
[15:49] <greyback> That would be great
[15:49] <greyback> Unity2D is reasonable for A11Y, but can be better. Every bit helps
[15:49] <greyback> Thank you
[15:50] <AlanBell> is the HUD stuff included in this testing?
[15:50] <greyback> HUD needs to be written in Unity2D yet :) But yes, it will not be accepted unless there are tests for it
[15:50] <AlanBell> great
[15:51] <mmrazik> AlanBell, unfortunately testability is Qt specific
[15:51] <mmrazik> so unity 3D goes with custom solution - Autopilot
[15:51] <greyback> AlanBell: I'm assuming unity-core has unit tests to check HUD works at a lower level
[15:51] <mmrazik> right now the wiki is work in progress but to get some idea: https://wiki.ubuntu.com/Unity/QA/Autopilot
[15:51] <mmrazik> yes, that is exactly the case
[15:51] <gema> mmrazik: any way to create an abstraction layer so that you can reuse the test cases between both?
[15:51] <mmrazik> in matter of fact Mark even published some coverage data on his blog
[15:52] <mmrazik> gema, we were thinking of cucumber
[15:52] <mmrazik> but those are very early thoughts ATM
[15:52] <mmrazik> not real work was done yet
[15:52] <kalikiana> greyback: can it run something like xephyr to avoid fiddling with the running system?
[15:52] <gema> mmrazik: ack
[15:52] <AlanBell> greyback: yeah, I am just trying to push orca testing back in the development lifecycle as far as possible, hopefully as far as design one day!
[15:53] <greyback> kalikiana: yes. In fact, I have it set up to run tests on Ubutu inside a virtual box, but controlled by the host machine
[15:53] <greyback> kalikiana: it ensures as little changes as possible are made to the sustem being tested
[15:53] <kalikiana> ah, nice
[15:53] <greyback> kalikiana: Xephyr isn't quite a "pure" but something I have in mind to also support
[15:54] <kalikiana> greyback: I'm mainly saying xeyphr since it's less overhead and faster
[15:54] <kalikiana> not every potential tester may want to have a vm running
[15:55] <greyback> AlanBell: noted. I must admit, it's been some time since I've tested Unty2D and Orca. But we do test them manually during the bug-fixing stage of the cycle
[15:55] <AlanBell> yeah, it is harder then ;)
[15:55] <greyback> kalikiana: indeed. You can run these test on your machine too, it just mucks up your desktop a little afterwards :)
[15:55] <AlanBell> stuff like the new shortcut overlay in unity just plain doesn't work with orca as it can't be focussed
[15:56] <mmrazik> Ok.  Any other questions?
[15:56] <greyback> AlanBell: yep. Unity2D has a problem with the Dash textbox, it can't be navigated with Orca. It needs to be fixed
[15:57] <greyback> AlanBell: yes if you should share where I could get that dummy speech dispatcher, I'd be grateful
[15:58] <mmrazik> As we are running out of time -- many thanks for joining us, for good questions and thanks greyback for the talk.
[15:58] <greyback> You're welcome!
[15:58] <mmrazik> We are also blogging about our activities on http://qualityhour.wordpress.com/ :)
[15:58] <mmrazik> And we want to make these public meetings on a monthly basis.
[15:58] <mmrazik> So see you next time!
[15:58] <mmrazik> byt
[15:58] <mmrazik> bye
[15:59] <mmrazik> #endmeeting
[15:59] <meetingology> Meeting ended Tue Jan 24 15:59:01 2012 UTC.
[15:59] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-01-24-15.31.moin.txt
[15:59] <AlanBell> greyback: http://people.ubuntu.com/~alanbell/file.conf and you need to edit /etc/speech-dispatcher/speechd.conf to add AddModule "file"  "sd_generic" "file.conf"
[15:59] <greyback> AlanBell: magic, thanks
[15:59] <AlanBell> "echo $DATA>>/tmp/orca.out" is the bit that does the magic
[15:59] <mmrazik> (btw we are on #ubuntu-testing for post-discussions :-))
[16:01] <Daviey> .. meeting starting shortly.
[16:01] <Daviey> (server)
[16:03] <Daviey> Chair isn't here.. /me drives
[16:03] <Daviey> #startmeeting
[16:03] <meetingology> Meeting started Tue Jan 24 16:03:02 2012 UTC.  The chair is Daviey. Information about MeetBot at http://wiki.ubuntu.com/AlanBell/mootbot.
[16:03] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[16:03] <Daviey> AlanBell: is the bot poorly?
[16:03] <Daviey> #startmeeting
[16:03] <meetingology> Daviey: Error: Can't start another meeting, one is in progress.
[16:03] <mmrazik> #endmeeting
[16:03] <Daviey> O_o
[16:04] <Daviey> o/
[16:04] <arosales> Hello
[16:04] <mmrazik> sorry.  Just thought I didn't finish my meeting.
[16:04] <hggdh> ~ô~
[16:04] <Daviey> Who is here for the ubuntu server meeting?
[16:04] <adam_g> o/
[16:04] <arosales> o/
[16:05] <utlemming> o/
[16:05] <zul> hi
[16:05]  * smb moves into the shadows
[16:05] <rbasak> o/
[16:05] <Daviey> #topic Review ACTION points from previous meeting
[16:05] <jamespage> o/
[16:06] <Daviey> Discuss merge of Open Discussion with Community update topics
[16:06] <SpamapS> Sorry for my lateness.. as usual, 1600 UTC is not doable for me.
[16:06] <SpamapS> but 1605 is :p
[16:06] <Daviey> Sounds like a no-brainer for me, any objections?
[16:06] <utlemming> +1
[16:06] <Daviey> #agreed merge of Open Discussion with Community update topics
[16:07] <SpamapS> :)
[16:07] <Daviey> #agree merge of Open Discussion with Community update topics
[16:07] <Daviey> #topic Precise Development
[16:07] <Daviey> Anyone else want to drive this?
[16:07] <Daviey> okay..
[16:07] <Daviey> Current Bugs pertinent to Precise Server release that we are working on http://status.qa.ubuntu.com/reports/ubuntu-server/release-bugs.html
[16:08] <Daviey> bug 883988
[16:08] <Daviey> adam_g: you wre following this?
[16:08] <adam_g> Daviey: yeah, targetted toward next essex milestone
[16:08] <Daviey> adam_g: looking on track?
[16:09] <adam_g> Daviey: honestly not sure anyone has touched it upstream but a fix has been discussed
[16:09] <Daviey> bug 893926 , assigned to mainerror who isn't here.  I'll follow up with him shortly.
[16:09] <Daviey> bug 911812, roaksoax ?
[16:10] <Daviey> adam_g: thanks, can you follow that up?
[16:10] <adam_g> Daviey: the glance bug? yes, ill ping jay this week to find out his thoughts
[16:10] <Daviey> rocking
[16:10] <SpamapS> Daviey: shouldn't we also be going over the WI tracker, since FF is coming soon?
[16:11] <Daviey> SpamapS: yes, but lets get the bugs done
[16:11] <Daviey> roaksoax: are you here?
[16:11] <Daviey> bug 913009, smoser is /away.. I believe it is still untouched, pending new upstream snapshot
[16:12] <Daviey> bug 916992, adam_g ?
[16:12] <adam_g> Daviey: patch merged upstream, should be fix released in ubuntu next snapshot (fri)
[16:12] <Daviey> SpamapS: following bug 914392 ?
[16:12] <Daviey> adam_g: great!
[16:13] <Daviey> new bug 920202, up for grabs!
[16:13] <Daviey> anyone want it?
[16:13] <SpamapS> Daviey: I am aware of 914392 but I have not been following up on it. I think the fix is fairly trivial, so perhaps I can patch it myself.
[16:13] <adam_g> Daviey: ill poke at it
[16:14] <Daviey> adam_g: you rock star!
[16:14] <zul> Daviey: i would poke lamont
[16:14] <Daviey> SpamapS: great news, do you want to take ownership
[16:14] <Daviey> zul: good thinking
[16:14] <Daviey> bug 875262 , SpamapS were you working with koolhead17 ?
[16:15] <Daviey> smb: has bug 607039 moved?
[16:15] <smb> Daviey, errr not really
[16:16] <Daviey> zul: bug 890362 ?
[16:16] <zul> Daviey: will be addressed this week
[16:16] <Daviey> bug 898840 .. roaksoax  seems absent, but i think it is blocked.
[16:16] <rbasak> SpamapS: re: bug 914392, I've just s/oneiric/precise/ as a workaround and it seems to be ok. Not fully tested thisi though.
[16:16] <Daviey> smb: Is there a path forward?
[16:17] <SpamapS> rbasak: right, but its a fairly important bug. ;)
[16:17] <Daviey> bug 904681, assigned to a slacker.. He hasn't touched it, but will do today/tomorrow.
[16:17] <rbasak> yes :)
[16:17] <smb> Daviey, If I had seen this before I may have an answer
[16:17] <SpamapS> Daviey: I will take bug 912716
[16:17] <Daviey> smb: Oh, sorry - i thought you were tracking that one?
[16:18] <smb> Daviey, Not that I can recall
[16:18] <Daviey> SpamapS: I think hggdh tentively had that one, awaiting triage/confirm
[16:18] <smb> ... though that may mean nothing
[16:18] <hggdh> this has been fixed since Maverick (by a zul patch!)
[16:18] <Daviey> smb: oh, ok - sorry.
[16:18] <smb> Daviey, Maybe SpamapS ?
[16:18] <Daviey> heh
[16:18] <hggdh> I am just waiting on the OP to clarify before closing
[16:18] <SpamapS> Daviey: yeah, it is the same bug, but the original bug wasn't actually fixed
[16:19] <Daviey> smb: I see you were on it in Nov. Are you wanting to continue on it?
[16:19] <lamont> Daviey: bah.  I'll look into that today
[16:19] <lamont> 920202 that is
[16:19] <smb> Daviey, About what do we talk exactly..?
[16:19] <Daviey> SpamapS: Sorry, i might have moved too fast.. but did you see me ask about the php bug? ^^
[16:19] <Daviey> lamont: \o/
[16:20] <Daviey> (lamont, there seems to bea  Debian bug aswell fwiw)
[16:20] <lamont> Daviey: that's because I'm consistent.
[16:20] <Daviey> smb: https://bugs.launchpad.net/ubuntu/+source/autofs5/+bug/607039/comments/19
[16:20] <Daviey> lamont: heh
[16:20] <smb> Daviey, Ah, yes. I may sure
[16:22] <Daviey> zul: bug 906654 ?
[16:22] <SpamapS> Daviey: the PHP bug is just an obsolete conffile that postinst should be removing.
[16:22] <zul> Daviey: i think openstackx might actually merged into nova proper, but other than that im still waiting for the MIR
[16:22] <Daviey> SpamapS: any closer to getting fix0rd?
[16:22] <Daviey> zul: which MIR ?
[16:23] <zul> Daviey: horizon
[16:23] <Daviey> ah, cool
[16:23] <Daviey> bug 907197, zul ?
[16:23] <zul> need to reproduce first..
[16:24] <Daviey> zul: that would seem pretty bad if it is valid.. :/
[16:24] <SpamapS> Daviey: no, somebody needs to take the action suggested by slangasek in comment #16.
[16:24] <Daviey> zul: will you be able to reproduce this week?
[16:24] <zul> Daviey: i can try it this afternoon
[16:24] <Daviey> SpamapS: Right, i thought you were working with koolhead17 to resolve that?
[16:24] <SpamapS> Daviey: have not heard from koolhead on it. Will ping him.
[16:25] <Daviey> s/i\ thought//
[16:25] <Daviey> SpamapS: rocking!
[16:25] <Daviey> bug 914257, adam_g
[16:25] <Daviey> adam_g: should that be Fix Committed?
[16:26] <adam_g> Daviey: will get to that in the next day or two
[16:26] <Daviey> adam_g: looks like it's fixed in bzr?
[16:26] <Daviey> bug 879666, rbasak
[16:26] <adam_g> Daviey: unfortunately, no
[16:26] <zul> Daviey: it has different side affects
[16:27] <adam_g> Daviey: the local_settings.py that was shipping before is no longer, so i propose we ship our own basedoff the example. ill ping zul about thi later this AM
[16:27] <Daviey> adam_g & zul: http://bazaar.launchpad.net/~ubuntu-server-dev/horizon/essex/revision/22 ?
[16:27] <rbasak> I hadn't seen your comment. I'll update the debdiff for precise.
[16:28] <adam_g> Daviey: no, that doesn't fix the bug and not sure why it was merged as such. local_settings.py is no longer part of the package, and is not installed.
[16:28] <adam_g> Daviey: and, if it was, the django app doesn't import it from /etc/openstack-dashboard
[16:29] <Daviey> lynxman: bug 916489 ?
[16:29] <Daviey> (lnxman awaiting update to merge proposal)
[16:30] <Daviey> Okay, shall we move on?
[16:31] <Daviey> http://status.ubuntu.com/ubuntu-precise/group/topic-precise-servercloud-infrastructure-deployment.html
[16:31] <Daviey> We seem to be making reasonably good progress.
[16:31] <Daviey> https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-cloud-power-management is of concern.
[16:31] <Daviey> roaksoax: when you read this, can you follow up with aquette ?
[16:32] <Daviey> jjohansen: What is the status of https://blueprints.launchpad.net/ubuntu/+spec/security-p-apparmor-containers ?
[16:32] <roaksoax> Daviey: will do
[16:32] <Daviey> jdstrand: ^^, is it looking ok?
[16:33] <Daviey> https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-arm-service-orchestration ... will be flushed today, with some changes.
[16:33] <Daviey> SpamapS: how is, https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-juju-charm-testing looking ?
[16:33] <SpamapS> Daviey: spec should land on the juju mailing list today, which should give way to the others falling rather rapidly
[16:34] <jdstrand> Daviey: jjohansen is continuing to work hard on this. it is an essential bp which we are committed to delivering
[16:34] <jdstrand> Daviey: he has made significant progress, but it hasn't landed yet
[16:34] <Daviey> https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-ceph .. is looking a concern.
[16:34] <SpamapS> Daviey: yeah, about half of that is going to have to be postponed
[16:35] <Daviey> arosales: are you able to dig into servercloud-p-ceph ?
[16:35] <Daviey> SpamapS: \o/, GREAT news
[16:35] <Daviey> nice one.
[16:35] <SpamapS> Daviey: it should hit main, it should have a MIR, but other than that, I don't think we're going to get much further with it
[16:35] <Daviey> roaksoax: https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-powernap ?
[16:35] <Daviey> https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-virtio-device-driver , is blocked on some non-Ubuntu issues.
[16:36] <Daviey> jdstrand: thanks for the update!
[16:36] <roaksoax> Daviey: well... haven't yet work on it furhter as I've been more concentrated into the cobb;er/orchestra/and now with the new stuff might gonna have to postpone work items
[16:37] <Daviey> arosales: https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-glusterfs-mir .. seems a MIR hasn't yet been raised.. that can be marked done when resolved.
[16:37] <Daviey> https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-openstack-testing jamespage / adam_g ?
[16:37] <adam_g> Daviey: should be marking a couple of those DONE this week
[16:37] <Daviey> SpamapS: Ceph in main?
[16:38] <SpamapS> Daviey: Yes, since we're going to turn on qemu's ceph RBD support
[16:38] <Daviey> rbasak: https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-arm-service-orchestration anything blocking?
[16:39] <Daviey> adam_g: https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-openstack-charms how is it looking?
[16:39] <rbasak> nope, just hitting more issues though. another bug to file outstanding
[16:39] <Daviey> lynxman, still not here? https://blueprints.launchpad.net/ubuntu/+spec/servercloud-p-cfjuju
[16:40] <rbasak> I've been slowed massively by a kernel regression but a fix is on its way
[16:40] <arosales> Daviey:  re: servercloud-p-glusterfs-mir: yup, SpamapS was also going to look in to that one, not anticipating a lot of work to complete the work item.
[16:40] <Daviey> rbasak / adam_g: please comment so we can move on.
[16:40] <adam_g> Daviey: looking okay, have some of those chamrs ready for merge into charm store currently
[16:41] <Daviey> !ping
[16:42] <Daviey> Am i here?
[16:42] <smb> Daviey, Which one of you?
[16:42] <Daviey> (there seems to be lag going on?)
[16:43] <smb> Hm, did not see any lag here but it is quite quiet
[16:44] <rbasak> who is still here?
[16:44] <rbasak> o/
[16:44] <jamespage> o/
[16:44] <smb> \o
[16:44] <adam_g> o/
[16:44] <Daviey> bug 1
[16:44] <hggdh> ~ô~
[16:44] <arosales> o/
[16:44] <utlemming> o/
[16:45]  * rbasak doesn't see any lag
[16:45] <smb> He is connected
[16:45] <Daviey> roaksoax: Okay, shall we discuss it out of band?
[16:45] <SpamapS> o/
[16:45]  * SpamapS had "alt-tab" induced lag
[16:45] <roaksoax> Daviey: sure
[16:47] <Daviey> GREAT adam_g
[16:47] <Daviey> #topic Ubuntu Server Team Events
[16:47] <Daviey> FOSDEM next weekend, expect to see - jamespage, rbasak and Daviey
[16:47] <Daviey> Other events?
[16:48] <arosales> Daviey, had some pretty good interest in Juju and Server at SCALE10x this past weekend.
[16:48] <Daviey> SpamapS: ok, thanks
[16:48] <arosales> SpamapS: and jcastro gave a charmschool and talk @SCALE 10x
[16:51] <SpamapS> Nothing in the immediate horizon though.
[16:51] <Daviey> #topic Weekly Updates & Questions for the QA Team (hggdh)
[16:52] <Daviey> Problem solved... sorry!
[16:52] <hggdh> no news from me, life seems to be kludging along on the QA/server front ;-)
[16:52] <hggdh> ..
[16:53] <Daviey> ok, thanks
[16:53] <Daviey> #topic Weekly Updates & Questions for the Kernel Team (smb)
[16:53] <smb> Still working on getting cobbler up locally which is not as simple as I thought
[16:53] <Daviey> smb: do you want some pointers?
[16:53] <smb> Am able to pxeboot real and virtual machines in some way
[16:53] <smb> Daviey, Always appreciated
[16:54] <Daviey> smb: roaksoax, smoser, myself etc are always willing to jump in.... always feel free to ask in #ubuntu-serber
[16:54] <Daviey> err, server
[16:54] <Daviey> thanks smb
[16:54] <Daviey> #topic Weekly Updates & Questions regarding Ubuntu ARM Server (rbasak)
[16:55] <rbasak> I have one openmpi question
[16:55] <rbasak> bug 889644
[16:55] <rbasak> With janimo's help I now have a version that builds on arm, and Debian have already taken it - their 1.5 is in experimental. But I'm worried about syncing this because it would pull the general archive version up from 1.4 to 1.5, and I don't know what other dependencies might break. There do seem to be a pile of rdepends. What exactly is the functionality/use case that we need to add, how would I verify existing functionality is not broken determ
[16:55] <rbasak> ine that what we need to add works? Or should I just get 1.5 synced and worry about what breaks later?
[16:55] <rbasak> Other than that ARM work is chugging away. I'm still hitting bugs trying to get juju to work, but am slowly making progress
[16:56] <Daviey> rbasak: I don't thnk anyone here has touched openmpi before, but i agree it does have plenty of rdepends.
[16:56] <Daviey> rbasak: lets take that offline...
[16:56] <rbasak> ok
[16:57] <Daviey> #topic Weekly Updates & Questions from the Ubuntu Community and Open Discussion
[16:57] <Daviey> ^^ note, new topic
[16:57] <Daviey> Firstly, sorry for my laggy connection.. I had some woes :/
[16:57] <arosales> Any objections from the server team from removing mysql-cluster-7.0 from universe?  It hasn't gotten any updates since September, no new upstream source since January 2011, and its not in Debian. It has a bunch of security vulnerabilities (with little/no upstream support from oracle) that will make maintaining it a large effort.
[16:57] <Daviey> anything from anyone?
[16:57] <Daviey> arosales: Sounds like a +1 from me, i don't think it had a high userbase anyway.
[16:57] <arosales> jdstrand had brought this up yesterday, and I wanted to check with the team
[16:58] <Daviey> Would be good to see it in Debian tho!
[16:58] <arosales> ok, I'll let jdstrand know this can be  removed from Universe
[16:58] <Daviey> moving on.... ?
[16:58] <Daviey> #topic Announce next meeting date and time
[16:59] <Daviey> same time, same place.. have fun..
[16:59] <Daviey> thanks for coming.
[16:59] <Daviey> o/
[16:59] <Daviey> #endmeeting
[16:59] <meetingology> Meeting ended Tue Jan 24 16:59:14 2012 UTC.
[16:59] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-01-24-16.03.moin.txt
[16:59] <apw> o/
[16:59] <jsalisbury> Roll Call for Ubuntu Kernel Weekly Status Meeting
[16:59] <smb> \o
[16:59] <herton> o/
[16:59] <smb> (still)
[17:00] <tgardner> o/
[17:00] <bjf> o/
[17:00] <ogasawara> o/
[17:00] <sforshee> o/
[17:00] <meetingology> Meeting started Tue Jan 24 17:00:20 2012 UTC.  The chair is jsalisbury. Information about MeetBot at http://wiki.ubuntu.com/AlanBell/mootbot.
[17:00] <meetingology> Available commands: #accept #accepted #action #agree #agreed #chair #commands #endmeeting #endvote #halp #help #idea #info #link #lurk #meetingname #meetingtopic #nick #progress #rejected #replay #restrictlogs #save #startmeeting #subtopic #topic #unchair #undo #unlurk #vote #voters #votesrequired
[17:00] <jsalisbury> ##
[17:00] <jsalisbury> ##
[17:00] <jsalisbury> [LINK] https://wiki.ubuntu.com/KernelTeam/ReleaseStatus/Precise
[17:00] <jsalisbury> [TOPIC] ARM Status (ppisati)
[17:00] <ppisati> Nothing new to report this week.
[17:00] <ppisati> ..
[17:00] <jsalisbury> [TOPIC] Release Metrics and Incoming Bugs (jsalisbury)
[17:01] <jsalisbury> Release metrics and incomming bug data can be reviewed at the following link:
[17:01] <jsalisbury> [LINK] http://people.canonical.com/~kernel/reports/kt-meeting.txt
[17:01] <jsalisbury> ..
[17:01] <jsalisbury> [TOPIC] Milestone Targeted Work Items (ogasawara)
[17:01] <ogasawara> [LINK] http://status.ubuntu.com/ubuntu-precise/canonical-kernel-distro-team-precise-alpha-2.html
[17:01] <ogasawara> || apw        || hardware-p-kernel-boot                || 1 work item  ||
[17:01] <ogasawara> ||            || hardware-p-kernel-config-review       || 4 work items ||
[17:01] <ogasawara> ||            || hardware-p-kernel-delta-review        || 3 work items ||
[17:01] <ogasawara> ||            || foundations-p-ipv6                    || 1 work item  ||
[17:01] <ogasawara> || jsalisbury || other-p-bug-workflows                 || 1 work item  ||
[17:02] <ogasawara> || ogasawara  || hardware-p-kernel-config-review       || 3 work items ||
[17:02] <ogasawara> || tgardner   || hardware-p-kernel-delta-review        || 1 work item  ||
[17:02] <ogasawara> If your name is in the above table, please review your Alpha-2 work items.  Note that Alpha-2 is next Thurs Feb 2.
[17:02] <ogasawara> ..
[17:02] <jsalisbury> [TOPIC] Blueprint: hardware-p-kernel-power-management (cking)
[17:02] <cking> no updates this week
[17:02] <cking> ..
[17:03] <jsalisbury> [TOPIC] Status: Precise Development Kernel (ogasawara)
[17:03] <ogasawara> Last week we uploaded the linux-3.2.0-10.17 Ubuntu kernel and we have
[17:03] <ogasawara> also just uploaded linux-3.2.0-10.18.  With Alpha-2 next Thurs, Feb 2,
[17:03] <ogasawara> I'd ideally like to upload our final kernel for the Alpha-2 milestone by
[17:03] <ogasawara> this Friday.  For any patches needing to land in Alpha-2, send them out
[17:03] <ogasawara> to the kernel-team mailing list immediately.
[17:03] <ogasawara> Important Upcoming Dates:
[17:03] <ogasawara>  * Thurs Feb 2 - Alpha 2 (~1 week)
[17:03] <ogasawara> ..
[17:03] <ogasawara> ~
[17:03] <jsalisbury> [TOPIC] Status: CVE's (apw)
[17:03] <apw> [17:03] <apw>
[17:03] <apw> [LINK] http://people.canonical.com/~kernel/cve/pkg/CVE-linux.txt
[17:03] <apw>
[17:03] <apw> Currently open CVEs for each supported branch:
[17:03] <apw>
[17:04] <apw> || Package                                  || Open      ||
[17:04] <apw> ||                                          ||           ||
[17:04] <apw> || linux Hardy                              ||   17 (-3) ||
[17:04] <apw> || linux Lucid                              ||   12      ||
[17:04] <apw> || linux Maverick                           ||   11 (-2) ||
[17:04] <apw> || linux Natty                              ||   10 (-3) ||
[17:04] <apw> || linux Oneiric                            ||    9      ||
[17:04] <apw> || linux Precise                            ||    7      ||
[17:04] <apw> || linux-ec2 Lucid                          ||   12      ||
[17:04] <apw> || linux-fsl-imx51 Lucid                    ||   11 (-4) ||
[17:04] <apw> || linux-mvl-dove Lucid                     ||    9 (-2) ||
[17:04] <apw> || linux-mvl-dove Maverick                  ||    9 (-2) ||
[17:04] <apw> || linux-ti-omap4 Maverick                  ||   12 (-4) ||
[17:04] <apw> || linux-ti-omap4 Natty                     ||    7 (-5) ||
[17:04] <apw> || linux-ti-omap4 Oneiric                   ||    6 (-2) ||
[17:04] <apw> || linux-ti-omap4 Precise                   ||    5 (-2) ||
[17:04] <apw> || linux-lts-backport-maverick Lucid        ||   11 (-2) ||
[17:04] <apw> || linux-lts-backport-natty Lucid           ||   10 (-3) ||
[17:04] <apw> || linux-lts-backport-oneiric Lucid         ||    9      ||
[17:04] <apw>
[17:04] <apw> This week two new CVEs were added both of which were closed out.
[17:04] <apw> Overall we have made some progress in closing the outstanding backlog.
[17:04] <apw>
[17:04] <apw> ..
[17:05] <jsalisbury> [TOPIC] Status: Stable, Security, and Bugfix Kernel Updates - Oneiric/Natty/Maverick/Lucid/Hardy (bjf/herton)
[17:05] <bjf> Here is the status for the main kernels, until today (Jan. 24):
[17:05] <bjf>
[17:05] <bjf>  * Hardy - 2.6.24-30.98
[17:05] <bjf>   * In updates.
[17:05] <bjf>   * Nothing new to prep, there were no new commits on master-next.
[17:05] <bjf>
[17:05] <bjf>  * Lucid - 2.6.32-38.84
[17:05] <bjf>   * Prep'd and uploaded.
[17:05] <bjf>
[17:05] <bjf>  * Maverick - 2.6.35-32.65
[17:05] <bjf>   * Prep'd and uploaded.
[17:05] <bjf>
[17:05] <bjf>  * Natty - 2.6.38-13.55
[17:05] <bjf>   * Prep'd and uploaded.
[17:05] <bjf>
[17:05] <bjf>  * Oneiric - 3.0.0-16.27
[17:05] <bjf>   * Prep'd and uploaded.
[17:05] <bjf>
[17:05] <bjf> Current opened tracking bugs details:
[17:05] <bjf>  * http://people.canonical.com/~kernel/reports/kernel-sru-workflow.html
[17:05] <bjf>
[17:05] <bjf> For SRUs, SRU report is a good source of information:
[17:06] <bjf>  * http://people.canonical.com/~kernel/reports/sru-report.html
[17:06] <bjf>
[17:06] <bjf> Future stable cadence cycles:
[17:06] <bjf>  * https://wiki.ubuntu.com/PrecisePangolin/ReleaseInterlock
[17:06] <bjf> ..
[17:06] <jsalisbury> [TOPIC] Open Discussion or Questions? Raise your hand to be recognized (o/)
[17:07] <jsalisbury> If no questions/discussions, then:
[17:07] <jsalisbury> #endmeeting
[17:07] <meetingology> Meeting ended Tue Jan 24 17:07:29 2012 UTC.
[17:07] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2012/ubuntu-meeting.2012-01-24-17.00.moin.txt
[17:07] <jsalisbury> thanks everyone


[07:33] <davidcalle> Morning o/
[07:43] <dholbach> davidcalle, the page generation refactoring is looking good - the new test case for the disappearing articles (on the 2nd import) passes and there are only two out of 37 tests left to fix now
[07:43] <dholbach> I hope to have something up to test for staging in the next hour
[07:44] <davidcalle> dholbach: \o/
[07:47] <dholbach> davidcalle, and it should help with the work of making Didier's full-tree imports easier
[08:26] <dholbach> at some stage it might make sense to look into speeding up the test suite (480.910s with postgres, 450.254s with sqlite)
[08:27] <dholbach> all tests pass now, next step: testing things manually
[09:22] <dholbach> davidcalle, is the JS redirect fix on prod already?
[09:22] <davidcalle> dholbach: it is
[09:23] <dholbach> cool, I'll file a bug for us to update the definitions, so we can drop old redirects, if that works for you
[09:29] <dholbach> https://bugs.launchpad.net/developer-ubuntu-com/+bug/1568760
[09:38] <davidcalle> dholbach: good idea, but I would wait for a proper admin interface before adding "legacy" redirects. Hopefully I'll have time for this later this week.
[09:38] <dholbach> sure
[09:41] <dholbach> I'll update the bug
[09:55] <davidcalle> Thanks :)
[09:56] <dpm> davidcalle, on the syntax you pasted for me for CLI instructions the other day, do you tend to add </br> to the end of each command?
[09:58] <davidcalle> dpm: you don't, everything in <pre><code> uses linebreaks and indentations it finds in the source view.
[09:58] <dpm> ok, I wasn't sure, thanks for confirming!
[09:58] <davidcalle> np
[11:13] <dpm> davidcalle, do you have other examples of embedded TOC, such as the one in https://developer.ubuntu.com/en/start/ubuntu-for-devices/porting-new-device, or shall I use that one for the page I'm currently working on?
[12:38] <davidcalle> dpm: that's more or less the one used when it needs one, same goes for design docs actually
[12:38] <dpm> davidcalle, thanks, I ended up using it for the get-started page :)
[12:51] <dholbach> davidcalle, the tests were passing, but two consecutive manual imports still showed the same issue... I'm pretty certain I found the issue, I need to think about a fix for this......
[12:52] <davidcalle> ouch :( *hugs*
[12:52] <dholbach> after the import we check if there are pages which were previously imported, but not part of the current import and delete them
[12:53] <dholbach> there's an issue with timestamps I think
[12:53] <dholbach> maybe articles which didn't need an update on the second import ... or something
[13:00] <dpm> davidcalle, argh, I've got an issue whereby when adding the link plugin and saving the page, it undoes all your changes :(
[13:00] <davidcalle> dpm: I have a trick for this! Don't use the link plugin :)
[13:01] <dpm> yeah, a bit late :)
[13:02] <dholbach> dpm, let's file a bug for this and see if a newer version fixes it and it not, let's report it upstream :-/
[13:02] <dholbach> dpm, is it just any page where this happens?
[13:03] <davidcalle> dpm: more seriously, the issue I've seen is when copying a link plugin from on page to another. I don't use it because of this.
[13:04] <dpm> dholbach, I don't know, I've seen it just now on the page I'm editing, now twice. The first time I thought there might have been some cache issues, the second one I think I can track it to the link plugin. Either that, or pages are not getting saved at all, which I don't think it's the case
[13:05] <dpm> also, viewing the history of a page and clicking on one of the history links generates an error page
[13:06] <dpm> perhaps because my page is not yet published?
[13:07] <dholbach> maybe you can write down what you did in a bug report and we try to try to fix it as one of the next things?
[13:07] <dholbach> in any case it's something we would know how to work around, but probably not any of the people who edit dev.u.c just every now and then :/
[13:09] <dholbach> davidcalle, I'm close to filing a bug for this issue and remove the tracking of 'stale pages' for now as a workaround :-)
[13:09] <dholbach> it'd let us bring the importer online
[13:09] <dholbach> ... and would give me a break from this problem ;-)
[13:17] <davidcalle> dholbach: what does it change to the process, if you remove the tracking of stale pages?
[13:18] <dholbach> davidcalle, we would need to delete stale pages, if e.g. a doc in snappy's branch gets deleted or renamed
[13:18] <dholbach> (which doesn't happen all that often)
[13:19] <dholbach> it'd let us deploy now and give us breathing room to fix the issue properly :)
[13:19] <davidcalle> Gotcha, yeah :)
[13:42] <dholbach> davidcalle, https://code.launchpad.net/~dholbach/developer-ubuntu-com/fix-double-imports/+merge/290978 updated
[15:13] <dholbach> mhall119, davidcalle, can we deploy ^ on staging and get a semi-recent db dump loaded? is that a lot of work to get going?
[15:41] <davidcalle> dholbach: db dump will take some time, but upload to staging when I'm out of the call and can fire the vpn :)
[15:42]  * dholbach hugs davidcalle
[15:42] <dholbach> which part takes time?
[15:45] <davidcalle> dholbach: the format we got the dump in. It's basically a copy of the db and not an extract of the db content. I haven't figured a correct way to push it in the db. If we simply replace the db with it, the site doesn't connect (authentication error with the db).
[15:47] <dholbach> ok, I see
[16:03] <davidcalle> dholbach: deployment started, see you in 15 min :)
[16:05] <davidcalle> Juju crashed, starting again 0:-)
[16:07] <dholbach> ouch
[16:13] <davidcalle> dholbach: network is too slow right now apparently, it's going to take ages. I'm going to leave the server, let it run. If it fails, I'll do it again later, I need to drive home. I'll send you results :)
[16:14] <dholbach> no worries
[16:14]  * dholbach hugs davidcalle
[16:14] <dholbach> thanks a lot for your help with this
[16:14]  * davidcalle hugs dholbach back
[16:14] <dholbach> you're an absolute hero
[16:14] <davidcalle> dholbach: have a nice eod o/ :)
[16:14] <dholbach> thanks!


[01:02] <wallyworld> kelvinliu: here's a small PR to fix the pod spec parsing issue https://github.com/juju/juju/pull/10603
[01:02] <kelvinliu> wallyworld: yep looking now
[01:04] <kelvinliu> lgtm thanks
[01:55] <anastasiamac> wallyworld: ask-or-tell add-credential PTAL https://github.com/juju/juju/pull/10604
[05:28] <thumper> https://github.com/juju/juju/pull/10605
[05:30] <thumper> jam ^^
[06:15] <wallyworld> hpidcock: did you need a review of your draft PR?
[06:15] <hpidcock> wallyworld: if you want, I think that would be good seeing as I'm still writing tests, so if something needs to change I'd rather do it now
[06:16] <wallyworld> ok
[06:16] <wallyworld> for tomorrow, i have the next actions PR up
[06:17] <kelvinliu> wallyworld: got 2mins HO? wanna confirm one thing about rbac.
[06:17] <wallyworld> sure
[06:18] <wallyworld> kelvinliu: in standup
[06:18] <kelvinliu> wallyworld: me2. in different room?
[06:22] <wallyworld> hpidcock: got to go AFK until team meeting, will look at PR after that
[06:24] <hpidcock> np no rush at all
[10:31] <stickupkid> achilleasa, CR https://github.com/juju/python-libjuju/pull/355 ?
[10:36] <stickupkid> achilleasa, yeah good shout, i'll fix that
[11:09] <stickupkid> achilleasa i updated and fixed
[11:36] <Parlos> Im deploying Openstack using the bundle (61), all looks fine in 'juju status'. But when I try to upload an image, I get "Error finding address for... Broken pipe". Found a bug report,https://bugs.launchpad.net/glance/+bug/1833009. which seemed to have a similar problem. It was however solved, so Im wondering if the issue in the 'bug' has been addre
[11:36] <Parlos> ssed in the current bundle, and/or this could be something else...
[11:36] <mup> Bug #1833009:  openstack image create fails with [Errno 32] Broken pipe  for openstack rocky and stein <glance> <juju> <openstack> <Glance:New> <https://launchpad.net/bugs/1833009>
[12:54] <magicaltrout> i'm not sure whats more broken
[12:54] <magicaltrout> the uk political system
[12:54] <magicaltrout> or my attempts to test juju on k8s
[12:54] <magicaltrout> https://discourse.jujucharms.com/t/cant-bootstrap-internal-k8s/2032/3
[12:54] <magicaltrout> if anyone has any ideas
[12:55] <magicaltrout> (we all know the correct answer is the uk political system)
[13:00] <stickupkid> magicaltrout,  the uk political system <- this
[13:03] <danboid> What happened to juju-gui / juju-quickstart? Is it dead?
[13:04] <magicaltrout> juju gui is still juju gui
[13:04] <rick_h> danboid:  basically, the gui is in maintenance mode while they do a new gui tool for management
[13:04] <magicaltrout> juju-quickstart is conjure-up now
[13:04] <magicaltrout> ish
[13:04] <magicaltrout> or whatever rick_h says... he clearly knows
[13:11] <danboid> After having a quick look at the conjure-up site, I don't think it is a (web) UI to juju, more like a wrapper of some sort?
[13:11] <danboid> It obvs depends on juju
[13:11] <rick_h> yea
[13:14] <magicaltrout> well juju gui exists if you've got a bootstrapped controller
[13:14] <magicaltrout> you just run
[13:14] <magicaltrout> juju gui
[13:14] <magicaltrout> its just not getting love from the devs
[13:36] <danboid> When you run 'juju register' what does it do? ie why is it taking multiple minutes on my i7 w/ 16GB RAM, gigE etc to register
[13:38] <danboid> I expected it would've been instantanous? Maybe its gone wrong?
[13:38] <danboid> It asked me for a password and the controller name but that was a good few minutes ago
[13:45] <rick_h> danboid:  it's trying to reach out to the controller and login
[13:48] <danboid> rick_h, Seems it failed. What port needs to be open on the controller?
[13:49] <danboid> ERROR Provided registration token may have been expired.
[13:50] <danboid> but it took several  minutes to show that
[13:53] <danboid> 17017 ?
[13:54] <rick_h> danboid:  the normal 17017 yea
[15:44] <stickupkid> rick_h, another merge forward of changes pylib https://github.com/juju/python-libjuju/pull/356
[15:45] <rick_h> stickupkid:  +1
[15:45] <stickupkid> rick_h, ta
[15:52] <jhobbs> rick_h: we're seeing this when attempting to bootstrap juju against openstack; any ideas? http://paste.ubuntu.com/p/FbVmmJv8xX/
[15:52] <rick_h> jhobbs:  looking
[15:52] <jhobbs> i'm not sure how key management with juju and openstack works; openstack doens't show any keypairs associated with the instance
[15:53] <rick_h> jhobbs:  have you tried to clear the ssh key in known_hosts for <IP_ADDRESS> on the client?
[15:54] <rick_h> jhobbs:  quick glance it looks like the VM comes up, gets an IP, and the client attempts to connect to the controller over the IP and fails due to an existing (different key) for the controller IP
[15:55] <jhobbs> yeah so it's using that tmp file for keys
[15:55] <jhobbs> which juju owns
[15:55] <jhobbs> /tmp/juju-known-hosts764870299:1
[15:55] <jhobbs> if i remove the key with the command it suggests, I get this instead:
[15:55] <jhobbs> 15:55:34 DEBUG juju.provider.common bootstrap.go:576 connection attempt for <IP_ADDRESS> failed: No RSA host key is known for <IP_ADDRESS> and you have requested strict checking.
[15:55] <jhobbs> Host key verification failed.
[15:56] <rick_h> jhobbs:  oic, hmmm not seen anything with that to date.
[15:56] <rick_h> jhobbs:  is there an entry in that file?
[15:56] <rick_h> jhobbs:  in /tmp/juju-known-hosts764870299 ?
[15:57] <jhobbs> let me see
[15:59] <jhobbs> <IP_ADDRESS> ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCzZr0m8iigEmkMoZva1pdaJ7U9eC61yg+wwq1isIbZPokHnBBGSKq74KojG8MJOVYSO2eeAharfGIXxfdHtqy6/5DFOF0SfL2IhVz3rDvBBGmuL1OrNO9vcZn/SNRK2ZaJm82r3BsA2M6kcJFxeq+PZ8gukcaqYAGq269Pz5+QWueVKHbiIQEPaLhuhDI+AnaqoGtmldz38xohvAglRfDTJtSfrHZzyley/3wLjZ+kC7IGeoWhGQ5pG6Sl+jjGoYom4GANDUFUDFIXxMfE/w0TCZbR6YeOliEjZJshzO4fM9fOgbxPZHkgOcj7k4jtNeJeOez7x4cKTB7G/ZN9N9E7 juju-bootstrap
[16:00] <jhobbs> maybe juju prepopulates that file with the key for the instance? maybe it gets it from the openstack api?
[16:01] <hml> jhobbs: there’s an ssh key in the cloud init used to create the instance.
[16:02] <hml> no keys via the openstack api directly
[16:02] <jhobbs> ok
[16:03] <jhobbs> so maybe it's not getting that cloud-init
[16:03] <hml> jhobbs:  bootstrapping to checkout a few things
[16:04] <hml> jhobbs:  there is a key created to use during bootstrap.
[16:06] <jhobbs> ok
[16:06] <jhobbs> I think the instance isn't getting the metadata for some reason
[16:06] <jhobbs> the cloud-init userdata from the metadata server
[16:08] <hml> then another key once it’s up for system
[16:16] <stickupkid> rick_h, achilleasa, the last pylibjuju commit around bundle changes https://github.com/juju/python-libjuju/pull/357
[16:16] <rick_h> hml:  thanks for helping out, I've got to get ready to go to that family thing and will be afk for a bit
[16:17] <hml> jhobbs: what’s odd too, is that the tmp file is created, used and removed during bootstrap
[16:18] <jhobbs> hml: right
[16:18] <jhobbs> hml: i think the instance is generating its own ssh server key because it's not getting the one from metadata
[16:18] <jhobbs> hml: so it's getting a mismatch
[16:18] <hml> jhobbs:  are you using the edge snap?
[16:18] <jhobbs> no hml, 2.6.8
[16:25] <hml> jhobbs:  i can’t reprod myself with openstack  ; but i do get it trying to directly ssh to the controller instance.
[16:28] <hml> though juju ssh works… it’s using a different key… so there are 3 over the process of bootstrap and configuring a machine.
[16:39] <hml> jhobbs: what’s configured via the model_defaults.yaml  ?
[16:53] <achilleasa> stickupkid: approved; on a sidenote, the relevant juju PR enountered CI errors on merge
[16:54] <stickupkid> achilleasa, :(
[16:56] <stickupkid> achilleasa it was an intermittent failure
[22:25] <wallyworld> babbageclunk: can you jump in standup HO?
[22:25] <babbageclunk> sure sure