=== alexlist` is now known as alexlist
=== _salem is now known as salem_
=== salem_ is now known as _salem
=== FJKong is now known as FJKong_afk
[01:59] <smoser> jbicha, that is fixed. i think.
[02:02] <smoser> jbicha, its stick in proposed
[02:02] <smoser> hmm.
[02:02] <smoser> https://launchpad.net/ubuntu/+source/cloud-init
[02:05] <smoser> hm.. anyone able to help with that ? the fix is in saucy-proposed. it was fixed in 0.7.3~bzr829-0ubuntu2, and is subsequently fixed in 0.73~bzr
[02:07] <smoser> i have to run, but i'd love it if someone could let that through -proposed for me ...
[02:10] <micahg> cloud-init/i386 unsatisfiable Depends: python-jsonpatch
[02:10] <micahg> trying: cloud-init
[02:10] <micahg> skipped: cloud-init (16 <- 67)
[02:10] <micahg>     got: 83+0: i-83
[02:10] <micahg>     * i386: cloud-init, ec2-init, walinuxagent
[02:14] <micahg> smoser: ^^ that's why
[02:18] <jbicha> it's not fixed, look in the build log for jsonpatch
=== _salem is now known as salem_
[02:18] <jbicha> I mean look in the cloud-init build log for "jsonpatch"
=== FJKong_afk is now known as FJKong
[03:22] <roaksoax> doko_: around already?
[03:37] <pitti> Good morning
[03:38] <FJKong> pitti: noon for now :)
[03:38] <pitti> FJKong: welcome to time zones :)
[03:39] <FJKong> lol
[03:53] <pitti> slangasek: ah right, sorry for not looking at main/universe in the list
=== FJKong is now known as FJKong_afk
=== Ursinha is now known as Ursinha-afk
[04:14] <pitti> TheMuso: FYI, I binNEWed alsa to fix the major uninstallability on amd64 (and thus related autopkgtest failures)
[04:25] <ScottK> Anyone seeing problems with curl trying to use IPv6 when it's not available in raring (Bug 1205185) - It just started for me recently, but is persistent.
[04:25] <ubottu> bug 1205185 in curl (Ubuntu Raring) "curl has apparently started attempting IPv6 even when it's not available" [Undecided,New] https://launchpad.net/bugs/1205185
[04:26] <micahg> ScottK: I got the same thing on precise
[04:26] <ScottK> So maybe it is on the server side.
[04:43] <TheMuso> pitti: I thought nothing was migrated from proposed till al deps were satisfied. I was aware of the bin new requirement, but maybe my knowledge on how proposed is used is incomplete or incorrect...
[04:43] <pitti> TheMuso: no, that's correct
[04:44] <pitti> TheMuso: the FYI was "this block should resolve itself soon now"
[04:44] <TheMuso> pitti: Right, thanks for the heads up, its not time critical.
=== salem_ is now known as _salem
[06:45] <dholbach> good morning
=== highvolt1ge is now known as highvoltage
=== tkamppeter__ is now known as tkamppeter
=== smb` is now known as smb
=== Ursinha is now known as Ursinha-afk
=== maxb_ is now known as maxb
=== iahmad_ is now known as iahmad|afk
=== mthaddon` is now known as mthaddon
=== didrocks is now known as didrocks_reallyb
=== didrocks_reallyb is now known as didrocks_busy
=== lan3y is now known as Laney
=== Ursinha-afk is now known as Ursinha
=== iahmad|afk is now known as iahmad
[09:06] <ev> seb128, Laney: do you have time today for a review of https://code.launchpad.net/~ev/ubuntu-system-settings/diagnostics/+merge/174385 ?
[09:06] <Laney> sure
[09:06] <ev> cheers!
[09:06] <seb128> Laney, I'm fine with the code, feel free to approve it once you are happy with it as well
[09:06] <seb128> (I didn't runtime test it, but seems you are doing that)
[09:07] <Laney> I'll do it right now
[09:07] <seb128> thanks
[09:17] <Laney> ev: oho, looks like alm is depwaiting
[09:18] <Laney> component-mismtaches
[09:18] <Laney> seb128: want to promote? https://bugs.launchpad.net/ubuntu/+source/whoopsie-preferences/+bug/1203067
[09:18] <ubottu> Ubuntu bug 1203067 in whoopsie-preferences (Ubuntu) "[MIR] whoopsie-preferences" [Undecided,Fix committed]
[09:23] <infinity> Laney: I've got it.
[09:23] <seb128> Laney, done
[09:23] <seb128> doh
[09:24] <seb128> infinity, ^
[09:24] <infinity> Oh, or not.  I hadn't run the command yet. ;)
[09:24] <Laney> Archive admins: FIGHT
[09:24] <seb128> ;-)
[09:24] <ev> lol!
[09:25] <infinity> seb128: Your pasted output leads me to believe you promoted the binary, but not the source.  Is it you that keeps doing that?
[09:25] <seb128> infinity, I did "./change-override -c main -S whoopsie-preferences" ... is that wrong?
[09:26] <seb128> infinity, I'm just using https://wiki.ubuntu.com/ArchiveAdministration as reference,
[09:26] <infinity> seb128: No, that's right.  You just only pasted the top line of that output.
[09:26] <seb128> To demote a source package and all of its binaries to universe:
[09:26] <seb128>     $ ./change-override -c universe -S tspc
[09:26] <seb128> infinity, oh, right, I didn't want to spam
[09:26] <seb128> sorry about that :p
[09:27] <infinity> Kay.  All good.  Now I need to sort out who it is who keeps promoting binaries and not source, since it's not you. :)
[09:27] <seb128> hehe, good luck ;-)
[09:27] <StevenK> infinity: auditor will fix that
[09:27] <StevenK> When it actually happens
[09:35] <racerunner> i need wire transfer only contact whitoli665@outlook.com
[09:54] <Laney> ev: Ah, I wasn't in the 'admin' group which the polkit override checks for, only 'sudo'
[09:54] <Laney> ev: I'll fix that one
[09:54] <ev> ahh, cheers
[09:55] <ev> what's the standard for testing dbus services these days?
[09:56] <Laney> ev: Could you make it so that clicking on the ListItem triggers the action too please?
[09:56] <Laney> I thought it wasn't working for a while because of that
[09:56] <ev> sure
[09:56] <Laney> great
[09:57] <Laney> ev: pitti's python-dbusmock?
[09:57] <ev> ooh, I'll have a look. cheers
=== davmor2_ is now known as davmor2
[10:10] <Laney> ev: Ah, I forgot - that snippet in the .pkla file is something you told me to put there. :P
[10:10] <Laney> Maybe you want to ship one from whoopsie-preferences instead?
[10:11] <pitti> ev: http://pypi.python.org/pypi/python-dbusmock has the README
[10:12] <ev> Laney: that's tricky. I think we want different pklas for Touch and desktop
[10:12] <ev> because on touch we don't have random password dialogs
[10:12] <ev> but those are a staple of the desktop experience ;)
[10:13] <ev> pitti: ah, nice one
[10:15] <pitti> ev: I use dbusmock for testing e. g. gnome-settings-daemon, to mock polkit and logind
[10:16] <ev> ah excellent, I'll have a look at those tests as a guide
[10:22] <Laney> ev: I don't understand what you mean - this would mean you have fewer authentication dialogs
=== doko_ is now known as doko
[10:24] <ev> Laney:  the purpose of that pkla is to replace an auth_keep dialog with a pass for anyone in an admin group. This makes sense on Ubuntu Touch where we don't have password dialogs (to my knowledge), but I am not sure it makes sense on the desktop where it's entirely normal to have an "unlock" button that is followed by a password dialog (see gnome-control-center -> security & privacy -> diagnostics).
[10:24] <ev> Does that make more sense?
[10:24] <ev> I am definitely open to suggestion here
[10:25] <ev> or direction for that matter :)
[10:25] <ev> desktop is not my baby
[10:26] <doko> Laney, seb128: does this ring a bell in gtk+3.0?
[10:26] <doko> # Install the binaries with a -3.0 suffix
[10:26] <doko> mv debian/libgtk-3-0/usr/lib/aarch64-linux-gnu/libgtk-3-0/gtk-update-icon-cache \
[10:26] <doko> debian/libgtk-3-0/usr/lib/aarch64-linux-gnu/libgtk-3-0/gtk-update-icon-cache-3.0
[10:26] <doko> mv: cannot stat 'debian/libgtk-3-0/usr/lib/aarch64-linux-gnu/libgtk-3-0/gtk-update-icon-cache': No such file or directory
[10:26] <doko> make: *** [binary-install/libgtk-3-0] Error 1
[10:26] <doko> $ find -name gtk-update-icon-cache
[10:26] <doko> ./debian/install/shared/usr/bin/gtk-update-icon-cache
[10:26] <doko> ./debian/build/shared/gtk/gtk-update-icon-cache
[10:30] <Laney> ev: Hmm. I thought polkit authentication was planned on touch but just not implemented yet.
[10:31] <Laney> Anyway, AIUI whoopsie-preferences will currently never prompt the user so this can't succeed
[10:32] <ev> if you know of some buried google doc that mentions this, I'd be quite interested to have a link
[10:32] <Laney> I guess implement that and then on touch you'd ship a pkla to skip it in some touch-polkit-policies package
[10:32] <ev> Laney: hm? It does polkit_authority_check_authorization_sync around the calls
[10:32] <seb128> Laney, ev: I'm not sure what are the exact plan, but there were talk about adding the auth dialog to mir/unity (the way it's gnome-shell doing those in GNOME nowadays)
[10:32] <seb128> Laney, ev: not sure that's needed for the phone and on the roadmap for v1 though
[10:32] <Laney> ev: Isn't that what POLKIT_CHECK_AUTHORIZATION_FLAGS_NONE says?
[10:32] <seb128> it might just be a "later" item for the convergence
[10:33] <Laney> the knowledge I have is hearsay I'm afraid
[10:33] <ev> oh curious
[10:34] <Laney> a lot of systemd dbus methods have a user_interaction flag that controls whether you are allowed to prompt or not
[10:34] <ev> that's the same code that's always been there, and I got a prompt before I started fiddling with my pkla
[10:34] <ev> so we should set that to POLKIT_CHECK_AUTHORIZATION_FLAGS_ALLOW_USER_INTERACTION then?
[10:36] <Laney> only if it is always called in response to a user action (let me check if it works)
[10:38] <Laney> yeah, I got prompted as soon as I went into diagnostics
[10:39] <Laney> So, I'll approve the s-s MP since it's all OK on that side and you can tinker with this stuff
[10:39] <ev> whoop
[10:40] <Laney> wait, did you push that change to the ListItem yet? :P
[10:41] <ev> working on it :)
[10:42] <Laney> ok, well ping me and I'll do it then
[10:42] <ev> will do
[10:51] <doko> Laney, seb128: any idea about gtk+3.0?  and is it necessary to enable the docs build for the binary-arch only build?
[10:55] <pitti> cjwatson: I'm just stunned by LP's publisher these days -- like, did you take out the sleep(1200) there?
[10:55] <pitti> cjwatson: thanks for that, amazing work!
[11:03] <Laney> doko: No, I don't know how it gets moved out of bindir into libdir
[11:03] <Laney> or wherever it gets moved to
[11:05] <Laney> doko: docs build> I guess not, try it :-)
[11:08] <seb128> doko, no real idea offhand either sorry
[11:09] <cjwatson> pitti: Heh, yeah, it was mostly William and Adam; mainly, we noticed that the apt-ftparchive caches hadn't been cleaned properly and had thus grown to enormous sizes, and cleaning them made a huge difference
[11:09] <cjwatson> pitti: So I then did https://code.launchpad.net/~cjwatson/launchpad/publisher-ftparchive-clean/+merge/173226 to make sure that won't happen again
[11:10] <pitti> cjwatson: yeah, I noticed that in ddeb-retriever too, I kill them every now and then
[11:10] <cjwatson> pitti: We also changed it to try to run every five minutes if one isn't running, rather than every 30, which I'd sort of been thinking about for a while
[11:11] <pitti> cjwatson: the last time I looked at the publisher run time (> 1 year ago, though) it still took > 20 mins
[11:11] <pitti> cjwatson: nice to hear that this was indeed just due to apt-ftparchve
[11:12] <ev> Laney: r135 fixes it. Sorry that took so long.
[11:13] <Laney> ev: thanks, no worries - I wasn't sitting on the edge of my seat for it or anything :P
[11:13] <ev> :)
[11:13] <cjwatson> pitti: Well, other bits and pieces over that timeframe, but yeah
=== MacSlow is now known as MacSlow|lunch
=== MacSlow|lunch is now known as MacSlow
[11:50] <pitti> jibel, dobey: seems I fixed autopkgtest's "allow-stderr" hard enough, saucy-adt-{dirspec,ubuntuone-client} are green now \o/
[11:50] <pitti> well, blue in public jenkins, but YKWIM :)
[11:52] <pitti> jibel: critical Friday-afternoon bug: we so much need the "green bullets" jenkins plugin back!
[12:03] <jibel> pitti, I know, we already tried to re-enable it with IS on jenkins.qa.u.c but it breaks sevelral other plugins and no images are loaded at all
[12:03] <pitti> jibel: urgh; well, it must be thousands of lines of code, it's a rather complex plugin after all
[12:04] <jibel> :)
=== _salem is now known as salem_
=== 20WACTA0R is now known as tvoss
=== steveire_ is now known as steveire
[13:11] <tvoss_> cjwatson, ping
[13:46] <cjwatson> tvoss: yes?
[13:49] <tvoss_> cjwatson, asac mentioned that you were looking into cmake cross compiling
[13:52] <cjwatson> tvoss_: well.  in theory it's somewhere on my list and I've looked at it before, but it's not something I'm likely to get to for at least a month
[13:52] <smoser> hey.. i need some help.
[13:52] <smoser> why is cloud-init 0.7.3~bzr869-0ubuntu1 stuck in proposed ?
[13:52] <smoser> https://launchpad.net/ubuntu/+source/cloud-init
[13:52] <tvoss_> cjwatson, ack, let me know when you start looking into it, mir has got support for it
[13:53] <cjwatson> tvoss_: OK
[13:53] <cjwatson> smoser: Because it's uninstallable in -proposed
[13:53] <cjwatson> The following packages have unmet dependencies.
[13:53] <cjwatson>  cloud-init : Depends: python-jsonpatch but it is not installable
[13:53] <smoser> but i dont think that is true. where do you see that ?
[13:53] <cjwatson> I ran 'chdist apt-get saucy-proposed-i386 install cloud-init' as ubuntu-archive@lillypilly
[13:54] <cjwatson> And http://people.canonical.com/~ubuntu-archive/testing/saucy-proposed_probs.html agrees
[13:54] <cjwatson> Your package depends on it and it's not in the archive
[13:54] <cjwatson> proposed-migration is absolutely correct
[13:55] <cjwatson> Just the same as when you asked 11 hours ago :)
[13:55] <smoser> so i *did* most definitely make that typo
[13:56] <cjwatson> smoser: The current version in -proposed is bzr849, not bzr869 as you mentioned above, if that helps
[13:56] <smoser> right
=== salem_ is now known as _salem
[13:56] <smoser> yeah, another typo
[13:56] <smoser> :)
[13:57] <doko> seb128, pitti: why does pygtk b-d on python-numpy-dbg?
[13:57] <doko> but not python-numpy
=== _salem is now known as salem_
[13:59] <smoser> but i have no idea how thats getting there.
[13:59] <Laney> https://launchpadlibrarian.net/145863443/buildlog_ubuntu-saucy-i386.cloud-init_0.7.3~bzr849-0ubuntu1_UPLOADING.txt.gz
[14:00] <Laney> see dh_python2 warnings
[14:00] <smoser> Laney, thank you.
[14:01] <smoser> is there a way to fix dh_python2 for that ?
[14:01] <cjwatson> It says how in the warning text
[14:02] <cjwatson> And in the dh_python2 man page
[14:06] <seb128> doko, that's coming from debian, unsure, it should probably b-d on both
[14:06] <seb128> doko, it happens to work because the dbg bring the normal package in
[14:07] <doko> seb128, I though I removed that before for ubuntu ...
[14:07] <doko> did it creep in again?
[14:07] <smoser> cjwatson, well, yeah, the pydist-overrides is clear. but is there a way to fix that so that every package gets it?
[14:07] <cjwatson> smoser: What's the package really called?
[14:08] <Laney> smoser: build-depend on the package
[14:08] <smoser> python-json-patch
[14:08] <cjwatson> Wouldn't it be simplest to rename it to match the module name?
[14:08] <cjwatson> Or Provides: python-jsonpatch if that's hard for some reason
[14:09] <seb128> doko, you removed the runtime depends, not the build-depends
[14:09] <seb128> doko, http://launchpadlibrarian.net/22962155/pygtk_2.13.0-2ubuntu4_2.13.0-2ubuntu5.diff.gz
[14:09] <cjwatson> Having packages that violate Python naming policy is kind of asking for trouble
[14:09] <doko> ahh, ok
[14:09] <doko> what a pity ..
[14:11] <smoser> cjwatson, ok. so i will open a debian bug suggesting . thanks.
[14:11] <cjwatson> smoser: The Provides should be easy to add in Ubuntu in the meantime, although renaming the package is more correct
[14:12] <cjwatson> That should let cloud-init in, or at least move you on to the next problem
[14:22] <smoser> cjwatson, I just filed debian bug. so you think adding Provides to python-json-patch is the best path ?
[14:23] <smoser> my 2 other questions to expose ingorance of mysefl are
[14:23] <cjwatson> smoser: It's not the best path for Debian, but it's the least-effort one for Ubuntu
[14:23] <cjwatson> In general Python packages should be named according to the Python policy
[14:23] <smoser> a.) I guess if i have dh_python2 I do not need the explicit depends listed in my debian/control
[14:23] <cjwatson> http://www.debian.org/doc/packaging-manuals/python-policy/ch-module_packages.html#s-package_names
[14:23] <smoser> right. i pointed at that in my bug to ubuntu
[14:24] <smoser> err... bug to debian
[14:24] <smoser> b.) when i just run 'debuild' i dont see output with those pydist warnings. what obvious thing am i doing wrong?
[14:24] <cjwatson> a) I believe not but test
[14:24] <smoser> (warnings shown https://launchpadlibrarian.net/145863443/buildlog_ubuntu-saucy-i386.cloud-init_0.7.3~bzr849-0ubuntu1_UPLOADING.txt.gz)
[14:25] <Laney> (b) You'll have the Depends installed which means that dh_python2 can map the modules back to package names
[14:25] <Laney> which is why I suggested adding it to build-depends
[14:25] <cjwatson> Right, so you could ... indeed, that
[14:25] <smoser> Laney, right i figured that was why that would resolve it.
[14:26] <cjwatson> In principle you want the modules installed anyway so you can run the test suite that you have ... right? :)
[14:26] <smoser> but if I added the build-depends, then i'd have to change package name at some point in the future, but clearly whatever happens with that package name has to think about that anyway.
[14:26] <cjwatson> Yeah
[14:26] <smoser> i'll add build-depends. thank you.l
[14:53] <seb128> Laney, ev: did we need that split main.pro/security-privacy.pro in security-privacy?
[14:53] <seb128> it seems suboptimal, it shows as a subtree "main" in qtcreator
[14:53] <seb128> rather than having the panel and just a subdir in it
[14:54] <ev> seb128: Laney requested that diagnostics live under security-privacy. If there's a better way of structuring that, please do share. I'm a bit wet behind the ears when it comes to qmake.
[14:56] <seb128> ev: I would just have made one .pro listing all the files but maybe it doesn't work for a reason I'm overlooking
[14:57] <Laney> seb128: Seemed a neat enough way of splitting it up to me
[14:57] <seb128> Laney, we have
[14:57] <seb128> > security
[14:58] <seb128>   > main
[14:58] <seb128>    > whoopsie
[14:58] <seb128> ups
[14:58] <seb128> main/whoopsie at the same level
[14:58] <seb128> why not simply
[14:58] <seb128> >security-panel
[14:58] <seb128>    > whoopsie
[14:58] <seb128> with main just being the panel dir?
[14:58] <Laney> I don't mind
[14:58] <Laney> feel free to do that
[14:58] <Laney> If it worked I didn't want to make ev redo it
[14:58]  * seb128 wishes there was a way to hide all those common/coverage/etc item in qtcreator
[15:21] <tkamppeter> mlankhorst, hi
[15:23] <sil2100> ricmm, tvoss_: hi guys, a question related to platform-api and qtubuntu - since greyback has some changes in those branches that he needs for unity-mir, do you know when that will be merged into trunks?
[15:24] <sil2100> ricmm, tvoss_: so that we can daily-release unity-mir already
[15:26] <tvoss_> sil2100, no idea
[15:27] <ricmm> sil2100: he has no changes in those branches to me merged
[15:27] <ricmm> sil2100: I have build rules changes to enable the mir building and deps
[15:27] <ricmm> but that cannot land until Mir is in main
[15:42] <sil2100> seb128: hi! Do you have a moment for a packaging ACK?
[15:43] <seb128> sil2100, sure
[15:44] <sil2100> ricmm: hmmm, so, only that is blocking building unity-mir
[15:44] <sil2100> seb128: http://10.97.0.1:8080/view/cu2d/view/Head/view/SDK/job/cu2d-sdk-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_ubuntu-ui-toolkit_0.1.46+13.10.20130726.1-0ubuntu1.diff
[15:45] <ricmm> sil2100: are you trying to publish unity-mir to disto?
[15:46] <seb128> sil2100, seems fine, are you sure it builds (I just received ppa emails about the ui toolkit failing to build)
[15:47] <sil2100> ricmm: maybe not yet, but we'd like to get it autolanding and daily-releasing to a PPA at least, and didrocks_busy said we'll do that only if all deps are ready
[15:47] <sil2100> seb128: it's building, we fixed the FTBFS earlier
[15:48] <sil2100> seb128: thanks!
[15:49] <ricmm> sil2100: well deps arent ready, we need to wait for Mir to land in distro
[15:50] <ricmm> once that happens I will land the dep MRs for qtubuntu and platform-api, which are already in place
[15:50] <ricmm> unity-mir currently lands in phablet-team/mir for auto building of the phone/mir image
[15:50] <ricmm> but not via daily release, once the chain of deps set up from distro then you are good to enable it
[15:51] <sil2100> Ok
[15:51] <ricmm> didier knows that tho, he knows the point we are at re landing of Mir
[15:51] <sil2100> ricmm: thanks!
[15:51] <sil2100> ricmm: he's busy busy right now so I didn't want to pester him, prefered pestering upstream instead ;)
[15:51] <robotfuel> ev: ping
[15:52] <ev> robotfuel: hi
[15:53] <robotfuel> ev: https://bugs.launchpad.net/ubuntu/+source/whoopsie-preferences/+bug/1205394 I just ran into this packaging bug on saucy, and wasn't sure where the right place for the bug is
[15:53] <ubottu> Ubuntu bug 1205394 in whoopsie-preferences (Ubuntu) "distupgrade fails in saucy because whoopsie-preferences _0.8_amd64.deb is trying to overwrite '/usr/bin/whoopsie-preferences', which is also in package activity-log-manager-control-center 0.9.4-0ubuntu6.1" [Undecided,New]
[15:53] <robotfuel> ev: launchpad says you're the owner, so I thought I'd ask you
[15:54] <ev> robotfuel: please install activity-log-manager 0.9.7-0ubuntu4
[15:55] <ev> I'll sort the bug out though
[15:55] <robotfuel> ev: apt-get install -f fixes it, but we don't want the dist-upgrade failure to happen right?
[15:56] <robotfuel> ev: is that the write place for the bug?
[15:56] <ev> it is, yes
[15:56] <ev> thank you
[15:57] <sil2100> seb128: last packaging ACK, phone: http://10.97.0.1:8080/view/cu2d/view/Head/view/Phone/job/cu2d-phone-head-3.0publish/lastSuccessfulBuild/artifact/packaging_changes_address-book-app_0.2+13.10.20130726-0ubuntu1.diff
[15:57] <sil2100> seb128: thank yoU!
[15:57] <sil2100> seb128: it adds a new package, it's hard to catch everything from a diff but it builds and looks ok
[15:58] <seb128> sil2100, nack, please name the binary qtdeclarative5-ubuntu-contacts<version>
[15:59] <seb128> sil2100, see kenvandine's comment today on https://code.launchpad.net/~seb128/gsettings-qt/rename-binary-package/+merge/177141
[15:59] <seb128> "we decided to change the package naming convention to qtdeclarative5-name1.0."
[15:59] <sil2100> seb128: so not qtdeclarative5-ubuntu-contacts-plugin but for instance qtdeclarative5-ubuntu-contacts1.0 ?
[15:59] <seb128> yes
[15:59] <sil2100> seb128: ACK! Good to know :)
[15:59] <seb128> thanks
[15:59] <seb128> better to fix it before it lands
[16:00] <seb128> otherwise we need to do a transition
[16:02] <kenvandine> sil2100, seb128: i proposed a branch for the contacts plugin
[16:02] <kenvandine> https://code.launchpad.net/~ken-vandine/address-book-app/versioned_plugin/+merge/177159
[16:03] <sil2100> kenvandine: ah! ha! Fast one ;)
[16:03] <kenvandine> :)
[16:03] <seb128> kenvandine, approved
[16:03] <sil2100> kenvandine: thanks, I was in the middle of doing that, but at least I won't have to push!
[16:03] <kenvandine> :-D
[16:03] <seb128> kenvandine, I can't change the status though
[16:04] <kenvandine> i did it this morning when i saw the publish failed
[16:04] <sil2100> seb128: approved it globally
[16:05] <kenvandine> sil2100, thx
[16:05] <seb128> sil2100, thanks
[16:05] <sil2100> kenvandine: the publish was in manual publishing, not failed! :) There was also the issue with SDK and the AP machines
[16:05] <kenvandine> sil2100, yeah... that's what i meant
[16:05] <kenvandine> because of the packaging changes
[16:06] <kenvandine> sil2100, is sdk fixed?
[16:06] <sil2100> kenvandine: yes! Published already
[16:06] <kenvandine> great
[16:06] <kenvandine> thx
[16:07] <sil2100> kenvandine: I have a problem with webapps though...
[16:07] <sil2100> kenvandine: since!
[16:07] <sil2100> kenvandine: I modified the config to include the missing packages: (extra ones) and redeployed the stack twice already
[16:07] <didrocks_busy> sil2100: I hope next week we won't have sdk to be published at 6PM ;) remember I won't be around at all, in a sprint :)
[16:08] <kenvandine> didrocks_busy, good times :)
[16:08] <sil2100> didrocks_busy: I promise! I filled in a bug early, the bug was fixed quickly but the merger couldn't get the fix in for some time
[16:08] <didrocks_busy> kenvandine: thanks!
[16:08] <sil2100> didrocks_busy: because of failing mediumtests
[16:09] <didrocks_busy> sil2100: ah, so upstream failures?
[16:09] <sil2100> Flacky tests, need to report those
=== didrocks_busy is now known as didrocks
=== Sweetsha1k is now known as Sweetshark
=== bfiller is now known as bfiller_lunch
=== bfiller_lunch is now known as bfiller
[17:38] <doko> SpamapS, online?
[17:40] <SpamapS> doko: I am. Wassup?
=== sam113101 is now known as sam113101_afk
=== sam113101_afk is now known as sam113101
=== salem_ is now known as _salem
=== _salem is now known as salem_
[17:59] <roaksoax> doko: howdy! So I've filed a removal bug for system-config-cluster, I have uploaded a new lvm2 disbaling clvm (which had build-deps from redhat-cluster). Also uploaded a new qpidd removing those build-deps. That should allow to remove redhat-cluster from the archives
[18:02] <slangasek> barry: apt-clone's testsuite is making me stabby.  I think I need a refresher on how to sanely write python2/3 bilingual unicode handling.  Can you point me to some appropriate docs?  I keep finding "and here's the right way to do it in python3, ignore that old python2 stuff" which I only wish I could
[18:25] <gQuigs> I was wondering if all the desktop related lucid bugs on here: http://people.canonical.com/~ubuntu-archive/pending-sru.html, could just be closed
[18:26] <doko> roadmr, is not building clvm the right thing to do?
[18:26] <doko> roaksoax, ^^^
[18:26] <roadmr> doko: hehe :)
[18:26] <doko> when used with
[18:26] <doko>  Red Hat's "cman" or corosync based (eg Pacemaker) cluster infrastructure.
[18:26] <doko> so it doesn't seem to be the case
[18:27] <gQuigs> at least xserver-xorg-video-openchrome, gnome-power-manager and moon
[18:27] <cjwatson> gQuigs: (no opinion right now as it's Friday evening, but) please don't close them without an SRU team member being involved because if we were rejecting those bugs we'd also need to remove the uploads from lucid-proposed
[18:28] <roaksoax> doko clvm supports cman, corosync or openais
[18:28] <gQuigs> cjwatson: ACK
[18:28] <roaksoax> but also depends on libdlm
[18:28] <roaksoax> which is currently shipped with tedhst cluster
[18:28] <roaksoax> however theres a new source package called dlm
[18:29] <roaksoax> that will ship this
[18:29] <roaksoax> doko so we neef to drop redhat-cludter first
[18:30] <doko> roaksoax, ok, so something from libdlm replaces it, correct?
[18:32] <roaksoax> doko: the dlm source will have libdlm binary (i already uploaded to the new queue) but we nred tonfrop redhat-cluster first
[18:32] <roaksoax> dlm got split from redhst-cluster source into its own
[18:32] <doko> ok
[18:32] <doko> but why remove it first?
=== cr3_ is now known as cr3
=== cr3 is now known as Guest69521
[18:34] <roaksoax> doko cause redhat-cluster is blocking corosync. So clvm needs newer corosync
=== Guest69521 is now known as cr3
[18:37] <roaksoax> and theres a weird build issue with the lvm2 packagr which fails for not finding corosyn... but if i build locally with newer corosync it works
[18:37] <doko> roaksoax, qpidd?
[18:37] <doko> so what did you upload?
[18:38] <roaksoax> 1. disabled clvm in lvm3 for the time being
[18:38] <doko> lvm3, not lvm2?
[18:39] <roaksoax> typo
[18:39] <roaksoax> lvm2
[18:39] <roaksoax> 2. disabled cman support in qpid
[18:39] <roaksoax> newer upstreams drops it
[18:40] <roaksoax> 3. dlm (which is in the new queue)
[18:41] <doko> ahh, qpid
[18:45] <doko> qpid-cpp even
[18:53] <roaksoax> doko: yep :) and crmsh needs mir if you free :)
[18:54] <doko> ok, I'll see, although it's end of day
[19:00] <barry> slangasek: it' start here: http://python3porting.com/ (has a lot of stuff not just unicode)
[19:02] <slangasek> barry: so http://python3porting.com/noconv.html ?
[19:03] <barry> slangasek: avoiding 2to3 is definitely preferred!
[19:03] <slangasek> especially for the testsuite ;)
=== slomo__ is now known as slomo
[19:04] <barry> slangasek: unless you like waiting minutes each run for 2to3 to do its thing :)
=== Ursinha is now known as Ursinha-afk
=== Ursinha-afk is now known as Ursinha
[19:35] <slangasek> jibel: how important is bug #1167266  (apt-clone adt failure on armhf)?  AIUI proposed-migration will only care about i386/amd64
[19:35] <ubottu> bug 1167266 in apt-clone (Ubuntu) "test_restore_state_simulate failed on arm because acpi-support is not available on this architecture" [Undecided,New] https://launchpad.net/bugs/1167266
[19:39] <infinity> slangasek: proposed-migration only cares about x86 tests for now, yes.  Still poor form to have x86 specific tests that don't exit cleanly on other arches.
[19:39] <slangasek> infinity: I'm not disputing that it's a bug, I'm asking what its priority should be
[19:39] <infinity> slangasek: Yeah, not a critical blocker from the POV of p-m.
[19:40] <slangasek> sure.  are there other reasons we might consider it a priority to have clean adt results on armhf later?
[19:42] <infinity> slangasek: Some day, I imagine we'd like to run more tests on ARM and, when we have enough (and fast enough) kit, to even block on it, but none of that is this month (or year?).
[20:21] <ari-tczew> barry: ping
[20:21] <barry> ari-tczew: pong
[20:23] <ari-tczew> barry: I've checked merge on python-gnupg and my POV is that can be synced. do you mind?
[20:24] <barry> ari-tczew: do you have a bug #?
[20:29] <ari-tczew> barry: I've not yet requested. I'd like to first ask you.
[20:29] <barry> ari-tczew: let me look
[20:29] <ari-tczew> ok
[20:30] <barry> ari-tczew: the merge of the source package produces conflicts, but i think i can straighten that out.  mind if i just go ahead and do that?
[20:34] <barry> ari-tczew: otoh, if you have the time and inclination, feel free to open a bug, and provide a debdiff or merge proposal
[20:38] <ari-tczew> barry: Well, I could request a sync. Look @ debdiff between current Ubuntu package und Debian: http://paste.ubuntu.com/5916134/
[20:38] <ari-tczew> I asked you because I'm not sure about refreshed skip_network_needing_test.patch in Debian
[20:41] <barry> ari-tczew: just a sec
[20:45] <barry> ari-tczew: i wouldn't want to drop the ubuntu changelog entries
[20:46] <barry> ari-tczew: if the refreshed patch still applies, then i think it's appropriate.  the key thing is that the buildds won't have access to keyserver.ubuntu.com so that test must be skipped
[20:50] <ari-tczew> well, wouldn't you to sync?
[20:56] <barry> ari-tczew: probably so.  file a bug so we can refer to it in the syncrequest
[20:56] <ari-tczew> barry: builds fine, so patch applies clearly. shall do I attach buildlog?
[20:56] <barry> ari-tczew: yes please
[20:57] <ari-tczew> barry: ok but I have i386
[20:57] <barry> ari-tczew: that's okay, i'll do a local build to double check
=== Ursinha is now known as Ursinha-afk
[22:08] <ari-tczew> barry: bug 1205505
[22:08] <ubottu> bug 1205505 in python-gnupg (Ubuntu) "Sync python-gnupg 0.3.4-1 (universe) from Debian unstable (main)" [Undecided,New] https://launchpad.net/bugs/1205505
=== salem_ is now known as _salem
=== jbicha is now known as Guest55151